Why BEC defeats technical controls
Most email security works by finding something bad in the message: a known-malicious URL, a suspicious attachment, a script. A BEC message contains none of those. It is a short, plausible, well-written note asking a colleague to update some bank details or push a payment through before end of day.
There is nothing for a scanner to detect, because nothing in the message is technically wrong. The fraud lives entirely in the meaning of the words and the identity of the sender, and both of those are judgement calls a filter cannot make. That is the whole reason BEC produces disproportionate financial losses relative to how few messages are sent.
The common variants
| Variant | Who is impersonated | What is asked for |
|---|---|---|
| CEO fraud | A senior executive | An urgent, confidential transfer, often while they are travelling |
| Invoice or mandate fraud | A real supplier | A change of bank details on a genuine outstanding invoice |
| Vendor email compromise | Nobody - the real supplier account is used | A reply in an existing thread with new payment details |
| Payroll diversion | An employee, to HR | A change of salary destination account |
| Attorney impersonation | A lawyer handling a confidential matter | Secrecy plus urgency around a transfer |
| Gift card scam | A manager | Vouchers bought and codes photographed - the low-value entry version |
The pattern across all six is identical: an authority figure, a payment, a deadline, and a reason not to check. Where the message is hand-written for one target using real research, it is also spear phishing - the two labels describe the same message from different angles.
What actually stops it
Because the message is not technically detectable, the control has to sit in the payment process rather than in the mail flow.
- Make verification mandatory and boring. Any change of bank details is confirmed by calling a number already on file - never a number from the message, and never by replying to the thread. Two minutes closes most of this category.
- Require two people for payments above a threshold, so no single compromised or pressured individual can complete one.
- Remove urgency as an override. Staff must know that no genuine executive request is damaged by a five-minute verification, and that acting fast is never the priority.
- Tag external mail, so a message claiming to be internal is visibly not.
- Enforce DMARC at reject to end exact-domain spoofing, while accepting it does nothing against lookalike domains or a compromised supplier.
- Monitor mailboxes for new forwarding rules, which is how an attacker quietly reads an invoice thread before joining it.
- Deploy phishing-resistant sign-in for finance and executives, since account takeover is the entry point for the most damaging variant.
If a payment has already gone out, contact the bank immediately and ask for a recall - the first few hours are the only realistic window. The surrounding control set is in how to prevent phishing.