Using Conditional Access to Combat Token Theft

Modern Controls Protecting Against Modern Attacks

In Microsoft’s Digital Defense Report, there was a lot of talk about AI. While it is an important change in the cybersecurity landscape, I was more intrigued by other numbers. The one that spiked my interest was the following quote on page 40:

Moreover, over the last year we’ve seen a 146% rise in AiTM phishing attacks, which occur when attackers trick users into clicking a link and completing MFA on the attacker’s behalf.

AiTM stands for Attack-in-The-Middle and is a way for attackers to gain access to a users’ account while bypassing multifactor authentication. In this type of attack, the attacker lures an end-user to their fake login pages. The user fills in their credentials, allowing the attackers to gain access to it and forward this information to Entra ID to execute a legitimate sign-in. When this legitimate sign-in is completed, the attacker has the user’s access token that they can use to log in. For more details on this attack, the Microsoft security team has released an extensive blog on it.

Because I work in a Security Operations Center, I regularly see this type of attack against my customers. At first, some were confused about how they were still being breached, even though they had multifactor authentication. There are several hardening efforts you can take to combat this kind of token theft. In this article, we will discuss some of the options and compare them against each other.

Requiring a Known Device

Requiring a known device for sign-in is a policy every organization should have. Not only to protect against token theft, but in general. If you don’t have this policy, users can log into company resources from any device. This should only be possible from a managed and secure device. You have the option to either require a registered or compliant device. A registered device is simply a device that is added to the tenant and known in Entra ID. A compliant device is a stronger control, as it means this device is managed using Microsoft Intune and receives security policies and updates through it.

Requiring a managed or compliant device for sign-in is difficult for some organizations. Sometimes, not everyone receives a device, or they need flexibility to use other devices.

To accommodate that, you could restrict access to only ‘registered’ devices. Users can easily register a device into the Entra ID tenant. Afterwards, you can set up a Conditional Access policy to exclude these devices using a device filter (Figure 1).

This is a policy that can set up with limited impact. Requiring a compliant device is a stronger control as it ensures the device to be managed by Intune. But like I said earlier, it is more difficult to implement.

This control will block attack-in-the-middle as the server used by the attacker is not registered in this scenario and will be blocked. A smart attacker could register their servers into Entra ID, but in my experience, this doesn’t happen often.

Authentication Strength

Phishing-resistant multifactor authentication will verify the server that is performing the login and block illegitimate servers. This blocks an AiTM completely as the login will never be completed.

There are multiple types of phishing-resistant authentication:

• Windows Hello for Business
• Passkeys
• Physical FIDO2 keys
• Certificate-based authentication

Some methods are easier to implement than others. While physical FIDO2 keys are useful, they come with an additional cost and extra complexity to deliver them to the users. Easier methods are Windows Hello for Business and Passkeys. Windows Hello for Business is a really convenient method as it is seamless, but it is only available on Windows devices.  Passkeys were recently made generally available by Microsoft and are ready for adoption. They form a free method of passwordless authentication.

Developing your phishing-resistant journey is a large project and requires a lot of thought. You need to ensure all of the scenarios are covered. Within most organizations, this is too complex to deploy to all users. Most of my customers are rolling out phishing-resistant MFA to their IT personnel and key users.

To implement phishing-resistant MFA, you need to execute two steps.

First, you need to have an authentication strength policy. This can be done using the Entra ID portal, select protection and then authentication methods. If you click on authentication strength, you will see the current policies. There are three built-in policies, one of them is the phishing-resistant MFA policy that we can use (Figure 3).

The next step is to use this policy in Conditional Access. To do so, select the desired authentication strength in the ‘Grant’ blade (Figure 3).

While it can be interesting to deploy this policy to every user, don’t let perfect be the enemy of good. Configuring this for your most important users is already a good step in the right direction. If you have executed this step, use these learnings to prepare a roll-out plan for the entire tenant.

Risky Sign-ins

Risky sign-ins is a part of Microsoft Entra ID Protection, which is included in a Premium Plan 2-bundle. It has the ability to flag logins as suspicious in real-time. When a user signs in, every sign-in has a risk associated with it. The risk level ranges from low to high. A sign-in is flagged as risky when some properties are out of the ordinary for a user. This includes the location, device used, ISP of the IP address, etc. This feature is really powerful and adds a lot of context to a sign-in. During an attack-in-the-middle, the sign-in is often flagged as risky, which helps us as defenders to identify potential account compromises.

Sign-in risk can also be used within Conditional Access. It is included as a condition, as seen in the screenshot below (Figure 4).

I couple this condition with the session control sign-in frequency to require authentication every time. This will ensure that a user has to reconfirm their credentials when a risky sign-in happens. If this happened during an attack-in-the-middle, it means the attacker’s access token is invalidated, locking them out.

The impact of this control is low. It will only require re-authentication when a sign-in is risky. A sign-in is only risky when a user uses a new type of device or signs in from a new location, which doesn’t happen every day.

Getting Started

This article contains three ways to protect against token theft. In an ideal scenario, all three of the protection mechanisms are implemented as they are complementary. In order to get quick wins, I recommend deploying the risk-based policies first. They offer great protection with minimal impact, but do require an Entra ID P2 license. If you don’t have a P2 license, I recommend implementing the device-based licenses first. These can be implemented after some basic configuration and with limited impact. The final implementation is the authentication strength policies. It offers extremely strong protection against attack-in-the-middle, but has a large impact as users need to adopt new authentication methods.

Whatever control you prioritize, it is important to take action, as the number of attacks will only increase.