Enhancing Security with Microsoft Entra Token Theft Protection

This article explores how Microsoft Entra’s new token theft protection policy can provide robust protection against token theft. By leveraging a new Conditional Access policy, organizations can safeguard their digital identities and sensitive data from cyberthreats.

Securing your IT landscape is increasingly becoming critical. With cyberthreats on the rise, and showing no signs of slowing down, bolstering your security framework and foundation should be a weekly, if not daily message in your ear and for your IT Pros. To keep those baddies out, Microsoft offers a comprehensive suite of technologies – Entra, Defender XDR, Intune, and Windows. A crucial aspect of these tools is their role in token theft protection.

A token allows applications to authenticate and authorize your users without them needing to ask for credentials repeatedly. These are becoming a hot target for hackers. In this article, we’ll look at the new token binding feature in Microsoft Entra and how it can be used with security features in other Microsoft products to prevent token hijacking.

What is token theft?

When a user logs in to an online service and uses multifactor authentication (MFA), I imagine they feel safe, knowing only they can access their account. However, after a user opens an email in Outlook on the Web, clicks on a ‘not-so-safe’ email, then…

Token theft, also known as token hijacking, is an attack in which malicious actors gain access to an authentication token used by an online service, like Microsoft 365. Authentication tokens are pieces of information stored locally on a device that tell an online service that the device has authenticated recently enough that it does not need to do so again.

This is where the hackers come in. After a user logs in to their Microsoft 365 ‘office.com’ portal with MFA, they are securely accessing their account. No one else can, right?

Well, in their Inbox, they open an email they assume to be legitimate and click on a link to open a project from another colleague. After they click on the link, their token is used to log in to that site. At that moment, the hacker can steal that token from the code they’ve inserted into the website. They are now free to log in as that user, open their OneDrive, and download whatever files they want.

Common attack methods and vectors

You may be surprised at the various scenarios and common workflows where token theft is rising in popularity. Here are some of the most common in the IT field.

• Man-in-the-Middle (MitM) Attacks – In these attacks, hackers intercept and alter communication between the client and server to steal tokens as they pass through a router or proxy server controlled by the attacker.
• Malware – Hackers will often use malware to acquire tokens directly from the client device. This coincides with my example above – Logging into Outlook on the Web, clicking on a link in email, and then allowing the hacker to steal and copy the temporary device token for Microsoft 365 (Entra ID).
• Phishing – Traditional phishing attacks often trick users into revealing their credentials, assuming everything is above board – this is where hackers use these stolen credentials to wreak mayhem with your private corporate data.
• Insecure Server Logs – Attackers can extract tokens from unsecured server logs of the relying party – tokens written in plain text could be stored here for their perusal.

Microsoft Entra: Conditional Access ‘Require token protection’ policy

In Microsoft Entra, a new conditional access policy is in public preview – Require token protection. It is designed to enhance security by ensuring that tokens used for authentication can only be used on the device where the user originally signed in, otherwise known as token binding. This policy helps protect against token theft by ensuring that even if a token is stolen, it cannot be used on a different device.

Before I show you how to create the policy, let me go through some of the important requirements and limitations to be aware of. Plus, an expensive license type is needed, too.

Requirements

First, let me list the requirements and currently supported apps for this policy.

• Windows 10 or newer devices – Microsoft Entra joined, Entra hybrid joined, or Entra registered
• OneDrive sync client version 22.217 or later
• Teams native client version 1.6.00.1331 or later
• Power BI desktop version 2.117.841.0 or later
• Visual Studio 2022 or later
• Office perpetual versions are not supported (2016, 2019, 2021, 2024, etc.)

Limitations

There are some limitations to incorporate into your planning.

• Microsoft Entra B2B (external users) aren’t supported
• The following apps are not supported because they don’t allow protected token flows
  • PowerShell modules with Exchange, SharePoint, or Microsoft Graph
  • PowerQuery extension for Excel
  • Visual Studio Code extensions
  • The new Teams 2.1 preview client is blocked after sign-out due to a transient bug
• The following Windows devices are NOT supported
  • Windows Server
  • Surface Hub
  • Windows-based Microsoft Teams Rooms (MTR) systems

Licensing requirements

This is important – this feature requires Microsoft Entra ID P2 licenses. Token Protection enforcement is part of Microsoft Entra ID Protection and will be part of the P2 license when the feature is generally available.

How to set up token theft protection in Microsoft Entra

To see how this policy works in Microsoft Entra, please follow these instructions:

• Sign in to the Microsoft Entra admin center as a Conditional Access Administrator.
• Navigate to Protection > Conditional Access > Policies.

• Create a new policy and give it a name.
• In the Users section, be sure to choose a small test group of users. Under Target resources, choose Office 365 Exchange Online and Office 365 SharePoint Online as the cloud apps to protect.

• Under the Grant section, make sure you check ‘Require multifactor authentication‘.
• Then, click the Session section, and put a checkmark in ‘Require token protection for sign-in sessions (Preview)‘.

• Be sure to keep the ‘Report-only‘ selected under the ‘Enable policy‘ section at the bottom. You want to test this first with a small set of users.

Enforcing this policy ensures that tokens are protected and can only be used on the intended device, providing an additional layer of security against unauthorized access.

How else can I protect against token theft?

Microsoft has several other technologies that can help detect and prevent token theft.

Microsoft Intune: Enable Local Security Authority (LSA) protection

Enabling Local Security Authority (LSA) protection in a Microsoft Intune policy is a crucial step in protecting against token theft. LSA protection, or LSA Protection Mode, is a security feature in Windows designed to protect against theft of credentials and other security threats.

Essentially, the Local Security Authority Server Service (LSASS) process is configured as a protected process, which prevents memory reading by non-protected processes and code injection.

Microsoft Entra ID Protection

Entra ID Protection helps detect and respond to token theft by providing risk detections and alerts. It includes features like anomalous token detection, token issuer anomaly detection, and adversary-in-the-middle (AitM) detection. These features help identify suspicious activities and potential token theft attempts, allowing administrators to take immediate action to mitigate risks.

Microsoft Defender

Besides Entra ID, Microsoft Defender XDR also offers methods to monitor identity theft. This includes dark web monitoring, credit monitoring, 24/7 restoration support, and identity theft insurance. By integrating with Experian, Defender XDR provides robust monitoring capabilities to detect stolen tokens and other identity theft indicators.

Together, these tools offer an obligatory cog in your overall comprehensive strategy to combat token theft in your organization.

Microsoft’s Security Service Edge (SSE) solution – restrict access from trusted network

Microsoft Security Service Edge (SSE) is a cloud-based security solution that provides advanced protection for users and applications accessing the internet.

Its main value comes from restricting access to trusted networks. As an example, when a user or app tries to access the Internet, SSE evaluates their network location based on configured ‘allowed’ IP addresses and/or ranges. If they are within a defined trusted network, they are given unrestricted access. If however, they are outside one of these networks, they will be required to provide more security information to prove they are who they say they are.

Using these controls, you are given enhanced security by requiring additional authentication and device checks. You are also improving your compliance posture with these documented and auditable logs. Simplified management, another boon for your admins, makes implementing this straightforward after your initial pilot phase.

How to implement a comprehensive strategy

In conclusion, while implementing Microsoft Entra’s Token Theft Protection is a crucial step in safeguarding your organization’s digital assets, it should be part of a broader, more comprehensive security strategy. Here are some key elements to consider.

1. Regular Security Audits – Conduct frequent security assessments to identify vulnerabilities and ensure compliance with the latest security standards.
2. User Education and Training – Create employee education campaigns about the risks of token theft and best practices for maintaining security, such as recognizing phishing attempts and using strong, unique passwords.
3. Multifactor Authentication – By now you should know my stance on MFA. There is no reason not to use it. Implement MFA across all critical systems, period.
4. Continuous Monitoring – Invest in advanced monitoring tools to detect and respond to suspicious activities in real-time – proactive is always more efficient than reactive.