BEC on Microsoft 365: How an AI SOC Investigates It in 90 Seconds

At 14:22:06 UK time, Microsoft Sentinel fires an impossible-travel alert on [email protected]. She signed into Outlook from London at 14:13. Four minutes later, a successful login arrives from Lagos, Nigeria.

Industry statistics tell you this will be a BEC attempt 92% of the time. Business Email Compromise is now the most common threat vector for UK SMEs, and the M365 environment is where most of it plays out. The FBI's IC3 reports put global BEC losses at over $50 billion since 2013. For UK MSPs, it's the incident type most likely to produce a catastrophic client outcome.

This post walks through exactly what happens next — step by step, with timings — when that alert is picked up by an agentic AI SOC.

The scenario

• User: Jaya Patel, finance manager at Contoso Ltd (a 180-seat professional-services firm in Bristol).
• Detection: Microsoft Sentinel impossible-travel analytic rule — London 14:13 to Lagos 14:17.
• Alert ID: INC-2026-04817, severity HIGH.
• MSP context: Contoso is one of 47 tenants managed by a two-analyst UK MSP using SocSage for alert triage.

Step 1–4 — Triage and initial enrichment (0:00–0:04)

Step 1: Alert ingestion (0:00)

SocSage ingests the Sentinel incident via the workspace API. The raw alert JSON contains the source IP (41.203.64.12), timestamps, user principal name, device ID, and Sentinel's generated severity.

Step 2: MITRE classification (0:01)

The triage agent maps the alert to MITRE ATT&CK technique T1078.004 — Valid Accounts: Cloud Accounts. This isn't a generic mapping; the agent uses the alert's evidence to decide between T1078 (Valid Accounts), T1586 (Compromised Accounts), and T1586.002 (Compromise Accounts: Email Accounts). Impossible-travel with no prior device compromise signals → T1078.004.

Step 3: Identity context (0:02)

The identity-enrichment agent queries Microsoft Graph API:

• Display name: Jaya Patel
• Job title: Finance Manager
• Manager: Robert Kline (CFO)
• Registered devices: 3 (iPhone, MacBook Pro, Windows laptop)
• Group memberships: Finance, All Staff, Accounts Payable
• MFA status: enabled, registered authenticator app
• Last password change: 47 days ago

Step 4: IOC enrichment (0:04)

The IOC agent calls VirusTotal and AbuseIPDB on 41.203.64.12. Results:

• VirusTotal: 72 of 89 engines flag as malicious
• AbuseIPDB: 94% confidence score, 217 reports in last 90 days
• Known context: residential ISP range in Lagos, Nigeria, previously observed in ~20 BEC campaigns
• Geolocation: Lagos, Nigeria (matches Sentinel's claim)

Step 5–8 — Lateral movement and privilege (0:04–0:16)

Step 5: Lateral-movement scan (0:08)

The lateral-movement agent queries Entra ID sign-in logs for the last 24 hours, filtered to j.patel:

• 14:13:42 — Successful sign-in, London, registered MacBook Pro, MFA satisfied (authenticator app)
• 14:17:31 — Successful sign-in, Lagos, unregistered browser fingerprint, MFA satisfied (SMS fallback — note this)
• 14:18:04 — SharePoint access, "Q2 Acquisition Targets" folder, 4 documents viewed
• 14:19:12 — Additional login attempt, Lagos, blocked by Conditional Access
• 14:21:58 — Outlook Web Access session, inbox rule created: "forward messages from @bank.co.uk to external address"

The last event is the critical signal: a forwarding rule to an external address. This is a classic BEC indicator — attackers use inbox rules to silently exfiltrate financial correspondence.

Step 6: Email assessment (0:11)

The email agent reviews message headers and M365 Defender verdicts from the preceding 48 hours. Finds a phishing precursor: at 10:14 the same morning, Jaya received an email claiming to be from "Microsoft 365 Security" asking her to reauthenticate via a linked URL. Defender for Office 365 verdict: "suspicious, not blocked." URL resolved to a lookalike domain — login-microsoft365.co.

Step 7: EDR interrogation (0:14)

The EDR agent queries SentinelOne across Jaya's three registered devices. All devices return clean — no suspicious processes, no credential-theft indicators, no persistence artefacts. The attack is cloud-only; her endpoints were never touched. This is typical of BEC: the attacker doesn't need the laptop, they only need the session token.

Step 8: Privilege-scope calculation (0:16)

The privilege agent computes blast radius:

• Jaya has no elevated roles — not an admin, not a delegated approver
• Mailbox access: her own inbox + 1 shared mailbox ([email protected])
• SharePoint: Finance site (full read/write), Q2 Acquisition folder (read-only)
• Teams: Finance channel, All-Staff channel
• No Azure resource access

The blast radius is significant — shared accounts-payable mailbox is an ideal position for invoice fraud — but contained. This is not a domain-admin compromise.

Step 9–13 — Timeline and narrative (0:16–1:02)

Step 9: Timeline reconstruction (0:28)

All events are assembled into a chronology:

1. 10:14 — Phishing email delivered (Defender verdict: suspicious)
2. 10:23 — User clicks link (inferred from browser proxy log)
3. 10:24 — Credentials submitted to lookalike site (inferred)
4. 14:13 — Legitimate London sign-in (MacBook Pro)
5. 14:17 — Lagos sign-in successful (MFA via SMS)
6. 14:18 — SharePoint access: 4 acquisition documents viewed
7. 14:19 — Blocked login attempt from Lagos
8. 14:22 — Inbox forwarding rule created
9. 14:22 — Sentinel fires impossible-travel alert

Step 10: D3FEND countermeasure mapping (0:45)

Recommended actions, ranked by effectiveness:

• D3-SR (Session Revocation) — Revoke all active tokens for j.patel
• D3-CH (Credential Hardening) — Force password reset and re-register MFA
• D3-NTA (Network Traffic Analysis) — Block source IP across tenant
• D3-MFAC (Multi-Factor Authentication Control) — Remove SMS fallback, enforce authenticator-only
• D3-MBT (Message Blocking) — Remove malicious inbox rule, quarantine forwarding target

Step 11: Risk score (0:58)

92% malicious. The residual 8% accounts for: legitimate travel (ruled out via calendar), VPN (ruled out via ISP type), and shared credentials (possible but unlikely given device registration patterns).

Step 12–13: Evidence packaging and narrative (1:02)

A 340-token incident summary is generated: two paragraphs of plain-English narrative, followed by a machine-readable evidence block (timestamps, IOCs, ATT&CK mapping, blast radius, recommended actions, confidence score). Everything is cross-referenced by event ID so a human reviewer can follow any claim back to source.

Step 14 — The HITL gate (1:02)

A Slack Block Kit card arrives in the MSP's #soc-contoso channel:

The MSP analyst reviews the evidence for 47 seconds, confirms with a glance at Jaya's Outlook calendar that she is not travelling, and clicks Approve all. SocSage executes the four actions in parallel:

• Session tokens revoked (Microsoft Graph revokeSignInSessions)
• Password reset forced on next login
• Inbox forwarding rule removed
• Conditional Access policy updated to require authenticator app for j.patel (SMS fallback removed)

Total time from alert to remediation: 2 minutes 17 seconds.

What would have happened without AI triage

Under a traditional Tier 1 model, the alert sits in the queue. The analyst picks it up at 16:47 — 2h 25m later — because the queue is already 340 alerts deep from the morning. By then:

• The attacker has had 2h 25m of access to the shared accounts-payable mailbox.
• 3 invoice redirection emails have been sent to Contoso's largest suppliers requesting payment to a new bank account.
• 2 of those invoices are paid the next morning. £47,000 is wired to a mule account in Lagos.

This isn't hypothetical. The Verizon DBIR puts median BEC dwell time before detection at 197 days. The reason isn't that attackers are clever; it's that Tier 1 is drowning.