critica alerta global

CISA confirma explotación activa de zero-day en Ivanti Connect Secure

El bypass de autenticación CVE-2026-104935 permite ejecución remota sin credenciales y ya está en el catálogo KEV de CISA. Honeypots registran intentos de explotación mientras una fuente sin corroborar habla de un tercer zero-day encadenado todavía sin parche.

·10 min de lectura ·Equipo Vantis
En 30 segundos
  • CISA agregó CVE-2026-104935 a su catálogo KEV el 13 de octubre de 2026: bypass de autenticación no autenticado en Ivanti Connect Secure que permite ejecución remota de comandos, usado de forma activa para robo de credenciales y exfiltración de datos.
  • Afecta las versiones 25.1.1.1 y anteriores, 25.1.2.2 y anteriores, y 22.8R2.4 y anteriores — prácticamente todo el parque vigente del producto hasta que se aplique el parche de Ivanti.
  • Una fuente derivada, sin corroboración independiente al momento de escribir, reporta que el ataque encadenaría hasta tres zero-days de Connect Secure para llegar a acceso root y que solo dos estarían parchados. Lo registramos como hipótesis a seguir, no como hecho confirmado.

Qué pasó

CISA publicó el 13 de octubre de 2026 una alerta sobre CVE-2026-104935, un bypass de autenticación en Ivanti Connect Secure que permite a un atacante remoto y no autenticado ejecutar comandos arbitrarios en el appliance. La agencia indica que actores de amenaza ya lo están explotando para robo de credenciales y exfiltración de datos, y lo agregó el mismo día al catálogo KEV.

Las versiones afectadas son 25.1.1.1 y anteriores, 25.1.2.2 y anteriores, y 22.8R2.4 y anteriores. Ivanti publicó un aviso de seguridad con la versión corregida y recomienda ejecutar el Integrity Checker Tool (ICT) antes y después de parchar.

Una nota de The Hacker News del 14 de octubre, citando telemetría de honeypots, reporta 105 intentos de explotación observados — es una fuente derivada que reporta sobre el mismo hecho que CISA, no una confirmación independiente adicional. Una segunda nota del mismo medio, del 13 de octubre, plantea algo más serio: que el atacante estaría encadenando tres zero-days de Connect Secure para llegar a acceso root, de los cuales solo dos tendrían parche disponible. Confianza baja: es una sola fuente derivada, sin que CISA o Ivanti lo confirmen en sus avisos oficiales a la fecha de este análisis. Lo nombramos porque, si se confirma, cambia la urgencia del parche — pero no lo tratamos como hecho.

Por qué importa acá

Connect Secure (ex Pulse Secure) es una de las plataformas VPN de acceso remoto más desplegadas en banca, gobierno y empresa grande en Chile. No tenemos una cifra de instalaciones locales — confianza media en que la exposición chilena es real y significativa, basada en que es un producto de categoría enterprise con presencia histórica en el mercado regional, no en un conteo verificado. Lo que sí es un hecho: es un appliance de borde, expuesto a Internet por diseño, y un bypass de autenticación no autenticado en ese tipo de activo es exactamente el patrón que en 2024 llevó a decenas de intrusiones con Connect Secure/Pulse Secure a nivel global.

La herramienta de corroboración de esta pieza también marcó como fuente primaria coincidente una alerta previa de ANCI, AVC26-00636 ("Ivanti EPMM - Vulnerabilidad Crítica", mayo 2026). Al revisarla, corresponde a Ivanti EPMM (Endpoint Manager Mobile), un producto distinto de Connect Secure, y el cruce se dio solo por el nombre del fabricante, no por el CVE. No la contamos como corroboración de este caso. La mencionamos únicamente como antecedente: Ivanti ha sido blanco de vulnerabilidades críticas explotadas activamente más de una vez en lo que va de 2026, en productos distintos.

Si una organización chilena calificada como Operador de Importancia Vital bajo la Ley 21.663 tiene un appliance Connect Secure comprometido con exfiltración de datos, eso configura un incidente reportable a ANCI. No citamos un plazo específico de reporte porque no lo verificamos para este caso puntual, pero la obligación de reporte temprano aplica igual.

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

La decisión de parchar un appliance de borde suele depender de un equipo de redes, no del equipo de seguridad — y ese desfase de dueño es la causa más común de que un KEV quede sin aplicar por semanas. Definan hoy quién tiene la autoridad para forzar una ventana de mantenimiento de emergencia en el Connect Secure, y quién reporta a ANCI si la organización es OIV bajo la Ley 21.663 y hay evidencia de compromiso con exfiltración.

  • Confirmar por escrito quién es el dueño del ciclo de parche del appliance VPN y su SLA interno para CVEs en KEV
  • Activar el procedimiento de reporte a ANCI si la organización es OIV y se confirma compromiso con exfiltración de datos
ID IdentificarSi esto me toca, por donde me toca

Antes de cualquier otra cosa, hay que saber si el activo existe y en qué versión está. Esto se confirma en minutos, no en días.

  • Inventariar todos los appliances Ivanti Connect Secure y su versión exacta (25.1.1.1, 25.1.2.2, 22.8R2.4 u otra)
  • Verificar si la interfaz de administración está alcanzable desde Internet (Shodan/Censys con el dominio propio, o revisión directa de reglas de firewall)
  • Revisar si el equipo de redes ya aplicó el parche o solo recibió la notificación del fabricante
PR ProtegerComo evito que ocurra

El control más efectivo es el parche. Mientras se aplica, la mitigación real es reducir exposición y asumir que las credenciales pudieron verse comprometidas.

  • Aplicar la versión corregida indicada en el advisory de Ivanti
  • Ejecutar el Integrity Checker Tool (ICT) interno y externo antes y después de parchar
  • Restringir el acceso administrativo del Connect Secure a rangos IP de gestión conocidos

Controles priorizados

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

PrioControlEsfuerzoMapeo
P1 Actualizar Ivanti Connect Secure a la versión corregida indicada en el advisory del fabricante medio MITRE ATT&CK M1051 CIS Controls v8 7.1 ISO 27001 A.8.8
P1 Ejecutar el Integrity Checker Tool (ICT) interno y externo en todos los appliances, antes y después de parchar bajo MITRE ATT&CK M1016 CIS Controls v8 7.5 ISO 27001 A.8.16
P1 Restringir el acceso a la interfaz de administración del Connect Secure a rangos IP de gestión conocidos, eliminando exposición directa a Internet medio MITRE ATT&CK M1030 CIS Controls v8 4.4 ISO 27001 A.8.20
P2 Rotar credenciales y revocar sesiones VPN activas tras aplicar el parche, dado el riesgo de robo de credenciales reportado por CISA bajo MITRE ATT&CK M1027 CIS Controls v8 6.2 ISO 27001 A.5.17
P3 Evaluar migración a un modelo de acceso remoto tipo ZTNA/broker que no exponga directamente el appliance a Internet, mientras se confirma su postura de seguridad alto MITRE ATT&CK M1030 CIS Controls v8 12.2 ISO 27001 A.8.21
P3 Definir un SLA interno de parche acelerado (72 horas) para cualquier CVE agregado al catálogo KEV en dispositivos de borde medio MITRE ATT&CK M1051 CIS Controls v8 7.1 ISO 27001 A.8.8

El parche es el control que de verdad cierra la vulnerabilidad; todo lo demás es reducción de ventana de exposición mientras se aplica. Si el Connect Secure no puede parcharse de inmediato, restringir el acceso administrativo y ejecutar el ICT son las dos medidas que más rinden por esfuerzo invertido esta semana.

DE DetectarComo me doy cuenta de que ya ocurrio

No hay firma pública del exploit, así que la detección es conductual sobre los logs del proxy/WAF que recibe el tráfico hacia el portal. Las reglas de esta pieza buscan el patrón de acceso a rutas administrativas desde fuera del allowlist esperado, no una cadena de bytes específica.

  • Desplegar las reglas de detección conductual de esta pieza en modo de solo alerta durante una semana antes de bloquear
  • Revisar retroactivamente los logs del proxy/WAF desde la fecha de publicación pública del CVE, y si es posible desde antes, dado que se trata de un zero-day

Qué necesitas tener logueado

  • Logs HTTP del reverse proxy/WAF/balanceador delante del portal Ivanti Connect Secure (o syslog del propio appliance si no hay proxy intermedio)
  • Firewall perimetral / NetFlow del segmento DMZ donde vive el appliance
  • EDR en endpoints que establecen sesión VPN exitosa, para correlacionar movimiento lateral posterior

Reglas y consultas de detección

sigmaAcceso sospechoso a endpoints administrativos de Ivanti Connect Secure
title: Acceso sospechoso a endpoints administrativos de Ivanti Connect Secure
id: 7c1e4a2b-6f3d-4e21-9a8c-5b2f1d6e9c47
status: experimental
description: Detecta solicitudes HTTP POST con respuesta 200 hacia rutas administrativas o de API de Ivanti Connect Secure, patrón consistente con intentos de explotación de CVE-2026-104935 (bypass de autenticación). Es una regla conductual, no una firma del exploit: ni Ivanti ni CISA han publicado el payload a la fecha.
references:
  - https://www.cisa.gov/news-events/alerts/2026/10/13/cisa-urges-patching-newly-exploited-vulnerability-ivanti-connect-secure
logsource:
  category: proxy
  definition: 'Requiere logs de reverse proxy, WAF o balanceador situado frente al portal de Ivanti Connect Secure, con campos de IP origen, método HTTP, URI y código de respuesta.'
detection:
  selection_path:
    cs-uri-path|contains:
      - '/dana-admin/'
      - '/api/v1/configuration'
      - '/dana-ws/'
  selection_method:
    cs-method: 'POST'
  selection_response:
    sc-status: 200
  condition: all of selection_*
fields:
  - c-ip
  - cs-uri-path
  - cs-method
  - sc-status
  - cs-user-agent
falsepositives:
  - Escaneos de vulnerabilidades autorizados contra el propio portal
  - Accesos legítimos de administración no documentados en el allowlist de gestión
  - Integraciones de monitoreo del propio fabricante
level: high
tags:
  - attack.initial_access
  - attack.t1190
  - cve.2026.104935
Requiere: Logs HTTP del proxy/WAF/balanceador que recibe el tráfico hacia el portal Ivanti Connect Secure, con campos cs-uri-path, cs-method, sc-status y c-ip. Si el portal no tiene proxy reverso delante, exportar directamente los logs del appliance vía syslog.
sentinel-kqlSolicitudes POST a rutas administrativas de Connect Secure (CommonSecurityLog)
CommonSecurityLog
| where DeviceVendor in ("Ivanti", "Pulse Secure") or DeviceProduct has "Connect Secure"
| where RequestURL has_any ("/dana-admin/", "/api/v1/configuration", "/dana-ws/")
| where RequestMethod == "POST"
| where DeviceCustomNumber1 == 200 or AdditionalExtensions has "200"
| project TimeGenerated, SourceIP, RequestURL, RequestMethod, DestinationHostName
| sort by TimeGenerated desc
Requiere: Ingesta del WAF/proxy frente al portal Connect Secure hacia CommonSecurityLog (vía AMA o conector CEF). Si hay Defender for Endpoint en los equipos que inician sesión VPN, complementar con DeviceNetworkEvents para correlacionar IPs de origen.
splunkAccesos POST con 200 a rutas admin de Connect Secure
index=proxy OR index=waf sourcetype=*access*
| regex uri_path="(dana-admin|api/v1/configuration|dana-ws)"
| search method=POST status=200
| stats count values(uri_path) as paths by src_ip, dest
| where count > 0
| sort - count
Requiere: index=proxy (o el nombre que use la organización) con campos uri_path, method, status, src_ip, dest provenientes del reverse proxy/WAF delante del portal Connect Secure.
Falsos positivos esperables

Las tres reglas son conductuales, no firmas del exploit: Ivanti y CISA no han publicado el payload de CVE-2026-104935 a la fecha de este análisis. Van a generar ruido si el equipo de administración accede a /dana-admin/ desde una IP no documentada en el allowlist de gestión, si hay escaneos de vulnerabilidades autorizados contra el propio portal, o si el fabricante corre chequeos de salud automatizados contra esas mismas rutas. Antes de usarlas en modo de bloqueo, córranlas una semana en modo de solo alerta y construyan el allowlist de IPs de administración legítimas a partir de esos resultados.

RS ResponderContencion y erradicacion

Si hay evidencia de acceso no autorizado, el parche solo no basta: hay que tratar el appliance como potencialmente comprometido.

  • Correr el ICT y, si marca hallazgos, aislar el appliance de la red antes de parchar
  • Tomar una imagen forense del appliance antes de aplicar el parche o reconstruirlo, porque el parche puede sobrescribir evidencia
  • Rotar todas las credenciales y revocar sesiones VPN activas, incluidas las de SSO/AD usadas a través del Connect Secure
  • Notificar a ANCI si corresponde por la Ley 21.663
RC RecuperarVolver a operar y no repetirlo

La experiencia con compromisos previos de Connect Secure/Pulse Secure (2024) mostró que un parche sobre un appliance ya comprometido no siempre elimina la persistencia. La recomendación del propio fabricante en esos casos fue reconstruir desde imagen limpia.

  • Si el ICT marcó hallazgos, reconstruir el appliance desde una imagen de firmware limpia en lugar de solo parchar sobre el estado actual
  • Validar integridad post-reconstrucción con el ICT antes de volver a producción
  • Revisar si la arquitectura de acceso remoto debe seguir dependiendo de un appliance expuesto a Internet o migrar a un modelo de broker/ZTNA

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