How Guest Accounts in Entra ID Can Become Subscription Owners

TLDR: A critical misconfiguration in Azure allows guest users to create new subscriptions and gain owner-level privileges within them, even without explicit directory roles. By leveraging billing role assignments and guest federation, an attacker can pivot from a low-privileged guest to a subscription owner, enabling them to attach managed identities to virtual machines for persistence. Security teams must audit billing role assignments and enforce the most restrictive external collaboration settings to prevent this escalation path.

Cloud environments are often treated as monolithic security boundaries, but the reality is far more fragmented. When we look at Microsoft Entra ID, the complexity of managing identities across tenants creates gaps that attackers are actively exploring. One of the most overlooked vectors is the interaction between guest user federation and Azure billing agreements. If you are performing a cloud assessment, you need to look beyond standard RBAC roles and start auditing the billing hierarchy.

The Mechanics of the Escalation

The core of this issue lies in how Azure handles subscription creation. A subscription is a logical container for resources, but it is also a security boundary. When a user is invited into a tenant as a guest, they are typically restricted by the lack of directory roles or group memberships. However, if that guest user is assigned a billing role—such as a contributor or owner on a billing profile—they gain the ability to create new subscriptions within that tenant.

The vulnerability is not a bug in the traditional sense but a design choice in how billing roles are applied. When a guest user creates a subscription, they are automatically granted the owner role on that new subscription. This is the pivot point. Once the attacker owns the subscription, they have full control over the resources within it. They can deploy virtual machines, configure networking, and, most importantly, attach managed identities to those resources.

Persistence via Managed Identities

Managed identities are the gold standard for cloud persistence. By attaching a system-assigned managed identity to a virtual machine within the newly created subscription, an attacker can effectively create a service principal that exists within the directory. This service principal can then be granted permissions, or it can be used to authenticate against other Azure services if the environment is misconfigured.

To see if a machine is joined to the directory, you can use the dsregcmd tool. If you find a machine that is joined to the tenant, you are looking at a potential persistence mechanism. The attacker does not need to compromise a high-privileged user account; they only need to compromise a guest account that has been granted a billing role. This is a classic example of Broken Access Control, where the separation between billing administration and resource management is not as robust as it appears.

Real-World Engagement Strategy

During a penetration test, your first step should be to enumerate the billing roles assigned to guest accounts. Do not assume that because a user is a guest, they have no power. Check the billing accounts, billing profiles, and invoice sections. If you find a guest user with any billing role, you have a path to subscription ownership.

Once you have created a subscription, you are the king of that container. You can spin up resources to test the environment's monitoring capabilities. Most security operations centers are tuned to look for suspicious activity in production subscriptions, but they often ignore new, empty subscriptions created by "authorized" users. This is where you can hide your persistence. You can also use this to test the effectiveness of Conditional Access policies. If you can join a device to the directory, you can test whether your device-based access rules are actually blocking unauthorized machines.

Hardening the Environment

Defending against this requires a shift in how you manage external collaboration. The default settings in Entra ID are often too permissive. You should navigate to the External Identities settings and ensure that guest user access is set to the most restrictive option. This prevents guests from enumerating directory objects, which is a prerequisite for many of these attacks.

Furthermore, you must audit who has billing roles. These roles should be treated with the same level of scrutiny as Global Administrator roles. If a user does not need to manage billing, remove their access. You can also use Azure Policy to restrict the creation of subscriptions to specific users or groups. By limiting who can create subscriptions, you eliminate the possibility of a guest user escalating their privileges through this billing-based path.

Finally, keep an eye on your security alerts. Microsoft has introduced specific alerts for when a guest user creates a subscription. If you see these in your logs, investigate them immediately. It is rarely a legitimate business activity for a guest to be provisioning new infrastructure. Treat every subscription creation event as a potential indicator of compromise until proven otherwise. The cloud is only as secure as the weakest link in your identity chain, and right now, that link is often the guest user you invited to help with a project six months ago.