Business email compromise (BEC)

BEC exploits process, not software. The attacker gets into a real conversation, either by taking over a mailbox after a spear phishing capture, or by sending from a look-alike domain that passes a casual glance. From inside the thread they wait for a genuine transaction (a supplier invoice, a property completion, a payroll change) and then intervene: new bank details, an urgent request from a named executive, a request to bypass the usual checks “just this once”. Because the account and the context are legitimate, there is no exploit to detect. The control that decides the outcome is human: whether a change of payment details triggers an out-of-band verification.

There is nothing for an antivirus to catch, which is precisely why it works. From the attacker’s side, the effort is social: build authority, add time pressure, and target the one person who can move money and who trusts the sender. In the cases we simulate, the failure is a payment process that accepts a change of bank details over email alone, or an executive whose account is trusted implicitly. A convincing voice or video using a deepfake now raises the ceiling further, but most successful BEC still needs nothing more than a plausible email and a gap in the approval chain.

We assess BEC exposure from two angles: the email path and the payment process. On email we check whether inbound spoofing is stopped by an enforced DMARC policy and whether account takeover is contained by conditional access. On process we test whether a change of payee survives without out-of-band confirmation. The finding is written against the missing control, with the financial impact stated plainly. This is part of how we test the payment and email path.