Credential Compromise: Contain, Investigate, Recover

Credential Compromise Containment and Recovery

Most intrusions today begin with valid credentials: a password phished through a fake login page, a session cookie stolen by an adversary-in-the-middle kit that also bypasses one-time codes, an access key committed to a public repository, a service account token exposed in logs, or an OAuth app that a user was tricked into approving. Attackers then use legitimate access — reading mail, creating forwarding rules, registering their own MFA device, creating new access keys — which blends in with normal activity.

Responding well is a race and a checklist. Contain quickly by revoking sessions and credentials; scope what the attacker did and touched; eradicate every form of persistence, not just the original password; restore access through a verified, phishing-resistant path; and verify that the attacker does not return. Resetting a password alone, while session tokens, OAuth grants, and attacker-registered MFA methods remain valid, leaves the door open.

TL;DR

Contain first: disable or lock the account if needed, revoke sessions and refresh tokens, and deactivate exposed keys and tokens.
Scope: review sign-in logs, audit logs, and data access for the compromise window — IPs, devices, apps, and actions.
Remove persistence: attacker-added MFA methods, mailbox rules and forwarding, OAuth grants, app passwords, new users, roles, keys, SSH keys, and scheduled tasks.
Restore safely: verify identity out of band, reset credentials, enroll phishing-resistant MFA, and re-enable access.
Verify: monitor for re-entry, blocked attempts, and lingering artifacts; check other accounts targeted by the same campaign.
Prevent: phishing-resistant MFA, conditional access, short token lifetimes, secret scanning, and least privilege.

Quick Example

Containing a compromised Microsoft Entra ID user with Microsoft Graph PowerShell:

Containing a leaked AWS access key and scoping its use:

Core Concepts

Common Scenarios

Containment

Speed matters more than perfect scoping. In order:

Stop new access: disable or block sign-in where business impact allows, or apply a restrictive conditional access policy.
Kill existing access: revoke sessions and refresh tokens; for cloud keys, deactivate them; for compromised IAM role sessions, revoke active sessions.
Cut exfiltration paths: remove forwarding rules and external sharing created recently.
Preserve evidence: export relevant logs before retention expires.

Coordinate through the incident process with clear roles. See Security Incident Response.

Scoping

Answer: when did access start, from where, what did the attacker do, and what could they reach? Sources include identity provider sign-in and audit logs, cloud audit trails (AWS CloudTrail, Azure Activity Logs, Google Cloud Audit Logs), mailbox and file access logs, SaaS audit logs, endpoint telemetry, and source control and CI logs. Check whether the same phishing campaign or leaked credential affected other accounts, and whether the account had privileged roles. See Privileged Access Management.

Persistence to Remove

See OAuth Token Lifecycle and Session Management and Cookie Security.

Restoring Access and Verifying

Verify identity out of band (a call to a known number, manager confirmation, in-person verification) before restoring access — attackers impersonate victims to helpdesks.
Reset credentials and require enrollment of phishing-resistant MFA such as passkeys or security keys.
Re-enable the account with heightened monitoring and, if appropriate, conditional access restrictions.
Verify eradication: watch for sign-in attempts from known attacker infrastructure, re-created rules, and new keys over the following weeks.
Notify affected parties and meet legal and regulatory obligations when data was accessed.
Review the incident: how was the credential obtained, why wasn't it detected sooner, and what control would have stopped it?

Best Practices

Revoke Sessions, Not Only Passwords

Always invalidate sessions and refresh tokens, and check for stolen-token scenarios.

Hunt for Persistence Systematically

Use a checklist across identity, mail, OAuth, cloud, source control, and endpoints for every compromise.

Prepare Scripts and Permissions in Advance

Keep tested containment scripts and break-glass responder access ready, so containment takes minutes.

Remove the Root Cause

Deploy phishing-resistant MFA, conditional access, secret scanning, and least privilege based on what the incident revealed.

Common Mistakes

Password Reset Only

Missing Mailbox Rules

Restoring Access to the Attacker

FAQ

What should I do first when an account is compromised?

Contain access: revoke the account's sessions and refresh tokens, disable or restrict sign-in if needed, and deactivate any exposed keys or tokens. Then preserve logs and begin scoping.

Is resetting the password enough?

No. Stolen session tokens, attacker-registered MFA methods, OAuth grants, mailbox rules, and newly created keys can all survive a password reset.

How do I find out what an attacker did with a compromised account?

Review sign-in logs and audit logs for the compromise window — identity provider, email, file storage, cloud audit trails, and SaaS audit logs — focusing on unusual IPs, new apps, and privileged actions.

What is session token theft?

An attack in which the adversary steals an authenticated session cookie or token — for example through a phishing proxy or malware — and reuses it to access the account without needing the password or MFA again.

How do I prevent credential compromise?

Use phishing-resistant MFA, conditional access, short token lifetimes, secret scanning, least privilege, admin consent for OAuth apps, and user reporting of suspicious messages.