Ivanti Connect Secure: UTA0576 roba credenciales de AD

En la primera semana de octubre de 2026, Volexity detectó a un grupo hasta ahora desconocido, al que llama UTA0576, mientras comprometía un dispositivo Ivanti Connect Secure (ICS) con la última versión disponible en ese momento, la 22.8R2.4. El grupo encadenó tres vulnerabilidades zero-day (omisión de autenticación, ejecución remota de código y escalada de privilegios) hasta obtener privilegios de root sin credenciales.

El 13 de octubre Ivanti publicó el aviso y las correcciones de las dos primeras fallas, agrupadas en la CVE-2026-104935 (CVSS v3.1 8,6). La escalada de privilegios aún no está corregida: según Help Net Security y Security Affairs llegará en una versión posterior. Ivanti habla de una explotación limitada a un número reducido de clientes. La CISA añadió la CVE a su catálogo KEV ese mismo día y pidió a las agencias federales estadounidenses actualizar y hacer un análisis forense antes del 16 de octubre. También publicaron avisos BSI/CERT-Bund (Alemania), CCB (Bélgica), INCIBE-CERT (España) y KISA/KrCERT (Corea del Sur).

Este artículo se centra en lo que hizo el grupo después del acceso, porque ahí están las huellas más útiles para quien defiende.

Cronología

• 1 de octubre: según Defused Cyber, citada por Help Net Security, primera actividad confirmada de esta campaña.
• 3 de octubre: según Security Affairs, el atacante ya estaba dentro del dispositivo del cliente de Volexity.
• 5 de octubre: Volexity empieza a investigar actividad sospechosa y la relaciona con la VPN.
• 13 de octubre: aviso y correcciones de Ivanti, inclusión en el catálogo KEV (fecha indicada por CSO Online).

Ivanti ya había encontrado «una parte» de la vulnerabilidad con su propio programa de seguridad y la había corregido en julio en la 25.1.3.0; estaba llevando la corrección a las demás ramas soportadas cuando empezaron los ataques.

Por qué el Integrity Checker no basta

Según Volexity, la cadena modifica el código solo en memoria y después restaura los datos de configuración: el Integrity Checker Tool (ICT) de Ivanti, que revisa los archivos en disco, no detecta nada. Para cada comando el grupo repetía toda la cadena y recibía los resultados en respuestas HTTPS normales, sin web shell ni puertas traseras persistentes. Los archivos temporales se eliminaban enseguida y se borraban algunas entradas de los registros de depuración de Ivanti y de auditoría de Linux. Para saber si un dispositivo ha sido comprometido hace falta, por tanto, un análisis forense, como recuerdan Volexity y la CISA.

Qué buscó en Active Directory

El dato más relevante para las empresas son los objetivos. Según el informe de Volexity, recogido por Security Affairs y Help Net Security, justo después del acceso UTA0576:

• usó una herramienta LDAP escrita en Python que se autenticaba en un controlador de dominio con la cuenta de servicio de la propia VPN;
• buscó en Active Directory las contraseñas LAPS de los administradores locales, las claves de recuperación de BitLocker y los atributos con contraseñas en claro;
• capturó el tráfico LDAP que pasaba por el dispositivo para recoger credenciales en claro, con una herramienta renombrada y oculta y ocho archivos de captura rotativos;
• realizó ataques de Kerberoasting con su propia implementación de Kerberos y campañas de password spraying contra cuentas del dominio;
• exfiltró la configuración y los resultados, comprimidos y codificados, por el mismo canal.

Volexity considera con confianza alta que el grupo preparaba movimientos laterales y un compromiso más amplio, interrumpido al ser descubierto. Sobre la motivación la confianza es baja: más probablemente criminal que de espionaje. Solo Security Affairs indica además que, según Volexity (confianza media), el grupo usa grandes modelos de lenguaje para desarrollar exploits y actividades posteriores al acceso.

En términos de MITRE ATT&CK: T1190 para el acceso inicial, T1068 para la escalada, T1070 para el borrado de huellas, T1040 para la captura de tráfico, T1558.003 (Kerberoasting), T1110.003 (password spraying) y T1041 para la exfiltración.

Versiones afectadas y corregidas

Según los avisos de INCIBE-CERT y KISA:

• 22.8R2.4 y anteriores de la rama 22.8: actualiza a la 22.8R2.5 y después, como recomienda Ivanti, pasa a la rama 25.1;
• 25.1.1.1 y anteriores: actualiza a la 25.1.1.2;
• 25.1.2.2 y anteriores: actualiza a la 25.1.3.0, a la 25.1.3.1 o posterior.

La 22.7R2.14 y anteriores no están afectadas por la CVE-2026-104935. Según CSO Online, Ivanti afirma que aún no hay indicadores de compromiso fiables y remite a los publicados por Volexity.

En el mismo boletín de octubre, resumido por INCIBE-CERT, Ivanti corrige también dos fallas críticas no explotadas: CVE-2026-106042 en Xtraction (actualiza a la 2026.4) y CVE-2026-109412 en Neurons Patch for Intune, ya corregida en la nube el 16 de septiembre; para esta última Ivanti recomienda rotar el secreto de cliente de la aplicación registrada en Microsoft Entra ID.

Impacto para las empresas europeas e italianas

La VPN es la puerta de entrada de empleados, proveedores y técnicos de mantenimiento, y su cuenta de servicio suele tener acceso de lectura a gran parte de Active Directory. La clave es que las credenciales robadas siguen siendo válidas después de actualizar: contraseñas LAPS, claves de BitLocker, cuentas con SPN y cuentas adivinadas con el spraying deben considerarse expuestas si el dispositivo fue comprometido.

Para las entidades sujetas a NIS2, la actualización forma parte de la gestión de vulnerabilidades con plazos documentados; un compromiso confirmado debe valorarse a efectos de la notificación al CSIRT nacional (en Italia, CSIRT Italia de la ACN, con alerta temprana en 24 horas para los incidentes significativos). En la sanidad, donde la VPN suele dar acceso remoto a médicos y proveedores de dispositivos, las claves de BitLocker y las contraseñas de administrador local abren el camino a los puestos clínicos.

Qué hacer ya

1. Conserva las pruebas antes de actualizar un dispositivo sospechoso: registros, copias de la configuración e imágenes del sistema (indicación de INCIBE-CERT).
2. Actualiza cada dispositivo y cada nodo de los clústeres a la versión corregida de tu rama; ejecuta el ICT, pero no tomes un resultado limpio como prueba de integridad.
3. Revisa Active Directory desde los controladores de dominio: consultas LDAP de la cuenta de servicio de la VPN a atributos LAPS, objetos de recuperación de BitLocker y atributos con contraseñas; picos de solicitudes de tickets Kerberos desde la dirección interna de la VPN; ráfagas de inicios de sesión fallidos en muchas cuentas.
4. Si hay compromiso, sigue las instrucciones de recuperación de Ivanti y rota: la contraseña de la cuenta de servicio de la VPN, las contraseñas LAPS, las claves de recuperación de BitLocker y las contraseñas de las cuentas con SPN y de las cuentas atacadas con spraying.
5. Reduce la exposición: limita los permisos de la cuenta de servicio de la VPN al mínimo imprescindible y usa conexiones LDAP cifradas, para que el tráfico que atraviesa el dispositivo no lleve credenciales en claro.
6. Sigue el aviso de Ivanti sobre la corrección de la escalada de privilegios e instálala en cuanto salga.

Cómo ayuda ARXDOME

ARX Expose muestra qué servicios expone tu empresa en internet y cuáles tienen vulnerabilidades conocidas, para que sepas enseguida si una pasarela de acceso remoto es accesible desde fuera. ARX Sentry lleva los registros de cortafuegos y dispositivos de red a un colector central, fuera del dispositivo: borrar los registros locales no elimina lo que ya se ha enviado. Las páginas SOC de identidades destacan ráfagas de intentos, accesos privilegiados y cambios en las cuentas, útiles para reconocer el password spraying y el uso de credenciales robadas.

Última actualización: 14 de octubre de 2026