Most advice about email fraud tells you to check the sender's address. That advice fails in the case that does the most damage: when the address is right.
If a criminal gets into your supplier's mailbox, the next invoice doesn't come from a lookalike domain or a free webmail account. It comes from the supplier's genuine address, often as a reply in a conversation your accounts team has been having for weeks. The only thing that has changed is the bank account.
This article explains how that happens, why the controls many businesses rely on don't catch it, and what an owner or finance manager can put in place: sensible Microsoft 365 controls, and a simple procedure for handling bank-detail changes.
The short version is above. The rest of this article covers how the attack works step by step, and what to do about it.
What business email compromise actually is
Business email compromise (BEC) is fraud that uses email to redirect payments. South Africa's banking risk information centre, SABRIC, defines it as "a criminal act where criminals illegally access an email account and communicate as if they are the user" (SABRIC).
In practice, email payment fraud takes two broad forms:
- Impersonation. The criminal pretends to be someone else, using a lookalike domain, a misleading display name or a forged copy of a real domain.
- Account takeover. The criminal gets into a real mailbox and sends from it. Microsoft describes attackers who break into real accounts with stolen passwords, "monitor email traffic for weeks, then strike when a major payment is due" (Microsoft).
This article is about the second form, because it is the one that defeats "check the sender's address".
How a real mailbox gets taken over
The pattern below is drawn from attacks Microsoft's threat researchers have documented in detail. Not every case follows every step, but most follow the same shape.
- The password, and often the session, is stolen. It usually starts with a phishing page that looks like a normal Microsoft 365 sign-in. The more capable kits sit in the middle between the user and the real sign-in page ("adversary-in-the-middle"). Microsoft documented one such campaign that attempted to target more than 10,000 organisations from September 2021. It captured the user's session cookie after they had completed multi-factor authentication (Microsoft Threat Intelligence, 2022).
- The attacker signs in as the user. A stolen session token is treated as a completed sign-in. Microsoft's guidance puts it plainly: "Because authentication requirements are met, the threat actor is granted access to organizational resources by using the stolen token" (Microsoft Learn).
- They read and wait. They look for conversations about invoices, payments and bank details, and learn who pays whom, how and when.
- They hide their tracks. They create inbox rules that move replies into folders such as Archive or RSS Feeds and mark them as read, or delete them outright, sometimes filtering on words like "invoice" (Microsoft Learn). In the 2022 campaign, attackers also deleted evidence from Sent Items and Deleted Items.
- They hijack the conversation. A reply arrives in the existing thread, from the real address, saying the banking details have changed. In the 2022 campaign, Microsoft saw payment fraud begin as little as five minutes after the credentials and session were stolen. That was the fastest case observed, not a typical one.
- They try to keep their access. In a 2023 case, the attacker registered their own phone-based MFA method on the compromised account. In that case, adding a new MFA method did not, by default, require the user to sign in again (Microsoft Threat Intelligence, 2023). The same campaign started with a phishing email from one of the victim organisations' trusted vendors.
That last point matters. The attack does not need to touch your systems at all. If your supplier's mailbox is compromised, the fraudulent request arrives in your inbox from a genuine sender.
Why the email gets past your security checks
A message sent from a genuinely compromised mailbox looks legitimate to most of the checks businesses rely on.
| Control | What it checks | Why a compromised mailbox gets past it |
|---|---|---|
| SPF, DKIM and DMARC | That mail using a domain comes from that domain's authorised servers and carries its signature | The mail really is sent through the domain's own mail system and signed with its real key, so it passes. DMARC is "designed to protect against direct domain spoofing" (DMARC.org), not against misuse of a real account. |
| Ordinary MFA (SMS codes, app codes, push approvals) | That the person signing in has a second factor | An adversary-in-the-middle page relays the MFA prompt and keeps the session that results. The attacker doesn't need the code again. |
| Email filtering | Known-bad links, attachments, senders and reputation | A reply in a real thread, from a trusted sender, may contain no link or attachment at all. Just new banking details. |
| Bank payment processing | That the payment can be processed to the account number provided | Processing a payment doesn't necessarily establish that the recipient is the party you intended to pay. In Hartog v Daly (2023), the court noted that the payment was collected "on the account number only, and not with reference to the account holder's name", as the payment industry's rules require. |
None of this is a reason to drop DMARC. DMARC stops criminals forging your exact domain, which is a different attack. It simply isn't designed for this one. See DMARC for your domain.
It helps to separate the four ways an email can pretend to come from someone you trust:
| Type | What it looks like | What helps most |
|---|---|---|
| Exact-domain spoofing | Your supplier's real address, forged, sent from a server they don't control | DMARC at enforcement (quarantine or reject) on the sender's domain |
| Lookalike domain | A domain one character away from the real one | DMARC does not help. A payment verification procedure, staff awareness and mail filtering do. |
| Display-name spoofing | A trusted name shown, with an unrelated address behind it | DMARC does not protect the display name. Filtering, awareness and verification. |
| Compromised mailbox | The real address, often in the real thread | Account security on the sender's side, behavioural detection on yours, and a payment verification procedure |
The payment verification procedure appears in every row except the first. That is deliberate.
MFA: essential, but not all MFA is equal
MFA remains essential. Turn it on for every mailbox. Microsoft states that MFA combined with blocking legacy authentication stops "more than 99.9%" of common identity-related attacks (Microsoft Learn). That is Microsoft's own figure, and it refers to common attacks such as password guessing, not the adversary-in-the-middle technique described above.
The important point is that not all MFA is equally hard to phish:
- SMS codes, one-time codes and ordinary push approvals can still be phished, because a fake sign-in page can relay them in real time. Push approvals can also be abused by sending repeated prompts until someone taps "approve".
- Passkeys and physical security keys are tied to the genuine website, so a fake sign-in page can't use them. They give much stronger protection. The US Cybersecurity and Infrastructure Security Agency (CISA) lists them, along with certificate-based authentication, as the phishing-resistant options (CISA).
A practical approach is to put MFA on everyone now, then move the accounts that can move money or change systems (finance, directors and IT administrators) to phishing-resistant methods first. See our multi-factor authentication service for how that rollout usually works.
Microsoft 365 controls that realistically matter
For businesses using Microsoft 365, these are the controls worth confirming. Several depend on your licences, so we've said which.
- Security defaults or Conditional Access. Security defaults are Microsoft's free baseline. They require MFA registration for all users and MFA for administrators, and they block legacy authentication. If your licences include Microsoft Entra ID P1 or P2, Microsoft recommends Conditional Access policies instead (Microsoft Learn).
- Legacy authentication blocked. Older protocols that can't do MFA give attackers a way around it. Our article on why security products don't make you secure covers this.
- Automatic forwarding to external addresses blocked. Microsoft has disabled it by default for new organisations since 2021, but it can be switched back on. Check that nobody has (Microsoft Learn).
- Alerts on new inbox rules and forwarding. Especially rules that move mail to Archive, RSS Feeds or Notes, delete mail, or filter on words like "invoice" or "payment".
- Re-authentication for MFA changes. Require users to prove who they are again before they can add or change an MFA method.
- Audit logging on, and someone reading it. Sign-in and audit alerts are only useful if a named person reviews them.
- Risk-based sign-in detection. Microsoft Entra ID Protection can flag unfamiliar sign-in properties, anomalous tokens, adversary-in-the-middle sign-ins and suspicious inbox rules. According to Microsoft's documentation at the time of writing, most of these need Entra ID P2 or Microsoft 365 E5-level licensing (Microsoft Learn). Many smaller businesses aren't licensed for them, so it is worth checking what yours actually includes.
Behavioural detection: spotting an account that isn't acting like its owner
A compromised account still authenticates correctly. Catching it therefore depends on noticing that the account is behaving unlike its owner. Useful signals include:
- sign-ins from an unfamiliar location, device or network
- activity at hours the person doesn't work
- messages to people they've never written to
- requests they never make, such as urgent payments or changed banking details
- new inbox rules, new forwarding, or a newly added MFA method
Microsoft's premium tiers look for some of these. Specialist behavioural email security tools look for them too. Be realistic about what such tools can do. Detection of this kind is probabilistic. It needs time to learn what normal looks like. And it can miss a well-timed request that fits the normal pattern, such as a reply inside an existing invoice thread during office hours. It is a strong layer, but it does not replace the payment procedure below.
One option we offer: ROI Technologies is a Darktrace Premier Partner, and we provide Darktrace / EMAIL. Darktrace says the product "learns exclusively from your activity and users" (Darktrace) and that it integrates with Microsoft 365 to monitor login data, account activity and email rules together (Darktrace). It is typically best suited to organisations with approximately 150 users or more, depending on environment and security requirements. We sell it, so read this paragraph as ours rather than as an independent assessment.
What your finance team should do when a supplier changes bank details
This is the control that works whichever type of attack you face, and it costs nothing but discipline. SABRIC gives the same advice: "Unusual payment instructions received by email, WhatsApp or telephone should be independently verified through a trusted channel before funds are transferred" (SABRIC Annual Crime Statistics 2025).
A procedure an owner can adopt as it stands:
- Treat every bank-detail change as high risk. This applies whether it arrives by email from the real address, as a reply in an existing thread, on a letterhead PDF, by WhatsApp or by phone.
- Verify independently, using contact details you already hold. Call a number from your supplier records, a previous contract or an earlier invoice. Never use a number, address or link supplied in the change request itself.
- Speak to a person you know at the supplier. Read the new details back to them and confirm them. Don't rely on a voicemail or a callback number they give you.
- Record the verification. Note who confirmed it, when, and on which number. File it with the supplier record.
- Use your bank's account verification service where it is available. It checks whether an account belongs to the person or company you expect. Ask your bank what it offers.
- Separate duties. The person who captures a bank-detail change should not be the person who approves the next payment to that account.
- Treat pressure as a warning sign. Urgency, secrecy or "the director needs this paid today" should increase your checks, not reduce them.
- Consider a hold or a test payment. For large amounts to a newly changed account, a short delay, or a small payment confirmed by phone first, costs little.
- Escalate immediately if money has already gone. See the first-hour steps below.
Why this matters in South Africa
SABRIC's 2025 report states that "supplier mandate fraud and business email compromise remained material risks". It describes criminals redirecting payments through fraudulent changes to banking details or compromised communications.
SABRIC does not publish a separate loss figure for business email compromise, and we could not find a reliable South African one elsewhere. The large rand figures that circulate online are generally estimates for all cybercrime, or totals for digital banking fraud, not measurements of email fraud. So we haven't quoted one.
Two South African judgments show how these losses can fall:
- ENS v Hawarden (Supreme Court of Appeal, 2024). Ms Hawarden was buying a property. Criminals compromised her email account, intercepted emails from the conveyancers, altered the banking details and sent her fraudulent account details. She paid R5.5 million to the fraudsters. The high court had found the conveyancers liable. The SCA overturned that finding and she bore the loss. The court said it "would have been fairly easy" for her to have verified the conveyancers' bank account details. It also said the idea that all creditors in the conveyancers' position owe their debtors a legal duty to protect them from their accounts being hacked is "untenable" (SAFLII).
- Hartog v Daly (Gauteng full court, 2023). A conveyancing attorney received an email, apparently from his client's husband, instructing him to pay the sale proceeds into an account the fraudster controlled. He paid R1,421,228.06. The court held him liable to his clients for that amount. The claim against the bank that received the money failed (SAFLII).
These are short summaries of two judgments decided on their own facts. They are provided for information only and are not legal advice. They do not establish a general rule about who carries the loss in every case. If you're dealing with a specific incident or contract, speak to your attorney.
What both cases show is practical. A few minutes spent verifying bank details independently is far cheaper than arguing afterwards about who should carry the loss.
If you think a mailbox has been compromised: the first hour
Microsoft's guidance for responding to a compromised Microsoft 365 account covers the technical steps (Microsoft Learn). In plain terms:
- Reset the password or disable the account.
- Revoke active sessions. A password reset alone may not remove an attacker who holds a stolen session token.
- Remove any MFA methods the attacker added.
- Delete malicious inbox rules and forwarding, including rules that are hidden.
- Review app consents and admin roles for anything unexpected.
- Check sent items and message trace to see who else received mail from the account.
- Warn clients and suppliers who may have received fraudulent payment instructions.
- Consider POPIA. Section 22 requires the responsible party to notify the Information Regulator and the affected people, as soon as reasonably possible, where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person. The Regulator directs these notifications to its eServices portal (Information Regulator).
If a payment has already been made, call your bank immediately and ask whether the payment can be stopped or recalled. Speed matters. Also report the matter to the South African Police Service (SAPS), and keep the emails (with their full headers) and any logs.
Where to start
If you do only three things after reading this, make them these:
- Put the bank-detail verification procedure above in writing, and make sure your finance team uses it.
- Confirm MFA is on for every mailbox. Then plan phishing-resistant methods for finance, directors and administrators.
- Check that someone is alerted when a new inbox rule or external forward is created, and that someone acts on it.
Your people are part of this too. Our security awareness training covers phishing simulation for staff. Walk your finance team through the thread-hijack scenario specifically: the real supplier address, a reply in the real thread, and new bank details.
Sources and further reading
South African sources:
- SABRIC: How to stay safe (business email compromise)
- SABRIC Annual Crime Statistics 2025
- Edward Nathan Sonnenberg Inc v Hawarden (2024) ZASCA 90
- Hartog v Daly (2023) ZAGPJHC 40
- Information Regulator: Handling of security compromises
Technical sources:
- Microsoft Threat Intelligence (2022): From cookie theft to BEC
- Microsoft Threat Intelligence (2023): Multi-stage AiTM phishing and BEC campaign
- Microsoft Learn: Responding to a compromised email account
- Microsoft Learn: Token theft playbook
- Microsoft Learn: Entra ID Protection risk detections
- CISA: Implementing phishing-resistant MFA
- DMARC.org FAQ
Protect your mailboxes and your payment process
Not sure which of these controls are actually enabled in your Microsoft 365 environment? We can help you review your current email-security setup and identify the gaps.
Explore Email Security