Business Email Compromise (BEC): How It Works and How to Stop It

Business email compromise (BEC) is fraud that gets a company to send money to a criminal because an email looked like it came from someone the company trusts. The ask is ordinary: pay this invoice to our new account, wire the deposit for the acquisition, update my direct deposit before Friday. Most BEC messages carry no malware and no link, so there is nothing for a filter to detonate.

The FBI's 2025 IC3 Annual Report recorded 24,768 BEC complaints and $3,046,598,558 in reported losses for 2025, the second-largest loss category after investment fraud. The 2024 figures were 21,442 complaints and $2,770,151,146. An FBI public service announcement in September 2024 counted $55,499,915,582 in exposed losses across 305,033 domestic and international incidents reported between October 2013 and December 2023.

This guide covers the BEC-specific mechanics. For the psychology behind the pretext, see the social engineering playbook. For phishing in general, see what is phishing. For how SPF, DKIM and DMARC work, see SPF, DKIM and DMARC explained.

The BEC variants

Every variant ends with a payment or a data transfer going somewhere new. They differ in who is impersonated and how the attacker gets a voice in the conversation.

CEO or executive fraud. The attacker poses as a senior leader and asks someone in finance for an urgent, confidential transfer, or asks an assistant to buy gift cards. It works through authority and secrecy: the target is told not to discuss it.

Vendor invoice and payment redirection. The attacker poses as a supplier and sends an invoice, or a notice that the supplier's bank details have changed. It rides on a real supplier, real invoice numbers and a payment that was due anyway.

Account compromise. The attacker takes over a real employee's mailbox and uses it to bill that employee's customers or to approve payments internally. Every authentication check passes, because the mail comes from the genuine system.

Attorney impersonation. The attacker poses as a lawyer handling a confidential deal or a property closing. The 2025 IC3 report describes a couple closing on a home who received an email impersonating their own attorneys and wired more than $449,000. Once the IC3 Recovery Asset Team asked for a freeze, the receiving bank confirmed the full amount was still in the account and on hold.

Payroll diversion. The attacker emails HR or payroll as an employee and asks to change the direct deposit account. The FBI's 2019 BEC update noted that the new account generally leads to a prepaid card. A second form, described in a 2018 FBI warning, phishes the employee's payroll portal login, changes the deposit account there, and adds rules that stop the employee seeing the change alerts.

Freight and logistics fraud. Brokers, carriers and shippers are a natural target because they run on email, rate confirmations and fast payment. Three patterns recur. Double brokering: a party takes a load and re-brokers it without authorization, collects payment, and leaves the hauling carrier unpaid. Carrier identity theft: a fraudster uses another carrier's USDOT number, or brokers without registering, both of which FMCSA classes as fraud and identity theft. Federal law lets only registered brokers who meet the financial security requirements broker interstate freight, and 49 U.S.C. 14916 makes anyone who knowingly allows a violation liable for a civil penalty of up to $10,000 per violation plus liability to the injured party for all valid claims. Remote-access lures: Proofpoint reported on 3 November 2025 that criminals posted fake loads from hijacked load board accounts and sent carriers links to .exe or .msi installers for remote management tools such as ScreenConnect, SimpleHelp, PDQ Connect, Fleetdeck, N-able and LogMeIn Resolve, then used that access to bid on real shipments and steal the cargo.

BEC variants compared

How attackers get in

Display-name spoofing. The From line reads "Dana Morales, CEO" <[email protected]>. Many phone mail apps show only the name, so the address never gets seen. The FBI's BEC guidance tells users to check the full sender address, especially on a phone, and to set clients to show it.

Exact-domain spoofing. The attacker puts your real domain in the From header and sends from their own server. DMARC at p=quarantine or p=reject stops this at receivers that enforce it. Domains still at p=none or with no record stay open to it.

Lookalike domains. The attacker registers a domain that reads like the real one: a swapped letter (kestrelfrieght.example), a doubled or missing letter, rn in place of m, an added word (kestrel-payments.example), a different top-level domain, or an internationalized name that uses Cyrillic or Greek letters and shows as xn-- in its raw form. The attacker controls the domain, so they publish valid SPF, DKIM and DMARC for it, and every check passes.

Compromised mailboxes. The attacker phishes a password or session token for a real mailbox, often a vendor's, and reads it for weeks. The FBI's 2020 warning on cloud email described criminals searching compromised mailboxes for financial transactions, setting rules to delete key messages, enabling automatic forwarding to outside accounts, and then posing as the vendor or customer to redirect payments. Adversary-in-the-middle kits that steal session cookies are covered in AiTM phishing explained.

Inbox rules. Once inside, the attacker adds rules that forward copies of mail to an outside address (MITRE T1114.003) or move replies from the real counterparty out of sight (T1564.008). Microsoft lists rules that move messages to Notes, Junk Email or RSS Subscriptions as a common symptom of a compromised mailbox.

Reply-chain hijack. The attacker replies inside an existing thread, either from the compromised mailbox or from a lookalike domain with the quoted history pasted in. The target sees a conversation they recognize and a request that fits it.

Remote-access installers. In freight fraud especially, the email carries a link to a "rate confirmation" or "carrier setup" file that installs a legitimate remote management tool. The tools are legitimate software, so the install can pass for routine IT work, and the attacker then operates from the victim's own machine and accounts.

Reading the headers: a worked example

Here is the header block of a vendor payment-change email as an accounts payable clerk at buyer.example received it in Microsoft 365. The real supplier is Kestrel Freight at kestrelfreight.example. All names, domains and addresses are fictional and use documentation ranges.

Return-Path: <[email protected]>
Received: from mail.kestrelfrieght.example (203.0.113.45)
        by mx.buyer.example with ESMTPS; Tue, 3 Nov 2026 14:02:11 +0000
Authentication-Results: mx.buyer.example;
        spf=pass (sender IP is 203.0.113.45) smtp.mailfrom=kestrelfrieght.example;
        dkim=pass (signature was verified) header.d=kestrelfrieght.example;
        dmarc=pass action=none header.from=kestrelfrieght.example;
        compauth=pass reason=100
X-Forefront-Antispam-Report: CIP:203.0.113.45;IPV:NLI;SFV:NSPM;DIR:INB;
        H:mail.kestrelfrieght.example;PTR:mail.kestrelfrieght.example
From: "Dana Morales | Kestrel Freight" <[email protected]>
Reply-To: <[email protected]>
To: <[email protected]>
Subject: RE: Invoice 88214 - updated remittance details
Date: Tue, 3 Nov 2026 09:01:58 -0500
Message-ID: <[email protected]>

Line by line:

1. Return-Path is written by the final receiving server and records the envelope sender from the SMTP MAIL FROM command (RFC 5321, section 4.4). Bounces go here. Its domain is kestrelfrieght.example, with ie reversed. That is the first sign the message did not come from Kestrel.
2. Received shows the server that handed the message to mx.buyer.example. Read the topmost Received lines your own servers added; lines further down were written by the sender and can be invented.
3. Authentication-Results is your receiving server's verdict (RFC 8601). Trust only the instance stamped by your own server, here mx.buyer.example. Compliant servers strip forged copies that claim to come from inside the boundary, and one added upstream proves nothing.
4. spf=pass ... smtp.mailfrom=kestrelfrieght.example means the sending IP is authorized by the lookalike domain's own SPF record (RFC 7208). The attacker wrote that record.
5. dkim=pass ... header.d=kestrelfrieght.example means the lookalike domain signed the message (RFC 6376). The attacker holds that key.
6. dmarc=pass ... header.from=kestrelfrieght.example means the passing domain matches the visible From. DMARC confirms the message came from the domain it shows. It has no idea that domain is a forgery of another one.
7. compauth=pass reason=100 is Microsoft's composite verdict: SPF or DKIM passed and aligned with the From domain. SFV:NSPM means spam filtering marked it as not spam. The filters did their job correctly on a domain that is not the supplier's.
8. From carries the real contact's name and a familiar layout. On a phone, only "Dana Morales | Kestrel Freight" shows.
9. Reply-To sends any answer to a free webmail account. Under RFC 5322, Reply-To names where the author wants replies sent, and mail clients address a reply there, so the clerk who presses Reply writes straight to the attacker. A Reply-To on a different domain from the From is one of the clearest BEC signals in any header.
10. Subject: RE: claims to be a reply, yet the block has no In-Reply-To or References header. RFC 5322 says replies should carry both, and mail clients add them. A reply with neither most likely belongs to a thread that does not exist in your mailbox.
11. Date is 09:01:58 at UTC minus five, which is 14:01:58 UTC, thirteen seconds before the Received stamp. Consistent, and an example of a field the attacker controls and can make look right.

Every authentication result in that block passed. The fraud shows in the domain spelling, the Reply-To, the missing thread headers, and the request itself.

Now compare the same request sent from Kestrel's real mailbox after a takeover:

Authentication-Results: mx.buyer.example;
        spf=pass smtp.mailfrom=kestrelfreight.example;
        dkim=pass header.d=kestrelfreight.example;
        dmarc=pass action=none header.from=kestrelfreight.example;
        compauth=pass reason=100
From: "Dana Morales | Kestrel Freight" <[email protected]>
Subject: RE: Invoice 88214
In-Reply-To: <[email protected]>
References: <[email protected]>

Correct domain, no Reply-To, a genuine thread. Nothing in the headers is wrong. The only signal left is the content: a bank change, by email, on a payment that is about to go out. That case is why the payment process has to carry the weight.

To find which mailboxes in your own tenant are pushing mail outward, an Exchange Online admin can list every rule, including hidden ones, as Microsoft's compromised account guide shows:

Get-InboxRule -Mailbox ap@buyer.example -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity
Get-Mailbox -Identity ap@buyer.example | Format-List Forwarding*Address,DeliverTo*

A non-blank RedirectTo, ForwardTo or ForwardingSmtpAddress pointing outside the organization needs an explanation. Hiding rules show up under MoveToFolder and DeleteMessage, so run Get-InboxRule with a plain Format-List as well when you suspect one.

Detecting lookalike domains

Lookalike detection is a comparison against domains you already trust, so start by writing that list down: your own domains and every vendor, customer and law firm that sends you payment instructions.

• Compare the registrable domain exactly. kestrelfreight.example and kestrelfrieght.example differ by two transposed letters, which human reading skips. A script or mail rule that compares against the vendor list is reliable where eyes are not.
• Flag near matches. An edit distance of one or two from a trusted domain, a trusted name plus a word (-payments, -invoice, -billing), the same name on another top-level domain, or any xn-- label deserves a hold.
• Check the domain's age. An RDAP or WHOIS lookup shows the creation date. A domain registered days before it sends a remittance change is a strong signal.
• Watch your own name. Open-source tools such as dnstwist generate the likely permutations of your domain and check which ones are registered, which tells you what your customers may be receiving in your name.
• Use the gateway's impersonation features. Microsoft Defender for Office 365 marks domain impersonation of protected domains with SFTY:9.19 and user impersonation with SFTY:9.20 in X-Forefront-Antispam-Report, and can show a first contact safety tip for new senders. Add your key vendors as protected domains.

For freight email, rate confirmations and carrier packets, the Freight Fraud Signal Checker scores remittance change requests, spoofed senders, lookalike broker domains, RMM installer links and double brokering cues in a pasted message, and compares a USDOT or MC number against FMCSA's public registry data.

The payment-change verification process

Every variant above ends at the same moment: someone is about to send money to an account they have not paid before. Put the control there.

1. Treat any change to where money goes as a separate event. New bank details, a new remit-to address, a new direct deposit account, a new escrow account. Each one triggers the steps below, whatever channel it arrived on and however senior the requester.
2. Hold the payment. No payment goes to new details until verification is done. Urgency in the request is a reason to slow down.
3. Call back on a number you already hold. Use the vendor master file, the signed contract or a past invoice from before the request. Never use a number from the email, its signature or an attachment, because the attacker wrote those. For carriers and brokers, FMCSA advises calling the number posted in SAFER when the one you were given does not match.
4. Speak to someone you know there. Ask them to confirm the change and read back the old account's last digits. A real contact can answer; a voice on an attacker's line usually cannot.
5. Require a second approver who did not handle the request. One person can be fooled; two people checking the same callback record is a much harder target.
6. Notify the old contact. Send a confirmation of the change to the previously known address and phone. If the vendor did not ask for it, they will tell you.
7. Record it. Who called, which number, who confirmed, who approved. The record is what the bank and your insurer will ask for if something still goes wrong.

Payroll changes follow the same logic: accept them only through the authenticated HR portal, and email the employee's known address when a deposit account changes. The social engineering playbook covers out-of-band verification for other request types, and AI voice cloning scams explains why a familiar voice on an inbound call is not proof of identity.

The first hours after a fraudulent transfer

Recovery depends on speed. Funds that reach the first receiving account can often be frozen; once they move on, the chance falls with each hop.

1. Call your bank's wire or fraud desk now. Ask for a recall of the payment and for the bank to contact the receiving bank directly. The 2025 IC3 report advises requesting the recall along with any indemnification documents the bank needs, and notes that banks differ in what help they give. Find out your bank's process before you need it.
2. File at ic3.gov the same day if you are in the US, with the full transaction details: amount, date, sending and receiving banks, account and routing numbers, and any reference numbers. The IC3 Recovery Asset Team uses the Financial Fraud Kill Chain to ask receiving banks to freeze funds. In 2025 it initiated 3,900 incidents covering $1,163,919,846 in attempted theft and froze $679,013,183, a 58 percent success rate. Domestic cases accounted for $507,042,623 frozen; for international transfers the team works with FinCEN's Rapid Response Team and FBI legal attachés abroad, and froze $171,970,560. The FBI asks victims to file regardless of the amount.
3. Contain the mailbox if it is yours. Disable or reset the account, revoke sessions, remove unknown MFA methods and app consents, and delete forwarding and inbox rules, following Microsoft's steps or your provider's equivalent. If the vendor's mailbox was the one compromised, tell them through a known phone number.
4. Preserve the evidence. Save the original messages with full headers as .eml files, export sign-in and audit logs, and keep the payment records. Do not delete the attacker's rules until you have recorded them.
5. Report locally. File a police report, which banks and insurers often request. Outside the US, use your national cybercrime or fraud reporting channel. Freight victims can also file with FMCSA's National Consumer Complaint Database.
6. Tell your insurer if you hold cyber or crime cover, within the notice period the policy sets.

The incident response guide covers the wider investigation once the money side is in hand.

Defenses in order of impact

1. The callback and dual-approval process above, applied to every bank detail change. It still works when the vendor's real mailbox is the one compromised.
2. Phishing-resistant MFA on email and payroll accounts, such as passkeys or hardware security keys, and blocking legacy protocols like POP and IMAP that the FBI notes can be used to get around MFA.
3. Block automatic forwarding to external addresses and alert on new inbox rules that forward, redirect or move mail.
4. DMARC at enforcement on every domain you own, including domains that never send mail, so your exact domain cannot be forged to your customers and suppliers.
5. External sender tags and full-address display, so a display-name spoof shows its real address.
6. Lookalike monitoring for your own domains and for your top vendors' domains.
7. For freight, verify every new carrier and broker against FMCSA records before tendering a load, and block remote management tools that IT has not approved.

Verdict

BEC is a payments attack that happens to use email. Email authentication removes one route, exact-domain spoofing, and should be at enforcement everywhere. Lookalike domains and taken-over mailboxes pass every header check, as the worked example shows, so the deciding control sits in accounts payable: no new bank details without a callback to a known number and a second approver. Write that rule down, apply it without exceptions for urgency or seniority, and rehearse the bank recall call so the first hour after a mistake is spent on the phone.

Related guides

• The Social Engineering Playbook
• What Is Phishing
• SPF, DKIM and DMARC Explained
• Email Security Guide
• AiTM Phishing Explained
• AI Voice Cloning Scams
• Incident Response 101