Tres zero-days en Ivanti Connect Secure dan acceso root sin autenticar

Volexity ha documentado una cadena de tres zero-days en Ivanti Connect Secure que permitió ejecutar comandos como root sin credenciales en un appliance con todos los parches al día, y Ivanti corrige dos de los fallos con el CVE-2026-104935. El tercero, una escalada de privilegios, sigue sin parche, y CISA incluyó el CVE en su catálogo KEV el 13 de octubre de 2026.

Qué ha pasado

Ivanti avisó el 13 de octubre de 2026 de que un zero-day en sus appliances VPN Connect Secure (ICS) se está explotando en ataques reales. El CVE-2026-104935 es una omisión de autenticación que permite a un atacante remoto y sin credenciales ejecutar comandos arbitrarios, y el fabricante reconoce explotación contra un número limitado de clientes.

El hallazgo es de Volexity, que investigaba un incidente en uno de sus clientes. La firma empezó a analizar actividad sospechosa el 5 de octubre de 2026 y sitúa el inicio de la explotación el 3 de octubre. El appliance comprometido ejecutaba la versión 22.8R2.4 (compilación 19097), así que estaba totalmente parcheado cuando entraron. Todos los detalles técnicos están en el informe original de Volexity.

Volexity sigue al responsable como UTA0576, un actor sin documentar hasta ahora. La firma valora con confianza baja que actúa por motivos criminales y lo resume así: «UTA0576 has criminal, rather than espionage, motivations» (UTA0576 tiene motivaciones criminales y no de espionaje). Ivanti pide a los clientes de versiones afectadas que actúen de inmediato y que ejecuten con regularidad su Integrity Checker Tool, según su comunicado de octubre.

CISA añadió el CVE al catálogo KEV el 13 de octubre de 2026 y fijó el 16 de octubre como fecha límite para las agencias federales. Llega dos días después de que publicáramos que FortiBleed seguía activa contra firewalls FortiGate, de modo que dos fabricantes de acceso remoto perimetral acumulan ahora avisos de explotación en la misma semana.

Detalles técnicos

La cadena de ataque, según Volexity, tiene tres pasos. El primero abusa de welcome.cgi, el CGI público de inicio de sesión, que acepta la petición por su ruta URL mientras una cabecera personalizada decide qué CGI interno la procesa. Con eso, una petición sin autenticar alcanza manejadores protegidos. El segundo paso usa wu.cgi, un manejador de subida que escribe el contenido del atacante en disco antes de validarlo. El fichero sobrevive unos instantes y esa ventana permite ejecutarlo con la misma técnica de enrutado por cabecera. Estos dos fallos comparten el CVE-2026-104935 y dan ejecución de código como el usuario cgi-server, según The Hacker News.

El tercer paso es la escalada a root. Un servicio de mantenimiento con privilegios máximos (dsinvoked, relacionado con DSCache) confía en datos de configuración de un almacén compartido. El atacante modificó de forma temporal una librería en memoria y una entrada de configuración para ejecutar su código como root, y después restauró la configuración. Por eso el Integrity Checker Tool no lo detecta. Tampoco dejó web shell ni backdoor, ya que usó el propio canal del exploit como mando y control y repitió la cadena completa para cada comando.

Una vez dentro, UTA0576 robó las credenciales almacenadas en el appliance, entre ellas las del dominio LDAP, y con una cuenta de servicio de Active Directory consultó el directorio en busca de contraseñas LAPS y claves de recuperación de BitLocker. También probó credenciales con una herramienta Kerberos propia, lanzó password spraying, capturó tráfico LDAP con un tcpdump renombrado y manipuló logs para borrar rastro. Si quieres situar este tipo de equipo en el mapa de la red, nuestro repaso de FWaaS y la VPN SSL explica por qué estos appliances son un objetivo tan rentable.

Como el atacante no dejó nada en disco, Volexity reconstruyó la intrusión con volcados de memoria analizados en su herramienta Volcano. La pestaña de alertas delató enseguida el sniffer del atacante. El proceso dsstatmond (PID 5012) aparece capturando tráfico de red y ejecutándose desde un directorio oculto, dos señales que la misma herramienta asocia también a backdoors conocidos como BPFDoor.

La tabla de procesos confirma lo que era dsstatmond. Se trata de un tcpdump renombrado que corre desde /data/.icscap, un directorio que no aparece en un listado normal del sistema de ficheros. Su filtro solo guarda tráfico de protocolos que viajan en claro, como LDAP, HTTP, FTP y telnet, que es justo donde un appliance VPN ve pasar credenciales y comandos de administración.

La memoria también conservaba buena parte del material del atacante. En la siguiente captura se ven los scripts de Python, los ficheros JSON con los resultados de las consultas a Active Directory y las capturas PCAP que generaba dsstatmond, recuperados aunque el atacante los había borrado del disco.

Indicadores publicados por Volexity de este incidente:

Volexity mantiene la lista completa en su repositorio de inteligencia de amenazas. Un comando de comprobación sobre los logs de un proxy inverso o un WAF situado delante del appliance puede servir de primer filtro:

grep -i "X-DSCGI-PATH" access.log | grep "welcome.cgi"

Comando de elaboración propia a partir de los indicadores de Volexity. Cualquier coincidencia pide revisar el contexto, porque la señal útil es la discrepancia entre la ruta y el valor de la cabecera.

A quién afecta

A quien tenga un Connect Secure expuesto en las ramas 22.8 y 25.1 sin las versiones corregidas. El registro CVE, citado por The Hacker News, da como no afectada la 22.7R2.14 y anteriores. Ni Ivanti ni Volexity han dicho cuántos clientes han sufrido ataques. En las fuentes consultadas no aparecen cifras de exposición en España ni un aviso de INCIBE-CERT o del CCN-CERT sobre este CVE a fecha de 13 de octubre de 2026.

Qué hacer

1. Actualiza a la versión corregida de tu rama: 22.8R2.5, 25.1.1.2, 25.1.3.0 o 25.1.3.1. Empieza por los appliances accesibles desde Internet.
2. Busca en los logs peticiones en bloque a /dana-na/auth/url_default/welcome.cgi con la cabecera X-DSCGI-PATH y una ruta distinta de la solicitada.
3. Comprueba en el appliance si existen el directorio /data/.icscap/, el proceso dsstatmond o los ficheros temporales de la tabla de indicadores.
4. No des por bueno el resultado del Integrity Checker Tool. Para confirmar o descartar una intrusión, Volexity pide análisis forense de red y de memoria.
5. Si hay indicios, restablece las credenciales expuestas: cuentas de servicio de Active Directory y LDAP configuradas en el appliance, contraseñas LAPS y, si se consultaron, las claves de recuperación de BitLocker. La gestión de identidades y accesos decide aquí cuánto daño puede hacer una cuenta de servicio robada.
6. Vigila el movimiento lateral y el password spraying que parta de la IP interna del appliance, y repasa los indicadores de detección de una APT en tu SIEM.
7. Aplica la corrección de la escalada de privilegios en cuanto Ivanti la publique. Según Volexity, llegará en una versión futura en las próximas semanas.
8. Si confirmas un compromiso, notifica a INCIBE-CERT (empresas y ciudadanos) o al CCN-CERT (sector público).

Análisis

El dato que más pesa es que el equipo atacado estaba en la última versión disponible. Desde el 3 de octubre hasta los parches del 13 de octubre de 2026 pasaron diez días de explotación sin parche disponible, y la herramienta de integridad del fabricante no detecta este ataque. Quien gestione ICS debería asumir que el estado del parche no demuestra que el equipo esté limpio, y que la telemetría de la red y de Active Directory pesa más que cualquier comprobación local.

Tampoco está claro lo que el aviso de Ivanti no cuenta. No hay workaround para quien no pueda actualizar, no se publica el vector CVSS y no se explica si actualizar expulsa a un intruso que ya esté dentro, según The Hacker News. Hay precedentes en el mismo producto. A finales de 2023 Volexity detectó otra cadena de dos fallos en Connect Secure que acabó explotada por varios grupos, y cabe esperar que otros actores copien la técnica cuando los indicadores se difundan.

Volexity añade una valoración con confianza media, y la damos como suya. La firma cree que UTA0576 usa LLM para desarrollar exploits y para la actividad posterior al acceso, y lo apoya en el uso continuo del canal del exploit, en los scripts específicos con credenciales fijas y en la complejidad de la cadena. Si es cierto, el ritmo de aparición de cadenas de este tipo seguirá subiendo y conviene medir la capacidad real de detección con ejercicios de simulación de ataques.

Preguntas frecuentes

¿Estoy a salvo si ya he actualizado mi Connect Secure?

Los parches cierran la omisión de autenticación y la ejecución remota, que son los dos pasos que dan la entrada sin credenciales. La escalada a root, último paso de la cadena documentada, sigue pendiente de corrección. Si tu equipo estuvo expuesto desde el 3 de octubre de 2026, el parche no borra una intrusión previa, así que revisa los indicadores igualmente.

¿Sirve el Integrity Checker Tool para saber si me han atacado?

No en este caso. El exploit altera código de librerías solo en memoria y restaura después los datos de configuración, y el atacante tomó medidas para evadir la herramienta. Ivanti recomienda ejecutarla con regularidad, pero Volexity indica que confirmar un compromiso exige análisis forense de red y de memoria.

¿Existe una mitigación mientras llega el parche del tercer fallo?

Las fuentes consultadas no nombran ninguna mitigación temporal. Lo que cabe hacer es instalar las versiones corregidas de los dos primeros fallos, limitar la exposición del appliance cuando el negocio lo permita y monitorizar la cabecera y las rutas descritas. Para repensar el perímetro como un punto más que verificar, merece la pena leer sobre la era post-perímetro.