The breach that started on a personal laptop
A large share of the identity incidents we see do not start with a phishing page or an exploit. They start weeks earlier, on a machine the security team has never heard of: a contractor's gaming PC, a developer's home laptop, a shared family computer where someone downloaded a "cracked" video editor. An infostealer ran for a few seconds, packed everything it could find into an archive, and shipped it out. Then it deleted itself.
The victim organisation's controls never saw any of it. The first signal is a login that looks completely legitimate, because technically it is: the right username, the right password, and a valid session cookie that already passed MFA.
The 2024 Snowflake customer intrusions are the textbook case. Mandiant attributed them to a financially motivated group (tracked as UNC5537) that used credentials harvested by infostealers, some of them years old, against customer tenants that lacked MFA. No vulnerability in Snowflake was needed. The logs were enough.
What a stealer log actually contains
"Stealer log" is the trade name for the archive an infostealer exfiltrates from one infected host. Families differ (RedLine, Vidar, Raccoon, Lumma and their many forks), but the output converges on a familiar layout:
[US]203.0.113.42_2026-08-14T09-12-55/
├── System.txt # hostname, OS, HWID, username, locale, IP, installed AV
├── Screenshot.jpg # desktop at infection time
├── Passwords.txt # URL / login / password triplets from every browser
├── Cookies/
│ ├── Chrome_Default.txt
│ └── Edge_Profile1.txt # Netscape-format cookie jars, ready to import
├── Autofill/ # names, addresses, phone numbers, form history
├── CreditCards/
├── Wallets/ # browser-extension and desktop crypto wallets
├── Messengers/ # Telegram session files, Discord tokens
├── FileGrabber/ # *.txt, *.kdbx, *.rdp, *.ovpn from Desktop/Documents
└── InstalledSoftware.txt
Three items matter most to an enterprise defender:
- Passwords.txt maps the user's whole digital life, including corporate SSO, VPN portals, CI/CD, cloud consoles and SaaS admin panels. Personal and work identities are mixed, because people use one browser for both.
- Cookies are the real prize. A valid session cookie for Microsoft 365, Google Workspace, Okta, GitHub or Salesforce lets a buyer resume an authenticated session without ever seeing a login prompt.
- System.txt gives the buyer the victim's IP, locale and user agent, which helps them blend in with the original session (same country, same browser fingerprint) and slip past naive impossible-travel rules.
MFA protects the login, not the session. Once the user authenticated, the identity provider issued a cookie or refresh token. Whoever holds that artefact is, as far as the application can tell, the user. An infostealer simply copies it.
Why session cookie theft bypasses MFA
Modern authentication is a chain: password, then second factor, then a token or cookie that represents "this browser already proved who it is." MITRE ATT&CK splits the abuse into two steps: Steal Web Session Cookie (T1539) and Use Alternate Authentication Material: Web Session Cookie (T1550.004). The stealer side usually also maps to Credentials from Web Browsers (T1555.003).
The economics are simple. Phishing a session requires live interaction with the victim (see adversary-in-the-middle kits). An infostealer collects every live session on the machine at once, silently, for every service, including the ones that use the strongest MFA. Even phishing-resistant FIDO2 keys do not help after the fact: the key protected the sign-in, and the stolen cookie is the post-sign-in state.
Browser vendors have started to push back. Google added App-Bound Encryption to Chrome on Windows in 2024, tying cookie decryption to the Chrome process identity so that a stealer running as the user cannot trivially decrypt the cookie store. Stealer developers responded within weeks with workarounds (injecting into the browser, abusing the elevation service, or remote debugging). It raised the cost; it did not end the technique. The longer-term fix is binding sessions to the device, covered below.
The market: from infection to buyer in hours
The supply chain looks like a normal business with specialised roles:
| Role | What they do |
|---|---|
| Developers | Sell the stealer as malware-as-a-service, with a web panel, builder and updates, on a monthly subscription |
| Traffic teams ("traffers") | Distribute builds via malvertising, fake software sites, cracked games, YouTube "tutorials", ClickFix fake CAPTCHA pages |
| Log shops and clouds | Aggregate and resell logs, searchable by domain, country, or presence of specific cookies |
| Buyers | Initial access brokers, BEC crews, ransomware affiliates, crypto drainers |
Logs move through automated marketplaces (Russian Market is the long-running example; Genesis Market was seized by law enforcement in 2023's Operation Cookie Monster) and, increasingly, through Telegram channels that publish "cloud of logs" dumps or sell subscription access. Telegram lowered the barrier: anyone can buy, nobody needs forum reputation, and fresh logs can be filtered for a target domain within minutes.
Law enforcement pressure is real but episodic. In May 2025 a coordinated action led by Microsoft's Digital Crimes Unit, Europol and partners disrupted Lumma's infrastructure, seizing thousands of control domains. The ecosystem adapted, as it always has: affiliates migrated to other families and the markets kept selling.
The shape is the lesson. Cookies decay fast, so buyers act fast. Passwords decay slowly, which is why old logs still work against services without MFA, exactly the Snowflake scenario.
How defenders respond
1. Treat a stealer infection as an identity incident, not a malware ticket
Reimaging the laptop is necessary and nowhere near sufficient. Assume every credential and session on that host is in someone else's hands. The response has to happen at the identity provider and in every SaaS the user touched.
2. Revoke sessions first, then reset
Order matters. A password reset does not always kill existing sessions, and refresh tokens can outlive the password. In Entra ID:
# Microsoft Graph PowerShell: invalidate refresh tokens and session cookies
Connect-MgGraph -Scopes "User.RevokeSessions.All"
Revoke-MgUserSignInSession -UserId [email protected]
Then reset the password, review registered MFA methods (attackers love adding their own authenticator), and repeat the revocation for Okta, Google Workspace, GitHub, AWS SSO and anything else in the Passwords.txt for that host. Personal accounts matter too: the user's personal email is often the recovery address for something corporate.
3. Bind tokens to devices
The structural fix is making stolen tokens useless off the original device:
- Entra Conditional Access token protection binds sign-in session tokens to the device for supported clients.
- Device Bound Session Credentials (DBSC), a Google-led web standard proposal, ties browser sessions to a key held in the device's TPM, so an exported cookie cannot be replayed elsewhere.
- Compliant or managed device requirements for sensitive apps mean an attacker replaying a cookie from an unmanaged VPS fails the device check.
None of these cover everything yet. Prioritise admin portals, cloud consoles, finance systems and source code.
4. Monitor for the signals that survive
Detection is hard because the replayed session is valid. What tends to stick out:
- A session token used from a new ASN or hosting provider shortly after its issue from a residential IP.
- Same session, two different user agents or countries in a short window.
- New inbox rules, OAuth app consents or MFA method changes right after an unusual session (see our BEC breakdown for the mailbox follow-up).
- EDR telemetry of non-browser processes reading browser credential stores (
Login Data,Cookies,Local State).
# Pseudo-logic for a token replay hunt
session_id seen from IP_A (residential, user's country)
AND same session_id seen from IP_B (hosting ASN) within 24h
AND IP_B never seen for this user in the past 30 days
=> high-priority triage
5. Watch the exposure, not just the endpoint
Since most infections happen on unmanaged devices, your telemetry will never see them. External monitoring of stealer log sources for your domains is how you learn about the contractor's gaming PC. When an address shows up, check it on /email/ for associated exposure context, and treat the hit as a trigger for steps 2 and 3, not as an FYI.
What to do Monday
- [ ] Write the "stealer infection" playbook: revoke sessions, reset, review MFA methods, enumerate SaaS from the log, check mailbox rules.
- [ ] Confirm that revoking sessions in your IdP actually kills SaaS sessions downstream (many apps keep their own cookies).
- [ ] Enable device-bound or compliant-device controls for admin and cloud console access.
- [ ] Block personal browser profile sync on corporate devices, so personal infections do not inherit work sessions.
- [ ] Tighten session lifetimes for high-value apps; long-lived cookies are long-lived risk.
- [ ] Subscribe to exposure monitoring for your domains and route hits to the identity team, not a shared inbox.
- [ ] Remove any remaining SaaS logins without MFA. Old stealer logs exist precisely for those.
Infostealers win because they attack the part of authentication that comes after all your controls. Close the gap after login, and a stolen log becomes a stale text file.
