Business Email Compromise Outearns Ransomware

Business email compromise became the most expensive category of cybercrime without using any technology worth describing. No malware, no exploit, no command and control infrastructure. An email that looks like it came from the chief executive, sent to someone in finance who has been told that this transaction is urgent and confidential, asking them to do the job they do every day. By the middle of the 2010s the numbers had become impossible to ignore. Law enforcement advisories tracked cumulative reported losses climbing from the hundreds of millions into the billions over successive updates, and the trajectory kept steepening. One networking equipment manufacturer disclosed in August 2015 that it had lost roughly $46.7 million through fraudulent transfer requests impersonating employees, recovering only part of it. That was a single company, a single scheme, and it exceeded the direct cost of most of the malware incidents that dominated security coverage that year.

Why the cheapest attack outperformed the sophisticated ones

The security industry in 2015 was built around detecting malicious code. Endpoint protection, network intrusion detection, sandboxing, signature updates — an entire architecture premised on the assumption that an attack contains something technically identifiable. Business email compromise contains nothing identifiable. The message is plain text. The sender may be a lookalike domain registered the previous week, a display name that renders correctly on a mobile client, or — in the more advanced version — an actual compromised mailbox belonging to a real supplier. There is no payload to scan and no anomaly to flag. Every technical control in the environment inspects the message, finds nothing wrong, and delivers it. The attack then targets the least-defended layer in any organisation: a person operating under authority pressure, time pressure and secrecy. The social engineering is not elaborate. It relies on three things being true in most companies — that senior executives sometimes make unusual requests, that questioning them is uncomfortable, and that payment processes have an exception path for urgency. The return on investment for the attacker is extraordinary. A domain registration, an hour of research on a public website and a professional networking profile, and a plausible email. Against that, a successful transfer of six or seven figures.

The variants that matter operationally

The original form was executive impersonation, and it remains the one people recognise. An email from the chief executive or finance director to a payments clerk, requesting an urgent transfer for a confidential acquisition, instructing the recipient not to discuss it. The more damaging variant is supplier invoice redirection. The attacker either spoofs or actually compromises a supplier's mailbox, watches the correspondence, waits for a genuine invoice cycle, and sends a notification that the supplier's bank details have changed. Everything about the transaction is legitimate — the invoice is real, the goods were delivered, the amount is correct — except the account number. Detection typically happens weeks later when the real supplier asks for payment. Payroll diversion works the same way at smaller amounts and higher volume: an email purporting to be from an employee asking HR to update their salary account before the next run. And professional-services impersonation exploits transaction moments — a message during a property purchase or a corporate deal, from someone appearing to be the lawyer or agent, providing settlement account details. What unites all of them is that the fraud exploits a process, not a system. Which means the fix is also a process, not a product.

Why technical controls only get you partway

Email authentication is worth implementing and it addresses a subset of the problem. Sender policy records, message signing and domain-based authentication policies make it materially harder for an attacker to send mail that appears to originate from your own domain, and a strict enforcement policy blocks exact-domain spoofing outright. They do nothing about lookalike domains, which is the more common technique. A domain that differs from yours by one character, or that swaps a country suffix, will pass every authentication check because it is properly configured mail from a domain the attacker genuinely controls. They also do nothing about a compromised legitimate mailbox, which is the hardest variant. When the email genuinely comes from your supplier's account, sent by an attacker who has been reading the thread for a month, there is no sender-level signal available at all. The controls that actually stop the loss sit in the payment process: verification of bank detail changes through a channel the attacker does not control, dual authorisation above thresholds, and a culture in which a payments clerk can decline an urgent request from an executive without professional risk. That last one is the cheapest control available and the one organisations are worst at building.

Practical Guidance for Payment Fraud Prevention Review

• Require out-of-band verification for every bank detail change, without exception. Call a number already on file — never a number from the email requesting the change. This single control prevents the majority of supplier redirection losses.
• Make dual authorisation mandatory above a defined threshold and remove the override. Most losses occur through an exception path that exists for urgency. The exception path is the vulnerability.
• Explicitly authorise staff to refuse and verify requests from senior executives. Say it publicly, from the top, and mean it. If declining the chief executive's urgent email is career-limiting, the control does not exist.
• Register and monitor lookalike domains. Common misspellings, character substitutions and alternate suffixes. Monitoring new registrations resembling your domain gives early warning of a campaign being prepared.
• Implement full email authentication and move to an enforcing policy. It eliminates exact-domain spoofing, which is the easiest variant to run against you.
• Flag external mail visibly in the client. A banner on messages from outside the organisation defeats display-name impersonation for most recipients most of the time.
• Train against realistic scenarios rather than generic phishing. Use your own payment process, your own supplier names and your own executive titles. Generic awareness training does not transfer to this attack.
• Rehearse the recovery clock. Recall attempts have a short window. Know which bank contact to call, who authorises a recall, and what law enforcement reporting route applies — before you need it at 4pm on a Thursday.

The Regional Dimension

The Gulf is an unusually attractive target for this category of fraud, and the reasons are structural. Cross-border payments are routine. A regional trading group paying suppliers in Asia, Europe and elsewhere in the Middle East generates a constant flow of international transfers in multiple currencies. An unusual destination account raises no flags in an environment where unusual destination accounts are normal, and this is precisely the condition attackers look for. Hierarchy and deference amplify the executive impersonation variant. In organisations where a direct instruction from a senior figure is not typically questioned by a junior staff member, the social engineering requires less skill. This is not a regional stereotype so much as an observation about which control — the authorisation to say no — needs the most deliberate investment here. Language and identity confusion help the attacker. Correspondence moves between Arabic and English, supplier names appear in multiple transliterations, and the same counterparty may exist under a legal Arabic name and an English trading name. A slightly wrong name on a payment instruction is unremarkable in that environment. Duplicate supplier master records, created by exactly this inconsistency, make it harder to spot that a bank account has changed against the wrong record. Channel behaviour is the third factor. Business in the region runs substantially over messaging apps, and payment instructions and bank details genuinely circulate that way. A WhatsApp message from a number claiming to be the finance director, with a photograph of a signed instruction attached, fits normal practice closely enough to work. Any payment fraud review in a Gulf organisation that only examines email is examining half the attack surface. Finally, multi-entity structures dilute control. A group with mainland, free-zone and Saudi entities frequently has different banking relationships, different authorisation matrices and different finance staff per entity, with the smallest entity having the weakest controls. Attackers research this. The target is rarely the head office.

The objection worth taking seriously

The legitimate pushback is that verification controls impose real friction on legitimate business, and that the cost of that friction is borne every day while the fraud may never arrive. Calling every supplier to confirm a bank change slows payment runs. Dual authorisation above a low threshold means senior people spend time approving routine transactions. A culture of challenge, applied indiscriminately, can slow decisions that genuinely are urgent. For a business where working capital timing matters and supplier relationships depend on paying promptly, these are not trivial costs. The honest response is to calibrate rather than to universalise. Verification on bank detail changes is non-negotiable because that is where the money is lost and the frequency of legitimate changes is low. Dual authorisation should be set at a threshold derived from your actual transaction distribution, not at a number copied from a policy template. And the challenge culture should be specific — staff are authorised to verify payment instructions — rather than a general licence to question everything. There is a harder version of the objection: most organisations that implement these controls still get hit, because the attack adapts to whatever process exists. That is partly true, and it argues for detection and recovery capability alongside prevention rather than for abandoning prevention. The organisations that lose the least are not the ones that never get targeted; they are the ones that notice within hours rather than weeks.

Common Questions

What is the single highest-return control?

Out-of-band verification of bank account changes using contact details already held on file. Supplier redirection accounts for a large share of total losses and this control addresses it directly, at low operational cost, because genuine bank detail changes are rare.

Does email authentication solve this?

It solves exact-domain spoofing, which is worth eliminating. It does not address lookalike domains or compromised legitimate supplier mailboxes, which together account for most successful attacks. Implement it and do not treat it as the answer.

How quickly must we act after a fraudulent payment?

Immediately — recall prospects fall sharply within the first day and continue falling. Have the bank escalation contact, the internal authoriser and the law enforcement reporting route documented in advance, and treat the first hour as an incident response scenario rather than a finance query.

How does AI change this attack?

It removes the remaining tells and adds new channels. The grammatical errors and tonal mismatches that alert experienced staff are gone; messages can be generated in fluent Arabic and English matching an executive's actual writing style drawn from public material. Voice cloning has already been used in this fraud category, which means telephone verification against a familiar voice is no longer sufficient on its own — verification needs to run against a known number or a pre-agreed challenge, not against recognising who is speaking. The controls that survive are procedural ones; the ones that relied on human detection are eroding quickly.

---

Payment Fraud Prevention Review — this is the one attack category where the effective controls sit in the finance process rather than in the security stack, which is exactly why it keeps working.