What is an infostealer, and what does it actually take from a browser?
An infostealer is malware built to smash-and-grab credentials in one short run, then exit. From a browser it targets saved passwords, session cookies, autofill and payment data, and the local encryption keys that unlock them, plus crypto wallets, VPN configs, and files matching keywords. It rarely persists; the damage is done the moment data leaves.
- ▸Saved passwords. Chromium stores them in the Login Data SQLite file, encrypted with a key held in Local State.
- ▸Session cookies. The Cookies SQLite database holds authentication cookies, the real prize, because a valid session cookie bypasses passwords and often MFA.
- ▸The keys. On Windows the Local State key is wrapped with DPAPI; the stealer calls CryptUnprotectData in the user context to decrypt it.
- ▸Everything else. Autofill, saved cards, crypto-wallet extensions, messaging-app tokens, and documents matching wordlists.
Families like RedLine, LummaC2, StealC, and Vidar dominate public reporting; the mechanics are broadly the same. Initial access increasingly arrives via paste-to-run lures, see ClickFix Explained: Why Paste-This-to-Verify Is 2026's Top Initial-Access Trick.
Which host artifacts prove an infostealer ran?
Because stealers are fast and leave little behind, hunt the access pattern, not a dropped binary. The strongest artifacts are a non-browser process reading the browser's Login Data and Cookies files, DPAPI decryption calls outside the browser, short-lived process trees from script interpreters, and a burst of outbound traffic to an unfamiliar host.
- ▸Credential-store reads. Any process that is not the browser opening Login Data, Cookies, or Local State under a user profile. Map this to MITRE ATT&CK T1555.003 and T1539.
- ▸DPAPI abuse. CryptUnprotectData called by a process other than the browser or a legitimate credential tool.
- ▸Suspicious parentage. mshta, powershell, wscript, or a freshly written binary spawning from a browser download, the Run dialog, or a temp path.
- ▸Staging and exfil. An archive or folder of harvested files in temp, then a single outbound POST to a new destination.
Chrome's App-Bound Encryption, added in Chrome 127, raised the bar by binding the key to the app through an elevation service, but stealer authors adapted quickly, so treat it as friction rather than a fix.
What detection rules catch browser credential-store access?
Build detections around file access and process lineage using Sysmon plus your EDR. The high-signal rule is simple: a process image path outside the browser install opens a handle to Login Data or Cookies inside a user's browser profile. Enrich with the accessing process, its parent, and its signing status to cut noise.
- ▸File access rule. Sysmon Event ID 11 and your EDR's file-open telemetry on paths ending in the User Data profile's Login Data, Cookies, or Network Cookies, where the actor is not the browser or a sanctioned backup agent.
- ▸Process access rule. Sysmon Event ID 10 showing a process opening the browser process, or reading Local State, outside expected tooling.
- ▸Lineage rule. Event ID 1 process-create chains where a browser or Office app spawns a script host that then touches profile files within seconds.
- ▸Express as Sigma. Author these as Sigma rules so they port across SIEMs, and tune per-host allowlists for password managers and sync agents to control false positives.
For query-driven hunting of the same behavior across endpoints, our walkthrough Threat Hunting with VQL: Velociraptor Queries That Find Real Intrusions shows how to pull these artifacts at fleet scale.
How do you detect stolen session cookies being replayed?
Host rules miss the second act, the cookie used from the attacker's machine. Catch replay at the identity and application layer: a known session token suddenly arriving from a new IP, ASN, device fingerprint, or geography, or two active sessions for one user in impossible-travel time. Alert, then force re-authentication.
- ▸Impossible travel. The same session or account authenticating from two distant locations inside a physically impossible window.
- ▸Fingerprint drift. The same session cookie presented with a different user-agent, TLS or JA3 fingerprint, or device ID than it was issued to.
- ▸New ASN or hosting IP. A session that has only ever come from a residential ISP suddenly arriving from a cloud or VPS network.
- ▸Anomaly velocity. A quiet account performing bulk reads, mailbox-rule changes, or OAuth grants right after a location change.
Wire these signals from your identity provider, such as Entra ID or Okta, and your reverse proxy into the SIEM, and make the response revoke the session, not merely log it.
How do token binding and short TTLs shrink the blast radius?
Even perfect detection is reactive; binding and expiry make a stolen cookie worthless. Token binding ties a session to a device-held key so a copied cookie fails elsewhere, and short access-token lifetimes with refresh rotation force frequent re-checks. Together they turn a stolen token from a standing key into a briefly useful copy.
- ▸Bind the session to hardware. Device Bound Session Credentials and DPoP bind a token to a private key that never leaves the device; a lifted cookie is useless without it. mTLS-bound tokens achieve the same server-side.
- ▸Shorten access tokens. Minutes, not days. A stolen access token that expires quickly limits the window of abuse.
- ▸Rotate refresh tokens. One-time-use refresh tokens with reuse detection revoke the whole chain when a stolen copy is replayed.
- ▸Prefer phishing-resistant auth. Passkeys and FIDO2 remove the shared secret at login, though the session cookie issued afterward still needs binding.
Passkeys change the login story but not the session story, the governance nuance is in Passkey Governance: The Questions That Start After Rollout.
What belongs in an infostealer response runbook?
Assume every credential and session on the host is burned. The runbook: isolate the endpoint, revoke all active sessions and refresh tokens for the user, force password resets from a clean device, rotate any secret that touched the browser, and hunt for lateral movement or mailbox rules created with the stolen session.
- ▸Contain. Isolate the host in EDR before you pull triage data.
- ▸Revoke, do not just reset. Kill sessions and refresh tokens in the identity provider; a password reset alone leaves live cookies valid.
- ▸Rotate the blast radius. Any password, API key, or token saved in that browser profile is compromised, rotate all of them.
- ▸Hunt forward. Look for OAuth grants, inbox rules, MFA device enrollment, and SaaS access from the new session.
- ▸Preserve and learn. Capture the Login Data and Cookies timestamps and exfil telemetry for scope and reporting.
Because stealer logs are sold and reused, treat this as potential data-theft extortion exposure, the shift covered in Data-Only Extortion Is the New Ransomware: What Changes for Your Backup and IR Plan.
How TuniCyberLabs helps
TuniCyberLabs builds the detection-and-response stack that catches infostealers on both sides of the theft. We deploy and tune Sysmon and EDR rules for credential-store access, author portable Sigma detections, wire identity-provider and proxy signals into your SIEM for cookie-replay alerting, and roll out token binding, short lifetimes, and refresh rotation so a stolen session dies fast. We validate the whole chain with realistic testing and hand you a runbook your team can execute under pressure.
Want detection rules and session-hardening tuned to your stack? Explore our cybersecurity services.