KeyDrift implants target keys on compromised Cisco SD-WAN

Compromised Cisco Catalyst SD-WAN control systems became a collection point for encryption keys in attacks using custom malware called KeyDrift, according to Cisco Talos findings reported by The Hacker News. The attackers gained access through CVE-2026-20127, an authentication bypass fixed in February.

Talos described the attacks as historical in its October 28 disclosure but gave no incident dates. Its findings document malware built to collect and transmit suspected key material; they do not establish that keys reached the attackers or that network traffic was decrypted.

Collecting keys inside the control process

KeyDrift places its LittleFilch component inside vdaemon, the Controller process responsible for encrypted control connections. From there, LittleFilch examines messages after decryption, selecting IP addresses and a 32-byte field for a predefined set of edge routers. Talos assesses that field to contain AES-256 key material distributed through the Controller.

The collection point corresponds to Cisco’s traditional key-exchange architecture. Cisco’s technical documentation describes routers generating an AES key for each transport location, or TLOC, and submitting it in Overlay Management Protocol route packets. The Controller redistributes that information in reachability advertisements so routers can establish encrypted data paths. AES keys regenerate every 24 hours by default, and control policies can limit which routers receive one another’s keys.

That architecture differs from Cisco’s pairwise-key option. With pairwise keys, the Controller distributes Diffie-Hellman public values, while edge routers derive their IPsec keys using ECDH and a P-384 curve. The reported LittleFilch behavior concerns key material carried through the traditional exchange; it does not demonstrate collection of pairwise-derived keys.

LittleFilch protects its collected records with RSA encryption before saving them to /var/tmp/vdaemon.bin. A separate capability sends the records over UDP to a destination specified in /var/tmp/vdaemon.conf. The malware deletes that settings file after reading it, and Talos could not recover it. Whether transmission occurred remains unresolved.

How the implants run

The Talos analysis, as reported by The Hacker News, describes altered service-startup scripts as KeyDrift’s principal launch mechanism. One variant modifies the run script under etc/sv/sshd/ so that conf_sshd executes before the genuine SSH server. That loader writes vdaemon process IDs into /tmp/system-vdaemon; an injector named rsshd then places PolyFlame, KeyDrift’s main module, into those processes.

PolyFlame operates in memory. Its TinyShell-like backdoor supports command execution and file reads and writes, while a relay mode passes commands between a command server and other machines. Commands can arrive within SD-WAN control traffic. No hardcoded server address appeared in the analyzed samples.

A Validator implant takes a different route. A fabricated service in /etc/sv/aaamgr/ starts the packed loader aaamgrd, which decrypts and executes PolyFlame. The distinction matters for detection: Cisco’s actual aaamgr component is a Python package and does not normally operate as a compiled service. The reported module filenames are libdssl.so for PolyFlame and libcommon.so for LittleFilch.

Talos also observed commands transferring existing files’ timestamps and permissions to attacker-created files, indicating timestomping intended to alter their apparent history.

The access flaw and available fixes

Cisco’s advisory identifies defective peering authentication as the underlying vulnerability. Crafted requests from an unauthenticated remote attacker can yield administrative privileges. On a Controller, the resulting internal account is highly privileged but is not root; it permits NETCONF access and changes to the SD-WAN fabric’s configuration.

The affected products are Catalyst SD-WAN Controller, Manager and Validator, formerly vSmart, vManage and vBond, regardless of configuration. Deployment scope covers on-premises installations and Cisco Hosted SD-WAN Cloud, including Cisco Managed and FedRAMP environments. Cisco acknowledges limited exploitation and recommends upgrading because no workaround resolves the flaw.

Its release-specific fixes are:

Cisco marks releases before 20.9 and trains 20.11, 20.13, 20.14 and 20.16 as having reached end of software maintenance and encourages customers to select a supported release.

For on-premises customers awaiting an upgrade, Cisco recommends restricting ports 22 and 830 to known controllers and other specified systems that require access. This mitigation succeeded in a test environment; customers must assess its effectiveness and possible effects on network functionality or performance in their own deployments. Cisco says these access guardrails already exist in the listed hosted environments. That statement establishes the presence of restrictions, not the patch status of every hosted instance.

Detection must also address existing compromise

Cisco advises checking /var/log/auth.log for Accepted publickey for vmanage-admin entries associated with unknown or unauthorized IP addresses, then comparing those addresses against System IPs configured in Manager. It also requires manual validation of control-connection peering events, particularly vmanage peers, using expected device roles, addresses, maintenance activity and authentication records.

Before opening a Technical Assistance Center case, customers should run request admin-tech on every control component. The Hacker News also reports that Cisco’s remediation guidance recommends rescanning those files through Check Bug Applicability on the Bug Search Tool page for CSCws52722.

For network detection, Talos’s October 28 update introduced Snort 2 rules 67387 through 67416 and Snort 3 rules 7:44 through 7:73 for inbound KeyDrift command-and-control connections. The Snort 2 rules are disabled by default and require activation by paid Snort Subscriber rule-set users; the update specifies no default state for the Snort 3 rules. Rules 65938 and 65958 cover exploitation of CVE-2026-20127 itself.

Talos recommends fixes, Cisco’s hardening guidance and incident response when post-compromise signs appear. Port restrictions do not remove installed malware. As quoted by The Hacker News, Cisco’s February remediation guide warns that exploitation established before an upgrade may persist afterward.

For Federal Civilian Executive Branch agencies, CISA’s ED 26-03, issued February 25 and updated March 11, requires immediate reporting when root-account compromise is identified. Agencies must rebuild the control management plane using fresh Manager, Controller and Validator instances from patched OVA or qcow2 images and migrate edge devices to them.

Infrastructure overlap limits attribution

Talos assigns the KeyDrift activity to UAT-11473, an operator targeting space and satellite services, defense and aerospace technology, and policy research. According to The Hacker News, Talos assesses with high confidence that its infrastructure substantially overlaps Silent Train, Lumen Black Lotus Labs’ name for a network of compromised small-office, home-office, IoT and business devices.

Lumen says Volt Typhoon used that network to conceal activity. CISA, the NSA and the FBI identified Volt Typhoon as Chinese state-sponsored in 2024. The infrastructure connection does not amount to Talos identifying UAT-11473 as Volt Typhoon, and Talos has not explained its relationship to UAT-8616, the exploitation cluster described in February as dating to at least 2023.

Separately, The Hacker News reports that Lumen said on October 28 that Volt Typhoon exploited CVE-2026-20127 by late 2025 and continued after February’s disclosure. Lumen did not attribute KeyDrift to that activity.