Business Email Compromise: The Billion-Dollar Attack Nobody Detects
BEC needs no malware, no exploit, and no payload. Just a convincing email and a wire transfer. Here is how it works, why tools miss it, and what stops it.
The attack with no payload
Business Email Compromise (BEC) is consistently the most expensive category of cybercrime by reported losses, ahead of ransomware in the FBI's IC3 statistics year after year. Billions of dollars annually, and yet a typical BEC attack contains:
- No malware
- No malicious attachment
- No exploit
- Often no link at all
Just text. An email that asks someone to send money to the wrong place, written convincingly enough that they do it. That is why your sandbox, your EDR, and most of your email security stack never fire. There is nothing to detonate.
How BEC actually works
BEC is a family of social engineering plays that share one goal: divert a payment. The common variants:
Thread hijacking
The attacker compromises a real mailbox (yours or a supplier's) through phishing or credential stuffing, then reads quietly. They wait for an invoice conversation that is already in progress, then reply inside the legitimate thread: "Quick update, we have changed banks, please use the account below for the pending invoice."
This is the most dangerous variant because everything checks out. Real thread, real history, real sender, passing SPF, DKIM, and DMARC, because it really is being sent from the legitimate mailbox. The only false thing in the email is the account number.
Lookalike domains
When the attacker cannot get into a real mailbox, they register a domain one glance away from the real one and continue the conversation from there:
Legitimate: [email protected]
Lookalike: [email protected]
Lookalike: [email protected]
Lookalike: [email protected]
Often they copy the entire quoted thread from the compromised account into the new one, so the recipient sees familiar context. A quick check of the sending domain in mlab.sh tells you a lot here: a "supplier" domain registered nine days ago, with privacy-proxy WHOIS and passive DNS showing only an MX record, is not your supplier of fifteen years.
CEO fraud and vendor impersonation
The blunter versions: an email impersonating an executive ("I need this transfer done before the board call, keep it confidential") or a known vendor with a new invoice. These rely on urgency, authority, and secrecy to short-circuit normal process. Gift card variants target smaller amounts at higher volume.
Payroll diversion
Same playbook, different target: an email to HR impersonating an employee, asking to update direct deposit details. Small amounts, rarely noticed until payday.
Why technical controls miss it
| Control | Why it fails against BEC |
|---|---|
| Antivirus / sandbox | No payload to analyze |
| SPF / DKIM / DMARC | Pass cleanly when a real mailbox is compromised |
| URL rewriting | Many BEC emails contain no URL |
| Reputation filtering | Lookalike domains are brand new with no bad history |
| User training alone | Thread hijacking defeats every "check the sender" heuristic |
Email authentication answers "did this come from where it claims." It cannot answer "is the bank account in this email correct." That question has no technical answer, which is why the strongest BEC defenses are process controls, not products.
The process controls that actually stop it
- Out-of-band verification for banking changes. Any change to payment details gets confirmed by phone, using a number from your vendor master record, never from the email requesting the change. This single rule defeats the majority of BEC attempts.
- Dual approval above a threshold. Two humans sign off on any transfer above a defined amount. The attacker now needs to fool two people through separate channels.
- Cooling-off period for new beneficiaries. A 24 or 48 hour delay on first payments to a new account gives detection and doubt time to work.
- Make verification blameless and expected. Finance staff must feel safe delaying a "CEO-urgent" payment to verify. If your culture punishes the delay, your controls exist only on paper.
Detection ideas for the SOC
You will rarely detect the fraudulent email. You can often detect the account compromise that precedes it:
- Authentication anomalies: sign-ins from new countries or ASNs, impossible travel, logins from hosting providers or anonymizing VPNs against a mailbox that normally sees one office IP.
- Mailbox rule creation: attackers almost always create inbox rules to hide their tracks, auto-deleting or moving replies containing words like "invoice", "payment", or "bank". Alert on new rules that delete or forward, especially rules created minutes after a risky sign-in.
- OAuth consents and new app registrations on mail accounts.
- Lookalike domain monitoring: watch new registrations resembling your domains and your top suppliers' domains, and enrich anything suspicious before it is used against you.
- Unusual send patterns: a mailbox that suddenly emails only one finance contact, or sends from mobile at odd hours.
None of these are exotic. Most tenants already log all of it; the gap is usually that nobody wrote the detections.
Response: the clock is the whole game
When a fraudulent transfer is discovered, treat it as a financial emergency first and a forensic case second.
- Call your bank immediately and request a recall or SWIFT stop on the transfer. Domestic transfers can sometimes be frozen within hours; international mule accounts are typically drained within one to two days. Every hour matters.
- Report to law enforcement fast. In the US, the IC3 Recovery Asset Team can trigger a Financial Fraud Kill Chain on international wires, with meaningful success rates when engaged within 48 hours. Other jurisdictions have equivalents; know yours before you need them.
- Contain the mailbox: reset credentials, revoke sessions and app passwords, remove attacker inbox rules and OAuth grants, check delegate access.
- Scope the compromise: how long was the attacker reading? Which threads? Which other counterparties saw emails from the compromised account? They are victims-in-waiting and should be notified.
- Preserve evidence: message traces, sign-in logs, the fraudulent emails with full headers, before retention windows eat them.
- Review the process failure. A BEC loss is almost always a control gap wearing an email costume. Fix the verification step that failed, not just the mailbox.
If you handle incidents more than occasionally, capture these steps as a short decision-oriented runbook with owners and phone numbers filled in. A platform like mlab IR can hold the playbook, the timeline, and the evidence trail in one place, which beats reconstructing the sequence from memory during litigation.
BEC wins because it attacks your process, not your perimeter. Verify banking changes out of band, watch for mailbox rules, and know your bank's recall number by heart. The attack is boring. So is the defense. It works anyway.
