Kompromittierte Cisco SD-WAN: KeyDrift zielt auf Schlüssel

Kompromittierte Kontrollsysteme von Cisco Catalyst SD-WAN wurden bei Angriffen mit der maßgeschneiderten Malware KeyDrift zu einem Sammelpunkt für Verschlüsselungsschlüssel, laut Erkenntnissen von Cisco Talos, über die The Hacker News berichtete. Die Angreifer verschafften sich über CVE-2026-20127 Zugang, eine Authentifizierungsumgehung, die im Februar behoben wurde.

Talos beschrieb die Angriffe in seiner Offenlegung vom 28. Oktober als historisch, nannte jedoch keine Vorfallsdaten. Die Ergebnisse dokumentieren Malware, die dafür gebaut wurde, vermutliches Schlüsselmaterial zu sammeln und zu übertragen. Sie belegen jedoch nicht, dass Schlüssel die Angreifer erreichten oder Netzwerkverkehr entschlüsselt wurde.

Schlüssel im Kontrollprozess sammeln

KeyDrift platziert seine Komponente LittleFilch innerhalb von vdaemon, des Controller-Prozesses, der für verschlüsselte Steuerverbindungen zuständig ist. Von dort untersucht LittleFilch Nachrichten nach der Entschlüsselung und wählt für eine vordefinierte Gruppe von Edge-Routern IP-Adressen sowie ein 32-Byte-Feld aus. Talos geht davon aus, dass dieses Feld AES-256-Schlüsselmaterial enthält, das über den Controller verteilt wird.

Der Sammelpunkt entspricht der traditionellen Schlüsselaustausch-Architektur von Cisco. Ciscos technische Dokumentation beschreibt, dass Router für jeden Transport-Standort, bekannt als TLOC, einen AES-Schlüssel erzeugen und ihn in Route-Paketen des Overlay Management Protocol übermitteln. Der Controller verteilt diese Informationen in Erreichbarkeitsankündigungen weiter, damit Router verschlüsselte Datenpfade aufbauen können. AES-Schlüssel werden standardmäßig alle 24 Stunden erneuert, und Steuerungsrichtlinien können einschränken, welche Router die Schlüssel der jeweils anderen erhalten.

Diese Architektur unterscheidet sich von Ciscos Option mit paarweisen Schlüsseln. Bei paarweisen Schlüsseln verteilt der Controller Diffie-Hellman-Public-Values, während Edge-Router ihre IPsec-Schlüssel mit ECDH und einer P-384-Kurve ableiten. Das berichtete Verhalten von LittleFilch betrifft Schlüsselmaterial, das über den traditionellen Austausch läuft. Es belegt nicht, dass aus paarweisen Schlüsseln abgeleitete Schlüssel gesammelt werden.

LittleFilch schützt gesammelte Datensätze mit RSA-Verschlüsselung, bevor es sie in /var/tmp/vdaemon.bin speichert. Eine separate Funktion sendet die Datensätze per UDP an ein Ziel, das in /var/tmp/vdaemon.conf angegeben ist. Die Malware löscht diese Einstellungsdatei nach dem Lesen, und Talos konnte sie nicht wiederherstellen. Ob eine Übertragung stattfand, bleibt ungeklärt.

Wie die Implantate laufen

Die Analyse von Talos, wie The Hacker News berichtet, beschreibt veränderte Dienststart-Skripte als wichtigsten Startmechanismus von KeyDrift. Eine Variante verändert das Run-Skript unter etc/sv/sshd/ so, dass conf_sshd vor dem echten SSH-Server ausgeführt wird. Dieser Loader schreibt die Prozess-IDs von vdaemon nach /tmp/system-vdaemon. Anschließend bringt ein Injector namens rsshd PolyFlame, das Hauptmodul von KeyDrift, in diese Prozesse ein.

PolyFlame arbeitet im Speicher. Seine TinyShell-ähnliche Backdoor unterstützt Befehlsausführung sowie das Lesen und Schreiben von Dateien. Ein Relay-Modus leitet Befehle zwischen einem Befehlsserver und anderen Rechnern weiter. Befehle können innerhalb des SD-WAN-Steuerverkehrs eintreffen. In den analysierten Proben tauchte keine fest codierte Serveradresse auf.

Ein Validator-Implantat geht einen anderen Weg. Ein erfundener Dienst unter /etc/sv/aaamgr/ startet den gepackten Loader aaamgrd, der PolyFlame entschlüsselt und ausführt. Der Unterschied ist für die Erkennung wichtig: Ciscos echte Komponente aaamgr ist ein Python-Paket und läuft normalerweise nicht als kompilierter Dienst. Die berichteten Modulnamen sind libdssl.so für PolyFlame und libcommon.so für LittleFilch.

Talos beobachtete außerdem Befehle, die Zeitstempel und Berechtigungen bestehender Dateien auf von den Angreifern erstellte Dateien übertrugen. Das deutet auf Timestomping hin, mit dem der scheinbare Verlauf der Dateien verändert werden soll.

Die Zugangslücke und verfügbare Korrekturen

Ciscos Sicherheitshinweis nennt eine fehlerhafte Authentifizierung beim Peering als zugrunde liegende Schwachstelle. Manipulierte Anfragen eines nicht authentifizierten Angreifers aus der Ferne können administrative Rechte liefern. Auf einem Controller ist das daraus entstehende interne Konto hoch privilegiert, aber nicht root. Es erlaubt NETCONF-Zugriff und Änderungen an der Konfiguration der SD-WAN-Fabric.

Betroffen sind die Produkte Catalyst SD-WAN Controller, Manager und Validator, früher vSmart, vManage und vBond, unabhängig von der Konfiguration. Der Einsatzbereich umfasst On-Premises-Installationen sowie Cisco Hosted SD-WAN Cloud, einschließlich der Umgebungen Cisco Managed und FedRAMP. Cisco bestätigt eine begrenzte Ausnutzung und empfiehlt ein Upgrade, da kein Workaround die Schwachstelle behebt.

Die versionsspezifischen Korrekturen lauten:

Cisco kennzeichnet Versionen vor 20.9 sowie die Linien 20.11, 20.13, 20.14 und 20.16 als nicht mehr mit Software-Wartung versorgt und rät Kunden, eine unterstützte Version auszuwählen.

On-Premises-Kunden, die auf ein Upgrade warten, empfiehlt Cisco, die Ports 22 und 830 auf bekannte Controller und andere festgelegte Systeme zu beschränken, die Zugriff benötigen. Diese Maßnahme war in einer Testumgebung erfolgreich. Kunden müssen jedoch selbst prüfen, wie wirksam sie in ihren Umgebungen ist und welche möglichen Auswirkungen sie auf Funktion oder Leistung des Netzwerks hat. Cisco sagt, diese Zugriffsbeschränkungen seien in den genannten gehosteten Umgebungen bereits vorhanden. Diese Aussage belegt das Vorhandensein der Beschränkungen, nicht den Patch-Stand jeder gehosteten Instanz.

Erkennung muss auch bestehende Kompromittierung berücksichtigen

Cisco rät, /var/log/auth.log auf Einträge Accepted publickey for vmanage-admin zu prüfen, die zu unbekannten oder nicht autorisierten IP-Adressen gehören. Diese Adressen sollten danach mit den im Manager konfigurierten System-IPs abgeglichen werden. Außerdem ist eine manuelle Prüfung der Peering-Ereignisse der Steuerverbindungen erforderlich, insbesondere bei vmanage-Peers. Maßstab sind erwartete Gerätetypen, Adressen, Wartungsaktivitäten und Authentifizierungsprotokolle.

Bevor Kunden einen Fall beim Technical Assistance Center eröffnen, sollten sie auf jeder Steuerkomponente request admin-tech ausführen. The Hacker News berichtet außerdem, dass Ciscos Behebungsleitfaden empfiehlt, diese Dateien über Check Bug Applicability auf der Seite des Bug Search Tool für CSCws52722 erneut scannen zu lassen.

Für die Netzwerkerkennung führte das Update von Talos vom 28. Oktober die Snort-2-Regeln 67387 bis 67416 und die Snort-3-Regeln 7:44 bis 7:73 für eingehende Command-and-Control-Verbindungen von KeyDrift ein. Die Snort-2-Regeln sind standardmäßig deaktiviert und müssen von Nutzern des kostenpflichtigen Snort-Subscriber-Regelsatzes aktiviert werden. Für die Snort-3-Regeln nennt das Update keinen Standardzustand. Die Regeln 65938 und 65958 decken die Ausnutzung von CVE-2026-20127 selbst ab.

Talos empfiehlt Korrekturen, Ciscos Leitfaden zur Härtung und Incident Response, sobald Anzeichen einer Kompromittierung nach dem Angriff auftreten. Portbeschränkungen entfernen keine bereits installierte Malware. Wie The Hacker News zitiert, warnt Ciscos Behebungsleitfaden vom Februar, dass eine vor einem Upgrade erfolgte Kompromittierung danach bestehen bleiben kann.

Für zivile Behörden der US-Bundesregierung (Federal Civilian Executive Branch) verlangt CISAs Anweisung ED 26-03, am 25. Februar herausgegeben und am 11. März aktualisiert, die sofortige Meldung, sobald eine Kompromittierung des Root-Kontos festgestellt wird. Die Behörden müssen die Steuerungsebene neu aufbauen, indem sie frische Manager-, Controller- und Validator-Instanzen aus gepatchten OVA- oder qcow2-Images bereitstellen und die Edge-Geräte auf diese umstellen.

Überschneidung der Infrastruktur begrenzt die Zuordnung

Talos ordnet die KeyDrift-Aktivität UAT-11473 zu, einem Akteur, der Weltraum- und Satellitendienste, Verteidigungs- und Luftfahrttechnik sowie Policy-Forschung ins Visier nimmt. Laut The Hacker News hält Talos es mit hoher Sicherheit für gegeben, dass sich seine Infrastruktur in erheblichem Maße mit Silent Train überschneidet. Silent Train ist der Name, den Lumen Black Lotus Labs für ein Netz kompromittierter Geräte aus Kleinbüros, Heimnetzen, IoT und Unternehmen verwendet.

Lumen zufolge nutzte Volt Typhoon dieses Netz, um Aktivitäten zu verschleiern. CISA, die NSA und das FBI stuften Volt Typhoon 2024 als von China staatlich unterstützt ein. Die Verbindung über die Infrastruktur bedeutet nicht, dass Talos UAT-11473 als Volt Typhoon identifiziert hat. Talos hat auch nicht erläutert, in welchem Verhältnis UAT-11473 zu UAT-8616 steht. UAT-8616 ist der im Februar beschriebene Ausnutzungscluster, der mindestens bis 2023 zurückreicht.

Separat berichtet The Hacker News, Lumen habe am 28. Oktober erklärt, Volt Typhoon habe CVE-2026-20127 bis Ende 2025 ausgenutzt und die Aktivität nach der Offenlegung im Februar fortgesetzt. Lumen führte KeyDrift nicht auf diese Aktivität zurück.