Threat Hunting Exercise: Analyzing Email BEC Wire Fraud Payment Redirect Dataset

This hunt uses a simulated email gateway/M365 dataset (email_bec_wirefraud_2022-07-09T080000.json) capturing T1586.002: Compromise Accounts - Email Accounts combined with social-engineering-driven financial fraud, where an adversary either compromises or closely spoofs a vendor's email account and inserts themselves into an active invoice-payment thread to redirect a wire transfer to an attacker-controlled bank account.

Step 1: Hypothesis Formation

Hypothesis: An email thread between an internal Accounts Payable user and an external vendor contact shows a mid-thread change in the sender's return-path/reply-to domain (a lookalike domain differing by one character, or a legitimate-looking but newly-registered domain) coinciding with a request to update banking/wire details, and the display name is preserved to visually match the real vendor contact. Indicators:

• Email headers: From display name matches the known vendor contact, but Reply-To or return-path domain differs subtly from the vendor's established domain (e.g., vendor-corp.com vs vendor-corp.co).
• Message content requests updated banking details, urgency language ("please process today", "our bank changed"), and discourages phone verification.
• DMARC/SPF/DKIM authentication results show a fail or none for the suspicious message, while prior legitimate thread messages passed.
• Domain WHOIS for the lookalike domain shows recent registration (days before the message).

Null Hypothesis: The vendor legitimately changed banking details as part of normal business operations (e.g., a genuine bank migration), and the domain difference is a red herring (e.g., a legitimate secondary domain). Invalidate via out-of-band verification (phone call to a previously-known-good number, not one provided in the suspicious email) and domain-authentication result review.

Rationale: BEC attacks defeat most technical controls because the email often passes basic spam filtering and relies entirely on human trust within an existing business relationship; this hunt validates detection via authentication-result and domain-lookalike analysis layered onto thread-continuity monitoring.

Step 2: Data Sources and Scope

• Sources: Email gateway/M365 message trace (headers, authentication results); DNS/WHOIS enrichment for sender domains; Accounts Payable transaction logs (for the null-hypothesis/impact check).
• Scope: ~2022-07-09T08:00:00-09:30:00 UTC; Internal user: ap-clerk@contoso.com; Vendor thread: "Invoice #48221 - Payment Due"; Lookalike domain: vendor-corp.co (legitimate is vendor-corp.com).
• SIEM Queries (Splunk/ELK or M365 Defender KQL):
• Auth-result mismatch mid-thread: EmailEvents | where Subject has "Invoice #48221" | project SenderFromAddress, AuthenticationDetails, Timestamp | sort by Timestamp asc
• Lookalike domain detection: | extend domain_distance = levenshtein(SenderFromDomain, "vendor-corp.com") | where domain_distance <= 2 and SenderFromDomain != "vendor-corp.com"
• Banking-change keyword filter: EmailEvents | where Body has_any ("updated bank details","new account number","wire instructions")

Step 3: Key Findings

Parsed events (6 shown) confirm a mid-thread sender-domain switch to a one-character lookalike, coinciding with a fraudulent banking-detail update request that failed DMARC.

Validation:

• Timeline: Legitimate thread → mid-thread sender-domain switch → urgency-driven banking-change request → payment processed - the fraud succeeded before detection, making rapid recall the priority.
• False Positives: Ruled out legitimate bank-change via authentication-result contrast (pass on all prior messages, fail on the fraudulent one) and the freshly-registered lookalike domain.
• Correlation: Single thread, single lookalike domain, single fraudulent request - a clean, classic BEC case.

Step 4: Recommendations & Next Steps

• Immediate Response: Contact the receiving bank immediately to attempt a wire recall/hold (time-critical - success rate drops sharply after 24-48 hours); notify law enforcement (FBI IC3 for US-based incidents) and file a report; contact the real vendor via a previously-known-good phone number to confirm their actual banking details were never changed; block the lookalike domain at the email gateway.
• Detection: Sigma/KQL-style rule: title: Mid-Thread Sender Domain Change with Authentication Failure → selection: same Subject/thread_id AND SenderFromDomain differs from prior messages AND AuthenticationDetails != pass - this pairing is high-signal and should be a standing real-time control, not just a hunt.
• Pro Tip: Implement a mandatory out-of-band verification policy for any banking-detail change request, regardless of how legitimate the email appears - require a phone call to a number from an existing, trusted record (never a number provided in the request email itself) before processing any payment-instruction change over $X threshold.

Hypothesis confirmed - a mid-thread BEC attack using a one-character lookalike domain successfully redirected an $84,500 wire payment before detection!