Business email compromise carries no malicious link and no attachment. There is nothing for a scanner to find, which is exactly why it works.
The short answer
Business email compromise, or BEC, is a fraud in which an attacker impersonates someone trusted and asks a person to move money or send data. There is usually no malware involved. The message is plain text, it references a real transaction, and it arrives at a plausible moment. The target is a business process, not a system.
That distinction decides which defences matter, because most of the email security stack is built to find things this attack does not contain.
On this page
Why BEC evades email security
| What is missing | Why it matters |
|---|---|
| No malicious attachment | Sandboxing has nothing to detonate |
| No link to a fake login page | Reputation and rewriting have no destination to check |
| No malware | Endpoint protection is never engaged, because nothing is executed |
| Low volume | A handful of messages to named individuals, not a campaign that trips volume analysis |
| Genuine context | Real invoice numbers, real project names and correct timing, often taken from prior reconnaissance |
The five BEC variants
| Variant | How it runs |
|---|---|
| Executive fraud | A message appearing to come from a founder or finance lead requesting an urgent transfer, usually while they are known to be travelling |
| Supplier invoice fraud | A real supplier relationship is used to request that bank details be updated on the next invoice. The costliest variant, because the amount is expected and the payment is routine |
| Payroll diversion | A request to human resources to change an employee’s salary account, timed just before a pay run |
| Legal or acquisition pretext | Confidentiality is used to prevent the target from verifying with anyone else, often framed around a deal or an audit |
| Data request | No money at all. Tax records, employee details or customer data are requested, which is then used to make a later fraud far more convincing |
Supplier fraud is the one to plan for
Executive fraud gets the attention, but a request from a founder to move money is unusual enough that a careful employee may pause. A supplier asking to update bank details is not unusual at all. The invoice is genuine, the amount matches an existing order, the sender knows the history of the account, and paying it is somebody’s routine job. Companies that train staff only to be suspicious of the chief executive remain exposed to the variant that empties more accounts.
Three ways they impersonate
| Method | What it looks like | What limits it |
|---|---|---|
| Lookalike domain | A registered domain one character away from the real one, or a different top-level extension | Detection of newly registered and visually similar domains, plus external sender tagging |
| Display name spoof | The name shown reads correctly while the underlying address is a free mail account. Effective because mobile clients hide the address | Header analysis and warning banners on mismatch |
| Compromised real account | The attacker is signed in to a genuine mailbox, often a supplier’s, and replies inside an existing thread | Nothing in the mail itself. Only MFA, sign-in anomaly detection and out-of-band verification |
The third method passes every authentication check
Domain authentication protects your domain from being forged. It cannot help when the mail is genuinely sent from the account it claims, because the attacker has the password. Every signature validates, alignment passes, the message arrives inside a thread the recipient started, and the reply quotes the conversation above it. This is why account takeover and BEC are the same problem viewed from two ends, and why enforcing multi-factor authentication across suppliers matters as much as enforcing it internally.
What actually stops it
Because a BEC message is technically legitimate, the controls that work are procedural. They are cheap, and they are the part most companies skip.
| Control | How it works |
|---|---|
| Out-of-band verification | Any bank detail change or unusual payment confirmed by phone, on a number already on file, never one supplied in the email |
| Dual authorisation | A second person approves payments above a threshold, so no single compromised mailbox completes a transfer |
| A written bank change process | Updates to supplier account details follow a fixed procedure regardless of who asks or how urgent it sounds |
| Removing urgency as an override | Staff are told explicitly that no real executive will penalise them for verifying. Urgency is the pressure the whole attack depends on |
| External sender tagging | A visible banner on mail from outside the organisation, which defeats most display name spoofing at a glance |
| MFA everywhere | Prevents the account takeover that makes the hardest variant possible |
Where Osto fits
Osto reduces the two impersonation methods that live in the mail itself. Inbound email security flags lookalike domains and display name mismatches before delivery, and content filtering limits reach to the credential harvesting pages that lead to account takeover in the first place.
The harder variant is addressed from the identity side. Multi-factor authentication and identity and access management make a mailbox takeover materially harder, and because sign-in events and mail events land in the same SIEM, an unfamiliar login followed by mailbox rule changes reads as one pattern rather than two unrelated entries in separate tools. Security awareness training covers the recognition side, and the incident response plan covers what to do in the hour after a payment goes out, when recovery is still possible.
What no security platform provides is the payment control. Out-of-band verification and dual authorisation are decisions your finance function makes, and they stop more BEC than any product does. Documented alongside the technical controls, they also satisfy what SOC 2 and ISO 27001 Annex A expect around authorisation and segregation of duties.
Platform walkthrough
Catch the login, not just the email
Inbound email security, enforced MFA and identity events correlated in one SIEM, so a mailbox takeover shows up as a pattern instead of a surprise.
Book a demoEvidence from live controls · 200+ frameworks mapped · One platform, everything
Frequently asked questions
What is BEC?
Business email compromise is a fraud in which an attacker impersonates a trusted party, usually an executive or a supplier, and asks someone to transfer money, change bank details or send sensitive data. It generally carries no malware.
What is the difference between BEC and phishing?
Phishing typically wants a credential and uses a link to a fake login page. BEC wants an action, most often a payment, and often contains no link at all. Phishing is frequently sent in volume, while BEC targets a named individual with real business context.
Does email authentication stop BEC?
Partly. Domain authentication stops attackers forging your own domain, which removes one method. It does nothing against lookalike domains, display name spoofing or mail sent from a genuinely compromised account.
What is the single most effective control?
Verifying bank detail changes by phone, using a number already held on file rather than one given in the message. It is free, and it defeats every variant including the one sent from a real compromised mailbox.
What should you do after a fraudulent payment?
Contact the bank immediately and request a recall, because the first hours matter most. Preserve the mail headers, check the mailbox for forwarding rules the attacker may have created, reset credentials, and report it to the relevant authority. Your incident response plan should already name who does each of these.