Overview
Credential resets are a critical containment and eradication action: revoking and replacing credentials the attacker may have compromised, so stolen passwords, keys, or tokens can no longer be used to regain access.
Learning objectives
- Explain why credential resets are essential during incident response.
- Identify which credentials must be reset after a compromise.
- Describe common pitfalls that undermine credential resets.
Core concept
Credential resets revoke and replace any authentication secrets the attacker may have obtained — passwords, API keys, tokens, certificates, and session cookies — so they can no longer be used. In most intrusions the attacker steals or abuses credentials (recall authentication anomalies, module 10), so isolating hosts alone does not remove that access: the attacker could log back in elsewhere with valid credentials. Credential resets close that door. Scope matters: the SOC resets not just the obviously compromised account but all credentials the attacker could have accessed — accounts used on compromised hosts, service accounts, shared secrets, and cached credentials. Effective resets also invalidate active sessions/tokens (not just change the password), because an existing session can outlive a password change. This action spans both containment (stopping ongoing access) and eradication (removing a foothold).
How it works
Once compromise is confirmed, the SOC identifies which credentials are at risk: the compromised user account(s), any accounts logged into the affected hosts, service accounts running on them, cached/stored credentials, API keys, and shared secrets. It then resets these — forcing new passwords, rotating keys and service-account secrets, and reissuing tokens/certificates as needed. Crucially, it invalidates existing sessions and tokens so an attacker with a live session or a stolen token cannot continue; simply changing a password may leave an active session valid. Where privileged or domain/directory credentials are involved, resets may need to be broad and carefully sequenced to avoid the attacker capturing the new secrets or to prevent operational disruption. Credential resets work together with isolation and persistence removal: isolation cuts network access, credential resets remove the attacker's valid logins, and persistence removal eliminates other footholds — together denying re-entry.
Practical example
Investigation shows the attacker compromised a user's password and used it to access three hosts, and that a service account was also running on those hosts. The SOC resets the user's password and — importantly — terminates all active sessions for that account so a live session cannot persist past the change. It also rotates the service-account credential and any API keys stored on the affected hosts, since the attacker could have read them. It verifies the resets propagate everywhere the credentials are used. Because the SOC reset all exposed credentials and killed active sessions — not just the one obvious password — the attacker's stolen logins are now worthless, complementing the earlier isolation. Skipping the service account or leaving sessions live would have left the attacker a way back in.
Cybersecurity relevance
Since most intrusions rely on stolen or abused credentials, credential resets are essential to genuinely remove attacker access — isolation and persistence removal are incomplete without them. Resetting the full set of exposed credentials (users, service accounts, keys, tokens) and invalidating active sessions denies the attacker the valid logins they would otherwise use to return. Incomplete resets — missing a service account, forgetting to kill sessions, or overlooking cached secrets — are a common reason incidents recur. This action, drawing on the authentication concepts from module 10, is a core part of both containing and eradicating a credential-based compromise.
Common mistakes
- Resetting only the obvious account, missing service accounts, shared secrets, API keys, or cached credentials.
- Changing passwords but not invalidating active sessions/tokens, leaving live attacker access intact.
- Poorly sequencing privileged/domain resets, risking either disruption or the attacker capturing the new credentials.
Key takeaways
- Credential resets revoke and replace all authentication secrets the attacker may have obtained, removing their valid access.
- Scope broadly: users, service accounts, keys, tokens, and cached/shared secrets — not just the one visible account.
- Invalidate active sessions and tokens, not just passwords; combine resets with isolation and persistence removal to deny re-entry.
Check your understanding
- Why is isolation alone insufficient when an attacker has stolen credentials?
- Which credentials should be reset after a host compromise, and why must active sessions be invalidated too?