Restless Guests: From Subscription to Backdoor Intruder

Restless Guests: From Subscription to Backdoor Intruder

Speakers: Simon Maxwell-Stewart

Conference: Cloud Village

YouTube: https://www.youtube.com/watch?v=LkM2RYiNwI8

Overview

In "Restless Guests: From Subscription to Backdoor Intruder," Simon Maxwell-Stewart unveils a critical, often overlooked attack vector within Microsoft Azure environments. The talk details how a Business-to-Business (B2B) guest user, despite possessing minimal or no explicit permissions within a target Azure tenant, can leverage billing roles from their home tenant to create and subsequently own Azure subscriptions in the resource tenant. This capability, initially an undocumented feature, challenges conventional security assumptions about the isolation and control of guest accounts.

Maxwell-Stewart, drawing from a real-world incident, meticulously dissects the underlying mechanisms of Azure identity, resource management, and billing. He demonstrates how this unexpected cross-tenant interaction can be weaponized to establish persistent backdoors, enumerate sensitive internal directory information, and ultimately facilitate privilege escalation to compromise high-privileged accounts like Global Admins through sophisticated phishing techniques combined with device identity manipulation. The presentation serves as a stark reminder for defenders to reassess their B2B guest threat models and actively harden default Azure configurations.

The significance of this research lies in its exposure of an unintuitive interaction between Azure's billing and identity systems, leading to a powerful initial access and persistence method. By exploiting default configurations and the inherent trust model of B2B collaboration, attackers can bypass traditional RBAC and directory role-based defenses. This talk is crucial for cloud security professionals, red teamers, and anyone responsible for securing Azure environments, providing both a deep technical understanding of the vulnerability and actionable recommendations for mitigation.

Background

▶ Watch: The core mystery: Guest creates Azure subscription (0:43)

The genesis of this discovery began with a perplexing incident: a B2B guest user was found to be the owner of an Azure subscription in a partner's tenant, despite having no apparent group memberships, directory roles, or RBAC assignments. This mystery sparked an investigation into the intricacies of Azure's identity and resource management systems.

At its core, Azure relies on Entra ID (formerly Azure Active Directory) as its primary identity provider. This directory manages various security principals, including human identities (users and B2B guests), service principals (representing applications or services), and devices. These principals authenticate against Entra ID and are then authorized to access resources based on assigned roles. For users and guests, these roles can be RBAC roles (over Azure resources), directory roles (over Entra ID itself), or app roles (over specific APIs).

Azure resources, such as Virtual Machines (VMs), databases, and networks, are organized into resource groups, which are then logically contained within subscriptions. Subscriptions are intended to act as a security boundary. Above subscriptions, management groups provide a hierarchical structure, with a single root management group at the very top. Crucially, this root management group forms the link between Azure resources and Entra ID, allowing RBAC roles assigned at this level to propagate down to all subscriptions within the hierarchy.

B2B guests are external users invited into an organization's Entra ID tenant (the resource tenant) from another directory (their home tenant). They are typically used for cost-saving measures, as the home tenant pays for the user. Guests authenticate against their home directory, receiving an ID token that allows them to federate into the resource tenant. Due to this external authentication, guests are generally designed to have fewer default privileges than regular users, making the initial discovery of a guest owning a subscription particularly alarming.

The missing piece of the puzzle involved billing agreements. Azure billing can be structured under various agreements, primarily Enterprise Agreements (EA) (legacy) and Microsoft Customer Agreements (MCA) (newer). These agreements define a hierarchy for managing billing accounts, profiles, and invoice sections. Critically, specific billing roles within these agreements (e.g., Owner or Contributor for MCA, Administrator for EA) grant the ability to create new subscriptions. The core undocumented behavior discovered was that these billing roles operate across tenant boundaries. An individual with a sufficient billing role in their home tenant can create a new Azure subscription and choose to place it within any resource tenant where they exist as a B2B guest. This newly created subscription automatically assigns the guest user as its owner, effectively bypassing all traditional RBAC and directory role checks within the resource tenant.

Key Findings

▶ Watch: Talk outline: Undocumented behavior and abuse potential (1:48)

The central discovery of this research is the cross-tenant subscription creation capability leveraged by B2B guest users. Specifically, a B2B guest, even one with no explicit RBAC roles, directory roles, or group memberships in the target resource tenant, can create and own a new Azure subscription within that tenant if they possess a sufficient billing role (e.g., Billing Account Owner, Invoice Section Owner) in their home tenant. This capability stems from the design of Azure's billing system, which allows billing administrators to select the target directory for a new subscription. Upon creation, the guest user is automatically granted the Owner RBAC role over this new subscription within the resource tenant.

Microsoft, when initially contacted, confirmed this behavior as an intended feature, asserting that subscriptions are a security boundary in Azure. However, they later acknowledged the existence of controls to prevent this. This highlights a significant gap in the understanding of the B2B guest threat model, as this behavior was unexpected by frontline defenders and administrators.

The vulnerability is exacerbated by several default configurations:

1. Default Guest Invitation Policy: By default, regular users and even other guests can invite new guest users into a directory. This means an attacker can easily invite their own "billing admin" guest account into a target tenant, creating a reliable attack vector.
2. Default Subscription Creation Policy: Azure's default setting for subscription creation allows "everyone" to create subscriptions, including guests who gain this privilege via the cross-tenant billing mechanism. This policy is a critical hardening point.

Once a guest owns a subscription, even if it's initially empty, they gain significant capabilities:

• Internal Principal Enumeration: The "Access control (IAM)" blade of the newly owned subscription reveals other security principals (users, service principals) who have inherited RBAC roles from the root management group of the resource tenant. This allows the attacker to discover high-privileged accounts, such as Global Admins or User Access Administrators, who might have broad access across the tenant. While a partial defense exists (restricting guest access to directory objects), it only prevents the Graph API lookup for full details, still allowing the attacker to retrieve principal IDs via the Management API.
• Device Identity Persistence: The subscription owner can create Azure Virtual Machines (VMs) within their subscription and join these VMs to the target Entra ID directory. These Entra ID joined devices are issued Primary Refresh Tokens (PRTs) when a user logs in. PRTs are highly valuable as they grant long-lived (up to 90 days) Single Sign-On (SSO) access to all OAUTH resources in Azure. Attackers can configure these VMs without Trusted Platform Module (TPM) protections and gain local administrator access, enabling the theft of PRTs and device identity certificates. These device identities persist even if the VM is deleted, serving as a stealthy backdoor.
• Privilege Escalation via Phishing: By combining enumerated internal admin accounts with stolen device identity certificates, attackers can perform sophisticated device code phishing attacks. This technique exploits legitimate OAUTH2 flows to trick an admin into authenticating, allowing the attacker to capture a refresh token. This refresh token, combined with the attacker's device identity certificate, can then be upgraded into a full-blown PRT for the admin, granting high-level access.
• Evasive Persistence with Managed Identities: To achieve stealthier persistence, the attacker can create a managed identity (represented as a service principal) within their owned subscription. This managed identity can be assigned the Owner role over the subscription. By adding federated credentials to this service principal, the attacker can establish an attacker-controlled OpenID Connect (OIDC) provider (e.g., using road OIDC). This allows the attacker to authenticate as the service principal without MFA. The original guest account can then be deleted, effectively making the attacker disappear from the directory while retaining full control via the service principal.

These findings collectively demonstrate a potent attack chain that leverages default, often misunderstood, Azure behaviors to achieve initial access, enumeration, persistence, and privilege escalation, bypassing many traditional security controls.

Technical Deep Dive

▶ Watch: Azure basics: Entra ID, security principals, resources (2:19)

The attack chain presented by Simon Maxwell-Stewart exploits the intricate interplay between Azure's identity, resource, and billing management systems. Understanding the technical nuances is crucial for both red teamers aiming to replicate the attack and defenders seeking to fortify their environments.

The initial foothold relies on the cross-tenant billing role privilege escalation. When an organization invites an external user as a B2B guest into their Entra ID tenant (the resource tenant), that guest typically authenticates against their home tenant's directory. This federation process gives the guest a limited identity within the resource tenant. However, if this guest user also holds a powerful billing role in their home tenant (e.g., Billing Account Owner under a Microsoft Customer Agreement (MCA) or Administrator under an Enterprise Agreement (EA)), they gain the ability to create Azure subscriptions. Crucially, when creating a subscription through the Azure portal or API, the billing administrator is presented with an option to select which Entra ID directory the new subscription should reside in. An attacker, as a billing admin in their home tenant, can simply choose the victim's resource tenant from this dropdown. The moment the subscription is provisioned, the guest account is automatically assigned the Owner RBAC role over this new subscription. This bypasses the typical permission checks within the resource tenant, as the creation logic is tied to the billing agreement, not the target directory's RBAC policies.

Once the attacker-controlled guest account owns a subscription, the next phase involves enumeration of internal security principals. While the newly created subscription is initially empty of resources, the attacker can navigate to the "Access control (IAM)" blade. Here, they observe a list of other security principals (users, service principals) who have inherited RBAC roles, often at the Contributor or User Access Administrator level, from the root management group of the resource tenant. This inheritance is common in well-managed Azure environments, where broad administrative roles are assigned at the top of the management group hierarchy to ensure consistent access. This effectively leaks the principal IDs of potentially high-privileged internal users and service principals.

The mechanism behind this enumeration involves two distinct API calls:

1. Management API: When querying role assignments on the subscription, the Azure portal first makes a call to the Azure Resource Manager (ARM) Management API. This API returns a list of principal IDs and their principal types (e.g., User, Group, ServicePrincipal) that have roles assigned at that scope or inherited from higher scopes.
2. Graph API: To enrich this information with human-readable details like display names, email addresses, or User Principal Names (UPNs), a subsequent call is made to the Microsoft Graph API, using the principal IDs obtained from the Management API.

A partial defense exists in the Guest user access level setting within Entra ID's external collaboration settings. Setting this to "Guest user access is restricted to properties and memberships of their own directory objects" can prevent the Graph API lookup from returning detailed information about other users. However, it does not prevent the initial Management API call, meaning the attacker can still reliably obtain the principal IDs of internal users, even if their full names or email addresses are obscured. This still provides valuable identifiers for subsequent attacks.

The attack then pivots to persistence and privilege escalation using device identities and Primary Refresh Tokens (PRTs). A PRT is a long-lived (up to 90 days) token issued to devices joined to Entra ID, enabling Single Sign-On (SSO) to all OAUTH resources within Azure. As a subscription owner, the attacker can provision an Azure VM. To facilitate PRT theft, this VM is configured as a Generation 1 virtual machine with standard security type, which lacks Trusted Platform Module (TPM) protections. The attacker, having local administrator access to this VM (because they created it), can then join the VM to the victim's Entra ID tenant. This can be achieved either by leveraging Azure AD-based Windows login (if the attacker assigns the Virtual Machine User Login RBAC role to their target admin on this VM) or by manually executing the dsregcmd /join command after adding a managed identity to the VM and adjusting registry settings. Once the VM is joined, any user logging into it with their Entra ID credentials will be issued a PRT, which can then be harvested by the attacker from the compromised VM. These device identities persist in Entra ID even if the underlying VM resource is deleted, creating a durable backdoor.

The final stage of privilege escalation involves combining these device identities with device code phishing. The attacker, having enumerated internal admin principal IDs, can target these individuals. Device code authentication is a legitimate OAUTH2 flow designed for input-constrained devices (e.g., CLI tools). An attacker initiates a device code flow on a compromised device (e.g., their evil VM or a local machine with a stolen device identity certificate). This generates a code and a URL that the user must visit on another device to complete authentication. Phishing kits (e.g., rotx or more sophisticated ones on GitHub) can present a convincing lure to an unsuspecting administrator, tricking them into entering the code. Upon successful authentication, a refresh token is sent to the attacker's device. This refresh token, when combined with the previously stolen device identity certificate (a technique pioneered by Durkan), can be upgraded to a full-blown Primary Refresh Token (PRT) for the victim administrator. With an admin's PRT, the attacker gains powerful SSO capabilities, potentially reaching Global Administrator privileges across the entire Azure environment.

For even stealthier and more resilient persistence, the talk introduces the concept of managed identities with federated credentials. Within their owned subscription, the attacker can create a user-assigned managed identity. This managed identity is represented as a service principal in Entra ID. The attacker then assigns this service principal the Owner RBAC role over the subscription. To authenticate as this service principal without traditional secrets, the attacker can add federated credentials to it. This involves setting up an attacker-controlled OpenID Connect (OIDC) provider (e.g., using the road OIDC tool). The service principal is configured to trust this OIDC provider, allowing the attacker to mint tokens and authenticate as the service principal. A key advantage here is that service principals are not subject to MFA protections or other user-centric privilege escalation controls. Once this persistent backdoor is established, the original guest account can be safely removed from the resource tenant using the "Remove me from this directory" option, effectively erasing the attacker's trace as a guest while maintaining full control over the owned subscription via the managed identity.

Demo / Proof of Concept

▶ Watch: Understanding B2B guests and cost-saving measures (4:38)

Simon Maxwell-Stewart demonstrated the practical application of these attack techniques through a custom-built offensive toolkit, which he made available on GitHub. This toolkit streamlines several steps of the attack chain, making it accessible for red teamers and security researchers.

The demonstration highlighted key commands and their outcomes:

1. Subscription Creation: The toolkit includes a command to create subscription. This command automates the process of interacting with management.azure.com to identify available billing profiles and invoice sections. The attacker then selects an invoice section, and the tool proceeds to create a new Azure subscription within the target Entra ID directory, automatically assigning the guest user as its owner. The output clearly showed the successful creation of a subscription, confirming the core vulnerability.

1. Evil VM Creation: Another critical command is create evil VM. This command is designed to provision an Azure Virtual Machine specifically tailored for PRT theft. It ensures the VM is a Generation 1 virtual machine with a standard security type, deliberately avoiding the more advanced security features like TPM that would protect PRTs. The VM is given a deceptive name, such as "bastion VM," to appear legitimate to defenders. This VM serves as the platform for joining to Entra ID and subsequently harvesting PRTs.

Beyond these core demonstrations, the toolkit offers other valuable functionalities:

• list tenants: Helps in identifying target directories.
• invite users: This is particularly useful for red teamers. If the attacker's guest user account doesn't have a legitimate email address for receiving invitation links, this command directly outputs the invitation URL. This bypasses the need for an active email inbox, simplifying the process of inviting the billing admin guest into the target tenant.
• security assessment: While the attacker might not have privileges to run a formal security assessment in the target tenant, the toolkit's approach is pragmatic: simply try various commands and observe what works and what doesn't to infer the security posture.
• A suite of commands for interacting with subscriptions, further emphasizing the control gained by the guest owner.

The toolkit serves as a robust proof-of-concept, illustrating how these complex, multi-stage attacks can be executed with relative ease using specialized tooling. It underscores the practical viability of the "Restless Guests" attack methodology.

Defensive Implications

▶ Watch: Introduction to less understood billing agreements (6:24)

The "Restless Guests" attack exposes significant vulnerabilities arising from insecure default configurations and a lack of understanding regarding cross-tenant billing interactions. For defenders, prevention is paramount, as detecting these sophisticated, multi-stage attacks can be challenging, especially once evasion techniques are employed.

Key Prevention Policies:

1. Subscription Creation Policy: This is the most critical control. Azure's default setting for "Subscription policies" allows "everyone" to create subscriptions. This must be changed. Navigate to Cost Management + Billing > Subscription policies and set "Allow users to create subscriptions" to "Permit to no one." This directly prevents guest users from leveraging their billing roles to create subscriptions in your directory.
2. Guest Invite Policy: The ability for any user or even another guest to invite external users is a significant enabler for this attack. To mitigate this:

• Go to Entra ID > External Identities > External collaboration settings.
• Under "Guest invite settings," change "Guests can invite" to "No."
• Consider setting "Members can invite" to "No" or "Only users assigned to a specific admin role can invite guest users." This restricts who can bring the "billing admin" guest into your tenant.

1. Guest User Access Level: While only a partial defense, restricting guest access to directory objects makes enumeration harder.

• In Entra ID > External Identities > External collaboration settings, set "Guest user access restrictions" to "Guest user access is restricted to properties and memberships of their own directory objects." This prevents the Graph API lookup from revealing full details of internal principals, although their principal IDs will still be visible via the Management API.

Other Crucial Controls:

• Harden External Collaboration Settings: Generally, review all settings under Entra ID > External Identities > External collaboration settings and configure them to the most restrictive options possible based on your organization's needs.
• MFA for Guests: Implement Conditional Access Policies to enforce Multi-Factor Authentication (MFA) for all guest users. While not directly preventing subscription creation, it adds a layer of security if a guest account is compromised and attempts to leverage its existing access.
• Monitor Guest-Owned Subscriptions: Regularly audit for any subscriptions where a guest user is listed as an owner. While evasion techniques (like deleting the guest account after establishing persistence) can bypass this, it's a vital initial detection mechanism. Microsoft Defender for Cloud does generate alerts for guest owners, so these should be actively monitored and investigated. Be aware that an attacker who is the guest owner might attempt to silence or waive these alerts.
• Conditional Access Policies based on Device Attributes: Implement policies that leverage device attributes for conditional access. Attackers control the naming of their "evil VMs" (e.g., "Corp Prod Bastion"), which could be used to influence or bypass less granular conditional access policies. Ensure policies are robust and not easily fooled by arbitrary device names.
• Harden Root Management Group Policies: Review and restrict RBAC role assignments at the root management group level. Overly permissive roles (e.g., broad Contributor or User Access Administrator) assigned at this level allow attackers to enumerate high-privileged internal users once they own a subscription. Grant roles with the principle of least privilege.
• Audit Devices: Regularly audit Entra ID for joined devices. Look for suspicious device registrations, especially those not managed by Intune or other Mobile Device Management (MDM) solutions. Device identities persist even if the underlying VM is deleted, making them stealthy backdoors.
• Understand Guest User Lifecycle: While allowing external users to leave the directory (via "Allow external users to leave this organization") aids in cleanup, defenders must be aware that a guest user might disappear from the directory after establishing persistence through other means (like managed identities with federated credentials). This means a disappearing guest doesn't necessarily mean the threat is gone.

In summary, the core defense strategy revolves around preventing the initial subscription creation by guests, controlling guest invitation mechanisms, and then layering additional security controls like MFA, robust monitoring, and stringent RBAC at the management group level. Hardening these default configurations is critical to securing Azure environments against the "Restless Guests" attack.

Key Takeaways

• B2B Guest Threat Model is Underestimated: The interaction between Azure's billing and identity systems creates an unintuitive attack vector where B2B guests, even with minimal explicit permissions in a resource tenant, can gain significant control.
• Azure Defaults are Insecure: Key default configurations, such as allowing "everyone" to create subscriptions and permitting users to invite guests, significantly lower the security posture and enable the attack chain.
• Cross-Tenant Billing Roles are Powerful: A guest's billing role in their home tenant can grant them the ability to create and own subscriptions in a target resource tenant, bypassing traditional RBAC controls.
• Stealthy Persistence and Escalation: Attackers can leverage newly owned subscriptions to enumerate internal directory objects, establish persistent backdoors via Entra ID joined devices and Primary Refresh Tokens (PRTs), and escalate privileges through targeted device code phishing against high-value admin accounts.
• Evasive Backdoors via Managed Identities: For ultimate stealth, attackers can transition from a guest account to a managed identity (service principal) with federated credentials, delete the original guest, and maintain persistent, MFA-less access.
• Hardening Works, But Requires Proactive Configuration: While the defaults are problematic, Azure provides specific policy controls (subscription creation, guest invite, guest access level) that, if proactively configured, can effectively prevent or significantly mitigate these attack techniques.

About the Speaker(s)

Simon Maxwell-Stewart is a cybersecurity professional with a unique background. He initially graduated with a degree in physics before transitioning into the fields of traditional software engineering and data engineering. For the past several years, he has dedicated his expertise to cybersecurity, a domain he expresses great passion for. Maxwell-Stewart describes himself as a "graph nerd," indicating a strong inclination towards visualizing and analyzing complex relationships, particularly evident in the graph diagrams used throughout his presentation. His work with various partners provided the real-world context and initial mystery that led to the in-depth research presented in "Restless Guests."