FortiBleed: por qué bastó una contraseña filtrada para tomar el control de un FortiGate

El 6 de octubre de 2026, el FBI y el Servicio Secreto de Estados Unidos publicaron un aviso conjunto sobre FortiBleed, una campaña dirigida contra cortafuegos Fortinet FortiGate expuestos a internet y sus pasarelas VPN (aviso del FBI y el USSS). El aviso cita el recuento de SOCRadar, que habla de más de 86.644 dispositivos comprometidos en 194 países, y describe la campaña como aún en curso.

Lo llamativo es lo que los atacantes no necesitaron. El propio análisis de Fortinet es tajante: «No se trata de una nueva vulnerabilidad de Fortinet» (Fortinet PSIRT). No hizo falta ningún exploit. Los atacantes simplemente iniciaron sesión.

Cómo funcionó

El aviso reconstruye la campaña a partir del propio servidor de los atacantes, que estos dejaron expuesto. En resumen:

Localizar las páginas de inicio de sesión. Escaneos automatizados de internet en busca de portales VPN de FortiGate.
Probar contraseñas conocidas. Credential stuffing y password spraying, alimentados con volcados de filtraciones anteriores de Fortinet y registros de infostealers.
Crackear el resto. Los hashes de contraseñas sustraídos de dispositivos comprometidos se enviaban a un clúster de GPU para descifrarlos sin conexión. El débil almacenamiento heredado en SHA-256 de las contraseñas de administrador lo facilitaba.
Quedarse dentro. Se creaban nuevas cuentas de administrador en el cortafuegos. En algunos casos se eliminaban las cuentas de los propietarios o se cambiaban sus contraseñas, y las víctimas quedaban sin acceso a sus propios dispositivos.
Vender el acceso. Las configuraciones VPN operativas y las listas de objetivos se empaquetaban para otros delincuentes. El aviso señala que FortiBleed ha servido de puerta de entrada a afiliados de ransomware.

Todos los pasos anteriores a «quedarse dentro» descansan sobre una única premisa: que un nombre de usuario y una contraseña válidos bastan para iniciar sesión en la VPN o en la interfaz de administración del cortafuegos.

Qué rompe la cadena

Elimine esa premisa y las herramientas principales de la campaña dejan de funcionar. Si la VPN y la consola de administración exigen además una aprobación en el propio teléfono del usuario, una contraseña rociada, comprada o crackeada ya no equivale a un inicio de sesión. Es un intento fallido y, con una aprobación legible, también una señal: alguien acaba de usar esa contraseña, y su titular ve una solicitud que no ha iniciado.

Tanto el aviso como Fortinet sitúan la autenticación multifactor en todas las cuentas de administrador y de VPN entre sus primeras recomendaciones. Esa es la parte que cubre Notakey. Un FortiGate puede enviar los inicios de sesión de VPN y de administrador a un servidor RADIUS, y el auth-proxy de Notakey se sitúa en esa ruta RADIUS: deja que su servidor RADIUS existente compruebe la contraseña, solicita después una aprobación en el teléfono y solo responde afirmativamente cuando ambas comprobaciones tienen éxito. La configuración se detalla en nuestra guía de VPN 2FA con RADIUS.

Qué no resuelve

Preferimos ser precisos antes que venderle algo.

Un dispositivo ya comprometido. El MFA en los nuevos inicios de sesión no hace nada contra las cuentas que crearon los atacantes, las sesiones que ya tienen abiertas o la configuración que modificaron. Los pasos del propio aviso van primero: cerrar todas las sesiones administrativas y de VPN, restablecer las contraseñas, revisar usuarios y configuración frente a una copia que se sepa correcta, y almacenar las contraseñas de administrador con PBKDF2 en lugar de los hashes heredados.
Una interfaz de administración expuesta. La primera recomendación del aviso es restringir la administración desde internet: hosts de confianza (bien), una política local-in (mejor) o ninguna administración desde internet (lo ideal). Un segundo factor en una interfaz que no debería ser accesible es la solución más débil.
Páginas de phishing que retransmiten un inicio de sesión en directo. El aviso pide MFA resistente al phishing. Según la definición del Gobierno de Estados Unidos, eso significa FIDO/WebAuthn o PKI, donde la clave está vinculada al sitio real. Una aprobación en el teléfono impide que baste con una contraseña rociada o crackeada, que es en lo que se apoyaba esta campaña. Por sí sola, no detiene a un atacante que hace de proxy de un inicio de sesión real a través de una página falsa, como explicamos en nuestra entrada sobre la fatiga de MFA y los ataques de retransmisión. Para el puñado de cuentas que administran el propio cortafuegos, merece la pena considerar claves vinculadas al sitio.

Si utiliza FortiGate

Tres puntos prácticos antes de colocar cualquier aprobación en el teléfono delante de un FortiGate. Proceden de la documentación de Fortinet; no hemos probado un FortiGate en nuestro propio laboratorio, y un FortiGate se comunica con el auth-proxy mediante RADIUS estándar, como cualquier otro concentrador VPN.

Aumente los tiempos de espera de RADIUS. De forma predeterminada, FortiGate concede 5 segundos a todo el intercambio RADIUS (remoteauthtimeout) y reenvía una solicitud al cabo de 5 segundos (timeout en el servidor RADIUS) (Fortinet: cómo funcionan juntos los dos temporizadores). Basta para comprobar una contraseña, no para que una persona saque el teléfono. El auth-proxy mantiene la solicitud abierta mientras el usuario decide (30 segundos de forma predeterminada), así que ambos valores deben superar holgadamente ese margen. La nota técnica de Fortinet indica que, con valores iguales, el FortiGate sigue enviando la solicitud una segunda vez. El auth-proxy reconoce la solicitud reenviada y la ignora, de modo que el usuario no tiene que aprobar una segunda vez, pero si el tiempo de reenvío es el mayor de los dos, el intercambio se limita a una sola solicitud. Por ejemplo, 60 segundos en total y 90 antes de un reenvío (notakey-proxy representa el nombre que haya dado a la entrada del servidor RADIUS que apunta al auth-proxy):
```
config system global
    set remoteauthtimeout 60
end

config user radius
    edit "notakey-proxy"
        set timeout 90
    next
end
```
Los administradores pueden usar la misma ruta. FortiGate admite la autenticación remota de administradores contra un servidor RADIUS (Fortinet: autenticación remota para administradores), incluida una cuenta de administrador comodín para todos los miembros de un grupo RADIUS (Fortinet: configuración de cuentas de administrador comodín). Así la aprobación protege la consola que buscaban los atacantes, no solo la VPN.
Conserve una forma de volver a entrar. FortiBleed dejó a los propietarios sin acceso a sus propios dispositivos. Mantenga un administrador local de emergencia con una contraseña larga y única, accesible solo desde hosts de confianza, y pruébelo antes de necesitarlo.

Por dónde empezar

Compruebe tres cosas esta semana: si la administración de su cortafuegos es accesible desde internet, si alguna cuenta de VPN o de administrador sigue iniciando sesión solo con contraseña, y cómo se almacenan las contraseñas de administrador. Si la respuesta a la segunda pregunta es sí, ese es exactamente el hueco para el que se diseñó FortiBleed.

Pruebe la demo en vivo para aprobar un inicio de sesión desde su propio teléfono en unos dos minutos, o solicite una demostración y trazaremos sus accesos de VPN y cortafuegos hacia un piloto.