Detecting Microsoft Entra ID Primary Refresh Token Abuse with Next-Gen SIEM

Microsoft Entra ID Primary Refresh Tokens (PRTs) are an attractive target for threat actors because they are long-lived, they are broadly scoped and they often don’t have additional multifactor authentication requirements after they are obtained. In this blog, we will discuss what PRTs are, how they are issued and how recently released research gives threat attackers a new way to obtain them. Finally, we will examine how organizations can detect these attacks using CrowdStrike Falcon® Next-Gen SIEM.

What Is a Primary Refresh Token?

A PRT is a single sign-on (SSO) token issued to devices that are registered or joined with Entra ID. This provides users with a way to access Entra ID-connected applications and websites without having to sign on again. The PRT is used to identify the user and device; it is typically used to obtain an access token, which grants access to a specific protected resource, such as an API. The access token is short-lived and usually has a limited lifetime, whereas the PRT is long-lived and can be used to request a new access token when the existing one expires. 

How Primary Refresh Tokens Are Issued

PRTs are issued to users and tied to their device. A prerequisite to getting a PRT issued is a user registering or joining a device to Entra ID. Some examples of legitimate device registration processes are detailed here.

To summarize an example of a device registration process:

1. The device connects to Entra ID during setup with the out-of-the-box experience (OOBE) and sends a request to discover authorization endpoints.

2. The device collects user credentials and sends a request to Entra ID to validate them.

3. If valid, Entra ID returns an ID token with claims.

4. The device checks for mobile device management (MDM) terms of use and presents them to the user if required.

5. The device sends a registration request to Azure Device Registration Service (DRS) with the ID token and other info.

6. Azure DRS validates the request, creates a device ID and certificate, and sends them back to the device (see image below).

7. The device saves the device ID and installs the certificate, completing registration.

The following image demonstrates the newly created certificate noted in Step 6 of the process:

Once the device is registered, a PRT is issued to Windows 10 or newer devices after a user successfully authenticates with their Entra ID credentials. This can be achieved through either primary account authentication on a hybrid or joined device or by adding a secondary work account on a registered device.

The user would then be able to access different Entra ID resources utilizing the PRT without the need to log in to each application.

How Adversaries Abuse Primary Refresh Tokens 

Threat actors can exploit PRTs in various ways, and multiple attack vectors have been identified. Here, we will delve into one specific method: phishing for PRTs. This type of attack — as demonstrated by security researcher Dirk-jan Mollema — involves tricking a user into authenticating to Entra ID using a device code generated by an attacker and then using the obtained access and refresh tokens to register a new device on their behalf, ultimately generating a new PRT. We’ll explore this attack in more detail and discuss potential detection opportunities.

Using Dirk-jan Mollema’s ROADtools, we can walk through how this process occurs.

First, we need to get a refresh token using the Microsoft Authentication Broker Client ID and roadtx’s gettokens command. This step retrieves a standard refresh token for the Microsoft Authentication Broker Client ID and is leveraged for user authentication.

Subsequently, we will use that refresh token to request an access token to the device registration service. The device registration process relies on this Microsoft Authentication Broker Client ID being used in this flow. That will be relevant later on when we discuss detecting PRT abuse.

We then register our device as noted within the image below. During this step, certificates and private keys are created for our fake device and subsequently used to register the device.

Finally, we can request a PRT for our new device, as outlined below.

Detecting Primary Refresh Token Abuse with Falcon Next-Gen SIEM

As demonstrated in Dirk-jan Mollema’s recent research, device code phishing can be used by threat actors as a way to obtain PRTs. Device code phishing involves tricking a user into entering an attacker-generated device code and authenticating to an authentication provider’s authorization URL. Because the attacker initiates the authentication and generates the device code, if a user authorizes that code, the attacker will receive the credentials.

To demonstrate how we can detect these attacks using Falcon Next-Gen SIEM, let’s consider a scenario where an adversary targets an organization in a phishing attack using these new techniques. A user receives an email requesting them to authenticate to Microsoft’s device code authentication URL.

Once the user authenticates, the threat actor receives both access and refresh tokens for that user.

The threat actor can then register a new device and request a Primary Refresh Token using ROADtools or a script utilizing it similar to this one. 

Due to the nature of device code phishing, the email and authentication logs may not be seen by endpoint or email protection. A user may receive an email to a personal account or scan a QR code containing the malicious URL from their mobile device and authenticate there. However, the authentication logs will still be available through Falcon Next-Gen SIEM’s Entra ID connector.

As mentioned earlier, the threat actor needs to leverage a specific client ID, also known as app ID, in the phishing attack. This is identifiable in Falcon Next-Gen SIEM logs via our Entra ID connector.

The simplest and most straightforward detection would be similar to one presented previously in Dirk-jan’s research. It would be something similar to this log analytics KQL query:

SigninLogs | where AppId == "29d9ed98-a469-4536-ade2-f981bc1d605e" and AuthenticationProtocol == "deviceCode"

The equivalent CrowdStrike query would be the following. Please note that this requires the Entra ID data connector due to some fields not being available via the Microsoft Graph API.

#repo = "3pi_microsoft_entra_id"
| Vendor.properties.authenticationProtocol = deviceCode
| Vendor.properties.appId = "29d9ed98-a469-4536-ade2-f981bc1d605e"

This query is a great approach and should work in most environments to detect device code phishing using that client ID. A correlation rule template based on this query is now available to Falcon Next-Gen SIEM customers.

In addition to this approach, Falcon Next-Gen SIEM’s correlation rules can combine these data points with two additional resource IDs and a “register device” event to alert activity where a device is registered in a suspicious way. This activity isn’t necessarily malicious in all environments, but it would be for most CrowdStrike customers. Correlation Rule Templates detecting this and some additional tool defaults are also available for customers.

If an account is determined to have been compromised, all refresh tokens for that user should be revoked.

Stay Ahead of Threat Actors

PRTs have become a target for threat actors, who can now use device code phishing tactics to obtain them. PRTs grant access to sensitive resources and data, making them a highly sought-after prize for attackers.

With Falcon Next-Gen SIEM, businesses can identify and detect both the phishing attacks that grant initial access and the registration of the fake device that will be used to eventually obtain the PRT. By detecting these threats in real time, they can quickly respond to incidents, contain the damage and prevent further exploitation.

Additional Resources