Cookie O’clock

Introduction

Over the past few years, the awareness of privacy and personal security has taken a significant step forward. Typical users have now adopted far more suspicious practices when utilizing multiple PC or mobile device applications. This is a direct result of the constant attempts of cybercriminals to launch malicious campaigns aimed at gaining access to both credentials and internal systems.

Users are suspicious when surfing the web; an average user is usually cautious about clicking on ads, disclosing personal information via unknown forms, avoiding clicking on suspicious links, and in general, is significantly more aware of threats.

For the non-technical user, the traditional way to access an internal system or platform is by providing valid credentials – and you are in. However, behind the scenes a unique authentication process on the local host takes place, offering the user a seamless experience on the website when the session is valid.

One of the major threats is the disclosure of credentials. If a threat actor gains access to credentials, he might use them to access sensitive information and the system. To mitigate this kind of threat, Multi-Factor Authentication was invented. However, it can be bypassed by a small piece of information stored on the local computer − the Cookie.

Cookies’ Usage, Benefits and Types

Once a user interacts with a website or service, the website/service requests to save information on the user’s behavior. All this information is stored in multiple cookies – text records, which are stored in the local host and will assist the server the next time this user visits the website. HTTP cookies (AKA internet cookies) track and monitor the sites you visit and the items you click on these pages. Cookies are also used to identify your computer when you connect to a computer network and to improve your web browsing experience.

Eventually, the server creates the data stored in a cookie when you connect. This information is labeled with an ID unique to you and your computer.

To clear things up, we will focus on three types of cookie:

All the above mentioned flags are crucial. Any misconfiguration on the server side could lead to a scenario where a stolen cookie can be maliciously used or manipulated.

The multiple CWEs (common weakness enumerations) below are related to cookie vulnerabilities:

• CWE-1004: Sensitive Cookie Without ‘HTTPOnly’ Flag
• CWE-539: Use of Persistent Cookies Containing Sensitive Information
• CWE-1275: Sensitive Cookie with Improper SameSite Attribute
• CWE-315: Cleartext Storage of Sensitive Information in a Cookie

With this knowledge in hand, we can move forward to understand the interest of stealers extracting this kind of data. As you may assume, some of the values of the cookies may contain sensitive data and tokens. In the next section we will see the difference between both of them, and later on, we will demonstrate how a threat actor can use this value to gain profit.

Service Authorization – Cookies vs Tokens

Access control is one of the most challenging topics for security in websites and web applications. The implementation mainly depends on how you store the data to be authenticated. Cookies and tokens are two standard methods for establishing authentication.

As we saw in the previous section, Cookies are multiple data chunks created by the server and sent to the client (i.e., browser) for communication. Tokens, usually JSON Web Tokens (JWTs), are signed credentials encoded into a long string of characters generated by the server. The primary distinction between cookies and tokens is that tokens are stateless, whereas cookies are stateful. The most significant difference between stateful and stateless is that stateless does not “save” data, whereas stateful does.

This is important since HTTP is a stateless protocol, meaning a user must authenticate on each request.  Each token saved on the computer will be used for a specific timeframe and after that, it will be invalid for use.

Multi-Factor Authentication

Until half a decade ago, a significant proportion of the services demanded solely valid credentials, which would be sufficient for accessing the system. As the attacks continued developing and the usage of services became extensive, a new authentication process emerged – the Multi-Factor Authentication (MFA).

MFA is an authentication method that requires the user to provide two or more verification factors to gain access to a resource such as an application, an online account, or a VPN. MFA requires one or more additional verification factors, rather than just a username and password, which reduces the likelihood of a successful attack. However, in some of the services, a cookie is stored with the session value after a successful MFA login process, and if this cookie gets into the wrong hands, the damage can be severe.

Essential for Stealers and Marketplaces

In the past year, Cyberint released multiple reports on the most prominent stealers that have emerged in the ecosystem and are currently active. Most stealers extract various files from an infected host, one of which is the cookies file, and we can now understand the importance of that file. In addition to the credentials file, the cookies file may be relentlessly valuable and contain sensitive data. It is a quick win for the threat actor to impersonate a user and bypass multiple authentication methods.

Besides the malware logs, cookies and active sessions are also up for sale in Darknet marketplaces. A threat actor can offer their “goods” for $5-10 after reviewing what services are available.

Another method used by more engaged threat actors is to offer access to specific services in a dedicated Darknet forum, which other forum members will find valuable.

Sensitive Cookies

Some cookies are more sensitive than others, which doesn’t mean they’re being stored more securely. There session cookies do not have an expiration date, such as MSISAuth. Cookies without expiration date are destroyed once the browser is closed.

However, this is not the case when examining other sensitive cookies. If you approve the “Stay Logged In” question after the MFA process in Microsoft Azure, you will get a cookie that authenticates you immediately, without any additional security measures.

We will examine the ESTSAUTH, ESTSAUTHPERSISTENT, and ESTSAUTHLIGHT authentication cookies and see how we can use them to bypass MFA.

Below is a list of sensitive cookies that may assist in MFA bypass:

Demonstration – Pass The Cookie

In the following demonstration, we will show how cookie injection can be performed and gain access to sensitive environments.

First, we should log into the account of John Doe. John’s company has a policy that enforces MFA validation in order to access internal systems, therefore, he should pass both valid credentials and MFA to create the relevant cookies that will be stored on his local host.

We will start with providing valid credentials:

Second, we will pass the MFA validation to gain access and generate valid session cookies:

Now we are logged in as a valid employee, we can see that we have the environment ready and can access files and directories:

And now, John’s cookies are stored on his personal/work computer, As presented in Figure 10:

Now the interesting part comes in.

The threat actor recently grabbed John’s cookies from a Darknet forum, a marketplace, or a malware log that was shared in a Telegram channel. The threat actor will open a new browser that does not contain any cookies, especially not John’s, and will start the authentication process by entering login.microsoftonline.com.

After entering the email address, the “Enter Password” screen will appear, just before entering the MFA authentication process. Let’s assume that the threat actor does not have the password nor MFA validation (i.e., authenticator, phone number etc.), which leaves the threat actor out of the account.

The next step is to inject or manipulate the missing cookies that are needed to perform the bypass. Since the threat actor is accessing the login page for the first time, none of the ESTS cookies exists on this specific webpage. So, we will use Chrome’s feature that lets a user create and alter cookies and will start injecting them into the webpage:

After injecting the ESTS cookies and refreshing the browser, the threat actor gained access into John’s account without having the password nor passing MFA authentication! now the threat actor can access any platform that uses the ESTS authentication cookies with the current user privileges, for example, Azure portal:

Below is a demonstration that captures the entire process from the victim authenticating on his local machine, to the threat actor using the stolen cookies to bypass the MFA:

Conclusions

As shown above, cookies are much more than a piece of text used by the browser or any other service. While creating the cookie to be served to the client, the developer must be extra careful while configuring the flags and the data carried in the cookie’s value.

In the last three months, Cyberint detected and collected tens of thousands of sensitive cookies from multiple unique sources. Alongside the cookies file there is additional information about the infected host and the login pages, which also assist to identify the vulnerable company, those companies are in constant risk if no action is taken.

Authentication cookies can be purchased by threat actors online, and quite easily. Threat actors often offer valuable sensitive cookies as an access vector to an organization. The price ranges between several dollars to thousands of dollars, and could even be higher.

One stolen cookie could lead to extensive compromise and data theft, and in the worst scenarios, even initial access for ransomware groups. We have already seen multiple groups utilizing cookies to gain access and cause major damage.