Andy Garcia · dev freelance
FRENES
Volver al blog
Seguridad

Tres zero-days de Ivanti dieron acceso root a una VPN totalmente parcheada. La herramienta de integridad del proveedor no lo detecta

19 de octubre de 2026 7 min de lectura

El martes 13 de octubre de 2026, Volexity publicó su análisis de una intrusión que empezó en un appliance VPN Ivanti Connect Secure. Un actor que nunca había visto, ahora rastreado como UTA0576, encadenó tres vulnerabilidades zero-day para ejecutar código como root sin autenticarse. El appliance estaba totalmente parcheado en ese momento, en la versión 22.8R2.4, Build 19097. El atacante no desplegó malware ni web shell.

Ese mismo día, Ivanti publicó correcciones para dos de las tres fallas, un bypass de autenticación y un error de ejecución remota de código, rastreadas juntas como CVE-2026-104935 y con una puntuación de 8,6 en la escala CVSS. La CISA añadió CVE-2026-104935 a su catálogo de vulnerabilidades explotadas conocidas (KEV) el 13 de octubre y dio a las agencias civiles federales hasta el 16 de octubre. La tercera falla, una escalada de privilegios, no tenía parche: Volexity escribió que Ivanti la corregiría en una versión futura "en las próximas semanas". El 15 de octubre recibió su propio identificador, CVE-2026-111357, con puntuación 7,0, asignado por MITRE y no por Ivanti. A 19 de octubre, el feed de avisos de seguridad de Ivanti no listaba ninguna corrección para ella, y el catálogo de la CISA no la incluía.

Volexity describió una sola víctima. Ivanti dijo que conocía una explotación "que afecta a un número limitado de clientes" en el momento de la divulgación. El 14 de octubre, The Hacker News informó de que Previdian, que opera sensores honeypot, había registrado 105 intentos de explotación desde 50 direcciones IP; su CEO dijo que las cargas útiles servían sobre todo para probar la ejecución de código. BleepingComputer informó de que Shadowserver rastrea más de 5.500 instancias de Connect Secure expuestas en línea, sin información sobre cuántas ya están parcheadas.

No administro un appliance Connect Secure. Leí el informe como un CTO que vende software a empresas y como un desarrollador independiente que publica sus propias apps, porque rompe tres supuestos en los que casi todos nos apoyamos: parcheado significa seguro, la herramienta de verificación del proveedor lo notaría, y el parche cierra el incidente.

La cadena, en claro

Volexity tuvo que reconstruir el ataque a partir de imágenes de memoria, imágenes de disco y volcados de memoria (core dumps), porque el atacante había borrado pruebas de los registros.

Primer paso: welcome.cgi, la página pública de inicio de sesión, acepta peticiones sin autenticación. El appliance usaba la URL para decidir si una petición estaba permitida, y una cabecera, X-DSCGI-PATH, para decidir adónde iba. Apunta la cabecera a un script protegido y la página de inicio de sesión te reenvía allí.

Segundo paso: wu.cgi, un gestor de subidas, escribe el archivo subido en disco antes de comprobar que es un ZIP válido. El atacante subió un script Perl con extensión .zip y lanzó peticiones en paralelo para ejecutarlo en la breve ventana antes de que el gestor lo borrara.

Tercer paso: un servicio root llamado dsinvoked ejecuta tareas de mantenimiento y lee de un almacén de configuración compartido qué programa lanza cada tarea. El atacante modificó una biblioteca en la memoria de su propio proceso, apuntó una tarea al intérprete de Perl, hizo que dsinvoked lo ejecutara como root y luego dejó la entrada y la biblioteca como estaban.

Toda la cadena se repetía para cada comando, y cada resultado volvía en la respuesta HTTPS. Ninguna puerta trasera esperaba en el equipo. Volexity documenta explotación desde el 3 de octubre. Defused, otra firma de inteligencia de amenazas, dijo a Cybersecurity Dive que vio la primera actividad el 1 de octubre, en sus honeypots y en instancias de clientes.

"Totalmente parcheado" dependía de la rama

El detalle que subrayaría está en el aviso de Ivanti, tal como lo recogen The Register, Rapid7 y Dark Reading: Ivanti había encontrado "una parte de esta vulnerabilidad" a través de su propio programa de seguridad y la corrigió en la 25.1.3.0, publicada en julio. "Estábamos trabajando en portar la corrección al resto de versiones compatibles cuando se produjo la explotación", dijo Ivanti, citada por Dark Reading.

Las versiones afectadas son la 22.8R2.4 y anteriores, la 25.1.2.2 y anteriores, y la 25.1.1.1 y anteriores, cada una dentro de su propia línea de código; el registro CVE de Ivanti dice que la 22.7R2.14 y anteriores no están afectadas. Las versiones corregidas son la 22.8R2.5, la 25.1.1.2, la 25.1.3.0 y la 25.1.3.1. Así que la víctima estaba al día en su rama, mientras que el registro CVE de Ivanti lista la 25.1.3.0, la versión de julio de la línea más nueva, como no afectada por CVE-2026-104935: unos tres meses de ventaja que las ramas más antiguas no tuvieron. La alerta de la CISA añade que la versión 22.8 llega al fin de su vida útil el 31 de enero de 2027.

Conviene saberlo para cualquier producto con varias líneas compatibles. Una línea más antigua sigue recibiendo correcciones de seguridad, pero más tarde. La rama que ejecutas es una decisión de seguridad, no solo de compatibilidad.

La herramienta que recomienda el proveedor es la que este ataque burló

La actualización de seguridad de octubre de Ivanti pide a los clientes que actualicen y que "ejecuten regularmente la Integrity Checker Tool". El informe de Volexity dice que esta cadena no le deja nada que encontrar a esa herramienta: el parche de la biblioteca vivió solo en memoria, la entrada de configuración se restauró y la biblioteca en disco nunca se modificó. La alerta de la CISA repite el aviso: la herramienta "puede no detectar pruebas de explotación" porque los comandos se ejecutan en memoria.

La limpieza fue más lejos. La carga útil eliminó entradas recientes del registro de depuración del appliance y del registro de auditoría de Linux, borró sus propios scripts y resultados temporales, y ejecutó un tcpdump renombrado, llamado dsstatmond, desde un directorio oculto con ocho archivos de captura rotativos. Volexity dice que no ha establecido del todo hasta dónde tuvo éxito cada paso de limpieza en el dispositivo de la víctima. La intención es clara de todos modos.

Una comprobación de integridad en verde es una afirmación sobre archivos en disco. Este ataque estaba hecho para dejar esos archivos intactos.

Parchear puede borrar las pruebas

Aquí es donde yo frenaría. La guía de implementación de la CISA para la Binding Operational Directive 26-04, fechada el 10 de junio, indica a las agencias federales que recojan pruebas antes del paso de parcheo, porque "el parcheo puede poner en peligro la disponibilidad de los artefactos". Su paso de pruebas empieza con "la adquisición inmediata de datos volátiles", lo que incluye la memoria. La entrada KEV de CVE-2026-104935 lleva la marca "Forensic triage required per BOD 26-04: Yes". La directiva solo obliga a las agencias civiles federales. El razonamiento vale para cualquiera.

Cuando el ataque vive en memoria, el orden importa. Si la actualización reinicia el appliance antes de que alguien haya capturado su memoria, la mejor prueba desaparece, y lo que queda son registros que el atacante editó. Parchea rápido, sí. Pero si hay cualquier señal de que el equipo se usó, captura primero.

El objetivo real era el directorio

Lo que UTA0576 hizo con root dice cuánto vale una VPN para un atacante. Extrajo credenciales de dominio almacenadas en el appliance. Usó la cuenta de servicio de Active Directory del appliance para buscar contraseñas de administrador local LAPS, claves de recuperación de BitLocker y atributos que contenían contraseñas. Desplegó una herramienta Kerberos a medida, hizo password spraying e intentó sacar credenciales del tráfico LDAP capturado. Volexity evalúa con confianza alta que era preparación para el movimiento lateral, y con confianza baja que el motivo es criminal y no espionaje.

La señal que lo delató fue mundana. Sean Koessel, vicepresidente de servicios profesionales de Volexity, dijo a Cybersecurity Dive que el equipo notó "fallos de autenticación originados en la interfaz interna" del appliance VPN. Una VPN no tiene por qué probar contraseñas contra tu propio directorio.

Volexity también evalúa, con confianza media, que el actor usó grandes modelos de lenguaje para desarrollar exploits y para la posexplotación, citando "scripts muy específicos con credenciales incrustadas en el código" en lugar de herramientas genéricas. Yo oriento mi propio trabajo con Claude Code, así que esa parte no me sorprendió: un script escrito para una sola red cuesta ahora poco, y un script de un solo uso no coincide con ninguna firma conocida. Los defensores usan las mismas herramientas. Dark Reading informó de que un portavoz de Ivanti dijo que el descubrimiento de julio procedía del propio proyecto LLM de Ivanti, que usa varios modelos de IA para encontrar y corregir fallas en sus productos. Volexity agradeció al programa Trusted Access for Cyber de OpenAI, diciendo que sus modelos de ciberseguridad reducen drásticamente el tiempo de análisis. El proveedor encontró primero parte del error; la corrección aun así no llegó a todas las ramas a tiempo.

Qué comprobaría ahora

Si ejecutas un appliance Connect Secure, o heredas uno a través de un cliente o de un proveedor de TI:

  1. Compara la versión exacta con la lista de versiones corregidas de arriba, y planifica salir de la 22.8 antes del 31 de enero de 2027.
  2. Si tus registros capturan las cabeceras de las peticiones, busca ráfagas de peticiones a /dana-na/auth/url_default/welcome.cgi con una cabecera X-DSCGI-PATH, y cualquier desajuste entre la ruta de la URL y esa cabecera, como recomienda Volexity. Espera que los atacantes encuentren otras rutas.
  3. Busca intentos de autenticación que vengan de la interfaz interna del appliance, y restos en /tmp/.
  4. Si algo parece raro, captura memoria y disco antes de actualizar. Después sigue la lista de recuperación de la CISA: copia de seguridad de la configuración, restablecer de fábrica o reconstruir en la última versión, restaurar la configuración, restablecer todas las contraseñas de dominio, de administrador y locales, revocar y reemitir los certificados almacenados, y restablecer las claves de API y las credenciales del servidor de licencias almacenadas.
  5. Pregunta qué puede leer la cuenta de servicio de directorio de la VPN. Si puede leer contraseñas LAPS o claves de recuperación de BitLocker, la VPN tiene una llave de cada máquina que esos secretos protegen.
  6. Vigila el aviso de Ivanti para la corrección de la escalada de privilegios, la falla que MITRE rastrea ahora como CVE-2026-111357. Hasta que salga, los puntos de entrada parcheados son lo único que separa a Internet de ese paso a root.

Si compras software o servicios de TI, la pregunta también cambia. No "¿estáis parcheados?" sino "¿qué rama, con qué rapidez llegan los backports a ella, y cómo sabríais si un equipo parcheado ya había sido usado?"

El appliance de esta historia hizo lo que pedía la checklist. La checklist medía lo equivocado.

Fuentes

¿Un proyecto del mismo estilo?

Diseño y despliego productos como este. Hablemos.

Hablemos