What are the signs that an attacker is still active after a password or MFA reset?

Why This Matters for Security Teams

A password or MFA reset is not the same as containment. If an attacker already has a live session, refresh token, mailbox rule, OAuth grant, or device-bound foothold, they can keep moving even after the victim changes credentials. That creates a false sense of closure and can delay incident response, which is why post-reset activity deserves the same urgency as initial compromise analysis. Guidance from MITRE ATT&CK Enterprise Matrix is useful here because it helps teams map what persistence looks like across identity, email, and session abuse.

Security teams often miss this because reset workflows focus on account recovery, not adversary eviction. The attacker may still read mail, approve access, register a new MFA factor, or pivot into SaaS applications without generating another obvious password prompt. That is especially dangerous in environments where identity events are fragmented across Entra ID, Google Workspace, VPN, endpoint, and help desk systems. In practice, many security teams discover an active intruder only after a second fraud event, mailbox tampering, or unexplained session activity has already occurred, rather than through intentional post-reset hunting.

How It Works in Practice

After a reset, the key question is whether the attacker’s existing trust still stands. Modern identity stacks often issue session cookies, refresh tokens, SSO assertions, or application-specific tokens that remain valid until they are explicitly revoked or naturally expire. If those artifacts survive the reset, the attacker may continue to operate with the privileges they already had. A reset may stop future password-based logins, but it does not automatically invalidate every live session or downstream token.

Operationally, investigators should look for evidence that access is being maintained through mechanisms other than the new password. Useful checks include:

• Active sessions from unfamiliar geographies, ASNs, or device fingerprints after the reset
• New MFA factors, recovery methods, or trusted devices added near the compromise window
• Mailbox forwarding, inbox rules, delegate access, or deleted security notifications
• Repeated SSPR attempts or help desk interactions designed to re-establish access
• Suspicious API calls, OAuth consent grants, or cloud app logins that continue after password change

This is where identity telemetry, endpoint telemetry, and SaaS audit logs need to be correlated quickly. CISA threat reporting and case guidance can help teams recognise common post-compromise patterns, especially when the attacker uses legitimate tools and timing to blend in with normal activity. When the environment has strong session management, the practical response is to revoke tokens, terminate sessions, remove unknown factors, and reset any adjacent credentials or app secrets that may have been exposed.

These controls tend to break down when organisations cannot centrally revoke sessions across all connected apps because the attacker simply shifts to whichever token, device, or mailbox path remains trusted.

Common Variations and Edge Cases

Tighter session revocation often increases operational friction, requiring organisations to balance rapid attacker eviction against user disruption and support load. That tradeoff becomes more difficult in federated environments, hybrid identity setups, and legacy applications that do not honour global logout consistently.

There is also no universal standard for how long a reset should be observed before declaring the account clean. Current guidance suggests treating continued activity as suspicious until session state, factor state, and recovery state are all verified, but the exact sequence depends on the platform. In some breaches, the attacker does not need to persist in the original account at all; they may have already created a secondary path through forwarding rules, delegated access, or a separate privileged account.

Agentic and AI-assisted intrusion tradecraft can accelerate this kind of persistence because automated tools can watch for resets, re-enrol factors, and retry access more quickly than a human operator. For that reason, NHI Management Group recommends treating post-reset monitoring as a cross-domain identity and detection problem, not just a password hygiene issue. Where AI-driven workflows are involved, the Anthropic report on first AI-orchestrated cyber espionage is a useful reminder that automation can compress attacker dwell time. Similar behavioural patterns are discussed in the CISA cyber threat advisories.

Related resources from NHI Mgmt Group

• Why do revoked sessions still matter after a password reset or offboarding event?
• How should security teams handle active sessions after a password reset?
• What breaks when password reset still depends on help desk workflows?
• What breaks when a password reset flow trusts attacker-controlled input?