13.1 Understanding BEC Attack Mechanics

4-6 hours · Module 13

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?

Defender for Office 365 detects malicious content — URLs, attachments, and known phishing patterns. A BEC email contains none of these. It is a legitimate email from a real account discussing a real transaction. The only malicious element is the bank account number change buried in the message body — and there is no detection signature for "wrong bank account number." BEC detection requires behavioural analysis (unusual sending patterns, thread hijacking from different IPs) rather than content analysis.
Defender was not enabled
The email was encrypted
BEC emails are always detected if Safe Links is enabled

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?

Two purposes. First, the attacker intercepts vendor replies — when the real vendor replies to the thread confirming the original (legitimate) bank details, the inbox rule hides this reply from the legitimate user so they do not see the contradiction with the fraudulent instructions. Second, the attacker gets copies of all payment-related emails for ongoing reconnaissance. The rule targets the specific keywords that appear in financial transactions.
To delete spam emails
To organise the user's inbox
To forward emails to the IT department

3. The payment recovery window for a wire transfer is typically 24-72 hours. How does this affect your investigation priority?

Financial impact assessment (subsection 13.6) becomes time-critical. If the fraudulent payment was sent, every hour of delay reduces the probability of recovery. The investigation must determine whether the payment was sent BEFORE completing the full technical investigation. If sent: engage the bank immediately (subsection 13.8) to attempt recall. The technical investigation continues in parallel but the financial recovery window takes priority over forensic completeness.
Complete the full investigation before contacting the bank
The recovery window does not affect investigation priority
Wait for law enforcement before contacting the bank