Una sola IP impulsa la explotación de Ivanti EPMM: vulnerabilidades RCE, bots automatizados y la urgencia de parchear

Publicada 5 min de lectura 136 lecturas

Los análisis de inteligencia sobre amenazas han detectado una campaña concentrada contra Ivanti Endpoint Manager Mobile (EPMM) en la que un único actor parece estar detrás de la mayor parte de las explotaciones activas de dos fallos críticos identificados en la plataforma. Estas vulnerabilidades, catalogadas en los reportes como CVE-2026-21962 y CVE-2026-24061, permiten la inyección de código sin necesidad de autenticación y, por tanto, pueden desembocar en la ejecución remota de código (RCE) sobre sistemas expuestos, lo que las convierte en vectores extremadamente peligrosos si no se mitigan con rapidez.

La compañía de inteligencia de internet GreyNoise ha publicado un seguimiento detallado de la actividad observada entre el 1 y el 9 de febrero: durante ese periodo recogieron 417 sesiones de intento de explotación que provenían de apenas ocho direcciones IP diferentes, y donde se aprecia un patrón muy claro de automatización y foco en los fallos mencionados. Puedes leer el informe de GreyNoise aquí: http://www.greynoise.io/blog/active-ivanti-exploitation.

Una sola IP impulsa la explotación de Ivanti EPMM: vulnerabilidades RCE, bots automatizados y la urgencia de parchear
Imagen generada con IA.

Lo más llamativo del trabajo de GreyNoise es que una sola dirección IP —193[.]24[.]123[.]42, alojada en el sistema autónomo PROSPERO OOO (AS200593)— concentra más del 83% del volumen total de sesiones de explotación detectadas. Censys y otros analistas han calificado el AS como de naturaleza “bulletproof”, es decir, infraestructura tolerante a abusos, utilizada habitualmente para operaciones maliciosas que buscan evitar bloqueos o retiradas rápidas de recursos por parte de proveedores legítimos. Para contextos como este conviene consultar plataformas de búsqueda de hosts y ASN como Censys para obtener más señales sobre la infraestructura implicada.

La actividad observada muestra picos puntuales muy intensos: el 8 de febrero se registraron 269 sesiones en una sola jornada, casi trece veces más que la media diaria de alrededor de 22 sesiones que se ven en el resto del periodo analizado. Además, la campaña parece estar totalmente automatizada, con rotaciones de hasta trescientos agentes de usuario distintos para ocultar o diversificar las peticiones y dificultar la identificación por patrones sencillos.

Un dato que sugiere objetivos comerciales en el ataque es que el 85% de las sesiones (354 de las 417 registradas) emplearon callbacks DNS en estilo OAST para comprobar si el código remoto se había ejecutado correctamente. Ese comportamiento es típico de actores que buscan validar accesos iniciales y luego venderlos o reutilizarlos, lo que encaja con la actividad de brokers de acceso inicial.

En paralelo, los investigadores notan discrepancias entre indicadores de compromiso (IoC) publicados en algunos informes y la telemetría observada: por ejemplo, direcciones vinculadas a servicios VPN comerciales, como rangos de Windscribe (185[.]212[.]171[.]0/24), han aparecido en listados públicos pero en la telemetría de GreyNoise esas IPs estaban escaneando instancias de Oracle WebLogic, sin evidencia de explotación de Ivanti. Esto subraya una idea práctica para los equipos de defensa: bloquear únicamente los IoC públicos puede dejar fuera la fuente más activa de la campaña, si ésta no figura en esas listas.

Además de los intentos contra Ivanti EPMM, la misma IP atribuida al actor explotó simultáneamente otras vulnerabilidades en distintos productos —incluyendo instancias de Oracle WebLogic y GNU Inetutils Telnetd— y también se ha vinculado a la explotación de CVE-2025-24799 en GLPI, según el seguimiento. En el caso del WebLogic la mayor parte de la telemetría observada correspondió precisamente a esa plataforma, con miles de sesiones registradas, lo que muestra que un solo punto de origen puede escanear y explotar múltiples objetivos de forma paralela.

Ivanti ha publicado un aviso de seguridad con hotfixes inmediatos y recomendaciones para mitigar los fallos en EPMM; la empresa ha anunciado además que lanzará parches completos en la versión 12.8.0.0 de EPMM en el primer trimestre. Hasta que esa versión esté disponible, Ivanti aconseja aplicar versiones RPM concretas según la rama de EPMM que se esté usando y, como medida más conservadora, construir una instancia EPMM nueva y migrar los datos allí. La nota de seguridad oficial y las instrucciones del proveedor están aquí: Aviso de seguridad de Ivanti y la guía de reconstrucción está disponible aquí: Instrucciones para reconstruir EPMM.

Una sola IP impulsa la explotación de Ivanti EPMM: vulnerabilidades RCE, bots automatizados y la urgencia de parchear
Imagen generada con IA.

Para los responsables de seguridad y administradores que gestionan EPMM, la conclusión es clara: aplicar las correcciones proporcionadas por el fabricante sin demoras y, cuando sea posible, seguir la recomendación más cautelosa de migrar a una instancia reconstruida para eliminar cualquier rastro de compromiso anterior. También conviene ampliar las defensas más allá de una simple lista de IoC y monitorizar comportamientos: detección de callbacks DNS atípicos, picos de tráfico en puertos y rutas propias de la plataforma, y alertas por patrones de user-agent inusuales son señales útiles que pueden anticipar intentos de explotación automatizada.

La campaña deja otra moraleja para la comunidad: los atacantes modernos combinan automatización masiva, infraestructura tolerante a abusos y técnicas de verificación remota para maximizar el rendimiento de sus operaciones. Eso obliga a una respuesta defensiva igualmente técnica y proactiva: parcheo ágil, segmentación de servicios expuestos, y colaboración entre equipos de seguridad y proveedores para compartir telemetría real y no depender solo de IoC divulgados públicamente.

Si gestionas EPMM o infraestructura relacionada, revisa inmediatamente las recomendaciones del fabricante y las notas de inteligencia pública, y prepara un plan de respuesta que contemple reconstrucción de instancias y monitorización continua. Para profundizar en los hallazgos técnicos y los indicadores observados, revisa el análisis de GreyNoise aquí: GreyNoise — Active Ivanti exploitation, y consulta las páginas de soporte de Ivanti para aplicar las correcciones sugeridas.

Cobertura

Relacionadas

Mas noticias del mismo tema.