KeyDrift Malware Turns Cisco SD-WAN Controllers Into Encryption-Key Harvesters

Attackers have used a maximum-severity flaw in Cisco Catalyst SD-WAN to install a purpose-built implant on the systems that orchestrate an organisation's wide-area network. The malware, tracked as KeyDrift, does not steal documents or credentials. It steals the cryptographic keys that encrypt traffic between branch sites, and it keeps them for later.

What happened

The entry point is CVE-2026-20127, an authentication bypass in the Catalyst SD-WAN control plane rated CVSS 10.0. An unauthenticated remote attacker can skip the login and obtain administrative privileges on the Controller (formerly vSmart), the Manager (formerly vManage) and the Validator (formerly vBond). On a Controller, the attacker lands as a highly privileged internal account that is not root but has more than enough rights to install software.

Cisco shipped fixes in February 2026 and widened the advisory to cover the Validator on 16 June. The vendor acknowledges limited in-the-wild exploitation. The newly documented KeyDrift intrusions are described as historical, and the public analysis does not say exactly when they took place or whether any harvested keys actually left the victim networks.

How KeyDrift works

In a Catalyst SD-WAN deployment, each edge router periodically generates an AES key for its own traffic and sends it to the Controller, which distributes it to the other routers. The process that handles these encrypted control sessions is called vdaemon. KeyDrift lives inside it.

The implant has two main pieces:

• PolyFlame, the core module, is injected into every running vdaemon process and runs entirely in memory. It can act as a lightweight command shell that runs commands and reads or writes files, or as a relay that forwards operator commands to other machines. It receives instructions inside normal SD-WAN control traffic, and the analysed samples carried no hard-coded command server, which makes network-level detection harder.
• LittleFilch hooks vdaemon on a compromised Controller and reads control messages after they have been decrypted. For a preset list of edge routers it extracts each router's IP address and a 32-byte value assessed to be the AES-256 key material the Controller is distributing. It encrypts what it collects with RSA, writes it to disk and can push it over UDP to an address read from a settings file, which it deletes as soon as it has been read.

Persistence is handled by tampering with the runit service scripts the appliances use to start their daemons. In one variant, the script that launches the SSH service first runs a loader called conf_sshd, which records vdaemon's process IDs and hands them to an injector, rsshd, that loads PolyFlame into each process. On a compromised Validator a fake service named aaamgr runs a packed loader that decrypts and starts PolyFlame. The real aaamgr component is a Python package and never runs as a compiled service, so that directory alone is a strong indicator. The operators also copied timestamps and permissions from legitimate files onto their own to blend in.

Who is behind it

The activity is tracked as UAT-11473. Its known targets include space and satellite services, defence and aerospace technology, and policy research organisations. Its infrastructure overlaps considerably with Silent Train, a network of compromised small-office, home-office and IoT devices that the China-linked Volt Typhoon group has used to hide its operations. US agencies publicly attributed Volt Typhoon to the Chinese state in 2024.

That link deserves a caveat. It rests on shared infrastructure, not on shared tooling, and nobody has stated that UAT-11473 and Volt Typhoon are the same group. It is also separate from an earlier exploitation cluster, UAT-8616, tied to this flaw since at least 2023. On top of that, Volt Typhoon itself is reported to have been exploiting CVE-2026-20127 by late 2025 and to have continued after the February disclosure, though that activity has not been tied to KeyDrift.

Why it matters

SD-WAN controllers are the trust anchor of the whole overlay. Whoever holds the keys they distribute can decrypt, and potentially replay or tamper with, traffic between every branch, data centre and cloud on-ramp in the fabric. Because the keys are harvested from decrypted control messages in memory, there is no exploit noise on the wire once the implant is in place. And because KeyDrift stores keys "for later", a compromise discovered today may have exposed traffic captured months ago.

The flaw also affects more than on-premises boxes. Cisco's hosted SD-WAN cloud deployments, including the Managed and FedRAMP environments, are in scope, although Cisco has already applied access guardrails there.

What to do

1. Upgrade to a fixed release. There is no workaround.

The 20.11, 20.13, 20.14 and 20.16 trains, and anything older than 20.9, have reached end of software maintenance, so a train jump is required.

2. Restrict ports 22 and 830 on the control components to the IP addresses of known controllers and management systems until you can upgrade. Cisco validated this in a lab; test it in your own network. Remember that blocking ports does nothing about an implant that is already installed.

3. Hunt for KeyDrift. No hashes, IPs or domains have been published, so the hunt is file- and behaviour-based:

• the runit run script under /etc/sv/sshd/ modified to call conf_sshd;
• a /etc/sv/aaamgr/ directory and an aaamgrd binary on a Validator;
• conf_sshd, rsshd, libdssl.so (PolyFlame) and libcommon.so (LittleFilch);
• /tmp/system-vdaemon, /var/tmp/vdaemon.bin and /var/tmp/vdaemon.conf.

Treat the timestamps on these artefacts with suspicion, since the group is known to timestomp.

4. Check for exploitation of the flaw itself. Review /var/log/auth.log for "Accepted publickey for vmanage-admin" entries from unexpected source IPs. Run request admin-tech on each control component and rescan the output with the Check Bug Applicability feature for bug CSCws52722 before opening a support case.

5. Enable the IDS coverage. Snort 2 rules 67387 through 67416 and Snort 3 rules 7:44 through 7:73 detect inbound KeyDrift command-and-control; rules 65938 and 65958 cover the vulnerability. The new Snort 2 rules ship disabled by default, so turn them on.

6. Plan for eviction, not just patching. Cisco's own remediation guidance warns that exploits already in place can survive an upgrade. If you find any indicator, start incident response, follow the Catalyst SD-WAN hardening guide, and seriously consider the approach CISA imposed on US federal agencies in February: redeploy Manager, Controller and Validator from clean patched images and migrate the edge routers to the new instances. Rotating the site-to-site keys is the conservative assumption, since the implant's whole purpose is to keep copies of them.

Vulnerabilities like this one tend to sit on appliances that nobody scans because they are "network equipment", not servers. Our vulnerability scanning service inventories the management interfaces exposed by your SD-WAN, VPN and firewall control planes and flags unpatched versions and reachable management ports before an attacker with a working exploit finds them first.