Una campaña bautizada como FortiBleed ha puesto en alerta a miles de organizaciones que utilizan firewalls Fortinet FortiGate y portales SSL VPN expuestos a Internet. Investigadores de seguridad han identificado una operación a gran escala centrada en credenciales: escaneo de dispositivos accesibles, reutilización de contraseñas filtradas, intentos masivos de acceso y validación de cuentas que todavía funcionan en equipos reales.
Las cifras varían según la fuente. Hudson Rock habla de 73.932 URL de firewalls comprometidos y más de 21.000 dominios afectados. SOCRadar, que mantiene el seguimiento activo, elevó el recuento a más de 86.000 dispositivos con credenciales verificadas en 194 países. Arctic Wolf sitúa el rango entre 30.000 y 75.000 dispositivos, mientras otros investigadores han advertido de que el conjunto podría representar una parte muy relevante de los Fortinet expuestos en Internet.
Fortinet, por su parte, niega que se trate de una vulnerabilidad nueva o de un incidente reciente en sus productos. La compañía sostiene que la actividad observada encaja con reutilización de credenciales procedentes de incidentes anteriores y técnicas de fuerza bruta contra dispositivos con mala higiene de contraseñas y sin autenticación multifactor. Esa diferencia de lectura no reduce la gravedad operativa: si una credencial de administrador o VPN sigue funcionando en un firewall expuesto, el perímetro ya no puede considerarse seguro.
Qué es FortiBleed y por qué preocupa
FortiBleed no debe entenderse como una única vulnerabilidad tipo CVE. Es más bien una campaña de compromiso de credenciales contra firewalls y pasarelas VPN Fortinet. Los atacantes habrían escaneado Internet en busca de dispositivos FortiGate accesibles y probado contra ellos listas de contraseñas obtenidas en filtraciones anteriores, registros de infostealers y otros conjuntos de credenciales expuestas.
Cuando una combinación funcionaba, el acceso se guardaba en una base de datos verificada. Según SOCRadar, el sistema se retroalimentaba: un dispositivo comprometido podía convertirse en punto de observación para capturar más credenciales de tráfico SSL VPN o entornos internos, que después volvían a alimentar el proceso de ataque.
| Elemento | Qué se ha observado |
|---|---|
| Nombre de la campaña | FortiBleed |
| Dispositivos objetivo | Fortinet FortiGate y pasarelas SSL VPN |
| Técnica principal | Credenciales filtradas, fuerza bruta y credential stuffing |
| Alcance reportado | Decenas de miles de dispositivos en 194 países |
| Riesgo | Acceso remoto a firewalls, VPN y redes internas |
| Vector debatido | No hay evidencia pública de una vulnerabilidad nueva |
| Respuesta de Fortinet | Lo atribuye a credenciales reutilizadas y ataques de fuerza bruta |
La diferencia entre explotar una vulnerabilidad y usar credenciales válidas es importante. En el segundo caso, muchas defensas tradicionales pueden fallar porque el inicio de sesión parece legítimo. El atacante no necesita romper el firewall si puede entrar con un usuario y una contraseña válidos.
Empresas de alto perfil en los listados
Hudson Rock publicó una interfaz donde aparecen dominios de empresas conocidas en sectores como tecnología, telecomunicaciones, logística, entretenimiento, retail, banca, fabricación y administración pública. Entre los nombres citados por distintos medios figuran Samsung, Oracle, Lenovo, Siemens, FedEx, Spotify, Huawei, Orange, Sony Pictures, Mercado Libre o Alibaba, entre otros.
Conviene matizarlo. Que un dominio aparezca en un listado de investigación no equivale necesariamente a que toda la organización esté comprometida, ni confirma por sí solo una intrusión completa en sus redes internas. Puede tratarse de un dispositivo, una filial, un portal concreto, una credencial antigua o un activo ya mitigado. Aun así, la presencia de grandes marcas ayuda a entender el alcance potencial de la campaña.
| Tipo de víctima | Riesgo principal |
|---|---|
| Grandes empresas | Acceso a redes internas y credenciales corporativas |
| Administraciones públicas | Exposición de servicios críticos o datos sensibles |
| Telecomunicaciones | Riesgo sobre infraestructura y clientes empresariales |
| Industria | Movimiento lateral hacia OT o entornos de planta |
| Servicios financieros | Acceso remoto a redes de alto valor |
| Proveedores TI | Efecto cascada sobre clientes gestionados |
| Pymes | Menos capacidad de detección y respuesta |
El firewall es una pieza especialmente sensible. No es un servidor cualquiera. Es la puerta de entrada y salida de la red, el punto donde se aplican políticas, VPN, segmentación, inspección, NAT y acceso remoto. Si un atacante controla esa capa, puede cambiar reglas, crear usuarios, observar tráfico, abrir persistencia o facilitar movimiento lateral.
El problema de las contraseñas heredadas
Uno de los puntos más relevantes del análisis técnico está en cómo se almacenaban credenciales de administrador en versiones anteriores de FortiOS. Arctic Wolf recuerda que Fortinet introdujo hashing basado en PBKDF2 para credenciales administrativas en versiones recientes como FortiOS 7.2.11, 7.4.8 y 7.6.1. El problema es que al actualizar desde versiones antiguas, las contraseñas existentes podían seguir almacenadas con mecanismos previos hasta que el administrador iniciara sesión de nuevo y se actualizara su almacenamiento.
Esto importa porque los hashes antiguos pueden ser más fáciles de atacar offline si un actor obtiene configuraciones o dumps previos. En una campaña con automatización y capacidad de cracking por GPU, incluso contraseñas aparentemente complejas pueden caer si proceden de hashes débiles o de filtraciones anteriores.
| Debilidad | Consecuencia |
|---|---|
| Contraseñas reutilizadas | Facilitan credential stuffing |
| Credenciales no rotadas tras incidentes previos | Siguen siendo válidas años después |
| Interfaces expuestas a Internet | Amplían la superficie de ataque |
| Ausencia de MFA | Una contraseña basta para entrar |
| Hashing legado | Mayor riesgo ante cracking offline |
| Falta de logs revisados | El acceso válido pasa desapercibido |
| Cuentas genéricas | Complican atribución y auditoría |
Fortinet recomienda actualizar a versiones recientes, forzar el uso de PBKDF2 y asegurarse de que los administradores vuelvan a iniciar sesión para migrar el almacenamiento de credenciales. También aconseja terminar sesiones activas, resetear contraseñas y revisar configuraciones.
Por qué no basta con cambiar una contraseña
La recomendación de rotar credenciales es urgente, pero no siempre suficiente. Si un atacante ya ha usado una cuenta válida para entrar en el dispositivo, puede haber cambiado configuración, creado usuarios, abierto reglas, añadido accesos VPN o generado persistencia. Por eso varias agencias y proveedores recomiendan investigar antes de dar por cerrado el incidente.
El NCSC británico, por ejemplo, pide revisar indicadores de compromiso, buscar creación de cuentas no autorizadas, actividad inesperada en logs y, si hay evidencias de compromiso, aislar el dispositivo y considerar un restablecimiento de fábrica. También advierte de que cambiar contraseñas puede no bastar si el actor obtuvo persistencia en el equipo.
| Acción | Motivo |
|---|---|
| Rotar credenciales admin y VPN | Cortar accesos conocidos |
| Terminar sesiones activas | Expulsar sesiones ya iniciadas |
| Revisar usuarios y configuración | Detectar cuentas o cambios maliciosos |
| Auditar logs | Buscar accesos desde IP o países inesperados |
| Aislar equipos con IoC | Evitar movimiento lateral |
| Restablecer de fábrica si hay compromiso | Eliminar persistencias en configuración |
| Actualizar FortiOS | Reducir exposición a fallos conocidos |
| Aplicar MFA | Hacer inútil la contraseña robada por sí sola |
La respuesta debe incluir también Active Directory, LDAP y otros sistemas de identidad integrados con la VPN. Si el firewall estaba conectado a un directorio corporativo y el atacante pudo observar o reutilizar credenciales, el problema ya no se limita al appliance.
Lo que deben hacer las organizaciones con Fortinet
La prioridad es inventariar todos los activos Fortinet expuestos a Internet. No basta con mirar los equipos principales del CPD. Hay que incluir sedes, filiales, appliances de laboratorios, entornos de terceros, portales antiguos y equipos olvidados. Muchos incidentes empiezan precisamente por activos que nadie revisa.
Después conviene comprobar si los dominios o direcciones aparecen en herramientas de verificación publicadas por Hudson Rock o SOCRadar. Esa comprobación no debe ser la única fuente de verdad, pero puede ayudar a priorizar. Si un activo aparece listado, debe tratarse como potencialmente comprometido.
| Paso | Recomendación práctica |
|---|---|
| 1 | Identificar todos los FortiGate, FortiFirewall y SSL VPN expuestos |
| 2 | Comprobar presencia en listas de FortiBleed |
| 3 | Terminar sesiones activas de administración y VPN |
| 4 | Rotar todas las contraseñas de administradores, VPN y cuentas de servicio |
| 5 | Activar MFA en accesos externos y administración |
| 6 | Actualizar FortiOS a versiones recomendadas |
| 7 | Restringir administración por IP, trusted hosts o VPN interna |
| 8 | Revisar logs, cuentas nuevas, cambios de reglas y accesos anómalos |
| 9 | Analizar AD/LDAP si hay integración con la VPN |
| 10 | Restablecer o reconstruir dispositivos si hay evidencias de persistencia |
Para equipos pequeños, el mensaje es simple: si la interfaz de administración de un firewall está publicada en Internet, hay que cerrarla salvo necesidad muy justificada. La administración debe limitarse a redes internas, VPN separadas, direcciones autorizadas o mecanismos de acceso fuertemente controlados.
El límite de las políticas de contraseñas complejas
FortiBleed vuelve a mostrar que las políticas tradicionales de complejidad no resuelven todo. Una contraseña larga, con símbolos y mayúsculas, deja de ser una defensa si aparece en texto plano en un registro de infostealer, si se reutilizó en otro servicio o si procede de un hash antiguo obtenido en un incidente previo.
El problema no es solo que los usuarios elijan malas contraseñas. Es que las credenciales tienen una vida demasiado larga en sistemas críticos. En muchas organizaciones, una contraseña de firewall o VPN se cambia solo cuando alguien deja el equipo, cuando hay una auditoría o cuando ocurre un incidente. Esa práctica ya no es sostenible.
| Control | Qué aporta |
|---|---|
| MFA obligatorio | Reduce impacto de contraseñas robadas |
| Rotación tras incidentes | Invalida credenciales antiguas |
| Contraseñas únicas | Evita reutilización entre servicios |
| Gestión centralizada de secretos | Mejora control y auditoría |
| Bloqueos ante fuerza bruta | Reduce intentos automatizados |
| Monitorización de infostealers | Detecta credenciales expuestas |
| Logs centralizados | Facilita investigación retrospectiva |
| Acceso por privilegio mínimo | Limita daño tras una cuenta comprometida |
La seguridad del perímetro ya no puede descansar en “contraseña fuerte” como única barrera. En un firewall expuesto, la contraseña debe ser solo una capa más.
Fortinet también intenta contener la lectura del incidente
La respuesta de Fortinet busca evitar una interpretación que asocie FortiBleed con una vulnerabilidad nueva del producto. La compañía afirma que no está relacionado con ningún incidente o advisory reciente y que las organizaciones que siguen buenas prácticas tienen riesgo mínimo. También indica que está contactando proactivamente con clientes potencialmente impactados.
Esa aclaración es relevante. Si no hay una vulnerabilidad nueva, el camino de mitigación cambia: no basta con esperar un parche milagroso. Hay que actuar sobre credenciales, exposición, MFA, versiones, configuración y registros.
Pero el hecho de que Fortinet descarte una vulnerabilidad nueva no convierte el caso en menor. Al contrario: pone el foco en una verdad incómoda para muchas empresas. El problema puede estar en la operación diaria, en contraseñas heredadas, en portales publicados, en cuentas genéricas, en actualizaciones incompletas y en falta de vigilancia sobre dispositivos de borde.
Un aviso para todos los equipos de seguridad
El caso FortiBleed no afecta solo a usuarios de Fortinet. Es un recordatorio para cualquier organización que exponga dispositivos de borde: firewalls, VPN, balanceadores, appliances de acceso remoto, portales de administración y soluciones SASE. Estos sistemas concentran credenciales, reglas de acceso y visibilidad del tráfico. Si caen, el atacante puede entrar por la puerta principal.
La tendencia no va a desaparecer. Los atacantes ya no necesitan siempre un zero-day. Muchas veces les basta con automatizar búsquedas, combinar filtraciones anteriores, usar infostealers, probar credenciales y moverse con rapidez. La escala de FortiBleed muestra lo rentable que puede ser este modelo.
Para los responsables de seguridad, la lección es clara: no hay que esperar a que el fabricante publique un CVE para actuar. Si un equipo de borde está expuesto a Internet y usa credenciales antiguas, compartidas o sin MFA, ya forma parte de la superficie real de ataque.
La pregunta no es solo si una organización aparece en una lista de FortiBleed. La pregunta es si su perímetro está diseñado para resistir el día en que una credencial válida deja de ser secreta.
Preguntas frecuentes
¿Qué es FortiBleed?
FortiBleed es el nombre usado por investigadores para describir una campaña global de compromiso de credenciales contra firewalls Fortinet FortiGate y pasarelas SSL VPN expuestas a Internet.
¿Es una vulnerabilidad nueva de Fortinet?
Fortinet afirma que no se trata de una vulnerabilidad nueva ni de un advisory reciente, sino de reutilización de credenciales de incidentes previos y fuerza bruta contra dispositivos con mala higiene de contraseñas y sin MFA.
¿Cuántos dispositivos están afectados?
Las cifras varían. Hudson Rock habla de 73.932 URL de firewalls comprometidos, SOCRadar ha elevado su recuento a más de 86.000 dispositivos y Arctic Wolf sitúa el rango entre 30.000 y 75.000.
¿Qué riesgo tiene una credencial válida de FortiGate?
Puede permitir acceso remoto al firewall o VPN, cambios de configuración, creación de usuarios, apertura de reglas, persistencia y posible movimiento lateral hacia redes internas.
¿Qué deben hacer los administradores?
Rotar credenciales de VPN y administración, terminar sesiones activas, activar MFA, actualizar FortiOS, restringir la administración desde Internet, revisar logs y validar que no haya cuentas o reglas no autorizadas.
¿Basta con cambiar la contraseña?
No siempre. Si hay indicios de compromiso, hay que revisar configuración, logs, usuarios, AD/LDAP y posible persistencia. En algunos casos puede ser necesario aislar y restablecer el dispositivo.
Fuentes:
Fortinet PSIRT
Hudson Rock
