Un nouveau malware baptisé PEERSTITCH attire l’attention des spécialistes de la cybersécurité en raison de sa capacité à se dissimuler dans la mémoire des équipements réseau et à exploiter des processus légitimes de Fortinet FortiOS. Selon les chercheurs de Palo Alto Networks Unit 42, cet implant a été découvert lors de l’analyse d’une intrusion visant un fournisseur de services de télécommunications.
L’attaque repose notamment sur l’exploitation de la vulnérabilité CVE-2025-61624, une faille de traversée de répertoire affectant plusieurs produits Fortinet. Évaluée à 5,4 sur l’échelle CVSS dans le compte rendu de The Hacker News, elle a été corrigée par Fortinet en avril 2026.
La particularité de PEERSTITCH réside dans son fonctionnement furtif : le malware ne laisse pas de binaire persistant sur le disque, n’ouvre pas de port d’écoute et ne déclenche pas directement de connexion réseau sortante. Il s’appuie plutôt sur des processus légitimes de l’équipement compromis pour établir un mécanisme de communication caché et contourner certaines vérifications appliquées aux sessions VPN.
Source : The Hacker News — PEERSTITCH Malware Deployed via FortiOS Flaw.
CVE-2025-61624 : une faille Fortinet exploitée dans une attaque ciblée
La vulnérabilité CVE-2025-61624 concerne l’interpréteur de commandes de plusieurs produits Fortinet, notamment :
- FortiOS ;
- FortiPAM ;
- FortiProxy ;
- FortiSwitchManager.
Cette faille de traversée de répertoire peut permettre à un attaquant disposant des privilèges nécessaires de provoquer l’écriture ou la suppression de fichiers en utilisant des arguments spécialement construits pour certaines commandes existantes.
Le risque dépend du produit, de sa version, de sa configuration et du niveau d’accès obtenu par l’attaquant. Dans le cas décrit par Unit 42, cette vulnérabilité a été exploitée pour contribuer au déploiement du malware PEERSTITCH sur des équipements FortiGate.
Il est important de noter que le score CVSS de 5,4 ne suffit pas à mesurer le risque opérationnel dans un environnement donné. Une vulnérabilité de gravité moyenne peut avoir des conséquences importantes lorsqu’elle intervient après la compromission d’un équipement d’administration centralisé ou dans une chaîne d’attaque visant plusieurs systèmes.
Fortinet a publié un correctif pour cette vulnérabilité en avril 2026. Les administrateurs doivent consulter l’avis de sécurité officiel pour identifier les versions affectées et les versions corrigées correspondant à leur environnement.
Référence : Avis de sécurité Fortinet — CVE-2025-61624, FG-IR-26-122.
Une intrusion plus large visant l’infrastructure FortiManager
D’après Unit 42, PEERSTITCH a été découvert au cours de l’investigation d’une intrusion prolongée contre un fournisseur de services de télécommunications, dont l’activité a été observée en septembre 2024.
L’opération, suivie sous l’identifiant CL-STA-0954, également associé à UNC5820, aurait commencé par la compromission d’un équipement FortiManager au moyen de la vulnérabilité critique CVE-2024-47575, connue sous le nom de FortiJump.
FortiManager permet d’administrer de manière centralisée des équipements Fortinet. Lorsqu’une telle plateforme est compromise, l’incident peut dépasser le périmètre d’un seul appareil : les configurations, les informations d’administration et les relations entre équipements gérés peuvent fournir aux attaquants des possibilités d’accès supplémentaires.
Dans le cas étudié, les chercheurs rapportent l’exfiltration d’une archive contenant notamment :
- des configurations de plus de 500 pare-feu FortiGate administrés ;
- des numéros de série et des adresses IP publiques associés aux équipements ;
- des informations sur la topologie et le routage des réseaux ;
- des données de configuration de l’infrastructure FortiManager ;
- des identifiants administratifs et VPN chiffrés, ainsi que des éléments cryptographiques.
Ces informations auraient ensuite servi à la reconnaissance du réseau, à l’établissement d’accès supplémentaires et au déploiement de portes dérobées. L’exploitation de CVE-2025-61624 intervient dans cette chaîne d’intrusion pour installer PEERSTITCH.
Cette séquence souligne un enjeu majeur : la compromission d’une plateforme d’administration centralisée peut faciliter l’extension d’une attaque à de nombreux équipements et réseaux clients.
La présence de plus de 500 pare-feu dans l’inventaire concerné ne signifie toutefois pas que tous ont nécessairement été infectés par PEERSTITCH. Elle illustre l’étendue de l’environnement administré et l’impact potentiel de l’exposition des données de gestion.
PEERSTITCH : un malware qui fonctionne directement en mémoire
PEERSTITCH est décrit comme un exécutable Linux ARM64 écrit en langage C. Il est conçu pour opérer directement dans la mémoire de processus légitimes de FortiOS, plutôt que de s’appuyer sur un fichier malveillant persistant sur le disque.
Selon les chercheurs, le malware présente plusieurs caractéristiques qui compliquent sa détection :
- Absence de binaire persistant : les méthodes de détection reposant uniquement sur l’analyse des fichiers peuvent passer à côté de l’implant.
- Pas de port d’écoute propre : le malware ne se comporte pas comme un service malveillant classique ouvrant son propre port réseau.
- Pas de connexion sortante directe : il utilise des processus légitimes pour dissimuler ses communications.
- Modification de processus existants : son fonctionnement repose sur l’injection de code dans la mémoire de composants de FortiOS.
Cette approche réduit les traces classiques sur lesquelles s’appuient certains outils de surveillance. Elle ne rend cependant pas le malware indétectable : des anomalies dans les processus, les journaux, le comportement VPN ou l’intégrité de l’équipement peuvent encore fournir des indices aux équipes de réponse à incident.
Les organisations doivent donc éviter de s’appuyer uniquement sur les antivirus traditionnels ou sur la recherche de fichiers connus. Les équipements réseau nécessitent également des contrôles adaptés à leur système d’exploitation, à leurs journaux et à leur comportement opérationnel.
Comment PEERSTITCH contourne certaines vérifications VPN
L’un des aspects les plus préoccupants de PEERSTITCH est son utilisation de deux processus légitimes de FortiOS : miglogd et iked.
D’après Unit 42, le malware modifie le comportement de ces processus afin d’établir un canal de communication interne dissimulé. Un mécanisme de marquage permet ensuite d’associer certaines sessions à un identifiant particulier. Lorsque le processus chargé de la gestion des échanges VPN retrouve cet identifiant, il peut suivre un chemin d’exécution alternatif qui contourne les validations de sécurité normalement appliquées.
En pratique, l’implant cherche à faire traiter certaines sessions VPN d’une manière différente du fonctionnement prévu par le système. Cela peut permettre aux attaquants de maintenir un accès discret à l’infrastructure compromise.
Cette technique est particulièrement préoccupante dans les environnements où les pare-feu assurent à la fois la protection du périmètre, l’accès distant et la segmentation des réseaux. Un équipement compromis peut devenir un point d’appui pour atteindre des ressources qui ne sont pas directement exposées à Internet.
Il convient néanmoins de distinguer le mécanisme décrit par les chercheurs de ses conséquences possibles : le contournement de contrôles VPN ne signifie pas automatiquement que tous les utilisateurs, toutes les connexions ou tous les réseaux administrés ont été affectés.
Une attaque difficile à détecter avec une surveillance classique
Les méthodes employées par les attaquants vont au-delà du simple déploiement d’un fichier malveillant. Unit 42 rapporte également des tentatives de dissimulation des traces, notamment par l’interruption de la génération de journaux système, l’effacement de journaux d’incident et la perturbation de la télémétrie.
Les chercheurs indiquent aussi que des comptes administrateurs non autorisés et certains objets de scripts automatiques ont été supprimés après exécution. Ces actions peuvent compliquer la reconstitution de la chronologie d’une attaque.
Dans ce contexte, plusieurs signaux doivent attirer l’attention des équipes de sécurité :
- des interruptions inexpliquées de la journalisation ;
- des modifications inattendues des comptes ou des configurations d’administration ;
- des sessions VPN qui ne correspondent pas aux habitudes d’accès ;
- des écarts d’intégrité dans les processus ou composants du pare-feu ;
- des changements inhabituels dans les relations entre FortiManager et les équipements gérés.
Pris isolément, ces événements ne prouvent pas une infection. Ils doivent être corrélés avec les journaux disponibles, l’inventaire des équipements et les informations communiquées par Fortinet et les chercheurs.
Les administrateurs peuvent consulter les ressources du centre de réponse aux incidents de sécurité Fortinet (PSIRT) pour suivre les avis officiels et les recommandations relatives aux vulnérabilités des produits de l’éditeur.
Quelles mesures pour protéger les équipements Fortinet ?
Face à cette menace, les organisations utilisant FortiOS, FortiGate ou FortiManager doivent adopter une démarche qui combine correction des vulnérabilités, vérification de l’exposition et recherche d’éventuelles compromissions.
1. Vérifier les versions et appliquer les correctifs
Les équipes informatiques doivent inventorier les équipements Fortinet déployés, relever leurs versions exactes et les comparer aux versions affectées et corrigées indiquées dans les avis officiels.
La mise à jour doit suivre les recommandations de Fortinet et le parcours de mise à niveau adapté à chaque produit. Il ne faut pas supposer qu’un correctif appliqué à FortiOS suffit à traiter une éventuelle compromission antérieure de FortiManager ou d’un autre composant.
2. Sécuriser FortiManager et les interfaces d’administration
Les plateformes de gestion centralisée doivent être particulièrement protégées. Il est recommandé de limiter leur accès aux réseaux et aux personnes autorisés, de réduire leur exposition directe à Internet et de renforcer l’authentification des comptes administratifs.
Les organisations doivent également examiner les journaux d’accès, les modifications de configuration et les relations d’administration entre FortiManager et les pare-feu gérés.
3. Rechercher les signes d’une compromission antérieure
L’installation d’un correctif empêche l’exploitation de la vulnérabilité corrigée dans les conditions prévues par ce correctif, mais elle ne garantit pas que l’équipement n’a pas déjà été compromis.
Les équipes de sécurité doivent examiner les journaux disponibles, les sessions VPN, les comptes administrateurs, les scripts automatiques et les changements de configuration inhabituels. Elles doivent aussi rechercher les signes de perturbation de la journalisation et comparer l’état des équipements à une configuration de référence fiable.
Si une compromission est suspectée, il est préférable de préserver les éléments de preuve et de suivre une procédure de réponse à incident avant d’effectuer des opérations de nettoyage susceptibles d’effacer des traces.
4. Réévaluer les identifiants et les accès
Lorsque des configurations, des identifiants ou des éléments cryptographiques ont pu être exposés, les organisations doivent évaluer la nécessité de renouveler les secrets concernés.
Cette démarche peut comprendre la rotation des mots de passe administratifs, des identifiants VPN et des clés ou certificats potentiellement exposés, ainsi que la révocation des sessions et des accès non autorisés.
Le renouvellement doit être coordonné avec les équipes responsables des services concernés pour éviter une interruption non maîtrisée des activités.
5. Renforcer la surveillance des équipements réseau
Les pare-feu et les plateformes d’administration doivent être intégrés aux procédures de supervision et de réponse à incident de l’organisation. La surveillance doit porter autant sur les événements de sécurité que sur les anomalies de fonctionnement, les changements d’administration et les comportements VPN.
Une attention particulière doit être accordée aux équipements administrant plusieurs sites ou réseaux clients, car leur compromission peut avoir des conséquences qui dépassent leur propre périmètre.
Conclusion : la compromission d’un pare-feu peut ouvrir la voie à une attaque plus vaste
La découverte de PEERSTITCH met en évidence l’évolution des techniques utilisées contre les équipements réseau. En opérant directement dans la mémoire de processus légitimes et en détournant certains contrôles VPN, ce malware cherche à maintenir un accès discret tout en échappant aux méthodes de détection les plus classiques.
L’incident analysé par Unit 42 rappelle également le risque associé à la compromission des plateformes d’administration centralisée : les données de configuration et les accès à de nombreux équipements peuvent devenir un levier pour étendre une intrusion.
Pour les organisations utilisant les produits Fortinet, les priorités sont de vérifier les versions déployées, d’appliquer les correctifs recommandés, de sécuriser les interfaces d’administration et de rechercher les signes d’une compromission antérieure. En présence d’indices suspects, une simple mise à jour ne doit pas remplacer une investigation complète.
La protection des infrastructures réseau exige ainsi une approche globale, associant gestion rigoureuse des vulnérabilités, contrôle des accès, surveillance des comportements et capacité de réponse aux incidents.
