DE0.10 The Six Attack Chains

2-3 hours · Module 0 · Free

Operational Objective

The Scenario Library: DE0.2 walked CHAIN-HARVEST in detail. DE0.3 walked CHAIN-MESH. This subsection provides the concise operational briefing for all six attack chains — their threat actor model, entry point, MITRE ATT&CK mapping, detection points, and the distinctive detection challenge each presents. These chains are the scenario backbone for the entire course. Every detection rule built in DE3 through DE8 maps to at least one chain, and the capstone (DE11) replays all six against your completed detection library.

Deliverable: Familiarity with all six attack chains, their ATT&CK mapping, and which course modules address each chain's detection requirements.

⏱ Estimated completion: 25 minutes

Attack chain reference

You have already seen CHAIN-HARVEST and CHAIN-MESH in detail (DE0.2 and DE0.3). This subsection summarizes all six chains in operational briefing format — the format your SOC team would use to brief incoming analysts on the threat scenarios relevant to your environment.

Figure DE0.10 — Six attack chains with threat actor model, target, and detection module mapping. Each chain spans multiple modules — detection rules are not isolated to one attack scenario.

CHAIN-PRIVILEGE: Insider PIM abuse

Threat actor: Disgruntled IT administrator (a.patel) — member of Phil Greaves’s IT team. Has legitimate standing access to PIM roles. Motivated by personal grievance.

Entry point: IT admin activates Exchange Admin via PIM (legitimate action). Then exceeds authorized scope by creating an Entra ID app registration with Mail.Read and Files.ReadWrite.All permissions.

The chain: PIM activation (legitimate) → app registration with excessive permissions (abuse) → Graph API access to CEO mailbox (collection) → data exfiltration via the app’s delegated permissions to personal cloud storage (exfiltration) → deletion of sent items to cover tracks (defense evasion).

Distinctive detection challenge: The PIM activation is authorized. Every IT admin on the team activates Exchange Admin periodically for legitimate work. Detection must identify SCOPE CREEP — post-activation actions that exceed the purpose of the activated role. An Exchange Admin who creates a transport rule is normal. An Exchange Admin who creates an app registration with mail permissions is abnormal — app registration is not an Exchange Admin function. The detection correlates PIM activation with post-activation actions, flagging actions outside the role’s expected scope.

Detection modules: DE4 (PIM activation anomaly), DE5 (app registration persistence), DE6 (audit log manipulation), DE7 (mailbox access and exfiltration).

CHAIN-DRIFT: Configuration change exploitation

Threat actor: Opportunistic external attacker — not specifically targeting Northgate. Runs credential sprays against many organizations and exploits whatever gap exists.

Entry point: IT team disables the “require compliant device” conditional access policy for 48 hours during a device migration. The attacker runs a password spray during the CA gap and compromises an account that would normally be blocked by device compliance.

The chain: CA policy disabled (legitimate IT change) → password spray during the gap (exploitation) → account compromise + MFA method registration (persistence) → bulk SharePoint download (collection/exfiltration).

Distinctive detection challenge: The CA policy change is legitimate and authorized. The detection engineer does not prevent the change — that is the security architect’s domain. The detection engineer builds a rule that creates HEIGHTENED ALERTING during the change window: monitor for CA policy modifications (AuditLogs), start a correlation window, and within that window, fire on any credential attack or suspicious sign-in that exploits the reduced controls. The rule answers the question: “Did someone attack us during the window we were exposed?”

Detection modules: DE6 (configuration change monitoring with exploitation correlation), DE4 (password spray during CA gap), DE5 (MFA method registration from suspicious context), DE7 (SharePoint bulk download).

CHAIN-FACTORY: Physical USB compromise

Threat actor: Contractor with physical access to Sheffield manufacturing plant — industrial espionage, possibly state-directed.

Entry point: Contractor plugs USB device into a manufacturing workstation running Defender for Endpoint P1 (sensor-only — limited automated response).

The chain: USB device connection (initial access) → PowerShell execution for reconnaissance (execution/discovery) → directory listing of engineering file shares (discovery) → file copy of CAD/CAM drawings to USB device (collection/exfiltration).

Distinctive detection challenge: Sheffield is a manufacturing plant. USB devices are used legitimately to load CNC programs onto manufacturing equipment. The detection must distinguish between an operator loading a .gcode file onto a CNC machine (legitimate, daily occurrence) and a contractor copying .dwg and .step engineering drawings to a USB device (data theft). File type and path filtering is essential: .dwg, .step, .iges files written to removable media from engineering share paths trigger alerts; .gcode files written to removable media from the CNC program directory do not.

Detection modules: DE3 (USB and removable media initial access), DE5 (PowerShell execution), DE6 (directory enumeration), DE7 (USB file exfiltration with file type filtering).

CHAIN-ENDPOINT: Watering hole to crown jewels

Threat actor: Targeted attacker — likely state-sponsored industrial espionage. The crown jewels (RHEL CAD/CAM rendering farm) contain intellectual property worth millions.

Entry point: Compromised industry forum (watering hole). A CAD engineer (m.thompson) visits the forum, triggering a drive-by download that deploys a fileless Cobalt Strike beacon.

The chain: Drive-by download (initial access) → fileless Cobalt Strike stager via encoded PowerShell (execution) → LSASS credential dump (credential access) → Pass-the-Hash lateral movement to other Windows systems (lateral movement) → LDAP enumeration of admin groups (discovery) → SSH key discovery on engineering workstation (credential access) → pivot to RHEL rendering farm using stolen SSH keys (lateral movement) → bulk read of engineering files (collection) → exfiltration over C2 channel (exfiltration).

Distinctive detection challenge: The attack CROSSES the Microsoft/Linux boundary. The initial 5 phases occur on Windows endpoints monitored by Defender for Endpoint P2. The final 3 phases (SSH pivot, RHEL access, file collection) occur on Linux servers monitored only by Syslog and auditd — no Defender for Endpoint. Detection must span both telemetry stacks, correlated through the compromised user identity (m.thompson). DeviceProcessEvents (Windows) + Syslog (Linux) joined on user entity. This cross-stack correlation is the most advanced detection pattern in the course.

Detection modules: DE3 (drive-by and C2 connection), DE5 (encoded PowerShell execution), DE6 (LDAP enumeration), DE7 (file share access and C2 exfiltration), DE8 (LSASS access, PtH, credential dump, beaconing).

⚠ Compliance Myth: "Physical security is not a detection engineering concern"

The myth: Physical access threats (CHAIN-FACTORY) are handled by physical security controls — badge access, cameras, escort policies. Detection engineering focuses on network and application-layer threats.

The reality: Physical access threats generate digital telemetry. A USB device connection produces DeviceEvents entries. File copies to removable media produce DeviceFileEvents entries. Reconnaissance commands produce DeviceProcessEvents entries. These are all detectable by analytics rules. Physical security controls prevent unauthorized physical access. Detection engineering catches what happens AFTER an authorized person (contractor with a valid badge) misuses their physical access. The two controls are complementary — and in environments like manufacturing where contractors have legitimate physical access, detection engineering is the primary defense against insider physical threats.

Try it yourself

Exercise: Rank the chains by relevance to your environment

For each of the six chains, rate its relevance to your organization on a 1-3 scale: 3 = "this could happen to us," 2 = "possible but less likely," 1 = "not relevant to our environment." Consider: does your organization have manufacturing (CHAIN-FACTORY)? Does it use SD-WAN (CHAIN-MESH)? Does it have crown jewel Linux servers (CHAIN-ENDPOINT)? Does it have PIM-eligible IT admins (CHAIN-PRIVILEGE)? Does it make CA policy changes (CHAIN-DRIFT)? Does it process financial transactions (CHAIN-HARVEST)?

Your highest-rated chains drive your detection backlog priority in DE2.

Check your understanding

CHAIN-ENDPOINT crosses the Windows/Linux boundary. The initial compromise occurs on a Windows workstation monitored by Defender for Endpoint. The attacker pivots to RHEL servers monitored by Syslog only. What shared entity allows cross-stack correlation between the Windows and Linux telemetry?

Answer: The user identity — m.thompson's username. On Windows, the credential dump captures m.thompson's domain credentials and SSH keys. The lateral movement to the RHEL farm uses m.thompson's SSH key. The Syslog authentication log on the RHEL server records the SSH login with m.thompson's username. The detection rule joins DeviceProcessEvents (LSASS access by m.thompson's session on Windows) with Syslog (SSH authentication as m.thompson on RHEL) within a time window. The user identity is the cross-stack correlation key. If the RHEL servers used service accounts rather than personal accounts, this correlation would fail — another reason to enforce personal accounts for interactive access on Linux servers.

Troubleshooting: “These attack chains seem complex — would real attackers actually do this?”

Yes, but simpler. The chains are realistic simplifications of real attack patterns. Real CHAIN-HARVEST attacks happen thousands of times daily — AiTM phishing is the dominant credential theft technique. Real CHAIN-MESH attacks follow the exact ransomware playbook documented by Microsoft’s DART team. Real insider threats follow CHAIN-PRIVILEGE’s scope-creep pattern.

The chains are intentionally multi-phase to demonstrate detection opportunities across the kill chain. In practice, detection at any single phase is sufficient to disrupt the chain. You do not need to detect all 7 phases of CHAIN-MESH — detecting Phase 2 (reconnaissance) is enough to contain the attacker before they reach Sheffield. The course builds rules for every phase because different environments may have different detection capabilities at different phases. Depth of coverage provides resilience.

📋 Operational Artifact — Attack Chain Relevance Matrix

Chain Relevance (1-3) Justification Priority Detection Module
CHAIN-HARVEST ___ ___ DE3, DE4
CHAIN-MESH ___ ___ DE6, DE8
CHAIN-ENDPOINT ___ ___ DE5, DE8
CHAIN-PRIVILEGE ___ ___ DE4, DE5
CHAIN-DRIFT ___ ___ DE6
CHAIN-FACTORY ___ ___ DE3, DE7

Chain	Relevance (1-3)	Justification	Priority Detection Module
CHAIN-HARVEST	___	___	DE3, DE4
CHAIN-MESH	___	___	DE6, DE8
CHAIN-ENDPOINT	___	___	DE5, DE8
CHAIN-PRIVILEGE	___	___	DE4, DE5
CHAIN-DRIFT	___	___	DE6
CHAIN-FACTORY	___	___	DE3, DE7

References used in this subsection

All six attack chain specifications (DETECTION-ENGINEERING-COURSE-BLUEPRINT.md)
Course cross-references: DE0.2 (CHAIN-HARVEST detail), DE0.3 (CHAIN-MESH detail), DE2 (threat modeling with chain prioritization), DE3-DE8 (rule building by detection domain)

Attack chain detection mapping: which rules fire at which phase?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
// ATTACK CHAIN COVERAGE: Map alerts to kill chain phases
SecurityAlert
| where TimeGenerated > ago(30d)
| extend KillChainPhase = case(
    AlertName startswith "DE3", "Initial Access",
    AlertName startswith "DE4", "Credential Access",
    AlertName startswith "DE5", "Persistence/Execution",
    AlertName startswith "DE6", "Discovery/Evasion",
    AlertName startswith "DE7", "Collection/Exfiltration",
    AlertName startswith "DE8", "Lateral Movement/Impact",
    "Other")
| summarize RuleCount = dcount(AlertName), AlertCount = count() by KillChainPhase
| sort by KillChainPhase asc

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.9 The NE Training Universe DE0.11 What This Course Builds →