The malware on these SD-WAN controllers was not after files. It was after the keys that encrypt the traffic between branches

Cisco Talos published an analysis on 28 October of a malware framework it calls KeyDrift, found on Cisco Catalyst SD-WAN controllers. The actor, which Talos tracks as UAT-11473 and calls a "highly sophisticated advanced persistent threat (APT) actor", got in through CVE-2026-20127, an authentication bypass in the controller.

That flaw is not news. Cisco patched it in February, and it went on CISA's catalogue on 25 February with a due date of the 27th. What is news is what was built on top of it.

What it takes

The collection module is called LittleFilch, and it hooks SSL_read inside vdaemon, the SD-WAN control daemon, where control-plane traffic has already been decrypted. From each buffer it keeps 3 fields: the vEdge public or transport address, the peer system address, and a 32-byte binary key field.

That last one is the point of the whole operation. Talos assesses it to be OMP-distributed AES-256 IPsec data-plane key material, which is the keying that protects traffic between SD-WAN edges. The records are RSA-encrypted into a file under /var/tmp and can be sent out over UDP shaped like a DTLS 1.2 record, so the exfiltration looks like the protocol the device already speaks. The module's own configuration file is deleted once it has been read.

Why keys rather than documents

Stealing files takes what exists on the box today. Stealing the keying that protects a network's traffic is a different proposition: it is an option on everything that crosses those tunnels afterwards, readable somewhere else, by somebody who no longer needs to be inside.

Hold the claim where Talos holds it. The identification of that 32-byte field is an assessment rather than a confirmed finding, and the report does not demonstrate bulk decryption of captured traffic or say whether any keys left any network. What it establishes is intent: a module written to find exactly that field and nothing else around it.

The command channel rides the control plane

The backdoor module, PolyFlame, arrives as libdssl.so and is injected into running vdaemon processes by a ptrace-based injector the authors named rsshd. Inside, it hooks 3 families of call, socket, DTLS and dynamic linker, which hands it the daemon's own view: DTLS session keys, vEdge topology, OMP routes and policy tables.

It is a TinyShell-style backdoor for running commands and reading or writing files, and it also relays commands to other peers, making a compromised controller an intermediate C2 for the rest. Talos describes it as built for "in-band control or tasking" over SD-WAN control-plane traffic rather than a conventional beacon.

Which is why the usual hunt comes up empty. Talos lists 6 things it could not recover from the samples: hardcoded addresses, binding ports, callback domains, URLs, host headers and polling intervals. There is nothing for a netflow query or a DNS log to catch, because the traffic that carries the tasking is the traffic the device is supposed to be sending.

Persistence in the places nobody reads

KeyDrift anchors itself in the controller's runit service paths, under 2 names you would never question, sshd and aaamgr, with modified run scripts starting the injection chain. One variant, aaamgrd, is a packed PolyFlame that masquerades as the aaamgr service, uses direct syscalls, carries an RC4-encrypted payload and checks TracerPid to see whether it is being debugged.

On one vBond appliance Talos also found timestomping and tampering with the PAM configuration, which is the part that should worry anyone planning to investigate rather than reimage.

Attribution, stated the way Talos states it

Talos assesses "with high confidence" that UAT-11473's infrastructure "overlaps considerably with" the covert access network known as Silent Train, associated with Volt Typhoon. That is an overlap of infrastructure, not a statement that the two are the same operator, and the report does not make the larger claim.

The observed targeting is space and satellite services, defence and aerospace technology, and policy research. Those are not sectors anybody robs for money.

What to do

• Patch CVE-2026-20127 if it is somehow still outstanding. It has been fixed since February and listed as exploited since the 25th of that month.
• Deploy the detection Talos published: Snort SIDs 65938 and 65958 for the vulnerability, and 67387 to 67416 on Snort 2 with 7:44 to 7:73 on Snort 3 for the malware.
• Read your runit run scripts. The persistence is in service definitions named after services you expect to see.
• Look for libdssl.so and libcommon.so loaded into vdaemon, an aaamgrd process, and files under /var/tmp that nothing should have written.
• Assume the keys are burned. Ask Cisco what forcing a rotation of data-plane keying involves on your version, because Talos does not say whether rotation puts the stolen material beyond use.
• Treat a compromised controller as a transit node for other victims, not only as your own problem.

What is not established

• Whether any stolen key material ever left a victim network. Talos does not say.
• How many organisations were affected, or over what period. The report describes historical activity without giving campaign dates.
• Whether the 32-byte field is what Talos assesses it to be. That is an assessment.
• How the command format works. Talos calls it unresolved, and the configuration file it would have explained was not recovered.
• Whether UAT-11473 is Volt Typhoon, a tenant of the same infrastructure, or something else. Overlap is what the report claims.
• What else the framework can do. Talos notes the observed variations "suggest active development", which is a way of saying this is a moving target.