BEC & AiTM In Depth — From Delivery to Dwell

BEC and AiTM are the two phishing attack types that cause the most financial and operational damage. They’re also the hardest to detect because the attack vector is trust — not malware. Neither requires the victim to install anything.

BEC In Depth

The Three BEC Variants

Variant 1: CEO Fraud

From: "CEO John Smith" <jsmith@corp-exec.net>   ← lookalike domain
To: finance-team@corp.com
Subject: Confidential — Wire Transfer Authorization

I need you to process an urgent wire transfer for a business acquisition.
Amount: $280,000 USD
Bank: [attacker account]
Handle this directly and confidentially. I'll explain more on my return.
— John

Variant 2: Vendor Fraud

From: accounts@vendor-invoicing.com  ← attacker-registered
Impersonating: accounts@real-vendor.com
Body: "We've updated our banking details. Please update your records
      and process this month's payment to our new account..."

Variant 3: Internal Account Compromise → BEC

The most dangerous variant — the attacker has already compromised a real employee’s email account (via credential phish or AiTM). Now BEC is sent from the real account with correct authentication. No lookalike domain. No header tricks. SPF/DKIM/DMARC all pass correctly. Only behavioral indicators remain.

BEC Indicator Checklist

Header indicators:

Reply-To address differs from From: address
From: domain is a lookalike (corp-finance.com, corp-exec.net, corp.finance.com)
Domain registration age < 30 days (WHOIS)
Received headers originate from VPS/cloud/residential ISP, not a corporate mail relay
DMARC fails (lookalike doesn’t have DMARC alignment with real domain) — or passes for wrong domain

Content indicators:

Wire transfer, direct deposit change, or W-2/tax document request
Urgency (“today,” “within the hour,” “before market close”)
Secrecy (“keep this between us,” “don’t discuss with others,” “handle directly”)
Requestor claims to be unavailable for phone verification (“I’m in a meeting,” “on a flight”)
Request to bypass normal approval process (“this is an exception,” “I’ll handle the approval retroactively”)

Behavioral indicators (from victim or mailbox):

Has the victim already replied to the attacker?
Has a wire been initiated or completed?
Did the victim’s account create any forwarding rules or inbox rules after the email arrived?
Any new OAuth applications granted access to the victim’s mailbox?

BEC Investigation Workflow

1. Acquire the email headers → run full header analysis (Lesson 1 checklist)
2. Identify the From: domain → WHOIS lookup for age
3. Check Reply-To: → does it differ? Submit to threat intel.
4. Search M365 UAL for: victim mailbox activity since email arrival
   - Did victim reply?
   - New-InboxRule events?
   - MailItemsAccessed from new IPs?
5. Contact victim directly (call, not email) → confirm if they took action
6. If wire initiated: escalate to finance immediately — wire recall window is ~24h
7. Preserve the email as evidence before remediation

AiTM In Depth

The Attack Timeline

AiTM is a multi-stage attack. Each stage leaves distinct log evidence:

Stage 1: Phishing delivery

Victim receives a phishing email with a link to the AiTM proxy
Email logs: delivery timestamp, sender, subject, recipient

Stage 2: AiTM session initiation

Victim clicks link → arrives at attacker’s reverse proxy (EvilProxy, Evilginx2, Tycoon 2FA)
Proxy forwards the real login page from Microsoft/Okta/Google
Victim enters credentials and completes MFA
Proxy captures the session token AFTER MFA
Identity logs: sign-in event from new IP (attacker’s proxy IP, not victim’s workstation)

Stage 3: Post-compromise access (the dwell phase)

Attacker uses session token directly — no password or MFA needed
Attacker IP appears in all subsequent access events
Identity logs: MailItemsAccessed, FileAccessed events from attacker IP
Timeline: typically begins within 1–5 minutes of victim completing MFA

Stage 4: Persistence

New-InboxRule: forwarding all mail, deleting security alerts
OAuth consent: grant a malicious app access to mailbox
Identity logs: New-InboxRule, OAuthConsent events

AiTM Log Correlation in Microsoft 365

Step 1: Find the suspicious sign-in

In Entra ID sign-in logs (SigninLogs table in Sentinel):

SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName == "victim@corp.com"
| project TimeGenerated, IPAddress, Location, AppDisplayName, 
          ConditionalAccessStatus, ResultType, AuthenticationRequirement
| order by TimeGenerated desc

Look for: a sign-in from an unfamiliar IP around the time the phishing email was delivered.

Step 2: Confirm with MailItemsAccessed

In M365 UAL (OfficeActivity table):

OfficeActivity
| where TimeGenerated > ago(7d)
| where UserId == "victim@corp.com"
| where Operation == "MailItemsAccessed"
| project TimeGenerated, ClientIP, ClientInfoString, MailboxOwnerUPN
| order by TimeGenerated desc

If ClientIP shows the attacker’s VPS IP (e.g., DigitalOcean, Vultr, Linode ASN) rather than the victim’s expected corporate or residential IP, the session token has been stolen.

Step 3: Check for inbox rules

OfficeActivity
| where Operation == "New-InboxRule"
| where UserId == "victim@corp.com"
| project TimeGenerated, Parameters

Step 4: Check for OAuth grants

AuditLogs
| where OperationName == "Consent to application"
| where InitiatedBy.user.userPrincipalName == "victim@corp.com"

Worked Example

AiTM investigation: 3-day reconstruction

Day 1 (Monday 09:14): Victim receives phishing email: “DocuSign — your document is ready for signature.” Link goes to docs-sign.microsoftonline-secure.net — AiTM proxy registered 6 days prior.

Day 1 (09:21): Victim clicks link, enters M365 credentials, approves MFA push.

Day 1 (09:22–09:47): Attacker uses stolen session token. MailItemsAccessed events from IP 185.220.101.44 (Tor exit node). Attacker reads all emails in Inbox and Sent Items. Creates inbox rule: “If subject contains ‘wire’ or ‘payment’, delete immediately.”

Day 1 (09:50): Attacker finds an ongoing vendor payment thread. Impersonates victim and emails finance team requesting account number change.

Day 2 (Tuesday): Finance team processes the changed account. Wire transfer of $340,000 sent.

Day 3 (Wednesday): Real vendor calls asking about overdue payment. Investigation begins.

Log artifacts available (Day 3 investigation):

Phishing email delivery event (Monday 09:14) in Exchange message trace
Entra ID sign-in log (Monday 09:21) — normal IP, MFA satisfied
Entra ID sign-in log (Monday 09:21, 3 seconds later) — IP 185.220.101.44, MFA already satisfied (session token reuse)
MailItemsAccessed events (Monday 09:22–09:47) from 185.220.101.44
New-InboxRule (Monday 09:50) — delete messages matching “wire” or “payment”
Sent email (Monday 09:51) — from victim’s account to finance team with changed bank details

Containment sequence:

Remove inbox rule immediately (before notifying victim — rule deletes alerts)
Revoke all active sessions for victim (Revoke-AzureADUserAllRefreshToken)
Force MFA re-registration
Escalate to finance for wire recall
Check all emails sent from victim’s account Days 1–3 for further attacker activity
Check if attacker replied to any external parties using victim’s account

ATT&CK Tags:

T1566.002 — Spearphishing Link
T1557 — Adversary-in-the-Middle
T1528 — Steal Application Access Token (session cookie)
T1114.002 — Email Collection: Remote Email Collection
T1534 — Internal Spearphishing (vendor account change email)

Retrieval Practice

An AiTM investigation shows the victim's Entra ID sign-in logs have two entries at 09:21:14 and 09:21:17 (3 seconds apart). The first is from the victim's known corporate IP; the second is from a Linode VPS IP. Both show MFA satisfied. What does this pattern tell you, and what is your immediate next pivot?

Reveal answer

The 3-second gap with MFA already satisfied on the second entry is the diagnostic signature of AiTM session token replay. The first entry is the victim completing the real MFA challenge through the proxy. The second entry (3 seconds later, different IP) is the attacker replaying the captured session token — MFA is shown as satisfied because it was satisfied on the victim's side. The session is now active from the attacker's IP. Immediate next pivot: search MailItemsAccessed events for the Linode IP from 09:21 onward — this tells you what the attacker read and when they began acting.

Retrieval Practice

In a BEC investigation, you find the victim's mailbox has a New-InboxRule that moves emails from 'finance-alerts@corp.com' to the Deleted Items folder. The rule was created 2 days ago. What is the attacker's intent, and what must you do before notifying the victim?

Reveal answer

The inbox rule suppresses finance notification emails — when the finance team tried to verify the payment change or received a fraud alert, those messages were silently deleted from the victim's view. The victim never saw the alerts. Intent: maintain the fraud for as long as possible by filtering out verification and alert emails. Critical: remove the inbox rule BEFORE notifying the victim. If you notify the victim first, and the attacker still has active session access, they see the security team's notification email arrive, know they've been detected, and may escalate (exfiltrate more data, lock the victim out, send more BEC from the account). Contain first, then communicate.