La présence d’un malware dans un contrôleur réseau peut mettre les secrets qui protègent le trafic entre les agences à la portée d’un attaquant.
Cisco Talos a publié le 28 octobre une analyse d’activités historiques de KeyDrift, décrivant un framework malveillant déployé après l’exploitation par des attaquants d’une faille d’authentification de Cisco Catalyst SD-WAN. Les chercheurs estiment qu’il a été conçu pour maintenir l’accès et collecter du matériel de clés de chiffrement. Les cibles observées comprenaient des services satellitaires ainsi que des organisations des secteurs de la défense, de l’aérospatiale et de la recherche stratégique.
Pour les équipes de sécurité, ces conclusions soulèvent deux questions : les contrôleurs vulnérables ont-ils reçu le correctif, et les attaquants avaient-ils établi un accès avant cela ?
Fonctionnement de KeyDrift dans les contrôleurs réseau
Selon l’enquête de Cisco Talos, un groupe suivi sous le nom UAT-11473 a exploité CVE-2026-20127 pour installer KeyDrift.
Son composant PolyFlame s’exécute au sein de processus légitimes des contrôleurs et prend en charge des commandes de porte dérobée. Un autre composant, LittleFilch, examine les messages de contrôle déchiffrés et extrait ce que Talos estime être du matériel de clés AES-256 IPsec utilisé pour protéger le trafic de données SD-WAN. Il stocke les informations collectées sous forme chiffrée et peut les transmettre.
Talos décrit ces attaques comme historiques. Son analyse du chevauchement d’infrastructures avec le réseau Silent Train de Volt Typhoon n’établit pas que UAT-11473 et Volt Typhoon sont un seul et même acteur.
Le risque plus large lié aux systèmes de gestion apparaît également dans des attaques exploitant une vulnérabilité d’Arista VeloCloud Orchestrator, qui peut transformer un accès limité au portail en contrôle privilégié de l’opérateur. Il s’agit d’une vulnérabilité et d’un incident distincts.
La faille sous-jacente de Cisco dispose déjà de correctifs
Cisco a signalé CVE-2026-20127 pour la première fois en février. Son avis de sécurité attribue une note de 10,0 au contournement de l’authentification et répertorie les logiciels Controller, Manager et Validator concernés.
Un attaquant distant non authentifié peut obtenir des privilèges administratifs. Sur un Controller concerné, cet accès comprend un compte privilégié non root capable de manipuler la configuration SD-WAN via NETCONF.
Cisco a publié des correctifs et indique qu’aucune mesure de contournement ne permet de résoudre la vulnérabilité. Les administrateurs doivent comparer la version installée de chaque composant de contrôle au tableau des logiciels corrigés fourni dans l’avis, et vérifier la compatibilité avant la mise à niveau.
Les mises à jour de sécurité de Cisco Meraki ont leurs propres produits concernés et exigences de firmware. Effectuer une mise à jour Meraki ne permet pas d’établir qu’un contrôleur Catalyst SD-WAN a été corrigé.
Ce que les administrateurs doivent vérifier avant de clore la réponse à l’incident
Cisco recommande d’examiner /var/log/auth.log à la recherche de connexions inattendues par clé publique impliquant le compte vmanage-admin, et de comparer les adresses IP sources aux adresses IP système configurées dans SD-WAN Manager. L’entreprise préconise également de valider les événements d’appairage des connexions de contrôle par rapport aux adresses IP autorisées, aux rôles des appareils, aux fenêtres de maintenance et aux journaux de modifications.
Ces vérifications doivent avoir un responsable et un résultat documenté. Un examen utile doit établir quels composants étaient exposés, quand ils ont été corrigés et si les journaux disponibles couvrent la période précédant la remédiation. Consignez les éléments manquants comme une lacune de visibilité plutôt que de considérer une recherche infructueuse comme une preuve de sécurité.
Conservez les éléments de preuve pertinents avant toute modification lorsque cela est opérationnellement possible. Si un accès suspect apparaît, faites intervenir les équipes de réponse aux incidents et le support de Cisco afin de déterminer l’étendue de la compromission et les étapes de récupération. Évitez d’effectuer des modifications de configuration isolées qui pourraient perturber la connectivité des agences ou brouiller les éléments de preuve.
Les restrictions d’accès méritent un examen distinct. Le guide de renforcement de la sécurité SD-WAN de Cisco recommande de limiter l’accès aux sources approuvées et de séparer les interfaces de gestion de l’infrastructure de transport exposée au public.
Pour une entreprise utilisant un service managé, demandez au fournisseur l’état des correctifs au niveau de chaque composant ainsi que le résultat de ses vérifications visant à détecter une compromission. Une déclaration générale selon laquelle « le réseau est à jour » laisse d’importantes questions sans réponse.
Si une enquête indique que des secrets ont été exposés, coordonnez leur remplacement avec les mesures de confinement et de récupération. La découverte distincte de clés AWS divulguées qui sont restées actives illustre pourquoi la suppression de l’exposition initiale et l’invalidation des identifiants concernés sont deux tâches distinctes. Les identifiants AWS et les clés de chiffrement SD-WAN nécessitent des procédures de récupération différentes.
La réponse doit donc aboutir à deux conclusions : des éléments prouvant que le logiciel vulnérable a été corrigé, et une évaluation visant à déterminer si un accès non autorisé a eu lieu. Une mise à niveau réussie répond à la première question. La seconde nécessite une enquête.
Pour en savoir plus : étendez votre examen de la sécurité réseau à l’infrastructure de commutation en vérifiant cinq vulnérabilités critiques de Cisco Nexus, les configurations concernées et les mesures d’atténuation.