13.1 Understanding BEC Attack Mechanics
Understanding BEC Attack Mechanics
BEC is not a technical exploit. It is a social engineering attack executed through a compromised or spoofed email account. The attacker’s weapon is trust — trust in the sender’s identity, trust in an ongoing email thread, and trust in the urgency of a financial transaction. Technical controls detect the infrastructure. BEC exploits the human process.
The five types of BEC
The FBI classifies BEC into five categories. Each requires a different investigation approach.
Type 1: Vendor invoice fraud (payment diversion). The attacker monitors email threads between the victim organisation and a vendor. When a legitimate invoice is due for payment, the attacker sends an email — from the compromised mailbox or a spoofed address — instructing the victim to send payment to a different bank account. The email appears to come from the vendor (or from an internal employee who manages vendor payments). This is the most financially damaging BEC type and the scenario in this module.
Type 2: CEO fraud (executive impersonation). The attacker impersonates a senior executive (CEO, CFO) and emails an employee in finance or accounts payable requesting an urgent wire transfer. The email typically claims urgency (“I need this processed before the board meeting”), confidentiality (“do not discuss this with anyone”), and authority (“I’ve already approved this with the bank”). The attacker relies on the employee’s reluctance to question an executive.
Type 3: Account compromise. The attacker compromises an employee’s email account and sends payment requests to the employee’s contacts — vendors, clients, or internal colleagues. The requests appear legitimate because they come from a real, trusted email address. This is the type that follows AiTM credential compromise (Module 12).
Type 4: Attorney impersonation. The attacker impersonates a lawyer or legal firm, typically in the context of a confidential transaction (M&A, litigation settlement). The urgency and confidentiality framing discourages the victim from verifying the request through normal channels.
Type 5: Data theft. The attacker targets HR or finance employees to obtain employee PII (tax forms, bank details, Social Security numbers) rather than direct payment. Less immediate financial impact but significant regulatory exposure (data breach notification obligations).
The BEC kill chain
BEC follows a predictable kill chain. Each stage maps to specific log sources and investigation queries.
Stage 1: Mailbox compromise (or domain spoofing). The attacker gains access to a mailbox via AiTM phishing (Module 12), credential stuffing, password spray, or consent phishing (Module 15). Alternatively, the attacker spoofs the sender domain without compromising any account. Investigation: SigninLogs, AuditLogs for compromised accounts; EmailEvents authentication headers for spoofed senders.
Stage 2: Reconnaissance. The attacker reads the victim’s email to identify: active vendor relationships, pending invoices, payment schedules, internal approval processes, and the individuals involved in financial transactions. This stage can last days or weeks — the attacker is patient because a well-researched fraud attempt has a higher success rate. Investigation: CloudAppEvents (MailItemsAccessed) from attacker IP.
Stage 3: Persistence and stealth. The attacker creates inbox rules to: intercept replies from the targeted vendor (redirect to a hidden folder so the legitimate user does not see them), delete security notifications, and forward copies of relevant email threads to an external address. Investigation: CloudAppEvents (New-InboxRule, Set-InboxRule).
Stage 4: Thread hijacking. The attacker replies to a legitimate email thread — inserting themselves into an existing conversation about a real invoice or payment. Because the reply appears in the existing thread, the recipient trusts it as a continuation of a conversation they are already having. The attacker modifies the payment details (bank account, routing number) in the reply. Investigation: EmailEvents (reply from different IP than previous thread messages).
Stage 5: Fraud execution. The recipient processes the payment to the attacker’s account. Once the wire transfer is sent, the attacker moves the funds through multiple accounts to prevent recovery. The window for payment recovery is typically 24-72 hours — after that, the money is gone. Investigation: this stage occurs outside M365 — the evidence is in the email thread, not in log data.
Stage 6: Evidence destruction. The attacker deletes sent emails from the compromised mailbox, removes inbox rules, and may revoke their own access to reduce forensic evidence. Investigation: CloudAppEvents (HardDelete, SoftDelete), AuditLogs (Remove-InboxRule).
Why BEC bypasses technical controls
No malware. BEC uses legitimate email functionality — no attachments to scan, no executables to detonate, no URLs to check (or the URLs point to legitimate sites like bank portals). Defender for Office 365 has nothing to flag.
No anomalous sign-in (in account compromise BEC). If the attacker compromised the account via AiTM, the sign-in may already be addressed. But the BEC activity itself — reading email, sending replies — is normal user behaviour. There is no detection rule for “user reading email about invoices.”
Trust exploitation. The email comes from a known sender, appears in an existing thread, discusses a real transaction, and requests a payment the recipient was already expecting to make. The only difference is the bank account number — and that difference is buried in the body of an email that looks entirely legitimate.
The detection challenge: BEC detection is not about finding malicious content. It is about finding anomalous communication patterns — emails sent from unusual IPs, replies to threads that arrive from different infrastructure than previous messages, and inbox rules that intercept specific keyword patterns.
BEC vs AiTM: the investigation difference
Module 12 (AiTM) focuses on the initial access and credential compromise. The investigation traces: phishing email → URL click → token capture → token replay → persistence.
Module 13 (BEC) focuses on what the attacker does with the compromised access. The investigation traces: mailbox reconnaissance → thread monitoring → inbox rule creation → thread hijacking → fraudulent email → financial impact.
The attacker is the same. The kill chain is sequential. AiTM is the entry. BEC is the objective. Some incidents involve both (the Northgate Engineering scenario in M11 included a BEC attempt in Wave 5). This module teaches the BEC-specific investigation skills that Module 12 introduced but did not cover in depth.
Subsection artifact: The BEC kill chain table mapping each stage to its data source and investigation query. This is the first section of your BEC investigation playbook.
Knowledge check
Check your understanding
1. A BEC email contains no malicious URLs, no attachments, and comes from a legitimate internal email address. Why does Defender for Office 365 not flag it?
2. The attacker creates an inbox rule that redirects emails containing "invoice," "payment," and "bank details" to a hidden folder. What is the operational purpose?
3. The payment recovery window for a wire transfer is typically 24-72 hours. How does this affect your investigation priority?