Compliance

5 Signs Your BEC Incident Isn't Resolved: Verify Closure

5 Signs Your BEC Incident Isn't Resolved: Verify Closure

Know what attackers see before they do. See a live Radar report →

You changed the password. You forced a sign-out on all sessions. You told the team the incident is closed. But if you're like most small organizations recovering from a Business Email Compromise (BEC), you may have just locked the front door while leaving three windows wide open.

A password reset kills exactly one thing: the attacker's ability to log in with stolen credentials. It does nothing about the OAuth app they consented to, the inbox rule silently forwarding invoices to an external address, the rogue device they registered as a trusted authenticator, or the session tokens still valid from before the reset. According to The Hacker News, recent threat roundups have specifically flagged 'self-healing backdoor' techniques — malware and access mechanisms engineered to survive standard remediation steps like credential resets and session revocations. That's not a hypothetical. That's the exact gap small businesses fall into every day.

The scale of the problem is bigger than most IT admins realize. A phishing operation dubbed the Yam Store network has reportedly sent over a billion phishing messages, which means the raw volume of BEC incidents hitting small business inboxes is enormous — and most of those victims are self-remediating without a structured closure process, leaving persistence mechanisms fully intact.

Here are the five signs your BEC incident isn't actually over, and the checklist to verify it is.

1. You Haven't Audited OAuth App Grants

When an account is compromised, attackers frequently consent to third-party OAuth applications that request mail.read, mail.send, or offline_access scopes. These grants survive password resets entirely. Recent research into a flaw nicknamed 'SneakPeek' highlighted how stolen OAuth tokens (including tokens tied to AI tools like Claude) can be used for silent, zero-click access — proof that token-based persistence is a live, actively exploited attack surface, not just a theoretical one. Pull the full list of enterprise app consents in your M365 admin center and revoke anything unrecognized, especially apps granted during the suspected compromise window.

2. Inbox Rules and Forwarding Are Still Unchecked

Attackers love quiet forwarding rules that redirect finance or HR mail to an external address without ever touching the inbox view. Check every mailbox involved in the incident for hidden transport rules, forwarding settings, and delegate permissions — not just the compromised account, but any mailbox it had access to.

3. You Haven't Reviewed Registered Devices and MFA Methods

A common persistence trick is registering a new authenticator app or device during the compromise, giving the attacker a standing MFA method that survives a password change. Review registered devices and MFA methods for the affected account and remove anything that wasn't added by the legitimate user. This ties directly into the identity-layer monitoring gap we cover in our breakdown of ITDR vs. MFA vs. Conditional Access for stopping BEC — password hygiene alone was never designed to catch this.

4. Session Tokens Haven't Been Fully Revoked

Forcing a sign-out isn't the same as revoking all refresh tokens. If token lifetimes weren't explicitly invalidated, a stolen session can remain usable well past the password reset. Confirm all refresh tokens were revoked at the tenant level, not just the user session.

5. You Haven't Checked for Lateral Movement or New Admin Roles

If the compromised account had any elevated privileges, verify nothing was changed — no new service principals, no new admin role assignments, no new mail flow connectors. This is exactly the kind of identity-layer blind spot we outline in ITDR for small business, explained, and it's also why device-code phishing (covered in our MFA bypass guide) is so dangerous — it can hand attackers a valid session without ever touching the password.

Treat Closure Like a Checklist, Not a Feeling

Incident closure shouldn't be a gut call. Document each of the five checks above with timestamps and who verified them. If you're a government contractor working toward CMMC Level 1, this documentation isn't just good practice — it's evidence of your incident response maturity that auditors will ask about.

Take Action

A password reset feels like closure, but attackers are counting on that feeling to buy them more time. Proactive scanning catches lingering persistence mechanisms — rogue OAuth grants, forwarding rules, unauthorized devices — before they turn into a second breach. Oscar Six Security's Radar gives you an affordable $99 scan to verify your environment is actually clean, not just quiet. Check out our solutions to get started. Focus Forward. We've Got Your Six.

Frequently Asked Questions

What should I check after a business email compromise is fixed?

Beyond a password reset, verify OAuth app grants, inbox forwarding rules, registered MFA devices, session token revocation, and any new admin role assignments. Each of these can preserve attacker access even after credentials are changed.

Can an attacker still access my account after I change the password?

Yes. If OAuth tokens, inbox rules, or registered devices weren't addressed, an attacker can retain access long after a password reset. This is a well-documented persistence pattern in modern BEC attacks.

How do I know if my BEC incident is truly closed?

Run through a five-point checklist covering OAuth grants, mail rules, registered devices, token revocation, and privilege changes, then document each verification step. A scan from a tool like Oscar Six Radar can also independently confirm the environment is clean.

What tool can verify my Microsoft 365 account is fully secured after a breach?

Oscar Six Security's Radar offers a $99 scan that checks for lingering misconfigurations and exposure points, including the kind of persistence mechanisms attackers rely on after a BEC incident. It's an affordable way to confirm closure beyond a password reset.

What is M365 persistence in a security context?

M365 persistence refers to techniques attackers use to maintain access to a Microsoft 365 account even after the original compromise vector (like a stolen password) is remediated, such as OAuth grants, mail forwarding rules, or registered authenticator devices.

Step-by-Step Guide

  1. Audit OAuth app grants

    Review enterprise application consents in the M365 admin center and revoke anything unrecognized or granted during the compromise window.

  2. Check inbox rules and forwarding

    Inspect every mailbox the compromised account touched for hidden forwarding rules, transport rules, or delegate access.

  3. Review registered devices and MFA methods

    Remove any authenticator apps or devices added during the incident that weren't registered by the legitimate user.

  4. Revoke all session tokens

    Force a tenant-level refresh token revocation, not just a user sign-out, to ensure stolen sessions can't be reused.

  5. Check for privilege or configuration changes

    Look for new admin role assignments, service principals, or mail flow connectors created during the compromise window.

Find out what's exposed. Radar scans your external attack surface and shows you exactly what needs fixing. See a sample report →