Who this is for. Owners, finance leads and IT administrators of organisations that pay invoices by bank transfer. If a message from a supplier, a customer or your own director could cause money to move, this is about you. It assumes no security background, and it ends with a runbook you can print.
Business email compromise, usually shortened to BEC, is fraud carried out through email. The goal is almost never to break your systems. The goal is to get a person to do something that looks routine: change a supplier’s bank details, pay an urgent invoice, buy gift cards, redirect a payroll deposit. Because the attack succeeds when a human acts, it can defeat an organisation with excellent technical defences, and it can succeed against one with none.
Two quite different attacks share the name, and mixing them up produces the wrong response. The first section separates them.
Two kinds of BEC
| Impersonation | Account takeover | |
|---|---|---|
| What the attacker controls | Nothing of yours. A lookalike domain, a free webmail address, or a forged display name | A real mailbox inside your organisation or a supplier’s |
| Why it is convincing | The name and tone look right | The message is genuinely from the sender, in an existing thread |
| Authentication results | Often fail alignment, or pass for the attacker’s own domain | Pass everything, because the mail really was sent by the account |
| Main technical defence | DMARC enforcement, impersonation filtering, external-sender marking | MFA, conditional access, mailbox monitoring, session revocation |
| What stops the payment | Verification by call-back | Verification by call-back |
The last row is the point. The two attacks need different technical defences and the same procedural one. If you only have time to fix one thing this month, it is the verification rule described later.
An account takeover also changes who you are talking to. A compromised supplier mailbox is the supplier’s incident, but the fraudulent request lands in your inbox. You cannot tell from the message that it is false, because all the usual signs are real.
Anatomy of an account-takeover BEC
This is a composite, hypothetical example. It is built from the stages that incident reports consistently describe, not from any specific case.
1. Initial access. A finance clerk at a supplier receives a message about a shared document, and signs in on a page that looks right. The page relays the sign-in to the real service in real time, and collects the session along with the password. A one-time code typed into it does not help, because the attacker passes it on while it is still valid. (This is why phishing-resistant sign-in matters; see conditional access.)
2. Quiet reconnaissance. The attacker does not change anything visible. They search the mailbox for words such as “invoice”, “remittance”, “bank details” and “wire”. They learn who pays whom, how often, and in what tone.
3. Hiding. They create a mailbox rule that moves any message containing words like “fraud”, “spoof” or “suspicious” to a rarely opened folder, or that marks replies from certain people as read. Another rule may forward copies of mail to an outside address, which also survives a password reset.
4. The hijack. When a real invoice is due, the attacker replies inside the existing thread: “Our bank has changed. Please use the account below for this and future payments.” The thread history, the writing style and the sender address are all genuine.
5. The payment. The customer’s finance team pays. The money lands in an account controlled by the attacker, often one that passes funds on quickly.
6. Discovery. Days or weeks later the real supplier asks why they have not been paid. By then the money may be gone.
Notice what the defender could have caught: an unfamiliar sign-in, a new forwarding rule, a rule that hides messages, a bank-detail change by email. Each is detectable. None of them is detected by a spam filter.
The signals worth watching
Not every message that mentions a bank account is fraud. These patterns deserve a second look:
- A request to change payment details, especially “for this and all future payments”.
- Pressure that discourages checking: “I’m in a meeting”, “this is confidential”, “do not call, I’ll be unreachable”.
- A new account in a different bank or country from the previous payments.
- A reply that arrives in the thread but is slightly off: a different signature, an unusual greeting, an unfamiliar sentence structure.
- A
Reply-Toaddress that differs from the sender, or a sender domain that is one character away from the real one. - A first-ever message from a “new” senior person asking for an urgent favour.
On your own mailboxes, the technical signals are different and quieter:
- A sign-in from a new country or an unfamiliar device, followed by mailbox activity.
- A new inbox rule that forwards, deletes, or moves mail to RSS Feeds, Archive or another folder nobody reads.
- A new forwarding address on a mailbox.
- A newly consented application with permission to read mail.
- A sudden burst of searches across a mailbox, or many messages read in a short time.
The first hour: a response runbook
This is written for a Microsoft 365 environment because most small organisations use one. The principles apply anywhere. Names and menus change, so use the steps as a sequence of goals and find the current location of each setting in your own admin tools.
Do this immediately and in this order.
- Decide who is in charge. One person owns the incident and keeps a timestamped log of every action. This matters for insurance and for any investigation.
- Contact the bank first if money has moved. Call your bank’s fraud or payments team, not a general helpline, and ask for a payment recall. Speed matters more than anything else on this list. Then report the fraud to the appropriate authority in your country; in the United States that is the FBI’s Internet Crime Complaint Center, and other countries have national equivalents.
- Contain the account. Block sign-in for the affected user, or reset the password and revoke their active sessions. Resetting the password alone often leaves existing sessions alive.
- Capture evidence before you clean up. Note the rules, forwarding and consented apps you find, with screenshots or exports, before removing them.
- Remove the persistence. Delete malicious inbox rules, remove forwarding, remove unfamiliar delegates and consented applications.
- Check what the attacker did. Review sign-in logs and the audit log for the account, and read the mailbox’s sent items for messages you did not write.
- Tell the people who are exposed. Warn the supplier or customer in the thread through a different channel, such as a phone number you already hold, because their mailbox may be compromised too.
Read-only commands that help in step 5 and 6, run by an administrator in Exchange Online PowerShell after connecting with Connect-ExchangeOnline:
# Inbox rules on one mailbox (read-only)
Get-InboxRule -Mailbox user@example.com | Select-Object Name,Enabled,ForwardTo,ForwardAsAttachmentTo,RedirectTo,DeleteMessage,MoveToFolder
# Forwarding configured on the mailbox itself (read-only)
Get-Mailbox user@example.com | Select-Object ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward
# Who else has rights to open this mailbox (read-only)
Get-MailboxPermission -Identity user@example.com | Where-Object { $_.AccessRights -like "*FullAccess*" -and -not $_.IsInherited }Revoking sessions with Microsoft Graph PowerShell, which changes the account’s state and should be done deliberately during an incident:
Connect-MgGraph -Scopes "User.ReadWrite.All"
Revoke-MgUserSignInSession -UserId user@example.comDo not delete the mailbox, wipe the device or rebuild the account before you have preserved what you need to understand the incident. Removing evidence helps the attacker and hurts you.
Prevention: controls in order of what they actually stop
1. A verification rule for payment changes. Any change to bank details, and any urgent or unusual payment request, must be confirmed by telephone using a number already held in your records, not one in the message. Write it down, apply it to everyone including executives, and give finance staff explicit permission to delay a payment while they verify. A sample rule:
Payment detail changes
1. Never act on a request to change bank details that arrives by email alone.
2. Call the supplier on the number in our supplier record (not the email).
3. A second person approves the change in the finance system.
4. Payments to a newly changed account over the agreed threshold are held for one business day.2. Strong sign-in on every account. MFA everywhere, phishing-resistant methods for administrators and finance, and blocking of legacy sign-in. This stops most takeovers at the start. Remember that it does not stop impersonation.
3. Mailbox hygiene. Block automatic forwarding to external addresses, alert on new forwarding and delete rules, and restrict which third-party applications users can authorise. See mailbox security.
4. Domain authentication. Enforce DMARC on your own domain so nobody can send mail using your exact address. This stops one kind of impersonation of you. See SPF, DKIM and DMARC.
5. Filtering and marking. Impersonation protection for named executives and finance staff, and visible marking of external mail.
6. Your suppliers. Ask critical suppliers to tell you, in advance and by a known channel, whenever their bank details change. Then treat any other route as suspicious.
How this fails
- “We have MFA, so we are safe.” MFA that can be relayed does not stop a live phishing page, and MFA does nothing against a lookalike-domain impersonation.
- Password reset only. The attacker’s forwarding rule, a consented application, or an active session survives it.
- A call-back to the number in the email. The attacker answers. The rule is “a number you already had”.
- Verification that skips the boss. Executives are the most impersonated people in an organisation and often exempt themselves from process. The rule has to apply to the person whose name is being forged.
- Blame. A clerk who fears punishment will not report a click quickly, and speed of reporting is what turns a click into a non-event.
- No one practised the response. The first hour is when the decisions that matter are made, and they should not be made for the first time during a real incident.
What to do next
Print the first-hour runbook and the payment rule, and walk through them once with finance. Use the email security readiness assessment to see which of the supporting controls you can honestly say are in place, then read mailbox security for the forwarding, rule and delegate audit that finds an attacker’s persistence.