“Evil VM”: From Guest Compromise To Entra Admin In 9 Easy Steps

Devices gain an identity in the Entra directory either as "registered devices" (user-owned "bring-your-own-devices"), or "joined devices" (organization-owned). In both scenarios, Entra ID generates a unique device identity through a private/public certificate.

Beyond the certificate, a transport key adds an essential layer of security. This key encrypts sensitive data sent from Entra ID to the device, serving as a "proof of possession", since only the device holding the key can decrypt the content. Given their critical role in device identity and security, these certificates and keys are typically secured within a Trusted Platform Module (TPM). The TPM is a hardware security chip (or firmware module) found on Windows machines, designed specifically for the secure storage and management of cryptographic keys and secrets.

An aspect of device behavior that is especially important to attackers is how Entra ID will issue Primary Refresh Tokens to joined devices. So, let’s dive into PRTs next.

What Primary Refresh Tokens Are and Why They Matter in Entra ID

Primary Refresh Tokens (PRTs) are used for single sign-on (SSO) within Entra ID. They are issued to users logging in to Entra ID from a joined device. A PRT is initially valid for 14 days and can extend to 90 days with continuous renewal, provided the user remains active on the device. The core function of a PRT is to enable seamless SSO, allowing users to request subsequent refresh and access tokens for various Microsoft applications and services without re-authenticating. To protect these high-value tokens, it is highly recommended that you secure them using the TPM.

In the context of our previous Restless Guests research—where an Entra guest account can obtain ownership over a subscription—it appears possible to circumvent the device joining controls shown in Figure 1 and Figure 2. Virtual machines (VMs) created within this subscription can be configured without device protections, exposing key data and token material, such as device certificates, transport keys, and any PRTs that are issued to it.

Since the user can create a Windows VM, they can choose to provision it with the “Azure AD based Windows Login” extension. During deployment, this VM will be joined to Entra ID, as shown below in Figure 3. The extension’s purpose is to facilitate login to the VM using the user’s Entra ID credentials. Remote access to the VM can then be granted by assigning the user one of the following RBAC roles: “Virtual Machine User Login” or “Virtual Machine Administrator Login”.

Furthermore, guests have no out-of-the-box rights to register or join devices; only members can do either. However, as we just demonstrated, we can overcome this limitation using the Entra ID login extension. The full attack path then unfolds as follows:

Let’s go through each step in the process.

Step-by-Step: How the Evil VM Attack Reaches PRT Theft and Entra Admin

1) Compromise a Guest Account to Establish Initial Foothold in Entra ID

Let’s assume a threat actor compromises a B2B guest account within a target tenant. We’ll assume this guest has no role assignments, group memberships, or any access explicitly granted by the tenant’s administrators. Our subsequent lateral movement will rely solely on out-of-the-box privileges and default tenant controls, demonstrating a real-world Entra ID guest account takeover scenario.

It's worth pointing out that there are a few different ways we could establish a viable foothold:

• Compromise a user account
• Get invited into the target tenant
  

2) Invite a “Restless Guest” with Billing Permissions into the Target Tenant

To introduce a “restless guest” in the resource tenant we are attacking, a specific setup is required. Let’s create a user in a separate tenant that we, as the attacker, control (our home tenant). The easiest way to achieve this is to sign up for a Microsoft Account using a credit card. We’ll even get $200 worth of free credits! The account used for signing up will automatically become the billing owner, as it is directly linked to the credit card used for billing.

Next, we need to invite this billing owner into the tenant we intend to attack. Due to the permissive Entra ID invite defaults, we can use our initial compromised guest account to invite this billing owner into the target tenant. Consequently, we now have a guest user in the resource tenant we are attacking, who is also a billing account owner in their home tenant.

3) Use Guest Billing Rights to Create a Subscription in the Target Directory

While in our home tenant, we can create a subscription. By default, we are also allowed to transfer this subscription into the resource tenant where this user is a guest.

If performing this in the portal, when creating a subscription, we specify the ‘subscription directory’ dropdown under ‘Advanced’ as resource. Once this is done, our guest is now the proud owner of a subscription.

4) Provision an Evil VM Without TPM to Enable PRT Theft

Subscription owners are free to create any resources they like within their subscription, giving us full privileges to make an evil VM. The primary goal of this step is to gain local admin access to a VM without TPM protections. We want a VM without TPM protections to make stealing the PRT easy. We accomplish this by choosing a “Gen 1” with security type “Standard”.

Doing so in the portal looks something like this:

5) Join the VM to Entra ID to Generate a Device Identity for Lateral Movement

We will also ensure the VM becomes an Entra ID-joined device. This configuration means the VM will have its own identity, allowing it to authenticate against the directory.

In the portal, we can achieve this during the VM creation process, by navigating to the “Management” tab, and selecting “Login with Microsoft Entra ID”.

We will also enter local admin credentials for the machine and then hit create. Once the VM is deployed, we can run “dsregcmd /status” on it to check both its TPM protection and join status.

Interestingly, we can also join devices without necessarily installing this extension. This technique was first explored in this article. Decompiling the extension’s binary reveals that it is essentially a simple wrapper for dsregcmd.exe. We can manually attach our own Managed Identity, change some registry settings, and then call “dsregcmd.exe /AzureSecureVMJoin”.

6) Extract Device Certificates and Transport Keys to Create a Persistent Backdoor

Since we have local admin access on the VM, we can steal the device certificate. This device identity will persist even if the guest account, the VM itself, or the entire subscription is deleted. Once stolen, we can authenticate as this device identity on a completely different machine. Congratulations, we are the proud owner of a device backdoor.

We can achieve this with AADInternals-Endpoints:

7) Enumerate Entra ID Admin Accounts via IAM Role Inheritance

To successfully phish users, we will need their details, such as names and emails. Thankfully, we can often obtain admin details by inspecting our newly created subscription’s IAM role assignments. Any users who have a role at the root management group will automatically inherit those permissions into our guest-created subscription. This typically happens when Global Admins toggle a setting in Entra ID that grants them basic access to all subscriptions within the tenant.

In the portal we do this by simply inspecting the “Access Control (IAM)” tab of the subscription, and then looking at the “Role Assignments”.

8) Phish a User via Device Code Flow to Harvest a Full Primary Refresh Token (PRT)

Because we have a stolen device certificate, we can combine it with a special kind of refresh token and upgrade it to a PRT. This technique was first published by Dirk-jan Mollema. While we recommend reading the original article for a detailed understanding of the technique, at a high level, this is what we are doing:

• Starting a device code OAuth flow, requesting a refresh token for the enrollment.manage.microsoft.com resource with the Microsoft Authentication Broker client id.
• Phishing an admin to complete the device code flow, and gaining the resulting refresh token.
• Upgrading the refresh token by combining it with our previously stolen device certificate (only this particular client and resource refresh token allows for a PRT upgrade).
  

If you want to try the phishing step, it can be implemented using ROADtools:

Attackers are using this technique in the wild, succeeding, and making news on Microsoft’s own blog. In fact, there are phishing kits for red teamers that support this flow. So, assuming we land a successful phish, we simply upgrade our refresh token to a PRT by using ROADtools again:

9) Use the Stolen PRT to Authenticate as the Phished Admin in Entra ID

We can then use this PRT to gain access to any Azure service we like:

Congratulations; you are now global admin!

Step 1: Restrict Guest Invitations to Reduce Entra ID Privilege Escalation Risk

Allowing only specified users to invite guests into the directory drastically reduces the initial attack vector.

Step 2: Block Subscription Transfers to Stop Guest-to-Owner Escalation

Allowing only specified users to transfer subscriptions into the directory prevents any guest from utilizing their billing role permissions to become a subscription owner inside the directory.

Step 3 :Enforce TPM-Backed VM Policies to Reduce PRT Theft Risk

Block the creation of “Gen 1” VMs within any subscription attached to the directory. Gen 1 VMs lack TPM (Trusted Platform Module) protections, making it significantly easier for threat actors to extract certificates and secrets from the device.

Refer to the Azure policy for allowed VM SKUs and apply it at the root management group level.

Step 4: Detect Device Code Phishing and Suspicious Entra Device Creation

If business constraints mean guest controls in the prior steps can’t be put in place, defenders may need to resort to detections to catch restless guests that are moving laterally. This poses challenges because an attacker can evade detections by creating persistent federated access via a managed identity, as detailed by this article. After creating such a backdoor, guests can transfer the subscription ownership and evade the “Guest accounts with owner permissions on Azure Resources” displayed by Microsoft Defender for Cloud. Ironically as a subscription owner, attackers can manually silence these alerts as well.

Moreover, attackers could be sneaky and give ownership of the subscription / Azure resources to real admins (gaining the principal id using the enumeration technique above). This would go a long way to make a subscription and its resources appear legitimate; the attacker only needs ‘contributor’ level RBAC permission. Even then, an attacker could relinquish all RBAC privileges once they have local admin to an Evil VM. In this case, the following detection rules provide a best effort for detecting the full range of possible attacks:

• Guest or Managed Identities assigned an RBAC role of ‘Owner’ or ‘Contributor’ on Azure resources
• VMs that are created without TPM protections
• Device Identities that correspond to VMs identified by the previous rule
• Device code authentications from the Microsoft Authentication Broker client to the enrollment resource.