Entraron en un aparato al día y fueron a por las claves de recuperación

El 13 de octubre Volexity publicó el análisis de una intrusión en un concentrador de acceso remoto Ivanti Connect Secure. El titular técnico cabe en una línea: encadenando tres fallos distintos, un atacante al que llaman UTA0576 obtuvo ejecución de código con permisos de root, sin autenticarse, sobre un aparato que el informe describe como «fully patched (22.8R2.4, Build 19097)». Volexity sitúa la explotación al menos desde el 3 de octubre; la empresa de detección Defused dice haber visto los primeros intentos el día 1. La corrección salió el 13: entre diez y doce días.

Si no usas ese producto, lo cómodo es pasar de largo. Nosotros tampoco lo vendemos ni lo desplegamos. El valor de este informe está en otra parte: es de los pocos que cuenta, paso a paso, qué hizo el atacante una vez dentro. Y esa lista, leída despacio, no es un inventario de credenciales. Es el índice de tu plan de recuperación.

Tres fallos, un CVE, y uno que sigue sin arreglar

La cadena tiene tres eslabones: un salto de autenticación en welcome.cgi, que permite llegar a ficheros CGI protegidos; una ejecución de código en wu.cgi, por escritura de fichero con una condición de carrera; y una elevación de privilegios a través del mecanismo de confianza con el que dsinvoked lee su configuración almacenada en DSCache. Los dos primeros van juntos bajo CVE-2026-104935, que es lo que se parcheó el 13 de octubre en las versiones 22.8R2.5, 25.1.1.2, 25.1.3.0 y 25.1.3.1. El tercero, la elevación de privilegios, no tenía CVE asignado cuando se publicó el análisis y sigue sin corrección: según Volexity, Ivanti trabaja en el arreglo y llegará en una versión futura «in the coming weeks».

Ese detalle, por sí solo, ya descoloca a cualquier proceso de gestión de vulnerabilidades: un eslabón de una cadena activamente explotada que no aparece en ningún feed, porque no tiene identificador que seguir. Tu escáner no puede decirte nada de algo que no existe en el catálogo.

Ni puerta trasera ni web shell

La parte que cambia el razonamiento de defensa es esta. Según Volexity, UTA0576 «passed commands and results through the exploit chain's HTTPS requests rather than a separate command-and-control (C2) channel, with no backdoor or web shell deployed to the compromised device». No hubo puerta trasera. No hubo web shell. No hubo canal de mando separado que un cortafuegos de salida pudiera ver raro. Y para cada orden que ejecutaban, dice el informe, «the entire exploit chain is executed»: volvían a entrar desde cero, una vez por comando.

La limpieza tampoco fue un borrado bruto. El código leía los dos registros que importan —/home/runtime/dlogs/debuglog y /var/log/audit/audit.log—, filtraba las entradas de la ventana temporal en la que habían estado y volvía a escribir los ficheros con el resto. No queda un hueco evidente ni un fichero a cero, sino un registro perfectamente verosímil al que le faltan unos minutos que nadie echa de menos.

Conviene no exagerarlo, porque el propio informe acota el alcance: sí quedaron artefactos, y por eso Volexity recomienda mirar el directorio /tmp/ y buscar peticiones a /dana-na/auth/url_default/welcome.cgi con cabeceras X-DSCGI-PATH sospechosas. Invisibles no fueron. Lo que dejaron, eso sí, está en sitios que ningún procedimiento de revisión rutinaria mira.

La herramienta que debía decírtelo dice que está limpio

El fabricante publica una utilidad, el Integrity Checker Tool, cuyo trabajo es exactamente ese: detectar modificaciones no previstas en los ficheros del aparato. Volexity lo explica sin rodeos: «because this exploit chain patches library code in memory only and restores configuration store data, the tool does not detect any modifications». CISA lo repitió el mismo día en su aviso, con la misma crudeza: la herramienta «may not detect evidence of exploitation of CVE-2026-104935 because threat actor commands execute in memory», y por eso recomienda análisis forense de red y de memoria a quien sospeche.

Y en la misma semana, el consejo del fabricante a sus clientes seguía siendo revisar el aviso, actualizar cuanto antes y «run the Integrity Checker Tool regularly». Las dos cosas pueden ser razonables a la vez —la herramienta sigue sirviendo para otras cosas— pero hay que leerlas juntas, porque la conclusión práctica es incómoda: un resultado limpio de esa herramienta no es una respuesta. Es la ausencia de una.

Nos apuntamos la corrección, porque la recomendación por defecto nuestra, y la de medio sector, después de un aviso sobre un aparato cerrado es «pásale la herramienta de integridad del fabricante». Aquí ese paso no cierra nada. Y el forense de memoria que sí lo cerraría exige acceso que en un aparato cerrado no tienes, y una herramienta de la que casi ninguna pyme dispone. Entre «no hay indicios» y «no hay forma de tener indicios» hay toda la distancia que separa cerrar un incidente de archivarlo sin saber.

LAPS, BitLocker y una herramienta que no llegaron a usar

Que se llevaron contraseñas de LAPS y claves de BitLocker lo ha contado toda la cobertura de esta semana; no es un hallazgo nuestro ni está escondido. Lo que casi nadie ha dicho es qué tipo de material es ese. Para llegar ahí hay que mirar la lista entera de actividad posterior a la intrusión que documenta Volexity:

• Extrajeron las credenciales de dominio de la cuenta de servicio LDAP con la que el aparato consulta el directorio.
• Desplegaron una herramienta LDAP en Python que buscaba, textualmente, contraseñas de LAPS, información de recuperación de BitLocker y atributos de Active Directory con valores userPassword y unixUserPassword.
• Subieron también una implementación propia de Kerberos en Python con funcionalidad de Kerberoasting que, dice Volexity, el guion que la invocaba no llegó a usar. Tenían la capacidad y priorizaron otra cosa.
• Capturaron tráfico filtrando protocolos en claro como LDAP (TCP 389), HTTP, FTP o telnet: por ahí siguen circulando credenciales sin cifrar en una red de empresa.
• Intentaron extraer nombres de usuario válidos de los registros de autenticación del propio aparato (log.events.vc0), y con ellos hicieron password spraying contra el directorio.
• Y se llevaron metadatos del Directorio Activo y la configuración del concentrador.

Las contraseñas de LAPS son las de administrador local de cada equipo: las que usas cuando una máquina no arranca en el dominio. Las claves de BitLocker son las de recuperación: las que usas cuando el disco no monta. Ninguna de las dos sirve para trabajar un martes cualquiera; las dos son el material con el que recuperas cuando algo ya ha salido mal. Y es lo primero que alguien fue a pedirle al directorio en cuanto tuvo permisos para preguntar, teniendo a mano un ataque Kerberos que ni siquiera lanzó.

Tu plan está escrito contra el borrado

Un plan de continuidad normal mide una sola cosa: cuánto tardas en volver a tener aquello que has perdido. RTO, RPO, copias inmutables, réplica en otro sitio, ensayo de restauración. Todo el aparato conceptual está construido contra la destrucción: algo se borra, se cifra, se rompe, y tú lo repones.

Copiar no destruye nada. Una copia no apaga un servicio, no dispara una alerta de disponibilidad, no abre un ticket, no consume RTO y no activa ningún plan. Tus claves de recuperación de BitLocker siguen ahí después de que alguien se las lleve: funcionan igual de bien, para ti y para él. Esa es la razón exacta por la que este escenario no está en casi ningún plan de continuidad que hayamos leído, incluidos los que están bien hechos y el plan de continuidad que nadie ha ensayado: no hay nada que restaurar, así que no hay nada que ensayar.

Y hay un segundo reloj corriendo. Las obligaciones europeas de notificación —NIS2 para quien esté en su ámbito, con su alerta temprana de 24 horas, y el RGPD con sus 72 si hay datos personales— arrancan cuando tienes conocimiento del incidente, no cuando el incidente ocurre. Es el mismo mecanismo del que escribimos a propósito del Cyber Resilience Act: el reloj arranca cuando te enteras. Aquí la herramienta diseñada para que te enteres está documentada, por el fabricante y por CISA, como incapaz de enterarse. Quién decide entonces que se ha «tenido conocimiento», y con qué prueba, es una pregunta que no se responde bien a las once de la noche de un martes.

El censo que falta: qué pasa si se copia

Lo que sí se puede hacer esta semana, sin comprar nada, es un censo de dos columnas. A la izquierda, lo que pasa por tu acceso remoto. A la derecha, la pregunta que no está en ninguna auditoría de copias: no «qué pasa si se borra», sino qué pasa si se copia. Con estas cuatro filas se empieza:

Falta la tercera columna, que no cabe en la tabla porque es un nombre propio: quién rota cada una de esas cuatro cosas, y en cuánto tiempo. El objetivo del ejercicio es poder decir, el día que un aviso diga que tu aparato de acceso remoto estuvo expuesto y no puedas demostrar nada, qué das por copiado y qué rotas, sin convocar una reunión para decidirlo. Si al rellenarlo descubres que nadie sabe qué cuenta de servicio usa el concentrador, ese ya es el resultado y vale el rato invertido.

Dos apuntes de calendario para cerrar el operativo. El procedimiento que CISA publica para quien sospeche termina en «Reset all passwords and revoke/reissue certificates and API keys», que es exactamente la columna derecha de arriba; esa misma tensión entre restaurar y rotar la vimos esta mañana desde el otro lado: el procedimiento oficial para recuperar un GitLab empieza con un DELETE. Y el aviso añade un detalle que conviene mirar antes de celebrar la actualización: la rama 22.8 llega a fin de vida el 31 de enero de 2027, así que salir por 22.8R2.5 compra tres meses y medio.

Lo que queda apuntado

El aparato que mira a internet por diseño es, casi siempre, el que menos puedes auditar: no le instalas un agente, no le lees la memoria, no entras por consola a mirar un proceso. Contábamos hace unos días que solo uno de cada ocho fallos explotados está en un aparato —son pocos en el recuento, y pesan muchísimo en las consecuencias—. Este caso añade el porqué: cuando el fallo cae ahí, lo que se lleva el atacante no es un servidor, es el permiso de preguntarle cosas a tu directorio. Y el directorio contesta a todo, incluido dónde guardas las llaves de repuesto.

Fuentes (consultadas el 14-10-2026): la cadena de tres fallos, los componentes afectados, la compilación 22.8R2.4 Build 19097, el «al menos desde el 3 de octubre», la frase sobre la ausencia de puerta trasera y canal de mando, la reejecución de la cadena por comando, las dos rutas de registro manipuladas, la limitación del Integrity Checker Tool y toda la lista de actividad posterior a la intrusión —incluidas las contraseñas de LAPS y las claves de BitLocker— salen del análisis de Volexity del 13 de octubre de 2026. La advertencia de CISA sobre la herramienta, la recomendación de forense de red y memoria, el procedimiento de recuperación y el fin de vida de la rama 22.8 están en su aviso del 13 de octubre; el alta en el catálogo de vulnerabilidades explotadas, en el aviso del mismo día. Las versiones corregidas y la situación del tercer fallo están recogidas por SecurityWeek, la recomendación del fabricante de seguir pasando la herramienta de integridad y la fecha del 1 de octubre que aporta Defused, por BleepingComputer. Un matiz que el propio informe marca y nosotros repetimos: Volexity atribuye con baja confianza una motivación criminal y no de espionaje, y con confianza media el uso de modelos de lenguaje por parte del atacante; son valoraciones, no hechos. Y un flanco de nomenclatura, por si vas a la fuente oficial: el catálogo KEV titula CVE-2026-104935 solo como Authentication Bypass by Spoofing Vulnerability, mientras que Volexity y la prensa especializada lo presentan cubriendo también la ejecución de código. No hemos reproducido la cadena, no desplegamos ese producto y no tenemos telemetría propia sobre su explotación. Lo nuestro es la lectura de la actividad posterior como índice del plan de recuperación y la tabla de «qué pasa si se copia».