Abusing Family Refresh Tokens For Unauthorized Access And Persistence In Azure Active Directory

In the evolving landscape of cloud security, a novel vulnerability within Azure Active Directory (Azure AD) exposes a critical risk to organizational assets.

This article delves into the misuse of “family refresh tokens” to gain unauthorized access and maintain persistence in Azure AD environments.

By exploring the technical underpinnings and potential attack pathways, we illuminate the urgent need for robust mitigation strategies to safeguard against these sophisticated threats.

• Ryan Marcotte Cobb, CTU Special Operations
• Tony Gore, CTU Special Operations

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.

Updates

• 2022-03-23: Added 17 new FOCI family client apps to known-foci-clients.csv

Table Of Contents

• Part 1 – Azure Active Directory and OAuth 2.0
  • Granting Consent
  • Grant Flows
    • Example 0 – Install Dependencies
    • Example 1 – Device Code Flow
  • Bearer Tokens
    • Example 2 – Decode Access Token
    • Example 3 – Use Access Token to Call Graph API
    • Example 4 – Redeem Refresh Token
  • Refresh Tokens: Specification vs. Implementation
    • Example 5 – Documented AAD Refresh Token Behavior: Different Scopes
    • Example 6 – Undocumented AAD Refresh Token Behavior: Different Clients
• Part 2 – Introducing Family of Client IDs & Family Refresh Tokens
  • Experiments
  • What is the mechanism and purpose behind this undocumented behavior?
  • Which client applications are compatible with each other?
  • What are the security implications of Family Refresh Tokens?
    • Example 7 – Privilege Differences between Access Tokens
    • Example 8 – Family Refresh Token Chaining
• Part 3 – Attack Paths
  • Device Code Phishing
  • Abusing Single Sign-On
• Part 4 – Mitigations against Family Refresh Tokens
  • Conditional Access Policies
  • Auditing Sign-In Logs
  • Revoking Refresh Tokens
• Conclusion

Part 1 – Azure Active Directory And OAuth 2.0

Azure Active Directory (Azure AD) is a cloud-based identity and access management (IAM) platform developed by Microsoft.

Microsoft uses Azure AD as the IAM provider for its own cloud services, such as Microsoft 365 and Azure Resource Manager.

Azure AD implements the OAuth 2.0 and OpenID Connect (OIDC) standards as the foundation for its authorization and authentication functionality, respectively.

OAuth 2.0 is an authorization framework that lets resource owners (usually end-users) delegate permissions to client applications to access web services on their behalf.

The IETF standard for OAuth 2.0 was originally defined in RFC 6749. Additional technical specifications were later ratified to detail use-cases that were not addressed in RFC 6749.

Even with active development on the OAuth 2.0 standard, Microsoft pushes the boundaries of its design to support the sheer scale and variety of services that rely on Azure AD.

This research focuses on the OAuth 2.0 implementation in Azure AD. We will highlight a few important differences between the implementation in Azure AD and the OAuth 2.0 specification.

We will explore the security implications of these differences and demonstrate how an attacker can abuse Azure AD implementation quirks for privilege escalation and persistent access to Microsoft cloud resources.

Lastly, we will share how we weaponized this undocumented feature for red team operations at Secureworks, as well as a few mitigations to protect your organization against it.

For more information click here