FortiBleed harponne 86 644 pare-feu FortiGate sans la moindre faille à patcher

6 octobre 2026. Le FBI et le Secret Service américain publient un avis conjoint, JCSA-20261006-01, qui confirme que la campagne FortiBleed compromet toujours des pare-feu FortiGate et des passerelles VPN SSL exposés sur Internet. 6 octobre 2026. Le cabinet SOCRadar décompte plus de 86 644 équipements compromis répartis sur 194 pays. 6 octobre 2026. Fortinet rappelle qu’il ne s’agit pas d’une nouvelle vulnérabilité, mais d’un vol d’identifiants à l’échelle industrielle. Pourquoi c’est important : face à cette campagne, un RSSI ne trouvera aucun correctif à appliquer — la remédiation passe par le MFA, le hachage PBKDF2 et le retrait de l’administration du pare-feu d’Internet.

Une campagne sans exploit, mais avec une chaîne complète

Le propre de FortiBleed est de ne reposer sur aucune faille logicielle nouvelle. La chaîne d’attaque, reconstituée après que les opérateurs ont exposé par erreur leur propre serveur dorsal, ressemble à un pipeline industriel de vol d’accès : scanner les FortiGate exposés, récupérer des identifiants par credential stuffing et password spraying à partir de fuites antérieures et de journaux d’infostealers, puis exfiltrer les empreintes de mots de passe vers un cluster GPU distribué.

Ce cluster fait tourner Hashcat et Hashtopolis — la plate-forme open source qui répartit le cassage de mots de passe sur plusieurs machines — pour convertir les empreintes en clair. Le problème de fond, identifié par Fortinet, est le stockage historique des identifiants administrateur en SHA-256 sur les anciennes versions de FortiOS. Un hachage SHA-256 sans sel se casse vite sur un parc de GPU ; d’où la recommandation de l’éditeur de migrer vers les branches 7.4, 7.6 ou 8.0, qui supportent PBKDF2.

La suite de la chaîne est encore plus inquiétante que le cassage. Une fois les identifiants validés, les opérateurs créent des comptes administrateur supplémentaires sur le pare-feu, suppriment parfois les comptes d’origine pour verrouiller l’organisation hors de son propre équipement, puis énumèrent l’Active Directory et mènent du password spraying interne. Le tout se termine par la revente d’accès : les journaux retrouvés contiennent des configurations VPN et des listes de cibles classées par chiffre d’affaires — la signature d’un initial access broker qui alimente des affiliés ransomware.

La passerelle SSL VPN, ce point d’entrée qu’on oublie de durcir

Le fait que FortiBleed vise précisément les passerelles VPN SSL n’est pas un hasard. Une VPN SSL est, par construction, un service exposé sur Internet qui accepte des connexions de n’importe qui avant même d’authentifier. Elle concentre trois faiblesses exploitées ici en cascade : un périmètre exposé, une authentification par mot de passe seul, et des comptes locaux au hachage faible.

L’avis conjoint du FBI et du Secret Service recommande donc des mesures qui ne passent par aucun patch : fermer toutes les sessions admin et VPN actives, réinitialiser les mots de passe, imposer un MFA résistant au phishing sur l’administration et l’accès distant, et réduire la surface d’administration. La hiérarchie est explicite — restreindre la gestion externe par des trusted hosts (bien), une local-in policy (mieux), ou supprimer purement l’administration depuis Internet (le mieux).

C’est le point le plus dur à faire admettre en entreprise. Beaucoup d’équipes réseau administrent leurs FortiGate directement depuis l’extérieur, par commodité, sur le port de gestion HTTPS. FortiBleed transforme cette commodité en dette de sécurité : chaque interface d’administration joignable depuis Internet est une porte d’entrée qui n’attend que des identifiants valides.

Ce que les indicateurs révèlent du mode opératoire

L’avis publie une série d’indicateurs de compromission utiles en SOC. Côté infrastructure, l’adresse 45.154.12.132 a été observée comme serveur C2, 154.202.59.169 et 103.27.186.156 comme nœuds proxy, 45.155.250.158 comme relais de balises, et 85.11.187.8 comme machine Hashtopolis. Les balises sortent principalement en HTTPS, sur des ports non standards comme 4332 et 4432.

Côté comptes, les opérateurs ajoutent des utilisateurs dont les noms imitent ceux du support — forticloud, fortiuser, fortinet-support, fortinet-tech-support. Un SOC doit donc traiter toute apparition de ces noms comme un signal d’alarme, et pas seulement vérifier les adresses IP. Fortinet recommande en complément de comparer la configuration courante à une configuration de référence connue, de surveiller les journaux du contrôleur de domaine pour du mouvement latéral, et d’auditer les clés d’API REST : une clé inconnue laissée par un attaquant vaut un accès persistant.

Le hachage SHA-256, l’autre ligne de défense qu’on néglige

L’angle mort de cette campagne est le format de stockage des mots de passe lui-même. Sur les anciennes branches de FortiOS, les identifiants administrateur locaux sont conservés en SHA-256 ; c’est précisément ce que les opérateurs de FortiBleed cassent à grande échelle. Un SHA-256 sans sel se réduit à des millions de tentatives par seconde sur un cluster GPU — la distance entre « fuite d’empreinte » et « mot de passe en clair » se mesure alors en heures pour les mots de passe faibles.

La parade de fond consiste à migrer vers les branches 7.4, 7.6 ou 8.0, qui stockent les identifiants en PBKDF2 — une fonction de dérivation délibérément lente, conçue pour rendre le cassage hors de prix, même sur un parc de GPU. Fortinet documente la bascule via le paramètre login-lockout-upon-weaker-encryption, qui refuse la connexion des comptes encore stockés dans l’ancien format. C’est une migration à planifier, pas un patch à appliquer : les comptes existants doivent être réinitialisés pour être ré-enregistrés dans le nouveau format.

En pratique, un administrateur peut auditer ses comptes locaux et forcer la bascule en quelques commandes sur la console FortiGate :

# Lister les administrateurs locaux et forcer le format PBKDF2
show system admin
config system admin
    edit "admin"
        set password ENC <nouveau-mot-de-passe>
    next
end

La commande show system admin révèle aussi les comptes ajoutés par l’attaquant — souvent des noms qui imitent le support, justement. Croiser cette liste avec l’historique de configuration reste le moyen le plus fiable de repérer une intrusion passée.

Le vrai piège opérationnel, souligné par l’avis, est le verrouillage : parce que les acteurs suppriment ou changent les mots de passe des comptes d’origine, certaines victimes se retrouvent exclues de leur propre pare-feu. La remédiation dépasse alors le simple reset — il faut reconditionner l’équipement, et parfois reconstruire la confiance avec l’Active Directory si l’intégration LDAP a été détournée.

Verdict

Si vous exploitez des FortiGate exposés sur Internet, agissez sur trois fronts sans attendre : coupez l’administration distante directe (au minimum une local-in policy, idéalement plus d’administration depuis Internet), imposez un MFA résistant au phishing sur l’administration et le VPN, et migrez vers FortiOS 7.4, 7.6 ou 8.0 pour activer le hachage PBKDF2 des identifiants administrateur. Si votre pare-feu est resté en SHA-256 avec des comptes locaux faibles, traitez-le comme probablement compromis — réinitialisez tous les mots de passe, auditez les comptes, et comparez la configuration à une référence. Et si votre priorité est la détection, ajoutez les noms de comptes usurpés (forticloud, fortiuser, fortinet-support) et les adresses de l’avis à vos règles : FortiBleed ne se patche pas, il se surveille et se durcit.

Références

• FBI / USSS — FortiBleed Operations Continue Targeting Exposed Systems (JCSA-20261006-01, 6 octobre 2026)
• Fortinet PSIRT — Analysis of Reported Credential Compromise of FortiGate Devices
• SOCRadar — FortiBleed: Fortinet Firewalls Compromised
• CloudSEK — Inside the FortiBleed Open Directory
• Fortinet Community — Enforcing PBKDF2 as hash function for administrator accounts (FortiOS 7.2.11+)