#14.12 Edge Device and Perimeter Appliance Exploitation

Playbook ID: PB-EDGE | Default severity: SEV-2 (escalate to SEV-1 if signs of exploitation are confirmed on any device, if the device held a Tier-0 or domain-privileged credential, if it is a file-transfer appliance holding regulated data, if a firmware or boot-level implant is suspected, or if more than one site in the same product family is affected) | Owner: Operations Lead (Network)

#When to run this

• A CVE affecting a VPN concentrator, firewall, load balancer, secure web gateway, remote-access gateway or managed file-transfer appliance you operate is added to the CISA KEV catalog, or the vendor's PSIRT advisory says exploitation has been observed in the wild.
• CISA issues an Emergency Directive or Binding Operational Directive naming a product family you run — ED 25-03 (Cisco ASA/Firepower, CVE-2025-20333 and CVE-2025-20362) and ED 26-01 (F5 BIG-IP) are the shape of this scenario.
• Your appliance vendor discloses a compromise of their own development environment or product source — the F5 pattern, where UNC5221 held access for at least twelve months and took BIG-IP source code and information on undisclosed vulnerabilities. No customer-side vulnerability to patch, and still your incident.
• Device behavior: an unexplained reboot; a configuration change with no change ticket; a new local administrative account; an SSH listener on a non-standard port; a new entry in the authorized-key store; a gap or reset in the log stream the device ships off-box; a change to the syslog destination itself. T1098 T1556
• Traffic: an outbound session originated by the appliance's own interface addresses to anything that is not the vendor's published update, licensing or telemetry infrastructure. T1071 T1572
• Authentication: a successful VPN session with no corresponding MFA event in the identity provider; authentication against the device's local account database when policy says the IdP; concurrent sessions for one identity from different ASNs. T1078 T1133
• File-transfer appliances: a file appearing in a web-served directory after the last legitimate deployment; requests to paths outside the application's route table; a single account pulling anomalous volume. T1190

Not for: compromise of a general-purpose web server or a custom application — that is Playbook 14.13. Compromise of a SaaS product you consume, or a vendor's platform rather than an appliance in your rack, is 14.5. An OT or ICS field device is 14.14. Routine patching of a vulnerability with no evidence of exploitation belongs to the vulnerability management program in Chapter 10, not here — this playbook starts where that one escalates. If the appliance turns out to be the entry point for domain-wide encryption, run 14.1 in parallel; if the credential taken from it was a domain-privileged account, hand the identity work to 14.4.

#What you are dealing with

An edge appliance is the one computer in your estate you are contractually discouraged from understanding. It ships as a sealed box, the vendor tells you not to install anything on it, the support agreement gets thin if you poke around, and in exchange it terminates every remote session your workforce has. It is a full server with a marketing name, a management interface, a credential store, and no EDR agent. That combination is exactly why it is now the busiest front in the market.

The numbers moved decisively. Verizon's 2026 DBIR puts vulnerability exploitation at 31% of breaches, overtaking credential abuse at 13% for the first time in the report's nineteen-year history (SecurityWeek); Mandiant has exploits as the top initial vector at 32% for the sixth consecutive year, with clusters UNC6201 and UNC5807 specializing in edge and core network devices (M-Trends 2026). CrowdStrike reports a 42% year-over-year rise in zero-days exploited before public disclosure, with 40% of China-nexus exploits targeting edge devices (2026 GTR), and VulnCheck measured 23.43% of KEV entries showing exploitation on or before the day the CVE was published (1H-2026). Meanwhile only 26% of KEV vulnerabilities were fully remediated across 13,000 polled organizations, down from 38%, and median patching time rose to 43 days (Help Net Security).

Read those together and the operating assumption writes itself: for a KEV-listed internet-facing appliance, assume the compromise happened before the patch existed. That is arithmetic, not pessimism, and it is why patching here is a containment step rather than remediation. In the ArcaneDoor campaign behind ED 25-03, Cisco confirmed the actor modified ASA ROM to persist across reboot and upgrade — the update installs cleanly, the version string changes, the implant stays. CISA re-issued guidance in November 2025 because devices reported as patched remained exposed (Help Net Security).

What the adversary wants is rarely the appliance. It is what the appliance holds and sees: the directory bind account, the RADIUS and TACACS+ shared secrets, the IPsec pre-shared keys for every partner tunnel, the certificates and their private keys, and the plaintext of every session after decryption. Salt Typhoon reached 600-plus organizations across 80 countries through provider- and customer-edge routers, persisting with added SSH authorized keys, SSH on non-standard ports, and log clearing (CISA AA25-239A); Volt Typhoon held some victims for at least five years on living-off-the-land technique with minimal malware (CISA AA24-038A). Ransomware crews use the same doors — CISA and the FBI tie Akira's initial access to SonicWall CVE-2024-40766, with proceeds around $244.17M as of late September 2025 (AA24-109A update).

The mistake teams make is trusting the device's own account of itself. You cannot put an agent on it, so your only telemetry is what the box chooses to tell you — and log clearing is standard tradecraft on exactly these devices. If you are not shipping logs somewhere the appliance cannot write, it will report that everything is fine and you will have no way to argue. Actionable takeaway: before this incident happens, confirm every perimeter appliance ships logs off-device to a collector it holds no credentials for, and alarm on the silence. That one control is the difference between an investigation and a shrug.

#Roles for this incident

Marking used below: `TIP-OFF = the adversary can observe this action. EVIDENCE` = this destroys or degrades evidence and must not run before capture.

#Phase 1 — Detection and Triage

Do the first three steps before you log in to the device. Everything you learn from the appliance itself is testimony from a witness who may be working for the other side.

# Step 2 — take the SIEM's copy before you touch the box, hash it, and manifest it.
# The local log is the attacker's to edit. This copy is not.
CASE=IR-2026-0142
OUT=/evidence/$CASE
# The manifest lives beside the tree, never inside it — a manifest that hashes itself
# while it is still being written will never verify again.
MANIFEST=/evidence/$CASE.sha256
mkdir -p "$OUT"
# <your SIEM's export for the device, written into $OUT — e.g. a saved-search export or API pull>
# Timestamp goes in before the manifest, so the manifest actually covers it.
date -u +%Y-%m-%dT%H:%M:%SZ > "$OUT/COLLECTED_AT.txt"
find "$OUT" -type f -print0 | xargs -0 sha256sum > "$MANIFEST"

Verify the manifest with sha256sum -c "$MANIFEST" immediately after collection, before anything else happens to the evidence store, and record the result in the artefact register. An unverified manifest is an assumption wearing a hash's clothes — the first time you check it should not be the day opposing counsel asks.

# Step 3 — record what the appliance originates, from a tap or SPAN upstream of it.
# A device under someone else's control is not a trustworthy sensor for its own traffic.
sudo tcpdump -i <span-interface> -s 0 \
  -w /evidence/$CASE/edge-$(date -u +%Y%m%dT%H%M%SZ).pcap \
  host <appliance-mgmt-ip> or host <appliance-outside-ip>

#Phase 2 — Containment

Sequence is the whole game in this phase. Capture volatile state, then close the management plane, then patch, then rotate credentials, then kill sessions. Patch before capture and you have destroyed the evidence that would have told you whether to replace the hardware. Kill sessions before rotating credentials and you have announced yourself to someone who still holds the keys.

# Step 7 — the appliance's directory bind account, reset twice.
# Microsoft's stated reason for the double reset: to mitigate pass-the-hash risk where
# on-premises password replication is delayed.
Set-ADAccountPassword -Identity <svc-vpn-bind> -Reset `
  -NewPassword (ConvertTo-SecureString -AsPlainText "<random1>" -Force)
Set-ADAccountPassword -Identity <svc-vpn-bind> -Reset `
  -NewPassword (ConvertTo-SecureString -AsPlainText "<random2>" -Force)

# Step 10 — revoke sessions for users who authenticated through the device.
# Revoke-MgUserSignInSession invalidates refresh tokens and browser session cookies by
# resetting signInSessionsValidFromDateTime. It does NOT reach an access token before expiry,
# and it cannot revoke a session token issued by an application.
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
$User = Get-MgUser -Search UserPrincipalName:'jdoe@contoso.com' -ConsistencyLevel eventual
Revoke-MgUserSignInSession -UserId $User.Id

#Phase 3 — Eradication

#Phase 4 — Recovery

#Phase 5 — Post-Incident

#Decision points

#Communications and notification triggers

A vulnerability, by itself, starts no regulatory clock. What starts a clock in this scenario is confirmed unauthorized access to data, and there are two paths to it here. The first is a file-transfer appliance, where the data is on the device — treat that as a data breach until proven otherwise and hand to Playbook 14.7 immediately. The second is downstream: the credentials taken from the device reached a system holding personal or regulated data. Brief the Legal Liaison the moment you can name a specific credential and a specific system it unlocked; do not wait until you can count records.

Two non-regulatory notifications are easy to miss and both are contractual. Partners sharing an IPsec pre-shared key or a certificate with your device must rotate on their side, and that is a notice with an obligation attached. And if the trigger was your vendor's own compromise rather than a vulnerability in your deployment, coordinate any public statement through Playbook 14.5 rather than publishing independently.

#Automation notes

Automate freely. KEV feed ingestion matched against the edge inventory, opening a ticket on a hit, is the highest-value automation in this scenario — the median CVE-to-KEV interval has fallen to 80 days and roughly 200 CVEs reached exploited status within 31 days in the first half of 2026, so a human reading advisories on a Tuesday is not a control. Also: a scheduled external scan for exposed management interfaces; nightly configuration snapshots into version control with an alarm on a non-empty diff; a silence alarm on every appliance's log stream; and the evidence export and hold in Phase 1 steps 2 and 3. All of it gathers; none of it changes anything.

Automate behind a human gate. Closing the management plane and applying an upstream block are strong one-click plays — reversible, scoped, and a false positive costs an administrator an inconvenience rather than an outage. Gate them on a named approver, rate-limit them, and make the automation prove the block with an external test rather than reporting success on an API response.

Never automate. Patching or rebooting an edge appliance, failing over to the HA partner, terminating workforce sessions, credential and PSK rotation, hardware replacement. Each is irreversible, destroys evidence, or scales its blast radius directly with your false-positive rate. The rule that holds: automation may gather, enrich, correlate and recommend without approval; it may act only where the action is reversible, scoped and rate-limited; anything irreversible needs a named human approver and carries the artefact that justified it. Chapter 17 has the gate design.

Actionable takeaway for the small team: the two controls that matter most here cost nothing. A cron job on a management host that exports each appliance's configuration, commits it to git and mails the diff; and a syslog target the appliance can write to but not administer, with an alert when the stream goes quiet. Between them they catch the added SSH key, the changed log destination and the cleared log — most of what Salt Typhoon's persistence actually looks like.

#!/usr/bin/env bash
# Nightly config drift alarm. Runs from a management host, never from the appliance.
# Replace fetch_config with your platform's read-only export (SSH export, HTTPS API, SCP backup).
set -euo pipefail
cd /srv/edge-config
while read -r dev; do
  fetch_config "$dev" > "$dev.conf"
done < devices.txt
git add -A
if ! git diff --cached --quiet; then
  git commit -q -m "edge config drift $(date -u +%Y-%m-%dT%H:%M:%SZ)"
  git --no-pager diff HEAD~1 HEAD | mail -s "EDGE CONFIG DRIFT" soc@example.com
fi

#Pitfalls