La campaña está activa ahora mismo, mientras lees este artículo.

No fue una vulnerabilidad nueva. No fue un zero-day. Lo que comprometió entre 30.000 y 75.000 firewalls FortiGate en 194 países fue algo mucho más simple: contraseñas reutilizadas, cuentas administrativas con nombres predeterminados de fábrica y hashes de autenticación SSL VPN crackeados offline. La campaña "FortiBleed" es un recordatorio directo de que un perímetro no garantiza seguridad cuando las credenciales que lo protegen ya circulan en bases de datos de infostealer. La gran mayoría de los dispositivos comprometidos permanece en línea y activa. El atacante todavía tiene acceso.

Qué ocurrió

El investigador Volodymyr Diachenko identificó un servidor operativo de un grupo de amenaza expuesto públicamente, que contenía herramientas de automatización y una base de datos de credenciales Fortinet validadas. Hudson Rock y SOCRadar analizaron los datos de forma independiente. Las cifras difieren (30.791 dispositivos frente a más de 73.000 URLs únicas), pero el diagnóstico es el mismo: escala industrial, credenciales funcionales y operación en curso.

Entre los dominios identificados figuran Foxconn, Samsung, Siemens, Oracle, PwC, Comcast, Chevron, AT&T, Toyota y cientos de entidades gubernamentales. La presencia en el conjunto de datos indica credenciales validadas para ese dominio. No es una confirmación de violación declarada por cada organización, pero tampoco es una falsa alarma.

Casos de compromiso total de red fueron documentados en Japón, Taiwán, Vietnam, Irak y Turquía. En el caso turco, la investigación apunta a un contratista del sector de defensa asociado a la OTAN, con alegaciones de exfiltración de documentos clasificados. Esa alegación específica aún espera confirmación independiente.

Cómo funciona la cadena

La operación es automatizada y autorreforzada. Cada dispositivo comprometido alimenta el ciclo con nuevas credenciales:

• Exploración de instancias FortiGate expuestas en internet (puerto 443 y variantes: 4443, 8443, 10443).

• Credential stuffing con contraseñas de filtraciones anteriores y recolecciones de infostealer.

• Captura de hashes SSL VPN para crackeo offline en un clúster de 45 GPUs mediante Hashtopolis.

• Validación automática de cada credencial antes de incluirla en la base de datos: solo entra lo que funciona.

• Movimiento lateral hacia Active Directory en compromisos más profundos.

• Uso del dispositivo comprometido como punto de escucha para capturar credenciales en tránsito y realimentar el motor de exploración.

Por qué las contraseñas complejas no ayudaron

Una parte relevante de las credenciales comprometidas incluía contraseñas de hasta 20 caracteres. La complejidad no protege una contraseña que ya fue recolectada por un infostealer y circula en texto plano en bases de datos underground.

Detalle técnico crítico: Fortinet migró al algoritmo PBKDF2 para el almacenamiento de credenciales administrativas a principios de 2025. Esa protección solo aplica a dispositivos cuyos administradores iniciaron sesión después de aplicar la actualización de firmware. Los dispositivos sin ese inicio de sesión posterior siguieron almacenando credenciales en SHA-256 con salt, mucho más vulnerable al crackeo offline. El firewall estaba actualizado. La credencial, no.

Qué hacer ahora: recomendaciones completas de mitigación

Ejecuta este checklist de inmediato. No esperes confirmación de presencia en los conjuntos de datos.

1. Rotar todas las credenciales ahora. Restablecer las contraseñas de todas las cuentas administrativas y de VPN SSL asociadas a dispositivos Fortinet. La complejidad de la contraseña anterior es irrelevante si ya fue filtrada.

2. Habilitar MFA obligatorio en todas las interfaces de gestión y acceso remoto expuestas externamente, sin excepción.

3. Auditar y renombrar cuentas predeterminadas. Las variaciones del usuario "admin" representan más de un tercio de todas las entradas en el conjunto de datos. Renombrar o desactivar todas las cuentas administrativas genéricas y cuentas de sistema nativas de Fortinet.

4. Restringir el acceso al panel de administración. Aplicar políticas local-in para limitar el acceso a la interfaz de gestión exclusivamente a IPs internas de confianza. Deshabilitar FortiCloud SSO cuando no sea estrictamente necesario.

5. Actualizar el firmware e iniciar sesión tras la actualización. La migración de credenciales a PBKDF2 solo ocurre con un inicio de sesión administrativo posterior a la aplicación del update. Sin ese inicio de sesión, un dispositivo actualizado sigue almacenando credenciales en el formato vulnerable.

6. Revisar los registros de acceso y VPN en busca de ubicaciones de inicio de sesión anómalas, sesiones administrativas inesperadas, accesos fuera de horario y volúmenes de tráfico inusuales.

7. Verificar la exposición del dominio con las dos herramientas gratuitas disponibles. Hudson Rock publicó un portal de consulta por dominio para verificación directa contra el conjunto de datos de la campaña. SOCRadar ofrece el Free Dark Web Report para análisis en dark web, registros de infostealer y bases de credenciales filtradas. Usa ambas: los conjuntos de datos tienen cobertura parcialmente distinta.

8. Involucrar al equipo de respuesta a incidentes de inmediato si el dominio de la organización es identificado en cualquiera de los conjuntos de datos. Tratar un resultado positivo como indicio de acceso no autorizado ya materializado, no como un riesgo teórico. No esperar confirmación adicional para iniciar la respuesta.

Conclusión

FortiBleed no requirió ningún descubrimiento técnico nuevo. Requirió automatización, credenciales antiguas y una lista de objetivos que cualquier escáner de puertos puede generar.

El atacante ya tiene el acceso. La pregunta es cuánto tiempo lo va a mantener.