FortiBleed : pourquoi un mot de passe divulgué suffisait pour prendre le contrôle d'un FortiGate

Le 6 octobre 2026, le FBI et le Secret Service américain ont publié un avis conjoint sur FortiBleed, une campagne visant les pare-feu Fortinet FortiGate exposés à Internet et leurs passerelles VPN (avis du FBI et de l’USSS). L’avis reprend le décompte de SOCRadar, qui fait état de plus de 86 644 équipements compromis dans 194 pays, et décrit la campagne comme toujours en cours.

Le plus frappant, c’est ce dont les attaquants n’ont pas eu besoin. L’analyse de Fortinet elle-même est sans détour : « Il ne s’agit pas d’une nouvelle vulnérabilité Fortinet » (Fortinet PSIRT). Aucun exploit n’a été nécessaire. Les attaquants se sont simplement connectés.

Le déroulement de l’attaque

L’avis reconstitue la campagne à partir du serveur des attaquants eux-mêmes, qu’ils avaient laissé exposé. En résumé :

Trouver les pages de connexion. Des balayages automatisés d’Internet à la recherche de portails VPN FortiGate.
Essayer des mots de passe connus. Bourrage d’identifiants (credential stuffing) et pulvérisation de mots de passe (password spraying), alimentés par d’anciennes fuites de données Fortinet et par les journaux de logiciels voleurs d’informations (infostealers).
Casser le reste. Les empreintes de mots de passe récupérées sur des équipements compromis étaient envoyées à une grappe de GPU pour être cassées hors ligne. Le stockage SHA-256 hérité, peu robuste, des mots de passe administrateur facilitait la tâche.
S’installer durablement. De nouveaux comptes administrateur étaient créés sur le pare-feu. Dans certains cas, les comptes des propriétaires étaient supprimés ou leurs mots de passe modifiés, et les victimes se retrouvaient exclues de leurs propres équipements.
Revendre l’accès. Des configurations VPN fonctionnelles et des listes de cibles étaient regroupées en lots à destination d’autres criminels. L’avis souligne que FortiBleed a servi de point d’entrée à des affiliés de groupes de ransomware.

Chaque étape précédant l’installation durable repose sur une seule hypothèse : un nom d’utilisateur et un mot de passe valides suffisent pour se connecter au VPN ou à l’interface d’administration du pare-feu.

Ce qui rompt la chaîne

Supprimez cette hypothèse et les principaux outils de la campagne cessent de fonctionner. Si le VPN et la console d’administration exigent en plus une approbation sur le téléphone de l’utilisateur, un mot de passe deviné, acheté ou cassé ne suffit plus à se connecter. La tentative échoue, et avec une approbation lisible, elle devient aussi un signal : quelqu’un vient d’utiliser ce mot de passe, et son titulaire voit une demande dont il n’est pas à l’origine.

L’avis comme Fortinet placent l’authentification multifacteur sur chaque compte administrateur et VPN en bonne place parmi leurs premières recommandations. C’est précisément ce que couvre Notakey. Un FortiGate peut transmettre les connexions VPN et administrateur à un serveur RADIUS, et l’auth-proxy Notakey s’insère dans ce chemin RADIUS : il laisse votre serveur RADIUS existant vérifier le mot de passe, demande ensuite une approbation sur le téléphone, et ne répond favorablement que si les deux réussissent. La mise en place est décrite dans notre guide 2FA sur un VPN via RADIUS.

Ce que cela ne corrige pas

Nous préférons être précis plutôt que de vous vendre quelque chose.

Un équipement déjà compromis. Le MFA sur les nouvelles connexions ne change rien aux comptes créés par les attaquants, aux sessions qu’ils détiennent déjà ou à une configuration qu’ils ont modifiée. Les mesures préconisées par l’avis passent en premier : mettre fin à toutes les sessions d’administration et VPN, réinitialiser les mots de passe, comparer les utilisateurs et la configuration à une copie saine connue, et stocker les mots de passe administrateur avec PBKDF2 plutôt qu’avec les anciennes empreintes.
Une interface d’administration exposée. La première recommandation de l’avis est de restreindre l’administration depuis Internet : hôtes de confiance (bien), politique local-in (mieux), ou aucune administration depuis Internet (idéal). Un second facteur sur une interface qui ne devrait pas être joignable reste la solution la moins solide.
Les pages d’hameçonnage qui relaient une connexion en temps réel. L’avis demande un MFA résistant au phishing. Selon la définition du gouvernement américain, cela signifie FIDO/WebAuthn ou une PKI, où la clé est liée au véritable site. Une approbation sur téléphone empêche qu’un mot de passe deviné ou cassé suffise, ce sur quoi reposait cette campagne. Elle n’arrête pas, à elle seule, un attaquant qui relaie une véritable connexion à travers une fausse page, comme nous l’expliquons dans notre billet sur la lassitude MFA et les attaques par relais. Pour les quelques comptes qui administrent le pare-feu lui-même, des clés liées au site méritent d’être envisagées.

Si vous exploitez des FortiGate

Trois points pratiques avant de placer une approbation sur téléphone devant un FortiGate. Ils sont tirés de la documentation de Fortinet ; nous n’avons pas testé nous-mêmes de FortiGate en laboratoire, et un FortiGate dialogue avec l’auth-proxy en RADIUS standard, comme n’importe quel autre concentrateur VPN.

Augmentez les délais RADIUS. Par défaut, le FortiGate accorde 5 secondes à l’ensemble de l’échange RADIUS (remoteauthtimeout) et renvoie une requête au bout de 5 secondes (timeout sur le serveur RADIUS) (Fortinet : comment les deux temporisations interagissent). C’est suffisant pour vérifier un mot de passe, pas pour qu’une personne sorte son téléphone. L’auth-proxy maintient la requête ouverte pendant que l’utilisateur décide (30 secondes par défaut) : les deux valeurs doivent donc dépasser largement cette fenêtre. La note technique de Fortinet précise qu’avec des valeurs égales, le FortiGate envoie tout de même la requête une seconde fois. L’auth-proxy reconnaît une requête renvoyée et l’ignore : l’utilisateur ne reçoit donc pas de seconde demande d’approbation, mais faire du délai de renvoi le plus long des deux permet de s’en tenir à une seule requête. Par exemple, 60 secondes au total et 90 avant un renvoi (notakey-proxy désigne le nom que vous avez donné à l’entrée de serveur RADIUS qui pointe vers l’auth-proxy) :
```
config system global
    set remoteauthtimeout 60
end

config user radius
    edit "notakey-proxy"
        set timeout 90
    next
end
```
Les administrateurs peuvent emprunter le même chemin. Le FortiGate prend en charge l’authentification à distance des administrateurs auprès d’un serveur RADIUS (Fortinet : authentification à distance des administrateurs), y compris un compte administrateur générique pour tous les membres d’un groupe RADIUS (Fortinet : configuration des comptes administrateur génériques). L’approbation protège ainsi la console que visaient les attaquants, et pas seulement le VPN.
Conservez un accès de secours. FortiBleed a exclu des propriétaires de leurs propres équipements. Gardez un administrateur local d’urgence doté d’un mot de passe long et unique, joignable uniquement depuis des hôtes de confiance, et testez-le avant d’en avoir besoin.

Par où commencer

Vérifiez trois choses cette semaine : si l’administration de votre pare-feu est joignable depuis Internet, si un compte VPN ou administrateur se connecte encore avec un simple mot de passe, et comment sont stockés les mots de passe administrateur. Si la réponse à la deuxième question est oui, c’est précisément la brèche que FortiBleed a été conçu pour exploiter.

Essayez la démo en ligne pour approuver une connexion depuis votre propre téléphone en deux minutes environ, ou demandez une démo et nous définirons avec vous un projet pilote couvrant vos connexions VPN et pare-feu.