Cookies; not just a scrumptious snack. How Pass-the-Cookie attacks can bypass your MFA

Multi-factor authentication (MFA) is a critical component in our defensive strategy, but isn’t a silver bullet in cyber security. Whilst it reduces the risk of unauthorised access, attackers continue to evolve their strategies to bypass it. One such method is known as “Pass-the-Cookie” attack.

In this post, we dive deeper into the methodology, showcasing how easy MFA is to bypass by looking at a real-world example – and share some recommendations on improving your cyber security posture.

To start, a simple question. Can you tell the difference between these two sign-ins for Office365? See the screenshots from the Azure sign-in logs below.

With the information provided, the answer is likely no. What if we added some more context around the authentication itself?

Still nothing? We can see that multi-factor wasn’t explicitly used this time (Authentication method = “Previously satisfied”), showing that MFA had been used previously. Is there anything else strange if we were to look at the device information?

We start to see different browsers and operating systems. Just from these logs, it still just looks like a regular sign-in?

For context, both above sign-ins were me, but I’ll detail the different methods I used to authenticate.

‘Sign-in #1’

• • This involved me previously inputting my username & password, along with Microsoft Authenticator push notification with a confirmation number. Then just opening a new browser window and browsing to the website.

‘Sign-in #2’

• • This involved no usernames, password or multi-factor. In fact, it wasn’t even on the same corporate device. All that was used was a stolen cookie.

Stealing credentials is nothing new?

Absolutely true. With the use of remote working, allowing users to sign into apps from personal devices and the use of more single sign on apps – we are seeing Pass-the-Cookie attacks on the rise.

Previously, we used to see tools such as Mimikatz used to interrogate LSASS (Windows credential storage system) – allowing us to retrieve information such as usernames and passwords:

We still see Mimikatz being used by attackers, but the adoption of MFA across multiple services has meant that attackers need to change their approach. In the balance of security versus convenience, we are seeing more security information being stored in our cookies – making these an attractive alternative target for the attackers.  As an MSSP, we are seeing this attack methodology on the rise across multiple client verticals, with our Security Operations Centre detecting and responding to numerous cases.

So, about those cookies – they aren’t just a scrumptious snack?

When you log into a website or application, cookies are there to maintain your sessions so you don’t have to keep re-entering credentials on every page you visit. Whilst this helps with productivity, they are also targeted by attackers who are attempting to hijack our sessions.

What do we mean when we say “hijack our sessions” though? Well, an attacker wants to trick their browser into pretending that you’ve already logged in once, so you don’t need to have to log in again. This allows them to act as you – allowing them to access anything that you would have access to.

Here, we are logging into office.com via the normal https://login.microsoftonline.com method.

In our example, we are using Windows 11, Chrome. When we browse to this page for the first time, we are prompted with a login screen. If we open developer tools, we can look at the current cookies that are there for this site.

After we complete our sign in process, we are logged in securely and can access our resources – but we also have some additional cookies.

What we are really interested in, is something called “ESTSAUTH”

Using the definition from Microsoft: (https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-web-browser-cookies)

This cookie allows us to remain logged in across multiple services, usually without being forced to re-authenticate every time.

So, if we can see this value – what would happen if this was stolen? In our example, it’s as easy as just copying the value from the browser. In the real world, attackers use a variety of different tools to emulate this function, but the result is the same – a key & value for ESTSAUTH.

Infostealers such as LummaC2, Redline or Racoon are commonly used by attackers – LummaC2 being the more common infostealer recently. LummaC2 is often disguised as fake software updates, or included in phishing emails with deceptive links – encouraging users to install the software, ready for it to steal their sensitive data.  

In our example, how would we re-use this cookie?

To demonstrate, we will open our clean machine. For this, we are running Ubuntu & Firefox – opening our browser and navigating to the “https://login.microsoftonline.com” URL.

After being presenting with our login page – we can look to bypass this. In our browser, we can use developer tools to create a new cookie with our stolen value. Depending on the browser used, we can create this cookie via a console command or simply right clicking in the storage section.

After entering this value, all we need to do is refresh our page.

We are now signed in, with the same user permissions as the previous session. We’ve entered no username, password or multi-factor.

How do we defend against this?

The answer is twofold – detective and preventative controls.

When we work with our clients, we explain this approach and the difference in the controls:

Detective controls:

Identifying activity that has either already occurred, or in the process of occurring. Allows us to spot unusual activity and alerts us to investigate further. Things like ‘Impossible travel’ are a detective control, allowing alerts to trigger when a user logs in from two places where it would have been impossible to physically travel to those two places within that time period.

Preventative controls:

Stopping the activity from occurring in the first place, usually by implementing a configuration or software change. Passwords, multi-factor and user awareness are all forms of preventative controls – acting as barriers for attackers to have to break down or bypass.

But what specifically can we do around Pass-the-Cookie?

This is a small selection of controls that could be implemented to help assist in an attack vector such as Pass-the-Cookie. Our preventative controls listed above are the foundation for stopping the event from happening – but they aren’t infallible. We use detective controls to react as quickly as possible to an initial access if our preventative controls have failed.

Multi-factor authentication (MFA) is essential for safeguarding user accounts. Implementing MFA as a preventative control makes it much more challenging for attackers to steal credentials and gain unauthorised access. However, MFA alone isn’t sufficient. Just as we avoid relying solely on usernames and passwords, we must build multiple layers of defence. This approach helps us detect and respond appropriately if any control fails.

Alongside robust security configurations – such as MFA, conditional access, administrator restrictions, and geo-IP blocking – we must emphasise user awareness in cyber security. As a security team, fostering a security-conscious culture empowers users to recognise phishing attempts, drive-by downloads, and fake browser updates on both corporate and personal devices.

For more information on how we use threat intelligence & dark web monitoring to proactively detect your corporate information on infected personal devices, or to discuss strategies for building a cyber security culture in your organisation, please get in touch.