Bypassing MFA with Pass-the-Cookie

Bypassing MFA with Pass-the-Cookie

Multi-factor Authentication (MFA) is a great way to increase security on web applications, remote desktop sessions, VPN, and virtually anywhere a user can log into. By introducing one or more additional factors into the authentication process you can prove somebody actually is who they say they are, and prevent a significant amount of impersonation and credential-based attacks. 

However, when adopting and implementing MFA technology it is important to understand exactly what it does and does not do, and what security gaps it leaves unfilled. While MFA is great, it is not a security panacea and it should be looked at as one part of a total security strategy.  

Recently I’ve been spending more time hands-on with MFA technology and wanted to test out ways that MFA could be bypassed by an attacker. One interesting technique I found was using browser cookies to get around MFA with a “pass-the-cookie” attack. In this post, I will explore this attack, how it works, and what you can do to best protect yourself.

Browser Cookies

I won’t go into the basics of browser cookies, as my colleague Nathan Sorrentino has recently done so with his blog post here. For the purposes of this research, the important thing to know is that browser cookies are a way that web applications can store user authentication information. This is so a website can keep you signed in and not constantly prompt you for your username and password every time you click on a new page. 

Now, what happens if those authentication cookies fall into the wrong hands?

Pass-the-Cookie

The concept of a pass-the-cookie attack is much like pass-the-hash or pass-the-ticket in an Active Directory domain. Basically, if you put MFA on top of your web applications the user logging in will be prompted to provide additional proof that they are who they say they are, such as accepting a push notification on their mobile device. Once they have passed all of those tests, they are allowed into the app.  At that point, a browser cookie is created and stored for that user’s session. 

This is similar to how Kerberos or NTLM would work, where after the authentication process is done, an artifact is stored locally on the user’s system. This is then used for future authentications so the user doesn’t constantly get prompted for their username and password.

If somebody were able to extract the right browser cookies they could authenticate as another user in a totally separate browser session on another system, bypassing all MFA checkpoints along the way. This is identical to how a user could “pass” the NTLM hash or Kerberos ticket if they extracted that from a user’s computer. 

Extracting the Cookies

For this test, I focused on the Google Chrome browser. Chrome stores its cookies in the following location in a SQLite database:

%localappdata%\Google\Chrome\User Data\Default\Cookies

The challenging part is that those cookies are encrypted for the user via the Microsoft Data Protection API (DPAPI). This is encrypted using cryptographic keys tied to the user the cookies belong to. I won’t go too far into DPAPI in this post but that topic has been covered in great detail by people who understand it much better than me (here is a good presentation by Paula Januszkiewicz from Black Hat Europe 2017 – DPAPI and DPAPI-NG: Decryption Toolkit).

So we need a way to get access to the Cookies database and to decrypt this information into plain text. 

Luckily Benjamin Delpy has done some impressive research into this area and incorporated it into Mimikatz. Also, harmj0y has written a very informative post on this subject which I used during my research. 

With Mimikatz in hand, I am able to extract a user’s cookies even though they are encrypted with this command:

dpapi::chrome /in:"%localappdata%\Google\Chrome\User Data\Default\Cookies" /unprotect

And as a side note, if you are looking for a way to run this from the command line I found this command to be useful (which I found here):

mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit

You can see running this produces the browser cookies which I can now copy offline to use wherever I please.

So now we understand the basics of a pass-the-cookie attack. Let’s take a step-by-step walkthrough and look at how this could be done in a real-world scenario.

Pass-the-Cookie Attack Scenario

In this scenario, we have a user (Tobias) who is an IT Administrator. Tobias uses MFA to protect everything he does including his web applications. One web application Tobias uses regularly is the Microsoft Azure Portal where he has some administrative duties managing his company’s Azure instance. 

You can see when Tobias logs into Azure he has to provide a second factor which is a code from the authenticator app on his mobile device. As long as nobody steals his iPhone Tobias and his Azure credentials should be safe!

Not so fast. Let’s imagine Tobias has clicked on a phishing email or his system has been compromised by some other means, and now an attacker is able to execute code within Tobias’s user context. Tobias is NOT an administrator on his laptop so the damage should be contained, right? 

Let’s see.

Extracting the Cookies

We saw just how easy this is earlier. All the attacker has to do is execute this command when running as Tobias:

mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit

It’s also worth noting if the attacker could not run as Tobias, but only as another user or computer context on the system, they could still perform this attack which is covered in more detail by Harmj0y in his post

Now you can dump all the cookies, but so what? There are a lot of cookies, which ones matter and what do you do with them? 

In researching, I came across this presentation on Pass-the-Cookie by Johann Rehberger which provides good insight into valuable cookies to target. 

For Azure, we care about the authentication cookies including ESTSAUTH, ESTSAUTHPERSISTENT, and ESTSAUTHLIGHT. You can see those are there for the taking on Tobias’s machine because he has been active on Azure lately:

Passing the Cookies

Now that we have the cookies we just need to pass them into another session to take over Tobias’s account. This is easy enough to do with Chrome and there’s nothing fancy required. I just opened a Chrome application in this case on my Kali Linux server and used the “Inspect” interface to add new browser cookies.

Currently, the attacker doesn’t know Tobias’s email or password, and also doesn’t have access to his mobile device so he would normally have no chance of logging into web apps like Azure.

But by inserting a cookie I will be able to get right in as Tobias. First, I inspect the session:

Next, I navigate to Application > Cookies and you will see the current cookies which do not include the ESTSAUTH or ESTSAUTHPERSISTENT.

I am going to add the ESTSAUTH but if available ESTSAUTHPERSISTENT is preferred which is generated by the “Stay Signed In” option.

Once added you can refresh the page and now you have logged into Azure as Tobias.  No MFA required.

You can see just how easy it is to perform a pass-the-cookie attack. Let’s take a look at some of the risks associated with this particular threat.

Mitigating Your Risk

I find pass-the-cookie to be particularly concerning for a few reasons. First, it does not require administrative rights. All users have access to read and decrypt their own browser cookies, regardless of whether they have privileged rights on their workstations.  

Second, the attacker doesn’t have to know the compromised account password or even the email address for this to work. This makes this attack very easy to do with minimal information. I was also able to successfully get this working after the browser had been closed. 

To prevent these types of attacks more stringent policies can be put in place for when cookies are cleared, but this needs to be balanced with driving people crazy with constantly re-authenticating each time they navigate to a site. People will just never close their browsers if they lose all their cookies each time they do. Strong authentication monitoring and behavior-based threat detection products are a very strong fit for detecting and minimizing the risk of these attacks. You can check out StealthDEFEND which can be used for detecting when accounts have been compromised and are being used in unexpected and potentially malicious ways.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Start a Free Stealthbits Trial!

No risk. No obligation.