FortiBleed es una campaña global de compromiso de credenciales dirigida principalmente contra firewalls Fortinet FortiGate y pasarelas SSL-VPN expuestas a Internet.
No debe confundirse con una vulnerabilidad nueva, un zero-day ni un CVE concreto: el núcleo de la operación es el abuso sistemático de contraseñas reutilizadas, filtradas o débiles, la ausencia de MFA y mecanismos heredados de almacenamiento de hashes que permiten convertir accesos perimetrales en una puerta hacia la red interna.
Su gravedad no procede únicamente de la escala. La amenaza demuestra un modelo operativo industrial: los atacantes descubren dispositivos expuestos, prueban credenciales obtenidas de filtraciones anteriores e infostealers, realizan password spraying y credential stuffing, recolectan nuevos materiales de autenticación desde los equipos comprometidos, descifran hashes de manera distribuida y validan el acceso resultante.
Finalmente, conservan o venden ese acceso a otros delincuentes, incluidos afiliados de ransomware.
El FBI y el U.S. Secret Service describieron esta actividad como una campaña aún activa a comienzos de octubre de 2026, con más de 86.644 dispositivos comprometidos en 194 países, según verificaciones atribuidas a SOCRadar.
¿Qué es realmente FortiBleed?
El nombre FortiBleed fue aplicado por investigadores externos a una operación de recolección masiva de credenciales contra infraestructura Fortinet conectada a Internet.
El término puede llevar a pensar en un fallo de software semejante a Heartbleed, pero esa interpretación es incorrecta y puede llevar a una respuesta insuficiente.
Fortinet afirmó en su análisis publicado el 19 de junio de 2026 que no se trataba de una nueva vulnerabilidad del producto ni de una actividad vinculada a un incidente o aviso reciente de la compañía.
Según el fabricante, los actores reutilizaban credenciales obtenidas en incidentes anteriores y ejecutaban ataques de fuerza bruta contra dispositivos con malas prácticas de contraseñas o sin autenticación multifactor.
Sophos llegó a una conclusión compatible: FortiBleed no se entiende como un único CVE, sino como una cadena formada por superficies de administración expuestas, ataques de fuerza bruta, material de credenciales extraído de archivos de configuración de Fortinet y cracking de hashes. Sophos remarcó que no había evidencia directa de que la operación estuviera explotando CVEs recientes de Fortinet.
La distinción importa operativamente. Ante una vulnerabilidad tradicional, la primera reacción suele ser aplicar un parche. Frente a FortiBleed, actualizar FortiOS es necesario para reducir riesgos y modernizar el almacenamiento de credenciales, pero no basta: una contraseña filtrada sigue funcionando aunque el dispositivo ya esté actualizado; una cuenta administrativa creada por el atacante seguirá allí hasta que se identifique y elimine.
Por eso FortiBleed es, en esencia, una crisis de identidad en el perímetro. El firewall deja de ser solamente un control de seguridad que filtra tráfico. Cuando su panel administrativo, SSH o VPN se exponen a Internet con autenticación débil, pasa a ser un activo de máximo valor para un delincuente: controla rutas, reglas, VPN, autenticación, visibilidad de segmentos internos y, potencialmente, relaciones de confianza con Active Directory, LDAP, RADIUS o TACACS+.
Origen y evolución
La exposición pública de FortiBleed se produjo a mediados de junio de 2026, cuando el investigador Volodymyr “Bob” Diachenko identificó un servidor accesible que contenía información atribuida a los operadores.
De acuerdo con el aviso de Sophos, el servidor abierto incluía nombres de usuario, direcciones de correo y contraseñas en texto claro asociadas a organizaciones de decenas de países.
Lo excepcional no fue solo la filtración de una lista de credenciales, sino que la exposición del backend permitió reconstruir el flujo operativo del grupo. El aviso conjunto del FBI y del U.S. Secret Service explica que un directorio abierto reveló una infraestructura madura de múltiples fases: identificación de portales FortiGate SSL-VPN, recolección y validación de credenciales, cracking mediante un clúster distribuido de GPU, priorización de objetivos y expansión del acceso dentro de las redes víctimas.
Las investigaciones públicas sitúan actividad de la campaña desde febrero de 2026. The Hacker News, citando trabajo de SOCRadar y otras firmas, informó que la operación habría apuntado a más de 430.000 firewalls FortiGate en todo el mundo y que los operadores usaban un proceso repetible de descubrimiento, acceso, captura, cracking y validación.
La atribución debe expresarse con cautela. La evidencia disponible apunta a un bróker de acceso inicial de habla rusa y motivación financiera; no hay una atribución pública definitiva a un Estado o a un grupo APT concreto.
Un initial access broker, o IAB, es un actor especializado en obtener accesos iniciales a redes corporativas y venderlos a otros criminales. Este modelo fragmenta el delito: unos comprometen la entrada, otros realizan movimiento lateral, otros exfiltran datos y otros despliegan ransomware.
El FBI y el U.S. Secret Service han señalado que la cadena de FortiBleed ha servido como punto de entrada para afiliados de ransomware, en particular INC/Lynx y Payload.
Esto no significa que todos los dispositivos afectados terminen cifrados ni que cada acceso observado haya sido vendido; significa que el acceso a un FortiGate comprometido debe tratarse como una posible fase inicial de una intrusión mayor.
¿Cómo funciona el ataque?
La campaña se entiende mejor como una fábrica de accesos. Cada etapa alimenta la siguiente y aumenta el valor de los datos obtenidos.
1. Reconocimiento masivo del perímetro
Los operadores rastrean Internet en busca de FortiGate, portales SSL-VPN, interfaces administrativas y servicios SSH expuestos.
El FBI y el U.S. Secret Service asociaron esta fase con Active Scanning, técnica MITRE ATT&CK T1595, orientada a localizar superficies accesibles de FortiGate SSL-VPN.
La exposición no equivale por sí sola a compromiso, pero reduce de forma considerable el esfuerzo requerido para atacar.
Un portal visible permite al atacante automatizar pruebas de credenciales, medir respuestas, identificar banners, detectar configuraciones débiles y seleccionar objetivos potencialmente rentables.
Las investigaciones también sugieren una priorización económica. En lugar de atacar a todos los objetivos con la misma intensidad, los actores clasifican organizaciones por factores tales como tamaño, ingresos y estructura de red.
La lógica criminal es simple: una empresa pequeña puede ser fácil de comprometer, pero un proveedor de TI, una organización con acceso a múltiples clientes o una entidad de infraestructura crítica puede multiplicar el valor del acceso.
2. Reutilización de credenciales y fuerza bruta
Una vez identificados los portales, el siguiente paso combina dos técnicas:
Credential stuffing: probar automáticamente combinaciones de usuario y contraseña filtradas anteriormente.
Password spraying: probar un conjunto pequeño de contraseñas comunes o probables contra muchas cuentas, procurando evitar bloqueos por intentos repetidos sobre un único usuario.
El aviso del FBI y del U.S. Secret Service señala que los operadores utilizaron credenciales provenientes de filtraciones previas de Fortinet y registros de infostealers.
Los infostealers son programas maliciosos instalados habitualmente en endpoints de usuarios para robar contraseñas guardadas en navegadores, cookies de sesión, tokens, historiales y otros datos de autenticación.
Aquí aparece una de las lecciones centrales de FortiBleed: la contraseña de administración del firewall no debe pertenecer al mismo universo de contraseñas que empleados, proveedores, cuentas de correo o servicios SaaS. Si el administrador reutiliza una clave comprometida en otro contexto, el control perimetral puede caer sin que exista ninguna vulnerabilidad del firewall.
3. Conversión del firewall comprometido en sensor de credenciales
La parte más inquietante de la operación es el uso de una herramienta personalizada en Go denominada FortigateSniffer.
De acuerdo con la documentación pública analizada por The Hacker News, esta herramienta abusa del comando legítimo de diagnóstico de FortiOS diagnose sniffer packet para capturar pasivamente tráfico de autenticación que pasa por el dispositivo.
No se trata necesariamente de instalar un rootkit sofisticado o explotar un error de memoria.
Si el adversario ya posee privilegios administrativos sobre el firewall, puede utilizar funciones nativas de diagnóstico como si fuera un operador legítimo. Ese uso de capacidades válidas dificulta la detección porque la actividad puede parecer administrativa, especialmente en entornos sin telemetría detallada, sin auditoría de comandos y sin una línea base de cambios.
Los informes públicos atribuyen a FortigateSniffer capacidad para analizar tráfico asociado con 24 protocolos, incluidos Kerberos, SMB, LDAP, RDP, WinRM, RADIUS, TACACS+, SMTP, FTP, Telnet, MS-SQL, MySQL y PostgreSQL.
El valor para los atacantes es enorme: un firewall que ve autenticaciones internas puede producir nuevas credenciales en texto claro, hashes, tokens y artefactos de sesión.
Este es el mecanismo de retroalimentación que hace que FortiBleed sea más peligroso que un simple ataque de contraseñas.
El acceso inicial genera datos de autenticación adicionales; esos datos se transforman en nuevas credenciales; y esas credenciales permiten extender el control hacia otros sistemas y dominios.
4. Extracción y cracking distribuido
Los operadores exfiltran hashes de contraseñas, tokens de sesión y, según los hallazgos reportados, datos de configuración. Posteriormente, someten el material a cracking fuera de línea utilizando infraestructura acelerada por GPU. El aviso federal identifica Hashcat y Hashtopolis como herramientas utilizadas para distribuir y gestionar trabajos de cracking.
Hashcat es una herramienta de recuperación de contraseñas que puede probar enormes cantidades de candidatos contra hashes. Hashtopolis es una plataforma para coordinar esa carga de trabajo en múltiples agentes o GPU. Juntas permiten que un grupo criminal industrialice el cracking y procese grandes volúmenes de hashes.
El problema se agrava cuando existen hashes heredados de SHA-256. El FBI y el U.S. Secret Service subrayaron que la campaña se benefició del almacenamiento legado de contraseñas con SHA-256 y recomendaron verificar el uso de PBKDF2 para credenciales administrativas.
PBKDF2 es una función de derivación de claves diseñada para encarecer computacionalmente cada intento de adivinar una contraseña. En otras palabras, no elimina el riesgo de contraseñas débiles, pero ralentiza drásticamente el cracking masivo frente a esquemas menos resistentes.
Fortinet recomienda actualizar a versiones soportadas y aplicar la configuración necesaria para abandonar opciones heredadas de cifrado de contraseñas.
5. Validación, persistencia y movimiento lateral
Las credenciales descifradas no se usan ciegamente. Los operadores las validan, eliminan falsos positivos, filtran honeypots, asocian accesos con organizaciones y priorizan las redes más valiosas. El aviso estadounidense documenta el uso de cuentas válidas, la creación de nuevas cuentas administrativas en el firewall y la enumeración de Active Directory para localizar cuentas privilegiadas.
La creación de cuentas locales administrativas en el FortiGate es una técnica de persistencia. El atacante no necesita depender de la cuenta comprometida originalmente si puede crear otra que parezca legítima. Entre los nombres observados por el FBI y el U.S. Secret Service aparecen adminin, fortiAdmin, forticloud-sync, fgtsecure, system_config, Technical_support, support_fortinet y forti_support2. Estos nombres no son una lista completa ni deben usarse como única detección, pero merecen investigación inmediata si no pertenecen a la configuración aprobada del entorno.
El impacto puede incluir además la eliminación de cuentas legítimas o el cambio de sus contraseñas. Ese comportamiento provoca el bloqueo del equipo administrador y se asocia a MITRE ATT&CK T1531, Account Access Removal.
En este escenario, un equipo de TI puede interpretar inicialmente el incidente como una pérdida de acceso administrativa, cuando en realidad se enfrenta a un compromiso activo y persistente.
Actores, objetivos y relación con ransomware
La evidencia pública permite sostener que FortiBleed opera como una campaña de acceso inicial de motivación financiera.
Las fuentes describen a un actor o ecosistema de habla rusa, pero no permiten atribuir de forma concluyente la campaña a un grupo estatal, a una identidad única o a una organización criminal formalmente identificada.
La mejor descripción es la de una infraestructura de acceso como servicio.
El operador obtiene credenciales y rutas de VPN funcionales, mide el valor de la víctima, conserva acceso mediante cuentas nuevas o sesiones y empaqueta el resultado para terceros.
El FBI y el U.S. Secret Service encontraron indicadores de configuraciones VPN operativas y listas de objetivos que respaldan la evaluación de que el grupo abastece acceso a actores posteriores.
El vínculo con INC/Lynx y Payload ransomware eleva el riesgo estratégico. Un ransomware moderno rara vez comienza por el cifrado: normalmente pasa por acceso inicial, descubrimiento de red, robo de credenciales, escalamiento de privilegios, exfiltración, preparación de mecanismos de recuperación y, solo después, interrupción o extorsión. FortiBleed puede facilitar las primeras etapas de esa secuencia.
También hay señales de que el modelo no se limita a Fortinet. Sophos confirmó actividad oportunista contra sus firewalls expuestos, aunque aclaró que no encontró evidencia de explotación de una vulnerabilidad en sus dispositivos y que los compromisos exitosos identificados se limitaron a portales VPN o SSH expuestos sin MFA. Esto refuerza una conclusión analítica importante: FortiBleed no es únicamente un problema de una marca, sino una demostración de cómo los perímetros de red se vuelven vulnerables cuando administración remota, contraseñas reutilizadas y ausencia de MFA coinciden.
¿Cómo detectar e investigar el ataque?
Una organización con FortiGate expuesto no debe limitarse a buscar el nombre FortiBleed en feeds de inteligencia. Debe partir de la hipótesis de que una autenticación administrativa legítima puede haber sido abusada.
Las señales prioritarias incluyen:
Inicios de sesión administrativos o SSL-VPN desde IP, geolocalización, ASN, horario o agente de usuario atípicos.
Series de intentos fallidos distribuidos entre múltiples cuentas, característicos de password spraying.
Exportaciones de configuración de FortiGate hacia direcciones externas. Sophos identificó este comportamiento como una señal temprana observada en la actividad investigada.
Creación, modificación o eliminación de administradores locales, usuarios VPN, objetos de autenticación, reglas de firewall, grupos, políticas
local-in, certificados, túneles o claves API.Cuentas con nombres parecidos a servicios de Fortinet que no existían en la línea base.
Cambios de contraseña o borrado de cuentas administrativas legítimas.
Uso de SSH administrativo no esperado; el aviso federal señala que los actores pudieron aprovechar SSH cuando el puerto estaba abierto.
Creación o uso de API keys no documentadas. Las claves REST API pueden permitir cambios, automatización y generación de respaldos; una clave desconocida debe tratarse como riesgo elevado.
Anomalías de autenticación, enumeración de cuentas, validación de Kerberos o actividad SMB originada desde pools VPN.
Lectura masiva y recursiva de compartidos de red, especialmente tras un inicio de sesión VPN inusual.
Conexiones salientes inesperadas desde el firewall, incluidas transferencias por SSH o HTTPS que no se corresponden con operaciones aprobadas.
Sesiones activas antiguas, tokens conservados o cambios de configuración no explicados por un ticket de cambio.
En un SOC, la correlación es más importante que un solo evento. Una exportación de configuración puede ser legítima; un inicio de sesión desde una VPN externa también puede serlo. Pero una exportación seguida de creación de administrador, autenticación anómala contra Active Directory y exploración SMB constituye una cadena que requiere contención urgente.
Protección y respuesta: ¿qué deben hacer las organizaciones?
La defensa frente a FortiBleed exige tratar los firewalls y las VPN como activos de identidad crítica. La prioridad no es solo “parchear”, sino cortar el acceso abusado, erradicar persistencia, invalidar secretos y buscar movimiento lateral.
Acciones urgentes
Inventariar todos los activos Fortinet expuestos. Identificar FortiGate, FortiProxy, FortiWeb, SSL-VPN, SSH, interfaces administrativas, servicios API y cualquier plano de administración accesible desde Internet. La visibilidad debe incluir IP pública, versión, propietario técnico, propósito de negocio y método de autenticación.
Reducir la superficie expuesta. El FBI, el U.S. Secret Service y Fortinet recomiendan restringir la administración externa mediante trusted hosts, políticas
local-ino, preferentemente, eliminar por completo la administración desde Internet. La práctica más sólida es administrar desde una red interna controlada, un bastion host o una solución de gestión fuera de banda.Terminar todas las sesiones administrativas y VPN. Esto fuerza una reevaluación de autenticación y reduce el valor de sesiones activas o cookies robadas. No debe hacerse de manera aislada: coordínelo con operaciones, continuidad de negocio y respuesta a incidentes.
Rotar credenciales de forma amplia. Restablecer contraseñas administrativas locales, usuarios VPN, cuentas de servicio, claves API y secretos utilizados por LDAP, RADIUS, TACACS+, Active Directory, SAML u otros proveedores conectados al firewall. Sophos recalca que deben revisarse también las credenciales compartidas o reutilizadas en otros equipos perimetrales.
Aplicar MFA resistente al phishing. Debe ser obligatorio para administración, VPN y acceso remoto. Fortinet y las agencias estadounidenses recomiendan MFA para todas las cuentas administrativas y VPN; el aviso federal enfatiza MFA resistente al phishing para cuentas remotas y administrativas. En entornos de alto riesgo, FIDO2/WebAuthn o autenticadores con resistencia a phishing ofrecen una garantía superior a MFA basado exclusivamente en SMS.
Erradicación y recuperación
Si hay señales de modificación no autorizada, el dispositivo debe tratarse como comprometido. La recuperación no debe consistir únicamente en cambiar contraseñas desde el mismo firewall bajo sospecha.
El proceso debe incluir:
Preservar evidencia suficiente: backups de configuración, logs de VPN y administración, eventos de autenticación, telemetría de Active Directory, NetFlow y registros de proxy o EDR.
Aislar o poner en cuarentena los dispositivos afectados con un plan que preserve conectividad crítica cuando sea necesario.
Comparar la configuración con una línea base conocida y aprobada.
Eliminar cuentas administrativas, usuarios VPN, claves API, certificados, políticas, rutas y túneles desconocidos.
Revisar si se eliminaron cuentas legítimas o se cambiaron contraseñas.
Rotar secretos asociados a identidad integrada: AD, LDAP, RADIUS, TACACS+, SAML, cuentas de automatización y sistemas de gestión.
Investigar movimiento lateral hacia controladores de dominio, servidores de archivos, servicios Kerberos, SMB, servidores RDP y sistemas de administración.
Determinar si hubo exfiltración de configuraciones, compartidos, credenciales o archivos.
Considerar reconstrucción confiable del dispositivo a partir de firmware verificado y una configuración limpia, especialmente cuando la integridad administrativa no puede demostrarse.
Intensificar la monitorización posterior a la recuperación, porque el actor puede haber obtenido credenciales válidas antes de ser expulsado.
El FBI y el U.S. Secret Service advierten que algunos casos pueden requerir medidas más allá del parcheo estándar y del cambio simple de contraseñas, precisamente debido a creación de cuentas nuevas, eliminación de accesos legítimos y posible movimiento lateral.
Mejoras estructurales a medio plazo
Para evitar que el incidente se repita, las organizaciones deberían establecer controles duraderos:
Separar cuentas de administración de las cuentas de uso diario.
Prohibir reutilización de contraseñas mediante gestores de secretos y credenciales únicas de alta entropía.
Aplicar acceso administrativo just-in-time cuando sea viable.
Centralizar logs de FortiGate, VPN, autenticación, cambios de configuración y API en un SIEM.
Crear alertas para exportaciones de configuración, creación de administradores, cambios de
local-in policy, modificación de trusted hosts y nuevas API keys.Revisar periódicamente usuarios locales y VPN contra una lista de cuentas aprobadas.
Usar control de cambios formal para toda modificación de firewall.
Validar que FortiOS utilice PBKDF2 para credenciales administrativas y eliminar configuraciones heredadas de almacenamiento más débil, siguiendo la guía oficial de Fortinet.
Deshabilitar servicios no esenciales: SSL-VPN, SSH administrativo, API o administración web pública cuando no sean imprescindibles.
Probar el plan de respuesta ante pérdida de control del firewall, incluidos respaldos de configuración validados y acceso físico o fuera de banda.
Segmentar la red para impedir que una VPN o firewall comprometido se convierta automáticamente en acceso privilegiado a Active Directory y compartidos críticos.
Conclusión
FortiBleed demuestra que el perímetro moderno se rompe menos por una sola falla técnica espectacular que por la combinación de exposición, identidades débiles, secretos reutilizados y falta de visibilidad. La operación explotó una realidad incómoda: un firewall correctamente actualizado puede seguir siendo una vía de intrusión si sus credenciales ya circularon en filtraciones, si su administración está abierta a Internet o si un atacante puede mantener una sesión y crear su propia cuenta.
La respuesta efectiva debe ser proporcional a la función del activo comprometido. Un FortiGate no es un servidor cualquiera: puede ser el punto de tránsito de VPN, autenticación, rutas, políticas y visibilidad de una organización. Por eso, ante señales de FortiBleed, la organización debe responder como si hubiera perdido temporalmente la confianza en su perímetro y en las identidades vinculadas a él.
La prioridad defensiva es clara: retirar la administración pública, exigir MFA resistente al phishing, invalidar sesiones y secretos, eliminar persistencia, revisar actividad lateral y reconstruir desde una configuración confiable cuando sea necesario. El objetivo no es solo expulsar al actor del firewall; es impedir que un acceso de borde se transforme en una operación de ransomware dentro de toda la red.
Fuentes y referencias
Fortinet — “Analysis of Reported Credential Compromise of FortiGate Devices”
https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devicesFederal Bureau of Investigation y United States Secret Service — “FortiBleed Operations Continue Targeting Exposed Systems Leading to Reports of Lockouts”, JCSA-20261006-01
https://www.ic3.gov/CSA/2026/261006.pdfSophos — “Advisory: Fortinet ‘FortiBleed’ Credential Exposure and Sophos VPN Bruteforcing Campaign”
https://www.sophos.com/en-us/security-advisories/fortinet-fortibleed-credential-exposure-and-sophos-vpn-bruteforcing-campaignSOCRadar — “FortiBleed: The Campaign That Cracked 86,644 Firewalls”
https://socradar.io/blog/fortibleed-fortinet-firewalls-compromised/Help Net Security — “FortiBleed is still active, with attackers locking admins out of Fortinet firewalls”
https://www.helpnetsecurity.com/2026/10/07/fortinet-fortibleed-campaign-fbi-advisory/The Hacker News — “FortiBleed Targeted FortiGate Firewalls in 110 Million-Credential Harvesting Operation”
https://thehackernews.com/2026/06/fortibleed-targeted-fortigate-firewalls.htmlThe Hacker News — “FBI Warns FortiBleed Remains Active After Amassing 86,644 Fortinet Device Credentials”
https://thehackernews.com/2026/10/fbi-warns-fortibleed-remains-active.htmlFortinet Community — “Technical Tip: Enforcing PBKDF2 as hash function for administrator accounts in FortiOS v7.2.11 and later”
https://community.fortinet.com/fortigate-3/technical-tip-enforcing-pbkdf2-as-hash-function-for-administrator-accounts-in-fortios-v7-2-11-and-later-220652Fortinet Documentation — “FortiGate Best Practices: Hardening”
https://docs.fortinet.com/document/fortigate/8.0.0/best-practices/555436/hardeningCloud Security Alliance — “FortiBleed: Anatomy of a 110-Million-Credential Harvesting Operation”
https://labs.cloudsecurityalliance.org/research/csa-research-note-fortibleed-network-infrastructure-credenti/SecurityWeek — “Russian Initial Access Broker Behind FortiBleed Campaign”
https://www.securityweek.com/russian-initial-access-broker-behind-fortibleed-campaign/