On October 28, Cisco Talos disclosed that threat actors exploited a critical vulnerability in Cisco Catalyst SD-WAN — a flaw Cisco patched back in February — to gain access to the systems that control organizations' SD-WAN fabrics and plant a custom implant dubbed KeyDrift. The malware's mission is singular and deeply concerning: it copies the cryptographic keys that encrypt traffic between sites and stages them for later use. Talos characterizes the observed attacks as historical but has not publicly pinned down exactly when the intrusions occurred — which means any organization that delayed applying the February fix needs to assume it may have been exposed during the gap.
Let me be blunt about why this matters more than a typical network-device CVE story. SD-WAN controllers and edge devices sit at the trust root of your wide-area network. The keys KeyDrift targets are what make your site-to-site traffic confidential. An attacker who harvests those keys and retains captured ciphertext can potentially decrypt that traffic later — this is the classic harvest-now, decrypt-later pattern applied at the network fabric layer. Patching today does not undo key material that was already exfiltrated. If your SD-WAN control plane was reachable and unpatched at any point after the vulnerability became known, you have a key-compromise problem, not just a patch-management problem.
This post breaks down what we know, how to hunt for compromise on and around your SD-WAN infrastructure, and how to remediate — including the step too many teams will skip: cryptographic key rotation.
Technical Analysis
What Was Attacked
- Affected platform: Cisco Catalyst SD-WAN (formerly Viptela) — the management, control, and edge components that make up an organization's SD-WAN fabric. The attackers specifically targeted the systems that control the SD-WAN network, which in Catalyst SD-WAN architecture means the management plane (vManage) and control-plane elements.
- The vulnerability: A critical flaw in Cisco Catalyst SD-WAN, patched by Cisco in February 2026. Notably, public reporting of this campaign does not specify a CVE identifier, and we will not guess one. Consult Cisco's security advisory catalog for the February 2026 Catalyst SD-WAN disclosures and map them to your running software train — your TAC representative or the Cisco Security Advisories portal can confirm the exact fixed release for your version.
- The payload — KeyDrift: Custom malware deployed post-exploitation. Its function is to locate and copy the keys used to encrypt inter-site traffic, then store them for later retrieval by the attacker. This implies the actors had sufficient access and dwell time to understand the target's key storage locations — consistent with deliberate, targeted operations rather than opportunistic scanning.
Why Key Theft on the SD-WAN Fabric Is a Strategic Loss
In Catalyst SD-WAN architecture, trust between controllers and edge routers is anchored in certificates and symmetric key material used to protect DTLS/TLS-secured control connections and IPsec-protected data-plane tunnels between sites. An implant that copies this material gives the attacker several durable options:
- Passive decryption: Combined with captured ciphertext (from upstream taps, ISP-level access, or previously collected pcaps), stolen keys enable offline decryption of inter-site traffic.
- Impersonation: Compromised device or controller certificates can allow rogue elements to join the fabric or man-in-the-middle site connections.
- Persistence beyond patching: Once keys are exfiltrated, applying the patch closes the door but leaves the attacker holding copies of everything taken before it closed.
This is why the remediation section below treats key rotation as mandatory, not optional.
Exploitation Status
- Confirmed in-the-wild exploitation: Yes — Talos attributes real intrusions to this activity.
- Timing: Described as "historical," with no disclosed window. Treat any period during which your SD-WAN ran the vulnerable release as potentially exposed.
- Public PoC: None reported as of this writing.
- CISA KEV: Check the CISA Known Exploited Vulnerabilities catalog for the relevant February 2026 Cisco SD-WAN CVE; actively exploited Cisco vulnerabilities are typically added with a federal remediation deadline, which is a useful forcing function for your own change board.
Who Should Worry Most
Organizations that (a) ran a vulnerable Catalyst SD-WAN release at any point after the February patch disclosure, (b) exposed vManage or controller interfaces beyond a tightly restricted management network, or (c) have no telemetry collection from their SD-WAN control plane and therefore cannot establish a clean bill of health. The third group is, frankly, the one that should lose sleep — absence of logs is not absence of compromise.
Detection & Response
This is a technical threat involving network-infrastructure compromise, so below are production-oriented detection and hunting content. A candid caveat from the trenches: network appliances are not Windows endpoints — most detection value here comes from syslog/audit forwarding from the controllers, management-plane access logs, and network telemetry. If you are not already shipping Catalyst SD-WAN logs to your SIEM, that is remediation step zero.
Sigma Rules
The following rules assume SD-WAN controller and management-jump-host telemetry is being collected (Linux syslog from controllers, process creation from jump hosts/admin workstations). They target the post-exploitation behaviors KeyDrift implies: shell activity spawned from management services, access to key/certificate material, and persistence via SSH keys.
---
title: Interactive Shell Spawned by Cisco SD-WAN Management Service
id: 3b7a1e92-6c44-4f1a-9d52-8e0a2b6c7d11
status: experimental
description: Detects an interactive shell spawned by web/application server processes on SD-WAN management systems, consistent with post-exploitation after compromising the management plane (e.g., vManage application server spawning bash/sh).
references:
- https://thehackernews.com/2026/10/hackers-exploited-cisco-sd-wan-flaw-to.html
- https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/30
tags:
- attack.execution
- attack.t1059.004
logsource:
category: process_creation
product: linux
detection:
selection_parent:
ParentImage|contains:
- '/tomcat'
- '/java'
- '/nginx'
- '/httpd'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/python'
- '/python3'
- '/perl'
condition: selection_parent and selection_child
falsepositives:
- Vendor maintenance scripts executed during upgrades — baseline against change windows
level: high
---
title: Encryption Key or Certificate Material Access on Network Infrastructure Host
id: 9f2c5d81-3a7b-4e60-b8f1-2d6c9a4e5b33
status: experimental
description: Detects interactive reading, copying, or archiving of private key and certificate material on Linux-based network infrastructure hosts, matching KeyDrift's collection of SD-WAN traffic encryption keys.
references:
- https://thehackernews.com/2026/10/hackers-exploited-cisco-sd-wan-flaw-to.html
- https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/10/30
tags:
- attack.credential_access
- attack.t1552.004
- attack.collection
- attack.t1560
logsource:
category: process_creation
product: linux
detection:
selection_paths:
CommandLine|contains:
- '.key'
- '.pem'
- 'id_rsa'
- '/etc/ssl/private'
- 'certificate'
selection_tools:
CommandLine|contains:
- 'cat '
- 'cp '
- 'tar '
- 'gzip '
- 'zip '
- 'openssl '
- 'scp '
- 'base64'
- 'xxd'
condition: selection_paths and selection_tools
falsepositives:
- Legitimate certificate renewal and backup jobs — scope to authorized automation accounts and windows
level: high
---
title: SSH Authorized Keys Modification on Infrastructure Hosts
id: 5e1d8a47-2b63-4c90-af76-1b9d3e5c8a22
status: experimental
description: Detects writes to SSH authorized_keys files on Linux infrastructure hosts, a common persistence mechanism after network appliance or controller compromise.
references:
- https://thehackernews.com/2026/10/hackers-exploited-cisco-sd-wan-flaw-to.html
- https://attack.mitre.org/techniques/T1098/
author: Security Arsenal
date: 2026/10/30
tags:
- attack.persistence
- attack.t1098.004
logsource:
category: file_event
product: linux
detection:
selection:
TargetFilename|endswith:
- 'authorized_keys'
- 'authorized_keys2'
falsepositives:
- Configuration management (Ansible, Puppet) key distribution — filter known automation sources
level: medium
KQL — Microsoft Sentinel / Defender Hunt
This query hunts Syslog and CommonSecurityLog (CEF) ingestion from Cisco SD-WAN controllers for the access and command patterns consistent with control-plane compromise and key collection. Run it across the full window since the February patch release if you have retention.
let Lookback = 270d;
let SuspiciousCmds = dynamic([".key", ".pem", "authorized_keys", "cat /etc", "tar ", "scp ", "openssl", "base64", "wget ", "curl ", "chmod +x", "/tmp/", "id_rsa", "private"]);
union isfuzzy=true
(Syslog
| where TimeGenerated > ago(Lookback)
| where Computer has_any ("vmanage", "vsmart", "vbond", "vedge", "cedge", "sdwan")
or HostName has_any ("vmanage", "vsmart", "vbond", "cedge", "sdwan")
| extend Msg = tostring(SyslogMessage)
| where Msg has_any (SuspiciousCmds)
or (Msg has "session opened" and Msg has "root")
or (Msg has "Accepted password" or Msg has "Accepted publickey")
| project TimeGenerated, Computer, HostName, Facility, SeverityLevel, ProcessName, Msg
),
(CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where DeviceVendor =~ "Cisco"
| where DeviceProduct has_any ("SD-WAN", "vManage", "Catalyst")
| where Message has_any (SuspiciousCmds)
or (Activity has_any ("login", "authentication") and Outcome !has "success" == false)
| project TimeGenerated, DeviceName, SourceIP, SourceUserName, Activity, Message, DestinationHostName
)
| sort by TimeGenerated desc
A second, higher-signal hunt: baseline which source IPs authenticate to your management plane, then alert on anything new. vManage access should come from a handful of known admin hosts and nothing else.
let Lookback = 90d;
let KnownAdminSources =
Syslog
| where TimeGenerated between (ago(Lookback) .. ago(7d))
| where SyslogMessage has "Accepted" and (Computer has "vmanage" or HostName has "vmanage")
| extend SourceIP = extract(@"Accepted \S+ for \S+ from ([0-9a-fA-F\.\:]+)", 1, SyslogMessage)
| where isnotempty(SourceIP)
| summarize by SourceIP;
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has "Accepted" and (Computer has "vmanage" or HostName has "vmanage")
| extend SourceIP = extract(@"Accepted \S+ for \S+ from ([0-9a-fA-F\.\:]+)", 1, SyslogMessage)
| where isnotempty(SourceIP)
| where SourceIP !in (KnownAdminSources)
| project TimeGenerated, Computer, SourceIP, SyslogMessage
| sort by TimeGenerated desc
Velociraptor VQL
For teams running Velociraptor on Linux management hosts, jump boxes, or any x86-based controller where an agent can be deployed, this artifact sweeps for the persistence and collection artifacts KeyDrift-style implants leave behind: rogue SSH keys, recent crontab changes, and unexpected binaries in temp paths.
-- KeyDrift post-exploitation sweep: rogue SSH keys, cron persistence, temp-path binaries
SELECT * FROM foreach(
row={
SELECT FullPath AS ArtifactPath, "ssh_key" AS ArtifactType
FROM glob(globs=["/root/.ssh/authorized_keys", "/home/*/.ssh/authorized_keys"])
},
query={
SELECT ArtifactPath, ArtifactType,
read_file(filename=ArtifactPath, length=4096) AS ContentSample
FROM scope()
})
UNION ALL
SELECT FullPath AS ArtifactPath, "cron_persistence" AS ArtifactType,
read_file(filename=FullPath, length=4096) AS ContentSample
FROM glob(globs=["/etc/cron.d/*", "/var/spool/cron/*", "/etc/crontab"])
UNION ALL
SELECT FullPath AS ArtifactPath, "temp_executable" AS ArtifactType,
"" AS ContentSample
FROM glob(globs=["/tmp/*", "/var/tmp/*", "/dev/shm/*"])
WHERE NOT IsDir
AND FullPath !~ "systemd-private"
Also pull netstat on management hosts to catch implants holding outbound connections — key staging implies exfiltration at some point:
-- Outbound connections from processes on management hosts, excluding expected services
SELECT Pid, Name AS ProcessName, Family, Type, Status,
Laddr, Lport, Raddr, Rport
FROM netstat()
WHERE Status =~ "ESTABLISHED"
AND Rport NOT IN (22, 443, 123, 53, 830, 514, 6514)
AND NOT Raddr =~ "^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)"
ORDER BY Pid
Tune the RFC1918 exclusion to your environment — the point is that a controller process holding an established session to a public IP on an unusual port deserves immediate scrutiny.
Remediation and Audit Script
The following Bash script performs a triage sweep on a Linux-based management host or jump box with reachability to your SD-WAN environment. It does not patch (that happens through your normal Cisco software upgrade process), but it verifies exposure window artifacts and collects evidence for IR.
#!/usr/bin/env bash
# keydrift_triage.sh — Audit SD-WAN management infrastructure for compromise indicators
# Run as root on management hosts / jump boxes. Output goes to a timestamped evidence bundle.
EVID="/var/tmp/sdwan_triage_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$EVID" && chmod 700 "$EVID"
echo "=== [1] Authentication anomalies: SSH logins to management plane ==="
grep -E "Accepted (password|publickey)" /var/log/auth.log /var/log/secure 2>/dev/null \
| grep -vE "from (10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)" \
> "$EVID/ssh_external_logins.txt"
echo "=== [2] Root sessions and privilege escalation ==="
grep -E "session opened for user root|sudo:" /var/log/auth.log /var/log/secure 2>/dev/null \
> "$EVID/root_sessions.txt"
echo "=== [3] SSH authorized_keys integrity ==="
find /root/.ssh /home/*/.ssh -name "authorized_keys*" -exec ls -la {} \; \
> "$EVID/authorized_keys_listing.txt" 2>/dev/null
find /root/.ssh /home/*/.ssh -name "authorized_keys*" -newermt "2026-02-01" \
> "$EVID/authorized_keys_modified_since_patch.txt" 2>/dev/null
echo "=== [4] Cron persistence ==="
cat /etc/crontab /etc/cron.d/* /var/spool/cron/* 2>/dev/null > "$EVID/cron_all.txt"
echo "=== [5] Executables in temp/transient paths ==="
find /tmp /var/tmp /dev/shm -type f -executable 2>/dev/null > "$EVID/tmp_executables.txt"
echo "=== [6] Key/cert material touched since February patch window ==="
find / -xdev \( -name "*.key" -o -name "*.pem" -o -name "*.p12" -o -name "id_rsa*" \) \
-newermt "2026-02-01" 2>/dev/null > "$EVID/key_material_recent.txt"
echo "=== [7] Processes spawned by web/app servers ==="
ps auxf | grep -E "(tomcat|java|nginx|httpd)" > "$EVID/web_service_tree.txt"
echo "=== [8] Established outbound connections (non-standard) ==="
ss -tnp state established 2>/dev/null > "$EVID/established_connections.txt"
echo "=== [9] Command history review ==="
for h in /root/.bash_history /home/*/.bash_history; do
[ -f "$h" ] && grep -E "(cat .*\.(key|pem)|scp |curl |wget |base64|openssl)" "$h" \
>> "$EVID/suspicious_history.txt" 2>/dev/null
done
echo "=== [10] Baseline package/binary integrity spot check ==="
find /usr/local/bin /opt -type f -newermt "2026-02-01" 2>/dev/null \
> "$EVID/new_binaries_since_feb.txt"
tar czf "${EVID}.tar.gz" -C /var/tmp "$(basename "$EVID")"
echo "Evidence bundle: ${EVID}.tar.gz"
echo "Review authorized_keys_modified_since_patch.txt and key_material_recent.txt FIRST."
Two findings in that bundle warrant immediate escalation to full IR: authorized_keys modified after the patch window by anything other than your config-management system, and private key material accessed or modified outside documented maintenance. Either one converts this from "patch and verify" to "declare an incident."
Remediation
Work through this in order. Do not stop at step one.
1. Confirm and apply the fixed software release. The flaw was patched in Cisco's February 2026 Catalyst SD-WAN security release cycle. Because the public reporting does not name a CVE, open the Cisco Security Advisories portal (https://sec.cloudapps.cisco.com/security/center/publicationListing.x), filter to Catalyst SD-WAN / vManage for February 2026, and map the disclosed vulnerabilities to your software train. If there is any ambiguity about which fixed release closes the exploited flaw, open a TAC case — do not guess. Check the CISA KEV catalog as well; if the relevant CVE is listed, the federal remediation deadline gives you executive air cover for an emergency change.
2. Audit the exposure window. Pull every controller and management-plane log you have covering the period from the patch release date (and ideally earlier — Talos has not disclosed when the intrusions began) through the date you actually patched. You are looking for the behaviors in the detection section above: anomalous logins to the management plane, shells under application services, key/cert file access, and unexpected outbound connections. If your SD-WAN controllers do not forward logs to a SIEM, enable remote syslog now — Cisco documents this for vManage and the controller elements — and accept that your historical visibility is limited, which itself is a finding to report upward.
3. Rotate the cryptographic material — this is not optional. If there is any chance your fabric was exposed while vulnerable, treat the inter-site encryption keys and device/controller certificates as compromised. Work with Cisco TAC on the supported procedure for certificate and key rotation across the Catalyst SD-WAN fabric (controller root certs, edge device certificates, and IPsec key material). Yes, this is operationally disruptive and requires careful sequencing to avoid dropping sites. The alternative is that an attacker retains the ability to decrypt traffic they captured months ago — and anything new they can still observe — indefinitely.
4. Lock down management-plane reachability. vManage and the controller elements should be reachable only from dedicated management networks and hardened jump hosts, never from general user segments or the internet. Enforce MFA and certificate-based admin authentication where supported, and alert on any new source IP authenticating to the management plane (the second KQL query above).
5. Hunt for persistence before declaring clean. KeyDrift was planted after exploitation, which means the actors wanted to stay. A patched device with the attacker's cron job or SSH key still in place is still compromised. Use the triage script and VQL artifacts above, and for any host with suspicious findings, rebuild from known-good media rather than attempting surgical cleanup on network infrastructure.
6. Review what traversed the wire. If keys were likely exfiltrated, assess what sensitive data crossed the affected site-to-site tunnels during the exposure window. Depending on your sector, this may trigger regulatory notification obligations (PCI-DSS key-compromise procedures, HIPAA breach analysis, etc.). Loop in legal and compliance early, not after forensics concludes.
7. Institutionalize the lesson. Network infrastructure telemetry belongs in your SIEM alongside endpoint and identity data. The organizations that can answer "were we hit?" in hours instead of "we don't know, the device doesn't log anywhere" are the ones that contain these campaigns cheaply. If your team lacks the cycles to build and maintain this coverage, that is exactly the gap a managed detection partner exists to close.
Related Resources
Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.