Infostealer incident response: a step-by-step containment checklist

Infostealer incident response is the ordered containment of a credential-theft infection: isolate the device, revoke live sessions and tokens, rotate exposed credentials, scope the blast radius across SSO, VPN and SaaS, then hunt for reuse and monitor for reappearance. A password reset alone does not contain it. SpyCloud recaptured 17.3 billion stolen session cookies in 2024, and each one is a login that survives the reset.

What is infostealer incident response?

Infostealer incident response is the containment workflow you run after a device is infected with credential-stealing malware and its stealer log has leaked. It differs from a generic phishing response in one way that matters: the attacker already holds valid credentials and, usually, a live session cookie. Recorded Future indexed 276 million credentials with active session cookies in 2025 (Recorded Future). That changes the order of operations.

NIST rebuilt its incident-handling guidance around this reality. SP 800-61 Revision 3, published in April 2025, maps response to the Detect, Respond and Recover functions, where containment and eradication sit inside Respond and restoration sits inside Recover (NIST SP 800-61r3). The checklist below follows that arc, tuned for the specific mechanics of a stealer log.

How do you identify the infected device and confirm the exposure?

Start from the log, not the endpoint. A stealer log names the host, the operating system and every saved credential, so read it before you touch anything. The hard part is that the infected machine is often one your controls never see. Verizon found 46% of systems holding corporate logins were unmanaged devices outside EDR coverage (Verizon 2025 DBIR).

• Match the log's machine fingerprint (hostname, OS build, local IP, installed apps) to an asset or a person.
• Enumerate every credential and URL in the log, not just the corporate ones, because reuse turns a personal login into a corporate key.
• Extract the cookie and token artifacts: those, not the passwords, decide how fast you must move.
• Flag whether the device is managed, unmanaged (BYOD or contractor) or fully out of reach, since that sets your eradication path.
• Timestamp the exfiltration if the log carries one, then assume the credentials are already for sale.

About 30% of infostealer-compromised systems were enterprise-licensed corporate devices, so a real share sits inside your fleet where you can act directly (Verizon 2025 DBIR). The rest need identity-side containment because you cannot reimage a machine you do not own.

Why revoke sessions and tokens before resetting passwords?

Because the attacker often does not need the password. A stealer log usually contains a live session cookie, which represents an already-authenticated session, so replaying it skips the login form and the MFA prompt. Recorded Future counted 276 million indexed credentials with active session cookies in 2025 (Recorded Future). Reset the password and that session stays valid until it expires or you kill it.

Sequence matters and so does speed. Recorded Future found 36.4% of stolen credentials were indexed within 24 hours of exfiltration and 53% within a week (Recorded Future). By the time your ticket is open, the log may already be listed. Revoke first, rotate second, so you are not resetting a password an attacker is happy to let you reset.

• Kill all active sessions for the user in the IdP (Entra ID, Okta, Google Workspace), not just the flagged app.
• Revoke OAuth grants and refresh tokens, which outlive a single session and re-mint access silently.
• Invalidate API keys, personal access tokens and .env secrets if the log came from a developer machine.
• Force re-authentication and re-enrollment of MFA, since a captured session can register a new factor.
• Only then reset the password, and do it for every account where the credential was reused.

The infostealer containment checklist, step by step

Run five moves in order: isolate, revoke, rotate, scope, monitor. The order is the point. A stealer log is a snapshot of one device but a key to many systems, so a linear reset misses the sessions and the reuse. Verizon named stolen-credential use the top initial-access action in 22% of breaches (Verizon 2025 DBIR), which is exactly what this sequence is built to shut down.

• Isolate: pull the identified device off the network if it is managed, and disable the affected accounts if it is not.
• Revoke: kill live sessions, OAuth grants and refresh tokens across the IdP before anything else.
• Rotate: reset passwords and secrets everywhere the credential appears, including every reuse.
• Scope: trace the blast radius across SSO, VPN, email and every connected SaaS the identity could reach.
• Monitor: watch for the same identity resurfacing in new stealer logs, because reinfection is common.

How do you scope the blast radius across SSO, VPN and SaaS?

Assume the identity, not the app, is compromised, then work outward from the IdP. One SSO credential fans out to every federated application, so containment that stops at the reported service leaves the rest open. Stolen-credential use was the top initial-access action in 22% of breaches (Verizon 2025 DBIR), and the attacker's next move is lateral into whatever the login unlocks.

• Identity provider: audit sign-in logs for the user, revoke sessions, and check for new MFA factors or app registrations.
• VPN and remote access: expire the session, rotate the credential, and review connection logs for unfamiliar geographies.
• Email: hunt for mailbox rules, forwarding and OAuth app grants an attacker uses to keep access after a reset.
• SaaS and cloud consoles: enumerate every app the SSO identity reached and revoke standing tokens in each.
• Privileged access: treat any admin or service account touched by the log as a priority-one rotation.

The ransomware link makes scoping non-optional. Verizon reported 54% of 2024 ransomware victims had their domains appear in infostealer credential dumps beforehand (Verizon 2025 DBIR). A stealer log is often the reconnaissance and the entry key at once, so under-scoping leaves the exact door the next stage walks through.

How do you hunt for credential reuse across the workforce?

Treat the leaked password as a pattern, not a single secret. Most people reuse, so one exposed credential opens several doors. SpyCloud found 70% of users exposed in breaches reused compromised passwords across multiple accounts (SpyCloud 2025). Search your identity stores for the same password, the same email and any variant before you call the incident contained.

The scale is why reuse hunting cannot be manual guesswork. SpyCloud recaptured 3.1 billion plaintext passwords in 2024, a 125% jump year over year (SpyCloud). Cross-reference the exposed identity against your directory and any breach-exposure feed, then rotate every match, not only the account named in the log.

How do you eradicate the malware and confirm it's gone?

Reimage the managed device; do not try to clean it. Infostealers ship as malware-as-a-service with fresh evasion baked into each build, and Flashpoint counted 11.1 million devices infected in 2025 spilling roughly 3.3 billion credentials, cookies and tokens (Flashpoint). A surface clean leaves persistence behind, and the log refills.

• Reimage from a known-good baseline rather than removing the detected binary.
• For unmanaged or contractor devices you cannot reimage, keep the accounts disabled until the owner proves a clean rebuild.
• Confirm eradication by validating that the revoked sessions and rotated secrets stay dead, not just that the file is gone.
• Document the timeline and the artifacts, which is the Recover work NIST SP 800-61r3 folds into restoration.

Eradication is where the identity work and the endpoint work meet. NIST's 2025 guidance ties containment and eradication together under the Respond function precisely because killing the malware without killing the stolen access, or the reverse, leaves the incident half-open (NIST SP 800-61r3).

How do you monitor for reappearance after containment?

Watch the criminal supply of stealer logs for your domains, continuously, from the outside in. The infection you just contained happened on a device your perimeter never saw, so the next one will too, and a SIEM rule fires only after the login attempt. Median attacker dwell time is 11 days, stretching to 26 when an outsider raises the alarm instead of your own team (Mandiant M-Trends 2025).

This is the post-compromise exposure model Ashetrace is built around: you verify a domain you control, and it surfaces which identities are exposed in fresh stealer logs so you can revoke and rotate before the credential is replayed. No passwords, cookies or tokens ever change hands. It turns monitoring from an after-the-login alert into a before-the-login signal.

So the question after any infostealer infection is not whether the credential leaked. At current volumes, assume it did. The useful question is how fast you can revoke the live session, rotate every reuse and confirm the identity is dead before someone else logs in with it.