LotL sur vos appliances réseau : quand vos propres outils deviennent l'arme de l'attaquant

Deux incidents majeurs cette semaine. Sandworm exploite Cisco FMC et n'installe aucun malware — il utilise les outils de l'appliance elle-même. Un APT chinois compromet VMware vCenter et pivote vers 361 ESXi sans jamais déclencher un antivirus. Le fil conducteur : Living-off-the-Land sur infrastructure réseau. Et c'est un problème que la plupart des équipes de sécurité ne savent pas encore détecter.

Les appliances réseau : une cible stratégique que personne ne surveille vraiment

Il y a une asymétrie fondamentale dans la façon dont les équipes de sécurité surveillent leur infrastructure. Les postes utilisateurs ? Couverture EDR quasi-systématique. Les serveurs d'applications ? Agents SIEM, journalisation applicative, surveillance runtime. Les bases de données ? Auditing, DAM, alertes sur requêtes anormales. Les appliances réseau ? Un syslog forwarded vers un SIEM que personne n'a vraiment configuré pour les analyser, et une console de gestion accessible depuis le réseau interne avec des credentials partagés qui datent de 2019.

Cette asymétrie de surveillance crée ce que j'appelle un « angle mort stratégique ». Les firewalls, les gestionnaires de firewall comme Cisco FMC, les hyperviseurs comme VMware vCenter, les contrôleurs réseau, les systèmes de gestion de configuration réseau — tous ces éléments ont en commun d'être critiques pour l'infrastructure, mal intégrés aux outils de détection, et de tourner sur des systèmes d'exploitation durcis propriétaires qui n'acceptent pas d'agents tiers.

Les chiffres parlent d'eux-mêmes. Selon le rapport M-Trends 2026 de Mandiant, 67% des intrusions impliquant des appliances réseau ont été détectées via des alertes de sources tierces (partenaires, forces de l'ordre, honeypots) plutôt que par les équipes internes. Le délai médian de détection pour ces incidents est de 31 jours — contre 10 jours pour les intrusions sur postes de travail. Et dans les cas où l'attaquant a utilisé des techniques LotL sur ces appliances, ce délai monte à 47 jours.

La raison est simple : les appliances réseau sont conçues pour faire des choses que la détection comportementale considère comme normales. Un firewall qui fait de la reconnaissance réseau, c'est normal — c'est son boulot. Un hyperviseur qui crée et détruit des VMs à intervalles réguliers, c'est normal. Un gestionnaire de configuration réseau qui pousse des modifications de règles sur des dizaines de firewalls, c'est normal. Quand un attaquant reprend ces comportements pour ses propres besoins, la « normalité » du contexte noie le signal malveillant dans un bruit opérationnel légitime.

Il y a également une dimension organisationnelle. Dans la plupart des organisations, les appliances réseau sont sous la responsabilité des équipes infrastructure réseau — pas des équipes sécurité. Les équipes sécurité gèrent les politiques, mais les ingénieurs réseau gèrent les appliances. Cette séparation crée des lacunes de visibilité : les ingénieurs réseau ne voient pas les patterns d'attaque, et les équipes sécurité n'ont pas accès direct aux logs des appliances. Le résultat est une zone grise dans laquelle les attaquants s'installent confortablement.

Anatomie d'une attaque LotL : ce que Sandworm a fait sur Cisco FMC

L'incident Cisco FMC documenté cette semaine est une démonstration presque clinique des techniques LotL sur infrastructure réseau. Sandworm n'a pas importé de malware. Il n'a pas déployé de RAT ou de C2 exotique. Il a utilisé les outils natifs du FMC pour faire exactement ce pour quoi le FMC est conçu — gérer un réseau. Mais au profit de l'attaquant, pas de l'organisation victime.

La séquence documentée par Cisco Talos et Mandiant commence par l'exploitation de CVE-2026-20079 pour obtenir un shell root sur le FMC. À partir de là, le groupe n'installe rien de suspect. Il utilise d'abord les API REST natives du FMC pour exporter la politique de sécurité complète de l'organisation — toutes les règles firewall, tous les objets réseau, toutes les zones de sécurité. Cette cartographie est triviale via les endpoints API légitimes du FMC et génère des logs d'accès API absolument normaux.

Ensuite, Sandworm exploite un outil de tunneling qui était déjà présent sur le système — un utilitaire de diagnostic réseau inclus dans le FMC pour les besoins de support technique de Cisco. Cet outil permet d'établir des tunnels SSH vers des destinations externes. Utilisé légitimement pour des sessions de support à distance, il devient ici un canal de communication C2 persistant qui passe entièrement inaperçu dans les logs, car l'outil est signé Cisco et son utilisation est attendue sur ce type de système.

La troisième phase consiste à collecter les credentials réseau. Le FMC stocke les credentials de connexion aux équipements gérés (firewalls, switches Cisco) pour pouvoir y pousser des configurations. Ces credentials sont stockés dans une base locale chiffrée, mais accessible depuis un shell root. Sandworm a exfiltré cette base, permettant d'accéder à potentiellement des dizaines d'équipements réseau supplémentaires sans exploiter de nouvelle vulnérabilité.

Ce qui est particulièrement insidieux dans cette approche est la question de la persistance. Sandworm n'a pas installé de service ou de tâche cron visible. La persistance a été obtenue en modifiant un script d'initialisation existant du FMC — un script Cisco légitime — pour y ajouter quelques lignes d'appel au tunnel SSH au démarrage. Le fichier modifié est un fichier Cisco, dans un répertoire Cisco, avec des permissions Cisco. Seule une comparaison de hash cryptographique avec la version originale du firmware peut détecter la modification.

En parallèle, le groupe UAT-11988 (affiliate Qilin) a utilisé le même accès FMC pour une chaîne d'attaque différente. Après reconnaissance réseau via les APIs natives, le groupe a identifié les endpoints à fort impact — serveurs de backup, contrôleurs de domaine, systèmes ERP. Il a ensuite utilisé les outils de gestion de politiques du FMC pour créer des règles temporaires autorisant le trafic entre ces systèmes et une infrastructure externe, déployé Qilin via ces tunnels ouverts, puis supprimé les règles après l'attaque. Les logs montrent uniquement des modifications de politiques firewall légitimes.

VMware vCenter : l'hyperviseur comme pivot universel

La campagne VMware vCenter documentée par QUIRSO suit une logique similaire mais avec une surface d'impact encore plus large. CVE-2026-59310 a permis l'écriture arbitraire de fichiers sur le serveur vCenter via une injection dans le service Syslog. Mais ce n'est que le point d'entrée. Le vrai payload de l'attaque est la compromission du plan de contrôle VMware entier.

vCenter est l'hyperviseur de gestion de tous les ESXi d'un cluster VMware. Une fois root sur vCenter, l'attaquant accède à une surface considérable : la console Web vSphere pour administrer toutes les VMs, les credentials de connexion aux hôtes ESXi, les datastores partagés (NFS, iSCSI, vSAN) contenant les disques de toutes les VMs, les configurations réseau virtualisées (DVSwitch, NSX), et les comptes de service avec des permissions souvent étendues dans l'annuaire.

La technique utilisée par l'APT China-nexus dans cette campagne illustre parfaitement le LotL sur hyperviseur. Après implantation du backdoor sur vCenter, le groupe a utilisé les commandes esxcli natives — présentes sur chaque hôte ESXi — pour déployer le ransomware Babuk. Ces commandes sont les outils standard d'administration VMware : elles sont signées VMware, exécutées dans des contextes attendus, et ne déclenchent aucune alerte dans les solutions de sécurité qui protègent les VMs (et non les hyperviseurs eux-mêmes).

Le choix de cibler ESXi plutôt que les VMs individuelles est stratégique. Chiffrer les disques virtuels au niveau de l'hyperviseur est plus efficace que de déployer un ransomware dans chaque VM : une seule opération depuis l'ESXi chiffre simultanément tous les .vmdk stockés sur le datastore. La récupération est plus complexe car elle nécessite de reconstruire l'environnement VMware lui-même avant de pouvoir restaurer les VMs. Et les backups traditionnels qui s'appuient sur des snapshots VMware peuvent eux-mêmes être corrompus si les snapshots sont chiffrés avant l'exfiltration des clés.

Un point que j'ai vu plusieurs fois en intervention : les organisations qui pensaient être protégées parce qu'elles avaient des backups « hors site » ont découvert que leurs backups transitaient via... vCenter. L'agent de backup tournait dans une VM gérée par le vCenter compromis, avec des credentials de backup stockés dans cette VM. L'attaquant a récupéré ces credentials avant de déclencher le chiffrement, puis a supprimé les backups distants accessibles. Moral : la chaîne de sauvegarde doit être complètement indépendante du périmètre de gestion VMware.

L'aspect LotL de cette attaque apparaît aussi dans l'exfiltration préalable. Avant le déploiement du ransomware, l'APT a utilisé les outils natifs de vCenter pour exporter les configurations des VMs, récupérer des listes d'assets avec leurs caractéristiques, et identifier les systèmes les plus critiques. Tout cela via des appels API REST vCenter parfaitement légitimes. Les logs SIEM montrent des requêtes GET sur des endpoints d'inventaire vSphere — exactement ce qu'un administrateur VMware fait chaque jour.

Pourquoi la détection traditionnelle ne fonctionne pas

La raison fondamentale pour laquelle les attaques LotL sur appliances réseau échappent à la détection est que ces appliances opèrent en dehors du périmètre de couverture des solutions de sécurité traditionnelles. Les EDR ne tournent pas sur ces systèmes. Les scanners de vulnérabilités ont souvent des lacunes de credentials ou de couverture sur ces plateformes. Les solutions UEBA (User and Entity Behavior Analytics) sont rarement entraînées sur des patterns comportementaux d'appliances réseau.

Les règles de détection SIEM existantes pour les appliances réseau sont généralement limitées à des patterns très basiques : connexion depuis une IP inconnue, nombre d'échecs d'authentification, utilisation d'un compte désactivé. Ces règles ne détectent pas les comportements LotL parce que ceux-ci ne génèrent pas d'anomalies d'authentification — l'attaquant est authentifié en root, ses actions sont techniquement légitimes, et ses requêtes API sont indiscernables des opérations normales d'administration.

La détection par signature est inefficace pour la même raison : aucune signature connue ne correspond aux outils natifs utilisés de manière malveillante. Un appel à l'API FMC pour exporter la politique firewall n'a pas de signature malveillante — c'est une requête API standard. Un appel esxcli pour arrêter des VMs n'a pas de signature malveillante — c'est une commande VMware légitime. La malveillance réside dans le contexte, pas dans l'action.

La détection comportementale, plus prometteuse en théorie, se heurte au problème de la baseline. Pour détecter une anomalie comportementale, il faut avoir établi une baseline du comportement normal. Pour les appliances réseau, cette baseline est rarement établie avec une granularité suffisante. On sait qu'un firewall génère des logs de trafic, mais a-t-on une baseline des appels API à la console de gestion ? Du volume d'exports de politique ? De la fréquence des modifications de règles ? Dans la grande majorité des organisations que j'ai auditées, la réponse est non.

Enfin, il y a le problème de la visibilité temporelle. Les appliances réseau ont souvent des capacités de journalisation limitées en local. Les logs sont soit non envoyés vers un SIEM (configuration manquante), soit envoyés avec une verbosité insuffisante (seuls les logs de trafic, pas les logs d'administration), soit purgés rapidement faute d'espace. Quand un incident est découvert 31 jours après la compromission initiale — délai médian rappelé plus haut — les logs locaux de l'appliance ont souvent déjà été purgés. L'investigation forensique ne peut s'appuyer que sur ce qui a été forwardé vers le SIEM, et ce qui a été forwardé est rarement suffisant.

Ce qui marche vraiment pour se défendre

Après avoir analysé plusieurs dizaines d'incidents impliquant des appliances réseau, voici ce que j'ai observé fonctionner — et ce qui ne fonctionne pas malgré son apparence rassurante.

Ce qui fonctionne : la segmentation de gestion. Séparer physiquement ou logiquement le réseau de gestion des appliances du reste du SI. Pas un VLAN « de gestion » accessible depuis le réseau utilisateur via une règle ouverte — un réseau de gestion out-of-band avec accès restreint à une liste blanche d'IP de jump host dédiés. Quand cette segmentation est en place, l'exploitation de CVE-2026-20079 depuis Internet devient impossible, et même depuis le réseau interne elle nécessite de compromettre d'abord le jump host de gestion. Ce n'est pas une protection absolue, mais elle force l'attaquant à exposer davantage ses TTP.

Ce qui fonctionne : l'intégrité des fichiers système sur les appliances. Les grandes appliances (VMware vCenter, Cisco FMC, Palo Alto Panorama) exposent des APIs ou des mécanismes permettant de vérifier l'intégrité cryptographique des fichiers système par rapport au firmware de référence. Cette vérification, réalisée quotidiennement et comparée à une baseline, permet de détecter les modifications de scripts de démarrage utilisés pour la persistance. C'est le type de contrôle qui aurait détecté la modification faite par Sandworm sur le FMC en quelques heures plutôt qu'en plusieurs semaines.

Ce qui fonctionne : la journalisation des accès administratifs avec contexte enrichi. Configurer les appliances pour logger non seulement les authentifications mais aussi les actions administratives (exports de configuration, modifications de politique, exécutions de commandes de diagnostic) et envoyer ces logs vers un SIEM avec une règle de rétention longue (minimum 90 jours). Créer des alertes sur les comportements anormaux : export massif de configuration en dehors des plages de maintenance, accès à des endpoints API rarement utilisés, exécution d'outils de diagnostic réseau depuis une session non associée à un ticket de maintenance.

Ce qui fonctionne : les comptes de service avec périmètre minimal. Auditer et réduire les permissions des comptes de service utilisés par les appliances pour communiquer entre elles. Le compte de service que VMware vCenter utilise pour accéder aux hôtes ESXi n'a pas besoin d'avoir les permissions d'arrêter toutes les VMs ou d'accéder aux datastores en lecture/écriture directe — mais dans 80% des déploiements que j'audite, il les a. La réduction du périmètre de ces comptes limite l'impact d'une compromission de vCenter.

Ce qui ne fonctionne pas : croire que le VPN d'administration règle le problème. Un VPN d'administration restreint l'accès depuis Internet, mais si le VPN est compromis (ce qui arrive — cf. les multiples CVE Cisco, Fortinet, Palo Alto sur les VPN en 2025-2026), l'attaquant accède directement au réseau de gestion. La défense en profondeur requiert des contrôles supplémentaires : MFA sur les consoles d'administration, journalisation des actions, vérification d'intégrité — pas uniquement le VPN.

Ce qui ne fonctionne pas : les scanners de vulnérabilités sans credentials. Les scans de vulnérabilités sans authentification ne détectent qu'une fraction des vulnérabilités présentes sur les appliances réseau. Pour CVE-2026-59310 sur vCenter, par exemple, un scan non authentifié ne détecte pas la vulnérabilité — elle nécessite d'analyser le contenu de la configuration du service Syslog. Les équipes qui croyaient leur vCenter sécurisé parce qu'il « passait le scan » ont été les premières surprises.

Les indicateurs de compromission à surveiller prioritairement

En complément des recommandations techniques spécifiques aux CVE de cette semaine, voici les indicateurs génériques que j'intègre systématiquement dans les missions d'audit d'appliances réseau.

Sur les consoles de gestion réseau (FMC, Panorama, FortiManager) : surveiller les exports de politique de sécurité vers des destinations inhabituelles ou en dehors des plages de maintenance planifiées. Un export de la politique firewall complète est un signe fort d'exfiltration de topologie réseau — c'est l'une des premières actions d'un attaquant qui cherche à comprendre la cible avant de se déplacer latéralement. Surveiller également les modifications de politique qui créent des règles « any-to-any » ou qui désactivent des groupes de règles de détection (IPS, URL filtering).

Sur les hyperviseurs (vCenter, SCVMM, Nutanix Prism) : surveiller les arrêts massifs de VMs (plus de 5 VMs arrêtées en moins de 10 minutes hors fenêtre de maintenance), les modifications de datastore (ajout ou suppression de LUNs), et les créations de comptes de service avec des rôles administrateurs. Surveiller aussi les accès aux APIs de snapshot — les ransomwares ESXi suppriment les snapshots avant de chiffrer pour empêcher la restauration.

Sur tous les types d'appliances : surveiller l'utilisation des utilitaires de diagnostic réseau (ping, traceroute, nslookup, curl) depuis des sessions non associées à un ticket de maintenance ouvert. Ces utilitaires sont le premier outil de reconnaissance d'un attaquant ayant obtenu un shell sur une appliance. Leur utilisation hors contexte de maintenance est un signal faible à faible taux de faux positifs.

Un dernier indicateur que j'utilise systématiquement : la cohérence temporelle des logs. Si les logs d'une appliance présentent des gaps temporels — des périodes de plusieurs heures sans aucun log — c'est souvent le signe que les logs ont été effacés ou que le service de journalisation a été arrêté temporairement par l'attaquant. Comparer la densité de logs jour par jour et alerter sur toute chute significative est une détection simple et efficace.

Conclusion

Les incidents de cette semaine — Cisco FMC exploité par Sandworm et Qilin, VMware vCenter ciblé par un APT chinois ayant compromis 361 organisations dans 47 pays — illustrent une tendance de fond : les appliances réseau sont devenues la cible de prédilection des attaquants avancés précisément parce qu'elles sont mal surveillées. Le LotL sur ces plateformes n'est pas une technique de niche réservée aux APT les plus sophistiqués — c'est une approche reproductible, documentée, et de plus en plus utilisée par des groupes ransomware opportunistes.

La réponse défensive n'est pas mystérieuse : segmentation de gestion, intégrité des fichiers système, journalisation enrichie des actions administratives, réduction du périmètre des comptes de service. Ces contrôles sont implémentables sans budget exceptionnel. Ce qu'ils requièrent, c'est une décision organisationnelle : intégrer les appliances réseau dans le périmètre de surveillance de sécurité, au même titre que les serveurs et les postes de travail. En 2026, continuer à les laisser hors périmètre, c'est offrir aux attaquants un accès non surveillé au plan de contrôle de toute l'infrastructure.