Do you like cookies? Everyone loves especially attackers and especially cloud-related cookies. If you have got multi-factor authentication (MFA) enabled on your account or are even passwordless in some situations, you can’t be compromised, correct? Think again. Well, not exactly. The cookie can be crumbled easily. 
Security issues, misconfiguration, security gaps, weaknesses, vulnerabilities, attack surfaces, adversaries, defensive tactics, strategy, prevention mode, incident analysis, and more are the day-to-day life for everyone who’s in the cloud security. Cloud computing loves Cookies.😜
In cloud and hybrid environments, there are many types of attacks. The old attacks alongside the new attacks. You can often see old attacks that get a different wrapping and are resurrected in front of the cloud environments—the Pass-the-Cookie attack.
Attackers take advantage of situations where old attack methods can be reused in front of the cloud to get fast results and strong persistence. As technology advances, so do the attackers.
Phishing attacks have become more sophisticated, and attackers are finding ways to bypass MFA. The reason why is because of the delicious cookies stored in your browser. For example, session cookies are a way to show the cloud that the user has already authenticated. This includes passing the strong authentication challenge. 

How the Cookie Crumbles

The cookie can be crumbled in any situation and in front of any server or cloud component. The cookie attack can be made by the different attack and vector implementations, sometimes without any detection or prevention by the security controls.

Cookie Introduction

Before we get into the pass the cookie, let’s do a quick overview about the cookie.
A cookie is a small piece of data that a cloud component or server sends to a user’s web browser. The browser may store the cookie and send it back to the same cloud component or server with later requests. Typically, the cookie indicates if two requests come from the same browser, which keeps a user logged in. For example, it will remember the stateful information for the stateless HTTP protocol.
Cookies are mainly used for three purposes:

• Session management – Logins, strong auth, shopping carts, game scores, or anything else the server should remember
• Personalization – User preferences, themes, and other settings
• Tracking – Recording and analyzing user behavior

Cookies are sent with every request so that they can affect performance. Once cookies are used for general client-side storage, it allows storing data on the client, including modern storage APIs currently recommended in many platforms. Modern APIs for client storage are the Web Storage API and can be used for localStorage and sessionStorage with local DB.
Adversaries can access cloud environments without knowing a user cred or even strong authentication from a multi-factor system using Pass-the-cookie techniques. If the cloud environment in question is the management console for your Azure, Office 365, AWS, Google, GitHub, or any other cloud environment, they could have the keys to your kingdom.

Types of Cookie

There are three primary types of cookies:

• Session cookies are specific to a particular visit and carry information as you view different pages, so you don’t have to re-enter information every time you change pages. Session cookies expire and delete themselves automatically in a short period, like after you leave the Site or when you close your web browser.
• Persistent cookies remember certain information about your preferences for viewing the site and allow us to recognize you each time you return. Persistent cookies are stored on your browser cache or mobile device until you choose to delete them, and otherwise typically delete themselves at expiration.
• Third-party cookies are placed by someone other and may gather browsing activity across multiple websites and multiple sessions. They are usually persistent cookies and are stored until you delete them or expire based on the period set in each third-party cookie.

Cookie-Based Authentication

Cookie-based authentication has been the default and the method for handling user authentication for a long time.
As I mentioned, cookie-based authentication is stateful. This means that an authentication record or session must be kept both cloud component or server and the client-side. The cloud component or server needs to keep track of active sessions in a database, while on the front-end, a cookie is created that holds a session identifier, thus the name cookie-based authentication.
Let’s take a look at the basic flow for cookie-based authentication:

1. The user enters their login credentials and using strong authentication
2. The server verifies the credentials are correct and creates a session which is then stored in a database
3. A cookie with the session ID is placed in the user’s browser (with all cookie attributes)
4. The session ID is verified against the database on subsequent requests, and if valid, the request is processed
5. Once a user logs out of the app, the session is destroyed both client-side and server-side

Pass-The-Cookie 

A pass-the-cookie attack occurs when a malicious user gets a copy of a valid cookie and then injects it into their session while interacting with the target cloud app. The cookie could be stolen through some attack vectors, including a simple extraction, or the old scenario with man-in-the-middle-attack (MITM) by intercepting the traffic between the user and the cloud app or monitoring network traffic if the cloud app does not follow secure design principles.
The cookie could also be stolen from the local browser cache or the memory of running processes by malware that has been installed onto the target user’s computer.
Assume the cookie obtained in a session cookie. In that case, the attacker can inject that into their session while accessing the cloud app using the developer tools built into their web browser.  In this scenario, the cloud app will trust the session cookie and grant the attacker all the rights and access of the user who initially logged in to create the session. This access will persist for as long as the session cookies are configured to remain valid as defined by the cloud app.
The migration to cloud-based environments means that targets valuable to adversaries such as file and database servers are no longer present many organizations’ leading networks. As a result, attackers who have infiltrated a network prioritize the search for session cookies that grant access to cloud environment management consoles—capturing the session cookie for a user with administrator access to the Azure, AWS, Office 365, Google, and any other cloud platform.
A management console potentially gives the attackers complete control over the whole cloud environment. The attackers could then grant themselves persistent access, install ransomware on any device, or even shut down servers and lockout the organization’s access to the cloud.
An adversary can pivot from a compromised host to the cloud app by stealing authentication cookies from browsers and related processes. At the same time, this technique bypasses most multi-factor authentication protocols, including other strong authentication like passwordless and biometric devices.
This can be because the authentication token that the attacker steals is issued after all valid factors. Many users persist in a valid cookie for an extended period, even if the web application is not actively used. Cookies can be found on disk and also in process memory. Additionally, other applications on the targets machine might store sensitive authentication tokens in memory, for example, apps that authenticate to cloud services. This pivoting technique can be extended to bearer tokens, JWT, and the likes.
ℹ️ Pass-the-Cookie is a post-exploitation technique to perform session hijacking.

Bring on the Session

A cookie isn’t alone, and it’s working with many other components, for example, Token. Sometimes, there is a direct relation, and sometimes, it’s in direct relation. Let’s do a quick explanation about the relation with other components.
ℹ️ The following components aren’t a mandate to carry out the path of the cookie attack.

Session Cookie

Cookies are small amounts of data stored in a web browser’s cache and repeated back to the same website that created them. Each browser maintains its independent cookie storage database, so cookies saved from a site accessed using a specific browser are not visible to other browsers. One of the things achieved by opening a Private Browsing / Incognito window in a browser is provided with a new, empty, temporary cookie database. However, the private mode behavior of each browser differs slightly.
A session cookie is simply a cookie storing information used by the cloud environments to manage the current user’s session. It is stored in the central cookie database of the web browser with all the others. When session cookies are generated by the cloud environments after a user has logged in successfully, this means a session cookie confirms that the user, password, and strong authentication are valid.
Once a cloud environment receives a request from a browser, a copy of the session cookie is included. The cloud environment validates the session cookie and uses it to authenticate and authorize the request. Sending the session cookie is more secure and comfortable than repeatedly sending the user cred of the current user. The session cookie should be designed with a time-limited life of hours and less, depending on the nature of the cloud environments. However, while the session cookie is still valid, it is a master key providing access to the cloud environments for anyone to steal a copy of the cookie.
The two key factors to remember about session cookies are:

• The session cookie is generated after any strong authentication has taken place and stored locally as a cookie
• The cloud environment accepts the cookie as proof of authentication without the need to know or provide user creds

Session cookies can be protected by ensuring they are not left on endpoint systems any longer than necessary.  A session cookie should be deleted automatically by the browser when the user logs out of the cloud environments – this is why it is best practice to always log out of cloud environments and not simply shut the browser tab or leave it idle in the background. Session cookies might delete when the user shuts down the web browser, depending on the configuration settings for the browser. However, it is not as reliable as logging out of the cloud environments to clear any session cookies.
ℹ️ Azure AD Identity Protection provides a dedicated identification for a session, cookie, and token anomalous and sessions mitigation for this scenario.
Cookies are a way to show the server that the user has already authenticated. This includes passing the 2FA challenge. Once the cookie has expired, you will be asked to re-authenticate, and it depends on the app, but sometimes you could have more substantial restrictions than others. These include:

• Session Proxy
• A single-use cookie
• Restricted by fingerprint.
• Cookie validation

This isn’t the case for all, though, and this is what attackers are exploiting. Services like Office 365, AWS, Google, and other platforms allow the cookie to be reused. The attacker needs a way of extracting them. The extraction can be done via PowerShell, Python, or manually with any tools.

Token and Cookie Relation

The world of tokens and cookies is not the same auth method but meets in many places in the cloud and sometimes with some relation.
Tokens are pieces of data that provide enough information to facilitate determining a user’s authorization to act. Tokens are artifacts that allow the app to perform the authorization and authentication process. There are common identity frameworks and protocols that use token-based strategies to secure access to applications and resources. That takes us to the id token.
An ID token is an artifact that a client app can use to use the identity of a user. For example, the ID token can contain the name, email, and event user profile picture. A client app can use the ID token to build a user profile to personalize the user experience.
An authentication server that conforms to the OIDC protocol to implement the authentication process issues its clients an ID token whenever a user logs in. The consumers of ID tokens are mainly client applications such as Single-Page Applications.
Once a user logins, the authorization component issues an access token, an artifact that client applications can use to make secure calls to an API. When a client app needs to access protected resources on a cloud environment on behalf of a user, the access token lets the client signal to the server that it has received authorization to perform specific tasks or access certain resources.
Then we’ve got the Refresh Token. A refresh token is a credential artifact that lets a client app get new access tokens without asking the user to log in again. A client app can get a new access token if the refresh token is valid and unexpired. Consequently, a refresh token with a very long lifespan could theoretically give infinite power to the token bearer to get a new access token to access protected resources anytime.
However, you may not need refresh tokens. There are scenarios where you can still get an access token without interrupting the user and without relying on the almighty power of the refresh token. Additional examples to keep a session going can be cookies or silent authentication.
There is a relation between TOKEN and Cookie. Still, there is a different identification method, especially when it comes to identification with the cloud.
This diagram is a great introduction and simplified overview of the difference between a cookie and token approach to authentication.

Embrace the RED

The Good, the Bad, and the Chain. Like any other attack scenario, the pass the cookie attack is based on a familiar Cyber Kill Chain framework.

Attack Chain

Pass the Cookie scenario can be partially based on the following steps:

1. Acquire the cookie from the victim’s browser or other processes
2. Exfiltrate the necessary authentication cookies
3. Open browser on the attacker’s machine or any other machine
4. Navigate to the resource to access – make sure to valid cookie domain
5. Use the Developer Console and set the cookie via document – use the Key and Value
6. Refresh the page and observe being logged in as the victim

The bad news is that sometimes browsers use the Win32 DPAPI with CryptProtectData and CryptUnprotectData to protect login passwords. This can make it somewhat annoying to decrypt these passwords since any tooling you’re using needs to consume the Win32 API. That means you’re probably looking at PowerShell, C, C#, or Rust which supports the Win32 API, and you’re most likely not going to perform this attack offline on a Linux host.

The good news is that you may need access to the DPAPI to perform this attack in some scenarios. If you can steal the specific files and the DPAPI keys, you can drop those onto a different Windows host and use its DPAPI functionality. However, you do not need to use the DPAPI on the host you’re stealing the passwords from.

Theft Tools

The scenario above can be done via the following tools that can extract the cookie seamlessly:

• PowerShell to dump passwords and cookies
• Python to dump passwords and cookies
• Mimikatz to dump passwords and cookies
• Rust to dump passwords and cookies
• Browser extensions
• Third-Party tools (MSI, EXE)
• firefox_creds – (Lite DB)
• cookie_crimes – (Windows and Linux)
• Evilginx2

ℹ️ PowerShell can extract the cookie without any detection – in most cases scenario.
Evilginx2 Mode
You can take the pass the cookie attack one step ahead with the evilginx2 tool. evilginx2 is a man-in-the-middle attack framework used for phishing login credentials and session cookies, bypassing MFA protection.
This tool is a successor to Evilginx, released in 2017, which used a custom version of the Nginx HTTP server to provide man-in-the-middle functionality to act as a proxy between a browser and phished website. The present version is entirely written in GO as a standalone application, implementing its HTTP and DNS server, making it extremely easy to set up and use.

Pass the Cookie on Office 365

Cloud providers give us a set of identity security with controls such as MFA, Passwordless, hardware token, and many others. In some way, it looks very promising, but there is a big difference between theory and the field, and the cookie is one of the old-new attacks that bypass any authentication.
The Pass-the-Cookie (PTC) isn’t new at all (even very old), but the technique in the cloud has revived it and places this attack as a high-risk factor for bypassing the identity layer. The bypassing will occur in any situation from MFA to hardware token (FIDO).

ℹ️ Hardware token and FIDO can bypass in some situation
How does the bypass look at Office 365? simple as you think about it. You log on to Office 365 with any user, then take the cookie value to other devices, and from there, you can log in to the same user without the need to know the UPN or password or any creds.
ℹ️ The RED side. In the field, attackers can pull out the cookie value from many tools, from PowerShell to some extension on the browser. The big issue is on the detection side – most security controls cannot identify this attack.
Let’s go and take the cookie from one browser and move it to other browsers.
First, we need to log in to Office 365 with some users (admin or standard). In this example, it is login.microsoft.com, but the URL https://myaccount.microsoft.com/?ref=MeControl can be a good one.
ℹ️ There are favorite URLs that we can pull out the cookie with the value name and value – ESTSAUTH.


We need MFA, no? 👇


Once we’re logged on, we can go to Developer tools > Application > Cookies > open the relevant website (login) and take the ESTSAUTH value with the value itself.
ℹ️ If the ESTSAUTH is missing, refresh the page again, and the value will appear.

ℹ️ Make sure to take the cookie value with all the characters as is. Else it won’t work.

Now. Let’s go to another device or browser and paste the cookie value with the ESTSAUTH name and value.
ℹ️ PowerShell can do this extraction with minimum actions

YEP. We’re now logged on without knowing the user creds and without strong authentication. 💪

Blue Teamers Side

As with any attack, we need to contain the attack (incident), so we need to know the artifacts, cookie values, storage paths, monitoring such activity, options in the various clouds, and more.
Let’s start from the blue side of the defenders.

Pass The Cookie – Cheat Sheet

Cookie Local Artifacts

All the cookies are stored in a single file called cookies, and each browser contains the user profile location.

Edge

%USERPROFILE%\AppData\Local\Microsoft\Edge\User Data\Default

Chrome

%USERPROFILE%\appdata\local\google\chrome\user data\PROFILE\Login Data
%USERPROFILE%\appdata\local\google\chrome\user data\PROFILE\Cookies

Firefox

%USERPROFILE%\\AppData\Roaming\Mozilla\Firefox\Profiles

Brave

%USERPROFILE%\appdata\local\BraveSoftware\Brave-Browser\user data\PROFILE\Login Data
%USERPROFILE%\appdata\local\BraveSoftware\Brave-Browser\user data\PROFILE\Cookies

Opera

%USERPROFILE%\appdata\roaming\Opera Software\Opera Stable\Login Data
%USERPROFILE%\appdata\local\Opera Software\Opera Stable\Cookies

Detections

When it comes to detections, we’ve got a few things that we can do with cookie detection:

• Monitor on the client-side for applications that perform process dumps on browser processes or others
• Monitor for unusual activity on critical web assets when possible
• Monitor for login anomalies or token anomalies when possible
• Leverage features that cloud providers and web apps provide with threat detection, and access logs
• Do authorized adversarial emulation to test token detections
• Monitor cookie stored location on the endpoint with Sysmon or EDR (or both)
• Use Azure AD Identity Protection Sign-in risk policy to mitigate automatically
• Use Azure Sentinel playbook with AADP integration to mitigate automatically

Azure AD Identity Protection

In many security tests I have done with different IDPs (Azure AD, OKTA, OneLogin) along with various security tools that work against the identity layer, I have found that many security tools (including the IDPs) do not detect the anomaly action except the Azure AD Identity Protection which detects an anomalous token. 💪
Azure AD Identity Protection anomalous token detection is now available in Azure AD Identity Protection (SEP 21). Some highlight from:

• Anomalous Token Offline This detection indicates abnormal attributes in the token, such as an unusual token lifetime or a token played from an unfamiliar location. This feature can detect abnormal characteristics in the token, such as time active and authentication from an unfamiliar IP address. This detection covers Session Tokens and Refresh Tokens More from the AADP website.
• Token Issuer Anomaly Offline This risk detection indicates the SAML token issuer for the associated SAML token is potentially compromised. The claims included in the token are unusual or match known attacker patterns.
• Unfamiliar sign-in properties can be detected on both interactive and non-interactive sign-ins. This detection is detected on non-interactive sign-ins. It deserves increased scrutiny due to the risk of token replay attacks.

Once Azure AD Identity Protection detects the cookie and token issue, it categorizes this attack as a Sign-in Activity.


ℹ️ We can mitigate this attack automatically with the built-in policy for risk policy.

Azure Sentinel

Azure Sentinel, my favorite security tool in any given situation, offers many possibilities due to its integration with Azure AD Identity Protection. Once an incident is raised, it allows us to analyze and investigate the incident from all known angles, from the interface, entities, investigation, and explore options to performing various queries.


Note: Azure Sentinel query for Cookie attack will be available soon 

Microsoft Defender for Endpoint

Will be available soon

Mitigating

To avoid pass-the-cookie attacks being used to pivot to cloud infrastructures, good security hygiene is needed by the cloud administrators, including:

• Access Cloud admin consoles using Incognito mode to reduce persistent cookie storage on desktop systems.
• Explicitly log off from Cloud admin consoles as soon as a task is completed and close the browser application, ultimately forcing the deletion of session cookies.
• Regularly monitor user access logs for the cloud environment to identify unusual access patterns.
• Create multiple user accounts with different access permissions based on the least privilege principle – this can limit the utility and value of the stolen session cookie.
• Use additional meta-data to invalidate the session, such as unexpected source IP or time of day of access. In this scenario, a stolen session cookie would not be considered valid by the web application if the source IP address it is sent from changes during the session’s life, as this could indicate the cookie has moved from a legitimate user onto the system of an attacker.
• Require Client-Side certificates. Client-side certificates make pass-the-cookie attacks more challenging as the attacker would need to obtain a copy of the certificate and the session cookie.
• Reducing the lifetime of session cookies, so they expire more quickly, thereby reducing the window of opportunity to steal and make use of them.
• Regularly delete persistent cookies, so they get removed from the hard drive to limit exposure.
• Browse sensitive sites (high-value assets) from isolated or dedicated machines
• Requiring further authentication proof for sensitive operations can help determine the damage.
• Requiring client-side certificates makes it also more challenging to pass the cookie.
• Use Azure AD Conditional Access Session Proxy to minimize token lifetime

Incident Response Side

Will be available soon – plan, contain, and mitigate this attack by IR framework.

Threat Intelligence Side

Will be available soon – Make your own TI from this attack

References

Steal Web Session Cookie, Technique T1539 – Enterprise | MITRE ATT&CK®
Strengthening Security Configurations to Defend Against Attackers Targeting Cloud Services | CISA
Bypassing MFA with Evilginx2
What is a risk? Azure AD Identity Protection | Microsoft Docs
WSTG – Latest | OWASP
Description of Cookies (microsoft.com)
Configure session behavior – Azure Active Directory B2C | Microsoft Docs
Security Archives – Elli Shlomo (eshlomo.us)