La conclusión cabe en tres líneas. El SHA-256 legado responde a «si se llevan el hash, cada intento de adivinar sale barato». La contraseña reutilizada responde a «ni siquiera hay que adivinar». Quedarte fuera del firewall ocurre porque, después de entrar, alguien tocó la cuenta original: el algoritmo no echa el cerrojo solo. Tras subir a un FortiOS que admite PBKDF2, el hash viejo espera a que ese administrador inicie sesión con éxito, o a que un superadministrador restablezca la contraseña. Para poder bajar de versión más adelante, el SHA-256 anterior sigue por defecto en un campo oculto.
La intención de búsqueda, en una frase
Quien busca «FortiBleed», «administrador bloqueado fuera del firewall» o «contraseña guardada con SHA-256» tiene tres hechos distintos apilados en la misma noticia. El primero: el atacante toma contraseñas de filtraciones anteriores o de registros de programas que roban credenciales, y las prueba directamente contra un FortiGate SSL VPN que sigue expuesto a internet. El segundo: si el equipo aún guarda el material de contraseña de administrador que el fabricante llama SHA-256 legado, una vez copiado el hash se puede adivinar sin conexión en un clúster de GPU. El tercero: ya dentro, la otra parte crea cuentas nuevas y cambia o borra al administrador de siempre, así que la persona legítima no abre el portal.
Esto va dirigido a quien todavía administra cuentas de firewall o de VPN, y al compañero al que le pidieron «cambiar esta noche todas las contraseñas de administrador». No sustituye la página de uso del generador de contraseñas, ni convierte Comprobar contraseña en una consulta de si este equipo aparece en FortiBleed. Lo que conviene llevarse es qué fallo detiene cada capa —hash rápido, derivación lenta de clave, reutilización de contraseña, cuenta borrada— y qué dos marcas del backup de configuración se pueden mirar en el propio equipo.
Qué dice de verdad el aviso del 6 de octubre
El aviso conjunto del FBI y el Servicio Secreto de Estados Unidos del 6 de octubre de 2026 (referencia JCSA-20261006-01, marcado TLP:CLEAR) llama FortiBleed a esta operación. El objetivo son firewalls Fortinet FortiGate y puertas de enlace VPN SSL orientados a internet. El aviso cita la cifra verificada por SOCRadar: más de 86.644 equipos en 194 países. Escribe que el ataque usa contraseñas reutilizadas o ya filtradas, y un almacenamiento legado de contraseñas en SHA-256, para llevarse el material de autenticación por lotes y romperlo. El hallazgo inicial es que los atacantes siguen escaneando firewalls Fortinet expuestos a internet con contraseñas obtenidas antes.
El mismo documento describe que un directorio de su propio backend quedó expuesto, y por eso se vio la cadena de herramientas. Tras localizar portales FortiGate SSL VPN, hacen relleno de credenciales y rociado de contraseñas con volcados antiguos de Fortinet y con registros de programas que roban credenciales. Los hashes de contraseña extraídos pasan a un clúster de GPU coordinado con Hashcat y Hashtopolis para el cracking offline. El resultado se filtra, se comprueba, y luego se crea una cuenta de administrador nueva en el firewall. El aviso describe el efecto posterior como reventa del acceso inicial, y dice que esa cadena se ha observado entregada a afiliados de ransomware, con los nombres INC/Lynx y Payload. Esas frases tienen el grado de evidencia «así lo escribe el aviso». Este artículo no repite una investigación forense.
Lo que choca de frente con «cambia la contraseña y se acabó» es el apartado del bloqueo. Según la respuesta inicial, si la otra parte borra la cuenta original o le cambia la contraseña, la organización descubre que no puede entrar en el equipo Fortinet. Durante la intrusión se crean cuentas que antes no existían. En algunos casos, borrar las cuentas actuales sirve para cortar el acceso de la propia organización mientras el movimiento lateral sigue dentro del entorno. Por eso el aviso dice que la contención puede ir más allá del parche habitual y del restablecimiento de contraseñas. Ese paso se mapea a la técnica T1531 de MITRE ATT&CK (Account Access Removal, retirada del acceso a la cuenta).
Este texto no da extracción de hashes, diccionarios ni órdenes de cracking, y no copia las listas de direcciones y nombres de cuenta del aviso. Esas listas son para quien ya está revisando registros en defensa. La comprobación de abajo usa solo un equipo que tienes derecho a administrar, y la documentación pública del fabricante. No descargues un directorio abierto de origen dudoso «para verificar la noticia», y no pegues un backup de configuración con hashes de contraseña en un ticket o en una ventana de chat.
Reutilizar la contraseña y el cracking offline no son el mismo camino
El titular tiende a resumir todo en «la contraseña era débil». En el aviso hay al menos dos caminos independientes, con condiciones de fallo distintas. El relleno de credenciales y el rociado ocurren en el login en línea. La otra parte envía un texto en claro que ya conoce, o que está probando. El algoritmo con el que el equipo guarda la contraseña solo afecta a cómo compara el propio equipo. No cambia la cadena que el atacante ya tiene en la mano. Si esa cadena coincide con una cuenta de VPN o de administrador que sigue vigente, el login es válido.
El cracking offline empieza cuando el hash ya se copió fuera. La otra parte deja de golpear tu portal y enumera intentos en sus propias máquinas: convierte cada intento en hash y lo compara con el material copiado. El coste de ese paso depende de cuánto trabajo exige el esquema de almacenamiento en cada intento, y de lo grande que sea el espacio de búsqueda de la propia contraseña. SHA-256 es un hash rápido pensado para integridad: la misma entrada produce siempre la misma salida, y el cálculo termina en una pasada. Sirve para comprobar un archivo. No sirve, por sí solo, para obligar a quien adivina una contraseña a pagar un coste visible en cada intento. Un clúster de GPU alquilado hace justamente eso: paraleliza una operación que termina en una pasada. Hashtopolis, en el aviso, reparte el trabajo de cracking entre varias máquinas. No es un algoritmo de cifrado nuevo.
| Camino | Qué tiene la otra parte | Después de guardar con PBKDF2 |
|---|---|---|
| Relleno de credenciales / rociado | Texto en claro, o una lista corta de contraseñas habituales | El texto en claro sigue entrando directo; la derivación lenta no frena una contraseña ya conocida |
| Cracking offline | El hash de contraseña copiado del equipo | Cada intento sale más caro; una contraseña corta o reutilizada aún puede acertarse |
| Quedarse fuera | Una sesión de administración que ya inició sesión | Cambiar o no el algoritmo no impide que cambien o borren la cuenta original |
La tercera fila corta una lectura frecuente: escribir «pasamos a un hash más lento» como si eso significara «el administrador ya no se quedará fuera». El bloqueo ocurre después de que la autenticación ya pasó. Depende de que la otra parte pueda cambiar la configuración. No depende de lo rápido que calcule SHA-256. A la inversa, limitarse a restablecer contraseñas, sin recoger la administración expuesta a internet y sin un segundo factor resistente al phishing, solo cubre una parte de lo que lista el aviso. El FBI y el Servicio Secreto ponen en el mismo grupo de mitigaciones: restringir el acceso de administración, cerrar las sesiones de administración y de VPN ya abiertas, restablecer contraseñas, activar un segundo factor resistente al phishing, revisar cuentas desconocidas y confirmar PBKDF2.
Qué demuestra SHA-256 y qué demuestra PBKDF2
La Password Storage Cheat Sheet de OWASP saca el almacenamiento de contraseñas del modelo «calcular un hash rápido una sola vez». Pide una derivación lenta de clave con una sal única: Argon2id, bcrypt, scrypt, o PBKDF2 con iteraciones suficientes. La sal impide que una tabla calculada de antemano sirva de una persona a la siguiente. Las iteraciones, o un parámetro que encarezca la memoria, hacen que cada intento repita mucho trabajo. Responden a preguntas distintas. Con sal, y aun así un solo SHA-256, las tablas arcoíris dejan de servir, y la fuerza bruta de una GPU contra una contraseña corta sigue siendo barata. Con lentitud, pero la misma sal para todo el mundo, un lote grande de hashes sigue cubierto por una sola tabla. El aviso no describe el esquema antiguo de Fortinet como «sin sal en absoluto». Este artículo tampoco rellena ese detalle. Lo que sí cabe en una frase es la comparación que el propio fabricante publicó después.
La nota técnica de Fortinet sobre el hash de la contraseña de administrador dice que, desde FortiOS 7.2.11, 7.4.8 y 7.6.1, el hash que guarda en la configuración las credenciales del administrador del firewall pasa de SHA256 a PBKDF2. En la nota, SH2 significa SHA256 y PB2 significa PBKDF2. Por debajo de esos puntos de partida, la misma nota sigue marcando la función de hash como SHA256. Las notas de versión de 7.2.11 describen el esquema nuevo como PBKDF2 con sal aleatoria, para subir la seguridad del almacenamiento de la contraseña del administrador local del sistema. Eso no es la misma frase que «la página dice que está cifrado». Aquí SHA-256 y PBKDF2 son derivaciones de un solo sentido. Ninguno envuelve la contraseña en un texto cifrado reversible con una clave simétrica. Ver SH2 no se lee como «en disco está el texto en claro». Ver PB2 no se lee como «si se filtra el texto en claro, da igual».
PBKDF2 no tiene un número de iteraciones «ya bastante lento» válido para todo el mundo. Lo que la documentación del fabricante deja público es el nombre del algoritmo, la sal, y las marcas SH2 / PB2 en la configuración. En la nota citada no hay un entero de iteraciones que se pueda copiar a un ticket. En la comprobación, «en este backup la cuenta ya es PB2» se acerca más a lo que el documento sostiene que «así que una GPU no puede romperlo». Una contraseña corta, o copiada de una filtración antigua, sigue siendo un intento de bajo coste con un número limitado de iteraciones. Una contraseña aleatoria, larga y distinta en cada cuenta, agranda el espacio de búsqueda. No apaga la interfaz de administración expuesta a internet.
La actualización no cambia el hash viejo antes del login
La frase de la nota técnica que más se pasa por alto es esta: al subir desde una versión anterior, la contraseña de administrador sigue guardada como SHA256 hasta que ese administrador concreto inicia sesión con éxito en el firmware nuevo. Para que todos los administradores locales pasen a PBKDF2, cada uno tiene que iniciar sesión al menos una vez. Quien aún no lo haya hecho, lo actualiza a mano un super_admin. Anotar el número de firmware en la orden de cambio no demuestra que la configuración ya no tenga SH2.
Aunque el campo actual de la contraseña ya sea PBKDF2, el hash viejo no desaparece solo. La nota lo escribe así: por compatibilidad hacia atrás, el SHA256 anterior permanece por defecto en el ajuste oculto old-password. La interfaz de administración, después de un login normal, no muestra ese campo. Un backup de configuración exportado por super_admin sí lo muestra. Mientras ese material viejo siga en el backup, sigue habiendo un hash que se puede atacar sin conexión. El atacante no tiene que esperar a que termines de subir el firmware para llevárselo. Si el propio archivo de backup entra en un disco en la nube, en un ticket o en un chat, es otra copia de SH2.
Borrar el SH2 de old-password es otro interruptor, no un efecto secundario de la actualización. En FortiOS 7.2.x y 7.4.x el ajuste se llama login-lockout-upon-downgrade. En documentación posterior, el otro nombre es login-lockout-upon-weaker-encryption. Al activarlo aparece un aviso de confirmación. Las notas de versión dicen que PBKDF2 está disponible desde 7.2.11, 7.4.8 y 7.6.1. Si después se baja a una versión que no admite ese hash, el administrador local no podrá entrar. Un camino como 7.2.11 hacia 7.4.7 —número de versión mayor, y aun así sin PBKDF2— también entra en ese cerrojo. Quien se autentica por LDAP, RADIUS o SAML no usa este conjunto de hashes locales, y ese bloqueo de bajada no le afecta. Las cuentas locales son el objeto de las marcas SH2 / PB2.
Por eso «activar el borrado del hash viejo» y «esta noche quizá haya que volver al firmware anterior» chocan. El día del incidente, si aún no está decidido en qué versión con PBKDF2 se queda el firmware, no abras ese cerrojo solo para quitar SH2. Conserva primero un camino para seguir entrando al equipo, y borra el material viejo cuando ya esté confirmado que no habrá marcha atrás. La recomendación del aviso —«confirmar el uso de PBKDF2 y retirar los hashes legados más débiles»— apunta a este tramo de la nota del fabricante. No es un sinónimo de cambiar la contraseña una vez en el portal.
Quedarse fuera ocurre después de un login correcto
La primera reacción al leer la noticia suele ser restablecer todas las contraseñas de administrador. Un restablecimiento invalida el texto en claro antiguo que la otra parte todavía no ha usado, y, si tú aún puedes entrar, empuja el almacenamiento de SH2 hacia PB2. No cubre el caso «ya entraron con tu cuenta y cambiaron la propia cuenta». El aviso habla de borrar la cuenta original o cambiarle la contraseña, de modo que el administrador legítimo no puede iniciar sesión, y a la vez de crear cuentas que antes no existían para conservar su propio acceso. Un fallo de autenticación en el portal VPN demuestra que el equipo ya no acepta ese juego de credenciales. No demuestra que la otra parte carezca de una cuenta nueva.
En el ticket conviene separar dos columnas. Una es contraseña y hash: si cada administrador local está ahora en SH2 o en PB2, si el backup aún tiene old-password, y si la contraseña nueva se reutiliza en el correo, en la consola cloud o en otra VPN. La otra es el inventario de cuentas: si hay administradores locales que no existían antes del aviso, si se cerraron todas las sesiones actuales, y si la interfaz de administración en internet sigue abierta a cualquier dirección. Un segundo factor resistente al phishing hace que «solo la contraseña» no baste para abrir la administración remota y la VPN. No borra una cuenta nueva que ya está escrita en la configuración, ni retira de la cola de GPU de la otra parte un hash viejo que ya se copió.
La frase del ransomware tampoco se adelanta. El aviso dice que el acceso inicial se entrega a otros. No dice que cada firewall que aún usa SHA-256 vaya a cifrarse hoy. Un equipo al que ya no se puede entrar se trata como integridad no confirmada: aislar, contrastar configuración y cuentas, y después hablar de recuperación. En un equipo al que todavía se entra, lo primero es recoger la administración expuesta a internet, cerrar sesiones, pasar a PB2 los administradores locales que siguen en SH2, y guardar la contraseña nueva aparte. En ninguno de los dos casos se escribe la misma cadena nueva en un anuncio de grupo.
Compruébalo en el equipo: marcas del backup, sin romper hashes
El número de versión, el titular de la noticia y las palabras «ya actualizado» no sustituyen la marca de hash de esta configuración. Los cuatro pasos de abajo suponen que ya eres administrador autorizado de este equipo. No abras el backup en un ordenador en el que no confíes, y no lo subas a un chat generativo «para que me diga si hay SH2».
- Compara la versión de firmware con los tres puntos de partida: 7.2.11, 7.4.8 y 7.6.1. Por debajo del punto de partida de esa rama, la nota del fabricante sigue marcando el hash del administrador local como SHA256. Una versión ya por encima del punto de partida solo dice que un login nuevo tiene ocasión de escribirse como PB2. No dice que las cuentas viejas ya terminaron el cambio.
- Exporta un backup de configuración con
super_adminy, en el propio equipo, buscaSH2,PB2yold-password. Solo si una cuenta tiene únicamentePB2y no tieneold-passwordpuedes anotar «en este backup no se ve el SHA-256 viejo». Que la interfaz no muestre el campo oculto no equivale a que el hash viejo ya se haya borrado. - Lista los administradores locales y marca las cuentas que, después de la actualización, nunca iniciaron sesión y cuya contraseña tampoco restableció un superadministrador. La nota dice que esas cuentas siguen en SHA256 hasta que ocurra el login o el restablecimiento. No mezcles en la misma conclusión las cuentas de autenticación remota con este conjunto de hashes locales.
- Si te planteas activar
login-lockout-upon-downgrade(ologin-lockout-upon-weaker-encryptionen la documentación), lee antes el aviso de bloqueo por bajada de las notas de versión, y confirma que a corto plazo no volverás a una versión sin PBKDF2. Después de activarlo, un administrador local que ya solo tiene PBKDF2 no podrá entrar en esa marcha atrás.
Esos cuatro pasos responden a «cómo guarda ahora esta configuración la contraseña de administrador». No responden a «si en la cola de GPU de la otra parte hay una copia anterior». Cuando el hash sale del equipo, cambiar el almacenamiento en local no anula la copia que ya se llevó. Lo que anula esa copia es cambiar la propia contraseña, y confirmar que el material de la contraseña nueva ya no queda como SH2 dentro de old-password. Si la administración en internet está cerrada se mira en la política de interfaces, no en el prefijo del hash.
Cuatro lecturas que se pasan del aviso
La primera lee «el firmware ya es 7.2.11 o superior» como «SHA-256 ya no está en la configuración». La nota ata la conversión al login correcto de ese administrador, o al restablecimiento de la contraseña, y deja el hash viejo por defecto en un campo oculto. El número de versión es un punto de partida. No es una marca de trabajo terminado.
La segunda lee PBKDF2 como «la contraseña reutilizada dejó de valer». La derivación lenta sube el precio unitario de la adivinación offline. Un texto en claro que ya se obtuvo en otro sitio, en una filtración antigua o en un registro de robo de credenciales, se envía igual en el login. Usar una contraseña distinta en cada sitio frena ese camino. No sustituye recoger la interfaz de administración.
La tercera lee «yo cambié la contraseña» como «el bloqueo no va a ocurrir», o como «si ya estoy fuera, el mismo restablecimiento me abre». Cambiar la contraseña exige que todavía puedas enviar ese cambio. Si la otra parte ya borró la cuenta o sustituyó la contraseña, el fallo del portal solo dice que las credenciales viejas no se aceptan. La contraseña nueva tampoco borra sola al administrador que la otra parte acaba de crear.
La cuarta lee «esta cadena no salió en la lista local de contraseñas débiles» como «no está en la cola de hashes de FortiBleed» o como «este firewall ya usa PBKDF2». El contraste con la lista ocurre en la pestaña del navegador. La marca de hash del equipo está en el backup de configuración. Una evidencia no sella a la otra. Una ausencia en la lista puede ser una contraseña larga que aun así se reutiliza. Una coincidencia solo dice que es demasiado habitual, y no demuestra por sí sola que este FortiGate haya sido invadido.
Preguntas frecuentes
Después de actualizar a FortiOS 7.2.11, ¿el SHA-256 desaparece al instante?
No. La nota del fabricante dice que, desde 7.2.11, 7.4.8 y 7.6.1, la contraseña del administrador local pasa a PBKDF2, pero tras la actualización se mantiene como SHA256 hasta que ese administrador inicia sesión con éxito, o hasta que un super_admin restablece esa contraseña. El hash viejo sigue por defecto en el old-password oculto. El backup de configuración de super_admin lo muestra. La interfaz de administración normal no lo muestra. Borrar el hash viejo exige activar aparte una política del tipo bloqueo por bajada, y aceptar que, al bajar a una versión sin PBKDF2, el administrador local no podrá entrar.
Después de pasar a PBKDF2, ¿sigue sirviendo un texto en claro que ya robaron?
Sí. PBKDF2 encarece el coste de «solo tengo el hash y tengo que adivinar intento a intento». Si la otra parte ya tiene el texto en claro, sacado de una filtración antigua o de un registro local de robo de credenciales, lo envía tal cual en el login y no necesita romper el hash. Reutilizar la misma cadena entre el correo, la VPN y la cuenta de administrador no se vuelve falsa porque la derivación sea lenta.
Si ya te dejaron fuera, ¿cambiar otra vez la contraseña sirve?
Ese cambio en el portal exige que todavía puedas iniciar sesión. El aviso dice que la otra parte puede borrar la cuenta original o cambiarle la contraseña, de modo que el administrador legítimo no entra, y a la vez crear cuentas que antes no existían. Eso se trata como «no puedo entrar al equipo»: aislar y contrastar la configuración. No se lee como «con otro restablecimiento de contraseña se termina». Cambiar la contraseña tampoco sustituye un hash viejo que el firmware aún no convirtió, o que sigue en old-password.
¿Una lista local de contraseñas débiles demuestra que el hash de este firewall no se rompió?
No. La lista local solo responde si esa cadena coincide, en la pestaña actual, con la lista pública de alta frecuencia y unas pocas variantes. No consulta FortiBleed ni lee la configuración del firewall. Una ausencia no demuestra que la contraseña nunca se filtró, y menos aún que el hash del equipo ya sea PBKDF2. Una coincidencia solo dice que la cadena es demasiado habitual: hay que cambiarla, y no seguir reutilizándola.
Deja la contraseña nueva en este equipo, no en un anuncio de grupo
Cuando el almacenamiento pasa de SH2 a PB2, sigues necesitando una contraseña de administrador que no hayas usado en ningún otro sitio. Ese paso se puede hacer en la pestaña actual con el generador de contraseñas de FastPwd. No hace falta registrarse, y en el sitio no hay almacén de contraseñas. El modo aleatorio usa crypto.getRandomValues, con longitud de 6 a 128 caracteres, 16 por defecto. Por debajo de 8 avisa de que la seguridad es menor. El resultado no se sube. No inicia sesión en tu firewall, no cambia SH2 por PB2 y no cierra la interfaz de administración en internet. Lo que entrega es una cadena que no tienes que inventar a partir de «admin», el nombre de la empresa o la estación del año, para sustituir la cuenta local a la que todavía puedes entrar.
Abre Network en las herramientas para desarrolladores, marca conservar el registro, y busca la cadena nueva entera en las líneas y en los cuerpos de petición. No debería aparecer en las peticiones de la página. Eso demuestra que esta vez no salió de la pestaña como cuerpo HTTP. No demuestra que después la pegaste en un chat. Si el navegador pregunta si guarda la contraseña, elige no guardarla. La lista de contraseñas ya guardadas en el navegador es otra puerta, ajena al PB2 de FortiOS. Una contraseña aleatoria de 16 caracteres, sacada de mayúsculas, minúsculas, dígitos y símbolos, tiene un espacio de búsqueda mucho mayor que las palabras cortas del rociado. Esa frase no se escribe como «por tanto SHA-256 es imposible de calcular» ni como «por tanto la interfaz de administración puede seguir abierta a internet».
Si además quieres ver si una cadena se parece a una contraseña débil de la lista pública de alta frecuencia, usa otra cadena de prueba que puedas tirar, y contrástala en Comprobar contraseña. La contraseña que se comprueba no se sube. El contraste es la lista pública que baja con la página. No es Have I Been Pwned, ni la biblioteca de hashes de FortiBleed. Una ausencia no demuestra que nadie en la web la haya visto. No pegues en el cuadro de comprobación la contraseña de firewall que estás a punto de activar, ni lleves allí el backup de configuración.
Si la contraseña nueva tiene que llegar una sola vez a otro compañero de guardia, no la escribas en un mensaje de grupo o en el cuerpo de un ticket que se queda en un servidor. Pásala por Burn-Link: el servidor solo guarda texto cifrado de forma temporal, la clave va detrás de la almohadilla del enlace, y crear y leer no piden cuenta. La forma del enlace es s.html?id={id}#{key}. Ese canal responde a «cómo entregarla una vez». No responde a «cómo reparar el firewall». Si el backup de configuración contiene SH2 u old-password, no metas el archivo entero en un enlace de un solo uso ni en un disco en la nube. El backup se queda en una máquina en la que ya confías, y se trata según vuestra propia regla de custodia de configuraciones. Una captura de pantalla, o reenviar el enlace completo, deja una copia a la que «leído y borrado» no llega.
Para seguir leyendo
Una lista local de contraseñas débiles puede pillar contraseñas débiles habituales, y no sirve como cruce de toda la web ni como biblioteca de hashes de un incidente concreto: Qué puede demostrar una lista local de contraseñas débiles, y por qué no es un cruce de toda la web. Al generar una contraseña hace falta un número aleatorio criptográficamente seguro, no Math.random: Por qué una contraseña generada con Math.random puede parecer lo bastante aleatoria sin ser un número aleatorio criptográficamente seguro. Cuando una clave de un solo uso va detrás de la almohadilla del enlace, el servidor por defecto no recibe ese fragmento: Por qué el hash de una URL puede guardar una clave, y cuándo esa protección falla.