Business email compromise: designing the process that stops it

Business email compromise consistently causes larger aggregate losses than ransomware, and it typically involves no malware at all. There is nothing to detect on an endpoint, nothing to quarantine, and often nothing technically wrong. The attack targets a business process, and that is where the defence has to be.

How it actually runs

• Vendor impersonation. The most costly variant. An attacker - often inside a compromised supplier mailbox - sends updated bank details for a legitimate, expected invoice. Everything about it is genuine except the account number.
• Executive impersonation. A request from a senior figure for an urgent confidential transfer, exploiting deference and time pressure.
• Payroll diversion. An employee appears to request a change of bank details for salary.
• Account takeover. The attacker is genuinely inside a mailbox, reading threads and choosing the moment - which is why the message reads perfectly.

Note what the strongest variant does not require: it does not need to spoof anything, because the mail genuinely comes from the supplier's real account. Email authentication does not help, and neither does a banner saying the sender is external.

Why technical controls under-perform here

DMARC at enforcement stops people sending as your domain. It does nothing about a compromised supplier mailbox, a lookalike domain the attacker legitimately registered, or a display name that reads convincingly on a phone. Filtering struggles because the message contains no malicious payload - it is text asking for something plausible.

These controls are still worth having. They just do not address the loss scenario.

The control that works

Out-of-band verification for any change to payment details, using contact details you already hold. Not a number in the email. Not a number on the invoice. The number in your vendor master record, called by a person.

Around it:

• Dual authorisation for bank detail changes and for payments above a threshold, with the second approver verifying independently.
• A mandatory cooling period on new or changed payee details before the first payment.
• Verification of the requester, not the request - confirm through a channel the attacker does not control.
• An explicit policy that urgency never overrides verification, stated by leadership so nobody fears causing offence by following it.

The cultural half

Every one of these attacks depends on someone feeling unable to challenge. A finance clerk who receives an urgent instruction apparently from a director is being asked to choose between a rule and a hierarchy.

The only durable fix is leadership stating plainly and repeatedly that verification is expected, that no legitimate request will ever require bypassing it, and that following the process during a convincing call is the correct behaviour even when it turns out to be genuine. Say it before an incident, not in the post-mortem.

Detection and response

Watch for the artefacts of account takeover: new mailbox rules that hide or forward messages, unusual sign-in geography after a successful MFA, and mass mailbox searches. Rule creation is the most common first action and is trivially detectable if anyone is looking.

If a payment has gone: contact the bank immediately - rapid recall is sometimes possible within hours - report to law enforcement, notify your insurer, and check for the mailbox rules that reveal how long the attacker had been reading.

Key takeaways

• The costliest variant uses a genuine supplier mailbox - authentication does not help.
• Verify using contact details you already hold, never ones supplied in the request.
• Leadership must state that urgency never overrides verification.
• Watch for new mailbox rules - the most common first action after takeover.