October 14, 2026

Unmasking Infostealers: Hunting Browser Session Cookie Theft with CrowdStrike Falcon

The MFA Bypass Paradox: How Infostealers Hijack Active Session Tokens

By Asghar Raza

6 min read

The MFA Bypass Paradox: How Infostealers Hijack Active Session Tokens

Multi-Factor Authentication (MFA) has long served as the baseline defense against credential theft, effectively mitigating password spraying, credential stuffing, and rudimentary phishing attacks. However, modern threat actors have adapted to this defensive boundary by shifting their focus from initial authentication prompts to post-authentication artifacts. Rather than attempting to harvest static passwords or defeat real-time second-factor challenges, contemporary information stealers target live session cookies stored directly within local browser profiles.

When a user successfully authenticates to a cloud service or enterprise application, such as Microsoft 365, AWS, or Okta, the service issues an encrypted session token. This cookie is stored locally on the endpoint to maintain state across browser reloads, eliminating the need for repeated logins. Information stealers exfiltrate these active tokens directly from disk or volatile memory. Once transferred to an adversary-controlled infrastructure, these stolen session cookies are imported into separate browser instances via session-replay tooling. Because the session cookie represents a validated identity state, the cloud service treats the adversary as the authenticated user. Consequently, the attack completely circumvents secondary authentication prompts, hardware tokens, and push notifications without requiring real-time user interaction.

Attack Vector AttributeCredential PhishingLocal Session Token TheftPrimary Target

Passwords, PINs, and active OTP codes

Session cookies (HttpOnly, Secure), OAuth/SAML tokens

MFA Bypass Capability

Low (Requires real-time adversary-in-the-middle proxying)

High (Bypasses MFA via post-authentication token replay)

Interaction Required

User must interact with a rogue login portal

Requires local malware execution on the host endpoint

Primary Detection Point

Network edge, email security, web reputation filters

Endpoint process behavior, local file access, API calls

Adversary Impact

Temporary credential access until password reset

Full account takeover and immediate access to SaaS environments

Local Store Topography and Data Persistence

Chromium-based architecture — which underpins Google Chrome, Microsoft Edge, Brave, and Opera — organizes profile data using structured directories within user application paths. Sensitive browser state data is written to dedicated SQLite 3 database files stored within specific user profile paths:

  • Session Cookie Store: %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies
  • Stored Credentials: %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data
  • Web Form State: %LOCALAPPDATA%\Google\Chrome\User Data\Default\Web Data

Within the Cookies SQLite database, metadata fields such as the domain (host_key), cookie name (name), creation timestamp, and path are stored in plaintext. However, the actual session secret is held in the encrypted_value binary column to prevent unauthorized inspection.

Cryptographic Evolution: From DPAPI Master Keys to App-Bound Encryption

To prevent unauthorized access to local database files, browser developers implemented multi-layered cryptographic mechanisms. Understanding how these protection layers evolved is essential for tracking stealer behavior.

Prior to Google Chrome version 127, Chromium relied on the Windows Data Protection API (DPAPI). The browser generated a random 32-byte master key, encrypted it using DPAPI's CryptProtectData function, and stored the Base64-encoded string inside the %LOCALAPPDATA%\Google\Chrome\User Data\Local State JSON file under the key path os_crypt.encrypted_key. Information stealers targeted this file by decoding the Base64 payload, stripping the 5-byte DPAPI header prefix, and calling CryptUnprotectData within the context of the logged-in user. The resulting plaintext master key decrypted the encrypted_value column in the SQLite database via AES-256-GCM.

Google introduced Application-Bound Encryption (ABE) in Chrome version 127 to address the inherent security limitations of DPAPI. ABE binds the stored encryption key to the specific binary identity of the browser application. In ABE-protected instances, the Local State JSON contains an app_bound_encrypted_key designated by a v20 header prefix. Decrypting v20 keys requires interacting with Chrome's elevated system service, IElevator COM interface, preventing non-browser binaries from directly executing standard DPAPI calls to extract the key.

Cryptographic ParameterLegacy Chromium (v10 / Chrome < 127)Modern Chromium (v20 / Chrome 127+ ABE)Key Path in Local State

Underlying Cryptography

Standard Windows DPAPI (CryptProtectData)

DPAPI combined with Chrome IElevator COM identity validation

Decryption Boundary

Any process running within the user session

Validated browser binary and service path only

Primary Exploitation Vector

Direct file parsing and CryptUnprotectData API calls

Process injection, COM elevation abuse, and memory scanning

Modern Stealer Mechanics: Bypassing App-Bound Encryption

Threat actors developing stealer families such as Lumma, Vidar, and custom backdoors have adapted their execution models to bypass App-Bound Encryption:

  1. COM Elevation Abuse: Malware initializes Component Object Model (COM) interfaces (CoInitializeEx) and communicates directly with Chrome's elevated IElevator COM service. By masquerading as an internal browser component, the stealer forces the service to validate the request and decrypt the key on its behalf.
  2. Process Cloning and Memory Injection: Advanced stealers utilize low-level native system calls (NtCreateProcessEx) to fork a suspended duplicate of an active browser process (chrome.exe). The stealer scans the duplicated memory space for the 32-byte key pattern, marked by v20: byte headers. It then queues an Asynchronous Procedure Call (QueueUserAPC) into a legitimate browser thread to execute CryptUnprotectMemory, obtaining the plaintext AES key directly from active memory.

Recent Threat Actor Campaigns and Masquerading Lures

Weaponizing Crisis Lures: The Fake Update Campaigns

Threat actors frequently align their initial delivery lures with major technology events to maximize infection rates. In July 2024, following global IT infrastructure outages, threat actors deployed malicious campaigns masquerading as emergency CrowdStrike Falcon updates.

In one campaign, adversaries distributed malicious ZIP archives named CrowdStrike Falcon.zip. The archive contained a self-extracting executable that unpacked a Python-compiled information stealer known as Connecio. Upon execution, Connecio parsed browser profile paths across Chromium and Gecko architectures, extracted credentials and active cookies, and exfiltrated the harvested data via automated SMTP connections.

Concurrently, threat actors registered typo-squatted domains such as crowdstrike-office365[.]com to deliver malicious Microsoft Installer (.msi) packages. The installers dropped CypherIt-obfuscated AutoIt loaders that verified sandbox environments before executing Lumma Stealer. Once initialized, Lumma targeted Login Data and Network\Cookies SQLite files across all user profiles to capture live session tokens.

Initial Access Vectors: ClickFix, Fake CAPTCHAs, and Extension Hijacking

Adversaries leverage several primary distribution mechanisms to execute stealing routines on target endpoints:

  • ClickFix and Fake CAPTCHA Tactics: Attackers compromise legitimate websites to display fake browser error alerts or CAPTCHA verification popups. Users are instructed to execute a keyboard shortcut (Win + R), which copies an obfuscated command to the system clipboard and launches the Windows Run prompt (explorer.exe or wt.exe). The pasted script executes a PowerShell payload that fetches and runs the stealer directly in memory.
  • Extension Hijacking: Threat actors compromise existing web browser extensions or submit malicious extensions to official web stores. These extensions request permissions to inspect web requests and access browser APIs. Using background scripts, the extension invokes functions like chrome.cookies.getAll() to collect active session tokens for specific domain targets (such as cloud management platforms or financial services) and transmit them directly to third-party command-and-control servers.
  • Trojanized Installers and Software Mods: Game modifications, cracked software packages, and rogue performance utilities hosted on third-party forums are frequently bundled with obfuscated loaders like SharpLoader or Hades Stealer. These loaders patch Antimalware Scan Interface (amsi.dll) buffers before executing the core stealer payload.

Threat Hunting Mechanics in CrowdStrike Falcon

Telemetry Architecture and Key Event Identifiers

Detecting cookie theft requires monitoring process interactions with browser storage files and memory structures. The CrowdStrike Falcon platform collects granular endpoint events through native telemetry streams:

  • #event_simpleName = ProcessRollup2: Tracks process creation, command-line arguments, parent-child process trees, and process paths.
  • #event_simpleName = FileAnalysisEvent / GenericAccessHeader: Captures process reads, modifications, or file opens targeting browser profiles.
  • #event_simpleName = Inproc / QueueUserAPC: Detects cross-process memory manipulation and asynchronous procedure call queuing.
  • #event_simpleName = DnsRequest / NetworkAccess: Identifies outbound communication with external command-and-control servers.

Production CQL Queries for Falcon LogScale

Security operations teams can deploy the following CrowdStrike Query Language (CQL) queries within Falcon Next-Gen SIEM or Falcon LogScale to hunt for infostealer behavior.

Query 1: Non-Browser Process Access to Browser Storage Files

This query identifies non-standard binaries reading SQLite database files (Cookies, Login Data) or reading the Local State key container.

Code snippet

#event_simpleName = /^(FileAnalysisEvent|GenericAccessHeader|ProcessRollup2)$/
| event_platform = Win
| TargetFileName = /\\User Data\\(Default|Profile \d+)\\(Network\\Cookies|Login Data|Local State)$/i
| ImageFileName != /\\(chrome|msedge|brave|opera|firefox|vivaldi)\.exe$/i
| select([@timestamp, aid, ComputerName, UserSid, ImageFileName, CommandLine, TargetFileName, SHA256HashData])
| sort(@timestamp, order=desc)

Query 2: App-Bound Encryption Bypass via Cross-Process APC Injection

This query identifies non-browser processes attempting process injection or queuing APC calls into browser executables to scan memory or invoke decryption routines.

Code snippet

#event_simpleName = /^(ProcessRollup2|SetThreadContext|QueueUserAPC|CrossProcessOpen)$/
| event_platform = Win
| TargetProcessId = /\\(chrome|msedge)\.exe$/i
| SourceImageFileName != /\\(chrome|msedge|svchost|csagent)\.exe$/i
| where(SourceImageFileName != TargetProcessId)
| select([@timestamp, aid, ComputerName, SourceImageFileName, TargetProcessId, CallingProcessGraphKey])
| sort(@timestamp, order=desc)

Query 3: Catching ClickFix and Clipboard-Driven Execution Patterns

This query hunts for terminal engines or shell utilities launched from Windows Explorer following clipboard interactions.

Code snippet

#event_simpleName = ProcessRollup2
| event_platform = Win
| ParentBaseFileName = "explorer.exe"
| ImageFileName = /\\(powershell|cmd|wt|mshta)\.exe$/i
| CommandLine = /(-w\s+hidden|-e\s+|-enc\s+|iex|DownloadString|trycloudflare)/i
| select([@timestamp, aid, ComputerName, ParentBaseFileName, ImageFileName, CommandLine, UserSid])
| sort(@timestamp, order=desc)

Strategic Countermeasures and Enterprise Hardening

Deep Integration versus Extension-Based Security

Many organizations attempt to protect browser security by deploying extension-based security plugins. However, browser extensions operate within restricted sandbox contexts, preventing them from inspecting process memory or blocking external file access. Extensions cannot control low-level HTTP transport layers or prevent host malware from reading SQLite database files directly from disk.

Securing identity session tokens requires continuous visibility at the host and operating system level. Native endpoint sensors monitor memory calls, file system handle creations, and cross-process interactions. By monitoring the cryptographic chokepoints used to access browser storage, endpoint sensors can intercept unauthorized memory access, block process injection, and neutralize exfiltration attempts.

Endpoint and Identity Security Controls

To defend against session token theft, organizations should implement the following technical recommendations:

  • Restrict Inter-Process Scripting: Disable the Windows Run prompt for non-administrative accounts and enforce PowerShell Script Block Logging alongside Constrained Language Mode.
  • Enforce Strict Application Control: Implement Windows Defender Application Control (WDAC) or AppLocker policies to restrict unverified binaries from executing within %TEMP% or %APPDATA% paths.
  • Harden Chromium Group Policies: Ensure that App-Bound Encryption remains enabled across all enterprise browser installations via Group Policy (GPO).
  • Deploy Identity Session Controls: Configure identity providers to enforce strict IP-binding, device compliance checks, and shortened session lifetimes for sensitive SaaS applications.
  • Maintain Automated Threat Hunting: Implement scheduled CQL queries within Falcon Next-Gen SIEM to monitor access to browser profile paths and detect process injection anomalies.

Conclusion

The evolution of information stealers highlights a strategic shift toward post-authentication targets. By exfiltrating active session tokens directly from local Chromium storage, threat actors can bypass Multi-Factor Authentication controls without needing to proxy login attempts or interact with users. Mitigating this threat requires an understanding of browser cryptographic structures, vigilance against emerging bypass mechanics like COM elevation and memory injection, and continuous telemetry monitoring across endpoint processes. By utilizing targeted threat hunting queries and leveraging deep endpoint visibility with CrowdStrike Falcon, security teams can effectively detect credential dumping, prevent session hijacking, and protect enterprise cloud identities.