Because attackers often use session cookies and tokens that remain valid even after a password change. If the live session is not revoked, the account can stay reachable. Effective response has to invalidate existing sessions, not only update credentials, or the attacker may retain access long enough to continue activity.
Why session revocation beats password resets after infostealer exposure
Infostealers usually steal the thing that is already logged in, not just the password. That means the attacker may hold a valid browser cookie, bearer token, or refresh token that still works until the session is explicitly revoked. A password change can stop future logins, but it does not reliably invalidate the live session the attacker is already using.
What stays valid after the password changes
The practical problem is that many modern systems separate authentication from session continuity. A password reset changes the credential used to start a new session, but an existing session may remain trusted by the application, identity provider, or downstream service until its expiry or explicit termination. That is why token and session security has to be part of the response, not an optional follow-on.
In an infostealer case, the attacker often does not need to reauthenticate if the stolen session artifact still grants access. If the session is long-lived, refreshable, or accepted across multiple devices, the compromise can outlast the password reset and continue to expose data, admin functions, or connected applications.
What effective response needs to cover
Good containment starts by invalidating the active session set, not only updating the account secret. That usually means terminating browser sessions, revoking refresh tokens, invalidating API tokens where possible, and forcing reauthentication for sensitive workflows. If the account is linked to SSO, federation, or connected SaaS tools, the revocation scope has to reach the places where the attacker can still ride a trusted token.
This is why a response plan should pair credential reset with a review of session lifetime, token revocation capability, and device trust. A complete response also checks whether the stolen session could have been exchanged for other tokens, because attackers often use one valid session to pivot into email, cloud apps, source control, or help desk systems.
Risk and Threat Considerations
Infostealer activity turns session hijacking into a persistence problem. If defenders only reset the password, the attacker may keep operating through a still-valid cookie or token and preserve access long enough to steal mail, exfiltrate files, reset other accounts, or set up a stronger foothold.
Failure mechanism: The stolen session artifact remains accepted by the application or identity layer even after the password is changed, so the attacker does not need to know the new password to continue using the account.
Impact: The account can stay reachable after the reset, which extends dwell time, increases the chance of data theft or privilege abuse, and can leave the defender believing the compromise is closed when it is not.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Infostealers commonly steal session cookies and tokens that act as secret access material. |
| NHI-07 — Long-Lived Secrets | Session artifacts that remain valid after a password reset create the persistence problem here. | |
| NHI-10 — Human Use of NHI | The account remains usable by an attacker when human response ignores non-password access paths. | |
| Recommendation — Revoke exposed sessions and rotate any stolen tokens or secrets immediately. Shorten token lifetimes and require explicit revocation for active sessions. Treat session cookies and tokens as separate access paths from passwords. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Session and token invalidation are part of managing authenticators after compromise. |
| IA-2 — Identification and Authentication (Organizational Users) | The issue centers on maintaining authenticated access after credential change for a user account. | |
| AC-12 — Session Termination | The core control need is ending existing sessions rather than only changing credentials. | |
| Recommendation — Invalidate or rotate compromised authenticators and session material after exposure. Force reauthentication and terminate current sessions when compromise is suspected. Terminate active sessions promptly when compromise is detected. | ||
| OWASP ASVS | V7 — Session Management | This question is fundamentally about session lifetime, invalidation and replay after credential reset. |
| V6 — Authentication | Password resets change authentication material but do not automatically end already-issued sessions. | |
| Recommendation — Implement explicit session revocation and reauthentication after credential changes. Require fresh authentication before continuing sensitive account activity. | ||
| MITRE ATT&CK | T1539 — Steal Web Session Cookie | Infostealers often capture browser session material that attackers can replay. |
| T1528 — Steal Application Access Token | Access tokens stolen by malware can remain valid after the password changes. | |
| Recommendation — Hunt for stolen session cookie use and revoke any confirmed live sessions. Monitor for token theft and invalidate issued tokens after exposure. | ||
Practitioner Guidance
What to verify: Confirm whether the platform actually revokes active sessions when the password changes, or whether sessions continue until expiry. For high-value accounts, verify revocation across the browser, mobile app, SSO layer, and any issued refresh or API tokens.
Decision rule: If an infostealer may have touched the device, treat password reset as only one containment step. Revoke sessions first or in parallel, then assess whether the account needs step-up authentication, forced sign-out, or broader token rotation to close the exposure window.
Practitioner takeaway: With infostealer exposure, the real question is not whether the password changed, but whether the attacker’s existing access path was actually cut off.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org