FortiBleed expose les pouvoirs en transit et convertit FortiGate à porte d'entrée pour intrus

Socrates a publié un rapport qui élargit la recherche sur la campagne de masse connue sous le nom de « FortiBleed », et sa conclusion la plus inquiétante est que les attaquants n'ont pas seulement collecté des références anciennes : ils ont déployé des snifers personnalisés sur les appareils FortiGate pour capturer des secrets d'authentification en transit et produire des références exploitables à grande échelle. Selon le rapport, l'opération aurait affecté des centaines de milliers de dispositifs FortiGate depuis au moins février 2026, ce qui en fait un exemple de la façon dont un échec dans la gestion de l'accès et dans l'exposition des consoles administratives peut devenir une première étape d'accès pour les acteurs spécialisés.

La technique centrale décrite dans le rapport est l'utilisation d'un outil en Go, baptisé comme FortigateSniffer, qui est connecté par SSH aux pare-feu commis et exécute la commande légitime de diagnostic FortiOS "diagnostic sniffer paquet". Cet abus d'une fonction administrative permet aux attaquants d'inspecter le trafic en temps réel pour rechercher des documents d'identification et d'authentification pour des protocoles tels que RADIUS, NTLM, Kerberos, LDAP, SMTP, IMAP, bases de données, RDP et bien d'autres.

Conseil Radar documente également une chaîne de traitement complète : les paquets capturés sont reconstruits avec un composant appelé SNIFTRAN et sont analysés avec une boîte à outils Python qui extrait des identifiants de texte clairs, des hashes et des tickets Kerberos. Ces artefacts sont ensuite préparés pour les attaques de force brute hors ligne et les craquements massifs avec Hashcat dans les GPU d'affaires loués. L'hypothèse selon laquelle les attaquants ont même téléchargé des fichiers de configuration et extrait des hachages est appuyée par une analyse de recherche indépendante; un résumé technique de cette mise à jour peut être lu sur le blog de Kevin Beaumont ( Kevin Beaumont) et dans le rapport Socrates ( Démantèlement de FortiBleed - SOCRadar).

Le profil de l'adversaire décrit ci-dessus correspond à celui d'un courtier d'accès initial (IAB): les acteurs qui y accèdent et les vendent sur les marchés illicites, ou qui les utilisent pour des intrusions et des extorsions ultérieures. La combinaison de techniques automatisées de farce crédentale, de force brute, d'exfiltration de configurations et de fissuration accélérée à l'aide de GPUs permet de transformer l'accès temporaire en identifiants réutilisables et, par conséquent, des portes d'entrée persistantes aux réseaux d'entreprise.

La complexité de l'attaque souligne un principe fondamental : un pare-feu commis n'est plus seulement une barrière et devient un observatoire privilégié. Un FortiGate avec accès administratif peut voir et enregistrer le trafic sensible; si cet appareil est contrôlé, l'attaquant obtient une visibilité sur les identifiants que de nombreuses organisations continuent d'envoyer en texte clair ou avec des protocoles vulnérables. Cela rend l'infrastructure d'identité - Active Directory, serveurs RADIUS, bases de données, courrier - cibles immédiates pour le mouvement latéral et l'escalade des privilèges.

Pour les équipes de sécurité et les administrateurs de FortiGate, la première priorité est d'examiner si l'inventaire fait partie des objectifs connus. Kevin Beaumont a publié une liste des adresses IP liées à la campagne qui peuvent servir de point de départ à la recherche ( liste des IP indiquée). De plus, la preuve de l'exécution d'un « paquet de sniffers de diagnose » et de connexions SSH non autorisées devrait être considérée comme un indicateur d'engagement de réponse immédiate.

En termes d'atténuation pratique, les organisations doivent agir sur deux fronts : le confinement immédiat et le durcissement structurel. Dans le confinement, vous devez examiner les comptes administratifs du pare-feu, faire pivoter les identifiants et les clés, désactiver l'accès administratif à partir d'Internet quand ils ne sont pas nécessaires, examiner les fichiers de configuration récents, restaurer à partir de sauvegardes fiables s'il y a des preuves de manipulation et activer multi-facteur pour l'accès administratif. En durcissant, il convient de limiter l'exposition des services de gestion aux réseaux internes ou aux bastions sûrs, de chiffrer les communications d'authentification (LDAP, TLS pour les services), d'appliquer la segmentation de sorte qu'un appareil engagé ne donne pas un accès direct aux domenas d'identité, et de surveiller les commandes administratives et les captures de paquets dans les pare-feu.

Un autre aspect pertinent que la campagne révèle est l'utilisation de l'ordinateur GPU loué par les agresseurs pour déchiffrer les hachages sur une échelle: louer 36 GPU d'affaires vous permet de casser les mots de passe beaucoup plus rapidement que la plupart des équipes de sécurité interne. Cela nous oblige à supposer que tout hachage obtenu pourrait être brisé en peu de temps, de sorte que la rotation des lettres de créances et la restauration des secrets après un éventuel engagement doit être effectuée sans délai. Pour comprendre la technologie utilisée pour le craquage et ses limites techniques, des sources publiques telles que le projet Hashcat offrent un contexte sur les capacités de craquage ( Hashcat).

Enfin, cet incident devrait servir à renforcer un changement de paradigme: il ne suffit pas de protéger de façon permanente; il est nécessaire de concevoir des défenses où les identités et les clés d'accès ne voyagent pas clairement et ne peuvent pas être recueillies d'un seul point de contrôle. Mettre en œuvre des politiques d'accès avec moins de confiance implicite, appliquer le MFA universellement, vérifier et alerter sur les changements dans les paramètres de sécurité, et pratiquer des exercices de réponse incidente avec des scénarios d'engagement de l'infrastructure réseau sont des étapes qui réduisent la récompense pour les acteurs cherchant à exploiter des dispositifs réseau comme les vecteurs.

Si vous administrez FortiGate ou si vous gérez l'identité dans votre organisation, examinez le rapport technique de SOCRadar, mettez à jour des chercheurs indépendants et la liste des PI publiés, et envisagez d'activer une réponse médico-légale et d'informer les parties touchées : la fenêtre pour empêcher que les titres de compétence saisis ne deviennent des accès persistants est limitée et une action proactive peut éviter des intrusions plus graves.