Security

Business email compromise: anatomy of an attack that almost worked

The finance manager finds out on a Tuesday, when a supplier rings to ask why an invoice is six weeks overdue. It was paid, finance insists. It was, in fact, paid to someone else. That phone call is how most business email compromise comes to light: not an alarm, but an awkward conversation long after the money moved. What follows is a post-mortem of a typical incident, a composite of cases we have seen, traced backwards from the payment to the root cause, then forward to the changes that stop the next one. It applies whether you look after one company's estate or thirty clients' worth.

The phone call that starts the post-mortem

The paper trail looks clean at first. Finance received the supplier's invoice as usual, on the usual thread, quoting the right PO number. A few days later came a follow-up from the same thread: the supplier had "changed banks" and would finance kindly use the new account details. The email read naturally, referenced the right people, and arrived at a believable moment. Finance updated the record and paid. Nothing about it looked like fraud, because almost none of it was fake: the attacker was inside a real mailbox, replying inside a real conversation.

This is worth stating plainly, because the popular image of email fraud is still a badly spelled message from a stranger. Business email compromise is the opposite. In the FBI's 2025 internet crime figures it accounted for just over $3 billion in reported losses across roughly 25,000 complaints, an average of more than $120,000 per incident, and 86% of it moved by wire or ACH transfer, which means it was largely gone before anyone noticed. Those are only the reported cases. The typical victim is not a careless person; it is an ordinary payment process that trusted an email it had every apparent reason to trust.

Working backwards: the rule hiding in RSS Feeds

The first real finding in the investigation is not the fraudulent email. It is an inbox rule in the finance manager's mailbox, created weeks before the payment, that nobody made. The rule is simple: any incoming message containing words like "invoice", "payment" or "bank details", or anything from the supplier's domain, gets marked as read and moved to the RSS Subscriptions folder. A folder that exists in every Outlook mailbox and that no human being has ever opened on purpose.

The rule is the attack. It let the intruder lift a genuine invoice out of the conversation before finance saw it, send their doctored follow-up, and then quietly swallow the supplier's replies, including the one that said "we have not changed banks, please ignore that email". It also swallowed anything that might have raised suspicion, like security notifications. And because inbox rules live in the mailbox rather than the session, the rule kept working even after the user later changed their password for unrelated reasons. Rules like this are not exotic: incident responders consistently find that a large share of compromised Microsoft 365 accounts, by some counts around 40%, get a malicious mailbox rule within minutes of the break-in. In one documented case the gap between compromise and rule creation was eight seconds. It is the first thing the playbook does.

Further back: the sign-in that passed MFA

So who created the rule? The audit log answers that too: a sign-in from an unfamiliar network, three weeks before the payment, at 2:41 in the morning local time. Here is the uncomfortable part. That sign-in satisfied multi-factor authentication. The organisation had MFA enabled, the user had it registered, and the attacker walked through it anyway.

The mechanism is adversary-in-the-middle phishing, and it is now the standard entry route. The user had received a convincing email a day earlier and clicked through to what looked exactly like the Microsoft sign-in page. It was a proxy: every keystroke was passed through to the real Microsoft login, including the genuine MFA challenge, which the user completed because from their side nothing was wrong. What the attacker kept was not the password but the session token issued at the end, the small credential that tells Microsoft 365 "this browser has already authenticated". Replay that token from anywhere and you are the user, with no password prompt and no MFA prompt, until the token expires or is revoked.

The root cause was not the click

At this point in most internal post-mortems, someone writes "user clicked a phishing link" in the root cause box and schedules more security awareness training. That is the wrong lesson, and it is worth being precise about why. The click was the trigger. The root cause was a set of conditions that turned one click into a five-figure loss:

• A stolen session worked from anywhere. Nothing checked whether the token was being replayed from an unknown device or an unexpected country.
• The persistence step was invisible. A new inbox rule in a finance mailbox is one of the loudest signals a tenant produces, and nothing was listening for it.
• The payment control lived inside email. The process for changing a supplier's bank details was "receive an email asking us to".

Every estate has users who will eventually click; the click rate never reaches zero, however much training you buy, and the evidence on phishing simulations says they barely move it. A control that only works if no human ever clicks a link is not a control. The honest root cause statement is: our security model assumed authentication happens once, at sign-in, and everything afterwards is trusted. The attacker simply operated in the "afterwards".

Why three weeks passed unnoticed

The most painful line in the timeline is the gap. Between the 2:41am sign-in and the supplier's phone call, twenty-three days passed. In that time the attacker signed in repeatedly, searched the mailbox for "invoice" and "payment run", read the finance calendar, created the rule, and sent the bank-change email. Every one of those actions was logged. Not one log was read.

This is the quiet failure underneath most business email compromise: the evidence was available the whole time, and availability is not the same as attention. Small and mid-sized organisations, and the lean teams and MSPs who support them, tend to assume mailbox compromise is something that happens to bigger targets. It is not. Attackers do not shortlist victims; they automate, and a 40-person firm's finance mailbox pays out just as well as anyone's. A server going offline pages somebody at 3am. A foreign sign-in to the finance manager's mailbox, in most estates, pages nobody at all. That asymmetry, loud infrastructure and silent identity, is exactly what this class of attack exploits.

The changes that prevent the next business email compromise

The fixes fall out of the timeline in reverse order, and none of them is training. In rough order of value:

1. Take bank details out of email entirely. Any change to payment details gets verified by a phone call to a number already on file, never one from the email. This is a policy, it costs nothing, and it would have stopped this incident on its own even with everything else failing.
2. Alert on the persistence moves. New inbox rules that move or delete mail, new forwarding addresses, new OAuth application consents, new MFA methods registered. These are rare, high-signal events. In this incident, a single alert on rule creation would have cut the dwell time from three weeks to one morning.
3. Make stolen tokens worth less. Conditional access policies that require a compliant or known device for mail access, at minimum for finance and admin roles, mean a replayed session from an attacker's server fails even with a valid token. Block legacy authentication protocols while you are there; they skip MFA entirely.
4. Move the riskiest people to phishing-resistant MFA. Passkeys and FIDO2 keys bind authentication to the real site, so a proxy page has nothing to steal. Rolling this out to finance, executives and IT admins covers most of the payout targets with a fraction of the effort of a full rollout.
5. Rehearse revocation. Know, before you need it, how to revoke a user's sessions in under five minutes. Resetting the password alone does not end a token-based intrusion, and it does not remove the rule.

If you have not hardened the tenant recently, our Microsoft 365 security checklist walks through the ten settings that close most of this off, including the conditional access and legacy authentication pieces above.

If you find one today: the first hour

Post-mortems are for the next incident. If you are reading this because you have just found the rule in someone's RSS folder, order matters:

1. Revoke sessions first, then reset the password. The reset alone leaves live tokens working.
2. Delete every inbox rule and forwarding address you did not create, and check the account's registered MFA methods and recently consented apps for anything the attacker added to keep a way back in.
3. Call the bank now, not after the investigation. Recalling a fraudulent transfer is measured in hours; after a day or two the money has usually been layered out of reach.
4. Assume lateral spread. Check other mailboxes for the same rule patterns and sign-in sources; attackers who land in one mailbox routinely phish colleagues from it, because internal mail is trusted mail.
5. Report and record. Action Fraud in the UK, IC3 in the US, and your insurer. Preserve the audit logs before retention quietly ages them out.

Where this fits with Helios

The pattern in this post-mortem, evidence that existed but was never looked at, is the problem Helios is built around. Helios connects to Microsoft 365 so identity sits in the same view as devices, patching, antivirus and backups, and Helio, the AI layer, treats an anomalous sign-in or a suspicious new mailbox rule the way it treats a failing disk: as something to investigate and surface now, not a log line to discover three weeks later. Whether you run IT for one business or for many, the goal is the same, to make the silent parts of the estate as loud as the servers.