Cisco FMC Zero-Day: El ransomware Interlock explota una vulnerabilidad CVSS 10.0 desde enero

Durante 36 días, los atacantes pudieron obtener acceso de root no autenticado a Cisco Secure Firewall Management Center antes de que Cisco lanzara un parche. El grupo de ransomware Interlock explotó activamente la vulnerabilidad CVE-2026-20131 (CVSS 10.0) desde el 26 de enero de 2026. Amazon Threat Intelligence detectó la campaña a través de su red de honeypots MadPot. No hay solución alternativa. Quien no haya aplicado el parche es vulnerable.

Lo que ha pasado: 36 días de Zero-Day

El 26 de enero de 2026, la red de honeypot MadPot de Amazon registró los primeros intentos de ataque contra Cisco Secure Firewall Management Center (FMC). Los atacantes explotaron una vulnerabilidad hasta entonces desconocida en la interfaz de administración web: CVE-2026-20131, clasificada con la puntuación CVSS máxima de 10.0. El ataque no requiere autenticación ni interacción del usuario y otorga al atacante acceso de root al sistema afectado.

Cisco publicó el parche el 4 de marzo de 2026 – 36 días después del inicio de la explotación activa. El 18 de marzo, Cisco actualizó el advisory y confirmó oficialmente la explotación en entornos reales. El 19 de marzo, CISA añadió la vulnerabilidad al catálogo de vulnerabilidades conocidas y explotadas y estableció un plazo para parchear hasta el 22 de marzo para las agencias federales estadounidenses. No hay solución alternativa – quien esté afectado debe aplicar el parche.

Están afectadas las versiones de FMC 7.0.5 a 7.4.1.1, así como las versiones de las líneas 7.6.x, 7.7.x y 10.0.0. La versión corregida para la rama 7.4.x es 7.4.2.1. Cisco publicó parches para todas las ramas de versiones afectadas en el advisory de seguridad correspondiente. La línea de tiempo completa ilustra la gravedad de la situación:

La debilidad: deserialización insegura de Java

CVE-2026-20131 se basa en la deserialización insegura de datos no confiables (CWE-502). El vector de ataque es la interfaz de gestión web del FMC. El flujo en detalle:

El atacante envía una solicitud HTTP especialmente preparada a la interfaz web del FMC. El cuerpo de la solicitud contiene un objeto Java serializado con un flujo de bytes malicioso. El FMC deserializa el objeto sin una validación suficiente y ejecuta el código contenido como root. Para verificar el éxito, el sistema comprometido envía posteriormente una solicitud HTTP PUT a un servidor controlado por el atacante. Luego, se descarga y ejecuta un binario ELF que carga herramientas Interlock adicionales.

Esto significa: una sola solicitud HTTP es suficiente para obtener el control total sobre el sistema de gestión de firewall. Desde allí, el atacante tiene acceso a la configuración de todos los firewalls administrados, la topología de la red y potencialmente toda la red empresarial. La vulnerabilidad no requiere ningún conocimiento previo sobre el sistema objetivo: ni credenciales, ni tokens de sesión, ni interacción previa.

Especialmente crítica es la función del FMC en la arquitectura de red. El Centro de Gestión es la instancia de configuración central para todos los firewalls Cisco conectados. Quien controle el FMC, controla toda la seguridad perimetral de la empresa. Los cambios de política, ajustes de reglas y listas de acceso se pueden distribuir desde allí a todos los dispositivos administrados. Un FMC comprometido no es un problema aislado: es un incidente que afecta a toda la red.

Además de CVE-2026-20131, Cisco también abordó CVE-2026-20079 en el mismo aviso, igualmente calificado con CVSS 10.0. Ambas vulnerabilidades se corrigieron con los mismos parches. Quien considere relevante uno de los dos CVE en su entorno, debería tratar ambos como críticos.

Quién está detrás: perfil de Interlock

El grupo de ransomware Interlock ha estado activo desde septiembre de 2024 y sigue un enfoque de doble extorsión: los datos se exfiltran y se cifran. Las víctimas reciben demandas de rescate que se refieren explícitamente a las leyes de protección de datos: un encuadre de DSGVO que pretende aumentar la presión sobre las víctimas europeas. La negociación se realiza a través de un portal basado en TOR que proporciona datos de acceso individuales para cada víctima.

Ataques anteriores confirmados de Interlock incluyen al proveedor de diálisis estadounidense DaVita, la red de hospitales Kettering Health, la Universidad Texas Tech y la ciudad de Saint Paul en Minnesota. En el Reino Unido, el grupo utilizó el RAT NodeSnake contra varias universidades. El análisis de la zona horaria de las actividades de los operadores sugiere un origen en la zona UTC+3: Europa del Este o Rusia. El perfil muestra un grupo que opera profesionalmente con infraestructura dedicada, equipo de desarrollo propio y un enfoque claro en sectores críticos en países industrializados. La combinación de doble extorsión y encuadre de DSGVO hace que Interlock sea una amenaza especialmente relevante para las empresas europeas.

Interlock utiliza un amplio arsenal: scripts de PowerShell para mapeo de red y reconocimiento, RAT personalizados basados en JavaScript y Java, instancias de ConnectWise ScreenConnect abusadas para persistencia, Webshells sin archivos para anti-análisis forense y eliminación sistemática de registros después de una compromisión exitosa. El grupo también utiliza una infraestructura de proxy-relé para ocultar el origen del ataque y emplea Volatility y Certify para análisis de memoria y enumeración de Active Directory.

Varios analistas informan de que partes del malware de Interlock se desarrollaron utilizando herramientas de inteligencia artificial generativas: un desarrollo que reduce aún más el esfuerzo para crear herramientas de ataque personalizadas. El grupo se dirige principalmente a sectores con alta presión de pago: atención médica, educación, sector público e industria manufacturera. Todos estos sectores están fuertemente representados en la región DACH.

Lo que Amazon ha descubierto

Amazon Threat Intelligence descubrió la campaña a través de su sistema MadPot, una red global de honeypots que monitorea la infraestructura de los atacantes y la comunicación de comando y control. Un error de OPSEC por parte de los operadores de Interlock expuso todo el kit de herramientas del grupo: scripts de reconocimiento, RAT personalizados, mecanismos de evasión y la infraestructura de proxy-relay a través de la cual se ocultaron los ataques.

Amazon coordinó la divulgación con Cisco y publicó el 20 de marzo de 2026 un detallado artículo en el blog con indicadores de compromiso (IoC) y recomendaciones defensivas. Este artículo en el blog es actualmente la mejor fuente pública disponible para IoC concretos: hashes, direcciones IP y dominios de la infraestructura de los atacantes. Los equipos de seguridad deben incorporar inmediatamente estos IoC en sus sistemas de detección y compararlos retrospectivamente con sus datos de registro desde finales de enero. La ausencia de coincidencias no es una señal de que no haya peligro, ya que Interlock elimina activamente los registros y utiliza técnicas sin archivos que evitan la detección de firmas clásicas.

Para las empresas de la región DACH es relevante: se enviaron muestras de malware de Interlock, entre otros lugares, desde Alemania. No se puede determinar a partir de fuentes públicas si esto ocurrió en el contexto del exploit de FMC o de actividades anteriores de Interlock. El BSI no ha publicado un aviso propio sobre CVE-2026-20131 hasta la fecha de cierre de la redacción, una vulnerabilidad que llama la atención dada la difusión de Cisco FMC en las redes empresariales alemanas.

La falta de una advertencia del BSI no debe entenderse como una señal de que no haya peligro. La CISA ya ha incluido la vulnerabilidad en el catálogo KEV y ha establecido un plazo para que las agencias federales estadounidenses apliquen parches. Quien esté sujeto a NIS-2 y detecte una compromiso de FMC está obligado a presentar un informe inicial al BSI dentro de las 24 horas. Un informe detallado debe seguir dentro de las 72 horas. Dado el plazo de 36 días desde la primera explotación, los registros deben verificarse retrospectivamente hasta el 26 de enero de 2026.

Qué hacer ahora

Los siguientes ocho pasos deben realizarse en este orden. Priorización: parchear primero, análisis forense en paralelo.

1. Comprobar si se ve afectado. ¿Qué versiones de FMC están en uso? Las versiones afectadas son 7.0.5 a 7.4.1.1, así como 7.6.x, 7.7.x y 10.0.0. La tabla de versiones completa está disponible en el informe de seguridad de Cisco. La versión se puede leer en la interfaz web de FMC en «Ayuda» y «Acerca de».

2. Aplicar el parche. Actualizar a la versión 7.4.2.1 o superior. Dado que no existe una solución alternativa, esta es la única medida efectiva. Cisco ha proporcionado parches para todas las ramas de versiones afectadas.

3. Aislar la interfaz de FMC. Hasta aplicar el parche: restringir la interfaz de gestión web de FMC a una red de gestión fuera de banda dedicada. Sin exposición a Internet. Acceso solo desde estaciones de trabajo de administradores autorizados.

4. Revisar los registros. Buscar solicitudes HTTP inusuales en la interfaz web de FMC, especialmente errores de deserialización de Java en los registros de aplicaciones y tráfico no autenticado en los puertos de gestión. Las solicitudes HTTP PUT a servidores externos son un fuerte indicador de compromiso exitoso.

5. Aplicar IoCs. Cargar la lista completa de indicadores de compromiso del blog de seguridad de AWS en SIEM y EDR. Buscar retrospectivamente desde el 26 de enero de 2026. Prestar especial atención a las solicitudes HTTP PUT a servidores externos desconocidos, que es el mecanismo de exfiltración confirmado.

6. Verificar el acceso privilegiado. Si un FMC se ha visto comprometido, el atacante tuvo acceso de root al firewall de gestión. Todas las configuraciones de firewall, credenciales y certificados gestionados a través del FMC afectado deben tratarse como potencialmente comprometidos. La rotación de contraseñas y la renovación completa de certificados son obligatorias.

7. Activar el plan de respuesta a incidentes. Cualquier compromiso confirmado o sospechoso de un FMC es un incidente de gravedad 1. El atacante tuvo acceso potencial a toda la infraestructura de firewall. Esto significa: verificar todas las reglas de firewall gestionadas en busca de cambios no autorizados, validar la integridad de las configuraciones de respaldo y verificar la segmentación de la red. Quien no tenga un plan de respuesta a incidentes debe cerrar esta brecha en paralelo.

8. Verificar Cisco Security Cloud Control. Los informes sugieren que la plataforma de control de seguridad en la nube de Cisco (SCC) también podría verse afectada por la vulnerabilidad. Quien utilice SCC debe contactar directamente con el soporte de Cisco y confirmar el estado del parche.

Conclusión

CVE-2026-20131 es el exploit de Cisco más grave de los últimos meses. Puntuación máxima de CVSS, acceso de root no autenticado, 36 días de explotación activa antes del parche y sin soluciones alternativas: esta es la peor combinación que puede ofrecer un informe de seguridad.

Quien opere Cisco FMC y aún no haya aplicado el parche acepta un riesgo que no se justifica, ni técnica ni frente a la dirección, que es personalmente responsable según NIS-2. El grupo Interlock ha demostrado que explota esta brecha de manera profesional y a gran escala. La combinación de deserialización de Java, acceso de root y el papel central de FMC en la arquitectura de red hace que cualquier FMC no parcheado sea un riesgo de seguridad para toda la red. Aplicar el parche no es una recomendación, sino una obligación. Hoy.

Preguntas frecuentes

Cada pregunta está bloqueada. Un toque desbloquea la respuesta.