The invoice fraud email that almost worked in Port Louis

It came from a real supplier address, referenced a real order, and asked for one small change to the bank details.

The supplier had been compromised, not spoofed, so every technical signal looked clean. What stopped it was a rule the client had adopted six months earlier: bank detail changes get confirmed by phone, on a number the finance team already had.

We are writing it up because the shape of this attack is the same every time, and because the businesses it works on are not careless. They are busy.

What actually happened

1. The supplier's accounts mailbox was accessed by someone who had bought or phished the credentials. No alarm was raised because the login looked ordinary enough.
2. The attacker read the mailbox quietly for several weeks. That is the part people underestimate — they learn the tone, the approval names, the payment terms and the invoice numbering.
3. They waited for a real invoice on a real order, replied inside the existing thread, and attached a near-identical PDF with one field changed: the account number.
4. The covering note was two lines about a change of banking arrangements, and it apologised for the inconvenience.

The finance officer who received it did nothing wrong. She had a purchase order that matched, a supplier she recognised, an amount she expected, and a thread she had been reading all month. She picked up the phone because the rule said to, not because anything felt off.

Why the technical controls did not fire

Most email security assumes a forged sender. SPF, DKIM and DMARC exist to answer one question — did this message really come from the domain it claims? Here the answer was yes, because it did. There was no attachment to detonate, no link to a fake login page, no lookalike domain with a swapped character. From the filter's point of view it was a routine supplier email.

Any control that depends on the message looking wrong will fail against an attacker who is using the real mailbox.

This is not a Mauritian problem or a small-business problem. The FBI's 2025 Internet Crime Report put reported business email compromise losses at just over US$3 billion for the year, second only to investment fraud, and noted that the overwhelming majority of losses across all categories now come from cyber-enabled fraud that targets a person's judgement rather than a software flaw. Roughly 86% of BEC losses moved by wire or ACH — fast, and usually gone.

Smaller businesses are attractive precisely because the payment path is short. One person raises it, one person approves it, and nobody is looking at a control matrix.

The four controls that stop it

1. A callback rule for any change to payment details

Written down, applied without exception, and — this is the part people get wrong — using a phone number from your own supplier record, never a number in the email. The attacker will happily answer the number they gave you.

2. Dual authorisation above a threshold

Pick an amount that reflects your business, not a textbook. For most of the SMBs we work with somewhere between Rs 50,000 and Rs 200,000 is the point where a second pair of eyes is worth the friction. Below it, speed matters more.

3. Explicit permission to slow a payment down

The most common reason people pay a fraudulent invoice is that the email is urgent and the person is junior. Say out loud, in writing, that nobody will ever be criticised for delaying a payment by a day to verify it. Then behave that way the first time someone does it.

4. Multi-factor authentication and login alerting on every mailbox

This does not protect you from your supplier being compromised, but it stops you becoming the compromised supplier in someone else's version of this story. Enforce MFA on all accounts, disable legacy authentication protocols, and turn on alerts for new-country logins and for mailbox rules that forward or auto-delete messages — attackers create those to hide the replies.

If the payment has already gone

Order matters here, and the first hour is worth more than the next week.

1. Call your bank and ask for a recall on the transfer. If the funds have not been withdrawn from the receiving account there is a real chance of getting them back.
2. Preserve everything. Do not delete the email, do not clean the mailbox, do not reset the supplier's password on your side. Export the message with full headers.
3. Report it. In Mauritius, incidents can be reported through MAUCORS, the national cybercrime reporting platform that connects CERT-MU, the Police Cybercrime Unit, the Data Protection Office and the ICTA. Report to your bank and the police in parallel, not sequentially.
4. Check the 72-hour clock. If personal data was exposed — and mailbox compromise usually means it was — the Data Protection Act 2017 requires notification to the Data Protection Commissioner without undue delay and, where feasible, within 72 hours of becoming aware.
5. Warn the supplier, by phone. Their mailbox is the crime scene, and they may not know. Assume every email you have exchanged with them recently has been read.

What we put in place, and why it is boring

We write these controls into the security plan for every retainer client, and we run a short session with the finance team rather than a company-wide slideshow nobody remembers. Three or four people in a room for forty minutes, working through two real emails, beats an annual e-learning module every time.

The rest of it is hygiene that makes the rest of the attack chain harder: MFA everywhere, alerting on suspicious mailbox rules, a documented offboarding process so old accounts are not left open, and a quarterly look at who actually has access to what. If that sounds adjacent to the licence audit we wrote about here, it is — the same orphaned accounts that inflate your bill are the ones nobody is watching.

And if you are automating your accounts payable, build the callback rule into the automation rather than around it. We covered how that works in the piece on invoice exceptions: a change of bank details should never be a case the machine posts on its own.

Frequently asked questions