Des systèmes de contrôle Cisco Catalyst SD-WAN compromis sont devenus un point de collecte de clés de chiffrement lors d'attaques menées avec un logiciel malveillant sur mesure appelé KeyDrift, selon les conclusions de Cisco Talos rapportées par The Hacker News. Les attaquants ont obtenu l'accès grâce à la CVE-2026-20127, un contournement d'authentification corrigé en février.
Talos a qualifié les attaques d'historiques dans sa divulgation du 28 octobre, sans fournir de dates d'incident. Ses conclusions décrivent un logiciel malveillant conçu pour collecter et transmettre du matériel de clés présumé ; elles n'établissent pas que ces clés soient parvenues aux attaquants ni que le trafic réseau ait été déchiffré.
La collecte des clés au cœur du processus de contrôle
KeyDrift place son composant LittleFilch à l'intérieur de vdaemon, le processus du Controller chargé des connexions de contrôle chiffrées. De là, LittleFilch examine les messages après déchiffrement, en sélectionnant les adresses IP et un champ de 32 octets pour un ensemble prédéfini de routeurs de périphérie. Talos estime que ce champ contient du matériel de clés AES-256 distribué par le Controller.
Ce point de collecte correspond à l'architecture traditionnelle d'échange de clés de Cisco. La documentation technique de Cisco décrit des routeurs générant une clé AES pour chaque emplacement de transport, ou TLOC, puis la soumettant dans des paquets de route du protocole Overlay Management Protocol. Le Controller redistribue ces informations dans des annonces d'accessibilité afin que les routeurs puissent établir des chemins de données chiffrés. Les clés AES se régénèrent toutes les 24 heures par défaut, et des politiques de contrôle peuvent limiter les routeurs qui reçoivent les clés des autres.
Cette architecture diffère de l'option de clés par paires de Cisco. Avec les clés par paires, le Controller distribue des valeurs publiques Diffie-Hellman, tandis que les routeurs de périphérie dérivent leurs clés IPsec à l'aide d'ECDH et d'une courbe P-384. Le comportement de LittleFilch signalé concerne le matériel de clés transporté par l'échange traditionnel ; il ne démontre pas la collecte de clés dérivées de paires.
LittleFilch protège ses enregistrements collectés par chiffrement RSA avant de les sauvegarder dans /var/tmp/vdaemon.bin. Une capacité distincte envoie ces enregistrements par UDP vers une destination indiquée dans /var/tmp/vdaemon.conf. Le logiciel malveillant supprime ce fichier de configuration après l'avoir lu, et Talos n'a pas pu le récupérer. Il reste à déterminer si la transmission a eu lieu.
Le fonctionnement des implants
L'analyse de Talos, telle que rapportée par The Hacker News, décrit des scripts de démarrage de services modifiés comme principal mécanisme de lancement de KeyDrift. Une variante modifie le script d'exécution sous etc/sv/sshd/ afin que conf_sshd s'exécute avant le véritable serveur SSH. Ce chargeur écrit les identifiants de processus de vdaemon dans /tmp/system-vdaemon ; un injecteur nommé rsshd place ensuite PolyFlame, le module principal de KeyDrift, dans ces processus.
PolyFlame fonctionne en mémoire. Sa porte dérobée de type TinyShell prend en charge l'exécution de commandes ainsi que la lecture et l'écriture de fichiers, tandis qu'un mode relais fait transiter les commandes entre un serveur de commandes et d'autres machines. Les commandes peuvent arriver dans le trafic de contrôle SD-WAN. Aucune adresse de serveur codée en dur n'est apparue dans les échantillons analysés.
Un implant Validator emprunte une voie différente. Un service fabriqué dans /etc/sv/aaamgr/ lance le chargeur packé aaamgrd, qui déchiffre et exécute PolyFlame. Cette distinction compte pour la détection : le véritable composant aaamgr de Cisco est un paquet Python et ne fonctionne normalement pas comme un service compilé. Les noms de modules signalés sont libdssl.so pour PolyFlame et libcommon.so pour LittleFilch.
Talos a également observé des commandes transférant les dates de modification et les permissions de fichiers existants vers des fichiers créés par les attaquants, ce qui indique un timestomping destiné à modifier leur historique apparent.
La faille d'accès et les correctifs disponibles
L'avis de sécurité de Cisco identifie une authentification défectueuse du peering comme vulnérabilité sous-jacente. Des requêtes forgées par un attaquant distant non authentifié peuvent aboutir à des privilèges administratifs. Sur un Controller, le compte interne qui en résulte est hautement privilégié sans être root ; il permet un accès NETCONF et des modifications de la configuration de la structure SD-WAN.
Les produits concernés sont Catalyst SD-WAN Controller, Manager et Validator, anciennement appelés vSmart, vManage et vBond, quelle que soit la configuration. Le périmètre de déploiement couvre les installations sur site ainsi que Cisco Hosted SD-WAN Cloud, y compris les environnements Cisco Managed et FedRAMP. Cisco reconnaît une exploitation limitée et recommande la mise à niveau, car aucun contournement ne corrige la faille.
Ses correctifs propres à chaque branche de version sont les suivants :
| Branche de version Catalyst SD-WAN | Première version corrigée ou migration requise |
|---|---|
| Antérieures à 20.9 | Migrer vers une version corrigée |
| 20.9 | 20.9.8.2 |
| 20.11 | 20.12.6.1 |
| 20.12 | 20.12.5.3 ou 20.12.6.1 |
| 20.13 | 20.15.4.2 |
| 20.14 | 20.15.4.2 |
| 20.15 | 20.15.4.2 |
| 20.16 | 20.18.2.1 |
| 20.18 | 20.18.2.1 |
Cisco indique que les versions antérieures à 20.9 ainsi que les branches 20.11, 20.13, 20.14 et 20.16 ont atteint la fin de la maintenance logicielle, et encourage les clients à choisir une version prise en charge.
Pour les clients sur site qui attendent une mise à niveau, Cisco recommande de restreindre les ports 22 et 830 aux Controllers connus et aux autres systèmes spécifiés qui ont besoin d'un accès. Cette mesure d'atténuation a fonctionné dans un environnement de test ; les clients doivent évaluer son efficacité ainsi que ses effets possibles sur le fonctionnement ou les performances du réseau dans leurs propres déploiements. Cisco affirme que ces garde-fous d'accès existent déjà dans les environnements hébergés listés. Cette affirmation établit la présence de restrictions, et non l'état d'application des correctifs sur chaque instance hébergée.
La détection doit aussi traiter les compromissions existantes
Cisco conseille de vérifier /var/log/auth.log à la recherche d'entrées Accepted publickey for vmanage-admin associées à des adresses IP inconnues ou non autorisées, puis de comparer ces adresses aux System IP configurées dans Manager. Il demande également une validation manuelle des événements de peering des connexions de contrôle, en particulier des pairs vmanage, en se fondant sur les rôles, adresses, activités de maintenance et enregistrements d'authentification attendus pour chaque équipement.
Avant d'ouvrir un dossier auprès du Technical Assistance Center, les clients doivent exécuter request admin-tech sur chaque composant de contrôle. The Hacker News rapporte aussi que les recommandations de remédiation de Cisco préconisent de réanalyser ces fichiers via Check Bug Applicability sur la page Bug Search Tool pour CSCws52722.
Pour la détection réseau, la mise à jour de Talos du 28 octobre a introduit les règles Snort 2 67387 à 67416 et les règles Snort 3 7:44 à 7:73 pour les connexions entrantes de commande et de contrôle de KeyDrift. Les règles Snort 2 sont désactivées par défaut et doivent être activées par les utilisateurs payants de l'ensemble de règles Snort Subscriber ; la mise à jour ne précise aucun état par défaut pour les règles Snort 3. Les règles 65938 et 65958 couvrent l'exploitation de la CVE-2026-20127 elle-même.
Talos recommande d'appliquer les correctifs, de suivre le guide de durcissement de Cisco et de lancer une réponse à incident dès que des signes de compromission post-exploitation apparaissent. La restriction des ports ne supprime pas les logiciels malveillants déjà installés. Comme le cite The Hacker News, le guide de remédiation de Cisco publié en février avertit qu'une exploitation établie avant une mise à niveau peut persister après celle-ci.
Pour les agences civiles fédérales du pouvoir exécutif américain (FCEB), la directive d'urgence ED 26-03 de la CISA, publiée le 25 février et mise à jour le 11 mars, impose un signalement immédiat lorsqu'une compromission du compte root est identifiée. Les agences doivent reconstruire le plan de gestion du contrôle à partir de nouvelles instances de Manager, Controller et Validator issues d'images OVA ou qcow2 corrigées, puis y migrer leurs équipements de périphérie.
Le recoupement d'infrastructures limite l'attribution
Talos attribue l'activité KeyDrift à UAT-11473, un opérateur qui cible les services spatiaux et satellitaires, les technologies de défense et d'aérospatiale, ainsi que la recherche en politique publique. Selon The Hacker News, Talos estime avec une grande confiance que son infrastructure recoupe largement celle de Silent Train, le nom donné par Lumen Black Lotus Labs à un réseau d'appareils compromis de petits bureaux et domiciles, d'objets connectés (IoT) et d'entreprises.
Lumen affirme que Volt Typhoon a utilisé ce réseau pour dissimuler son activité. La CISA, la NSA et le FBI ont identifié Volt Typhoon comme un acteur parrainé par l'État chinois en 2024. Ce recoupement d'infrastructures ne revient pas à identifier UAT-11473 comme Volt Typhoon, et Talos n'a pas expliqué son lien avec UAT-8616, le groupe d'exploitation décrit en février comme remontant à 2023 au moins.
Par ailleurs, The Hacker News rapporte que Lumen a indiqué le 28 octobre que Volt Typhoon avait exploité la CVE-2026-20127 au plus tard fin 2025, et qu'il avait poursuivi ses activités après la divulgation de février. Lumen n'a pas attribué KeyDrift à cette activité.
