Cisco Talos details KeyDrift malware designed to collect encryption keys

Cisco Talos said on October 28, 2026, that attackers exploited a critical Cisco Catalyst SD-WAN vulnerability to install KeyDrift, malware designed to collect the keys that protect traffic between sites and maintain backdoor access. The findings give network operators specific signs to check for, including on systems already upgraded to fixed software.

Cisco disclosed and fixed the vulnerability, CVE-2026-20127, in February. At that time, Talos described exploitation tracked as UAT-8616 going back to at least 2023. The October findings, covered by The Hacker News, concern historical attacks by a group Talos tracks as UAT-11473; Talos has not specified when those attacks occurred.

The flaw lets a remote attacker bypass login checks without credentials and gain administrative privileges. It has a severity score of 10.0 out of 10 on the Common Vulnerability Scoring System. On a Controller, the access is through a highly privileged internal account, not the root account with full system privileges. Cisco says it is aware of limited exploitation.

How Talos says LittleFilch collects key material

Cisco’s software-defined wide-area networking system connects sites through edge routers. In its traditional key exchange, each router periodically generates an AES encryption key for its traffic and sends it to the Controller, which distributes it to other routers. A Controller process called vdaemon handles the encrypted control connections carrying those keys.

Talos found that KeyDrift’s LittleFilch component intercepts the SSL_read function inside vdaemon, allowing it to inspect control messages after decryption. For a predefined list of edge routers, LittleFilch extracts public or transport IP addresses, internal system IP addresses and a 32-byte field. Talos assesses that field as AES-256 IPsec key material used to encrypt traffic between routers.

LittleFilch encrypts its records using RSA and stores them in /var/tmp/vdaemon.bin. It can send the encrypted records over UDP, using a format resembling DTLS 1.2 encrypted application traffic. It reads local and remote network addresses and ports from /var/tmp/vdaemon.conf, then deletes that file. Talos could not recover the configuration and did not establish whether collected keys were transmitted.

What operators can look for

KeyDrift starts through altered runit scripts, which launch device services. In one deployment, the SSH service launcher starts conf_sshd before the legitimate server. That script lists vdaemon process IDs, and rsshd injects PolyFlame into those processes. On an affected Validator, a fake aaamgr service starts aaamgrd, a loader that decrypts and runs PolyFlame. Cisco’s legitimate aaamgr is a Python package, not normally a compiled service.

Talos says PolyFlame runs in memory and can execute commands, read and write files, or relay commands between an attacker-controlled server and other machines. Its backdoor does not provide an interactive shell. It accepts instructions through SD-WAN control traffic; the analyzed samples contained no fixed external server address. Talos also observed commands copying existing files' timestamps and permissions onto attacker files, which can make malicious files less conspicuous.

Talos released KeyDrift detection rules 67387–67416 for Snort 2 and 7:44–7:73 for Snort 3 on October 28. Existing rules 65938 and 65958 cover the vulnerability itself. The October update lists the Snort 2 rules as disabled by default, so Subscriber-rule users must enable them.

Talos assesses infrastructure overlap, not a shared group identity

Talos says UAT-11473 has targeted space and satellite services, defense and aerospace technology, and policy research. It assesses with high confidence that the group’s operating infrastructure overlaps considerably with Silent Train, a network of compromised office, home and connected devices that Lumen says Volt Typhoon used to hide its activity.

Talos has not identified UAT-11473 as Volt Typhoon or explained its relationship to UAT-8616. Separately, Lumen said on October 28 that Volt Typhoon exploited CVE-2026-20127 by late 2025 and continued after Cisco’s February disclosure. Lumen did not connect that activity to KeyDrift.

Fix the vulnerability and assess any existing compromise

The vulnerability affects Controller, Manager and Validator systems, formerly called vSmart, vManage and vBond, regardless of configuration. It covers on-premises installations and Cisco-hosted deployments, including Cisco Managed and FedRAMP environments. Cisco added Validator to the advisory on June 16.

The Hacker News lists 20.12.6.1 for the 20.11 release train instead. Releases earlier than 20.9 and the 20.11, 20.13, 20.14 and 20.16 trains have reached the end of software maintenance and require migration to fixed releases.

Cisco says there is no workaround. Until an upgrade, on-premises operators can restrict ports 22 and 830 to known controllers and other known systems. Cisco says this worked in a test environment but asks customers to check its effectiveness in their networks. Hosted controllers already block external access on these ports by default; hosted customers should still review their allowed inbound management rules and retain only necessary network ranges. These rules govern management access only and do not apply to edge routers.

Neither port restrictions nor an upgrade should be treated as proof that an existing compromise has been removed. Cisco warns that earlier compromises can remain after patching. Its guidance does not specify whether upgrading removes KeyDrift or whether potentially exposed keys should be replaced.

Cisco’s next step is to collect diagnostic bundles using request admin-tech from every Controller, Manager and Validator before opening a Technical Assistance Center (TAC) case. Select Log and Tech; Core is not required. Collect Controller bundles one at a time, then upload all bundles for assessment. Cisco also recommends rescanning control-component bundles against bug CSCws52722 through its Check Bug Applicability feature, including after an earlier upgrade.

Preliminary checks include /var/log/auth.log entries reading “Accepted publickey for vmanage-admin” from unexpected addresses and unfamiliar peers in controller syslogs. Administrators should validate addresses against their own infrastructure and send suspicious entries, timestamps, addresses and peer details to TAC.

Cisco directs customers to wait for TAC’s assessment before remediation. If TAC finds no compromise indicators, customers should upgrade every control component to fixed software. If indicators are present, customers should follow the environment-specific process provided by TAC and Cisco’s security response team. Talos also urges organizations that detect unauthorized activity to activate incident response.