DE0.2 CHAIN-HARVEST: AiTM to BEC

CHAIN-HARVEST: the attack

Monday, 09:14 UTC. Sarah Chen (s.chen@northgateeng.com), Finance Analyst at Northgate Engineering’s Bristol headquarters, receives an email. The sender appears to be DocuSign — a service Northgate uses routinely for contract signatures with manufacturing clients. The email contains a link to review and sign a purchase order from a known supplier.

The email passed Defender for Office 365 scanning. Safe Links evaluated the URL at delivery time — it pointed to a legitimate-looking landing page hosted on a compromised WordPress site. Safe Attachments found no attachment to detonate. The anti-phishing policy checked the sender domain against impersonation protection lists — the sender was not impersonating a Northgate executive, it was impersonating DocuSign, which is not in the impersonation protection scope. The email landed in Sarah’s inbox with no warnings.

Sarah clicked the link. The landing page redirected through two intermediary domains to an EvilProxy reverse proxy presenting a pixel-perfect Microsoft sign-in page. Sarah entered her credentials and completed the MFA push notification on her Authenticator app. She believed she was signing into Microsoft 365 to access the DocuSign document. She was. But the EvilProxy proxy sat between her browser and Microsoft’s authentication endpoint, capturing the session token issued after successful MFA.

The attacker now holds Sarah’s valid session token. No password was stolen — the session token bypasses both the password and MFA for its remaining lifetime.

Figure DE0.2 — CHAIN-HARVEST attack timeline mapped against Northgate Engineering's 23 analytics rules. Every phase generates telemetry. No rule fires.

Phase-by-phase: why each detection failed

Phase 1 — Phishing email. Northgate has one template rule for phishing: “Phishing email detected by Microsoft Defender for Office 365.” This is a pass-through rule — it creates a Sentinel incident when Defender for Office 365 flags an email as phishing. If Defender does not flag it, the rule does not fire. The rule does not independently analyze EmailEvents or EmailUrlInfo. It depends entirely on Defender’s verdict. Defender’s verdict was “clean” because the URL pointed to a compromised legitimate site that was not yet in Microsoft’s threat intelligence feeds. A detection engineer would build a rule that queries EmailUrlInfo for URL patterns associated with AiTM proxy infrastructure — newly registered domains, specific URL path structures, redirect chains — independent of Defender’s verdict.

Phase 2 — Credential capture via AiTM. Northgate has two identity rules: impossible travel and risky sign-in. The impossible travel rule did not fire because the attacker used a residential proxy IP in the same country as Sarah — London, 120 miles from Bristol. The sign-in appeared as a normal remote access event. The risky sign-in rule fires only on High risk sign-ins as classified by Entra ID Protection. Entra ID Protection classified the sign-in as Medium risk (unfamiliar sign-in properties) — the rule’s threshold is High. A detection engineer would build a rule that detects session token anomalies: the sign-in occurs on a device the user has never used before, the browser fingerprint does not match her baseline, and the non-interactive token refresh occurs from a different IP than the interactive sign-in that created the session. These signals exist in SigninLogs and AADNonInteractiveUserSignInLogs. No rule queries them.

Phase 3 — Inbox rule persistence. Northgate’s inbox rule template fires on rules that forward email to external addresses. The attacker did not create a forwarding rule — forwarding rules are well-known indicators of compromise and sophisticated attackers avoid them. Instead, the attacker created a rule that moves emails matching financial keywords to the RSS Subscriptions folder — a folder most users never check. This hides the emails from Sarah so she does not see the CFO’s responses to the fraudulent wire transfer request. The template rule does not detect folder-move rules because it was not designed for this variant. A detection engineer would build a rule that detects any inbox rule creation from a session that has identity risk signals, regardless of the rule’s action type.

Phase 4 — Email collection. No rule exists. Northgate has zero analytics rules that query OfficeActivity for MailItemsAccessed events. The attacker read three months of Sarah’s email over a three-hour period. The access pattern — hundreds of MailItemsAccessed events with OperationType “Bind” from a single session within a short window — is highly anomalous. Sarah’s normal email access pattern is 20-40 Bind events per day spread across working hours. The attacker generated 400+ in three hours. The data exists in the workspace. No rule looks at it. A detection engineer would build a rule that baselines per-user MailItemsAccessed volume and fires when a session exceeds the baseline by a configurable multiple.

Phase 5 — BEC wire fraud. No rule exists. Northgate has zero analytics rules that detect business email compromise patterns — emails from internal accounts containing financial keywords (wire transfer, bank account, payment details, routing number) sent to executives or finance staff. The attacker sent the fraudulent wire transfer request from Sarah’s legitimate mailbox to the CFO. From the email system’s perspective, this is a normal internal email. A detection engineer would build a rule that detects the pattern: recent identity risk signal on the sender’s account + email to finance/executive recipients + financial keywords in the subject or body. This cross-source correlation — identity risk in SigninLogs joined with email content in EmailEvents — is exactly the kind of detection that templates do not provide because it requires environment-specific entity definitions.

The detection rules that would have caught it

Each phase of CHAIN-HARVEST had a detection opportunity — not with exotic technology, but with KQL queries against data already in the Sentinel workspace. These are the rules you will build in this course:

Phase 1 detection (DE3): A rule querying EmailUrlInfo for emails containing URLs with characteristics of AiTM proxy infrastructure — redirect chains through recently registered domains, specific URL path patterns known to be associated with EvilProxy and Tycoon 2FA kits, and mismatches between the displayed URL text and the actual URL destination.

Phase 2 detection (DE4): A rule querying SigninLogs and AADNonInteractiveUserSignInLogs for session token anomalies — interactive sign-in from an unrecognized device followed by non-interactive token refresh from a different IP within 30 minutes. This detects the AiTM pattern regardless of the sign-in risk classification.

Phase 3 detection (DE5): A rule querying OfficeActivity for New-InboxRule or Set-InboxRule events where the creating session has any identity risk signal (medium or high risk sign-in, unfamiliar sign-in properties, anonymous IP) within the preceding 60 minutes. This catches inbox rule persistence regardless of the rule’s action type.

Phase 4 detection (DE7): A rule querying OfficeActivity for MailItemsAccessed volume anomalies — sessions where the Bind event count exceeds the user’s 30-day baseline by more than 5x within a rolling 4-hour window. This detects bulk email reading whether the attacker uses OWA, Graph API, or EWS.

Phase 5 detection (DE7): A rule joining SigninLogs (recent risk signal on the sender) with EmailEvents (internal email containing financial keywords sent to finance or executive distribution lists). This cross-source correlation detects BEC attempts originating from compromised internal accounts.

Five rules. Five KQL queries. Each one queries data that already exists in the workspace. Each one would have generated an alert within minutes of the corresponding attack phase. The earliest detection (Phase 1) would have alerted the SOC before Sarah even clicked the link. The latest detection (Phase 5) would have alerted the SOC before the CFO authorized the wire transfer.

The attacker’s perspective: why this works

The attacker did not use a zero-day exploit. They did not deploy custom malware. They did not compromise a domain controller or move laterally to servers. Every tool and technique in CHAIN-HARVEST is commodity: EvilProxy is sold as a phishing-as-a-service platform. The BEC playbook is well-documented. The inbox rule persistence is a standard technique used by thousands of threat actors.

The attacker succeeds not because the techniques are sophisticated, but because the detection is absent. The attacker knows that most organizations detect what their vendor detects — and nothing more. If Defender does not flag the email, no one looks at it. If Entra ID Protection does not classify the sign-in as high risk, no one investigates it. If no rule queries MailItemsAccessed, the bulk email reading is invisible. The attacker operates in the space between what the vendor catches and what the SOC monitors.

Detection engineering closes that space. Every rule you build in this course is designed to detect techniques that vendor tooling misses — not because the vendor is bad, but because the vendor builds for the general case and your attacker targets the specific case. Your environment, your users, your risk profile, your data patterns. The detection engineer writes rules for that specificity.

Troubleshooting: “We have a managed SOC — wouldn’t they catch this?”

The managed SOC triages alerts from your rules. If your rules do not fire, the managed SOC has nothing to triage. They are an operational resource — they monitor, investigate, and escalate the alerts your detection library generates. If your detection library covers 10.3% of techniques, the managed SOC monitors 10.3% of techniques. The other 89.7% is not their gap to close — it is yours.

Some managed SOC providers offer “content development” or “custom detection” services. If this is contracted and active, verify what they have built. Request the full list of custom analytics rules, their ATT&CK mappings, and the date each was last tuned. If the custom rules are template-based or have not been tuned in 6+ months, the effective coverage may be lower than the contracted coverage.

The relationship is complementary, not substitutive. You build the detection library. They operationalize it 24/7. This course teaches the building. The managed SOC handles the operating.

References used in this subsection

• CHAIN-HARVEST attack chain specification (course blueprint)
• Course cross-references: DE3 (initial access detection), DE4 (credential attack detection), DE5 (persistence detection), DE7 (collection and exfiltration detection)

CHAIN-HARVEST detection timeline: what fires and what does not

1
2
3
4
5
6
7
8

// CHAIN-HARVEST gap analysis: which tables contain the attack telemetry?
// Run each query — non-zero results confirm the DATA exists even if no RULE fires
SigninLogs | where TimeGenerated > ago(1d) | summarize Count = count() | project Table = "SigninLogs", Count
| union (EmailEvents | where TimeGenerated > ago(1d) | summarize Count = count() | project Table = "EmailEvents", Count)
| union (OfficeActivity | where TimeGenerated > ago(1d) | summarize Count = count() | project Table = "OfficeActivity", Count)
| union (DeviceLogonEvents | where TimeGenerated > ago(1d) | summarize Count = count() | project Table = "DeviceLogonEvents", Count)
// If all tables return data: the TELEMETRY for CHAIN-HARVEST detection exists.
// The gap is not data — it is RULES.