El firewall de Cisco ya se usa para instalar el ransomware Qilin: el plazo de CISA venció hace 14 días

El 12 de septiembre de 2026, CISA dio a las agencias federales de Estados Unidos hasta esa fecha para parchar Cisco Secure Firewall Management Center. Hoy son 14 días después y la falla sigue bajo explotación activa por tres grupos distintos, uno de ellos el actor estatal ruso Sandworm y otro un afiliado que instala el ransomware Qilin. Si tu empresa corre un Secure FMC sin parchar, el punto no es "todavía puedo actualizar": es que hay que asumir que ya te vieron adentro y revisar qué hicieron, no sólo cerrar la puerta.

Qué falla exactamente

La vulnerabilidad central es CVE-2026-20079, con CVSS 10.0, la puntuación máxima. Está en la interfaz web de Secure FMC: un proceso del sistema mal configurado al arrancar crea una sesión que nunca se rota hasta que un usuario autenticado toca el panel, y un atacante puede combinar esa sesión estática con credenciales de máquina codificadas de fábrica para saltarse la autenticación y ejecutar comandos como root, sin necesidad de contraseña ni acceso previo. Así lo documenta el análisis técnico de Cisco Talos.

La segunda falla, CVE-2026-20316, tiene CVSS 5.3: son credenciales estáticas que dan acceso con una cuenta de bajos privilegios. Sola no es crítica, pero encadenada con la primera permite reconocimiento y escalada. Cisco confirmó explotación activa de ambas en agosto de 2026, y CISA sumó CVE-2026-20079 a su catálogo de vulnerabilidades explotadas el 9 de septiembre, con el plazo del 12 de septiembre para el gobierno federal estadounidense, según la cobertura de The Hacker News sobre la alerta de CISA.

Tres grupos, tres objetivos distintos

Talos identificó tres clústeres de actividad separados sobre el mismo par de fallas:

• Uno sin atribuir, que instala web shells en JSP y ejecutores de comandos en JAR para robar credenciales.
• Uno vinculado a Sandworm, el grupo militar ruso detrás del wiper NotPetya y de ataques previos a la red eléctrica de Ucrania, que despliega el malware modular Cyclops Blink.
• Uno ligado a un afiliado de Qilin, que usa CVE-2026-20316 para entrar con la cuenta de bajo privilegio, abusa de archivos internos del sistema para hacer reconocimiento con permisos de root, monta un proxy SOCKS5 y túneles SSH inversos que exponen LDAP, Kerberos, SMB y WinRM hacia la red interna, y de ahí usa impacket e Invoke-TheHash (herramientas abiertas de robo y reutilización de credenciales Windows) junto con inhibidores de antivirus hechos a medida antes de soltar el ransomware Qilin en los equipos seleccionados. El detalle de esa cadena está en la nota de Security Affairs sobre el despliegue de Qilin.

Que tres operaciones independientes, con objetivos distintos (espionaje, credenciales, cifrado de archivos), converjan sobre la misma falla en cuestión de semanas es lo que distingue esto de una vulnerabilidad más en la lista. Es lo mismo que se vio semanas antes con Cisco ISE tiene una falla CVSS 10.0 que decide quién entra a tu red: CISA fija el 19 de septiembre para parchar: el software de gestión de infraestructura de red se volvió el blanco preferido, precisamente porque desde ahí se controla todo lo demás.

La exposición pública

Según escaneos de internet de Censys y FOFA citados por firmas de inteligencia de amenazas, había entre 300 y 700 instancias de Secure FMC expuestas directamente a internet a mediados de septiembre de 2026, con Censys ubicando cerca de 300 y FOFA entre 600 y 700, de acuerdo con el resumen técnico publicado sobre la falla. La interfaz de administración de un firewall nunca debería estar en internet abierto, pero ese es justo el universo que los tres grupos vienen probando desde julio, según el reporte de Help Net Security sobre la explotación de ambas fallas.

Qué revisar esta semana, en orden

Parchar es el primer paso, no el último. Antes de cerrar el caso:

1. Confirma la versión de Secure FMC que corre tu equipo y si ya aplicó el parche o el hotfix de Cisco.
2. Revisa si el panel de administración de FMC alguna vez estuvo accesible desde internet, aunque hoy ya no lo esté. Un firewall reconfigurado después del ataque no borra lo que pasó antes.
3. Busca en los registros de auditoría sesiones o comandos ejecutados con privilegios de root desde direcciones IP que no reconoces, sobre todo fuera de horario de mantenimiento.
4. Busca archivos web shell (JSP, JAR) que no formen parte de la instalación estándar, y cambios recientes en archivos internos del sistema como license.tmp.
5. Revisa el tráfico saliente de la red de gestión: proxies SOCKS5, túneles SSH inversos o tráfico LDAP, Kerberos, SMB o WinRM que no debería originarse en el firewall.
6. Si algo de lo anterior aparece, no es un caso de parchado: es un incidente. Rota todas las credenciales alcanzables desde ese FMC, incluidas cuentas de dominio, y considera reconstruir el equipo desde una imagen limpia.

Esa revisión de logs y esa correlación de hallazgos contra un marco de cumplimiento es justo el tipo de trabajo que conviene automatizar antes de que vuelva a pasar: una revisión de vulnerabilidades apoyada en IA puede correlacionar indicadores de compromiso contra los registros de tu infraestructura sin depender de que alguien se acuerde de revisarlo manualmente cada semana. Es el mismo enfoque con el que se construyó, según se describe en el caso de un producto de ciberseguridad llevado de la idea a la operación, un pipeline que escanea, prioriza y propone remediaciones sin esperar al boletín del fabricante.

Dónde esto no aplica, y dónde la respuesta obvia es la equivocada

Si tu organización no opera Secure FMC on-premises (por ejemplo, usa otro producto de gestión de firewall o un servicio administrado que Cisco opera por ti), esta falla específica no te toca directamente, aunque el patrón sí: cualquier consola de administración de infraestructura crítica es blanco preferente cuando aparece una falla de autenticación crítica.

La respuesta obvia y equivocada es pensar que, si ya instalaste el parche, el tema está cerrado. El parche cierra la puerta de entrada; no revierte lo que un atacante hizo durante las semanas en que estuvo abierta. Si tu FMC estuvo expuesto a internet entre julio y septiembre de 2026, aunque hoy esté parchado, el threat hunting no es opcional: es la diferencia entre cerrar una vulnerabilidad y descubrir un ransomware ya instalado dentro de tres meses. La misma lógica aplica al asegurar la operación completa contra ransomware, no sólo el perímetro: Sin MFA, EDR y respaldos inmutables no hay póliza: lo que las aseguradoras ya exigen antes de cubrir un ciberataque repasa lo que ya piden las aseguradoras antes de emitir una póliza, precisamente porque el parche solo no basta para cobrar un siniestro.

Tampoco es un caso aislado de Cisco: el mismo mes, CISA sumó otras cinco fallas explotadas activamente en herramientas de soporte remoto y equipos de red, como se detalla en Tu proveedor de soporte remoto o tu router pueden ser la puerta de entrada: CISA suma 5 fallas explotadas en Artifactory, ScreenConnect y MikroTik. La pregunta que vale la pena hacerle a tu proveedor o a tu equipo de TI no es sólo "¿ya parcheamos?", sino "¿tenemos forma de saber si alguien entró antes de que parcháramos?". Si la respuesta es no, ese es el hueco que hay que cerrar primero.

Si eso ya existe y se quedó corto, lo tomamos, lo arreglamos y lo operamos.

Fuentes

• Active exploitation of Cisco Secure Firewall Management Center vulnerabilities, Cisco Talos
• Attackers exploit critical Cisco FMC flaw to deploy Qilin ransomware, Security Affairs
• Cisco FMC exploited: CVE-2026-20079, CVE-2026-20316, Help Net Security
• CISA flags exploited Cisco, Citrix, Fortinet flaws, sets Sept. 12 federal patch deadline, The Hacker News
• Cisco FMC bug hits CVSS 10.0, 700 boxes exposed, resumen técnico con cifras de exposición