CyphrQ
Menu

Infostealers and Session Cookie Theft: Why MFA Isn't Enough

Infostealer malware can copy a logged-in session and skip MFA. How session cookie theft works, and the controls that make a stolen token useless.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

12 min read

An infostealer is malware that copies saved passwords and logged-in sessions from a browser, and a stolen session cookie can let an attacker skip multi-factor authentication (MFA) because the sign-in already happened. What stops it is keeping the malware off your devices, binding sessions to the device that created them, and ending sessions quickly when something looks wrong.

MFA is still worth having. It stops the large class of attacks that start with a stolen password. This post is about the gap it leaves, and the controls that close it.

What is an infostealer, and how does it steal session cookies?

An infostealer is a type of malware built to collect data from an infected computer and send it to the attacker. Browser data is the main target: saved passwords, autofill details, payment cards, and cookies.

A session cookie is a small piece of data your browser keeps after you sign in. It tells the website "this browser already proved who it is", so you are not asked for your password and MFA code on every click. A session token is the same idea for apps and APIs.

That convenience is the weakness. MITRE ATT&CK, the public catalogue of attacker techniques, describes the pattern in T1539 Steal Web Session Cookie: adversaries steal session cookies from web applications or services and reuse them to access those services as an authenticated user, without needing the user's credentials. Cookies can be taken from disk, from browser process memory or from network traffic. MITRE notes that stolen session cookies can sometimes bypass MFA.

Infostealers get onto a device the way other malware does, by someone running something they should not have. The person may see nothing wrong, which is why the defences below do not rely on spotting it.

Because MFA is checked at one moment: when you sign in. After that, the website trusts the cookie.

Picture a hotel key card. The front desk checked your passport when you got the card. A thief who copies the card never has to show a passport to open the door. The cookie is the card.

MITRE describes the second half of the attack in T1550.004 Web Session Cookie: because the session is already authenticated, reusing the stolen cookie can bypass some MFA protections. The attacker imports the cookie into a browser they control and the site treats them as you. MITRE adds that cookies are often valid for an extended period of time, even if the web application is not actively used.

Microsoft's token theft guidance puts it plainly in its token theft playbook: a token theft attack occurs when threat actors compromise and replay tokens issued to a user, even if that user has satisfied multifactor authentication. Because the authentication requirements were met, the attacker is granted access using the stolen token.

This is a different problem from the phishing-proxy attack covered in AI Phishing Protection for Small Business: The 30-Day Plan. There the cookie is captured while you sign in. Here the malware is already on your machine and takes the cookie after the sign-in is finished. The defence for the second case starts on the device.

You do not need to guess at the scale. Two sources show what this looks like in practice.

Lumma Stealer. In May 2025 Microsoft's Digital Crimes Unit took action against Lumma, a stealer sold as a subscription service to other criminals. Microsoft reported that between 16 March and 16 May 2025 it identified over 394,000 Windows computers worldwide infected with Lumma. A US court order allowed it to take down, suspend or block about 2,300 malicious domains. The US Department of Justice seized Lumma's central command structure, and Europol and Japan's JC3 helped suspend infrastructure in their regions. Microsoft says Lumma has been marketed and sold through underground forums since at least 2022 and names ransomware actors such as Octo Tempest (Scattered Spider) among its users. Microsoft's post lists passwords, credit cards, bank accounts and cryptocurrency wallets as what Lumma takes. MITRE's page for T1539 separately lists Lumma Stealer, RedLine, Raccoon, Vidar and others as stealers that harvest browser cookies.

Cookies used against email accounts. MITRE's T1550.004 page records two real cases. In the SolarWinds compromise, APT29 used stolen cookies to reach cloud resources, and a forged duo-sid cookie to bypass MFA on an email account. Star Blizzard bypassed MFA on victim email accounts using session cookies stolen with the EvilGinx phishing proxy. Neither case needed the victim's password at the point of access.

The honest limit: neither source tells you how many of the 394,000 machines had a session stolen, or how many stolen sessions were used. I have not found a published figure I could read at source, so this post does not give one.

What stops session token replay?

No single control does. Microsoft frames token defence in Protecting tokens in Microsoft Entra ID as minimise the risk of theft, detect and mitigate, and protect against replay. The table below is my plain-language grouping of the same ideas.

Layer What it does Example controls
Keep the malware off Stops the stealer running at all Patched browsers and operating systems, endpoint protection with real-time and behaviour monitoring, blocking illegal-software and risky web categories, no cracked software
Bind the session to the device A copied token does not work anywhere else Chrome Device Bound Session Credentials, Microsoft Entra Token Protection
Limit what a stolen session can do Shorten its life and make sensitive actions ask again Shorter session lifetimes, re-authentication for sensitive actions, a compliant-device requirement, alerts on unusual use
Revoke fast Ends the session when you find the theft Revoke sessions, not just reset the password

What are device-bound session credentials?

Device Bound Session Credentials (DBSC) is a Chrome feature that ties a sign-in session to a key held in the computer's secure hardware, so a copied cookie stops working elsewhere.

The most direct fix is to make the cookie worthless away from the device that created it. Google's Chrome team announced on 9 April 2026 that Device Bound Session Credentials (DBSC) is publicly available on Windows in Chrome 146, with macOS coming in a later release. The browser creates a key pair in hardware (the TPM on Windows, the Secure Enclave on macOS) that cannot be exported. The website issues short-lived cookies and hands out a fresh one only when the browser proves it holds the private key. A stolen cookie expires quickly and cannot be renewed without the key.

Google says it has observed a significant reduction in session theft for sessions protected this way, and gives no figures. The keys come from hardware modules, and Google says it is exploring software-based keys for devices without dedicated secure hardware, so assume such devices are not covered today. Google describes DBSC as designed to be an open web standard through the W3C process. The website must support it too: sites add registration and refresh endpoints on their side. As a user or admin, check whether the services you rely on have switched it on.

Microsoft's equivalent for business accounts is Token Protection in Conditional Access, covered in the next section.

Shorter lives and a second check for sensitive actions

Even without device binding, a stolen cookie is only useful while it is valid. MITRE's mitigation for T1539 is to clear persistent cookies regularly and shorten cookie lifetimes. For sensitive actions, such as changing payment details or activating an admin role, require a fresh sign-in with a passkey or security key, so a stolen session alone is not enough. Microsoft's guidance recommends exactly this, using authentication context in Conditional Access.

What should you do if an infostealer infected a laptop?

If you find an infostealer on a machine, changing the password is not the whole job. Microsoft's token theft playbook lists revoking current tokens as its own step, separate from resetting passwords. Its steps for a suspected token theft are:

  1. Block the user while you investigate.
  2. Revoke current tokens.
  3. Reset passwords.
  4. Remove any added MFA methods or devices the attacker registered.
  5. Delete suspicious inbox rules.
  6. Isolate and remediate the infected device. Rebuilding it is my recommendation, not the playbook's wording.
  1. Update browsers and operating systems automatically. Protections such as DBSC only reach you in current browser versions (Chrome 146 or later on Windows).
  2. Stop cracked and "free" software. Untrusted software is how malware runs on a work laptop. Give staff an approved route to get the tools they need.
  3. Run real endpoint protection on every laptop, with real-time and behaviour monitoring switched on, not just a scheduled scan.
  4. Use a separate browser profile, or a separate browser, for admin and finance work. Fewer extensions, no personal logins.
  5. Turn on passkeys or security keys for email, accounting and banking. They stop the password path, so the attacker needs the cookie route. See the 30-day plan.
  6. Write the incident step down: if a laptop is suspected, sign out everywhere, revoke sessions, reset the password, then clean the device. One page is enough.
  7. Ask your email and accounting providers whether they offer device-bound sessions or session-lifetime settings, and what the defaults are.

Going deeper: for security and IT teams

Threat model. The attacker is usually a commodity operator renting a stealer, not a targeted intruder. They need code execution as the user on one endpoint. They get whatever the browser holds: credentials, cookies, tokens and autofill. The result is a valid session in SaaS, mail, VPN or cloud consoles without a password prompt or MFA challenge. Passwords taken in the same sweep outlive the session, which is why cleanup must cover both.

ATT&CK mapping. T1539 Steal Web Session Cookie (Credential Access) covers collection. T1550.004 Web Session Cookie (Lateral Movement) covers replay. MITRE's mitigations for T1539 are M1047 Audit, M1032 Multi-factor Authentication (hardware tokens such as FIDO keys, plus Conditional Access that restricts sign-in to trusted devices), M1021 Restrict Web-Based Content, M1054 Software Configuration (clear persistent cookies, shorten lifetimes), M1051 Update Software and M1017 User Training. Its detection strategy DET0509 lists five analytics. AN1402 flags suspicious access to browser cookie stores and memory reads against browser processes. AN1406 flags session cookies or tokens used from unusual user agents or locations, and token reuse without reauthentication. For replay, DET0074 includes AN0201 (cloud app access with session tokens lacking matching MFA or credential validation), AN0202 (cookies reused from a different client type than the baseline, such as Chrome switching to curl) and AN0203 (web session tokens used in native Office apps without related token refresh).

Entra ID: Token Protection. Per Microsoft Learn (page updated August 2026), Token Protection is a Conditional Access session control that accepts only device-bound sign-in session tokens, such as Primary Refresh Tokens (PRTs). On Windows the PRT secret sits in the TPM. Native app enforcement is generally available on Windows, iOS/iPadOS and macOS for Exchange Online, SharePoint Online and Teams, plus Azure Virtual Desktop and Windows 365 on Windows. Browser-based support is preview only, for selected web apps accessing Azure Resource Manager (the "Windows Azure Service Management API" resource), on Windows and macOS. It requires Windows 10 or newer devices that are Entra joined, hybrid joined or registered. For Apple devices Microsoft lists MDM-managed devices only (macOS 14.0 or later, iOS/iPadOS 16.0 or later), and its page labels the Apple device section "Preview" while its availability table says GA, so confirm the current status before you plan around it. Microsoft's token protection guidance adds two limits: unregistered devices have no PRT, and protection applies only to the user who signed into the device. Deploy in report-only mode first, capture both interactive and non-interactive sign-in logs, and pilot with a group before enforcing.

Other Microsoft controls, as documented. Require a compliant device through Conditional Access, with an Intune compliance policy that requires a Defender for Endpoint machine risk of low or clear. Enable Defender Antivirus real-time protection, cloud protection, network protection and tamper protection. Configure Credential Guard on Windows. On macOS, disable iCloud Keychain sync for Entra tokens and use Platform SSO. Block device code flow wherever possible. Require interactive, phishing-resistant re-authentication (sign-in frequency set to every time) for sensitive authentication-context actions and for medium or higher sign-in risk. Use network-based enforcement with Continuous Access Evaluation (CAE) and strict location enforcement for CAE-capable apps.

Detection. Microsoft lists these as triggers: Entra ID Protection's Anomalous Token, Unfamiliar sign-in properties and Attacker in the Middle detections; Defender for Endpoint's attempted access of the Primary Refresh Token; and Defender XDR alerts "Stolen session cookie was used" and "Possible AiTM phishing attempt". Persistence signals include a new MFA method or passwordless credential, new device registrations, mailbox forwarding or inbox rules, and mass or unusual file downloads. In Sentinel the playbook queries AADUserRiskEvents filtered on unfamiliar or anomalous event types, SigninLogs by IP and device, AuditLogs for security-info changes, and OfficeActivity and CloudAppEvents for post-compromise activity. Note that anomalous token detections do not always have a matching SigninLogs entry, so check the other tables.

Test that it works. In a lab tenant, with consent and a test account, confirm what happens when a session is used from a second managed device and from an unmanaged one. Do not test with real user sessions.

Ask your vendors and team: - Which of our SaaS apps support device-bound sessions (DBSC or equivalent), and which only issue long-lived bearer cookies? - What is the default and the maximum session lifetime in each critical app? - When we revoke a user, does it end all sessions and refresh tokens, or only block the next sign-in? - Which endpoints lack real-time protection or a TPM, and so cannot use device-bound tokens? - Who is paged on a "stolen session cookie" alert, and how fast must they act?

Key takeaways

  • An infostealer copies saved passwords and logged-in sessions from a browser. A stolen session cookie can bypass MFA because MFA was already satisfied at sign-in.
  • MITRE ATT&CK tracks this as T1539 (stealing the cookie) and T1550.004 (replaying it). Microsoft's playbook says token replay works "even if that user has satisfied multifactor authentication."
  • Scale is real: Microsoft identified over 394,000 Windows computers infected with Lumma in a two-month window in 2025.
  • The strongest defence is making the session worthless off the device: Chrome's DBSC (Chrome 146 on Windows) and Microsoft Entra Token Protection do this, within the limits above.
  • Pair that with short session lives, fresh sign-ins for sensitive actions, keeping the malware off devices, and alerts on token reuse.
  • After an infection, resetting the password is not enough. Revoke sessions, remove added MFA methods and inbox rules, then clean the device.

Sources