Posted on

Business Email Compromise Guide: 5 Hidden Persistence Traps

Business Email Compromise Mailbox Review

Most business email compromise guide advice ends at the same two instructions: reset the password and turn on multifactor authentication. Both are right and neither evicts the attacker. In the mailbox investigations our team runs, the account is usually reported clean within an hour and the intruder still has working access, because what they left behind does not depend on the password they stole. Five footholds survive a reset. Each one is a setting a legitimate administrator could have made, which is exactly why a quick review walks past them and the second fraudulent invoice arrives a fortnight later.

The Five Things This Guide Assumes About Your Tenant

  • You run Microsoft 365 or Google Workspace with fewer than 300 mailboxes and no dedicated security team watching sign-in telemetry.
  • You already know how these attacks begin and how to harden against them. If that groundwork is missing, start with our explainer on what business email compromise is and how to prevent it.
  • Your first response to a suspected compromise was a password reset, possibly hours after the sign-in that mattered.
  • Nobody has looked at the mailbox’s rules, connected applications, or active sessions since, because none of those appear in the incident report.
  • Your audit retention is whatever came with your licence, which for many small tenants is shorter than the time it takes to notice a problem.

Why a Business Email Compromise Guide Should Not End at the Password Reset

A password reset invalidates one credential while leaving every other access path the attacker established untouched, which is why an account can be genuinely remediated on paper and still be sending mail on behalf of the intruder. The credential was the door. Once inside, an attacker with even brief mailbox access spends their first minutes building routes that do not need the door again.

We see the timeline repeat. The intrusion is noticed because a client queried an invoice, the helpdesk resets the password that afternoon, and the ticket closes. Three weeks later a second fraudulent payment request goes out from the same mailbox, worded correctly, quoting a real project. Nothing was re-breached. The original access never ended, and our write-up of how we stopped an email account compromise in minutes exists because speed of eviction matters more than speed of reset.

Trap 1: The Inbox Rule That Hides the Conversation

An attacker-created inbox rule keeps the fraud invisible by moving the victim’s own replies out of sight, and it keeps working after a password reset because a mail rule belongs to the mailbox rather than to the session. The construction is simple and effective. A rule matches on words such as invoice, payment, wire, bank, or a named client, and moves those messages to RSS Feeds, Conversation History, or a folder named with a single character that reads as clutter.

The effect on the victim is that their side of the conversation disappears. Finance replies to a supplier query and never sees the supplier’s confused answer, so the fraud runs on unchallenged for weeks. We have also found forwarding rules pushing copies to an external address, which continues exfiltrating mail long after the account is considered recovered.

Two variants are worth knowing because they hide in different places. A mailbox rule is visible to the user in their own mail client, so a determined check will find it. A transport rule sits at the tenant level, applies to mail flow rather than to one mailbox, and never appears in the user’s settings at all, which means a user-side review can come back clean while a copy of every message still leaves the organization. The second variant needs an administrator to look, and it is the one that survives a mailbox handover to a new employee.

Check every rule on the affected mailbox and read the actions rather than the names. Delete what you did not create, and record what it matched on, because the match terms tell you what the attacker was hunting and therefore which conversations to review with clients. There is a fair caution here: users create odd rules themselves and deleting one legitimately in use causes its own disruption, so confirm with the mailbox owner where the rule looks plausible. What is not defensible is closing an incident without reading the rule list at all.

Trap 2: The Connected Application a Password Reset Cannot Touch

An OAuth consent grant gives a third-party application standing permission to read and send mail under the user’s identity, and because that permission is not a password, resetting the password does not revoke it. This is the foothold that most often explains access continuing after remediation, and it is also the one almost no small-tenant review looks at.

The attack is a consent prompt. The user is shown a page asking an application to access their mailbox, the page is legitimate infrastructure from the identity provider, and the application is named something forgettable such as a document viewer or a mail add-in. Once granted, the application holds its own access, independent of the user’s credential and often surviving MFA enrollment as well.

Enumerate the applications consented to on the affected account and across the tenant, then revoke anything unrecognized. The wider governance point is that user consent is on by default in many tenants, which means any staff member can grant a stranger’s application access to their mail without an administrator involved. Restricting consent to administrator approval is a one-time change with real friction attached, and it is worth the argument. This is the same class of exposure as the unmanaged tools we cover in shadow AI oversight and unapproved tools, where the risk arrives through a legitimate approval path rather than a breach.

The Tokens and Registrations That Outlive Your Remediation

Session state and authentication methods are stored separately from the password, so both can carry an attacker past a reset, and clearing them takes deliberate action rather than a checkbox. This is the least intuitive part of eviction and the part most often skipped.

Trap 3: The Session That Never Ended

A refresh token issued before the reset can remain valid afterward, letting an attacker mint new access without ever re-authenticating, so an account shows a fresh password and a live intruder at the same time. Modern authentication trades a sign-in for tokens: a short-lived access token and a longer-lived refresh token that quietly obtains replacements. A password change does not automatically invalidate what is already issued.

The remediation step is to revoke sessions explicitly for the affected user, which forces every client to re-authenticate against the new credential. In practice this takes one action in the admin center and it is missing from most internal runbooks we review. Until it runs, the reset has changed what a new sign-in requires without touching what an existing session can already do.

Order matters more than people expect. Revoking sessions before the password is reset leaves a window where the attacker can sign in again with the credential they still hold and obtain fresh tokens, which puts you back where you started. Reset first, then revoke, then verify that recent sign-in activity shows no successful authentication from an address you cannot account for. Doing the two steps in the wrong sequence is a common reason a mailbox that was properly remediated shows renewed access within the hour.

The counterpoint worth acknowledging is user impact. Revoking sessions signs the person out everywhere, on every device, and for a partner in the middle of a client meeting that lands badly. Some administrators defer it for that reason. Deferring it during a confirmed compromise is the wrong trade, and the honest way to hold both is to make session revocation automatic on any suspected mailbox incident and accept the inconvenience as the cost of eviction.

Trap 4: The Second Factor the Attacker Registered

An attacker who reaches an account before MFA is enforced can enroll their own authentication method, which means enabling MFA afterward hardens the account around the intruder rather than against them. This is the trap that most convincingly produces a false sense of resolution, because the security posture genuinely improved and the report reflects that.

The mechanics are unremarkable. The attacker adds a phone number or an authenticator registration to the account. When MFA is later enforced, their method satisfies it. The user notices nothing, since their own method also works, and approval prompts arriving at an unfamiliar device are invisible to them.

Review the registered authentication methods on the affected account and remove any you cannot attribute to the user, then have the user re-enroll. Do this before enforcing MFA rather than after, because enforcement applied over a compromised registration list simply locks in whatever is already there. Phishing-resistant methods reduce the initial exposure, and the broader hardening sequence sits in our email security guide and the gaps SMBs miss.

What a Business Email Compromise Guide Should Say About Evidence

Eviction and evidence are separate jobs, and the evidence has an expiry date, so the audit record that would tell you what the attacker read is often gone before anyone thinks to ask for it. This is the trap with legal and client consequences rather than technical ones.

Trap 5: The Audit Log Expired Before You Looked

Unified audit retention on entry-level licensing is measured in months rather than years, so a compromise discovered late can leave you with no way to establish what was accessed, which is the question clients and insurers ask first. Detection frequently comes from outside, when a customer questions payment details, and by then the sign-in and mailbox-access records covering the intrusion may have aged out.

Two actions matter. Export the relevant audit data at the moment you suspect a problem rather than after the investigation is scoped, because export preserves what retention will not. Then check what your retention window actually is, rather than assuming, and extend it where the licence allows. A tenant holding client financial correspondence is carrying a records obligation that a default retention setting was never chosen to meet.

There is a second expiry nobody plans for. Audit search in most tenants has to be switched on before it records anything, and in older tenants it was off by default, so the question is not only how long the record is kept but whether it was ever being written. Confirm that auditing is enabled now, while nothing is wrong, because the answer cannot be changed retroactively. A firm that discovers during an incident that logging was never turned on has no investigative path left, only an assumption to disclose.

The scoping question is the one that determines your notification duties. Not whether the attacker sent mail, which is visible, but which messages they opened, which is only answerable from the audit trail. Firms that cannot answer it end up notifying broadly and conservatively, which is more expensive and more damaging to client confidence than a precise answer would have been. We hold this alongside recovery documentation for the same reason, which is the thinking behind our business continuity and disaster recovery practice and our continuity planning work.

Frequently Asked Questions

Does changing the password end a business email compromise?

No, it invalidates one credential and leaves inbox rules, consented applications, existing sessions, and attacker-registered authentication methods intact. Eviction means clearing all five, and the password is the easiest of them.

How do I tell whether an inbox rule was created by an attacker?

Read the action rather than the name. Rules that move messages matching payment terms into a low-visibility folder, or that forward externally, are not patterns users build for themselves. Confirm anything ambiguous with the mailbox owner.

Can multifactor authentication be enabled safely after a compromise?

Enable it, but review the registered methods first. An attacker who had access before enforcement may already have enrolled their own, in which case enforcement validates their method along with the user’s.

How long do I have to preserve evidence of a mailbox intrusion?

Export as soon as you suspect one, because retention on entry-level licensing is finite and often shorter than the discovery delay. Once the window passes, the record of what the attacker read is unrecoverable.

Is user awareness training still worth it if these footholds bypass it?

Yes, because training reduces how often the initial consent or credential theft succeeds, which is the cheapest place to stop the chain. Recognizing the lure remains the first control, and our guidance on avoiding phishing email scams covers that layer.

Who Is Behind This Advice

Mindcore handles mailbox compromise for professional services firms, medical practices, and construction and manufacturing clients across New Jersey and Florida. The five footholds in this article come from the investigations rather than from a vendor briefing, and the reason we can list them confidently is that we keep finding them in accounts somebody else already marked resolved. The pattern is consistent because the standard response addresses the credential and stops there.

Matt Rosenthal, our chief executive, holds the practice to eviction rather than reset as the measure of a closed incident, on the reasoning that an account is only recovered when every access path the attacker built has been removed and evidenced. That standard is why our mailbox reviews produce a list rather than a reassurance.

Check the Five Before You Call It Closed

A reset password and enforced MFA describe an account that is harder to break into next time, and neither says anything about whether somebody is still inside this time. You can check all five footholds on a suspect mailbox in under an hour. Read the inbox rules and note what they match on, enumerate the consented applications and revoke what you cannot name, revoke active sessions so existing tokens die, review the registered authentication methods and strip anything the user does not recognize, then export the audit data before retention takes it. If any one of those turns up something you did not create, the incident you closed was not closed. Our team runs this eviction sequence with SMB leadership regularly and can work alongside whatever provider handles your tenant today. Book a free strategy call and we will start with the rules and the consent list.

Related Posts

Matt Rosenthal