Why do mailbox rules remain dangerous after a password reset?

Why This Matters for Security Teams

Mailbox rules are dangerous because they change the NIST Cybersecurity Framework 2.0 problem from simple credential recovery into a persistence and evasion issue. A password reset can block interactive sign-in, but it does not automatically remove inbox rules, forwarding targets, or message suppression logic already inside the tenant. That means an attacker can keep intercepting password resets, invoice approvals, and security alerts after the account owner thinks access has been restored.

This is the same lifecycle gap NHIMG highlights in incidents involving compromised identities and hidden persistence. The LLMjacking research shows how quickly attackers move once a secret or identity is exposed, while DeepSeek breach illustrates how exposed credentials and adjacent control failures can create a wider trust problem than the first compromise suggests. In practice, many security teams encounter mailbox rule abuse only after fraud, data theft, or missed alerts has already occurred, rather than through intentional lifecycle review.

How It Works in Practice

Mailbox rules live inside the email platform as account-level or tenant-level settings. Attackers often create forwarding rules, delete or archive messages containing security warnings, and move messages from key senders into hidden folders. Once those rules exist, the attacker can continue operating even after the original password is reset, because the rule is not an authentication artifact. It is an authorization and workflow artifact.

The right response is therefore broader than password rotation. Security teams should treat mailbox abuse as a persistence path and revoke the session, token, and rule set together. That means:

• Reviewing inbox rules, transport rules, and forwarding destinations during incident response.
• Removing suspicious rules before or immediately after credential reset.
• Invalidating active sessions and refresh tokens, not just changing the password.
• Checking whether alternate recovery channels were also changed by the attacker.
• Monitoring for rule recreation, which can indicate the compromise is still active.

Current guidance suggests using policy and alerting to detect high-risk actions such as automatic forwarding outside the organisation or rules that delete security notifications. Where possible, pair this with privileged access controls and mailbox auditing so changes are attributed and reviewed quickly. This aligns with the broader identity governance approach described in NHIMG research on exposed secrets and rapid attacker follow-on activity. These controls tend to break down in legacy mail environments, shared mailboxes, or tenants where auditing is incomplete because rule changes are difficult to attribute in time.

Common Variations and Edge Cases

Tighter mailbox control often increases operational overhead, requiring organisations to balance fast user recovery against the need to inspect every persistence mechanism. Not every rule is malicious, and that is where judgement matters. Auto-forwarding for assistants, ticketing workflows, or executive delegation can look similar to compromise, so best practice is evolving toward risk-based review rather than blanket deletion.

There is no universal standard for this yet, but the practical pattern is clear: reset passwords for containment, then validate mailbox state for recovery. In high-risk environments, teams should also look for OAuth consent abuse, shared mailbox delegation, and conditional access gaps, because these can preserve attacker access even when mailbox rules are cleaned up. Another common edge case is mobile mail clients that cache access and continue to sync data after the password changes, which can delay detection of continued exfiltration.

For incident responders, the key question is not only "Was the password reset?" but "Was the mailbox state restored to a known-good baseline?" That is the difference between closing an account compromise and leaving a live foothold behind.

Related resources from NHI Mgmt Group

• Why do compromised credentials remain dangerous even after a password reset?
• Why do leaked secrets remain such a persistent NHI risk?
• Why do leaked private keys remain dangerous after discovery?
• Why do leaked secrets remain dangerous after they are detected?