DE0.6 Walking CHAIN-HARVEST

CHAIN-HARVEST: the attack that 23 rules miss

CHAIN-HARVEST is an AiTM credential phishing campaign that moves through five phases in under four hours: phishing delivery, token capture via proxy, inbox rule persistence, mailbox reconnaissance, and BEC wire fraud. The attacker uses commodity tooling — EvilProxy for the phishing proxy, standard Outlook Web for email access, and social engineering for the financial fraud. Nothing exotic.

Nothing that requires a zero-day or custom malware. The total attacker investment is a few hundred dollars. The potential return from a successful wire fraud is measured in hundreds of thousands.

Every phase generates telemetry in the Sentinel workspace. EmailEvents captures the phishing delivery. SigninLogs captures the anomalous authentication. OfficeActivity captures the inbox rule creation and the mailbox access. EmailEvents captures the outbound BEC email. The data is there. No rule examines it in the right way.

Estimated time: 40 minutes.

Phase 1 — Phishing email delivery (09:14)

Here is CHAIN-HARVEST as a structured attack chain specification — the format detection engineers use to document attack scenarios and map them to detection rules:

{
  "chain_id": "CHAIN-HARVEST",
  "name": "AiTM Credential Phishing → BEC Wire Fraud",
  "actor_profile": "Financially motivated, BEC operator",
  "phases": [
    { "phase": 1, "technique": "T1566.002", "table": "EmailEvents",
      "time": "09:14", "action": "EvilProxy phishing link delivery" },
    { "phase": 2, "technique": "T1557", "table": "SigninLogs",
      "time": "09:17", "action": "AiTM session token capture" },
    { "phase": 3, "technique": "T1137.005", "table": "OfficeActivity",
      "time": "09:24", "action": "Inbox rule persistence" },
    { "phase": 4, "technique": "T1114.002", "table": "OfficeActivity",
      "time": "09:31-12:45", "action": "412 emails accessed" },
    { "phase": 5, "technique": "T1534", "table": "EmailEvents",
      "time": "13:02", "action": "BEC wire transfer request" }
  ],
  "detection_rules": ["DE3-001", "DE4-002", "DE5-001", "DE7-002", "DE7-006"],
  "total_duration_hours": 3.8,
  "detection_result": "0 of 5 phases detected by 23 template rules"
}

Five phases, five ATT&CK techniques, three data tables, under four hours from phishing email to fraudulent wire transfer. Walk through each phase to see where detection should have fired and why the template rules missed it.

The attacker sends a phishing email to a finance manager containing a link to an EvilProxy-hosted credential harvesting page.

The link points to a compromised legitimate website — a UK engineering standards portal that was compromised 48 hours ago — which redirects to the proxy infrastructure. The domain is not in Microsoft's threat intelligence feeds because it has 8 years of legitimate reputation and was compromised too recently for reputation-based feeds to update.

EvilProxy is an AiTM phishing-as-a-service platform that handles the proxy infrastructure, the credential capture, the session token interception, and the dashboard where the attacker monitors compromised sessions.

The attacker doesn't need to build anything — they subscribe to the service, configure the target tenant, and launch the campaign. The barrier to entry for AiTM phishing dropped from "build your own Evilginx2 infrastructure" to "buy a subscription and point it at a domain." This is why AiTM phishing has become the dominant initial access technique for BEC campaigns — it bypasses MFA without requiring any technical sophistication beyond following a setup wizard.

The email itself is unremarkable — a notification about a shared document, using the finance manager's company name and a plausible sender.

The URL is the only indicator, and it points to a legitimate domain. Safe Links follows the URL, reaches the legitimate engineering standards portal, and finds nothing malicious because the redirect to EvilProxy is triggered by JavaScript that executes in the user's browser, not in Safe Links' detonation sandbox.

The organization has one template rule for phishing: "Phishing email detected by Microsoft Defender for Office 365." This rule fires when Defender flags an email as phishing. Defender's verdict was "clean" because the URL pointed to a recently compromised legitimate site with established reputation.

The rule depends entirely on Defender's verdict. If Defender doesn't flag it, the rule doesn't fire. No independent analysis of EmailEvents or EmailUrlInfo occurs.

What a detection engineer would build:

A rule that queries EmailUrlInfo for URL structural patterns associated with AiTM proxy infrastructure — redirect chains where the initial domain differs from the final domain, URL path patterns characteristic of proxy kit frameworks, and domain age analysis on the redirect target. This rule fires on structural URL characteristics, not domain reputation.

The rule is DE3-001 in Module 3.

Phase 2 — AiTM token capture (09:17)

Sarah clicks the link, sees a legitimate-looking Microsoft login page (the proxy passes everything through), authenticates with her credentials and MFA, and the proxy captures her session token. The attacker replays the token from their own infrastructure.

Two sign-in events appear in SigninLogs within three minutes. the finance manager's legitimate interactive sign-in: Edge browser, Windows 11, corporate office IP. The attacker's non-interactive token refresh: Chrome browser, Linux, residential proxy IP in a nearby city. Same SessionId. Different DeviceDetail. Different IP. Different operating system. Different browser.

The organization has two identity rules. The impossible travel rule doesn't fire because both IPs are in the same country — 120 miles apart, within the threshold.

The risky sign-in rule fires only on High risk classifications from Entra ID Protection. This sign-in was classified Medium (unfamiliar properties) — below the threshold. The analyst who set the High threshold did so because Medium-risk sign-ins generated 15-20 false positives per day from legitimate remote workers.

What a detection engineer would build:

A rule that detects session token anomalies — same SessionId with mismatched DeviceDetail between the interactive sign-in and the non-interactive token refresh, within a 30-minute window. The signal is device fingerprint divergence within a single session. This pattern does not occur in legitimate authentication because users don't change their browser, OS, and IP mid-session.

The rule is DE4-002 in Module 4.

The core of this detection — the cross-table join on SessionId with DeviceDetail mismatch — looks like this in KQL:

// Cross-family: suspicious sign-in → inbox rule creation within 30 minutes
let suspiciousSignins = SigninLogs
 | where TimeGenerated > ago(1d)
 | where RiskLevelDuring in ("medium", "high")
 | project SigninTime = TimeGenerated, UserPrincipalName, SessionId, IPAddress;
OfficeActivity
 | where TimeGenerated > ago(1d)
 | where Operation == "New-InboxRule"
 | extend ruleUser = UserId
 | join kind=inner suspiciousSignins
 on $left.ruleUser == $right.UserPrincipalName
 | where TimeGenerated between (SigninTime .. (SigninTime + 30m))
 | project
 SigninTime,
 RuleCreatedTime = TimeGenerated,
 UserPrincipalName,
 IPAddress,
 Operation,
 Parameters

You don't need to understand every line yet — Module 1 teaches rule architecture, and DE4 builds this rule. The point is that the detection signal (suspicious sign-in followed by inbox rule creation within 30 minutes) translates directly to a KQL join with a time window. The data is there. The query is straightforward. The rule was never written.

Phase 3 — Inbox rule persistence (09:24)

The attacker creates an inbox rule: move emails containing "invoice," "payment," "wire," or "transfer" to the RSS Subscriptions folder. This hides financial email evidence from Sarah. She won't see the CFO's responses to the fraudulent wire request because they'll be silently moved to a folder she never opens.

the template rule for inbox rules fires on rules that forward email to external addresses. The attacker didn't create a forwarding rule — forwarding rules are a well-known compromise indicator and sophisticated attackers avoid them.

A folder-move rule achieves the same objective (hiding emails) without triggering forwarding-based detection. The OfficeActivity record contains the full rule configuration in the Parameters field: MoveToFolder targeting "RSS Subscriptions," SubjectContainsWords including "invoice," "payment," "wire," "transfer." Every detail is logged. The template doesn't examine it.

What a detection engineer would build:

A rule that detects inbox rule creation targeting hidden folders (RSS Subscriptions, Junk Email, Deleted Items) combined with financial keywords, from a session with identity risk signals. The detection targets the behavior (hiding financial emails) not the specific action (forwarding). The rule is DE5-001 in Module 5.

Phase 4 — Mailbox reconnaissance (09:31–12:45)

The attacker accesses the finance manager's mailbox through Outlook Web for three hours, reading three months of email history.

They're looking for three things: financial processes (how supplier payments work, who approves wire transfers, what the typical amounts are), organizational relationships (who reports to whom, which suppliers are active, which contacts Sarah communicates with about payments), and email templates (how Sarah writes, what signatures she uses, what her typical subject line patterns look like). The attacker needs this information to craft a convincing BEC email that the CFO won't question.

412 MailItemsAccessed events with OperationType "Bind" appear in OfficeActivity from a single SessionId between 09:31 and 12:45. the finance manager's baseline is 28 Bind events per day during working hours — approximately 3-4 per hour during a normal workday.

The attacker generates 14 times her daily volume in three hours. The per-hour rate during the attack is approximately 137 Bind events per hour, compared to the finance manager's normal 3-4. That's a 30-40x hourly deviation.

The organization has zero rules that query MailItemsAccessed. The most anomalous email access pattern in the workspace goes completely unexamined. The data required for time-series anomaly detection — make-series on daily or hourly Bind counts per user, series_decompose_anomalies to identify the outlier — exists in OfficeActivity. The KQL functions exist in Sentinel. Zero rules use either.

What a detection engineer would build:

A rule that baselines per-user MailItemsAccessed Bind volume and fires when a session exceeds the baseline by a configurable multiplier. The rule accounts for variation — some users read more email than others — by computing per-user baselines rather than global thresholds. The rule is DE7-002 in Module 7.

Phase 5 — BEC wire fraud (13:02)

The attacker sends an email from the finance manager's compromised account to the CFO requesting an urgent wire transfer to "updated" supplier banking details.

The email is crafted using the intelligence gathered in Phase 4: it references a real supplier, a real project, and a realistic amount ($287,000). It uses the finance manager's email signature, her writing style, and a subject line that matches her previous correspondence about supplier payments.

The recipient address for the "updated" banking details (vendor-payments@supplier-portal.com) is one Sarah has never emailed before — a first-time external recipient with payment-related domain naming. This is a detectable signal: the combination of an internal email from a recently compromised account, containing financial keywords, sent to a first-time external recipient with payment-related naming, is the BEC completion signature.

The organization has zero BEC detection rules. The highest-impact phase — the phase that causes direct financial loss — has no detection at all. The attack is detected six hours later when the CFO calls the supplier to confirm the account change, and the supplier has no record of requesting one.

What a detection engineer would build:

A rule that detects first-time external email to addresses matching financial or payment patterns, from an account with recent identity risk signals (the suspicious sign-in from Phase 2) or recent inbox rule creation (the persistence from Phase 3). The cross-family join — connecting EmailEvents (the BEC email) with SigninLogs (the compromised authentication) through user identity and time window — is what elevates this from a noisy "first-time recipient" rule to a high-confidence BEC detection.

The rule is DE7-006 in Module 7.

The pattern across all five phases

Every phase failed for the same structural reason: the rules examined the wrong signal. Phase 1 depended on a vendor verdict instead of analyzing email telemetry independently. Phase 2 used geographic distance instead of device fingerprint divergence. Phase 3 checked for forwarding instead of the broader behavior of hiding financial emails. Phase 4 had no rule at all. Phase 5 had no rule at all.

Detection engineering fixes this by starting from the adversary's behavior: what does this technique look like in telemetry, and what signal distinguishes it from legitimate activity? That question produces different rules than "what templates does Microsoft provide?" The seven rules that catch CHAIN-HARVEST span four modules and four data source families, and they exist because a detection engineer modeled the attack, hypothesized the signals, and built rules that target those signals specifically.

The telemetry was there — all of it

This is the detail that makes CHAIN-HARVEST instructive. The data was collected at every phase. The ingestion budget was spent. The Sentinel workspace stored every event. The failure was not in data collection — it was in data examination. The gap between data collected and data examined is the gap detection engineering closes.

Phase 1 left records in EmailEvents showing the inbound email with the EvilProxy URL. EmailUrlInfo recorded the URL's redirect chain — the initial domain (the compromised engineering standards site) and the final domain (the EvilProxy proxy). The domain registration age for the proxy was 72 hours. All of this is queryable in KQL.

Phase 2 left two SigninLogs records within three minutes — one interactive (Edge/Windows/corporate IP) and one non-interactive token refresh (Chrome/Linux/residential proxy IP). The SessionId field matches across both records. The DeviceDetail field does not. This is the canonical AiTM signal — same session, different device — visible in plain text in the sign-in logs.

Phase 3 left an OfficeActivity record with Operation "New-InboxRule." The Parameters field contains the full inbox rule configuration: MoveToFolder targeting "RSS Subscriptions," SubjectContainsWords including "invoice," "payment," "wire," "transfer." Every detail of the persistence mechanism is in the log.

Phase 4 left 412 MailItemsAccessed records with OperationType "Bind" from a single SessionId between 09:31 and 12:45. the finance manager's 30-day average was 28 Bind events per day. The anomaly is a 14x deviation from baseline — the kind of outlier that time-series anomaly detection is designed to catch.

Phase 5 left an EmailEvents record showing an internal email from the compromised account to the CFO (CFO) with financial keywords in the subject. Cross-referencing with OfficeActivity shows the email was sent from the same session that created the inbox rule and read 412 emails. The session correlation — connecting phases 2 through 5 through a single compromised SessionId — is a KQL join operation.

What CHAIN-HARVEST teaches about detection engineering

CHAIN-HARVEST is not just an attack walkthrough. It's a diagnostic for how detection programs fail. Each phase demonstrates a different failure mode:

Phase 1 demonstrates vendor dependency — delegating detection to Defender's verdict instead of building independent detection capability. When the vendor misses it, you miss it. Detection engineering builds rules that operate independently of vendor verdicts.

Phase 2 demonstrates wrong-signal detection — using geographic distance when the actual distinguishing signal is device fingerprint divergence.

Most template rules use the obvious signal (location) instead of the precise signal (device context). Detection engineering starts from the adversary's behavior and works backward to the telemetry signal, rather than starting from the available template and hoping it matches.

Phase 3 demonstrates pattern rigidity — checking for one specific action (forwarding) when the attacker used a different action (folder-move) that achieves the same objective. Template rules detect the indicator. Detection engineering detects the behavior.

Phase 4 demonstrates the unexamined data problem — the telemetry exists, the table is populated, the events are recorded, and no rule queries them. The most common detection gap is not missing data — it's data that nobody wrote a rule to examine.

Phase 5 demonstrates the compounding gap — by the time the attack reaches its highest-impact phase (financial fraud), the detection program has already failed at four earlier opportunities. Each missed phase made the next phase more damaging. Layered detection — rules at multiple phases of the chain — catches what any single rule might miss.

These five lessons are the foundation of the detection engineering methodology you'll apply throughout DE3-DE8. Every rule you build addresses one or more of these failure modes.