La campagne FortiBleed illustre un angle mort que beaucoup d'équipes sécurité sous-estiment encore : patcher une vulnérabilité ne suffit pas si les identifiants ont déjà été volés avant la correction. Au 19 juin 2026, les données agrégées font état de 86 644 appareils Fortinet dont les hachages de mots de passe administrateur ont été craqués via un cluster GPU dédié. Ce chiffre ne concerne pas uniquement des équipements non patchés : une part significative des appareils touchés avait déjà reçu les correctifs au moment de l'extraction initiale des hachages.
Ce que FortiBleed révèle sur la surface d'attaque réelle
La mécanique de l'attaque repose sur une exploitation d'une vulnérabilité de lecture de fichier arbitraire, permettant d'exfiltrer le fichier de configuration local — et avec lui, les hachages des comptes administrateur. Une fois ces hachages en main, le craquage offline par force brute sur GPU devient une question de temps, pas de compétence. Les équipements patchés ultérieurement gardent leurs comptes compromis : le correctif ferme la porte, mais les clés sont déjà copiées.
Ce qui rend cette campagne particulièrement instructive, ce sont les données sur la nature des comptes compromis. Selon l'analyse de SOCRadar, les comptes admin génériques (du type admin, administrator, root) représentent 35 % des identifiants craqués. Les comptes système intégrés Fortinet par défaut constituent 28,3 % supplémentaires. Ensemble, ces deux catégories totalisent près des deux tiers des accès compromis. Ce n'est pas un problème de sophistication de l'attaque : c'est un problème de hygiène de configuration.
Pourquoi les comptes par défaut restent si répandus
Il serait tentant d'attribuer ce phénomène uniquement à un manque de maturité des équipes. La réalité est plus nuancée. Sur un parc d'équipements réseaux étendu — plusieurs dizaines de firewalls, parfois hérités de différentes générations de déploiement — la rotation systématique des identifiants par défaut se heurte à des contraintes opérationnelles réelles. Les comptes service intégrés Fortinet, en particulier, sont parfois conservés par des équipes qui craignent de casser une fonctionnalité ou une intégration non documentée.
À cela s'ajoute un biais cognitif fréquent chez les équipes réseau : la confusion entre compte désactivé et compte supprimé. Un compte désactivé dont le hachage figure dans la configuration reste craquable offline. La désactivation ne protège que contre l'authentification en ligne, pas contre l'extraction et le craquage différé du condensat.
La puissance du craquage GPU change les hypothèses de risque
Les anciennes règles empiriques sur la solidité des mots de passe méritent d'être réévaluées. Un cluster GPU moderne peut tester des centaines de milliards de combinaisons par seconde sur des hachages MD5 ou SHA-1. Les mots de passe courts, même non triviaux, tombent en quelques minutes. Les mots de passe de complexité intermédiaire (8 à 10 caractères, mélange alphanumérique) peuvent être craqués en heures sur des hachages faibles.
FortiOS utilise des mécanismes de hachage qui ont évolué selon les versions. Les équipements anciens ou mal configurés peuvent conserver des hachages moins résistants. Un inventaire du parc avec vérification des versions de firmware et des mécanismes de stockage des identifiants est donc un prérequis avant toute rotation.
Patch plus rotation : les deux actions non négociables
Face à FortiBleed, la réponse technique se décompose en deux axes indissociables. Le premier, appliquer le patch, est acquis pour la plupart des équipes. Le second, forcer la rotation immédiate de tous les identifiants administrateur, l'est beaucoup moins — et c'est précisément ce second axe qui conditionne l'efficacité réel du premier.
Concrètement, la rotation doit cibler en priorité les comptes correspondant aux deux catégories surreprésentées dans FortiBleed : tous les comptes portant un nom générique (même renommés mais issus du compte admin initial), et tous les comptes système Fortinet intégrés qui ne sont pas strictement nécessaires à une fonctionnalité active. Pour les comptes qui doivent subsister, un mot de passe d'au moins 16 caractères avec entropie élevée, stocké dans un gestionnaire de secrets (CyberArk, HashiCorp Vault, ou équivalent), est le minimum.
Compléter cette démarche par une authentification multifacteur sur les interfaces d'administration, même en accès VPN, élimine la grande majorité des scénarios d'exploitation post-craquage. Un attaquant qui dispose du mot de passe en clair mais se heurte à un second facteur reste bloqué à l'entrée.
Les équipes qui souhaitent évaluer leur exposition réelle sur ce type de scénario peuvent s'appuyer sur des environnements de simulation, comme ceux proposés dans le catalogue de labs FortiBleed et scénarios d'attaque réseau de CyberAct, pour rejouer l'attaque en conditions contrôlées et valider leurs contre-mesures.
Ce que les RSSI doivent retenir pour leur gouvernance
FortiBleed n'est pas un incident isolé : c'est la confirmation d'un schéma récurrent. Les vulnérabilités de lecture de fichier arbitraire sur les équipements périmètre (Fortinet, mais aussi d'autres constructeurs) ont alimenté plusieurs campagnes similaires ces dernières années. À chaque fois, la fenêtre d'exploitation entre la divulgation publique et le déploiement des patches chez les clients a suffi pour exfiltrer des configurations en masse.
La leçon de gouvernance est claire : la politique de gestion des identifiants sur les équipements réseau doit intégrer un scénario de compromission silencieuse. Cela signifie définir une procédure de rotation d'urgence activable en moins de 24 heures, maintenir un inventaire précis des comptes existants sur chaque équipement, et tester régulièrement cette procédure — pas seulement la documenter. Pour les organisations qui démarrent ce travail, un diagnostic de maturité cyber permet d'identifier rapidement les angles morts prioritaires avant le prochain incident.
Questions fréquentes
Comment des appareils déjà patchés peuvent-ils être concernés par FortiBleed ?
Le patch corrige la vulnérabilité d'accès au fichier de configuration, mais s'il a été appliqué après une exfiltration silencieuse, les hachages sont déjà entre les mains de l'attaquant. Le craquage se fait offline, sans interagir avec l'équipement : le correctif n'y change rien. Seule la rotation des identifiants après le patch neutralise réellement le risque.
Pourquoi les comptes admin génériques sont-ils si nombreux dans les données compromises ?
Les comptes avec des noms comme admin ou administrator sont souvent conservés par habitude ou par crainte de casser des intégrations existantes. Leur prévalence dans les données FortiBleed (35 % des comptes craqués) reflète une réalité opérationnelle : la rotation des identifiants par défaut est souvent reportée indéfiniment sur des parcs stabilisés.
Un mot de passe complexe protège-t-il suffisamment contre le craquage GPU ?
La complexité aide, mais elle doit être combinée à un mécanisme de hachage robuste côté équipement. Sur des hachages faibles (MD5, SHA-1 non salé), même des mots de passe de longueur raisonnable peuvent être craqués en quelques heures. La combinaison d'un mot de passe long à haute entropie, d'un stockage sécurisé et d'une authentification multifacteur reste la seule protection fiable.
Quelle est la procédure minimale recommandée après détection d'un équipement potentiellement exposé ?
Trois actions dans l'ordre : identifier tous les comptes présents sur l'équipement et leur origine, forcer la rotation immédiate de tous les mots de passe (y compris les comptes service), puis vérifier que le MFA est actif sur toutes les interfaces d'administration exposées. Si l'équipement a accès à d'autres systèmes internes, traiter le mouvement latéral potentiel comme priorité parallèle.