Un groupe de pirates informatiques chinois a pris le contrôle complet du système d’authentification d’une organisation et est resté présent pendant une décennie. Les attaquants ont eu une vision totale de l’activité administrative.
Les chercheurs de Sygnia ont nommé cette intrusion « Operation Highland ». Ils l’attribuent au groupe d’espionnage numérique Velvet Ant. Cette campagne a ciblé d’abord des systèmes vulnérables exposés sur internet, puis a basculé vers un réseau interne sans connexion directe à l’extérieur.
Les pirates de Velvet Ant ont pénétré le réseau isolé d’infrastructures critiques d’une grande organisation. Ils y ont mené des opérations d’espionnage pendant dix ans.
La campagne a débuté en 2016. Sygnia a documenté en 2024 les longues opérations de ce groupe, qui avait déjà exploité pendant trois ans des appareils F5 BIG-IP sans être détecté. La même année, Cisco avait signalé une vulnérabilité zero-day dans NX-OS sur des commutateurs Nexus, que Velvet Ant exploitait.
Le déroulement de l’attaque de Velvet Ant
L’attaque a commencé par la compromission de serveurs accessibles depuis internet. Les chercheurs ne précisent pas la vulnérabilité exploitée.
Velvet Ant a déployé un shell inverse GS-Netcat modifié, camouflé en composant système légitime. Ce shell se connectait à un domaine relais codé en dur et offrait un accès à distance chiffré. Il assurait sa persistance soit via un service systemd malveillant, soit par la modification d’un script de démarrage.
Source : Sygnia
Ensuite, les pirates ont installé un proxy SOCKS5 personnalisé pour tunneliser le trafic réseau. Cela leur a permis d’atteindre des systèmes internes non accessibles directement depuis internet. Le proxy fonctionnait comme un démon déguisé en ‘smbd -D’, avec des noms de fichiers et des ports différents sur chaque machine. Les serveurs compromis sont ainsi devenus des points de pivot internes.
Source : Sygnia
La partie la plus complexe de l’attaque a consisté à construire un chemin d’exécution à distance vers le réseau isolé. Pour y parvenir, Velvet Ant a modifié la configuration d’un serveur Nginx compromis et exposé sur internet. Ce serveur devait rediriger des requêtes spécialement conçues vers un serveur backend compromis.
La configuration Nginx du serveur backend a aussi été altérée pour transmettre les requêtes à un processus FastCGI (fcgiwrap) écoutant sur un port distinct. Ce wrapper FastCGI a servi de pont d’exécution. Il traitait les requêtes et lançait un binaire personnalisé nommé ‘uptime’. Cet outil établissait des connexions SSH vers les systèmes du réseau isolé d’infrastructures critiques, en utilisant les paramètres fournis dans des requêtes HTTP POST.
Sygnia explique : « En enchaînant ces modifications, Velvet Ant a établi un chemin d’exécution à distance vers l’environnement séparé via de simples requêtes HTTP, sans jamais nécessiter de connexion directe au réseau d’infrastructures critiques. »
Persistance à long terme et vol d’identifiants
Une fois l’accès à l’environnement isolé établi, Velvet Ant s’est concentré sur la persistance à long terme et le vol de mots de passe. Les pirates ont ciblé les Linux Pluggable Authentication Modules (PAM), un ensemble de bibliothèques qui permettent aux administrateurs de configurer les méthodes d’authentification.
Les attaquants ont remplacé les modules légitimes ‘pam_unix.so’ par des versions piégées. Ces versions acceptaient des mots de passe codés en dur et collectaient les identifiants des utilisateurs. Sygnia a identifié neuf variantes distinctes du module PAM malveillant, chacune compilée dans un environnement de build séparé. Ce détail indique un acteur bien équipé.
Les chercheurs notent que deux de ces modules malveillants se distinguent car ils agissent à la fois comme une porte dérobée et comme un collecteur d’identifiants.
Les acteurs de Velvet Ant ont aussi remplacé des composants OpenSSH comme ssh, sshd et scp par des versions trojanisées. Ces versions capturaient les mots de passe, enregistraient les commandes entrées pendant les sessions SSH et stockaient les données collectées localement pour une récupération future.
Sygnia déclare qu’en étendant leur contrôle au processus d’authentification via la modification des composants PAM et OpenSSH, les pirates ont eu accès aux mots de passe au moment de leur utilisation. Ils pouvaient aussi contourner le flux d’authentification.
Les chercheurs précisent : « L’activité administrative est devenue entièrement observable : chaque connexion, chaque commande exécutée sur les hôtes compromis. L’accès n’était plus lié à un point d’entrée spécifique mais intégré au processus d’authentification lui-même. »
De cette manière, les pirates ont assuré leur persistance malgré les changements de mot de passe et les fermetures de session. Ils ont aussi réduit l’efficacité des mesures de confinement conventionnelles.
Une purification complexe
Sygnia rapporte que même après la découverte de la compromission, la remédiation et l’éviction de Velvet Ant ont été particulièrement complexes.
Les pirates avaient remplacé tant de composants critiques par leurs versions personnalisées que leur suppression risquait de rompre l’authentification. Cela aurait pu bloquer les administrateurs légitimes et provoquer des interruptions de service.
Pour résoudre ce problème, les chercheurs ont construit un laboratoire de test. Ils ont validé le processus de remplacement des binaires, profilé chaque hôte, testé les résultats et préparé des procédures de retour en arrière avant de tenter le nettoyage.
Sygnia recommande aux défenseurs de considérer les composants d’authentification comme PAM, OpenSSH et le LSASS de Windows comme des actifs de sécurité critiques. Il faut les protéger avec un EDR, une surveillance de l’intégrité des fichiers, un accès privilégié renforcé, une authentification multi-facteurs et une surveillance continue des modifications non autorisées.
Les organisations doivent aussi planifier une récupération hors ligne. Cela inclut des sauvegardes strictes avec une planification adéquate pour créer automatiquement des instantanés avec des copies immuables. Le processus de restauration doit prévoir de tester les sauvegardes et les scripts de récupération sur des hôtes exécutant des systèmes d’exploitation validés.