Token Theft Part 1 - Offensive

Token Theft Part 1 - Offensive


Over recent years, in response to an increasing number of cyber-attacks, more and more organizations have increased their coverage of multi-factor authentication (MFA). As a consequence, threat actors started to implement more advanced tactics and techniques which would allow them to bypass MFA and give them access to corporate resources.
In today’s cyber security landscape there is a growing increase in threat actors using token theft for MFA bypass.

By compromising and replaying a token issued to an identity that has already completed multi-factor authentication, the threat actor satisfies the validation of MFA and access is granted to organisational resources accordingly.

This change is a concerning tactic for SOC teams because the expertise needed to compromise a token is very low and it is indeed hard to detect, and few organisations have token theft mitigation in their incident response plan.
Two of the most common token theft techniques are the Adversary-in-the-middle (AiTM) attack and malware, designed to steal user credentials and tokens (browser cookies).


What is an Adversary-in-the-middle (AiTM) attack?

Adversary-in-the-middle attack (AiTM - Mitre - T1557) is a type of attack that aims to intercept authentication between users and a legitimate authentication service for the purpose of compromising identities or performing other actions. The attackers position themselves between a user and the service to steal credentials and intercept MFA in order to capture the session cookie. The attackers can then replay the session with the stolen session cookie before the token expiration time and impersonate the user without user intervention or MFA. With this session, the attackers could access the affected user’s resources and applications and perform Business Email Compromise (BEC) attacks and other malicious activities.



It is still a common scenario with the majority of today’s workforce working from home or in the hybrid setup, that users might be accessing resources on the corporate network using their own personal devices, which are unmanaged and not visible to the IT department. These unmanaged devices are likely to have weaker security controls than those that are managed by organisations. Users on these devices may be signed into both personal websites and corporate applications at the same time, allowing attackers to compromise tokens belonging to both.

There are publicly available open-source tools which can execute AiTM phishing attacks in an automated manner. Some of the widely used tools are Evilginx2, Modlishka, Muraena, Naked Pages and many others. There is also an increasing trend of threat actors adapting the malware to include token theft in its activity. Lack of security measures and limited visibility of the endpoints can make the detection of these attacks very difficult.

Tokens are at the center of OAuth 2.0 identity platforms, such as Azure Active Directory (Azure AD). To access a resource (for example, a web application protected by Azure AD), a user must present a valid token. To obtain that token, the users must sign-in to Azure AD using their credentials. At that point, depending on policy, they may be required to complete MFA. The user then presents that token to the web application, which validates the token and allows the user access.


OAuth token flow diagram

When Azure AD issues a token, it contains information (claims) such as the username, source IP address, MFA, and more. It also includes all privileges of the authenticating user in Azure AD.


Common phishing attack:

With the common credential phishing attack, the threat actors may use the credentials they have compromised to try and sign-in to Azure AD. If the security policy requires MFA, the attackers are stopped from being able to successfully sign-in.

Common credential phishing attack stopped by MFA


The AiTM phishing attack:

The Adversary-in-the-middle (AiTM) phishing attack is more advanced than the common credential phishing attack and requires the attacker to insert malicious infrastructure between the user and the legitimate website or application.

Every modern web service implements a session with a user after successful authentication so that the user doesn’t have to be authenticated at every new page they visit. This session functionality is implemented through a session cookie provided by an authentication service after initial authentication. The session cookie is proof for the web server that the user has been authenticated and has an ongoing session on the website. In AiTM phishing, an attacker attempts to obtain a target user’s session cookie so they can skip the whole authentication process and act on the latter’s behalf.

To do this, the attacker deploys a web server that proxies HTTP packets from the user that visits the phishing site to the target server the attacker wishes to impersonate and the other way around. This way, the phishing site is visually identical to the original website (as every HTTP is proxied to and from the original website). The attacker also does not need to craft their own phishing site like how it is done in conventional phishing campaigns. The URL is the only visible difference between the phishing site and the actual one.


AiTM phishing attack flow diagram


Pass-the-cookie attack:

This attack works in a very similar way to the AiTM phishing attack, the only difference being that the malware is being used instead of the AiTM infrastructure and browser cookies are the target. For example, when the user authenticates to Azure AD via web browser, a cookie is created and stored for that session on the device. If the attacker can compromise a targeted device via malware and extract the browser cookies, they could pass those cookies into a separate browser and bypass all security measures.

Credential theft malware like Redline, Emotet, IceID and many others have built-in functionality to extract and exfiltrate browser cookies.



Phishing still remains a frequent technique that threat actors use to gain initial access to corporate networks. The strong introduction of MFA among organisations is making the attackers adapt and improve their attacks by trying to bypass and circumvent the MFA implementations. This is causing a strong shift from common phishing attacks to more advanced attacks like Adversary-in-the-middle (AiTM). Commonly spread malware is upgraded by threat actors to include the functionality of stealing browser cookies by default. It is important to understand, that even with evolved tactics, tools, and techniques from the threat actors, using MFA in combination with other security measures (EDR solutions, conditional access policies, updated software/hardware, protected data, etc.) still provides solid protection against a wide range of attacks.

This was part 1 of the Token Theft, covering the offensive side. In part 2 of Token Theft, we will discuss the defensive side with the focus on how to detect, defend and mitigate these attacks.

Stay tuned.