Identity Threat Concepts - Cookie Stealing Part 1
- brencronin
- Jun 11
- 13 min read
Updated: Aug 27
Understanding Identity in Transit vs. Identity at Rest: The Session Hijack Problem
This article breaks down a key issue in modern identity protection: the critical difference between “Identity at Rest” and “Identity in Transit.”
1. Identity at Rest
Identity at rest refers to credentials stored on systems or in databases, password hashes, key material, etc. Traditional attacks here include:
Breaches targeting hashed credentials.
Well-defined defenses exist for this space:
Strong password hashing with salting (e.g., bcrypt, scrypt).
Limiting access and alerting on suspicious retrieval.
etc
These problems, while still relevant, are relatively well understood and defendable with best practices.
2. Identity in Transit
When users authenticate to web applications, stateless protocols like HTTP/S are typically used. To maintain the session without repeated logins, servers issue session tokens or cookies post-authentication.
The core security challenge is that these cookies/tokens function as bearer tokens, whoever holds them is granted access, without re-verification. On desktop operating systems, there's limited browser application isolation from the user's context, meaning any local malware running in the user's context can access the same browser memory and file space. Since the browser must access session cookies to function, so can the malware, making cookie/token theft a powerful method for identity compromise.
This is where a new class of risks emerge: if the session cookie/token can be stolen, the attacker can impersonate the user, without needing the password. Worse, these cookies/tokens often bypass MFA protections since they're issued after the MFA step.
🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪🍪
Cookies vs. Tokens: Understanding Their Roles in Web Authentication
In modern web authentication, the terms cookies and tokens are often used interchangeably, leading to confusion about whether they refer to the same thing. While they can work together, they are not exactly the same.
What Are Tokens?
Tokens are digital credentials issued by an authentication service after a successful login. They are used to maintain session state in stateless protocols like HTTP by verifying the identity of the user for subsequent requests, without requiring them to log in again.
There are several common types of authentication tokens, especially in cloud and federated environments:
Access Tokens: Security tokens used for authorization, allowing access to specific resources on behalf of an authenticated user. They contain claims that determine access rights, making them sensitive credentials that must be protected, and unlike ID tokens, they serve authorization rather than authentication purposes.
Session Tokens: Maintain the user's session with the web application (sometimes interchangeable with access tokens depending on the system).
Refresh Tokens: Used to obtain new access tokens without re-authenticating.
ID Tokens: Security tokens that prove a user has been successfully authenticated, containing claims with user information issued by the authorization server. They are always in JWT format and allow clients to verify user identity, functioning like digital name tags.
SAML Tokens: Used in SAML-based federated authentication systems.
OAuth Tokens: Facilitate authorization across services and APIs.
What Are Cookies?
Cookies are a browser-based storage mechanism defined by the HTTP specification. They are key-value pairs that a web server can set on a client’s browser and that the browser sends automatically with each subsequent request to the same domain.
Session Cookies store information that helps maintain a session state, such as a session ID or token.
Persistent Cookies remain on the device beyond the session and are often used for "remember me" functionality.
Cookies can contain tokens (e.g., a JWT or session ID), but they can also store other data. Additionally, some applications store tokens outside cookies, in localStorage or sessionStorage, though this comes with different security tradeoffs (e.g., vulnerability to XSS vs. CSRF, etc).
Tokens versus Cookies
Understanding the distinction is essential for understanding Identity in Transit incident response. Tokens are the mechanism by which authentication is verified. Cookies are just one of the transport mechanisms to deliver and persist those tokens.
To complicate matters, legacy applications may rely solely on session cookies that reference a server-stored session state without any use of access or refresh tokens. In contrast, modern cloud-native applications often use stateless tokens like JWTs, which can be stored in cookies or elsewhere depending on the security model.
The Identity in Transit Threat Landscape
There are two primary categories for how session cookies/tokens are compromised:
A. Man-in-the-Middle (MitM) Based Theft
These techniques intercept authentication sessions before or after login, capturing session tokens:
AiTM – Adversary-in-the-Middle: Attacker proxies user traffic to the real login page and steals the token post-authentication.
Tools: Evilginx2, Modlishka
BiTM – Browser-in-the-Middle: User operates in a tampered or malicious browser environment that intercepts authentication traffic.
These are especially dangerous because they don’t require system-level compromise, just user interaction with a malicious site or proxy. Common outcomes of this compromise include:
Business Email Compromise (BEC)
Initial access to corporate SaaS environments to further escalate compromises.
This article will not focus on that particular category of attack, as I’ve already covered it in depth in a previous breakdown: Adversary-in-the-Middle (AiTM) & Business Email Compromise (BEC).
Additionally, several companies are actively advancing detection and response capabilities in this space. A growing category of security solutions known as Identity Threat Detection and Response (ITDR) is specifically designed to detect, analyze, and mitigate identity-based attacks, including those that intercept credentials or hijack sessions in transit.
Examples of ITDR platforms that help organizations investigate and respond to these types of threats include:
These tools are instrumental in defending against sophisticated identity-centric threats that bypass traditional security controls.
B. Endpoint-Based Cookie/Token Theft (InfoStealers)
These involve direct compromise of the user’s system and extraction of session cookies/tokens stored in browsers:
Notable InfoStealers:
RedLine Stealer: Steals credentials, session cookies, and crypto wallets. Delivered via phishing or malicious ads.
Vidar Stealer: Grabs browser data and OS credentials, often spread via drive-by downloads.
Raccoon Stealer: Specializes in autofill data, passwords, and cookies.
Lumma Stealer: A newer MaaS stealer, actively updated and sold in cybercrime forums.
SocGhlosh: (also known as FakeUpdates) is a JavaScript-based malware framework used primarily for initial access in cyberattacks. It is often delivered through compromised legitimate websites and uses social engineering to trick users into downloading and executing malware, typically under the guise of a fake browser or software update.
Common ways InfoStealers get initial access to systems
Fake Games
Malvertising
SEO Poisoning
Fake Job ads
Vishing
Malicious VScode extensions
Malicious browser updates
Common InfoStealer Techniques once they have system access:
Remote browser debugging abuse
Browser process memory dumping
Direct cookie file extraction (e.g., from Chrome/Edge paths)
Malicious browser extensions with elevated access
While these require local compromise, they remain widespread due to stealer malware campaigns targeting everyday users and unmanaged systems.
Identity Attack Chain: InfoStealer Session Hijacking
Breaking down the identity attack chain specific to session cookie theft via InfoStealers:
1. Initial Access
The threat actor compromises the user’s endpoint, most commonly through:
Phishing emails
Malvertising
Trojanized software downloads
These initial infection vectors often deliver InfoStealer malware directly or via additional loaders.
2. Session Theft
Once on the system, the InfoStealer exfiltrates session data, such as:
Web browser session cookies
Stored credentials
System tokens or credentials (using tools like Mimikatz, though these are increasingly detected by EDRs)
Browser session theft is often stealthier and easier than browser memory access, making it the preferred technique when evading modern EDRs.
To enable session theft, attackers may:
Exploit remote debugging protocols (e.g., Chrome DevTools)
Dump browser memory or session storage
Install malicious browser extensions
Session Replay
The stolen session cookie or token is then injected into a new browser session controlled by the attacker.
No password or MFA prompt is then required
The attacker assumes the authenticated identity of the victim
The session grants full access based on the victim’s roles and permissions in the web-based consoles they access
Post-Exploitation & Persistence
If the compromised session belongs to a privileged user (e.g., administrator), via administrative web consoles the attacker can:
Modify configurations via web portals
Create new accounts
Create persistent backdoors
Move laterally across SaaS platforms
Escalate privileges or access sensitive data
This is why session cookies from active enterprise cloud platforms, such as Azure, Google Workspace, or AWS, are highly valuable targets for attackers during post-exploitation, as they enable seamless access without reauthentication.
Techniques for Browser Session Theft
Commonly used Threat Actor techniques to steal session cookies directly from web browsers:
Remote Browser Debugging Abuse
Browser Process Memory Dumping
Direct Cookie File Extraction (e.g., Chrome/Edge user data paths)
Malicious Browser Extensions with elevated privileges
1. Remote Browser Debugging Abuse
Attackers increasingly exploit remote debugging features to bypass newer browser security controls like Chrome’s App-Bound Encryption (ABE). By launching browsers like Chrome or Edge with the --remote-debugging-port flag, malware can expose the browser's internal APIs, granting direct access to session data such as cookies and tokens.
This method circumvents App-Bound Encryption (ABE), a security feature designed to protect sensitive data (like cookies) by binding decryption to the legitimate Chrome process. ABE relies on a privileged service to validate that only the authenticated Chrome application can access, and decrypt stored credentials. However, when debugging is enabled, this boundary is weakened, allowing info-stealers to retrieve decrypted session data without triggering typical OS-level access controls.
Example (Microsoft Edge):
msedge.exe --remote-debugging-port=9334(Note: Many of the infostealer families have been observed using port 9222, the default chrome browser debugging port)
To avoid alerting the user, the browser is often launched in headless mode which will launch the browser process without the gui:
--headlessTo load the victim’s profile data (cookies, history, bookmarks), attackers use:
--user-data-dir=C:\Path\To\User\DataOnce running, the malware connects to the exposed debugging port, uses the browser’s API to enumerate cookies, and exfiltrates session data.
Detection Strategies
Monitor browser launch commands for suspicious flags such as:
--remote-debugging-port=
--remote-debugging-targets=
--user-data-dir=
Atomic Red Team https://www.atomicredteam.io/ Example test:
Get-Process msedge | Stop-Process Start-Process "msedge.exe" "https://outlook.com --remote-debugging-port=9334 --remote-allow-origins=*"Tunneling Access to Remote Debugging Ports
A common technique used by threat actors in session theft attacks is traffic tunneling. Since browser debugging ports are typically accessible only on the local machine, attackers often expose them remotely using port forwarding.
To achieve this, they may use the netsh interface portproxy command to forward traffic from an external port to the local debugging port:
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=9443 connectaddress=127.0.0.1 connectport=9334Additionally, they may modify firewall rules to allow inbound connections to the remote listening port.
Additional Detection Opportunities related to remote port access
Monitoring for use of netsh interface portproxy or unusual firewall modifications on Windows endpoints may indicate attempts to expose local debugging ports, often a strong signal of infostealer or session hijacking activity.
Browser Process Memory Dumping - Post Decryption Cookie Theft Technique
Malware can perform process injection or memory access on running browser processes such as chrome.exe or msedge.exe to extract sensitive session data directly from memory. This technique targets the decrypted state of session cookies while they are actively loaded and in use by the browser.
Unlike file-based cookie theft (which requires decryption of encrypted cookie stores like Chrome’s Cookies SQLite DB), process memory dumping bypasses encryption altogether, since browsers must decrypt session cookies into memory for runtime use. Steps for browser process memory dumping.
Code Injection or Handle Access: The malware opens a handle to the browser process using Windows APIs like OpenProcess, and may inject malicious code using WriteProcessMemory or similar techniques.
Memory Read and Extraction: Using memory reading APIs (e.g., ReadProcessMemory), the malware scans the browser’s memory regions for identifiable cookie structures or session tokens.
Cookie Reconstruction: Extracted values (like Set-Cookie strings or JWT access tokens) are parsed and reused for authenticated session hijacking, no password or MFA needed.
Direct Cookie File Extraction (e.g., Chrome/Edge user data paths)
Direct Cookie File Extraction (e.g., Chrome/Edge User Data Paths)
Browsers like Chrome and Edge store session cookies in encrypted SQLite databases to preserve login sessions and protect user credentials. For Chrome, cookies are located at:
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\CookiesThese cookies are encrypted using DPAPI (Data Protection API), which ties decryption keys to the user’s Windows login context. While DPAPI provides effective protection against external access, malware running within the user’s session, such as infostealers, can leverage native Windows APIs (e.g., CryptUnprotectData) to locally decrypt cookie values.
Two Common Techniques Used by Threat Actors:
Local Decryption:
Infostealers directly decrypt the AES key using DPAPI within the infected session.
Remote Decryption:
Attackers extract the user's DPAPI master key from:
C:\Users\<User>\AppData\Roaming\Microsoft\ProtectIf the attacker can obtain the user's login credentials or DPAPI_SYSTEM secret, they can attempt offline decryption on another system.
Application-Bound Encryption (ABE)
In Chrome 127 (July 2024), Application-Bound Encryption (ABE) was introduced to mitigate these attacks. ABE ensures that even if malware runs under the user context, access to cookies is denied unless the decryption request originates from the legitimate Chrome process. This is enforced by a privileged Chrome service running as SYSTEM, which validates the request source before returning the decryption key.
To bypass ABE, infostealers have shifted tactics:
Remote Debugging Abuse: Launch Chrome with --remote-debugging-port to access session cookies via exposed APIs.
Downgrade Attacks: Some malware modifies registry keys to disable ABE protections. For example, in Microsoft Edge:
Registry Path: HKLM\Software\Policies\Microsoft\Edge
Key: ApplicationBoundEncryption
Value: 0 (disables ABE)Once ABE is disabled and the browser is restarted, session cookies become accessible using legacy decryption techniques.
Malicious Browser Extension Attacks
Malicious browser extensions are a stealthy threat vector that operate inside the browser’s security context, giving adversaries direct access to authentication cookies, session tokens, and other sensitive web data, without needing system-level exploits.
Disguised as legitimate tools (e.g., productivity add-ons or shopping assistants), these extensions often request excessive permissions, such as:
Access to all websites (<all_urls>)
Read/modify web page content
Use of browser storage APIs
Intercepting network traffic (webRequest, webRequestBlocking)
Once installed, a malicious extension can:
Read and exfiltrate session cookies in real time
Inject JavaScript to hijack active sessions
Capture sensitive form data and credentials
Bypass MFA through session token replay attacks
Why malicious extension attacks are dangerous?
Because they do not involve process injection or disk decryption, these attacks are highly evasive, often bypassing traditional EDR and antivirus solutions.
They persist through browser restarts and user sessions
Run with the same trust level as the browser
Easily evade endpoint-based detections
Can also exfiltrate data over encrypted HTTPS connections
Developer Mode: A Hidden Risk in Browser Extension Attacks
An often-overlooked risk in browser extension attacks is Developer Mode. When enabled, it allows unsigned or custom extensions to be manually loaded, bypassing standard extension signing and review processes.
Attackers can exploit this by configuring the browser to run in Developer Mode and loading malicious extensions as part of their attack chain. This tactic enables stealthy deployment of unauthorized extensions without triggering traditional extension security checks.
Browser extension attacks and the supply chain
Browser extensions are also rapidly emerging as a high-risk supply chain attack vector, exemplified by the 2024 Cyberhaven breach. In this incident, attackers compromised a Cyberhaven developer’s credentials and used them to push a trojanized version of the company’s browser extension. Once deployed, the malicious extension operated as an infostealer, harvesting sensitive data from unsuspecting customers, while simultaneously maintaining outbound communication with command-and-control (C2) infrastructure. This attack not only exploited trusted software distribution channels but also highlighted the growing risks of extension-based compromises.
Protecting Against Malicious Browser Extension Attacks
1. Enforce Extension Allowlisting: Use enterprise device control policies, such as Chrome ADMX templates or Microsoft Edge GPO settings, to allow only approved browser extensions. This helps block unverified or risky add-ons before they're installed. For example, extensions can be controlled through an endpoint management system such as Microsoft Intune, where they can be blocked or whitelisted. Similarly, security teams can use EDR tools to block or whitelist extensions based on their file hash.
2. Monitor and Audit Extensions: Limit the number of installed extensions and perform regular audits to identify unnecessary or potentially dangerous ones. Prioritize minimalism and remove anything not essential to business functions.
3. Validate Developer Reputation and Permissions: Ensure extensions are published by trusted developers. Review their requested permissions carefully, watch for red flags like access to “all URLs,” tabs, cookies, or storage APIs.
4. Use Defensive Tools: Deploy tools like Chrome Extension Defender or ExtShield to detect malicious behavior, such as unexpected data access or suspicious network activity originating from extensions.
5. Maintain Up-to-Date Browsers and Extensions: Regularly update browsers and extensions to patch known vulnerabilities. Enable automatic updates where possible to reduce risk from outdated software.
Chrome Extension File Paths
For forensic investigation or incident response, Chrome browser extensions are stored in:
Windows
C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Default\Extensions
Linux
~/.config/google-chrome/Default/Extensions/
macOS
~/Library/Application Support/Google/Chrome/Default/Extensions/
Conclusion: Combatting Infostealers in the Identity Attack Chain
This identity-centric attack chain underscores a critical shift: defending identity in transit is just as essential as protecting credentials at rest. Techniques like MFA and strong passwords become irrelevant once a session cookies/tokens are hijacked. Modern attacks increasingly target web-based authentication, leveraging stolen session cookies/tokens to bypass even robust access controls.
To counter this, maintaining secure browser configurations is non-negotiable. Keeping browsers patched is a baseline control, as demonstrated by the improvements in Chrome 127, which introduced Application-Bound Encryption (ABE) to limit unauthorized cookie access. Likewise, preventing high-risk behaviors such as enabling Developer Mode, loading unsanctioned extensions, or launching browsers with remote debugging enabled must be enforced through policy and configuration management.
Emerging technologies are also shifting the defense paradigm:
Device Bound Session Credentials (DBSC), introduced as a trial in Chrome 135, bind session credentials to device hardware using cryptographic keys, limiting the ability to replay stolen tokens.
Secure hardened enterprise browsers like island.io go further, enforcing strict memory, process, and file access controls to protect browser resources from exfiltration, even under compromise.
Layered detection strategies are necessary
Even with strong controls, real-world environments are imperfect. Browsers will be misconfigured, and users will be tricked. This makes detection and monitoring for infostealer activity essential. While infostealers vary widely, they share common capabilities, including:
Extracting browser-stored data such as passwords, cookies, autofill entries, and download histories.
Capturing system and user context (e.g., usernames, geolocation, hardware details, and presence of security tools).
Exfiltrating this data to command-and-control (C2) infrastructure.
Serving as loaders for secondary payloads or malware deployment.
Some of these behaviors (e.g., exfiltration to C2) are consistent with broader malware tactics, but others, especially the direct targeting of browser data, require specialized detection strategies. That’s why visibility into browser telemetry, session activity, and anomalous API usage is now a critical part of identity threat detection.
As attackers increasingly pivot from stealing passwords to hijacking active sessions, defenders must evolve in kind. Securing web access is no longer just about authentication, it’s about controlling and monitoring the full browser environment.
This means enforcing the use of hardened enterprise browsers, implementing protections like token binding, and tightly restricting risky features such as remote debugging and developer mode.
Equally important is behavioral monitoring of browser activity to detect session hijacking techniques in real time. These additional network monitoring measures aren’t optional, they form the foundation of a modern, defense-in-depth identity security strategy.
References
Token tactics: How to prevent, detect, and respond to cloud token the
Lurking Threats in Post-Authentication Sessions
Mitre ATT&CK: Credentials from Password Stores: Credentials from Web Browsers
Mitre ATT&CK: Steal Web Session Cookie
Access tokens in the Microsoft identity platform
ID tokens in the Microsoft identity platform
Hands in the Cookie Jar: Dumping Cookies with Chromium’s Remote Debugger Port
Atomic red team: T1539 - Steal Web Session Cookie
Use Alternate Authentication Material: Web Session Cookie
List of Chromium Command Line Switches
Debugging Cookie Dumping Failures with Chromium’s Remote Debugger
Remotely debugging Firefox instances
Pivot to the Clouds: Cookie Theft in 2024
Detecting browser data theft using Windows Event Logs
Device Bound Session Credentials explainer
Behind the Chrome Vault: A Guide to Stealing Cookies
Behind the Chromium Vault: A Guide to Stealing Cookies II
Go BLUE! A Protection Plan for Credentials in Chromium-based Browsers
Cookie-Bite: How Your Digital Crumbs Let Threat Actors Bypass MFA and Maintain Access to Cloud Environments
Cookie stealing: the new perimeter bypass
Hunting Raccoon: The New Masked Bandit on the Block
Big-Game Stealing (Part 2): Defenses for Top Infostealer Techniques
Detection.fyi: Potential Cookies Theft via Browser Debugging
Hijacked Extensions: The Threat of Compromised Browser Add-Ons
Abusing DPAPI
How Infostealers Are Bypassing New Chrome Security Feature to Steal User Session Cookies
Stealers evolve to bypass Google Chrome’s new app-bound encryption
Katz and Mouse Game: MaaS Infostealers Adapt to Patched Chrome Defenses
Demystifying Myth Stealer: A Rust Based InfoStealer
BitM Up! Session Stealing in Seconds Using the Browser-in-the-Middle Technique
The Ultimate Guide to Session Hijacking aka Cookie Hijacking
Rethinking Remote Browser Isolation (RBI)
Island Introduces the World’s First Self-Protecting Browser
Origin trial: Device Bound Session Credentials in Chrome
Infostealers Crash Course: A Tradecraft Tuesday Recap
Huntress 2025 Cyber Threat Report: Proliferating RATs, Evolving Ransomware, and Other Findings
A Detailed Guide to Chrome Remote Debugging
Browser Stored Credentials
Web Browser Stored Credentials
Abusing DPAPI
Introduction to Chrome Browser Extension Security Testing
Manage Microsoft Edge extensions in the enterprise
Microsoft Edge - Policies
Alternative ways to distribute an extension
wtfbins chrome
Beware the Cookie Monster: Cyberhaven Extension Vulnerability Allowed Cookie Theft
Security Vulnerabilities Study in Software Extensions and Plugins
Don’t Ghost the SocGholish: GhostWeaver Backdoor
Katz and Mouse Game: MaaS Infostealers Adapt to Patched Chrome Defenses
How to Blacklist/Whitelist Extensions in Chrome with Intune
Cyberhaven’s preliminary analysis of the recent malicious Chrome extension
Cyberhaven Supply Chain Attack: Exploiting Browser Extensions