Restless Guests: The True Entra B2B Guest Threat Model

Azure resources are logically isolated into subscriptions, and users inside Entra can also be assigned RBAC roles that allow them to administer the resources inside a particular subscription.

However, there’s an entirely parallel set of lesser-known permissions that relate to billing management and subscription creation. When considering best practices for locking down Entra ID or performing an Azure threat model, the focus is generally on administrative permissions, not billing permissions. This is especially true when thinking about restricting external guest accounts.

The available Azure Enterprise Agreement roles are as follows. EA billing roles can only be assigned to individual user accounts. A large percentage of the billing roles can create subscriptions, shown below:

The EA/MCA billing roles are assigned at the billing account level, which exists separately from the Entra directory. Because billing roles permit subscription creation, they also allow the user to create and transfer subscriptions into a tenant where they are merely a guest. This becomes particularly problematic when the two tenants are not controlled by the same organization, which is the most common use case for B2B guest accounts.

BeyondTrust researchers also validated that the Owner assignment over a subscription allows a guest to transfer these subscriptions into the tenant they are invited into, while retaining ownership over the subscription.

To recap, if you invite an external guest account into your organization’s Entra tenant, and that account holds an EA or MCA billing role or owns a subscription their home tenant, they can transfer subscriptions into your tenant, all while retaining ownership over them. This is true for external guest users who exist in pay-as-you-go Azure tenants that an attacker could spin up in just a few minutes.

Now, let’s invite our “attacker” account into our “defender” Entra tenant as a guest user. While in this case we are using an attacker-created tenant, this could also occur if a third-party tenant with guest accounts in your environment were compromised.

"Simon” is invited as a B2B guest user by our separate “defender” tenant, which represents a separate organization outside of the attacker’s control. You can see that our Simon external guest account has no group memberships, roles, or applications assigned to it.

It is also important to point out that the value of the identities field is “MicrosoftAccount”, which means the user is federating into this guest tenant from an existing Microsoft account. The same attack works when the value of the identities field is “ExternalAzureAD”, which means the guest user is federating from another AzureAD tenant.

Because “Simon” is a Billing Owner of the billing account associated with their home tenant, the attacker can create subscriptions in the tenant they’re a guest in using the standard Azure Portal UI. When creating a subscription for their home directory, under the advanced settings, they have the option to choose any tenant they are a part of.

We can now see the new, attacker-controlled subscription created, and that the attacker has the Owner role in this subscription.

We believe that this represents an interesting reconnaissance technique. Most Azure administrators wouldn’t expect an unprivileged guest in their Entra ID directory to be able to enumerate privileged users at all. But through the subscription-creation attack, that visibility becomes possible.

Scenario 2: Weakening Azure Policy

By default, all subscriptions (and their resources) are governed by Azure policies that are designed to enforce security standards and trigger alerts when violations occur. For example, policies may generate alerts when virtual machines are configured with weak security settings or run known malicious tools inside the tenant.

However, when a guest becomes a subscription Owner, they have full write permissions to all policies that apply to their subscription. This means the attacker can modify or disable the policies applied to their subscription, effectively muting security alerts that would otherwise notify defenders of suspicious or non-compliant activity.

This control gap allows the attacker to operate within a rogue subscription with reduced visibility from security monitoring tools. From this foothold, they can perform malicious activities or target external systems—all while remaining under the radar. This is very useful for some of the other techniques listed below.

Scenario 3: Creating User-Managed Identities

A guest user with subscription Owner permissions can create a User-Managed Identity within their subscription. Managed Identities are typically used to assign identities to Azure resources for service-to-service authentication, allowing them to act as security principals with assigned roles and permissions.

This becomes a powerful attack vector because creating a Managed Identity also creates a service principal identity in the shared Entra ID directory (referred to as an “enterprise application” in the UI). That means the guest user—through their subscription—has introduced a new identity into the tenant directory itself, extending their influence beyond the boundaries of the subscription.

Notably, the lifecycle of this service principal is not strictly tied to the attacker subscription. With the right permissions, it could interact with other subscriptions or the Entra directory directly.

To escalate further, the attacker can also assign this Managed Identity as the Owner of the previously made guest subscription. This means the managed identity gets to retain all privilege the guest user originally had, giving the attacker a durable foothold in the environment, independent of their guest account. This kind of identity pivoting is a common persistence technique, allowing the attacker to hide in plain sight, away from the guest account.

Going further, the attacker can deepen that persistence using a known attack perimeter: adding federated credentials to the Managed Identity. These credentials can allow external actors or systems to authenticate as the identity, even after the original guest account is removed.

Another reason the managed identity creation technique is so appealing to attackers is the API permission model. Service principals often require API Permissions to perform actions in the directory—but API permissions don’t benefit from the same privilege escalation protections that limit directory roles. Practically speaking, this service principal is a single misconfiguration away from obtaining a privileged directory role. One accidental API permission assignment like “RoleManagement.ReadWrite.Directory” to Microsoft Graph would be enough to grant Global Administrator-level control.

The good news for defenders: by default, service principals are locked down and have no real access unless explicitly granted. However, attackers could exploit this by launching targeted API permission phishing attacks, tricking legitimate admins into granting this managed identity elevated privileges. The service principal would appear like a legitimate Enterprise Application, and it would not be immediately apparent that a rogue guest is in control of it.

Scenario 4: Tenant-Joined Devices

Guest users with subscription Owner permissions can also create Azure resources that appear as “joined” devices in the Entra ID tenant. One technique involves creating a Virtual Machine (VM) and enabling the “Azure AD-based Windows Login” VM extension during setup.

Figure 15 shows a VM extension for Entra ID based Windows Login

When configured this way, the VM is automatically registered as a “device principal” in Entra ID > Devices.

While we will demonstrate how an attacker is able to steal the private certificate of a device like this in a future blog, it’s important to note that this attack path potentially allows for the abuse of conditional access policies. As detailed by this article: Stealing and faking Azure AD device identities, attackers may be able to exfiltrate the private certificate used to authenticate the device, granting them trusted access under the guise of a legitimate machine.

Conditional access policies often depend on device trust, which can be established by dynamic groups. For example, an organization might configure dynamic groups like “Windows Workstations” or “VPN Machines” with membership rules, such as:

(device.displayName -startsWith “WORKSTATION”) and (device.image -eq “windows 10”)

Because the attacker controls many properties of the device, like it’s display name and operating system, they can use prior knowledge or simply experiment with different VM configurations to brute force membership into trusted groups. If successful, this may allow the attacker to abuse Conditional Access Policies and gain unauthorized access to trusted assets.

This represents a device-based variant of a known dynamic group exploit previously seen in user object targeting. BeyondTrust’s Identity Security Insights® product helps to uncover many such misconfigured dynamic groups that unintentionally expose hidden Paths to Privilege™. Organizations should be careful with these kinds of setups.

In addition to enabling this policy, we recommend the following actions:

• Audit all guest accounts in your environment and remove those that are no longer required

• Harden guest controls as much as possible: for instance, disable guest-to-guest invitations

• Monitor all subscriptions in your tenant regularly to detect unexpected guest-created subscriptions and resources

• Monitor all Security Center alerts in the Azure Portal; some may appear even if the visibility is inconsistent

• Audit device access, especially if these utilize dynamic group rules.

To assist defenders, BeyondTrust Identity Security Insights provides built-in detections to flag subscriptions created by guest accounts, offering automated visibility into these unusual behaviors. To gain a snapshot of potential identity-based risks in your environment, including those introduced through guest access, BeyondTrust also offers a no-cost Identity Security Risk Assessment.

BeyondTrust Identity Security Insights customers can gain a holistic view of all identities across their entire identity fabric. This includes gaining a consolidated understanding of Entra guest accounts and their True Privilege™. We highly recommend customers of Insights regularly review Guest accounts that have high levels of true privilege.

Below is an example filter: