Une campagne de pare-feu a exposé 70 000 identifiants. Les sessions VPN sont le vrai risque.

Group-IB et NyxLab ont publié le 21 octobre 2026 une enquête conjointe sur une campagne qui a récolté des identifiants sur des pare-feu et des portails VPN exposés à Internet, principalement dans les gammes FortiGate et FortiWeb de Fortinet et sur les passerelles GlobalProtect de Palo Alto Networks. The Hacker News a rapporté les conclusions le 23 octobre. Les chercheurs attribuent l'activité à un pseudonyme criminel, k0t, également vu sous les noms CryptoFeel, Member19 et QazWsxShop, et comptent plus de 70 000 identifiants exposés et données associées, y compris des extractions LDAP.

À lire aussi: Le groupe Leakers$ détourne des panneaux LED publics en Égypte, en Malaisie et au Brésil · La branche japonaise de Sony, fournisseur d'accès, annonce une fuite de 2,6 millions d'enregistrements.

Le chiffre se lit facilement de travers. Soixante-dix mille est un décompte d'entrées d'identifiants, pas d'organisations compromises, et Group-IB ne donne aucun nombre de victimes pour la campagne. Pour les défenseurs, ce qui compte est la séquence derrière : un équipement que l'on trouve depuis un moteur de recherche, un fichier de configuration qui se déchiffre avec une clé que tout le monde connaît et une session VPN qui peut survivre à l'identifiant qui l'a ouverte.

Ce que les 70 000 comptent vraiment

Le jeu de données décrit dans le rapport de Group-IB et NyxLab est du matériel opérationnel : des identifiants d'équipements réseau, plus des extractions d'annuaire du type qu'un équipement conserve lorsqu'il authentifie le personnel auprès de LDAP ou d'Active Directory. Group-IB indique que l'ensemble recoupait très peu les données d'identifiants FortiBleed signalées plus tôt en 2026, ce qui compte parce qu'un défenseur ayant nettoyé après FortiBleed pourrait sinon supposer que cette liste est la même.

Ce n'est pas une liste de victimes. Group-IB note que les identifiants de victimes vont de domaines publics et d'adresses e-mail à des adresses IP internes, et que l'attribution exacte ne peut pas être vérifiée pour tout l'ensemble. Les domaines uniques trouvés dans le matériel donnent une borne inférieure du nombre d'organisations touchées. La répartition régionale de ces domaines est de 37,6 % pour l'Asie-Pacifique, 31,9 % pour l'Amérique latine, 15,8 % pour l'Europe et 12,7 % pour le Moyen-Orient et l'Afrique du Nord. Les chercheurs précisent que cela reflète les endroits où les équipements exposés ont été trouvés lors de l'analyse, et non un projet de cibler ces régions.

Beaucoup des compromissions de FortiGate portent des dates entre février et juin 2026, la même fenêtre que FortiBleed. Group-IB évalue avec une confiance modérée que l'activité appartient à la grappe plus large liée à FortiBleed, tout en disant que les preuves n'établissent pas que les mêmes opérateurs ont géré les deux ensembles. Les deux chiffres qui circulent sur ces campagnes mesurent aussi des choses différentes. Cryptopolitan a résumé le décompte FortiBleed par 86 644 équipements compromis, en citant SOCRadar. Additionner les identifiants d'une campagne aux équipements d'une autre produit un chiffre plus gros et aucune image utile.

Un scanner, pas une équipe de recherche

La reconnaissance explique la dispersion. k0t ne semblait pas choisir ses victimes par secteur ni par rumeur. Selon le rapport, l'opérateur a acheté ou emprunté un accès à des moteurs de recherche de surface d'attaque, a demandé sur un forum public un compte FOFA premium ou quelqu'un capable d'exporter des listes d'IP depuis FOFA, ZoomEye et Censys, et a déclaré plus tard avoir trouvé des partenaires pour FOFA et ZoomEye. Des résultats en masse au format ip:port étaient demandés pour que des outils automatisés puissent les traiter.

Les recherches se sont concentrées sur les portails GlobalProtect, filtrés par les caractéristiques de la page de connexion, les en-têtes de réponse et les certificats, d'abord en Amérique du Nord, puis en Europe et en Asie-Pacifique. Les systèmes FortiGate et FortiWeb figuraient aussi dans la file, et des consoles SonicWall SMA1000, OPNsense et Cisco ISE apparaissent dans la surveillance de l'opérateur. Le rapport indique qu'il n'existe aucune preuve de compromission réussie d'un SMA1000.

« k0t semble choisir ses cibles potentielles en énumérant à grande échelle des équipements réseau exposés plutôt qu'en enquêtant sur des organisations individuelles. » — Chercheurs de Group-IB et NyxLab, 21 octobre 2026

Cette distinction compte parce que c'est l'exposition, et non le secteur, qui a décidé qui apparaissait dans l'ensemble. L'outillage correspond à cette approche : un scanner FortiGate qui ingère un fichier texte d'adresses, étiquette chacune avec un pays depuis une base GeoIP embarquée et fait tourner un pool de threads sur la liste. Le rapport note une liste d'exclusion codée en dur pour la région de la CEI et d'autres juridictions, désactivable par un indicateur, et que certaines victimes venaient des pays exclus, ce qui suggère que l'indicateur a été utilisé. Cybersecurity News a aussi détaillé les deux scripts sur mesure derrière l'opération.

La clé par défaut qui fait avouer un pare-feu

Une fois dans un FortiGate, l'outil peut télécharger la configuration de l'équipement et la déchiffrer localement. La clé est la clé AES par défaut de FortiOS, une faiblesse suivie sous CVE-2019-6693. Le correctif de Fortinet a consisté à ajouter une option de chiffrement des données privées. Si personne ne l'a activée, l'équipement continue d'utiliser la clé connue, et une sauvegarde de configuration devient un fichier lisible.

Une configuration de pare-feu contient plus que des règles. Elle contient les identifiants que l'équipement utilise pour se lier à LDAP ou à Active Directory, ainsi que des comptes administrateur et des comptes locaux, parce que l'équipement a besoin de ces secrets pour faire son travail. Un attaquant capable de déchiffrer le fichier hérite des relations que ces secrets autorisent. Aucun exploit n'est nécessaire à ce stade, seulement un téléchargement et une routine de déchiffrement.

C'est l'étape la moins spectaculaire de la chaîne et probablement la plus lourde de conséquences. Un équipement non corrigé est une exposition temporaire qu'une fenêtre de maintenance peut fermer. Un identifiant d'annuaire copié dans un fichier de configuration reste valide jusqu'à ce que quelqu'un le change, et l'équipement ne montre aucun signe qu'il a été lu. C'est exactement pour cette raison que les conseils défensifs de Group-IB traitent un équipement de bord compromis comme une possible compromission des identifiants de l'entreprise.

Deux façons de passer la connexion

Les méthodes d'accès initial varient selon le produit.

Sur FortiWeb, l'outil exploite CVE-2025-64446, une traversée de chemin relative qui peut permettre à un attaquant non authentifié d'exécuter des commandes administratives via des requêtes HTTP ou HTTPS forgées. La requête usurpe le compte intégré prof_admin avec un en-tête falsifié, puis crée un nouvel administrateur local avec un nom d'utilisateur aléatoire de huit caractères et la même chaîne comme mot de passe. Le nouveau compte reçoit le profil prof_admin et une plage d'hôtes de confiance 0.0.0.0/0, ce qui signifie qu'il peut se connecter de n'importe où.

Sur FortiGate, où cette voie ne s'applique pas, le repli est la force brute contre l'API REST, avec des noms d'utilisateur comme admin, fortinet et sysadmin et des mots de passe comme admin et fortigate. Quand l'équipement renvoie un code de verrouillage, l'outil met l'hôte en attente pendant 60 secondes et réessaie, ce qui correspond au minuteur de verrouillage par défaut de l'administrateur FortiGate. Le rapport lit ce détail comme le signe que l'auteur de l'outil connaissait le produit.

La voie Palo Alto utilise CVE-2026-0257, un contournement d'authentification dans les portails et passerelles GlobalProtect de PAN-OS et Prisma Access, mais uniquement là où les cookies de contournement d'authentification et la configuration de certificats correspondante sont activés. L'exploit forge un cookie en chiffrant une chaîne de session avec une clé publique tirée du certificat TLS de la cible elle-même, puis le soumet avec un mot de passe vide au point de terminaison de connexion GlobalProtect. Un équipement vulnérable le déchiffre, vérifie le format de la session et ne vérifie pas si le cookie a jamais été légitime. De là, l'outil ouvre une connexion VPN OpenConnect. The Hacker News avait déjà rapporté que des opérateurs de Qilin et INC tentaient d'exploiter la même faille.

Cette dernière étape est la raison pour laquelle « corrigez le pare-feu » est une instruction incomplète. La session est déjà authentifiée. Elle n'a plus besoin du mot de passe.

Ce que l'accès devient

Le manuel de post-exploitation est familier, et c'est en partie pourquoi il fonctionne. OpenConnect fournit le point d'appui. La reconnaissance couvre Active Directory, les partages SMB et les antivirus installés. La persistance vient de logiciels de gestion à distance : agents MeshCentral, Atera, Teramind, AnyDesk, ngrok, plus AdaptixC2 comme second canal de commande. L'élévation de privilèges utilise NetExec, Impacket, noPac, Kerbrute, PetitPotam et Mimikatz, et l'exfiltration passe par Rclone vers des buckets Wasabi S3 et des lecteurs MEGA.

Les chiffres de MeshCentral donnent une idée de l'échelle. Au moment de l'analyse, Group-IB a trouvé 28 groupes d'équipements actifs contenant 84 équipements compromis, plus des artefacts pour 100 autres groupes depuis supprimés. Le serveur ne contenait aucun fichier, ce que les chercheurs lisent comme un signe d'accès interactif en direct, avec des données préparées et déplacées séparément.

Group-IB évalue aussi que les opérateurs partagent des liens avec les groupes de rançongiciel Qilin et The Gentlemen, agissant probablement comme courtier d'accès initial ou affilié. La base est le recoupement des victimes : beaucoup d'organisations de cette campagne ont ensuite été listées sur les sites de fuite de ces groupes. Le rapport qualifie la relation de non confirmée, et la réserve mérite d'être répétée. Le recoupement des victimes prouve qu'un accès a circulé, pas qui l'a vendu à qui.

Corriger ferme la porte, pas la session

Les deux CVE ont des correctifs éditeurs, et la campagne exploite des failles connues et des configurations faibles. Ni Fortinet ni Palo Alto Networks ne sont cités dans le rapport avec une nouvelle déclaration, il n'y a donc pas de bilan récent des éditeurs sur le nombre d'équipements encore exposés.

TechPastWeek a couvert ce mois-ci deux épisodes comparables d'équipements de bord : les zero-days Citrix NetScaler et la faille d'écriture de fichiers de FortiMail. Les deux se sont terminés par la même instruction de corriger, et les deux ont laissé la même question sur ce que l'attaquant avait déjà emporté. Côté FortiBleed, les avertissements du gouvernement américain début octobre indiquaient que l'activité se poursuivait, un mauvais moment pour traiter un correctif isolé comme une clôture.

La liste de remédiation qui découle du rapport est plus longue qu'une file de correctifs :

• Recensez chaque FortiGate, FortiWeb et portail GlobalProtect exposé à Internet. Le conseil du rapport part lui-même de l'exposition, pas du secteur.
• Vérifiez le niveau de correctif et la configuration. Pour GlobalProtect, les réglages de contournement d'authentification et de certificats décident si CVE-2026-0257 s'applique. Sur FortiOS, le chiffrement des données privées décide si une configuration volée est lisible.
• Partez du principe que les secrets stockés sont compromis si un équipement a été atteint. Faites tourner les identifiants de liaison à l'annuaire et les administrateurs locaux, et révoquez les sessions VPN au lieu d'attendre leur expiration.
• Traquez les comptes que personne n'a créés : nouveaux administrateurs locaux, plages d'hôtes de confiance modifiées, exports de configuration, schémas de verrouillage et de nouvelle tentative, connexions depuis des adresses inhabituelles.
• Cherchez des installations de MeshAgent, Atera, Teramind, AnyDesk, ngrok et AdaptixC2, et Rclone écrivant vers du stockage cloud.

L'ordre compte. Corriger d'abord sans faire tourner les identifiants laisse à l'intrus sa voie la plus facile, et une session ouverte via un cookie forgé ignore que le bug soit corrigé.

Ce qui reste inconnu est vaste. Group-IB a promis un rapport technique supplémentaire. Il n'y a ni nombre de victimes, ni victimes nommées, ni attribution étatique dans le matériel public, et le chiffre de 70 000 continuera d'être cité comme s'il fournissait les trois. La question plus utile pour un défenseur est plus modeste et admet une réponse : lesquels de mes équipements sont trouvables depuis un moteur de recherche, et qu'apprendrait un attaquant de leur fichier de configuration ?

Image de couverture : « Fortinet FortiGate 6501F.png » de Premeditated, CC BY-SA 4.0, via Wikimedia Commons. L'image montre un châssis FortiGate 6501F, l'une des gammes de produits visées par la campagne.