DE0.3 CHAIN-MESH: Ransomware Across the SD-WAN

2-3 hours · Module 0 · Free

Operational Objective

The Second Attack Chain: DE0.2 walked CHAIN-HARVEST — an identity and email attack that exploited detection gaps in sign-in analytics and mailbox monitoring. This subsection walks CHAIN-MESH — a ransomware attack that exploits an entirely different gap: lateral movement across the SD-WAN. The same 23 analytics rules. A different attack pattern. The same outcome: zero alerts until impact. Where CHAIN-HARVEST exposed identity detection gaps, CHAIN-MESH exposes endpoint and network detection gaps — particularly the cross-site lateral movement that the SD-WAN mesh enables.

Deliverable: Understanding of how ransomware attack chains exploit lateral movement detection gaps, and the specific cross-site correlation rules that would catch the movement between sites.

⏱ Estimated completion: 25 minutes

The attack begins at the edge

Thursday, 22:47 UTC. An initial access broker sells VPN credentials for j.morrison@northgateeng.com — a field engineer based in Edinburgh — on a dark web marketplace. The credentials were harvested from a third-party breach of a professional networking site where Morrison used the same password. Morrison’s Northgate account has MFA enabled via Microsoft Authenticator push notification. The attacker registers the stolen credentials with a SIM-swapped phone number matching Morrison’s, receives the MFA push, and authenticates to the Prisma Access VPN.

The attacker is now inside the Northgate Engineering network. The VPN connection terminates at the Edinburgh spoke. The SD-WAN mesh provides full connectivity to every other site.

Figure DE0.3 — CHAIN-MESH attack timeline. Seven phases across three sites (Edinburgh → Bristol → Sheffield). First alert fires at Phase 7 — ransomware pre-encryption. By that point, the attacker has domain admin credentials, a local admin backdoor, and encryption has begun.

Why the first six phases were invisible

CHAIN-HARVEST was invisible because of identity and email detection gaps. CHAIN-MESH is invisible because of entirely different gaps: endpoint discovery detection, lateral movement detection, and defense evasion detection. The two chains together expose the full breadth of Northgate’s detection problem — it is not a single gap in one domain, it is systematic absence of detection across multiple domains.

Phase 1 (VPN access) was missed for the same structural reason as CHAIN-HARVEST’s Phase 2: the sign-in came from the same country and the conditional access policy does not require device compliance for VPN connections. The VPN authentication policy was an explicit exception made during the 2022 migration to accommodate field engineers using personal devices. That exception is now an attack surface. Detection requires session-level analysis: this is Morrison’s first VPN connection from this device, at a time outside his normal working pattern (22:47 on a Thursday), from a residential IP he has never used.

Phases 2-3 (discovery and lateral movement) were missed because Northgate has zero analytics rules for reconnaissance commands or RDP anomaly detection. The discovery commands (nltest, net group, systeminfo) are individually legitimate — IT administrators run them routinely. The detection signal is not any single command but the sequence: 5 reconnaissance commands within 15 minutes from a user account (field engineer) that has never run these commands before. The RDP to the domain controller from an Edinburgh field engineer is anomalous — Morrison has never RDP’d to a DC. But no rule establishes per-user RDP baselines.

Phase 4 (DCSync) might generate a Defender for Identity alert — DCSync replication requests from non-DC sources are a known detection pattern. But the alert depends on Defender for Identity’s confidence level and the specific DFI rule configuration. The template pass-through rule in Sentinel would forward the alert if DFI generates one. This is the single potential detection point in the chain — and it is a vendor detection, not a custom rule. If DFI does not fire (which happens with certain DCSync variants that mimic legitimate replication patterns), the entire chain is undetected until Phase 7.

Phases 5-6 (WMI lateral movement and defense evasion) were missed because no rule detects remote WMI execution or Windows Event Log service manipulation. WMI execution is visible in DeviceProcessEvents (wmiprvse.exe spawning child processes on the target server) and DeviceNetworkEvents (DCOM/WinRM connections from the source server). The data is in the workspace. No rule queries it.

Phase 7 (ransomware pre-encryption) is finally detected by a Microsoft template rule for “Potential ransomware activity.” This template fires on vssadmin shadow copy deletion and mass file extension changes. It fires at 01:05 — 2 hours and 18 minutes after initial access. By this point, the attacker has domain admin credentials, a local admin backdoor account, and encryption has begun on the Sheffield ERP server.

⚠ Compliance Myth: "Our ransomware detection rules will catch the attack before damage occurs"

The myth: Ransomware detection rules (shadow copy deletion, mass file modification, ransom note creation) protect against ransomware because they detect the attack.

The reality: Ransomware detection rules detect the IMPACT phase — the last phase of the kill chain. By the time vssadmin deletes shadow copies, the attacker has already completed reconnaissance, lateral movement, privilege escalation, and tool deployment. The “detection” at Phase 7 is not early warning — it is damage notification. The attacker has been in the environment for over 2 hours and has established persistence (local admin account on the DC) that survives the ransomware containment. True ransomware defense means detecting the PRE-encryption phases: the credential compromise (Phase 1), the lateral movement (Phases 3 and 5), and the defense evasion (Phase 6). Each of those phases has a detection opportunity that this course addresses in DE4, DE6, and DE8 respectively.

The cross-site detection challenge

CHAIN-MESH crosses three sites: Edinburgh (entry), Bristol (escalation), Sheffield (impact). Each site hop is visible in the telemetry — DeviceNetworkEvents shows the RDP and WMI connections, DeviceLogonEvents shows the Type 10 (remote interactive) logons, and the firewall CommonSecurityLog shows the inter-site traffic allowed by the SD-WAN policy.

The detection challenge is CORRELATION across sites. Any single hop — Morrison RDP’ing to a Bristol server — might be explainable. Morrison is a field engineer who occasionally needs remote access to Bristol resources. The signal is the CHAIN: VPN login at an unusual time → reconnaissance commands the user has never run → RDP to a DC the user has never accessed → WMI execution on a Sheffield server the user has no business reason to touch → security tool tampering on that server. Each event is ambiguous in isolation. The chain is conclusive.

Building this detection requires multi-entity, time-windowed correlation: join events across UserPrincipalName (the common entity), filter for new device/server access (comparing to a 30-day baseline per user), and sequence the events within a rolling time window. This is the kind of detection that no template provides — and exactly the kind of detection that KQL’s join and make-series operators are built for.

Try it yourself

Exercise: Map your lateral movement detection

Review your Sentinel analytics rules. Do any of them detect: RDP connections to servers the user has never accessed before? WMI remote execution from unexpected source devices? Reconnaissance command sequences from non-IT user accounts? Cross-site connections that traverse site boundaries via SD-WAN or VPN?

If the answer to all four is no, your environment has the same CHAIN-MESH blind spot as Northgate Engineering. Note which of these gaps is most critical for your environment — that informs your detection backlog priority in DE2.

The detection rules that would have caught it

Phase 1 detection (DE4): VPN session anomaly — new device, off-hours connection, residential IP not in user’s baseline. Correlation: SigninLogs VPN event + time-of-day anomaly + device enrollment check.

Phase 2 detection (DE6): Reconnaissance command sequence — 3+ discovery commands (nltest, net group, systeminfo, whoami) from the same user within 15 minutes, where the user has run fewer than 2 of these commands in the past 30 days. This fires within 15 minutes of the attacker’s arrival.

Phase 3 detection (DE8): RDP first-access anomaly — user connects via RDP to a server they have never accessed in the past 90 days, where the server is a domain controller or Tier 0 asset. Immediate high-severity alert.

Phase 5 detection (DE8): WMI remote execution — wmiprvse.exe spawning child processes on a server where the execution was initiated by a remote DCOM/WinRM connection. Cross-server correlation using DeviceProcessEvents and DeviceNetworkEvents.

Phase 6 detection (DE6): Security service manipulation — Windows Event Log service stopped, audit policy modified, or Defender service stop attempted. NRT rule with immediate high-severity alert.

The earliest detection point is Phase 2 — reconnaissance commands at 23:12, 25 minutes after initial access. That detection gives the SOC 1 hour 53 minutes before ransomware encryption begins. Enough time to revoke the session, isolate the compromised device, and reset Morrison’s credentials.

Check your understanding

CHAIN-MESH detects at Phase 7 (ransomware encryption) with a 2-hour-18-minute dwell time. If detection had occurred at Phase 2 (reconnaissance), what is the revised dwell time and what containment actions prevent the remaining phases?

Answer: Revised dwell time: approximately 25 minutes (22:47 VPN access → 23:12 recon detection). Containment: revoke Morrison's Entra ID sessions (Entra ID → Users → Revoke sessions), disable the VPN session in Prisma Access, reset Morrison's password and MFA registration, and isolate the Edinburgh endpoint if identifiable. These actions terminate the attacker's access before Phases 3-7 can execute — no lateral movement, no privilege escalation, no ransomware. The difference between detecting at Phase 2 and detecting at Phase 7 is the difference between a contained credential compromise and an active ransomware incident.

Troubleshooting: “We do not have visibility into our SD-WAN traffic”

If SD-WAN logs are not in Sentinel: Check whether your SD-WAN management platform (Meraki Dashboard, Panorama, Viptela vManage) exposes logs via API or Syslog. Most SD-WAN platforms can forward flow data and policy-match logs to a SIEM. If your SD-WAN logs are not in Sentinel, the cross-site lateral movement in CHAIN-MESH is visible only through endpoint telemetry (DeviceNetworkEvents on the source and target devices). This works for devices with Defender for Endpoint P2 but misses movements to devices with P1 or no EDR — like Northgate’s manufacturing workstations and the Sheffield Server 2016 ERP system.

If you use a flat network with no SD-WAN: The lateral movement detection still applies — RDP and WMI connections between servers are visible in DeviceNetworkEvents and DeviceLogonEvents regardless of the network architecture. The cross-site correlation dimension is absent, but the first-access anomaly detection (user connects to a server they have never accessed) works on any network topology.

📋 Operational Artifact — CHAIN-MESH Detection Gap Analysis

Attack chain: CHAIN-MESH (Ransomware via SD-WAN Lateral Movement)
Phase 1 — VPN compromise: Rule exists? [Y/N] — Fires on this variant? [Y/N] — Gap: ___
Phase 2 — Discovery: Rule exists? [Y/N] — Fires on this variant? [Y/N] — Gap: ___
Phase 3 — RDP lateral (Edinburgh → Bristol): Rule exists? [Y/N] — Gap: ___
Phase 4 — Privilege escalation (DCSync): Rule exists? [Y/N] — Gap: ___
Phase 5 — WMI lateral (Bristol → Sheffield): Rule exists? [Y/N] — Gap: ___
Phase 6 — Defense evasion: Rule exists? [Y/N] — Gap: ___
Phase 7 — Ransomware pre-encryption: Rule exists? [Y/N] — Gap: ___
Earliest possible detection: Phase ___ | Current detection: Phase ___
Dwell time reduction: From ___ hours to ___ minutes

References used in this subsection

CHAIN-MESH attack chain specification (course blueprint)
Course cross-references: DE4 (credential attack detection), DE6 (discovery and evasion detection), DE8 (lateral movement and ransomware detection)

CHAIN-MESH telemetry availability check

1
2
3
4
5
6
// CHAIN-MESH requires cross-site correlation — verify the data sources exist
DeviceLogonEvents | where TimeGenerated > ago(1d) | summarize Count = count() | project Table = "DeviceLogonEvents", Count
| union (DeviceProcessEvents | where TimeGenerated > ago(1d) | summarize Count = count() | project Table = "DeviceProcessEvents", Count)
| union (CommonSecurityLog | where TimeGenerated > ago(1d) | summarize Count = count() | project Table = "CommonSecurityLog", Count)
| union (DeviceFileEvents | where TimeGenerated > ago(1d) | summarize Count = count() | project Table = "DeviceFileEvents", Count)
// CHAIN-MESH crosses 6 data tables — all must be connected for full detection

You're reading the free modules of Detection Engineering

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus

← DE0.2 CHAIN-HARVEST: AiTM to BEC DE0.4 The Detection Engineering Discipline →