Introduction

About 2 years ago I recorded a video for some colleagues showing just how easy it is to steal credentials within Microsoft 365 using open-source software called Evilginx.  At the time, threat actors really were not using these pages and frankly weren’t very good at what they were doing.  Users they were phishing were still falling for the Microsoft forms pages asking for usernames and passwords, so why would they need to adjust and get more advanced?  Well, just as I predicted then, the threat actors evolved and are now starting to use more advanced mechanisms for stealing credentials from your users.  Threat actors recognized that compromising a machine is no longer feasible, but getting a user to click a link and “sign in” is far easier.  In today’s article we will talk through what token theft is, how to detect it, and what you can do to better protect your Microsoft 365 environment.

What Is Token Theft?

Token theft is when a threat actor intercepts a user’s authentication token, take it, and use it on another system to sign in as the user without entering their password or approving MFA.  If only MFA is required, that may be contained within the authentication token and the threat actor may be meeting all the organizational requirements for sign in.

How Does Token Theft Happen in Microsoft 365?

There are various strategies an attacker can use to steal auth tokens from your users within Microsoft 365.  The most common methods are below:

Phishing Attacks

Your users have likely witnessed the classic phishing emails asking for you to send money to a Nigerian prince or even buy gift cards for your very busy CEO.  Well, the Nigerian Princes and the CEO’s have all been taken care of and now the threat actors are using very legitimate looking emails to get your users to click links.  The “open” button on this email would take your users to a sign in page that would utilize a Man-in-the-Middle attack to intercept a legitimate sign in token, give it to a threat actor, then the threat actor would be able to replay it on their own device.

Man-in-the-Middle (MitM) Attacks / Session Hijacking

These attacks are commonly used in conjunction with a phishing link/email.  The threat actors using these tactics will likely have a webpage and server hosting the MitM page.  In my examples, I have a phishlet from Evilginx that is set to mimic the Office 365 sign in pages.  In this instance you can see that the victim’s organization even has custom branding setup and Evilginx will pull those from public APIs and render them to make the user feel like they are signing into the right place.

This sign in page will collect the username, password, and 2FA token.

Next, the threat actor will go to their server, collect the credentials in the form of a block of JSON text, then drop them into a cookie editor.

With the session cookie injected into the threat actor’s session, they refresh the page and are brought into the O365 main landing page as the victim user without having to enter a username, password, or 2FA.

Malicious OAuth Apps

This type of attack is much less common but is still showing up.  When MFA was first getting implemented with Microsoft customers, threat actors had to think on their feet and they went toward creating malicious enterprise/OAuth applications which would ask users for permission to their data, then once the user hit the “approve” button, it would systematically grab their data, create forwarding rules, or even provision virtual machines in azure for crypto mining (source).  An example of the fake sign in page is below:

This entire attack can easily be mitigated by changing two settings within the Entra ID administrative center.

• Changing your user consent settings to either no apps consented by end users or only allowing verified publishers to be consented.  https://entra.microsoft.com/#view/Microsoft_AAD_IAM/ConsentPoliciesMenuBlade/~/UserSettings

• Changing your admin consent workflow settings so your admins can be notified when users are requesting new applications.  https://entra.microsoft.com/#view/Microsoft_AAD_IAM/ConsentPoliciesMenuBlade/~/AdminConsentSettings

Impact of Token Theft in Microsoft 365

Account Takeover

When a user’s authentication token is stolen, everything that user has access to should come into question.  The threat actors that are stealing account information now have very fast ways of stealing entire Inboxes, OneDrives, and SharePoint sites.  With this being said, anything the users has access to should be considered stolen, unless proven otherwise via Audit Logs.

Data Breaches

When the unauthorized access occurs, the data that the user has access to is likely breached and should be considered breached until a forensic report can show that it wasn’t touched.  To know your responsibilities for reporting a data breach, reach out to breach coach or attorney.

Financial Loss

With the contents of inboxes now called into question, we ask “Why did the threat actor take these things and break into this person’s account?”  It is likely because they are looking for some way to get paid for their actions.  Maybe they are looking for a directions document for vendors to pay.  In this instance a threat actor would take this document, edit it to contain their account information, then use the account that they stole, and send the updated payment instructions to your unsuspecting vendors.  A good threat actor would then delete these emails so it cannot be traced.  Your organization, without the proper investigation, would not know about these and likely wouldn’t discover these events until your vendors are past due on invoices.  When you would reach out to your vendors to find out why they aren’t paying, they would then show you the updated payment instructions the threat actor provided.

Lateral Movement and Persistence

These threat actors are good at getting into accounts and they use the accounts they steal to get even more accounts.  You can see now how this can continue and continue.  These folks will also leave persistence mechanisms for themselves to get back into these accounts or even so they can sell access to these accounts in the future.  The persistence will mean that they can get back into them using MFA or systemically via a malicious OAuth app and they can continue on with the financial crimes or bring in another threat actor group that would perform a different type of attack.  As you can see below, the threat actor registered two other methods for authentication on the user and set their method as the default so the user would not see when they were prompted.

How to Detect Token Theft

Within Microsoft Defender XDR, there are certain alerts that will be triggered in this event, and they will all be contained within an incident.  In a credential theft and token compromise event, the incident and alerts will look like the below.  You will also see sign ins for a user from new IP addresses that say their sign in request was successful and their MFA was fulfilled by a claim in the token.  The latter part can be legitimate, but in the event of a net new sign in from a new IP address with that information would mean it should be looked into further.

Best Practices for Preventing Token Theft

Educate Users

Educating your users on the practices of phishing, how easy it is to steal their information, and to educate them on how they are pivotal to security as well is so important.  Users should know that they are the last defense in our security and even though we have technologies to better protect, we are not able to stop all attacks.

Require Compliant Devices

To best protect against the token theft and token replay attacks, you should consider requiring all devices in your environment be marked as compliant by Intune or Hybrid Azure AD Joined.  This does require all devices be enrolled or configured to check in, but once this is complete you can set a policy to require compliance or Hybrid Join.  This will stop an attack where the token is stolen and replayed.  See the below image where the threat actor is attempting to replay the session cookie but blocked by Conditional Access because they are not on a compliant machine.

Require Phish Resistant MFA

The next thing to consider is requiring phish resistant MFA.  What is phish resistant MFA?  This is an MFA method based on public/private key cryptography and is immune to drive by or credential theft attacks.  Examples of phish resistant MFA are FIDO keys, Passkeys (passwordless authentication mechanisms), and WebAuthn (Windows Hello for Business or Biometric Authentication).  The first step to deploying phish resistant MFA would be to devise a plan and strategy that would work for your users and determine the authentication mechanisms we want to get them enrolled under.  Once users are enrolled, we would get a conditional access policy setup like below to require phish resistant MFA for a pilot group of users, then eventually apply it to all users.

Require Token Lifetime Policies

Token lifetime policies can protect against token theft, but they can also require your users to input MFA more frequently.  This method of preventing token theft likely isn’t worth your time to consider.  Any good threat actor will steal credentials, then get into that account within about 12 hours and create a persistence mechanism like another 2FA method registered for the user and be able to re-auth as frequently as they need to.  Reduced token lifetimes would cause your users to MFA more frequently and would end up causing MFA fatigue.  This method is not recommended.

Audit Apps and Review App Permissions

Enterprise applications are another way that threat actors will give themselves persistence mechanisms into your environment.  These persistence mechanisms can bypass MFA and can continue to cause damage after an event if not cleaned up appropriately.  Review your enterprise apps quarterly and review the permissions to them.  If you don’t recognize the app, disable it, and work with the users included in the app to understand the purposes.  If it can’t be sourced to what the app is, consider involving a breach coach and your cyber insurance.

Employ Defender to Alert on Token Usage

Defender XDR will alert on token stealing by default when licensed appropriately.  It is recommended to consider consolidating your endpoint protection, identity protection, and email security under one tool so you can better detect events like this.

Conclusion

In conclusion, token theft presents a serious and evolving threat to Microsoft 365 environments. While Microsoft’s robust security measures such as Multi-Factor Authentication (MFA), Conditional Access, and tools from the Defender suite are essential in minimizing risks, it is equally critical for organizations to stay proactive. Implementing advanced identity protection strategies, ensuring regular user education, and continuously monitoring for suspicious activities can drastically reduce the likelihood of token theft. As cybercriminals develop more sophisticated tactics, organizations must remain vigilant and leverage the full range of security features available within Microsoft 365 to safeguard their digital assets.