Zero-Day en Ivanti Connect Secure: parchea, investiga, reemplaza

¿Por qué esta campaña es distinta de un ciclo de parches normal? Porque los atacantes se adelantaron al fabricante y porque las redes de seguridad habituales no los detectaron.

Según el análisis de Volexity, el equipo víctima estaba completamente actualizado y aun así los atacantes obtuvieron acceso root. Hay tres detalles clave para los equipos de defensa:

• No hay malware que encontrar. Volexity no halló web shell ni puerta trasera de primera etapa. Los atacantes repetían la cadena de explotación completa cada vez que necesitaban ejecutar un comando y leían el resultado en la respuesta HTTP.
• El verificador de integridad no lo ve. La cadena opera en gran parte en memoria, y Volexity indica que la herramienta Integrity Checker de Ivanti no detecta las modificaciones. CISA también advierte que puede pasar por alto la evidencia. Un escaneo limpio no prueba que el equipo esté limpio.
• Se borró evidencia. Los atacantes eliminaron de forma selectiva entradas de los registros de depuración y auditoría y borraron sus propias cargas.

El segundo desafío es lo que buscaban. Volexity describe cómo el actor extrajo las credenciales de dominio almacenadas en el equipo, consultó Active Directory en busca de contraseñas LAPS y claves de recuperación de BitLocker, intentó Kerberoasting y password spraying, y ejecutó una herramienta de captura de paquetes renombrada para recolectar material LDAP, HTTP Basic y NTLM en texto claro. Es decir, la VPN se usó como plataforma de lanzamiento para obtener secretos que abren el resto del entorno.

Por último, el paso de escalada de privilegios no tenía CVE ni parche cuando se publicó el informe. Ivanti ha dicho que la corrección llegará en una próxima versión, de modo que parchear hoy cierra la puerta de entrada, pero no retira toda la cadena.

¿Cómo funciona la cadena de explotación de Ivanti Connect Secure? Volexity describe cuatro etapas. Primero, una solicitud manipulada a la página welcome.cgi, con un encabezado X-DSCGI-PATH alterado, omite la autenticación y llega a un manejador interno de cargas. Segundo, una condición de carrera en ese manejador permite que un script Perl cargado se ejecute antes de validar el archivo, lo que da ejecución de código como la cuenta del servicio web. Tercero, se entregan scripts por etapas que se ejecutan en memoria. Cuarto, los atacantes modifican el proceso en ejecución y abusan de una tarea programada para ejecutar código como root, y luego restauran los cambios para ocultar lo ocurrido.

¿Qué debe hacer ahora mismo? Trate esto como un incidente hasta demostrar lo contrario:

1. Parchee. Según SecurityWeek, las correcciones de Ivanti para la omisión de autenticación y la RCE están en las versiones 22.8R2.5, 25.1.1.2, 25.1.3.0 y 25.1.3.1. Confirme la ruta de actualización exacta de su rama en el aviso de Ivanti antes de programar el cambio.
2. Investigue. Busque volúmenes altos de solicitudes a welcome.cgi y solicitudes donde la ruta de la URL y el encabezado X-DSCGI-PATH no coinciden. Revise /tmp y /home/runtime/tmp en busca de scripts o archivos JSON inesperados, busque un proceso llamado dsstatmond o un directorio oculto .icscap en /data, y revise vacíos en los registros de depuración y auditoría.
3. Haga análisis forense, no solo escaneos. Si algo parece sospechoso, capture evidencia de memoria y de red. No dependa del Integrity Checker.
4. Recupere correctamente. La guía de CISA ante un posible compromiso es restablecer de fábrica y reinstalar la última versión, y reconstruir los despliegues en nube y virtuales antes de restaurar la configuración.
5. Rote todo lo que el equipo podía alcanzar. Restablezca contraseñas de dominio, administrador y cuentas locales, reemita certificados y reemplace claves API y credenciales de cuentas de servicio almacenadas. Los secretos robados siguen robados después del parche.

Planifique también el largo plazo: Volexity y otras fuentes señalan que la línea 22.8 llega al fin de su vida útil el 31 de enero de 2027, por lo que la migración a la línea 25.1 ya debería estar en su hoja de ruta.

¿Por qué las empresas deben replantear la VPN tradicional? Porque el patrón se repite: una puerta de enlace expuesta a internet con acceso profundo a la red, una falla explotada antes de que exista un parche y atacantes que pasan del borde al directorio en cuestión de horas.

Pasar del acceso VPN amplio a nivel de red hacia un acceso de red de confianza cero (ZTNA) cambia la economía del atacante. En lugar de aterrizar en una red interna plana, un usuario, o un atacante con credenciales robadas, recibe acceso a una aplicación a la vez, tras verificaciones de identidad y de dispositivo. Hay menos que robar en un solo equipo y el radio de impacto del próximo zero-day es menor. Si además se combina con una red gestionada y multioperador, se obtiene conectividad resiliente sin dejar un gran concentrador expuesto como única puerta de entrada.

Los beneficios para el negocio son concretos:

• Menor impacto de una brecha. El acceso segmentado por aplicación limita lo que puede revelar una puerta de enlace comprometida.
• Detección más rápida. El monitoreo continuo de equipos de borde y de la actividad del directorio detecta la recolección de credenciales posterior a un exploit, no solo el exploit.
• Menos trabajo de emergencia. Menos equipos expuestos significa menos maratones de parches en fin de semana y menos reconstrucciones forzadas.
• Mejor postura de auditoría. Inventario documentado, SLA de parches y procedimientos de rotación de credenciales son justo lo que piden reguladores y aseguradoras de ciberriesgo.

HIT Communications lleva más de 30 años construyendo y operando redes empresariales en Latinoamérica, Estados Unidos y Europa, y vemos la misma prioridad en todas las regiones: el acceso remoto debe ser rápido y, a la vez, defendible.

Nuestros servicios gestionados de ciberseguridad incluyen un SOC 24/7 con SIEM y detección y respuesta gestionadas (MDR), de modo que la actividad sospechosa en equipos de borde, como solicitudes de autenticación inusuales o consultas de credenciales contra Active Directory, sea investigada por analistas y no quede en un registro que nadie lee. Le ayudamos a construir los playbooks de búsqueda y respuesta a incidentes descritos arriba y apoyamos arquitecturas de confianza cero que reducen la dependencia de una única puerta de enlace VPN.

En la red, nuestras soluciones de conectividad multioperador y SD-WAN combinan internet dedicado, SD-WAN y seguridad estilo SASE para que los usuarios remotos y de sucursales lleguen a las aplicaciones por rutas controladas y redundantes. Y con nuestros servicios gestionados de TI asumimos el trabajo poco visible que evita emergencias: inventario de activos, gestión de parches con SLA claros, respaldo y planes de recuperación.

Si su equipo Ivanti estuvo expuesto entre principios de octubre y la publicación del parche, podemos ayudarle a evaluar si corresponde investigar, reconstruir y rotar credenciales, y luego diseñar un modelo de acceso remoto más difícil de vulnerar.

El zero-day de Ivanti Connect Secure demuestra que una VPN totalmente parcheada no es necesariamente una VPN segura. Los atacantes explotaron una falla desconocida, no dejaron malware, borraron registros y fueron directo por las credenciales que abren Active Directory. Las acciones inmediatas son claras: parchear, buscar los indicadores documentados, usar análisis forense y no solo el verificador de integridad, reconstruir si sospecha un compromiso y rotar todos los secretos que el equipo podía alcanzar.

La acción estratégica es reducir la cantidad de confianza que concentra un solo dispositivo expuesto a internet. Inventaríe sus equipos de borde, defina SLA de parches medidos en días, monitoréelos como servidores críticos y avance hacia el acceso por aplicación.

Si desea una visión experta de su exposición en acceso remoto, hable con el equipo de HIT Communications y le ayudaremos a convertir este aviso en un plan concreto.