Business Email Compromise is one of the highest-impact cyber threats facing organisations — the FBI IC3 consistently reports billions in annual losses. Unlike malware-heavy attacks, BEC relies on trusted email channels and legitimate-looking requests. Detection requires monitoring identity, mail flow, and financial systems together.
Modern BEC almost always begins with an Adversary-in-the-Middle (AiTM) phishing kit that captures session cookies, bypassing MFA entirely. From there, attackers set up silent inbox rules to hide their tracks, conduct recon inside the mailbox, and pivot to fraud or lateral phishing within the organisation.
◈ Table of Contents
01
Background
CONTEXTB1BEC Attack Phases & MITRE Mapping
| Phase | MITRE | Key Indicator | Severity |
|---|---|---|---|
| AiTM phishing / session token theft | T1539, T1566.002 | Sign-in from new geography/ASN immediately after phishing click; risk event in Entra ID Protection | CRITICAL |
| Inbox rule creation (hide/redirect) | T1114.003 | New Outlook rule redirecting to RSS/deleted items; keywords: invoice, payment, wire, bank | HIGH |
| Mail forwarding to external address | T1114.003 | ForwardingSmtpAddress set on mailbox; ExternalOofOptions changed | HIGH |
| OAuth app consent grant | T1528 | New OAuth app granted Mail.Read / Mail.ReadWrite / Mail.Send permissions | HIGH |
| Wire transfer fraud email | T1566.002, T1496 | Finance or exec account sending payment instruction emails to external recipients | CRITICAL |
| Lateral phishing from compromised account | T1566.001 | High-volume outbound email to internal/external from compromised account post-takeover | CRITICAL |
B2Log Sources
| Source | Table / Portal | Key Events |
|---|---|---|
| Entra ID Sign-in Logs | SigninLogs (Sentinel) / Entra Portal | Risk events, impossible travel, new ASN, token replay detection |
| Unified Audit Log (M365) | OfficeActivity (Sentinel) / Purview | New-InboxRule, Set-Mailbox, ConsentGranted, EmailSendingLimitExceeded |
| Defender for Office 365 | EmailEvents, EmailUrlInfo | Phishing click, AiTM kit fingerprint, post-delivery detonation |
| Entra ID Protection | AADRiskyUsers, AADUserRiskEvents | Unfamiliar sign-in properties, leaked credentials, impossible travel |
02
Identification
INVESTIGATEBEC Investigation Workflow
I1Inbox Rule Detection & Mail ForwardingKQL + SPL
KQL — Sentinel: Suspicious inbox rules
// Detect new inbox rules that redirect/delete mail (BEC hallmark)
OfficeActivity
| where TimeGenerated > ago(7d)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend RuleParams = parse_json(Parameters)
| where RuleParams has_any (
"DeleteMessage", "ForwardTo", "RedirectTo",
"MoveToFolder", "MarkAsRead", "StopProcessingRules"
)
// High-value targets
| where UserId has_any ("cfo@", "finance@", "ap@", "ceo@", "exec@")
or RuleParams has_any ("invoice", "payment", "wire", "bank", "transfer")
| project TimeGenerated, UserId, ClientIP, RuleParams, UserAgent
| order by TimeGenerated desc
KQL — Mail forwarding to external address
OfficeActivity
| where TimeGenerated > ago(7d)
| where Operation == "Set-Mailbox"
| extend Params = tostring(Parameters)
| where Params has "ForwardingSmtpAddress"
| where Params !has "@yourdomain.com" // replace with your domain
| project TimeGenerated, UserId, ClientIP, Params
| order by TimeGenerated desc
SPL — Splunk UAL: Inbox rule creation
index=o365 Operation IN ("New-InboxRule","Set-InboxRule")
| spath Parameters
| where like(Parameters, "%DeleteMessage%")
OR like(Parameters, "%ForwardTo%")
OR like(Parameters, "%invoice%")
OR like(Parameters, "%payment%")
| table _time, UserId, ClientIP, Parameters
| sort -_time
I2AiTM Session Token Theft & Risky Sign-insKQL
KQL — Sentinel: Impossible travel + MFA bypass indicators
// Sign-in from new country/ASN right after successful MFA
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName == "[email protected]"
| where ResultType == 0 // success
| extend CountryCode = tostring(LocationDetails.countryOrRegion)
| extend ASN = tostring(NetworkLocationDetails[0].networkNames[0])
| order by TimeGenerated asc
| project TimeGenerated, UserPrincipalName, IPAddress, CountryCode, ASN,
AuthenticationDetails, ConditionalAccessStatus, RiskLevelDuringSignIn,
UserAgent, AppDisplayName
KQL — Entra ID token theft / unfamiliar sign-in
AADUserRiskEvents
| where TimeGenerated > ago(7d)
| where RiskEventType in (
"unfamiliarFeatures", "anonymizedIPAddress",
"impossibleTravel", "tokenIssuerAnomaly"
)
| project TimeGenerated, UserPrincipalName, RiskLevel, RiskEventType,
IPAddress, Location, AdditionalInfo
| order by TimeGenerated desc
AiTM kits steal the post-MFA session cookie — the sign-in log will show MFA succeeded (ResultType=0, AuthenticationRequirement=multiFactorAuthentication) followed immediately by activity from a completely different IP and country. That pattern is near-certain AiTM.
I3OAuth Consent Grant AbuseKQL
KQL — Sentinel: Suspicious app consent grants
// New OAuth apps granted Mail permissions — common BEC persistence mechanism
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Consent to application"
| extend Scopes = tostring(TargetResources[0].modifiedProperties[0].newValue)
| where Scopes has_any ("Mail.Read", "Mail.ReadWrite", "Mail.Send", "MailboxSettings.ReadWrite")
| extend AppName = tostring(TargetResources[0].displayName)
| extend InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, InitiatedBy, AppName, Scopes
| order by TimeGenerated desc
After an account takeover, attackers often grant a rogue OAuth app Mail.ReadWrite permissions — this lets them read mail indefinitely even after the password is reset, because OAuth tokens survive password changes. Always revoke OAuth grants during containment.
03
Containment
STOP ITC1Account Takeover ContainmentImmediate
- 1Block sign-in: Entra ID → Users → [user] → Account enabled → NO. This terminates all future authentication.
- 2Revoke all sessions: Users → [user] → Revoke sessions. This invalidates existing session tokens including the stolen one.
- 3Revoke OAuth grants: Entra ID → Enterprise applications → [app] → Permissions → Revoke user consent. Or via PowerShell:
Revoke-AzureADUserAllRefreshToken -ObjectId [UPN] - 4Remove malicious inbox rules: Exchange Admin Center → Recipients → Mailboxes → [user] → Manage mailbox → Inbox rules → Delete the attacker-created rule.
- 5Remove mail forwarding: Exchange Online PowerShell →
Set-Mailbox [UPN] -ForwardingSmtpAddress $null -DeliverToMailboxAndForward $false - 6If wire transfer fraud email was sent — notify Finance immediately with the recipient email addresses and amounts mentioned. Time is critical for bank recall.
C2Purge Phishing Emails from Organisation
- 1If the compromised account sent phishing internally — use Defender for Office 365 Threat Explorer to find all recipients:
security.microsoft.com → Email & collaboration → Explorer → From: [compromised UPN] - 2Soft-delete the phishing emails org-wide: Threat Explorer → Select messages → Delete → Soft delete. This removes from inbox but retains in recoverable items for forensics.
- 3Check if any recipient clicked a link — review EmailUrlInfo for clicks post-delivery and cross-reference with those users' SigninLogs for subsequent risky sign-ins.
04
Eradication
CLEAN UPE1Full Account Remediation
- 1Reset password via out-of-band channel (phone call to user's manager — not email). Enforce complex password.
- 2Clear all MFA methods and re-register via a Temporary Access Pass (TAP): Entra ID → Users → [user] → Authentication methods → Delete all TOTP/authenticator entries → Issue TAP.
- 3Review all inbox rules on the mailbox (not just the attacker's rule) — confirm legitimate rules are intact.
- 4Enable Litigation Hold on the mailbox to preserve evidence before re-enabling the account:
Set-Mailbox [UPN] -LitigationHoldEnabled $true - 5Re-enable account after full remediation. Monitor sign-in logs for the next 7 days for anomalies.
Eradication Complete When
- All sessions revoked, OAuth grants removed, inbox rules cleaned
- Mail forwarding to external addresses disabled
- Password reset and MFA re-registered via TAP
- Phishing emails purged from all recipient inboxes
- Finance team notified of any fraudulent payment instructions
05
Escalation
TIERSESC1Escalation Tiers
| Tier | Trigger | Action |
|---|---|---|
| L1 → L2 | Inbox rule created, mail forwarding confirmed, account blocked | Hand off with: affected UPN, risky sign-in timestamps, inbox rule details, OAuth apps identified |
| L2 → CISO + Legal | Wire transfer fraud email sent or payment processed; multiple mailboxes compromised; PII exfiltrated via forwarding | CISO + Legal + HR notified. If payment processed — contact bank within 24h for recall. Potential regulatory notification. |
| L2 → Finance Director | Any email from compromised account referencing payment, wire, invoice, or bank account change | Finance Director verbally confirms with the email sender via phone before any payment action. Hard stop on all payments referenced in suspicious emails. |
Authorized security research & penetration testing only. Unauthorized use is illegal. Authored by Rudra Verma | Senior Security Architect | CyberHawk Consultancy.