Infostealer malware: stolen browser sessions that bypass MFA

Infostealer malware is the quiet workhorse of modern account takeover. It does not lock your files or announce itself with a ransom note. It infects a single machine, empties the browser of everything it can read, and sends that haul to whoever is buying. The most damaging part of that haul is often not a password at all — it is a live session cookie that lets an attacker step into an already-authenticated session and walk straight past multi-factor authentication.

What an infostealer actually is

An infostealer (or "stealer") is a class of commodity malware built for one job: harvest credentials and other valuable data from an infected device, then exfiltrate it. It is sold as a service on criminal markets, so the same strain runs across thousands of unrelated victims. Well-known families in this category include RedLine, Raccoon and Lumma — but the family name matters less than the behaviour, which is remarkably consistent across the category.

Infection usually comes through the endpoint, not the website: a cracked application, a malicious ad, a fake installer, a poisoned "download this codec" prompt, or a phishing attachment. Once it runs, the stealer typically finishes its work in seconds and may even delete itself, so the victim rarely notices anything happened.

What it exfiltrates

Stealers target the places a browser and operating system keep useful data:

• Saved passwords — the credential store your browser offers to remember for you, decrypted on the machine the stealer controls.
• Autofill and form data — names, addresses, and sometimes payment details cached for convenience.
• Session cookies and tokens — the small values a site sets after you log in that keep you logged in. This is the crown jewel, and it is why MFA does not save you here.
• Other local secrets — cryptocurrency wallet files, VPN and FTP client configs, and similar stored credentials, depending on the strain.

The exfiltrated bundle from one machine is called a stealer log. It lists the infected device, the software on it, and every credential and cookie recovered — grouped by the sites they belong to.

Why stolen session cookies bypass MFA

This is the part worth getting exactly right, because it is widely misdescribed. Infostealers do not break the MFA algorithm, crack a TOTP secret, or defeat the cryptography behind a security key. They sidestep the login entirely.

When you sign in — password, then second factor — the server rewards a successful authentication by issuing a session token, stored in your browser as a cookie. On every subsequent request, your browser presents that cookie and the server treats you as already authenticated. You are not asked for your password or your second factor again for the life of that session; that is the entire point of a session.

A stealer copies that cookie. An attacker who imports it into their own browser presents a token that represents an authentication that already happened and already passed MFA. The server has no reason to re-challenge — from its point of view, this is the same logged-in session. The attacker never sees the login page, so there is no second factor to satisfy. This is session replay (sometimes called session hijacking or "pass-the-cookie"), and it works until the session expires, the user logs out, or the session is explicitly invalidated server-side.

The practical lesson: MFA protects the act of logging in. It does nothing for a session that has already been established and then stolen.

Why one infected device becomes a corporate problem

Stealer logs are traded in bulk — sold in bundles, dripped into subscription channels, or aggregated into searchable databases. Because the log is organised by site, a buyer can filter for a specific target: "show me every log that contains a session or credential for login.yourcompany.com."

That is how a single infected laptop turns into an exposure for your whole organisation. The infected device does not have to be a server or an admin's workstation. It can be:

• An employee's personal machine that they also use to check work email or a SaaS admin panel.
• A contractor or supplier with a login to your systems.
• A customer whose stolen session for your site enables account takeover against them — and reputational and support cost for you.

One log can contain the employee's SSO credentials, their live session cookies for a dozen internal tools, and their saved passwords — a ready-made foothold that no amount of firewalling your servers will prevent, because the theft happened on a device you do not control.

Defending against a threat that lives on the endpoint

Because the compromise happens off your infrastructure, this is fundamentally an endpoint plus identity problem. Server-side hardening still matters, but the useful controls are about limiting what a stolen session is worth and detecting exposure fast:

• Shorten session lifetimes and require re-authentication for sensitive actions. A cookie that expires in hours is worth far less than one that lives for weeks.
• Bind sessions to context where feasible — device, IP, or client fingerprint — so a token replayed from an unfamiliar location is challenged or refused. Treat this as risk signalling, not a silver bullet, since determined attackers can approximate context.
• Revoke sessions on risk signals: new device, impossible travel, or a password change should invalidate existing sessions, not just future logins. Make "log out everywhere" real and server-enforced.
• Adopt phishing-resistant MFA — passkeys and WebAuthn/FIDO2. They do not stop cookie theft on their own, but they eliminate the phishable password entirely and, when tied to re-authentication, make a stale stolen session far less useful.
• Harden the endpoint: EDR, blocking unsigned installers and cracked software, and keeping credential stores out of shared or personal machines. This is where the theft is actually prevented.
• Monitor stealer-log and breach intelligence for your domain, so that when a credential or session tied to your organisation surfaces in a log, you can force a reset before it is used.

That last point is where external monitoring earns its place. You cannot patch a laptop you have never seen, but you can watch the markets those laptops feed into and react the moment your domain shows up. It pairs naturally with the identity hygiene covered in retiring deprecated TLS versions and with keeping the software you run patched, as in WordPress plugin vulnerabilities — different attack surfaces, same principle of shrinking what an attacker can reach.

How Cyber Report checks this

Cyber Report runs a passive, external exposure check against stealer-log and breach intelligence for your domain — no packet is sent to your site to do it. It separates staff and corporate logins captured off infected machines (which we treat as critical, since they hand an attacker a direct foothold) from customers' stolen logins for your site (an account-takeover risk we flag as high), so you know which resets to force first.

See what we scan, or run a scan on your own domain to see where you stand.