Cisco FMC: parchear cierra la puerta, pero nadie te devuelve el plano de tu red

El 9 de septiembre Cisco Talos publicó que está viendo explotación real de dos fallos del Secure Firewall Management Center, el aparato desde el que muchas empresas administran todos sus cortafuegos a la vez. Hasta ahí, miércoles normal. Lo que no es normal es el recuento: tres agrupaciones de atacantes distintas, sin relación entre ellas, dentro de la misma caja. Una dejó un webshell. Otra, un actor de amenaza persistente, desplegó dos scripts para recolectar las configuraciones de los cortafuegos gestionados. La tercera acabó soltando ransomware. Y ahí está la parte que casi nadie comenta: de todo lo que se llevaron, hay una parte que el parche no arregla, porque no se puede rotar.

Lo que hay, sin adornos

Son dos fallos distintos y conviene no mezclarlos. CVE-2026-20079 es un salto de autenticación en la interfaz web del FMC, con CVSS 10.0: un atacante remoto y sin credenciales ejecuta comandos y acaba como root sobre el sistema operativo de debajo. El origen que describe Cisco es un proceso de sistema que se crea mal en el arranque. CVE-2026-20316 es otra cosa: credenciales estáticas —escritas en el propio producto— de una cuenta de bajo privilegio, con CVSS 5.3. No da root; da entrada.

Cisco ya tiene hotfixes para los dos. La versión de endurecimiento completa, que además trae otros arreglos, la anuncian para la semana del 16 de septiembre, y Talos pide expresamente que no se espere a ella: aplicar los hotfixes ahora. CISA metió el 10.0 en su catálogo de vulnerabilidades explotadas el 9 de septiembre, con fecha de corrección del 12 para las agencias federales estadounidenses. El 5,3 ya estaba: entró el 29 de julio, con plazo del 1 de agosto y marcado como usado en campañas de ransomware. Seis semanas antes de que Talos publicara nada. A ti esas fechas no te obligan; el reloj que marcan, sí. Y no hay workaround para el bypass: lo único que reduce el riesgo mientras parcheas es que la interfaz de gestión no se alcance desde internet. Que, dicho sea de paso, es donde debería llevar años.

Tres grupos, tres botines distintos

Talos separa la actividad en tres agrupaciones, y merece la pena mirarlas por separado porque cada una enseña una cosa distinta:

• UAT-12197 explotó el 10.0, dejó un webshell JSP en un directorio de Tomcat y colocó un fichero JAR malicioso para consultar las bases de datos internas del sistema comprometido y sacar de ahí datos de autenticación y credenciales.
• UAT-11823, que Talos describe como un actor de amenaza persistente, usó los dos fallos. Dejó una reverse shell con Netcat, desplegó dos scripts en bash para recolectar las configuraciones de los dispositivos gestionados y terminó instalando Cyclops Blink, un implante ELF con DNS sobre HTTPS, administración de ficheros y robo de credenciales.
• UAT-11988 entró por las credenciales estáticas —el 5,3— e hizo reconocimiento largo, enumeración de dominio y robo de credenciales antes de desplegar ransomware Qilin. Para moverse hacia dentro montó un proxy SOCKS5 en Python y un túnel SSH inverso desde el propio FMC, reenviando LDAP, LDAPS, Kerberos, SMB, NetBIOS y WinRM; en los equipos usó impacket, Invoke-TheHash y utilidades hechas a medida para apagar el antivirus. El aparato de gestión convertido en trampolín hacia el directorio activo.

La persistencia es lo que más nos gustó, precisamente por lo poco espectacular que es. El fichero license.tmp del aparato fue modificado para actuar como un paquete Makeself —un autoextraíble— que la utilidad package_info.pl ejecuta como root durante el proceso de instalación. También hay scripts colocados en /etc/init.d/. Nada exótico: un fichero con nombre aburrido, en un sitio donde nadie mira, que el propio producto ejecuta con todos los permisos porque para eso está.

De las tres cosas que se llevaron, dos se rotan y una no

Ponlas en fila. Credenciales: se rotan. Una tarde mala, un día entero si la casa es grande, pero se hace y se acabó. Un dominio cifrado: se restaura. Duele, cuesta dinero y noches, pero tiene procedimiento y tiene final. Las configuraciones de los dispositivos gestionados: no se rotan. No hay botón. No hay comando. No hay proveedor al que llamar.

Y no se rotan porque no son un secreto: son una descripción. La configuración de tus cortafuegos es el plano de tu red. Dice qué segmentos existen y cómo los llamáis internamente. Dice qué habla con qué y por qué puerto. Dice dónde están los extremos de tus VPN y con qué empresas. Dice qué publica cada regla de NAT. Y sobre todo dice tus excepciones: esa regla de «permitir cualquiera hacia este host» que alguien puso «temporalmente» en 2019 porque una aplicación vieja no tragaba nada más fino, y que sigue ahí porque quitarla da miedo.

Alguien con ese fichero delante ya no necesita escanear tu red. Y eso importa más de lo que parece, porque el escaneo es la fase ruidosa: es lo que dispara alertas, lo que deja huella en los flujos, lo que da tiempo a reaccionar. Quien llega con el plano bajo el brazo se salta justo el trozo del ataque en el que tenías alguna posibilidad de enterarte. Se presenta directamente donde está lo bueno, y parece tráfico legítimo porque va exactamente por donde tú mismo escribiste que se podía ir.

Y ese fichero no caduca cuando parcheas. El parche cierra la puerta por la que entró. La copia que ya salió sigue siendo válida mañana, en marzo y el día que cambies de proveedor de mantenimiento. Escribimos la primera mitad de esta idea cuando FortiOS dejó un symlink que sobrevivía a la actualización: parchear no es limpiar. Esto es la segunda mitad, y es peor, porque limpiar sí se puede hacer. Desaber, no.

La lista corta

Escríbela una vez y la tienes para siempre. En casi todas las empresas que hemos visto cabe en media hoja:

• Configuraciones de cortafuegos, routers y balanceadores. Y sus copias de seguridad, que suelen estar en un recurso compartido con más permisos de los que debería.
• El inventario: NetBox, o la hoja de cálculo que hace de NetBox. Es la versión legible del mismo plano.
• Diagramas de red y documentos de arquitectura, con nombres de host y direcciones dentro. Normalmente en el disco de alguien.
• Las zonas DNS internas. El mapa más barato de leer que existe: te da nombres, funciones y, con los nombres, prioridades.
• El repositorio de infraestructura como código. Ahí no está solo lo que hay: está por qué está así y qué se probó antes.
• El directorio de personas: nombres, cargos, quién depende de quién, extensiones. Es lo que hace verosímil una llamada al servicio de asistencia.

De todo eso, las contraseñas que aparezcan dentro se rotan y punto. Lo demás, no. Ahí es donde hay que decidir, y decidir cuesta más que parchear, que es exactamente la razón por la que casi nadie lo hace.

El aparato que protege tu red es aquel en el que no puedes mirar

Vuelve a los indicadores de Talos y fíjate en qué son: un JSP en un directorio de Tomcat, un license.tmp que en realidad es un instalador, scripts en /etc/init.d/. Todo eso se encuentra si tienes acceso al sistema operativo de debajo. En un appliance, normalmente, no lo tienes: tienes una consola con menú, y es así por diseño, porque el fabricante sostiene el soporte precisamente sobre que nadie toque ahí.

Esa es la incomodidad estructural de los aparatos de seguridad: son las máquinas donde no puedes instalar tu agente, así que tu detección de endpoint no llega hasta ellas. Ya contamos cómo una consola en verde puede no significar nada. Aquí es un problema distinto y en cierto modo más limpio: no es que el agente mienta, es que no hay agente. No es un fallo de nadie; es una consecuencia del modelo.

Lo que sí te queda son dos señales, y lo interesante es que ninguna de las dos vive dentro del aparato. La primera es la red: con quién habla tu consola de gestión, y la respuesta correcta es «con muy poca gente y siempre la misma». Cyclops Blink usa DNS sobre HTTPS justamente para que su tráfico se parezca a navegación normal, así que la pregunta útil no es «¿qué protocolo?» sino «¿desde cuándo esta máquina inicia conexiones salientes hacia destinos nuevos?». Eso lo ve el análisis de flujos, no el appliance. La segunda es la configuración, comparada contra una copia que no viva en el propio aparato: si tu única referencia de cómo debería estar el FMC es el FMC, no tienes referencia, tienes un espejo. Es lo mismo que dijimos cuando le tocó a la consola de gestión de otro fabricante, y lo repetimos sin cambiar una coma.

Para lo inmediato hay algo más concreto: Cisco publicó firmas de Snort: 66075 a 66080 para el 10.0, 66883 para el de credenciales estáticas y 66960-66961 para el malware. Si tienes IPS en el camino de esa interfaz de gestión, comprobar que esas firmas están cargadas y en modo bloqueo es el trabajo de diez minutos de hoy.

Sobre el 5,3

El ransomware no entró por el 10.0. Entró por el 5,3. No vamos a repetir aquí el post que ya escribimos sobre que la nota no basta para ordenar la cola de parcheo, pero sí un matiz que no dijimos entonces: en un aparato de propósito único, «cuenta de bajo privilegio» es una etiqueta prestada del mundo de los servidores de propósito general, donde efectivamente hay muchas cosas que esa cuenta no puede hacer. En un FMC no hay muchas cosas. El privilegio no se mide en qué puede ejecutar la cuenta: se mide en cuántos cortafuegos ve. Una cuenta de solo lectura en el sistema que guarda la configuración de todo tu perímetro es, exactamente, el botín del que habla este artículo.

Qué haríamos, por orden y por coste

1. Hoy: parchear y sacar la gestión de internet. Los hotfixes de los dos CVE, sin esperar a la versión de la semana del 16. Y en paralelo, comprobar si esa interfaz de administración es alcanzable desde fuera. Si lo es, ese es el hallazgo de verdad, porque no es de este mes: lleva ahí desde que se montó.
2. Esta semana, barato: rotar todo lo rotable que aparezca en esa configuración. Claves precompartidas de IPsec, comunidades SNMP, cuentas de servicio, credenciales de RADIUS y TACACS, claves de API de las integraciones, certificados del portal. Esto no depende de si crees que te tocó o no: es lo que cuesta una tarde y cierra la mitad barata del problema.
3. Este mes, coste medio: auditar las excepciones. Toda regla que existe «temporalmente» desde hace años está ahora escrita en algún sitio que no controlas. La pregunta no es si la regla es peligrosa en abstracto, que casi siempre lo es: es si sigue haciendo falta. Y eso no se adivina, se mide: pon la regla en registro un mes y mira si la toca alguien. Las que no registran nada se caen solas, y esa conversación es mucho más fácil que la del «por si acaso». Quitar las que sobran es la única acción de esta lista que cambia el plano de verdad, y además la puedes justificar sin hablar de ningún incidente.
4. Caro y lento: cambiar la topología. Renumerar un segmento, mover un extremo de VPN, rehacer la segmentación. Casi nadie lo hace. Nosotros tampoco lo recomendamos casi nunca, y decirlo en voz alta es parte del trabajo. Pero que la respuesta sea «no» por escrito y con una razón, no por olvido. «Hemos evaluado renumerar el segmento de servidores y hemos decidido que no, porque el coste es X y el beneficio no lo justifica» vale muchísimo dentro de año y medio, cuando pase cualquier cosa y alguien pregunte qué se hizo.
5. Y una que no cuesta nada: sacar la copia de la configuración del propio aparato. Un repositorio externo con historial, al que el appliance escribe pero del que no puede borrar. No es sólo para esto: es lo que convierte «creo que alguien tocó una regla» en «esta regla cambió el martes a las 3:14 y el diff es este».

Lo que no afirmamos

No sabemos cuántos FMC hay expuestos a internet y no lo estimamos: hemos visto cifras circulando estos dos días y no hemos podido contrastarlas con una fuente primaria, así que no las damos. Talos no dice que UAT-11823 sea Sandworm: dice, con alta confianza, que es un actor de amenaza persistente cuyo utillaje se solapa con el de Sandworm, y que el implante que despliega —Cyclops Blink— ya fue atribuido a Sandworm por Estados Unidos y el Reino Unido. Solapamiento de herramientas no es identidad, y buena parte de la cobertura de estos días ha saltado de lo uno a lo otro sin avisar. Aquí nos quedamos en lo que dice el informe. Tampoco sabemos si en algún caso concreto llegaron a exfiltrar configuraciones completas o parciales: lo que dice el informe es que se desplegaron scripts para recolectarlas, y la diferencia importa. Y no somos resellers de una plataforma concreta, Cisco incluida: recomendamos según el caso, no según la comisión, así que nada de lo de arriba nos cambia la factura. Si tienes FMC y tu proveedor aplicó los hotfixes el miércoles, has hecho la parte urgente y no hay nada que contratar; te faltaría la otra, la del plano, y esa no es urgente, es importante, que es peor.

Nota de fuentes

Todos los hechos de este post proceden de fuentes públicas consultadas el 11 de septiembre de 2026. La principal es la entrada del blog de Cisco Talos «Active exploitation of Cisco Secure Firewall Management Center vulnerabilities», del 9 de septiembre de 2026, de donde salen las tres agrupaciones de actividad (UAT-12197, UAT-11823 y UAT-11988) y lo que hizo cada una, la descripción de las dos vulnerabilidades y sus puntuaciones CVSS 10.0 y 5.3, el webshell JSP en el directorio de Tomcat, el fichero JAR que consulta las bases de datos internas, la reverse shell de Netcat, los dos scripts en bash para recolectar las configuraciones de los dispositivos gestionados, el implante Cyclops Blink con DNS sobre HTTPS, el ransomware Qilin, el resto del utillaje (proxy SOCKS5 en Python, túnel SSH inverso, impacket, Invoke-TheHash, apagadores de antivirus), la persistencia mediante el license.tmp convertido en paquete Makeself y ejecutado como root por package_info.pl, los scripts en /etc/init.d/, la recomendación de aplicar los hotfixes sin esperar a la versión de endurecimiento de la semana del 16 de septiembre y las firmas de Snort 66075-66080, 66883 y 66960-66961. La descripción del origen del CVE-2026-20079 como un proceso de sistema creado indebidamente en el arranque, la ausencia de workaround y la mitigación de no exponer la interfaz de gestión a internet están en el propio aviso de seguridad de Cisco (cisco-sa-onprem-fmc-authbypass-5JPp45V2); la naturaleza de credenciales estáticas del CVE-2026-20316, en la cobertura de Help Net Security (10 de septiembre de 2026). Las fechas del catálogo KEV de CISA están verificadas contra el fichero JSON primario del catálogo, versión 2026.09.10: CVE-2026-20079 con alta el 9 de septiembre y plazo del 12, y CVE-2026-20316 con alta el 29 de julio, plazo del 1 de agosto y marca de uso conocido en campañas de ransomware. La vinculación de UAT-11823 con Sandworm es del propio Talos, que declara solapamiento de utillaje —no identidad— y recuerda que Cyclops Blink fue atribuido a Sandworm por Estados Unidos y el Reino Unido; la distinción entre solapamiento e identidad es nuestra. Es lectura NUESTRA y no de las fuentes: la distinción entre lo que se rota y lo que no; que la configuración del perímetro funciona como una descripción y no como un secreto, y que por eso permite saltarse la fase ruidosa del escaneo; la lista de seis ficheros que siguen siendo válidos dentro de dos años; el argumento de que en un aparato de propósito único el privilegio se mide en cuántos dispositivos ve la cuenta; la idea de que en un appliance las dos únicas señales disponibles viven fuera del aparato; y los cinco puntos ordenados por coste, incluida la recomendación de dejar por escrito la decisión de NO cambiar la topología. No damos ninguna cifra de aparatos expuestos ni de víctimas, porque no la tenemos verificada. La fotografía de portada es «Switches and connectors unplugged», publicada en rawpixel bajo licencia Creative Commons CC0 1.0.