Look for external forwarding, new inbox rules, OAuth grants, app passwords, and active sessions that survive the reset. If those are still present, the attacker may continue to observe mail or manipulate messages without needing the original password. Persistence in BEC often sits in delegated access paths rather than the password itself.
What signs show BEC persistence survived the password reset?
The strongest indicator is that the mailbox still behaves as if the attacker has a path into it. External forwarding, hidden inbox rules, OAuth grants, app passwords, and active sessions can keep working after a reset, because the password is only one access path. If those artifacts remain, the compromise is often still live.
Where BEC persistence actually hides after reset
BEC operators usually try to avoid relying on the password alone. They prefer mailbox-level persistence, delegated access, or token-based access that survives a credential change. That is why a reset can look successful while the attacker continues to read mail, alter messages, or wait for a payment thread to reappear.
Review the mailbox as a set of access paths, not as a single login event. A clean reset only removes one route; it does not automatically revoke forwarding destinations, application consents, refresh tokens, or sessions already established in the tenant. NHIMG’s Email Identity and BEC Guide is the best match when you need to trace those persistence paths end to end.
Which mailbox artifacts are the clearest persistence clues?
External forwarding to an unfamiliar address is one of the clearest signs, especially if it sends copies of messages outside the business after the reset. New inbox rules that auto-archive, delete, or mark messages as read can hide the attacker’s activity and suppress alerts. OAuth grants and app passwords are equally important because they can preserve access without reusing the changed password.
Active sessions are the other major clue. If a current session survives, the attacker may still access mail until that session is revoked, even though the user can no longer sign in with the old password. Identity Threat Detection and Response (ITDR) Guide helps frame these session and token artifacts as part of the compromise, not as separate hygiene issues.
Mailbox review should also include delegated mailbox permissions, rogue transport rules, mobile mail clients, and any connected applications that can send or read mail on the user’s behalf. Those are often more durable than the original password and can let the attacker keep manipulating invoices, approvals, or vendor conversations. For recovery mechanics and reset abuse, see Account Recovery and Help Desk Security Guide.
How should practitioners confirm the compromise is really gone?
Confirmation requires both mailbox inspection and access-path cleanup. The practical test is not “did the password change” but “can the account still receive, route, or act on mail in a way the user did not approve?” That means checking forwarding, rules, consented apps, device logins, and any session or token that still authorises mail access.
When the mailbox is part of a broader BEC pattern, validate the business side too. Review whether any finance workflow, vendor contact, or payment instruction changed while the attacker had visibility, because persistence in BEC is often used to time fraud, not only to steal data. The right response is to pair mailbox cleanup with message tracing and recipient verification before the account is returned to normal use.
Risk and Threat Considerations
A password reset can create false confidence if the attacker has already established mailbox persistence. The risk is continued surveillance and message manipulation from within a legitimate account path, which makes fraud harder to spot and can let the attacker wait for the next payment or approval thread.
Failure mechanism: The attacker keeps one or more non-password access paths, such as forwarding rules, OAuth consent, active sessions, or app passwords, so the reset does not remove all authorised control.
Impact: The mailbox can remain under attacker influence, enabling ongoing message interception, reply injection, invoice redirection, and delayed fraud even after the user believes recovery is complete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Password resets must also revoke or rotate surviving authenticators and sessions. |
| AC-2 — Account Management | BEC persistence often survives through account-level access paths and delegated access. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Mailbox rules, forwarding, and OAuth changes require log review to confirm persistence is gone. | |
| Recommendation — Revoke stale authenticators, tokens, and app passwords after a BEC reset. Review and remove unauthorized mailbox access paths and delegated permissions. Correlate mailbox and identity logs to confirm post-reset abuse is absent. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant reauthentication and authenticator lifecycle matter when sessions persist after reset. |
| Recommendation — Use strong reauthentication and authenticator replacement for recovered accounts. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stale tokens, app passwords, and sessions are authentication paths that can outlive a password reset. |
| Recommendation — Invalidate all bearer tokens and app credentials tied to the compromised mailbox. | ||
Practitioner Guidance
What to prioritise: Treat mailbox persistence artefacts as the primary recovery target. If forwarding, rules, OAuth grants, or sessions remain, they outrank the password reset itself because they preserve operational access.
What to verify: Confirm that every surviving access path has been removed, including hidden rules, delegated permissions, and third-party app consents. If you cannot prove revocation, assume the account is still exposed.
Decision rule: If the account participated in finance, procurement, or executive mail threads, do not restore business confidence until the mailbox is clean and recent outbound activity has been reviewed for manipulation.
Practitioner takeaway: In BEC recovery, the password change is only the start of containment; the real question is whether any mail-handling path still lets the attacker observe or act from inside the account.
Related resources from NHI Mgmt Group
- What are the signs that an attacker is still active after a password or MFA reset?
- What are the signs that macOS adware persistence is still active after removal?
- Why do still-valid secrets matter after public disclosure?
- Why do revoked sessions still matter after a password reset or offboarding event?