Business email compromise: the inbox rules you are not watching

Business email compromise is not really about reading email. It is about controlling a mailbox quietly enough to commit fraud, and the quiet part is almost always an inbox rule. The money moves because the request comes from a real, trusted account, and it keeps moving because the persistence the attacker plants lives somewhere a password reset never touches. That last point is the one most response efforts get wrong, and it is why the same organizations get hit twice.

The mental model worth carrying into every BEC case is this: the compromise does not live in the password. It lives in the mailbox’s configuration and in the tokens that already authenticated. Reset the credential and you have changed the lock on a door the attacker stopped using hours ago.

Why does BEC keep working after you reset the password?

Because the password is not where the attacker’s foothold is. Three things typically outlive a reset, and all three are the actual compromise.

The first is the session. Modern mailbox takeovers frequently come from adversary-in-the-middle phishing or token theft, where the attacker captures a live session or a refresh token rather than the password itself. That token keeps authenticating after the password changes, so the “reset and done” playbook leaves the intruder signed in. This is the same lesson token theft teaches everywhere: disabling or rotating the credential does not kill a session that already exists.

The second is the rules. An inbox rule the attacker created does not care what the password is. It keeps auto-deleting the victim’s replies and forwarding sensitive mail regardless, silently, until someone removes it by hand.

The third is delegated access. If the attacker granted a mailbox delegate, added a FullAccess permission, or registered a rogue OAuth application, those grants persist independently of the password too. A reset that ignores them is cosmetic.

So the reframe is not academic. “We reset the password” is the sentence that precedes the second fraudulent wire.

How does the attacker get into the mailbox in the first place?

Increasingly, without ever learning the password - which is exactly why the reset-only response fails. Two initial-access paths dominate, and both hand the attacker something a credential change does not revoke.

The first is adversary-in-the-middle phishing. A convincing sign-in page proxies the real Microsoft login in real time, so when the victim authenticates and completes MFA, the kit captures the resulting session cookie or refresh token. The attacker replays that token and is inside as the user, MFA already satisfied. The password was never the point, so resetting it changes nothing the attacker relies on.

The second is help-desk social engineering, the technique Scattered Spider (Octo Tempest) made routine: call the service desk, impersonate an employee, and talk an agent into resetting MFA or the password for you. Here the attacker does get a credential, but they also get to enroll their own MFA method, which means the account is theirs until that rogue method and the sessions are removed. MFA fatigue - spamming push prompts until someone approves - is a third, lower-effort variant.

The operational consequence is the same in every case: the initial access produces a live session and often a persistence grant, not just a known password. That is why containment has to revoke sessions and tokens and hunt the rules and delegates, not simply rotate the credential. If you only reset what they never needed, you have not evicted them.

What does the attacker actually do inside the mailbox?

They turn a trusted identity into a payment instrument. Once inside, the attacker is not exfiltrating for its own sake; they are looking for money in motion - an open invoice, a pending wire, a real estate closing, a vendor relationship with predictable payment cycles. They find a live thread about a payment and they hijack it: they reply as the real person, or they wait for the counterparty to reply and intercept it, and they change the bank details at exactly the moment the transfer is about to happen.

The reason it works is authenticity. The fraudulent email is not a spoof and not a lookalike domain; it is a genuine message from your colleague’s real account, passing SPF, DKIM, and DMARC because it legitimately originated there. Every technical signal says trust this, because every technical signal is true. That is what separates BEC from ordinary phishing: phishing tricks a person into acting, while BEC uses a real account to make the request itself.

Groups like Scattered Spider (Octo Tempest) and the broader ecosystem of BEC crews have industrialized this. The initial access is often help-desk social engineering or an AiTM phishing kit; the payoff is a redirected wire. The mailbox is just the position from which the fraud is run.

Why are inbox rules the persistence you keep missing?

Because they are quiet by design, and they do the concealment and the exfiltration at the same time. The tell in a BEC case is rarely the login - logins from odd locations get lost in the noise of a mobile workforce and VPNs. The tell is the rules.

The classic pattern is a rule that moves or deletes any message matching the fraud - the counterparty’s domain, a subject line, keywords like “invoice” or “payment” - so that the victim never sees the replies happening in their own name. Paired with it is a forwarding rule that copies sensitive mail to an external address, giving the attacker ongoing visibility without having to log back in. Attackers hide these in plain sight by routing mail to folders no one opens: RSS Feeds, Conversation History, a rule named a single character or left blank.

In ATT&CK this is T1564.008, hiding via email rules, and it pairs with email collection and exfiltration over the forwarding channel. The important operational fact is the one already stated: none of it is removed by a password reset. Someone has to go find the rules.

How do you detect it in Microsoft 365?

You hunt the audit log for rule creation and modification, and you alert on external forwarding. Search the unified audit log for New-InboxRule and Set-InboxRule events, and prioritize the ones that forward to an external address, delete messages, or move mail to low-visibility folders. A rule that forwards externally, or one that quietly relocates a counterparty’s mail, is a high-fidelity signal - far higher than a geo-anomalous login.

Turn on mailbox auditing so those actions are recorded in the first place, and stand up alerting on external auto-forwarding specifically, because that single control catches both the persistence and the data leaving. Do not stop at inbox rules: check for tenant-wide transport (mail flow) rules that forward externally, for added mailbox delegates and FullAccess grants, and for newly consented OAuth applications with mail permissions. Each is a foothold that survives the obvious fix.

How do you contain and eradicate it, in the right order?

Order matters, because doing the visible step first tips the attacker while leaving their real access intact. Reset the password and, in the same motion, revoke the account’s active sessions and refresh tokens - the reset alone leaves the stolen session alive, so the revocation is the part that actually evicts them. Then remove the malicious inbox rules and any forwarding, and block external auto-forwarding across the tenant so the channel cannot simply be recreated. Enforce MFA on the account, recognizing that AiTM can defeat some MFA, so pair it with conditional access and, for the highest-risk roles, phishing-resistant methods. Finally, audit for the persistence that hides one level up: mailbox delegates, FullAccess permissions, and rogue OAuth grants, at both the mailbox and tenant level.

Then scope backwards. Which threads did the attacker touch? Which counterparties received mail from this account during the compromise window? A BEC that redirected one wire has often teed up others, and the counterparties may be mid-fraud without knowing it. Containment is not complete when the account is clean; it is complete when the fraud in flight has been chased down.

Why is this a finance-process problem, not only a security one?

Because the fraud pays off in the finance workflow, and that is where it is cheapest to stop. Every technical control above reduces the odds of a takeover, but none of them guarantees it, and the whole point of BEC is that the malicious request looks perfect. The control that does not depend on catching the intrusion is a human one: any change to payment details - a new bank account, a new routing number, an “urgent” change to a pending wire - is verified out of band, by calling a known phone number for the counterparty, never by replying to the email thread.

That habit is decisive because it breaks the attacker’s only real advantage. They control the mailbox, so they control the thread, so any verification that stays inside the thread verifies nothing. A single phone call to a number you already had defeats the payoff even when the mailbox is fully owned. Security teams should treat that finance control as part of the BEC defense, not as someone else’s problem, and should build the muscle before an incident rather than during one.

The through-line holds all the way down: the compromise is not the password, and the defense is not the password reset. It is the session you revoke, the rules you remove, the delegates you find, and the phone call finance makes before the money moves.