In this section

DE0.7 The Six Attack Chains in Detail

8-10 hours · Module 0 · Free
What you already know

You walked CHAIN-HARVEST phase by phase in Section 6. This section introduces the five remaining attack chains that provide the testing backbone for the 71 detection rules in the course. Each chain represents a realistic multi-phase attack against the organization's specific infrastructure, industry, and threat landscape.

Why the course uses attack chains, not isolated techniques

Detection courses often teach rules technique by technique — detect T1566.002, detect T1078.004, detect T1003.001. That teaches KQL syntax for individual indicators. It doesn't teach how attackers chain techniques into campaigns where each technique depends on the success of the previous one and detection opportunities compound across phases.

The six the organization attack chains model realistic campaigns. Each chain uses four to seven ATT&CK techniques in sequence, crosses multiple data source families, and has detection opportunities at every phase.

When you build a rule for inbox rule persistence in DE5, you understand it's detecting Phase 3 of CHAIN-HARVEST — after token capture in Phase 2, before mailbox reconnaissance in Phase 4. That context shapes the rule's entity mapping (link the inbox rule to the compromised session), severity (high — persistence after confirmed compromise), and response procedure (immediate session revocation and inbox rule removal).

Before walking each chain, check how many of the six your current rules can detect. This KQL counts distinct ATT&CK techniques covered per attack chain:

KQL
// Which attack chain techniques do your rules cover?
SecurityAlert
| where TimeGenerated > ago(90d)
| mv-expand technique = todynamic(ExtendedProperties).["Techniques"]
| where isnotempty(technique)
| summarize CoveredTechniques = make_set(tostring(technique))
| extend
    HARVEST = array_length(set_intersect(CoveredTechniques,
        dynamic(["T1566.002","T1557","T1137.005","T1114.002","T1534"]))),
    MESH = array_length(set_intersect(CoveredTechniques,
        dynamic(["T1078","T1021.002","T1003.001","T1562.001","T1486"])))
Expected Output
HARVEST  MESH
───────  ────
0        1

NE covers zero of five CHAIN-HARVEST techniques and one of five CHAIN-MESH techniques (the T1078 Valid Accounts template rule). An attacker running either campaign traverses the full chain undetected. The single covered technique in CHAIN-MESH fires on the initial VPN authentication — but at Layer 1 quality, with a 60% FP rate from legitimate VPN sign-ins. The SOC closes it without investigation.

Estimated time: 35 minutes.

CHAIN-MESH — compromised VPN → SD-WAN lateral movement → ransomware

A threat actor purchases valid VPN credentials from an initial access broker. The credentials belong to an the organization contractor whose personal device was compromised by an infostealer six months ago — the contractor reused their the organization VPN password on a personal site that suffered a breach.

The credentials have been circulating on dark web marketplaces for three months. The attacker authenticates to the organization's VPN from a residential proxy at 2:14 AM on a Saturday — outside the contractor's normal working hours, from a device fingerprint that doesn't match the contractor's registered endpoint.

From the VPN, they traverse the SD-WAN mesh — three sites (a design office, the headquarters and primary manufacturing facility, and a secondary manufacturing site) connected with flat trust between sites. The SD-WAN architecture was designed for performance and operational simplicity, not for zero-trust segmentation.

The attacker moves from the design office to headquarters by accessing an SMB share on a file server. No exploit needed — the VPN credential grants network-level access, and flat SD-WAN trust means remote site endpoints reach headquarters servers directly. The lateral movement is indistinguishable from a legitimate user accessing a shared drive, except for the time (2:47 AM) and the source (a VPN session that started from an unusual IP).

At headquarters, they deploy Cobalt Strike beacons on two servers using WMI (T1047), dump LSASS memory using comsvcs.dll — the built-in Windows utility that creates a minidump, avoiding Mimikatz which is well-detected by Defender (T1003.001).

They disable Windows Defender real-time protection on the target servers (T1562.001) and delete volume shadow copies to prevent ransomware recovery (T1490). Between 4 AM and 6 AM — while the managed SOC partner is operating with weekend skeleton staff — they deploy ransomware via PsExec across the headquarters and secondary manufacturing systems.

Five phases. Data families: Identity, Endpoint, Infrastructure. Detection modules: DE3, DE4, DE6, DE8.

Eight detection rules. The 24-72 hour window between initial VPN access and ransomware deployment is the detection window this course teaches you to exploit. Every phase in that window generates detectable telemetry — the VPN authentication appears in CommonSecurityLog, the lateral movement appears in DeviceLogonEvents and DeviceNetworkEvents, the credential dumping and defense evasion appear in DeviceProcessEvents. Multiple detection opportunities exist before the ransomware deploys.

CHAIN-ENDPOINT — watering hole → Cobalt Strike → IP theft

A threat actor compromises an engineering standards portal that the organization engineers visit regularly — a legitimate industry site that publishes specifications for defense manufacturing tolerances.

The compromised page contains injected JavaScript that checks the visitor's UserAgent for Windows clients and delivers a browser exploit that downloads a Cobalt Strike beacon disguised as a PDF viewer plugin update (T1189). The beacon is staged on a recently registered domain that mimics a CDN — the kind of domain that web proxies typically whitelist.

The beacon establishes C2 over HTTPS using a malleable profile that mimics legitimate Azure CDN traffic patterns (T1071.001).

Malleable C2 profiles modify the beacon's network behavior — HTTP headers, URI patterns, timing intervals — to resemble legitimate traffic for the domain it impersonates. Without deep packet inspection that examines the payload content (not just the connection metadata), the C2 traffic is indistinguishable from a user browsing an Azure-hosted website.

The attacker discovers engineering file shares through LDAP queries (T1087.002), identifies the CAD/CAM server containing defense contract engineering drawings that are export-controlled under ITAR, uses Pass-the-Hash to access it (T1550.002), stages 2.3 GB of drawings in a compressed archive on a staging server (T1074.001), and exfiltrates over DNS using encoded TXT record queries (T1048.001).

DNS exfiltration encodes data in the subdomain labels of DNS queries — each query carries a small payload (typically under 200 bytes), and the attacker's DNS server reassembles the queries into the original file. The exfiltration is slow but nearly invisible because DNS is allowed outbound in virtually every network and the individual queries are indistinguishable from legitimate DNS lookups without pattern analysis.

Five phases. Data families: Endpoint, Identity, Infrastructure. Detection modules: DE3, DE5, DE6, DE8, DE7.

Seven detection rules. The detection challenge is that the attacker uses legitimate protocols (HTTPS for C2, DNS for exfiltration) and legitimate system tools (LDAP for discovery, PtH for lateral movement). The detection signals are behavioral — process-to-network patterns that legitimate applications don't produce, LDAP query patterns that users don't generate, DNS query patterns with entropy characteristics that legitimate domains don't exhibit.

CHAIN-PRIVILEGE — insider PIM abuse → app registration → exfiltration

A disgruntled the organization administrator with eligible PIM roles activates Global Administrator at 11:47 PM on a Thursday — outside normal business hours, without a corresponding change request in the ITSM system. The administrator has a legitimate reason to hold PIM eligibility — they perform quarterly Entra ID configuration reviews that require Global Admin.

But this activation is not for a scheduled review. Within 15 minutes, they create an app registration with Mail.ReadWrite.All and User.Read.All permissions (T1098.001), consent to the permissions on behalf of the organization (granting the app access to every mailbox in the tenant), and use the service principal to access executive mailboxes programmatically through the Graph API (T1114.002).

The Graph API access is the sophistication in this chain. Instead of forwarding emails (which would trigger the inbox rule template) or accessing OWA (which would generate MailItemsAccessed events under their own user session), the attacker uses the app registration's service principal — a non-human identity — to read mailboxes through the API.

The access appears in the audit logs under the app registration's identity, not the administrator's. If nobody monitors service principal mailbox access, the connection between the administrator's PIM activation and the app registration's data access is invisible.

They download three months of CEO and CFO email — board materials, M&A discussions, salary data, strategic planning documents.

They exfiltrate to a personal OneDrive account using the same browser session (T1537), then deactivate the PIM role and attempt to delete the app registration to remove evidence. The deletion appears in AuditLogs — but it's an app registration deletion, and most organizations don't alert on app registration lifecycle events.

Five phases. Data families: Identity, Cloud Apps. Detection modules: DE4, DE5, DE6, DE7. Five detection rules. Insider threat detection is structurally different from external threat detection.

The attacker has legitimate credentials. Their individual actions are authorized — admins activate PIM roles, admins create app registrations, apps access mailboxes through Graph API. No single action is suspicious in isolation. The detection signal is the sequence (PIM activation → app creation → consent → mailbox access → data transfer → cleanup), the timing (late Thursday night), and the scope (executive mailboxes accessed by a newly created app registration). This chain teaches temporal correlation and behavioral analysis — connecting individually benign events into a suspicious sequence through time-window analysis and entity correlation.

CHAIN-DRIFT — configuration change → exploitation window → compromise

the security architect temporarily disables a Conditional Access policy to troubleshoot a vendor integration. The policy required MFA for all cloud app access. The intention is to re-enable after the vendor completes testing. The vendor's testing runs long. The architect gets pulled into an incident. The CA policy remains disabled for four hours.

A threat actor who obtained a valid credential three months ago through credential stuffing has an automated script that tests authentication every 30 minutes.

At 9:45 AM — 30 minutes after the CA policy was disabled — the script succeeds. The attacker authenticates without MFA (T1078.004), establishes persistence through an OAuth consent grant (T1098.003), and exfiltrates SharePoint data (T1213.002) before the policy is re-enabled at 1:20 PM.

Four phases. Data families: Identity, Cloud Apps. Detection modules: DE6, DE3, DE5, DE7. Four detection rules. Most organizations monitor for configuration changes but not for the exploitation of the windows those changes create. CHAIN-DRIFT teaches temporal correlation between a security configuration change and anomalous activity during the resulting window.

CHAIN-FACTORY — physical access → USB → IP theft

A contractor with physical access to the manufacturing plant connects a personal USB device to an engineering workstation. The USB device contains an autorun executable (T1091) that enumerates local and network file shares (T1135), identifies engineering drawings on a mapped network drive, and copies 847 MB of CAD files and manufacturing process documents to the USB device (T1025).

The entire operation takes 12 minutes. The contractor disconnects the USB and walks out.

Five phases. Data family: Endpoint. Detection modules: DE3, DE6, DE7.

Five detection rules. Manufacturing environments often have USB exemptions for legitimate data transfer — engineering data is frequently too large for email and too sensitive for cloud sharing. The detection rules must distinguish legitimate USB use (contractor copies their own QC reports to a known USB device) from malicious USB use (contractor copies engineering IP from a network share to an unregistered device). The distinction is in scope and access pattern, not in the USB connection itself.

How the chains map to detection modules

Each chain touches multiple modules. Each module addresses multiple chains.

This cross-referencing means a single rule often covers a phase in two or three chains — the inbox rule detection (DE5-001) catches CHAIN-HARVEST Phase 3 and any other chain that uses inbox rule persistence. The credential dumping detection (DE4-005) catches CHAIN-MESH and CHAIN-ENDPOINT. Building 71 rules produces coverage for approximately 36 individual techniques, but those techniques appear across all six chains.

ChainPrimary tacticsData familiesDetection modulesRules
CHAIN-HARVESTInitial Access → Persistence → Collection → BECIdentity, Email, Cloud AppsDE3, DE4, DE5, DE77
CHAIN-MESHInitial Access → Lateral Movement → ImpactIdentity, Endpoint, InfrastructureDE3, DE4, DE6, DE88
CHAIN-ENDPOINTInitial Access → Execution → Collection → ExfiltrationEndpoint, Identity, InfrastructureDE3, DE5, DE6, DE7, DE87
CHAIN-PRIVILEGEPrivilege Escalation → Persistence → CollectionIdentity, Cloud AppsDE4, DE5, DE6, DE75
CHAIN-DRIFTDefense Evasion → Initial Access → PersistenceIdentity, Cloud AppsDE3, DE5, DE6, DE74
CHAIN-FACTORYInitial Access → Discovery → CollectionEndpointDE3, DE6, DE75

The chain-to-module overlap also reveals where you get the most coverage per rule. DE7 (collection and exfiltration) covers phases in five of six chains — exfiltration detection functions as a safety net even when earlier-phase detections are absent.

DE5 (persistence) covers four of six chains. If you had to prioritize a single module for immediate operational value, those two provide the broadest cross-chain coverage.

Scenario

Your organization is a 200-person professional services firm. Cloud-only — no on-premises infrastructure, no manufacturing floor, no USB-accessible workstations. Which of the six attack chains are relevant to your threat landscape? Which can you deprioritize? The answer determines which detection modules deliver the most immediate value for your environment.

Mapping the chains to your environment

Not all six chains are equally relevant to every organization. The relevance depends on your technology stack, your physical infrastructure, your data assets, and your workforce composition.

CHAIN-HARVEST

is relevant to any organization that processes financial transactions through email. The BEC component targets finance teams. If your organization makes supplier payments, processes invoices, or transfers funds based on email instructions, CHAIN-HARVEST is a primary threat.

Manufacturing, professional services, real estate, and financial services are the most targeted industries.

CHAIN-MESH

is relevant to organizations with multi-site network infrastructure — SD-WAN, site-to-site VPN, or any architecture where network trust extends between locations. Manufacturing companies with multiple facilities, companies with regional offices, and organizations with factory or warehouse networks connected to headquarters are the primary targets.

The ransomware deployment phase targets operational disruption — manufacturing lines, warehouse operations, customer-facing services.

CHAIN-ENDPOINT

is relevant to organizations that hold intellectual property or sensitive engineering data.

Defense contractors, technology companies, pharmaceutical companies, and engineering firms face this chain from state-sponsored actors targeting their IP. The DNS exfiltration channel makes this chain particularly persistent — the attacker can exfiltrate data slowly over days without triggering volume-based alerts.

CHAIN-PRIVILEGE

is relevant to any organization with privileged administrators. The insider threat dimension makes it relevant regardless of industry. If you have people with PIM-eligible roles, standing Global Admin access, or the ability to create app registrations with broad permissions, this chain models a realistic insider threat scenario.

CHAIN-DRIFT

is relevant to any organization that makes security configuration changes — which is every organization.

The specific scenario (CA policy disabled for troubleshooting) is universal. The teaching point is broader: any security control that can be temporarily weakened creates a window that a persistent attacker can exploit, and most organizations monitor the change but not the exploitation of the window.

CHAIN-FACTORY

is relevant to organizations with physical locations where contractors or visitors have access to endpoints.

Manufacturing, construction, healthcare, and education environments with shared workstations or contractor-accessible systems face this threat. The USB dimension is often dismissed as a legacy attack vector, but it remains relevant in environments where USB use is permitted for legitimate data transfer.

In the threat modeling module (DE2), you'll formally assess which chains align with your organization's threat landscape and prioritize accordingly. For now, consider which chains resonate with your own environment — the answer informs which detection modules will have the most immediate operational value for you.

Detection Engineering Principle

Attackers chain techniques — they do not use them in isolation. A detection rule that catches one phase of a chain is valuable. Detection rules that cover multiple phases of the same chain provide layered defense — if the attacker evades Phase 2 detection, Phase 3 and Phase 4 rules still catch the campaign. Layered detection across a chain is more resilient than any single rule.

Next

Section 8 introduces the MITRE ATT&CK framework — the common language that detection engineers use to describe what they build, measure what they cover, and communicate with the broader security community.

Unlock the Full Course See Full Course Agenda