Infostealer logs turn one infected laptop, often a personal or contractor device you do not manage, into a ready-made package of your passwords, session cookies and API keys that anyone can buy. Mandiant's investigation of the 2024 Snowflake campaign found that at least 79.7 percent of the accounts the attacker used had prior credential exposure, with the earliest linked infection dating to November 2020, which means the warning was available for years before it was acted on. This guide is about the response process: how to monitor for stealer logs that mention your organisation, triage them, invalidate what they contain and confirm whether it was used. It is for SOC analysts, threat intelligence teams and identity engineers. The malware families and infection routes are covered in the Infostealer Threat Guide.
Key takeaways
- A log entry is an incident, not intelligence trivia: treat any valid corporate credential or session in a stealer log as compromised until revoked.
- Sessions matter more than passwords: a stolen cookie can bypass MFA, and a password reset alone may not end existing sessions.
- Match on URLs, not only email domains: the most dangerous entries are logins to your SSO, VPN, data platforms and admin consoles, wherever the username is personal.
- Automate the first hour: enrichment, session revocation and user notification should run from the alert, with analysts handling the exceptions.
- Measure from infection date: the gap between infection and revocation is the number that tells you whether the programme works.
How the attack works
An infostealer runs once, harvests what the user's browser and applications hold, and uploads it as a "log" to the operator. Microsoft's May 2025 analysis of Lumma lists what a typical stealer takes: saved browser passwords, session cookies and autofill data from Chromium and Gecko browsers, cryptocurrency wallets, VPN configuration files, email and FTP client data, and documents from user folders, along with system metadata. Logs are then sorted, resold and searched by other criminals for logins that are worth something.
| Log content | What it enables | ATT&CK |
|---|---|---|
| Saved passwords with the URL they belong to | Direct sign-in where MFA is absent; password spraying elsewhere | T1555.003, T1078 |
| Session cookies | Replay of an authenticated session, bypassing MFA | T1539, T1550.004 |
| Tokens and keys in files, CLIs and environment files | API and cloud access as a non-human identity | T1552.001, T1528 |
| VPN profiles and remote access configuration | Network access with valid configuration | T1078 |
| System information (hostname, user, IP, installed software) | Target selection and matching the log to your organisation | N/A |
Infection usually depends on user action: phishing, malvertising for fake software downloads, cracked applications and fake CAPTCHA "ClickFix" pages that persuade the user to paste a command (T1204.004). In several Snowflake investigations Mandiant traced infection to contractor systems also used for gaming and pirated software, from which one laptop held access to multiple client organisations.
Where it shows up
Your organisation's data can appear in a stealer log in three distinct ways, and monitoring has to cover all of them:
- Corporate devices: the infected machine is yours. EDR may already have an alert; the log shows what left before containment.
- Personal and BYOD devices: a user's home computer holds their corporate SSO password through browser sync, or a personal browser profile signed in to work apps. You will have no endpoint telemetry.
- Third-party devices: a supplier, contractor or MSP technician's machine holds credentials to your systems under their own or your domain. The Scania insurance portal breach began with a legitimate external user's login to a partner-run application, which Scania believes was leaked by password-stealing malware.
Monitoring sources
| Source | What it gives you | Considerations |
|---|---|---|
| Commercial threat intelligence and dark web monitoring | Searchable stealer log collections, alerts on your domains and URLs, often with cookies | Coverage varies; ask how logs are obtained and how fast they are indexed |
| Breach notification services | For example, Have I Been Pwned offers stealerLogsByEmailDomain and stealerLogsByWebsiteDomain API endpoints for verified domains on a Pro subscription | Lists email and site pairs, not passwords or cookies; good for triage |
| National CERTs, law enforcement and vendors | Notifications after takedowns or investigations | Irregular; route them into the same workflow |
| Your own EDR | Infections on managed devices | Does not see personal or supplier devices |
| Platform providers | SaaS providers that detect leaked credentials or tokens and notify you | Make sure notifications reach the SOC, not a shared mailbox |
Data handling: stealer logs contain other people's personal data and live secrets. Do not buy logs from criminal markets, restrict access to the analysts who need it, store extracts encrypted with a short retention period, and agree the lawful basis with your privacy team before you start.
Impact
- Data platform theft: in the Snowflake breach, single-factor customer accounts using infostealer credentials led to data theft and extortion affecting about 165 organisations that were notified.
- Collaboration and project tools: in the Schneider Electric Jira breach, Hudson Rock linked the attacker's account of the breach to a Lumma infection on an employee's computer that also held migration account credentials.
- Session hijack of SaaS and cloud consoles: cookies give access without a password prompt. See the Infostealer Logs and Session Token Abuse Guide.
- Non-human identity exposure: developer machines hold cloud keys, package registry tokens and CI secrets that do not expire when the developer changes their password.
- Ransomware initial access: VPN and remote access credentials are sold to access brokers. See the Top 10 Ransomware Initial Access Vectors.
Detection
Triage and response workflow
- Ingest and normalise: pull each new log mention into a case with the infection date, device name, user, and the list of URL, username and credential type entries.
- Match to identities: match on your email domains and on your login URLs (SSO, VPN, webmail, data platforms, admin consoles, code hosting), because personal usernames on your URLs are easy to miss.
- Enrich: is the account active, is it privileged, when was the password last changed (if before the infection date, it is likely still valid), is MFA enforced, and is the device managed?
- Score: use the priority table below.
- Revoke: for every matched account, revoke sessions and refresh tokens, reset the password, review MFA methods, and rotate any keys or tokens in the log.
- Hunt for use: search sign-in logs from the infection date for the account, looking for new IPs, ASNs, devices and user agents, and for cookie replay without an interactive sign-in.
- Handle the device: isolate and reimage managed devices; for personal or third-party devices, notify the user or supplier and block access until it is cleaned.
- Close with evidence: record revocation times, hunt results and root cause.
| Priority | Criteria | Response target |
|---|---|---|
| P1 | Privileged account, IdP or cloud console session cookie, cloud or CI key, or any valid credential to a single-factor system | Revoke within [1] hour, hunt same day |
| P2 | Valid standard user credential for SSO or VPN; infection within the last 90 days | Revoke within [4] hours |
| P3 | Password already changed since infection, MFA enforced, no cookies | Confirm, notify user, monitor |
| P4 | Personal accounts only, or decommissioned services | Notify user with advice |
Session invalidation by platform
- Microsoft Entra ID: Revoke sessions in the admin centre or Revoke-MgUserSignInSession revokes refresh tokens. Microsoft notes access tokens remain valid for about an hour unless the app supports Continuous Access Evaluation, and that Entra ID cannot revoke an application's own session cookie.
- Other identity providers: clear all user sessions and OAuth grants for the user in the IdP admin console, then do the same in high value SaaS apps that keep their own sessions.
- Cloud and developer credentials: deactivate access keys, revoke personal access tokens and package registry tokens, and check for new keys created with them. See the Leaked Credential Response Playbook.
Detection signals on your own estate
- Endpoint: non-browser processes reading browser credential and cookie stores, and DPAPI decryption by scripting or .NET processes, which Microsoft provides hunting queries for. On Windows, Chrome's App-Bound Encryption logs Event ID 257 (source Chrome, Application log) when verification fails; Google presents it mainly as a compatibility signal, so use it as context.
- Identity: session use from a new ASN or country without a fresh interactive sign-in, and sign-ins from residential proxy ranges.
- Non-human identities: API keys and tokens used from networks they have never used.
Prevention and hardening
| Control | Effect on stealer logs | Notes |
|---|---|---|
| Phishing-resistant MFA everywhere, including data platforms and service users where supported | Stolen passwords alone stop working | Snowflake later moved to block single-factor password sign-ins |
| Token protection (Entra Conditional Access) | Binds sign-in session tokens to the device | Generally available for named native apps; browser support in preview and limited, so pilot in report-only mode |
| Device Bound Session Credentials | Binds web sessions to a TPM-held key with short-lived cookies | Requires site support; Chrome documentation notes malware present at registration may still extract the key. See the Device-Bound Session Credentials Guide |
| Network allow lists and device compliance | Stolen credentials fail from attacker infrastructure | Mandiant listed missing allow lists as a Snowflake factor |
| Short-lived credentials for workloads and developers | Keys in logs expire before resale | Replace long-lived keys with federation |
| Block browser password saving for corporate accounts; managed browser profiles | Fewer secrets in the browser store | Pair with an enterprise password manager |
| Endpoint hardening: no standing admin, application control, ASR rules, tamper protection | Fewer infections; App-Bound Encryption forces malware to elevate or inject | See the EDR Guide |
Rolling out the programme
- Weeks 0 to 4: inventory your login URLs and domains, connect at least one monitoring source, and agree data handling with privacy.
- Weeks 4 to 8: build the triage workflow and test revocation on volunteer accounts; run P1 cases manually.
- Weeks 8 to 12: automate enrichment and revocation for P1 and P2 cases with an analyst approval step; keep a rollback path (re-enable the account) for false matches.
- Ongoing: extend to suppliers through contract clauses requiring notification, and track the metrics below.
Small organisations can start with a breach notification service, manual revocation and MFA on everything. Large organisations need commercial coverage that includes cookies, URL matching across subsidiaries, and automated revocation through the IdP and SOAR.
Metrics
- Median time from infection date to revocation, and from log availability to revocation.
- Percentage of P1 cases revoked within target.
- Percentage of log entries where the credential was still valid at triage (falling as MFA and rotation improve).
- Repeat infections per user or supplier.
- Share of log entries from unmanaged or third-party devices.
Framework mapping
| Framework | Reference |
|---|---|
| NIST CSF 2.0 | ID.RA-02 (intelligence received), DE.AE-07, DE.CM-03, PR.AA-03, RS.MI-01 |
| NIST SP 800-53 Rev. 5 | SI-5, PM-16, IA-5, AC-12 Session Termination, SI-4, IR-4, RA-10 |
| MITRE ATT&CK v20 | T1555.003, T1539, T1550.004, T1552.001, T1528, T1078, T1204.004 |
Lessons from incidents
- Old logs still work: the Snowflake campaign used credentials stolen as early as 2020 that had never been rotated. Triage by infection date against password change date, not by when you first saw the log.
- Service and migration accounts leak too: the Schneider Electric case involved credentials named for migration work on an employee device. Inventory and rotate non-human accounts found in logs as P1.
- Suppliers are part of your exposure: contractor devices in the Snowflake campaign and an external user's login in the Scania case show that monitoring only your own domain misses logins to your systems held by others.
- Revoking the password is not enough: sessions and tokens outlive resets unless explicitly revoked.
Practitioner checklist
- List every login URL and domain that matters and monitor stealer logs for all of them.
- Route every source, including vendor and CERT notifications, into one case workflow.
- Compare infection date with password last-changed date during triage.
- Revoke sessions and refresh tokens before or alongside password resets.
- Rotate API keys, tokens and cloud keys found in logs as P1.
- Hunt sign-in logs from the infection date for each matched account.
- Require supplier notification of infections affecting your credentials.
- Enforce phishing-resistant MFA and pilot token binding for high value apps.
- Handle stealer log data under an agreed lawful basis with short retention.
- Report median infection-to-revocation time monthly.
Standards and references
- Google Cloud (Mandiant): UNC5537 targets Snowflake customer instances for data theft and extortion
- Microsoft Security: Lumma Stealer, breaking down the delivery techniques and capabilities
- Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
- Microsoft Learn: Token protection in Microsoft Entra Conditional Access
- Google Security Blog: Improving the security of Chrome cookies on Windows
- Chrome for Developers: Device Bound Session Credentials
- Have I Been Pwned: API v3 documentation (stealer logs)
- MITRE ATT&CK: Steal Web Session Cookie
Related NHI Mgmt Group resources: Infostealer Threat Guide · Session Hijacking and Cookie Theft Guide · Token and Session Security Guide · Leaked Credential Response Playbook