Abusing Family Refresh Tokens for Unauthorized Access and Persistence in Azure Active Directory

Undocumented functionality in Azure Active Directory allows a group of Microsoft OAuth client applications to obtain special “family refresh tokens,” which can be redeemed for bearer tokens as any other client in the family. We will discuss how this functionality was uncovered, the mechanism behind it, and various attack paths to obtain family refresh tokens. We will demonstrate how this functionality can be abused to access sensitive data. Lastly, we will share relevant information to mitigate the theft of family refresh tokens.

You can find the current research here: https://github.com/secureworks/family-of-client-ids-research

In short, I was curious about undocumented/unexplainable behavior with Azure AD refresh tokens wherein an RT issued to one client app can be redeemed for new bearer tokens as a different client app (and benefit from their scopes).

I performed a series of experiments brute forcing several million refresh token grants between combinations of OAuth clients/resources and using a variety of different grant flows. I then did data analysis on the results. I found a cluster of ~15 out of ~600 client apps. All of which could redeem their RTs for any of the other ~15 client apps and were first-party, pre-consented, public clients present by default in an Azure AD tenant. Subsequent digging through git histories in the MS identity SDKs revealed the mechanism behind this behavior, which MS confirmed.

AAD will issue special “family refresh tokens” (FRTs) to a special list of “family” clients applications. FRTs differ from normal RTs in that they are not bound to the same client as the original authorization. A single FRT can be used to acquire bearer tokens (including more FRTs) for any/every/all client apps in the “family” and with their scopes. As such, the blast radius from FRT theft is considerable.

I walk through several practical attack scenarios to obtain and abuse FRTs. I can share some of our tooling around FRTs that we use for red team engagements.

Lastly, I cover the few mitigations available for FRTs with a good discussion around conditional access.