Not All Tokens Are Created Equal

Entra tokens are authentication tokens issued by Microsoft Entra to enable secure access to Microsoft 365 services and other resources. These tokens are crucial in user and application authentication, allowing access to resources like Microsoft Teams, OneDrive, and SharePoint. Because of the access they grant, Entra tokens have become a desirable target for malicious attackers.

One way an attacker can get a hold of a token is via phishing, abusing the OAuth2.0 Device Authorisation grant process. This process requests a device code from Microsoft and upon entering the code and authenticating with their EntraID account an attacker can obtain a JWT token.

If a victim falls for this successful phish then its possible to retrieve a bearer token.

Bearer Token

Some key elements to point out in the above bearer token that was obtained through this process are as follows:

1. Access Token: which is the actual JWT token. This token is used to authenticate requests to the specified resource.

2. Refresh Token: Used to obtain a new access token without requiring the user to log in again. This is typically valid for a longer period (up to 90 days) and allows for session continuity.

3. _ClientId: The client application that requested the token.

4. isMRRT: denotes that the refresh token is a Multi-Resource Refresh Token (MRRT), allowing it to be used across multiple resources within the same organisation.

5. Resource: the URL for Microsoft Graph API, indicating where this token can be used.

6. expireIn: Specifies the remaining time in seconds before the token expires.

As stated above these tokens are MRRT (Multi Resource Refresh Tokens) which means they are refresh tokens that can be used to obtain an access token for a resource that can be different from the resource for which the MRRT was obtained in the first place. So why does an attacker want these: Well as mentioned earlier these tokens can be used to access various cloud-based services, including Outlook, SharePoint, OneDrive, and Teams, potentially exposing a wealth of sensitive data AND once an MRRT is obtained, it allows access without the need to re-trigger MFA, even if MFA is required for initial login. Some Nice positives for attackers!

Multiple blogs go into more detail on these Tokens so I'm not going to go into too much detail regarding the actual tokens themselves but I will link other blogs at the end if you want to dive deep. However, it's worth stating that Access tokens are designed to expire after a limited duration, typically around one hour. When an access token expires, the client application must acquire a new one to maintain access to protected resources. To do this, the client can either seek authorisation from the resource owner again or utilise a refresh token to request new access tokens, using the original authorisation as a basis. It's the latter of these that we can abuse once we have a refresh token.

In short: Refresh tokens allow you to obtain Access Tokens for multiple resources.

To accomplish this as an attacker we can use a few tools but most notably are TokentacticsV2, GraphRunner, AADInternals and ROADtools. All linked here:

https://github.com/f-bader/TokenTacticsV2

https://github.com/dirkjanm/ROADtools

https://github.com/Gerenios/AADInternals

https://github.com/dafthack/GraphRunner

Once you’ve captured a token through your device code phishing method, you can leverage it to access data across various Microsoft services—such as Azure CLI, MS Graph, Teams, and Outlook—depending on the permissions granted. From there, you can also run enumeration tools like Roadrecon or AzureHound to further explore the environment. This is how:

RoadRecon

As we captured a MS Graph token (windows[.]net) you will have to use tokentactics to refresh to a Graph token with the below:

RefreshTo-GraphToken -refreshToken <0.Aug<SNIP>SWSa> -domain domain.com

Then extract the token

$graphToken.access_token

Use the access token with roadrecon

roadrecon auth --access token <eyJ0hg<SNIP>sh>

Then you can pull data, including Conditional Access policies

roadrecon gather

roadrecon plugin policies

You can also change the FOCI using roadtx depending on what app we are impersonating. For example:

roadtx gettokens --refresh-token "SNIP" -c msteams
roadtx gettokens --refresh-token "SNIP" -c azcli

A list of FOCI client IDs can be found here:

https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv

You can keep refreshing your token with the below:

roadtx gettokens --refresh-token file -c msteams

(Using the 'file' parameter uses .roadtools_auth to pull tokens from to save you pasting string)

Graphrunner

To use the refresh token for graphrunner I do the following

Invoke-RefreshGraphTokens -RefreshToken "<SNIP>" -tenantid "domain.com"

This should write tokens to $tokens with an expiry time

You can view your tokens by checking the $tokens variable

You can also run Invoke-AutoTokenRefresh to refresh them on a regular interval - the default is 5 minutes unless you specify differently

Outlook

You can use token tactics to refresh the Outlook tokens, which you can pass in a Burp request

RefreshTo-OutlookToken -refreshToken <0.Aug<SNIP>SWSa> -domain domain.com

Then extract the tokens

$OutlookToken.access_token
$OutlookToken.refresh_token

Once you have both tokens, open Burpsuite and either create a request using the below or proxy a legitimate request to https://outlook.office.com I have the request saved in a Burp project which I just open when I'm doing this attack.

• Code: will be your refresh token

• id_token: will be your access token

Send the request and you should receive a 302 response.

You can then request in browser and refresh and you should be logged into Outlook.

Azurehound

Azurehound can be run using the graph refresh token

RefreshTo-GraphToken -refreshToken <0.Aug<SNIP>SWSa> -domain domain.com

azurehound -r "0.AVAApQl<SNIP>" list --tenant domain.com -o output.json

Mitigation

You can mitigate this attack by using a Conditional access policy.

Microsoft has detailed how to do this here.

Conclusion

While this technique is not new, I created this blog to both share insights with others and reinforce my own learning. There are excellent resources that delve deeper into this attack, including valuable research from Secureworks. Additionally, Dirk Jan Mollema’s tools and blogs provide brilliant contributions to this area.

https://dirkjanm.io/introducing-roadtools-and-roadrecon-azure-ad-exploration-framework/

https://github.com/secureworks/family-of-client-ids-research