El 29 de octubre de 2026 Ivanti publicó correcciones para dos zero-days más de Ivanti Connect Secure, CVE-2026-111357 y CVE-2026-118527, que los atacantes habían encadenado con el anterior CVE-2026-104935 para lograr ejecución de código como root sin autenticación. La descripción «totalmente parcheado» corresponde a la versión que examinó Volexity (22.8R2.4 en el momento de su informe), no a las nuevas versiones corregidas. Volexity identifica al actor como UTA0576 y vio la cadena en uso desde el 3 de octubre, y el aviso del NCSC-NL señala que la 25.1.1.2, tratada antes como parcheada, sigue siendo vulnerable a los dos fallos nuevos.

Si ejecutabas la 25.1.1.2 o la 22.8R2.5 y cerraste el ticket, el compromiso de un dispositivo VPN es para ti una cuestión abierta. Las versiones corregidas son la 25.1.1.3 y la 22.8R2.6. Instalarlas es necesario y no te dice nada sobre lo que ocurrió antes de hacerlo.

Confirma las versiones afectadas y corregidas directamente en el aviso de Ivanti, la alerta de CISA y el análisis de Volexity; no pudimos leer esas páginas completas y trabajamos a partir de lo publicado en torno a ellas. NCSC-2026-0416 no es un aviso nuevo: se publicó por primera vez el 13 de octubre y después se actualizó con los dos nuevos CVE.

Qué hace la cadena de Ivanti Connect Secure con tus pruebas

Los tres fallos son una elusión de autenticación (CVE-2026-104935, CVSS 8,6), una escalada de privilegios (CVE-2026-111357, CVSS 8,8) y un fallo de subida de archivos mediante identificadores predecibles (CVE-2026-118527, CVSS 4,3). La escalada de privilegios no tenía corrección disponible cuando los ataques salieron a la luz. Volexity informa de que UTA0576 no desplegó malware ni web shell. Volvió a explotar el dispositivo para cada comando, modificó logs de forma selectiva, eliminó artefactos temporales de ejecución y restauró el estado alterado del sistema, lo que eludió el Integrity Checker Tool de Ivanti.

Volexity también afirma que no pudo establecer que todas las operaciones de limpieza tuvieran éxito. Es la única debilidad útil: la manipulación es imperfecta, pero solo la detectarás si conservas una segunda copia del registro que el atacante nunca tocó.

Volexity evalúa, con baja confianza, que el actor tiene una motivación criminal y no de espionaje. Se desconoce el alcance; Ivanti dijo que se vio afectado un número limitado de clientes, y el informe de Volexity abarca un solo dispositivo investigado. Planifica para el peor caso en tu propio dispositivo, no para el caso medio.

Un informe dice que Ivanti afirma que no hay indicadores de compromiso fiables; comprueba el aviso de Ivanti. En cualquier caso, un resultado limpio del comprobador del fabricante es una prueba débil cuando lo que se eludió fue precisamente el comprobador.

Parchear y luego buscar: la lista de respuesta a incidentes que seguiríamos

La tensión es sencilla. Rapid7 aconseja conservar la memoria y los logs antes de reiniciar o restablecer cuando sea factible, y Volexity encontró la cadena completa en memoria. Volexity advierte además de que un posible compromiso exige analizar juntos memoria, disco y red.

  1. Restringe primero la exposición. Si puedes limitar el portal a rangos de origen conocidos, o desconectarlo hasta haber capturado las pruebas, hazlo antes que nada. Un informe dice que Ivanti no publicó ninguna solución provisional oficial para los dos CVE nuevos, así que este es nuestro consejo provisional, no el de Ivanti.
  2. Pregunta a Ivanti antes de actuar y captura después memoria y disco. No hemos verificado un método para extraer una imagen de memoria del dispositivo, así que pregunta al soporte de Ivanti y a tu proveedor de respuesta a incidentes cómo hacerlo en tu versión antes de tocar la alimentación. Después toma la imagen de memoria, luego una imagen de disco o una copia de seguridad, y guarda ambas fuera del dispositivo.
  3. Actualiza a la 25.1.1.3 o a la 22.8R2.6. Ivanti recomienda que los clientes de 22.8.x pasen a la 25.1.1.3 o posterior; una fuente indica que 22.7 y 22.8 llegan al final de su vida útil el 31 de enero de 2027, así que confirma la fecha con Ivanti.
  4. Haz el threat hunting de fuera hacia dentro, con las pruebas de la sección siguiente.
  5. Rota las credenciales y decide después si reconstruyes.

Si no puedes permitirte el paso de captura, parchea igualmente y asume la pérdida. Un dispositivo explotado y sin parchear es peor que uno sin examinar.

Pruebas que deben vivir fuera del dispositivo

Esto va más allá del consejo habitual de «envía tus logs fuera del equipo». Aquí el propio comprobador de integridad del fabricante fue eludido y los logs locales se editaron de forma selectiva, así que la copia externa es tu único registro independiente. Operamos un SOC 24/7, y en nuestro servicio de Ciberseguridad los logs de los clientes se almacenan en nuestros datacenters y solo los ve personal de la UE; sea cual sea tu stack, guarda el log en un lugar que el dispositivo no pueda editar.

Cuando el comprobador de integridad puede eludirse, el único testigo honesto es la copia que salió del equipo antes de que llegara el atacante.

  • Copias de syslog reenviado y de SIEM anteriores al 3 de octubre. Compáralas con los logs locales. Un hueco, o un log local más corto que el reenviado, es un posible indicador de manipulación.
  • Logs de firewall y de proxy situados delante del dispositivo. Volexity no vio malware ni web shell, y volvió a explotar el dispositivo para cada comando, así que busca peticiones repetidas al portal, su volumen y sus direcciones de origen.
  • Datos de flujo y capturas de paquetes del segmento situado detrás.
  • Logs del controlador de dominio de todo lo que tocaron la dirección interna del dispositivo y sus cuentas de servicio.
  • La imagen de memoria que tomaste antes del reinicio.

Threat hunting en dispositivos de borde: mira detrás del dispositivo

Busca detrás del dispositivo: observa lo que hizo después el atacante, porque eso ocurre en sistemas que controlas. Volexity vio robo de credenciales, reconocimiento de Active Directory y exfiltración de datos, incluida la captura de paquetes LDAP y una herramienta LDAP en Python que buscaba contraseñas de administrador y claves de recuperación de BitLocker. Otras fuentes añaden extracción de credenciales de VPN, búsquedas de contraseñas de LAPS y password spraying.

  • Consultas LDAP desde el dispositivo o su cuenta de enlace que lean atributos relacionados con contraseñas, atributos de LAPS u objetos de recuperación de BitLocker, sobre todo en masa.
  • Patrones de inicios de sesión fallidos que parezcan password spraying desde el rango de direcciones internas de la VPN.
  • Sesiones VPN de usuarios que no estaban trabajando, o que procedan de orígenes inesperados, desde al menos el 3 de octubre.
  • Transferencias salientes desde servidores de archivos o desde el segmento del dispositivo que no coincidan con ningún trabajo de copia de seguridad ni de sincronización.

Trata las listas de IOC como un complemento. Según se informa, los indicadores de Volexity están publicados en GitHub; valídalos allí y no en recopilaciones de terceros, y no dejes que un resultado sin coincidencias dé por terminada la búsqueda.

Qué rotar

La secuencia de recuperación de CISA, según la recoge una fuente secundaria, es: copia de seguridad, restablecimiento de fábrica y actualización, restauración, restablecer todas las contraseñas, reemitir los certificados, restablecer las claves de API y las credenciales del servidor de licencias. El aviso anterior de CISA para otro fallo de Ivanti (CVE-2025-22457, abril de 2025) añadía restablecer la contraseña enable del administrador, las claves de API almacenadas y las contraseñas de usuarios locales y de cuentas de servicio. También añadía restablecer dos veces las contraseñas del entorno on-premises, revocar los tickets de Kerberos y revocar los tokens de la nube. Era otro CVE, así que contrástalo con el texto actual de Ivanti y de CISA antes de adoptarlo.

Delimita la rotación por lo que buscaba el actor, no por lo que puedas demostrar que se leyó:

  • Todas las credenciales que pasaron por el dispositivo: cuentas de enlace LDAP, cuentas locales, contraseñas de administrador y de enable.
  • Los certificados y las claves privadas alojados en él, además de las claves de API y las credenciales del servidor de licencias.
  • Los secretos del directorio que buscó el actor: contraseñas gestionadas por LAPS y, si tienes algún motivo para pensar que se leyeron, claves de recuperación de BitLocker.
  • Sesiones y tokens: tickets de Kerberos y tokens de la nube de las cuentas que se autenticaron a través de la VPN.

El restablecimiento de fábrica es una recomendación conservadora, no una prueba de persistencia. No encontramos ninguna fuente que establezca que la 25.1.1.3 o la 22.8R2.6 elimine por completo el acceso de un atacante si el dispositivo ya estaba comprometido. Nosotros lo reconstruiríamos.

Cuenta desde el 3 de octubre, no desde la fecha límite de KEV

CISA añadió ambos CVE nuevos a KEV el 30 de octubre de 2026, y los plazos para las agencias federales se publicaron como el 2 de noviembre y el 13 de noviembre; confírmalos en el catálogo. Los plazos de KEV de CISA indican cuándo la explotación se volvió innegable, no cuándo empezó. Volexity vio a UTA0576 usar la cadena desde el 3 de octubre, así que tu ventana de revisión empieza como mínimo en esa fecha, no desde el día en que actualizaste.

Fuentes