One Foothold, Whole Estate: Cisco SD-WAN Manager and Jadepuffer
Both attacks land on the layer every downstream system obeys, so containment has to work before an analyst finishes reading the alert.
These two incidents share a target layer. A branch router applies whatever template SD-WAN Manager pushes. Azure executes a delete call from any identity that holds the right role. Both behaviors are by design. In each case the attacker skips the endpoint and lands on the layer every downstream system trusts by default, so the first malicious action already reaches the whole estate.
| Threat | Authority seized | Blast radius | First containment move |
|---|---|---|---|
| Cisco Catalyst SD-WAN Manager bypass | Admin-level API | Every edge router in the fabric | Restrict GUI and API to an admin jump network; apply Cisco's fix |
| Jadepuffer | Compromised Azure identities | Every subscription those identities can touch | Resource locks plus immutable backups that need a second approver to delete |
SD-WAN Manager: the bypass closes, the accounts stay
SD-WAN Manager is the policy and configuration authority for the entire fabric. Per CSO's analysis, admin API access lets an attacker push templates, change routing and segmentation, create persistent admin users and weaken controls at every branch at once. The ATT&CK mapping is T1190 (exploiting a public-facing application) followed by T1098 (account manipulation for persistence).
The second technique sets the response. The fix closes the bypass. Any admin account or API token the attacker created beforehand survives it. An instance with its GUI or API reachable from the internet or from flat user segments warrants incident handling. The hunt list is short:
- Unrecognized admin accounts.
- New API tokens.
- Template or policy pushes with no change ticket.
- API calls from unfamiliar sources, as far back as log retention allows.
Jadepuffer: familiar kill chain, faster clock
Microsoft describes Jadepuffer as an autonomous agentic attacker. The reporting does not quantify that autonomy. Microsoft's account of initial access is hedged: exposed credentials “may have” been the source. The sequence is familiar. The attacker signs in with a valid cloud account (T1078.004), then destroys data (T1485), likely while also inhibiting recovery (T1490).
The change is the interval between gaining privilege and causing damage. Human destructive crews typically leave minutes to hours there, and alert triage happens inside that interval. An agent compresses it. Containment that waits on an analyst reading an alert lands after the deletes. The controls that hold up make destruction mechanically hard at the point of the call. Visibility alone records the deletes after they happen:
- CanNotDelete locks on production resource groups. A delete call fails even when the caller holds the right role.
- Backups in vaults with soft delete and immutability, plus Resource Guard requiring a separate approver before any backup is removed.
- An Azure Activity Log detection for delete operations from a single caller that exceed baseline in a short window, wired to a SOAR playbook that disables the principal and revokes its sessions with no human in the loop.
The last control carries its own risk. An auto-disable that fires on a legitimate cleanup job is a self-inflicted outage. Known automation identities need a baseline before the playbook is armed.
What is published so far
Neither report included a CVE ID, a CVSS score, an affected-version list or indicators of compromise. Cisco's PSIRT advisory and Microsoft's Jadepuffer guidance are the primary sources for scoping exposure. Both items rest on a single secondhand report. Active exploitation of a management plane still justifies same-day containment while the details catch up.
What to do
Restrict every Cisco Catalyst SD-WAN Manager GUI and API to a dedicated admin jump network today. Apply Cisco's PSIRT fix or mitigation, and send any instance that was reachable from the internet to incident response for a compromise assessment.
This week, apply CanNotDelete locks to production Azure resource groups and enable Resource Guard on backup vaults. Then baseline your known automation identities and arm a single-caller mass-deletion alert that auto-disables the principal through SOAR.