Le 14 octobre, l’Unité 42 a publié une enquête détaillée sur PEERSTITCH, un nouveau type d’implant déployé contre un fournisseur de services gérés de télécommunications (un MSP, c’est-à-dire une entreprise qui gère l’infrastructure réseau pour le compte de ses clients). L’intrusion a débuté à partir d’un seul dispositif de gestion. À partir de là, les pirates ont extrait des mots de passe, des clés de chiffrement et des fichiers de configuration complets de plus de 500 pare-feu appartenant à la fois au fournisseur et à ses clients.
Chaque étape s'appuyait sur un processus légitime, des identifiants valides ou un protocole de gestion fiable. Rien de ce qu'ils ont fait n'a jamais semblé suspect.
Un seul appareil, 500 pare-feu
La cible utilisait FortiManager de Fortinet, la console centrale qui transmet les paramètres à tous les pare-feu qui lui sont rattachés. Les attaquants ont exploité une vulnérabilité (CVE-2024-47575, connue sous le nom de FortiJump) qui leur a permis d'enregistrer un faux périphérique sur cette console à l'aide d'une seule requête non authentifiée. À partir de là, ils ont généré et téléchargé une archive contenant la configuration complète de chaque pare-feu géré : mots de passe stockés dans un format récupérable, clés de chiffrement privées, cartes du réseau et inventaire reliant chaque périphérique à son adresse publique.
L'Unit 42 a confirmé qu'elle était en mesure de pirater les mots de passe contenus dans ces fichiers de configuration. Disposant ainsi d'identifiants réels, les pirates se sont connectés via le VPN des pare-feu eux-mêmes. Le journal d'audit a enregistré ces connexions réussies.
Un bug de « gravité moyenne » qui permettait d'obtenir un accès root
Un administrateur de pare-feu, même le plus privilégié, opère dans un environnement de ligne de commande restreint. Le véritable système d’exploitation se trouve en arrière-plan et fonctionne avec un contrôle total. Les attaquants ont comblé cette brèche grâce à une deuxième vulnérabilité (CVE-2025-61624), une faille de traversée de chemin dans le système de scripts automatiques du pare-feu qui leur a permis de placer et d’exécuter un fichier n’importe où sur le système.
Cette faille n'est pas considérée comme critique. Son exploitation nécessite une session authentifiée. Prise isolément, elle semble justifier un correctif de priorité moyenne. Dans le cadre de cette intrusion, c'est cette étape qui a permis de transformer des identifiants volés en un contrôle total des pare-feu protégeant des centaines de réseaux. Cela revêt une importance particulière pour quiconque hiérarchise les correctifs en se basant uniquement sur leur niveau de gravité.
Un implant qui se cache à l'intérieur même du pare-feu
C'est ce que les pirates ont installé ensuite qui distingue cette intrusion des autres.
PEERSTITCH s'exécute une seule fois, s'injecte dans deux programmes déjà en cours d'exécution sur le pare-feu (son service de journalisation et son service VPN), puis se supprime du disque. Description d'Unit 42 : «PEERSTITCH ne laisse aucun fichier binaire persistant sur le disque, n'ouvre aucun port d'écoute et n'initie aucune connexion réseau sortante. Il communiqueplutôt via le trafic généré par des processus légitimes sur l'hôte infecté, ce qui rend l'malware e insensible aux techniques classiques d'endpoint s et de détection réseau. »
En termes simples : il n'y a aucun fichier suspect à repérer, aucun programme inattendu en cours d'exécution, aucune nouvelle connexion réseau à détecter. L'implant se cache au sein même des processus que le pare-feu est censé exécuter. Il communique en écrivant directement dans la mémoire de ces processus, et non via le réseau. Lorsque le service VPN gère une session et détecte un signal laissé par l'implant dans la mémoire, il contourne discrètement les contrôles de sécurité habituels du pare-feu.
Les pirates ont également détourné le système de renouvellement des certificats intégré au pare-feu pour en faire un canal de commande. Chaque fois que le pare-feu tentait de renouveler un certificat, il contactait un serveur contrôlé par les pirates et exécutait leurs instructions. Un cycle de maintenance de routine s'est ainsi transformé en une porte dérobée persistante.
Ils ont rangé derrière eux
Avant d'exécuter leurs outils, les attaquants ont désactivé le service de journalisation afin de l'empêcher d'enregistrer leur activité. Ils ont ensuite effacé les journaux d'erreurs, supprimé les comptes qu'ils avaient créés, remplacé leurs modifications de configuration par du texte factice inoffensif et supprimé le fichier binaire de l'implant du disque. L'équipe Unit 42 a également observé des coupures intermittentes de la connexion de gestion pendant les périodes d'activité malveillante, ce qui semble être une manœuvre délibérée visant à empêcher le déclenchement d'alertes en temps réel.
Écart n° 1 : tout semble normal
Cette intrusion correspond parfaitement à ce que j'appelle la « lacune n° 1 » dans le livre blanc intitulé « Mind Your Gaps in the Age of AI-Powered Attacks » : le scénario dans lequel des outils légitimes et des sessions valides servent de vecteurs à l'attaque, et où il n'existe aucune signature d'malware s permettant de la détecter.
Chaque composant était soit un processus de confiance, soit un identifiant valide. L'accès initial s'est effectué via un protocole de gestion que la console expose de par sa conception. Les sessions VPN utilisaient de véritables mots de passe et de véritables certificats, extraits des fichiers de la console elle-même. L'implant fonctionnait au sein des services du pare-feu lui-même. Le canal de commande passait par un module de certificats intégré, déclenché par un cycle de renouvellement standard.
Un pare-feu sur lequel PEERSTITCH est installé semble, à l'issue de tous les contrôles habituels, fonctionner normalement. Aucun processus inattendu. Aucun port inattendu. Aucune connexion inattendue. La seule différence réside dans le comportement du trafic qui le traverse.
La dimension MSP
Il existe ici une deuxième faille, que j’appelle généralement « faille n° 3 » : un mouvement qui traverse les frontières organisationnelles et qui n’est visible depuis aucun point de vue particulier. La cible était un MSP. Sa console de gestion détenait les clés d’accès aux pare-feu de ses clients. La compromission de la console d’une organisation a permis aux attaquants d’accéder, grâce à des identifiants, à des réseaux appartenant à d’autres organisations.
L'Unit 42 a précisé qu' elle n'avait pas examiné les réseaux des clients ; l'exposition décrite concerne donc le vol d'identifiants et de clés, et non une intrusion confirmée en aval. Cependant, ces clés n'expirent pas lorsque la console de gestion est mise à jour. Comme l'indique le rapport : «Les éléments de confiance cryptographiques régissant la relation entre la plateforme et chaque appareil géré restent entre les mains de l'attaquant et restent valides jusqu'à leur remplacement. »
L'application d'un correctif sur la console referme la porte qui avait été ouverte. Elle ne révoque pas les clés qui se sont échappées.
La détection doit se baser sur le comportement, et non sur la signature
La détection ne présente pas de dysfonctionnement. Elle est simplement incomplète. Les outils basés sur les fichiers ne détecteront pas PEERSTITCH, car il n'y a pas de fichier. Les outils de surveillance du réseau qui recherchent des connexions inattendues ne détecteront pas son canal de communication, car il communique au sein de la mémoire de l'hôte lui-même. Les outils de surveillance des sessions ne signaleront pas les connexions VPN, car les identifiants étaient valides.
C'est ce que permettrait de détecter la détection comportementale : remarquer que les schémas de trafic d'un pare-feu ont changé d'une manière que sa configuration ne justifie pas, ou que les sessions qui le traversent sont traitées différemment de ce qu'elles devraient l'être. Cela nécessite d'observer ce que fait le réseau, et pas seulement ce que signalent les terminaux. Le rapport d’Unit 42 comprend des indicateurs de compromission et une règle de détection à l’intention des équipes prêtes à mener des opérations de recherche. Le FBI et les Services secrets ont également publié, le 6 octobre, un avis conjoint concernant l’exploitation en cours des appareils FortiGate.
Vectra AIL'approche de [nom de l'entreprise] en matière de « détection et réponse aux incidents » s'articule précisément autour de ce type de lacune : identifier les comportements des attaquants dans le trafic réseau alors que les terminaux, les identifiants et les outils de gestion indiquent tous que tout va bien. Le livre blanc intitulé « Mind Your Gaps in the Age of AI-Powered Attacks », au chapitre 2, présente en détail la lacune n° 1.