critica research global

Cadena de zero-days da root en Ivanti pese al parche

Volexity documentó explotación activa desde al menos el 1 de octubre contra appliances ya actualizados. Uno de los tres fallos encadenados sigue sin CVE ni parche, y el verificador de integridad del fabricante podría no detectar el compromiso.

·13 min de lectura ·Equipo Vantis
En 30 segundos
  • Un actor identificado por Volexity como UTA0576 encadenó tres vulnerabilidades en Ivanti Connect Secure (ICS) para obtener ejecución de código como root sin autenticación, incluso contra un appliance que corría la versión 22.8R2.4 completamente parchada al momento del ataque.
  • Ivanti liberó parche el 13 de octubre de 2026 para dos de los tres eslabones (CVE-2026-104935, CVSS 8.6); el tercero, una escalada de privilegios vía el servicio dsinvoked, no tiene CVE asignado ni corrección disponible.
  • El actor no dejó webshell ni backdoor: operaba replicando la propia cadena de explotación sobre HTTPS, con modificaciones solo en memoria, borrado selectivo de logs y reversión de sus propios parches. Volexity advierte que la herramienta de integridad de Ivanti podría no detectar esta actividad.

Qué pasó

Esta nota de Vantis parte de un research note publicado por Cloud Security Alliance (CSA Labs) el 16 de octubre de 2026, que a su vez sintetiza hallazgos técnicos de Volexity —la fuente primaria de este caso— junto con cobertura de Rapid7, BleepingComputer, Help Net Security y el aviso oficial de Ivanti.

Según Volexity, el actor UTA0576 combinó tres fallas para llegar a ejecución de código como root sin autenticar en Ivanti Connect Secure:

  1. Bypass de autenticación en welcome.cgi: una solicitud puede incluir el encabezado X-DSCGI-PATH, que redirige internamente la petición hacia un script protegido como wu.cgi, mientras el appliance autoriza según la URL visible y no según el destino real.
  2. Ejecución remota de código en wu.cgi: el manejador acepta un archivo subido, calcula un hash MD5 del nombre y lo escribe temporalmente en disco; existe una condición de carrera entre la creación del archivo y su borrado tras validación, que el atacante gana enviando solicitudes en paralelo.
  3. Escalada de privilegios mediante un parcheo en memoria de libdsplibs.so, que hace que el servicio dsinvoked ejecute scripts Perl arbitrarios como root.

Los dos primeros eslabones están cubiertos por CVE-2026-104935 (bypass de autenticación por spoofing, CWE-290, CVSS v3.0 8.6), corregido en las versiones 22.8R2.5, 25.1.1.2, 25.1.3.0 y 25.1.3.1. Quedan afectadas 22.8R2.4 y anteriores, 25.1.1.1 y anteriores, y 25.1.2.2 y anteriores. Ivanti reconoció explotación activa y CISA agregó el CVE a su catálogo KEV el mismo día; el Canadian Centre for Cyber Security emitió el aviso AV26-1035. El tercer eslabón no tiene CVE ni parche a la fecha de esta nota.

Sobre la cronología hay una diferencia que vale la pena marcar con precisión: Volexity sitúa el *inicio* de la explotación "no más tarde del 3 de octubre" (es decir, un límite superior), mientras que cobertura relacionada con CISA habla de actividad "desde al menos el 1 de octubre" (un piso observado). No son el mismo tipo de afirmación, y la nota de CSA lo señala explícitamente. Para efectos de cacería de amenazas, conviene partir desde la fecha más temprana, el 1 de octubre.

Un detalle operativo relevante: el actor no instaló persistencia tradicional. Según Volexity, los comandos y resultados viajaban dentro de las propias solicitudes HTTPS de la cadena de explotación, sin canal de comando y control separado ni webshell en disco. Eso significa que cada acción del atacante requería volver a explotar el appliance, y que el acceso dependía de que las vulnerabilidades siguieran abiertas, no de un implante persistente.

El objetivo posterior a la explotación fue el entorno de Active Directory circundante: extracción de credenciales vía herramientas LDAP y Kerberos a medida, recolección de contraseñas LAPS y llaves de recuperación BitLocker, captura de tráfico buscando protocolos en texto plano, y password spraying contra cuentas de AD. El payload además borró selectivamente entradas de /home/runtime/dlogs/debuglog y /var/log/audit/audit.log, se autoeliminó, y revirtió sus propios parches en memoria.

Shadowserver reporta, según cifras citadas por BleepingComputer, más de 5.500 y hasta 5.600 instancias de ICS expuestas a internet; ninguna de las dos cifras tiene fecha de corte ni indica cuántas siguen vulnerables.

Por qué importa acá

No tenemos confirmación de organizaciones chilenas afectadas en esta campaña específica, y no la vamos a inventar. Dicho eso, Ivanti Connect Secure es un producto de VPN de perímetro, categoría de software que en Chile suele operar en banca, salud y organismos públicos —justamente los sectores que la Ley 21.663 define como potenciales Operadores de Importancia Vital (OIV). Si una entidad OIV identifica que un appliance ICS estuvo expuesto a internet con una versión afectada desde el 1 de octubre en adelante, el deber de evaluar si corresponde reporte a ANCI nace de ese hecho, independientemente de si esta campaña puntual la tocó.

Hay dos puntos de la nota de CSA que merecen una lectura con nivel de confianza explícito, porque son evaluaciones de Volexity, no hechos verificados de forma independiente:

Nuestra propia evaluación, con confianza media, es que este caso confirma un patrón que CSA ya venía documentando con SonicWall SMA (julio y octubre de 2026) y Cisco SD-WAN (junio de 2026): dispositivos de borde que concentran privilegios de directorio, con ventanas cada vez más cortas entre descubrimiento y explotación. La alternativa que no podemos descartar es que se trate de casos aislados sin relación operativa entre sí, simplemente coincidentes en la superficie de ataque que eligen los actores (dispositivos de borde en general, no un mismo grupo o kit). Lo que sí es un hecho reportado por Volexity, y no una evaluación nuestra, es que el parcheo del 13 de octubre no cierra completamente la exposición: la escalada de privilegios sigue sin corrección, y la herramienta de integridad de Ivanti podría no detectar actividad que existió solo en memoria.

Para efectos prácticos: parchar es necesario pero no es el fin del trabajo. Cualquier appliance que estuvo expuesto a internet con una versión vulnerable desde el 1 de octubre debe tratarse como potencialmente comprometido hasta que un análisis forense de red y memoria diga lo contrario — esto es un juicio precautorio explícito de la propia fuente, no una afirmación de que todos los equipos fueron explotados.

Anatomía del ataque

Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.

Qué hacer, fase por fase

Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.

GV GobernarQuien decide, que se reporta y a quien

Si su organización es un OIV bajo la Ley 21.663 (banca, salud, sector público, utilities) y opera Ivanti Connect Secure, este incidente debería gatillar una decisión formal: ¿se activa el parcheo de emergencia fuera de ciclo?, ¿se informa a la gerencia de riesgo antes o después de confirmar exposición?, ¿hay base para un reporte a ANCI? No citamos plazos de reporte específicos porque la fuente no los entrega para este caso puntual; verifique los plazos vigentes directamente con ANCI según la clasificación de su organización.

  • Designar un responsable único de la decisión de parcheo de emergencia para dispositivos de borde, con autoridad para sacar el equipo de producción si es necesario.
  • Evaluar con el equipo legal/cumplimiento si la exposición de ICS desde el 1 de octubre configura un hecho reportable a ANCI bajo Ley 21.663.
  • Incluir el historial de zero-days de Ivanti (2024, 2025, 2026) como factor en la próxima revisión de riesgo de terceros/proveedores.
ID IdentificarSi esto me toca, por donde me toca

El primer paso no es parchar, es saber qué tiene expuesto. Inventaríe todos los appliances ICS, su versión exacta y su exposición real a internet desde el 1 de octubre.

  • Listar todas las instancias de Ivanti Connect Secure en la organización y confirmar versión exacta (22.8R2.4 o anterior, 25.1.1.1 o anterior, 25.1.2.2 o anterior = afectadas).
  • Confirmar si cada appliance estuvo accesible desde internet en algún momento desde el 1 de octubre de 2026, no solo al momento de la revisión.
  • Verificar qué privilegios de directorio tiene configurado cada appliance (cuentas de servicio, acceso a LAPS, BitLocker) para priorizar por impacto potencial, no solo por exposición.
PR ProtegerComo evito que ocurra

Parchar es obligatorio pero insuficiente mientras el tercer eslabón siga sin corrección. Los controles abajo están priorizados por costo y por lo que realmente cierra exposición.

Controles priorizados

P1: esta semana · P2: este mes · P3: este trimestre

PrioControlEsfuerzoMapeo
P1 Actualizar todos los appliances ICS a 22.8R2.5, 25.1.1.2, 25.1.3.0 o 25.1.3.1 de forma urgente, fuera del ciclo normal de parches medio MITRE ATT&CK M1051 CIS Controls v8 7.1 ISO 27001 A.8.8
P1 Capturar memoria y tráfico de red de cualquier appliance expuesto desde el 1 de octubre, antes de reiniciar o actualizar medio CIS Controls v8 8.9 ISO 27001 A.5.28
P1 Rotar credenciales alcanzables desde el appliance: cuentas de servicio de la VPN, contraseñas LAPS, llaves de recuperación BitLocker medio MITRE ATT&CK M1026 CIS Controls v8 5.3 ISO 27001 A.5.17
P2 Reenviar logs del appliance a un colector externo en tiempo real, dado que el payload borra entradas locales tras la explotación bajo CIS Controls v8 8.2 ISO 27001 A.8.15
P2 Restringir el acceso de gestión del portal a rangos de IP conocidos y segmentar la red del appliance respecto a los controladores de dominio medio MITRE ATT&CK M1030 CIS Controls v8 12.2 ISO 27001 A.8.22
P3 Evaluar una arquitectura de acceso zero trust que reduzca la dependencia de un concentrador VPN perimetral único con privilegios amplios de directorio alto MITRE ATT&CK M1030 CIS Controls v8 12.1 ISO 27001 A.8.3

El control P1 más urgente —actualizar— no cierra el tercer eslabón de la cadena (escalada de privilegios sin parche). Mientras ese fix no exista, los controles de segmentación y de logging externo son los que realmente limitan el daño de una reexplotación.

DE DetectarComo me doy cuenta de que ya ocurrio

La detección aquí es conductual: no hay firmas de archivo porque la actividad vive en memoria y en los propios logs HTTP del appliance. Lo decisivo es tener esos logs fuera del equipo, porque el payload los borra localmente.

Qué necesitas tener logueado

  • Logs de acceso web del portal ICS, reenviados por syslog a un colector externo (los logs locales son borrados selectivamente por el payload)
  • Logs de WAF o proxy reverso ubicado delante del appliance, si existe, capturando encabezados HTTP personalizados
  • Logs de autenticación de Active Directory (eventos LDAP/Kerberos, password spraying)
  • NetFlow/firewall para identificar ráfagas de solicitudes paralelas hacia el appliance consistentes con explotación de condición de carrera

Indicadores de compromiso

OjoLos indicadores están defanged (hxxp, [.]) para evitar clics accidentales. El bloque de abajo los trae en crudo, listos para tu lista de bloqueo.
TipoIndicadorConfianzaNota
header_http X-DSCGI-PATH alta Volexity (vía CSA Labs)
ruta_archivo /home/runtime/tmp/<hash_MD5_del_nombre_de_archivo_subido> media Volexity (vía CSA Labs)
directorio [.]icscap (directorio oculto usado para captura de paquetes vía dsstatmond) media Volexity (vía CSA Labs)
blocklistIndicadores en crudo
X-DSCGI-PATH
/home/runtime/tmp/<hash_MD5_del_nombre_de_archivo_subido>
.icscap (directorio oculto usado para captura de paquetes vía dsstatmond)

Reglas y consultas de detección

sigmaPosible bypass de autenticación en Ivanti ICS vía X-DSCGI-PATH
title: Ivanti Connect Secure - Posible Bypass via X-DSCGI-PATH Header
id: 7c3e9a1f-4b2d-4e8a-9f6c-1a2b3c4d5e6f
status: experimental
description: Detecta solicitudes a welcome.cgi que incluyen el encabezado X-DSCGI-PATH apuntando a un script distinto, patrón reportado por Volexity en la cadena de explotación de octubre de 2026 contra Ivanti Connect Secure.
references:
    - https://www.volexity.com/blog/
    - https://labs.cloudsecurityalliance.org/research/csa-research-note-ivanti-connect-secure-zero-day-chain-20261/
author: Vantis - Analisis de Amenazas
date: 2026-10-16
logsource:
    category: webserver
detection:
    selection_path:
        cs-uri-stem|contains: 'welcome.cgi'
    selection_header:
        cs-header-x-dscgi-path|contains:
            - 'wu.cgi'
            - '.cgi'
    condition: selection_path and selection_header
falsepositives:
    - Escaneos de vulnerabilidad autorizados que prueban la misma ruta
    - Herramientas de administración legítimas que usen el mismo encabezado por error de configuración (poco común)
level: critical
tags:
    - attack.initial-access
    - attack.t1190
    - cve.2026-104935
Requiere: Que el reverse proxy o WAF delante del appliance registre encabezados HTTP personalizados; los logs nativos del portal ICS no bastan porque el payload los modifica.
sentinel-kqlSolicitudes a welcome.cgi con header X-DSCGI-PATH sospechoso
CommonSecurityLog
| where DeviceVendor == "Ivanti" or Activity has "welcome.cgi"
| where RequestURL has "welcome.cgi"
| where AdditionalExtensions has "X-DSCGI-PATH" and (AdditionalExtensions has "wu.cgi" or AdditionalExtensions has ".cgi")
| project TimeGenerated, SourceIP, RequestURL, AdditionalExtensions, DeviceVendor
| sort by TimeGenerated desc
Requiere: Logs del appliance o del WAF/proxy ingeridos en CommonSecurityLog vía CEF/Syslog, con los encabezados HTTP conservados en AdditionalExtensions.
splunkDetección de bypass ICS por header X-DSCGI-PATH en índice proxy
index=proxy sourcetype=ivanti_ics OR sourcetype=waf
| search uri_path="*welcome.cgi*" AND (req_header="*X-DSCGI-PATH*wu.cgi*" OR req_header="*X-DSCGI-PATH*.cgi*")
| table _time, src_ip, uri_path, req_header
| sort - _time
Requiere: index=proxy con los encabezados HTTP crudos capturados; confirmar con el equipo de logging que el campo req_header no está siendo truncado o sanitizado antes de la ingesta.
wazuhRegla Wazuh para solicitudes anómalas a welcome.cgi
<rule id="100620" level="14">
  <if_sid>31100</if_sid>
  <url>welcome.cgi</url>
  <field name="http_header">X-DSCGI-PATH</field>
  <description>Posible explotacion de Ivanti Connect Secure: header X-DSCGI-PATH hacia welcome.cgi (CVE-2026-104935)</description>
  <mitre>
    <id>T1190</id>
  </mitre>
</rule>
Requiere: Decodificador de Wazuh capaz de extraer encabezados HTTP personalizados desde los logs web reenviados (requiere configuración adicional, no viene de fábrica).
Falsos positivos esperables

Escáneres de vulnerabilidades autorizados (internos o de un proveedor de pentesting) que prueben activamente este CVE generarán el mismo patrón. Correlacionar con ventanas de escaneo conocidas antes de escalar como incidente. El volumen de solicitudes paralelas hacia wu.cgi también puede coincidir, en casos raros, con pruebas de carga mal configuradas contra el portal; verificar origen antes de confirmar explotación.

RS ResponderContencion y erradicacion

Si hay sospecha de explotación, el orden de las acciones importa: capturar memoria y tráfico de red antes de reiniciar o actualizar, porque Volexity solo pudo recuperar la evidencia completa desde memoria viva.

  • Capturar memoria y tráfico de red del appliance antes de cualquier reinicio o actualización, siguiendo un proceso de adquisición forense ya ensayado.
  • Revisar logs web/proxy desde el 1 de octubre en busca de solicitudes a /dana-na/auth/url_default/welcome.cgi con el encabezado X-DSCGI-PATH apuntando a un script distinto del indicado en la URL.
  • Revisar /home/runtime/tmp/ en el appliance en busca de archivos cuyo nombre corresponda al patrón MD5(nombre_original) descrito por Volexity.
  • Si no se puede descartar explotación, asumir que las credenciales de directorio alcanzables desde el appliance fueron tomadas: rotar cuentas de servicio de la VPN, resetear contraseñas LAPS y rotar llaves de recuperación BitLocker.
  • Revisar logs de autenticación de Active Directory en busca de password spraying y actividad LDAP/Kerberos anómala en el período posterior a la exposición.
RC RecuperarVolver a operar y no repetirlo

La vuelta a operación no termina con el parche: mientras la escalada de privilegios siga sin corrección, el appliance conserva una superficie de riesgo residual que hay que compensar con controles compensatorios y monitoreo reforzado.

  • Aplicar la actualización a 22.8R2.5, 25.1.1.2, 25.1.3.0 o 25.1.3.1 de forma urgente, fuera del ciclo normal de parches.
  • Si se confirma compromiso, seguir el procedimiento de recuperación publicado por Ivanti en su aviso, incluyendo verificación de integridad posterior al parche.
  • Suscribirse al feed de avisos de Ivanti y planificar una ventana de cambio adicional para cuando se publique la corrección del tercer eslabón (escalada de privilegios).

Llévatelo

Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.

La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.

Fuentes

¿Esto te aplica y no sabes por dónde partir?

Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.

Agendar diagnóstico

Relacionado