Evading Token Protection For EntraID/M365 (2024 Edition)

The topic of using token protection has cropped up on my timeline again recently, so I thought it was necessary to do an updated post on Token Protection in Conditional access.

Like many Microsoft customers protecting users from external token theft and AiTM (adversary in the middle) ranks as one of the most top security concerns when it comes to an attacker gaining unauthorized access to cloud data.

I decided to revisit the conditional access policy for Token Protection as the Documents for implementation has changed from when I initially evaluated right when it came out in preview. If you are unfamiliar with token protection you can read the Microsoft document below on how to get started. (Conditional Access enforcement requires an Entra ID P2 License)

Token protection in Microsoft Entra Conditional Access - Microsoft Entra ID

To set the stage for Token Protection I have certain conditional access policies enforced. The conditional access polices below are some of what I consider the bare minimum anyone should be doing in Conditional access. Administrators and users are required to do MFA, legacy authentication is blocked, and to access security info registration, you are required to satisfy an MFA request before you can access that type of information. All these policies are available as a conditional access template from Microsoft if needed.

Figure 1 — Conditional Access Policy States

Device State of Targeted User

Before I set up token protection its important to check on the device state of what your end user has. A key requirement for Token protection is outlined in the following:

• Windows 10 or newer devices that are Microsoft Entra joined, Microsoft Entra hybrid joined, or Microsoft Entra registered.

For the purpose of this blog we will focus on a Microsoft Entra Hybrid joined device.

Figure 2— Device States Table

[1] https://learn.microsoft.com/en-us/entra/identity/devices/troubleshoot-device-dsregcmd

If i run the dsregcmd command I am able to determine that the end user I am targeting is running on a Microsoft Entra Hybrid joined device. I’m also including certain device details that the device is using such as a TPM protected device.

Figure 3 — Device State

(Failure) Simulated Device Code Phishing

Using TokenTactics, I start with a simulated device code phish that I want the end user user to complete.

Figure 4 — Device Code Phish

If the end user attempts to complete, the following message will be received on the end user screen. The conditional access message also tells us that token protection is working in this particular scenario as seen in the message below.

Figure 5 — Conditional Access Block

Success: Device Code Phishing with OS/2 Warp Agent

For this scenario I am using a fork of TokenTactics that allows me to switch the device type that I am sending my Device Code phish.

Figure 6 — Device Code OS/2 Warp Phish

From the end user perspective once they complete the request they will see a screen that they have successfully signed into Microsoft Office. If you look in my previous screenshot you will see I got a bearer token back.

Figure 7 — MS Office Sign In

Taking the exploitation a bit further I can execute the following commands with TokenTacticsV2 to get a single line access token that I can replay into Graph Runner.

Invoke-RefreshToMSGraphToken -Device OS/2
$MSGraphToken.access_token

Figure 8 — Access Token

If we replay this token into GraphRunner, we will see that everything is in working order to pivot into other services such as fetching emails as the compromised end user.

Figure 9 — Graph Scope

Figure 10 — Confirming Email Access

Warning on Token Protection

Stacking token protection policy by itself in conditional access is not enough for external token theft mitigation.

Token Theft Mitigations That Do Not Require E5

If you are on the Azure AD Free tier, unfortunately this does not apply. However, if you are on M365 E3 and using conditional access then please read on. These mitigations are for you. You can do these mitigations without and E5 license and they can be extremely effective at mitigating external token theft in your environment. (Please note I am not covering mobile device scenarios below)

Requiring Hybrid Entra ID Join (If you are running traditional active directory)

If you are running traditional active directory and using Entra ID connect to sync your on premises users to the cloud, I will stress that configuring Hybrid Join in Entra ID connect is in your best interest. The following article below steps you through the process.

Configure Microsoft Entra hybrid join - Microsoft Entra ID

I have hybrid Entra ID join configured slightly different from Microsoft recommendations and I will explain my reasoning below. This is my configuration policy grant on Entra ID Join:

Figure 11 — Grant Access Configuration

So what is different from Microsoft’s recommendation? For grant access I am requiring the Entra Hybrid joined device and requiring it as a selected control.

If you choose the Microsoft default conditions…MFA, compliance, and hybrid will be thrown in along with requiring only one of the selected controls. IMHO having an either/or situation to satisfy a grant control can lead to an unintended bypass should an attacker register MFA on behalf of the end user. Since we are requiring MFA for all cloud workloads with a different policy, I am ok with eliminating the MFA requirement and putting device compliance under a different conditional access policy.

Block Unknown or Unsupported Device Platforms

Blocking unknown or unsupported device platforms is something I highly recommend doing. It will stop token theft if an attacker uses something like an OS/2 warp user agent. This should be done immediately in any tenant. Details on how to do this are below:

Block unsupported platforms with Conditional Access - Microsoft Entra ID

End Results

Since I now have these two options in place for the end user + token theft protection, we should see if we can get a token with traditional token theft methods. Below we see another device code initiated with an OS/2 User agent. This method will now fail since the originating request came from an unmanaged device.

Figure 12 — Token Theft Fail

So what about phishing with evilginx?

Traditional phishing with evilginx will also fail because of the same principal. The origin request will fall outside devices managed by the organization. This however does not prevent the password from being stolen. This is why MFA is extremely important to stop those types of attacks.

Other parting thoughts with token theft?

To make this blog a little shorter I did not cover mobile devices. This looks at external token theft strictly from a managed desktop/laptop device perspective.

One thing I did want to mention but its still currently in preview is the ability to block device code flows. Once it becomes GA, I will highly recommend this be put in place. This will render tools such token tactics, ineffective.

Block authentication flows with Conditional Access policy - Microsoft Entra ID

While these sources and methods block external token theft, I should mention they do not cover internal token theft when an attacker establishes an internal foothold with a C2 and SOCKS proxy connecion. Possible future blog with that? Maybe?

For now I hope everyone that reads this finds the information useful.