The category is called infostealer malware — families with names like RedLine, Lumma, Raccoon, and Vidar. They aren't sophisticated nation-state implants. They're cheap, commodity tools sold as a service to low-skill criminals, and their goal is mundane: run on a victim's machine for a few seconds, vacuum up everything of value, and exfiltrate it. What they vacuum up has quietly become the engine behind a huge share of modern account takeovers and corporate breaches.
What a Stealer Actually Takes
When an infostealer runs, it doesn't sit around waiting to keylog your next login. It harvests what's already on disk and in memory, then usually deletes itself. In one pass it typically grabs:
- Saved passwords from browsers and some password managers
- Session cookies and authentication tokens from every logged-in browser tab
- Autofill data — names, addresses, sometimes payment details
- Cryptocurrency wallet files and browser wallet extensions
- System and browser fingerprint details — enough to help impersonate your device
The saved passwords are bad enough. But the session cookies are the prize, because of what they let an attacker skip.
Why the Session Cookie Beats the Password
Think about what happens when you log in somewhere with 2FA. You enter your password, you approve a push or type a code, and the server — now satisfied you're you — issues your browser a session token (usually stored as a cookie). From then on, your browser presents that token on every request, and the server takes it as proof that the full login already happened. You don't re-enter your password or 2FA on every click, because the token is the standing proof of authentication.
That's the weakness. If an attacker steals a valid session token, they can import it into their own browser and present it to the server — which sees a fully authenticated session and serves up your account. This is called pass-the-cookie, and the critical fact is what it bypasses:
Two-factor authentication protects the moment of login. A stolen session token represents a login that already succeeded. The attacker isn't logging in — they're resuming a session you already authenticated. There's no second factor to prompt for, because from the server's view, no new login is happening.
This is why "but I have 2FA" is not a complete defense against infostealers. The malware doesn't attack your login; it steps in after it. The same logic defeats most password managers for the stolen-session window: the credential was already used, the door is already open, and the attacker walks through the open door rather than picking the lock.
The Economy Behind It
What makes this an ecosystem rather than a one-off is the marketplace. Infostealer output is packaged into "stealer logs" — bundles containing one victim's harvested passwords, cookies, and fingerprint data — and sold in bulk on criminal marketplaces and Telegram channels. A buyer doesn't need to write malware or even understand it. They purchase fresh logs, load the cookies, and harvest accounts.
This division of labor is why several major corporate breaches in recent years have been traced back to a single employee's or contractor's personal device being infected with a commodity stealer. The credentials and session tokens for a corporate system ended up in a log, the log was sold, and a different criminal used it to walk into the company — no exploit, no zero-day, just a valid session someone else had paid pennies for.
The breach didn't start with a hacker targeting the company. It started with someone clicking a fake download on a home computer, weeks earlier, and a $10 log changing hands.
How They Get Onto Your Machine
Infostealers spread through ordinary social engineering, not exotic exploits. Common vectors include cracked or pirated software, fake installers for popular apps, malicious browser extensions, "fix your problem" instructions that have you paste a command into a terminal, and increasingly convincing fake CAPTCHA or "verify you're human" pages that trick users into running a command themselves. The throughline is that you run the program. That's also the good news — it means user behavior is a real line of defense, not just luck.
What Actually Defends Against This
Because the attack targets the session rather than the login, the defenses are different from the usual password advice.
| Defense | Why it helps against stealers |
|---|---|
| Don't run untrusted software | The single highest-value control. Avoid cracked apps, paste-this-command pages, and unofficial installers — the primary infection routes. |
| Phishing-resistant 2FA (passkeys / hardware keys) | Doesn't stop a stolen cookie by itself, but eliminates the password-phishing path stealers also feed, and underpins device-bound sessions. |
| Device-bound sessions | Newer schemes cryptographically tie a session token to a key held in your device's secure hardware, so a copied cookie is useless elsewhere. |
| Short session lifetimes & re-auth for sensitive actions | Shrinks the window a stolen token is valid and forces a fresh check before high-stakes operations. |
| Revoke sessions after any compromise | "Log out all devices" invalidates stolen tokens. After any suspected infection, rotate passwords and kill every active session. |
The structural fix: binding the session to the device
The most promising long-term answer attacks the root cause: a session token shouldn't be a bearer credential that works for anyone holding it. Emerging standards bind a session to a private key generated in the device's secure hardware — a TPM or secure enclave — so the browser must cryptographically prove possession of that key on each request. A copied cookie alone no longer works, because the attacker can't extract the hardware-held key. Google's Device Bound Session Credentials proposal is one effort in this direction, and it mirrors the same principle that makes passkeys resistant to phishing: the secret never leaves the hardware, so stealing a copy of what's on disk isn't enough.
The Mental Model Worth Keeping
The lesson of infostealers is that an authenticated session is itself a secret worth protecting — often more worth protecting than the password, because it has already cleared every check the password and 2FA were meant to enforce. We've spent two decades teaching people to guard their passwords. The attackers quietly moved one step downstream, to the token that says the password check already passed.
Practically, that means two habits. First, treat "run this program" as the high-risk decision it actually is — most stealer infections are self-inflicted at that exact moment. Second, when anything feels off, don't just change your password; revoke your sessions too. A password change alone leaves the attacker's stolen session alive and well. You have to close the door they're already standing inside.