Effectively this means that with a token I requested in my lab tenant I could authenticate as any user, including Global Admins, in any other tenant. Because of the nature of these Actor tokens, they are not subject to security policies like Conditional Access, which means there was no setting that could have mitigated this for specific hardened tenants. Since the Azure AD Graph API is an older API for managing the core Azure AD / Entra ID service, access to this API could have been used to make any modification in the tenant that Global Admins can do, including taking over or creating new identities and granting them any permission in the tenant. With these compromised identities the access could also be extended to Microsoft 365 and Azure.

I reported this vulnerability the same day to the Microsoft Security Response Center (MSRC). Microsoft fixed this vulnerability on their side within days of the report being submitted and has rolled out further mitigations that block applications from requesting these Actor tokens for the Azure AD Graph API. Microsoft also issued CVE-2025-55241 for this vulnerability.

Impact

These tokens allowed full access to the Azure AD Graph API in any tenant. Requesting Actor tokens does not generate logs. Even if it did they would be generated in my tenant instead of in the victim tenant, which means there is no record of the existence of these tokens.

Furthermore, the Azure AD Graph API does not have API level logging. Its successor, the Microsoft Graph, does have this logging, but for the Azure AD Graph this telemetry source is still in a very limited preview and I’m not aware of any tenant that currently has this available. Since there is no API level logging, it means the following Entra ID data could be accessed without any traces:

• User information including all their personal details stored in Entra ID.
• Group and role information.
• Tenant settings and (Conditional Access) policies.
• Applications, Service Principals, and any application permission assignment.
• Device information and BitLocker keys synced to Entra ID.

This information could be accessed by impersonating a regular user in the victim tenant. If you want to know the full impact, my tool roadrecon uses the same API, if you run it then everything you find in the GUI of the tool could have been accessed and modified by an attacker abusing this flaw.

If a Global Admin was impersonated, it would also be possible to modify any of the above objects and settings. This would result in full tenant compromise with access to any service that uses Entra ID for authentication, such as SharePoint Online and Exchange Online. It would also provide full access to any resource hosted in Azure, since these resources are controlled from the tenant level and Global Admins can grant themselves rights on Azure subscriptions. Modifying objects in the tenant does (usually) result in audit logs being generated. That means that while theoretically all data in Microsoft 365 could have been compromised, doing anything other than reading the directory information would leave audit logs that could alert defenders, though without knowledge of the specific artifacts that modifications with these Actor tokens generate, it would appear as if a legitimate Global Admin performed the actions.

Based on Microsoft’s internal telemetry, they did not detect any abuse of this vulnerability. If you want to search for possible abuse artifacts in your own environment, a KQL detection is included at the end of this post.

Technical details

Actor tokens

Actor tokens are tokens that are issued by the “Access Control Service”. I don’t know the exact origins of this service, but it appears to be a legacy service that is used for authentication with SharePoint applications and also seems to be used by Microsoft internally. I came across this service while investigating hybrid Exchange setups. These hybrid setups used to provision a certificate credential on the Exchange Online Service Principal (SP) in the tenant, with which it can perform authentication. These hybrid attacks were the topic of some talks I did this summer, the slides are on the talks page. In this case the hybrid part is not relevant, as in my lab I could also have added a credential on the Exchange Online SP without the complete hybrid setup. Exchange is not the only app which can do this, but since I found this in Exchange we will keep talking about these tokens in the context of Exchange.

Exchange will request Actor tokens when it wants to communicate with other services on behalf of a user. The Actor token allows it to “act” as another user in the tenant when talking to Exchange Online, SharePoint and as it turns out the Azure AD Graph. The Actor token (a JSON Web Token / JWT) looks as follows when decoded:

{
    "alg": "RS256",
    "kid": "_jNwjeSnvTTK8XEdr5QUPkBRLLo",
    "typ": "JWT",
    "x5t": "_jNwjeSnvTTK8XEdr5QUPkBRLLo"
}
{
    "aud": "00000002-0000-0000-c000-000000000000/graph.windows.net@6287f28f-4f7f-4322-9651-a8697d8fe1bc",
    "exp": 1752593816,
    "iat": 1752507116,
    "identityprovider": "00000001-0000-0000-c000-000000000000@6287f28f-4f7f-4322-9651-a8697d8fe1bc",
    "iss": "00000001-0000-0000-c000-000000000000@6287f28f-4f7f-4322-9651-a8697d8fe1bc",
    "nameid": "00000002-0000-0ff1-ce00-000000000000@6287f28f-4f7f-4322-9651-a8697d8fe1bc",
    "nbf": 1752507116,
    "oid": "a761cbb2-fbb6-4c80-aa50-504962316eb2",
    "rh": "1.AXQAj_KHYn9PIkOWUahpfY_hvAIAAAAAAAAAwAAAAAAAAACtAQB0AA.",
    "sub": "a761cbb2-fbb6-4c80-aa50-504962316eb2",
    "trustedfordelegation": "true",
    "xms_spcu": "true"
}.[signature from Entra ID]

There are a few fields here that differ from regular Entra ID access tokens:

• The aud field contains the GUID of the Azure AD Graph API, as well as the URL graph.windows.net and the tenant it was issued to 6287f28f-4f7f-4322-9651-a8697d8fe1bc.
• The expiry is exactly 24 hours after the token was issued.
• The iss contains the GUID of the Entra ID token service itself, called “Azure ESTS Service”, and again the tenant GUID where it was issued.
• The token contains the claim trustedfordelegation, which is True in this case, meaning we can use this token to impersonate other identities. Many Microsoft apps could request such tokens. Non-Microsoft apps requesting an Actor token would receive a token with this field set to False instead.

When using this Actor token, Exchange would embed this in an unsigned JWT that is then sent to the resource provider, in this case the Azure AD graph. In the rest of the blog I call these impersonation tokens since they are used to impersonate users.

{
    "alg": "none",
    "typ": "JWT"
}
{
    "actortoken": "eyJ0eXAiOiJKV1Qi<snip>TxeLkNB8v2rWWMLGpaAaFJlhA",
    "aud": "00000002-0000-0000-c000-000000000000/graph.windows.net@6287f28f-4f7f-4322-9651-a8697d8fe1bc",
    "exp": 1756926566,
    "iat": 1756926266,
    "iss": "00000002-0000-0ff1-ce00-000000000000@6287f28f-4f7f-4322-9651-a8697d8fe1bc",
    "nameid": "10032001E2CBE43B",
    "nbf": 1756926266,
    "nii": "urn:federation:MicrosoftOnline",
    "sip": "doesnt@matter.com",
    "smtp": "doesnt@matter.com",
    "upn": "doesnt@matter.com"
}.[no signature]

The sip, smtp, upn fields are used when accessing resources in Exchange online or SharePoint, but are ignored when talking to the Azure AD Graph, which only cares about the nameid. This nameid originates from an attribute of the user that is called the netId on the Azure AD Graph. You will also see it reflected in tokens issued to users, in the puid claim, which stands for Passport UID. I believe these identifiers are an artifact from the original codebase which Microsoft used for its Microsoft Accounts (consumer accounts or MSA). They are still used in Entra ID, for example to map guest users to the original identity in their home tenant.

As I mentioned before, these impersonation tokens are not signed. That means that once Exchange has an Actor token, it can use the one Actor token to impersonate anyone against the target service it was requested for, for 24 hours. In my personal opinion, this whole Actor token design is something that never should have existed. It lacks almost every security control that you would want:

• There are no logs when Actor tokens are issued.
• Since these services can craft the unsigned impersonation tokens without talking to Entra ID, there are also no logs when they are created or used.
• They cannot be revoked within their 24 hours validity.
• They completely bypass any restrictions configured in Conditional Access.
• We have to rely on logging from the resource provider to even know these tokens were used in the tenant.

Microsoft uses these tokens to talk to other services in their backend, something that Microsoft calls service-to-service (S2S) communication. If one of these tokens leaks, it can be used to access all the data in an entire tenant without any useful telemetry or mitigation. In July of this year, Microsoft did publish a blog about removing these insecure legacy practices from their environment, but they do not provide any transparency about how many services still use these tokens.

The fatal flaw leading to cross-tenant compromise

As I was refining my slide deck and polished up my proof-of-concept code for requesting and generating these tokens, I tested more variants of using these tokens, changing various fields to see if the tokens still worked with the modified information. As one of the tests I changed the tenant ID of the impersonation token to a different tenant in which none of my test accounts existed. The Actor tokens tenant ID was my iminyour.cloud tenant, with tenant ID 6287f28f-4f7f-4322-9651-a8697d8fe1bc and the unsigned JWT generated had the tenant ID b9fb93c1-c0c8-4580-99f3-d1b540cada32.

I sent this token to graph.windows.net using my CLI tool roadtx, expecting a generic access denied since I had a tenant ID mismatch. However, I was instead greeted by a curious error message:

Note that these are the actual screenshots I made during my research, which is why the formatting may not work as well in this blog

The error message suggested that while my token was valid, the identity could not be found in the tenant. Somehow the API seemed to accept my token even with the mismatching tenant. I quickly looked up the netId of a user that did exist in the target tenant, crafted a token and the Azure AD Graph happily returned the data I requested. I tested this in a few more test tenants I had access to, to make sure I was not crazy, but I could indeed access data in other tenants, as long as I knew their tenant ID (which is public information) and the netId of a user in that tenant.

To demonstrate the vulnerability, here I am using a Guest user in the target tenant to query the netId of a Global Admin. Then I impersonate the Global Admin using the same Actor token, and can perform any action in the tenant as that Global Admin over the Azure AD Graph.

First I craft an impersonation token for a Guest user in my victim tenant:

I use this token to query the netId of a Global Admin:

Then I create an impersonation token for this Global Admin (the UPN is kept the same since it is not validated by the API):

And finally this token is used to access the tenant as the Global Admin, listing the users, something the guest user was not able to do:

I can even run roadrecon with this impersonation token, which queries all Azure AD Graph API endpoints to enumerate the available information in the tenant.

None of these actions would generate any logs in the victim tenant.

Practical abuse

With this vulnerability it would be possible to compromise any Entra ID tenant. Starting with an Actor token from an attacker controlled tenant, the following steps would lead to full control over the victim tenant:

1. Find the tenant ID for the victim tenant, this can be done using public APIs based on the domain name.
2. Find a valid netId of a regular user in the tenant. Methods for this will be discussed below.
3. Craft an impersonation token with the Actor token from the attacker tenant, using the tenant ID and netId of the user in the victim tenant.
4. List all Global Admins in the tenant and their netId.
5. Craft an impersonation token for the Global Admin account.
6. Perform any read or write action over the Azure AD Graph API.

If an attacker makes any modifications in the tenant in step 6, that would be the only event in this chain that generates any telemetry in the victim tenant. An attacker could for example create new user accounts, grant these Global Admin privileges and then sign in interactively to any Entra ID, Microsoft 365 or third party application that integrates with the victim tenant. Alternatively they could add credentials on existing applications, grant these apps API permissions and use that to exfiltrate emails or files from Microsoft 365, a technique that is popular among threat actors. An attacker could also add credentials to Microsoft Service Principals in the victim tenant, several of which can request Actor tokens that allow impersonation against SharePoint or Exchange. For my DEF CON and Black Hat talks I made a demo video about using these Actor tokens to obtain Global Admin access. The video uses Actor tokens within a tenant, but the same technique could have been applied to any other tenant by abusing this vulnerability.

Finding netIds

Since tenant IDs can be resolved when the domain name of a tenant is known, the only identifier that is not immediately available to the attacker is a valid netId for a user in that specific tenant. As I mentioned above, these IDs are added to Entra ID access tokens as the puid claim. Any token found online, in screenshots, examples or logs, even those that are long expired or with an obfuscated signature, would provide an attacker with enough information to breach the tenant. Threat actors that still have old tokens for any tenant from previous breaches can immediately access those tenants again as long as the victim account still exists.

The above is probably not a very common occurrence. What is a more realistic attack is simply brute-forcing the netId. Unlike object IDs, which are randomly generated, netIds are actually incremental. Looking at the differences in netIds between my tenant and those of some tenants I analyzed, I found the difference between a newly created user in my tenant and their newest user to be in the range of 100.000 to 100 million. Simply brute forcing the netId could be accomplished in minutes to hours for any target tenant, and the more user exist in a tenant the easier it is to find a match. Since this does not generate any logs it isn’t a noisy attack either. Because of the possibility to brute force these netIds I would say this vulnerability could have been used to take over any tenant without any prerequisites. There is however a third technique which is even more effective (and more fun from a technical level).

Compromising tenants by hopping over B2B trusts

I previously mentioned that a users netId is used to establish links between a user account in multiple tenants. This is something that I researched a few years ago when I gave a talk at Black Hat USA 22 about external identities. The below screenshot is taken from one of my slides, which illustrates this:

The way this works is as follows. Suppose we have tenant A and tenant B. A user in tenant B is invited into tenant A. In the new guest account that is created in tenant A, their netId is stored on the alternativeSecurityIds attribute. That means that an attacker wanting to abuse this bug can simply read that attribute in tenant A, put it in an impersonation token for tenant B and then impersonate the victim in their home tenant. It should be noted that this works against the direction of invite. Any user in any tenant where you accept an invite will be able to read your netId, and with this bug could have impersonated you in your home tenant. In your home tenant you have a full user account, which can enumerate other users. This is not a bug or risk with B2B trusts, but is simply an unintended consequence of the B2B design mechanism. A guest account in someone else’s tenant would also be sufficient with the default Entra ID guest settings because the default settings allow users to query the netId of a user as long as the UPN is known.

To abuse this, a threat actor could perform the following steps, given that they have access to at least one tenant with a guest user:

1. Query the guest users and their alternativeSecurityIds attribute which gives the netId.
2. Query the tenant ID of the guest users home tenant based on the domain name in their UPN.
3. Create an impersonation token, impersonating the victim in their home tenant.
4. Optionally list Global Admins and impersonate those to compromise the entire tenant.
5. Repeat step 1 for each tenant that was compromised.

The steps above can be done in 2 API calls per tenant, which do not generate any logs. Most tenants will have guest users from multiple distinct other tenants. This means the number of tenants you compromise with this scales exponentially and the information needed to compromise the majority of all tenants worldwide could have been gathered within minutes using a single Actor token. After at least 1 user is known per victim tenant, the attacker can selectively perform post-compromise actions in these tenants by impersonating Global Admins.

Looking at the list of guest users in the tenants of some of my clients, this technique would be extremely powerful. I also observed that one of the first tenants you will likely compromise is Microsoft’s own tenant, since Microsoft consultants often get invited to customer tenants. Many MSPs and Microsoft Partners will have a guest account in the Microsoft tenant, so from the Microsoft tenant a compromise of most major service provider tenants is one step away.

Needless to say, as much as I would have liked to test this technique in practice to see how fast this would spread out, I only tested the individual steps in my own tenants and did not access any data I’m not authorized to.

Detection

While querying data over the Azure AD Graph does not leave any logs, modifying data does (usually) generate audit logs. If modifications are done with Actor tokens, these logs look a bit curious.

Since Actor tokens involve both the app and the user being impersonated, it seems Entra ID gets confused about who actually made the change, and it will log the UPN of the impersonated Global Admin, but the display name of Exchange. Luckily for defenders this creates a nice giveaway when Actor tokens are used in the tenant. After some testing and filtering with some fellow researchers that work on the blue side (thanks to Fabian Bader and Olaf Hartong) we came up with the following detection query:

AuditLogs
| where not(OperationName has "group")
| where not(OperationName == "Set directory feature on tenant")
| where InitiatedBy has "user"
| where InitiatedBy.user.displayName has_any ( "Office 365 Exchange Online", "Skype for Business Online", "Dataverse", "Office 365 SharePoint Online", "Microsoft Dynamics ERP")

The exclusion for group operations is there because some of these products do actually use Actor tokens to perform operations on your behalf. For example creating specific groups via the Exchange Online PowerShell module will make Exchange use an Actor token on your behalf and create the group in Entra ID.

Conclusion

This blog discussed a critical token validation failure in the Azure AD Graph API. While the vulnerability itself was a bad oversight in the token handling, the whole concept of Actor tokens is a protocol that was designed to behave with all the properties mentioned in the paragraphs above. If it weren’t for the complete lack of security measures in these tokens, I don’t think such a big impact with such limited telemetry would have been possible.

Thanks to the people at MSRC who immediately picked up the vulnerability report, searched for potential variants in other resources, and to the engineers who followed up with fixes for the Azure AD Graph and blocked Actor tokens for the Azure AD Graph API requested with credentials stored on Service Principals, essentially restricting the usage of these Actor tokens to only Microsoft internal services.

Disclosure timeline

• July 14, 2025 - reported issue to MSRC.
• July 14, 2025 - MSRC case opened.
• July 15, 2025 - reported further details on the impact.
• July 15, 2025 - MSRC requested to halt further testing of this vulnerability.
• July 17, 2025 - Microsoft pushed a fix for the issue globally into production.
• July 23, 2025 - Issue confirmed as resolved by MSRC.
• August 6, 2025 - Further mitigations pushed out preventing Actor tokens being issued for the Azure AD Graph with SP credentials.
• September 4, 2025 - CVE-2025-55241 issued.
• September 17, 2025 - Release of this blogpost.

The setup

Intune supports a “Certificate Connector” that can be installed on-prem, to allow Intune to request certificates in AD CS. The certificate connector is documented here and provides 3 options for distributing certificates:

• PKCS, which requests the certificates in AD CS using an Intune generated private key, and pushes the certificate plus the key to the device.
• SCEP, in which case the device requests the certificate over the Simple Certificate Enrollment Protocol using an Intune provided “challenge”. The SCEP endpoint is usually internet exposed through a proxy.
• PFX import, which distributes administrator uploaded PFX certificates to devices (not covered in this blog).

The certificate connector is usually installed on a standalone server in AD, and in case of the SCEP protocol will also need the Network Device Enrollment Service (NDES) server role (part of AD CS). In addition, both of these configuration options require an AD CS certificate template that allows user supplied SANs. On the AD side, such a template would look as follows (output from Certipy):

  1
    Template Name                       : NDES-Computer
    Display Name                        : NDES-Computer
    Certificate Authorities             : hybrid-HYBRID-DC-CA
    Enabled                             : True
    Client Authentication               : True
    Enrollment Agent                    : False
    Any Purpose                         : False
    Enrollee Supplies Subject           : True
    Certificate Name Flag               : EnrolleeSuppliesSubject
    Extended Key Usage                  : Server Authentication
                                          Client Authentication
    Requires Manager Approval           : False
    Requires Key Archival               : False
    Authorized Signatures Required      : 0
    Schema Version                      : 4
    Validity Period                     : 1 year
    Renewal Period                      : 6 weeks
    Minimum RSA Key Length              : 2048
    Template Created                    : 2025-05-22T14:09:06+00:00
    Template Last Modified              : 2025-05-22T14:10:00+00:00
    Permissions
      Enrollment Permissions
        Enrollment Rights               : HYBRID.IMINYOUR.CLOUD\svc_ndes
                                          HYBRID.IMINYOUR.CLOUD\Domain Admins
                                          HYBRID.IMINYOUR.CLOUD\Enterprise Admins

The following details are important for this attack:

• The template is from a CA that is in the NTAuthCertificates object in AD.
• The EnrolleeSuppliesSubject flag is set, this is a requirement for Intune to be able to issue certificates for other users/devices, meaning that this flag should always be set for Intune templates.
• The certificate allows for client authentication. As client authentication is one of the major use cases for these certs I can’t imagine many cases in which this will not be configured.
• A service account hosting the NDES server role or the host on which the certificate connector is running is authorized to enroll in the cert template. For SCEP it is common to use a separate service account, for PKCS I think it defaults to the computer account of the server. If “Domain Users” can enroll then you already have ESC1 and there isn’t much need for the rest of this blog as long as you have network connectivity to the CA.

SCEP vs PKCS

While the Intune Certificate connector supports both protocols, companies are likely to use either one or the other. Architecture wise they are quite different, so let’s take a high-level look at how both operate:

PKCS

PKCS performs most of the operations between Intune and the device. The flow is as follows:

• Intune will generate a Certificate Sign Request (CSR) and private key within the Intune service.
• When the Certificate Connector checks in it will download the CSR and try to request the certificate with AD CS.
• It then uploads the issued certificate to Intune.
• The issued certificate with the Intune generated private key is pushed to the device.

In a diagram, that looks as follows:

The important details here are:

• The private key is generated by Intune, not by the device. Theoretically Intune also possesses the private key while it hasn’t yet been provisioned to the end-user device.
• The device only communicates with Intune, not with any AD asset directly.
• It can be used to enroll in any template that the connector service has access to, since this is supplied in the certificate configuration.

SCEP

With SCEP, the flow is different:

• Intune generates an encrypted and signed “challenge blob” and send this with the certificate details to the device.
• The device generates a private key locally and uses SCEP to talk to the NDES server, requesting a certificate based on a CSR and the challenge.
• The certificate connector validates the challenge and CSR by sending them to Intune. Intune performs various checks to confirm that the subject, SANs, EKUs etc matches with the certificate profile, and that the challenge isn’t expired.
• If the validation succeeds, the certificate connector sends the CSR to the CA and it will issue the certificate.
• The signed certificate is returned in the SCEP response to the device.

Again a diagram of this flow:

A few notable points:

• In this case the private key never leaves the end device.
• The device does communicate with AD, usually over something like an application proxy.
• The device generates the CSR so it could request a completely different cert, however the NDES server validates the request by sending the CSR to Intune.
• The enrollment template is fixed because it is configured in the registry on the NDES server.

Issuing AD CS certificates with arbitrary subjects as an Intune Administrator or Global Administrator

It should be no surprise that if such a setup is present, it can be abused by attackers if they have a privileged role in the tenant. After all, the AD CS template allows any subject, the Certificate Connector or NDES server can enroll these templates, so with the correct configuration we can impersonate a Domain Admin or a domain controller. There are three main challenges with this:

1. Configuring the template so that strong mapping requirements are met and AD will accept the certificate for our user.
2. Getting the certificate delivered to an endpoint under the attackers control and using it to request a TGT for further exploitation.
3. Having network access to talk to on-prem Domain Controllers. This is out of scope for the blog post, I’m assuming you already have at least network access in AD. While somewhat uncommon, it could be the case that companies also roll out their VPN configurations via Intune which usually use the same or a similar device certificate for authentication. As an Intune admin you could also roll out your favorite C2 implant binary to any Intune managed endpoint and get access to the on-prem network that way.

Let’s look at the Intune part first. Consider an example certificate profile here:

This is a device certificate, which is why it uses the DNS Subject Alternative Name (SAN) for mapping it to a specific device. User certificates would usually use the UPN instead of the DNS name. The Intune “Certificate type” is a device certificate in this case, which means it will be saved as a computer certificate on the endpoint if the Entra ID device object is in scope of the configuration profile. For user certificates, they are stored as a user certificate on the endpoint, and will be issued to users in scope of the configuration profile.

Both user or device certificate can be used to impersonate user or computer accounts in AD, since the mapping is done based on the SAN and the AD CS template will allow both objects. Whether to target a user or device in AD is up to you, in this example the goal will be to impersonate a Domain Controller, so I will pick a computer as a target and use a DNS SAN.

We will create a new configuration profile rather than modifying an existing one, to prevent the change from being rolled out to actual endpoints. This also makes sure the certificate will be provisioned immediately, since I don’t know how fast Intune picks up on “changed” certificate configurations, if at all, once a certificate is already issued.

Based on MS-PKCA section 3.1, during PKINIT the certificate will need to be strongly mapped. Luckily for us there is a SAN URL tag specifically for Intune that we can use to ensure this: URL=tag:microsoft.com,2022-09-14:sid:<value>. In normal configurations this would be dynamically filled in for hybrid joined devices based on the SID that they have in AD, but we can also hard code it in the template. So in our new template, make sure to configure:

• The subject (doesn’t really matter in this case).
• The DNS SAN mapping to the hostname of a Domain Controller.
• The URL SAN that includes the SID of the Domain Controller (can be queried with BloodHound, ldapdomaindump or any other LDAP tool).
• Make sure the EKUs include client authentication.

In my case the final config looks like this:

Now we need to scope this to a device to actually issue the certificate. There are multiple approaches to this:

• Scope it to a legitimate device that is in the same tenant.
• Enroll a Windows based virtual machine in Intune.
• Enroll a fake device with tools such as AADInternals or pytune (I have not tested how easy it is to extract the certs from their output).
• Use roadtune with a fake Intune device which supports both PKCS and SCEP certificates.

While roadtune has (or will have actually from the next release) the most seamless support for this attack, it is currently not available as an open source tool but is part of the Outflank Security Tooling framework. If you have that, great, you can read more about the roadtune specific implementation in the roadtune documentation. But since I don’t want to promote commercial tooling in this blog I will stick with explaining the other flows here, with the primary focus on real Windows devices or VMs.

In this case I have an already enrolled VM that is in a group that I scope this configuration profile to:

It can take a while for the device to pick up the new policy or for Intune to actually start pushing it. Assume a delay of around 5-10 minutes (that is what I had in my test). The telemetry in Intune is quite slow so don’t rely on that. Since it may take a long time for the device to sync, it is better to trigger a manual sync until we see the certificate in the store:

Once the certificate is in the store, we can either export it out (and bypass the key export restrictions) using mimikatz, or we can use it directly with Rubeus by specifying the thumbprint. Note that Rubeus only searches in the user store, so if the certificate type was “device” you need to patch out the store lookup to target the system cert store instead. We specify the certificate by its thumbprint.

If we want to capture the certificate before it is stored in the store, we can actually see the PFX cert in the SyncML data as well. There is a super awesome tool to debug this called SyncMLViewer by Oliver Kieselbach that allows us to capture the SyncML messages via ETW. If we search for the PFX install message, which will contain the “PFXCertInstall” command, we find the PFX itself and it’s encrypted password:

Decrypting the PFX password requires using the Intune MDM cert and private key, and using that to decrypt the PKCS7/CMS encoded data blob, which gives the PFX password. Performing this is out of the scope of this blog but that would be an alternative to exporting the key out of the Windows certificate store.

Now that we have a TGT for a Domain Controller we have essentially compromised the on-prem domain.

If you have a SCEP configuration profile instead of a PKCS profile, we can use the same technique to issue the cert to a real device, alternatively we can also pick the required details out of the SyncML stream and use that with scepreq as explained further down in the blog.

ESC1 over Intune

Now that we understand the general setup, let’s look at how we can achieve this without the modification of configuration profiles, for example from the point of a low-privileged user with an Intune license. Consider for example the following template:

This template puts the FQDN of our device as a SAN in the template. There are many variables that could be used here, as is reflected in the Microsoft documentation. What is important here is that some of these come from essentially untrusted / user controlled data. This will mostly be the case for “device” type certificates, since “user” certificates are usually based on Entra data such as a UPN, which can’t be modified by the user themselves.

There could be a corner case if the company is syncing Tier 0 AD users to Entra ID, which is against best practices. If you could compromise such an account it could also be used to request certificates. But that would be a corner case that likely requires similar privileges in the tenant as the scenario above.

Back to the device cert based scenario. Microsoft does call it out in the documentation that these parameters could be spoofed.

So this is exactly what we will be doing in this case. Before strong mapping was required, this would have been quite easy since we only need to include the correct DNS or UPN SAN in our request. Now that strong mapping is the default, that leaves us with two options:

1. If strong mapping is not enforced, aka the registry setting StrongCertificateBindingEnforcement is set to 1, then we can use both PKCS and SCEP templates to request a certificate with a UPN or DNS name SAN that is attacker controlled.
2. If strong mapping is enforced, which is the default currently and will be the only supported mode from September 2025, then we can only use SCEP templates to perform this elevation of privileges.

Why SCEP? Because with PKCS, the entire flow is between Intune and the Certificate Connector, which means we cannot add the strong mapping. The KDC will not accept our certificate and throw an error if no strong mapping is present. With SCEP we can create our own CSR, and as long as the subject and SANs match with the values in the Intune configuration profile it turns out we can add the SID security extension to the certificate with an arbitrary SID, this will pass the validation.

To sum up the requirements:

• We need to have a SCEP certificate that is configured for client auth and allows the Digital Signature key usage (this will be the case in most deployments).
• The certificate should have a SAN mapping that uses user-controlled or modifiable data. Examples are given below. This is what makes the configuration actually vulnerable and what should be mitigated if you are using such a configuration in production.
• We need to have a device that is in scope of this configuration profile.

There are a few challenges here:

• Intune does not by default allow regular users to view the configuration profiles. If we want to determine the actual configuration we would need to have a role assigned like Global Reader. An alternative, if one has access to a legitimate device, is to look at the certificates installed on the device. If the SAN is constructed from something that is user controllable, such as the device name or serial number, it can be abused.
• If we do this with a device that is in scope of the real policy, we can modify the configuration on-device. Doing that however will require figuring out where the device is getting these values from and then replace them either on disk, in memory or in the registry. For a fake device this is easier since we can just change the device parameters in the enrollment profile data.

Some abusable configurations in SANs are:

• Having a DNS SAN with {{DeviceName}}. The device name can be configured as an FQDN, though Windows will not allow you to do so in the UI. Intune accepts these names without issue.
• Having a DNS SAN with {{DeviceName}}.companydomain.com. In this case we only need to spoof the first part, which we can do by renaming the real device.
• Having a configuration as above, but then with {{IMEI}} or {{SerialNumber}}. I don’t know where real Windows devices source this information from, so you’d have to figure that out yourself, or enroll a fake device.

Examples of configurations that are not vulnerable:

• Having a DNS SAN with {{DeviceName}}.companydomain.com, if the domain does not match the on-premises domain name.
• Using a SAN with data source from Entra / Intune that is automatically generated, such as AAD_Device_ID or DeviceId

I have not figured out yet where {{FullyQualifiedDomainName}} is sourced from, it may be that this only exists on hybrid joined devices.

In this walkthrough we will explore the simplest configuration, where there is a SCEP cert that has a SAN based on the device name and a domain suffix that matches with on-prem AD.

Let’s rename our device to match a Domain Controller name:

We also run the SyncMLViewer tool to watch the SyncML traffic, since we will use this to capture the traffic. What we are looking for are SyncML nodes with the ClientCertificateInstall/SCEP URI. These will contain the data for our SCEP enrollment. Once we trigger the sync with the new name we should see the data.

This contains everything we need to use scepreq to talk to the NDES service. Scepreq is a new tool that I’m releasing with this blog. It is essentially a modified fork of PyScep with a command line wrapper and extensions for AD CS and Intune specific certificate requests. The structures for custom SANs and security extensions are borrowed from Certipy.

We will need:

• The ServerURL, which contains the SCEP endpoint.
• The Challenge, which is used in SCEP as a password. The challenge is valid for an hour after it is issued.
• The EKUMapping, which should at least contain client authentication (1.3.6.1.5.5.7.3.2), or the “any purpose” EKU.
• The key usage. The values are from X509KeyUsageFlags defined in certenroll.h. Most of the time it will be 160 in decimal which means both “digital signature” and “key encipherment”.
• The SubjectName for the cert.
• The SubjectAlternativeNames to use. These have a bit of a weird format with the comment in the documentation “Refer name type definition in MSDN”. The format is as follows: [nameformat1]+[actual name1];[name format 2]+[actual name2], where the nameformat is a number. I did manage to find the documentation for these numbers, they match to constants from the AlternativeNameType enum in certenroll.h.
• The SID from our victim, the Domain Controller, queried as in the first scenario in this blog.

If we take all that we can pass it to scepreq. Note that most of these values are actually case sensitive!

scepreq -u https://s25-ndes.hybrid.iminyour.cloud/certsrv/mscep/mscep.dll -p <challenge> --dns HYBRID-DC.hybrid.iminyour.cloud -s 'CN=c711a89b-7b82-4d84-bfa2-040d03057ee5' --sid S-1-5-21-1414223725-1888795230-1473887622-1000

If all succeeds we get a certificate. If not, there is unfortunately zero error information that NDES will give to use as of why this failed. It will be in the Event logs on the NDES server, but that is not a source of information that we can see in this scenario. Anyway, if all goes well it should look like this:

Once we have the certificate we can request a TGT with PKINITtools, Certipy or Rubeus:

And once again we have a TGT for a Domain Controller, elevating our privileges to Domain Admin.

Challenges and mitigations

In this case the starting point was a Windows device on which we had Administrator access so that we could spoof the correct variables and abuse the template. If it is not such an easy example as above, it would be more complex to spoof the correct identifier (such as a serial number) on a real device. Getting a fake device enrolled with either a tool or as a VM would work, but then usually corporate device enrollment limitations would apply, often enforced through Autopilot. There is some discussion about whether Autopilot and the registration of hardware IDs is actually a security feature or more of an accidental security barrier for attackers. I see it as a feature that will often stop attackers from enrolling fake devices, though I don’t think it is intended this way.

In any case, the important message here is that Intune administrators should avoid using spoofable identifiers in certificate profiles. And of course be aware that when someone obtains Intune Administrator or Global Administrator and also has access to the AD network, it is pretty much game over.

As far as detection goes, the usual AD CS certificate abuse detection advice would apply, and hopefully some security product or custom detection rule will alert on certificates being issued for Domain Admins or Domain Controllers, or TGTs requested for them with a certificate if this is not normally something they do.

Tools

The scepreq tool is available on GitHub. If you want to do this with roadtune, expect a new release soon which includes PKCS extraction capabilities and automatic SCEP enrollment based on configurations that are pushed from Intune.

Lastly a shout-out to Rudy Ooms, whose documentation on all the Intune things was extremely valuable while developing the Intune related protocols.

Federated credentials concept

The idea behind federated credentials is that you can choose to trust some other Identity Provider (IdP) to authenticate your apps. This solves for example manual credential management on workloads that run outside of Azure, where Managed Identities are unavailable. An example of this is that you can use federated credentials in GitHub actions. This would allow a specific pipeline or pipelines from the same repository to access a workload identity without needing certificates or passwords configured in the pipeline definition. The concept of federated identities in Entra and Azure documented here.

On a protocol level, federated credentials use OpenID Connect (OIDC) as a way of establishing a trust between Entra and another IdP. The protocol is standardized and is commonly used to let applications trust Entra ID as an IdP, but in this case we use it as a way for Entra ID to trust a third-party IdP. Once the IdP is configured as a trusted token issuer, Entra will query the .well-known/openid-configuration endpoint as specified in the OpenID Connect discovery protocol. This configuration document also points us to the trusted keys with which ID tokens must be signed.

Creating our own minimal IdP

The idea behind using federated credentials is that we trust a well-known platform such as GitHub, AWS or GCP. But we can also roll our own IdP with our own keys, as long as we can host them somewhere Entra ID can reach them. At the minimum, we need two files:

• The OpenID Provider Configuration file at .well-known/openid-configuration.
• The keys document linked in the jwks_uri property of the Provider Configuration file.

The keys document contains a public key and/or certificate that we can use to sign our tokens. The certificate is optional in this deployment, a public/private RSA or EC keypair is sufficient to make it work. The certificate that we want to use can be self-signed, so we don’t need to involve a Certificate Authority. I’ll show you later how we can generate the keys and configuration with roadoidc, but let us assume for now that we have these files hosted on https://roadoidcapp.azurewebsites.net. This site will then become the issuer of our tokens.

Configuring federated credentials on applications and user managed identities

We can configure the federated credential on applications in the tenant we want to target. The permissions here are identical to the permissions you would normally need to configure certificates or passwords on applications, so you would need one of the following:

• Global Administrator (doh)
• (Cloud) Application administrator
• Owner privileges over the app
• Application.ReadWrite.All or Directory.ReadWrite.All Microsoft Graph permissions

We can then configure the federated credentials on an application as follows:

The issuer should be https://roadoidcapp.azurewebsites.net since this is where our keys are hosted. The subject identifier and audience could be anything since we can put arbitrary strings in our tokens, so just pick something nice or leave it at the default. We can achieve the same with the Microsoft Graph API, if preferred over the portal. What is interesting, is that while technically the federatedIdentityCredentials property also exists on Service Principals, the Microsoft Graph API does not allow us to configure these credentials there, stating that it is not supported.

User Managed identities

On User Managed identities this concept is more interesting, since we don’t normally manage credentials ourselves on them. In fact, for certificates and password credentials this is not even possible, Microsoft prohibits us from modifying these properties on the service principal representing the managed identity in Entra ID. We can however manage their federated credentials, granted that we have Microsoft.ManagedIdentity/userAssignedIdentities/federatedIdentityCredentials/write permissions that come with the following built-in Azure RBAC roles:

• Contributor / Owner
• Managed Identity Contributor
• Azure Red Hat OpenShift Federated Credential Role

With these permissions, we can configure the federated credentials on the user managed identity, and authenticate to it from anywhere without needing to link the identity to a resource and having access to that resource. Note that this attack is only possible on User Managed Identities, not on System Managed Identities, since these are tied to a resource and don’t allow federated credential configuration.

Creating an OpenID connect provider with roidoidc

Before we authenticate we need to host the OpenID Connect provider configuration and the public keys somewhere Entra ID can reach them. In this case I’m hosting them as an Azure App Service, but any file host will do, including Azure Blob storage or S3 (which would be cheaper than Azure App Service). I’ve added some alternative hosting instructions in the roadoidc readme, but the first commands would be the same.

We need to generate the configuration for our environment with the genconfig.py file, found in the roadoidc directory of ROADtools. I suggest cloning the repository locally after install roadtx and roadrecon, which contain all the dependencies for roadoidc as well. In my case I will be running the app at roidoidcapp.azurewebsites.net, which means that becomes my issuer parameter.

python3 genconfig.py -c testconfig.py -i https://roadoidcapp.azurewebsites.net
Saving private key to roadoidc.key
Saving certificate to roadoidc.pem
Key ID: 54XPuTfyhvtuy94A6g2YjiL3Rx8=
Saving configuration to testconfig.py

Now move the config to the flaskapp folder so we can deploy it on Azure App Service. We can upload the app using the Azure CLI, optionally specifying the subscription to deploy to and/or an existing app service plan. The command below will create a new app service plan with the cheapest B1 tier:

mv testconfig.py flaskapp/app_config.py
cd flaskapp/
az webapp up -n roadoidcapp --sku B1

Once the webapp is up, verify we can reach the discovery document at https://yourapp.azurewebsites.net/.well-known/openid-configuration. If that works we can now authenticate to the app or user managed identity that we configured the federated credentials on.

Authenticating with federated credentials and roadtx

Make sure you have the latest version of roadtx installed. We need to specify quite a few parameters to authenticate with federated credentials and roadtx:

• The client ID of the application or user managed identity (-c)
• The tenant we want to authenticate to. Either as tenant ID or as one of the domains of the tenant (-t)
• The scope of the token we want to have, for example https://graph.microsoft.com/.default (-s)
• The issuer that we configured in the previous stap (-i)
• The certificate and/or key that we created (--cert-pem and --key-pem)
• The subject that we configured in the federated credential configuration (--subject)
• An optional audience if you changed it in the federated credential configuration (--audience)
• An optional key id if you chose a custom one when generating the IdP config (--kid)

In my case, the command would be as follows:

roadtx federatedappauth -c 8a2c36aa-66fb-46cd-9b2d-b94a4945e0a9 --cert-pem roadoidc.pem --key-pem roadoidc.key --subject testapp -t iminyour.cloud --issuer https://roadoidcapp.azurewebsites.net/ -s https://graph.microsoft.com/.default 

This will request a token using the client credentials grant flow, using a federated assertion instead of a certificate based assertion, which is somewhat documented in the Identity Platform documentation. The output of this command will be an access token in the .roadtools_auth file.

Conclusion

This blog shows an alternative approach attackers can use to configure credentials on Entra ID applications and Azure User Managed Identities. It can help them persist in environments or even elevate privileges if they can compromise a service principal with high privileges. Federated Credentials can come from well-known identity providers, but we can also create our own minimal IdP to avoid being limited to a platform such as GitHub for our token requests. Defenders should be aware of this possibility and monitor for unexpected federated credential that are configured on User Managed Identities and Entra ID applications. Thomas Naunheim wrote a great blog with defensive guidance on this same topic.

The tool that you can use to create your own IdP is available in the ROADtools repository on GitHub in the roadoidc directory.

Temporary access passes are not enabled by default. However, many tenants that primarily use passwordless forms of authentication have them enabled to allow users to configure passwordless authentication methods for the first time, or for account recovery in the case these users need to reset their authentication methods. For attackers, Temporary Access Passes (TAPs) also provide interesting options, since these temporary passwords exist next to the users regular password, which means configuring a TAP on an account is not a destructive action like resetting the account password. The abuse of TAPs by itself is not new, there are already some great blogs that explore this concept, such as this blog by Daniel Heinsen from SpecterOps.

After I read Daniel’s blog a while ago, I started playing with these TAPs to see if I could also utilize them with ROADtools to request tokens and what the limitations on those tokens would be. Since TAPs can be used to configure passwordless authentication methods, it shouldn’t be a surprise that we can also use them to configure Windows Hello for Business keys on accounts, which was added to ROADtools after my Windows Hello talks last year. I’ll describe the steps for this below. What I found more interesting during my research, is that TAPs can be used for lateral movement in hybrid environments as well, where the use of a TAP in Entra would allow the attacker to authenticate in the on-premises Active Directory. It would even allow the attacker to recover the NT hash of the victim account, which might be used to recover the plain text password of the victim account. The hybrid lateral movement part is only applicable if Cloud Kerberos Trust is used, which gives Entra ID the ability to issue Kerberos tickets for on-prem identities.

Configuring TAPs

Temporary Access Passes can be configured by admins, provided that the feature is enabled and the admin has sufficient rights to do so. The requirements and methods are quite clearly laid out in the TAP documentation from Microsoft. We can also do it over the Microsoft Graph Rest API, however that would require that we have a token with the UserAuthenticationMethod.ReadWrite.All delegated permissions. Unfortunately for us, there aren’t any built-in Microsoft apps that I’m aware of that have this kind of access, so our best bet is to use the Azure/Entra portal or to borrow a token from that portal and use that with PowerShell or the REST API. In this case we’ll stick to the Azure Portal to configure the temporary access pass.

Temporary Access Passes act as alternative credentials for the user, which means that we can use them while the legitimate user is not interrupted, which is a big advantage over destructive actions like password resets, which will invalidate the users current sessions and likely cause some complaints. Since the TAP also counts as MFA, we don’t need to worry about them receiving notifications or text messages from MFA prompts either. Now that we have a TAP, lets see what we can do to convert this into persistent access.

Abusing the TAP for lateral movement

The TAP itself is only valid during the configured lifetime. While we can influence this when creating the TAP, a longer validity might also be suspicious, because the TAP automatically becomes the preferred authentication method during its lifetime. To minimize the chance of the legitimate user being prompted for the TAP, we can make its lifetime as short as possible, or allow it to only be used once.

Configuring Windows Hello for Business keys with a TAP

To configure Windows Hello for Business, we need to have some special tokens. This process is very similar to the flow from my last blog where we used the special permissions of the Microsoft Authentication Broker to request a token that we can upgrade to a PRT. This flow is also similar to how Windows upgrades Primary Refresh Tokens to include an MFA claim after obtaining them with only a password. In this flow we don’t use the authentication method directly in the PRT request, but we use a special refresh token that acts as an intermediary.

Windows Hello provisioning also requires us to have a device in the tenant. Lucky for us, registering or joining devices is enables in almost all tenants, so if we do not have access to an existing device we can register or join one as part of the flow. We could technically abuse an existing device here, but that would complicate the process, especially if there is a TPM involved.

The first step is to authenticate using the TAP, using the prtenrich command from roadtx. This command also works without an existing PRT if we use the --no-prt flag, which allows us to use a TAP for authentication.

roadtx prtenrich -u hybrid@hybrid.iminyour.cloud --no-prt

This will prompt us for the TAP (which is now the preferred authentication method), and give us a refresh token. If we do not yet have a device certificate/key, we can also use this refresh token to register a device.

roadtx gettokens --refresh-token <token> -c broker -r drs

We can join or register a device with the device module:

roadtx device -n blogtest2 -a register

And with our newly registered device we can get a PRT:

roadtx prt -r <refreshtoken> -c blogtest2.pem -k blogtest2.key

The output of these commands should look somehwat like this:

Unfortunately for us, this PRT is only going to be valid for as long as the TAP itself. It does not say so in the expiry time, but it will get refused after the TAP expiry:

If we want to have actual persistence, we need to provision some additional credentials on the account. In this case, we could set up a Windows Hello key for the account, which we can then use after the TAP expires. The process to do this is very similar as in my last blog. We use the prtenrich command again to get an access token for Windows Hello provisioning, then we register the actual hello key.

roadtx prtenrich --ngcmfa-drs-auth
roadtx winhello -k hybriduser.key

The prtenrich command should automatically proceed if we did the TAP authentication within the last 10 minutes. If not, we can just use the TAP again to comply with MFA requirements (provided the TAP was valid for multiple uses). The winhello command provisions the key for our user. If we want, we can use it to get a new PRT, that is valid for longer and also counts as MFA:

roadtx prt -hk hybriduser.key -c blogtest2.pem -k blogtest2.key -u hybrid@hybrid.iminyour.cloud

We can use this PRT with the usual prtauth and browserprtauth to either get tokens or to browse the web as our victim.

Obtaining NT hashes of the victim via a TAP

So far, we didn’t see anything unexpected. After all, a TAP is a legitimate way to configure passwordless credentials, such as Windows Hello keys or FIDO keys (we wouldn’t even need to use custom tools to register a FIDO key, a browser would be sufficient). But if we take a step back and look at the PRT that we received after using the TAP, we see something unexpected:

Our PRT came with a Kerberos TGT for the on-premises Active Directory that our victim is part of. This is made possible by the Cloud Kerberos Trust feature, so it only works if that has been configured in the Entra tenant and the on-prem AD. However, it is meant to make on-premises authentication possible with Windows Hello for business keys and FIDO keys, not necessarily with TAPs. The issue here is that while a TAP is by definition temporary, the TGT that we receive here is valid for 10 hours, which most likely exceeds the validity of the TAP itself. Further more, since Cloud Kerberos trust enables recovering legacy credentials (meaning NT hashes), we can obtain the NT hash of our victim, provided that we have line-of-sight to an on-premises AD Domain Controller. The NT hash can be used to request TGTs even after the TAP expired or our access in the cloud was revoked. If the original password of the user is relatively weak, we might also be able to recover the plain text password by brute forcing the NT hash with tools such as hashcat.

So to recap, provided we have the following:

• TAPs enabled in the tenant
• Sufficient access to provision TAPs on our victims
• Cloud Kerberos trust enabled
• Line of sight to the on-premises AD

We could obtain the NT hash for anyone we can provision a TAP for, without requiring to configure persistence on their account, and all with a single device identity to leave as few traces as possible. While this list of requirements is quite long, if you do meet all of them it could be used as a somewhat noisy hash dump method, entirely controlled from Entra. There are limits on which accounts we can target with this, so users like Domain Admins (which shouldn’t be synced to Entra in the first place) are not affected. The restrictions and details of how exactly this works are covered in my blog on Cloud Kerberos Trust.

Let’s perform the last step of our attack. We re-use the PRT we got at the first step, so the one requested using the TAP, before we enrolled a Windows Hello key. This PRT contains a partial TGT, which we can exchange for a full TGT using ROADtools hybrid’s partialtofulltgt.py script.

python partialtofulltgt.py -f roadtx.prt hybrid.iminyour.cloud/hybrid

If we want to do this for more users, we simply provision a TAP for them too, request a TGT with the TAP and then recover the NT hash. You could write a script that loops through this and recovers as many hashes as possible, without making permanent changes to the accounts or causing impact on the real user of the account.

Disclosure, prevention and detection

While many parts of this are following the design principles, the ability to obtain a long-term key (NT hash) with a Temporary Access Pass seemed like a vulnerable feature of the protocol to me. Microsoft did consider it a valid finding when I reported it to MSRC, but not one of immediate concern because of the high privilege requirements, and the fact that an admin in that position would also be able to compromise an on-premises account through something like password write-back if that is enabled in the tenant.

I agree with them that the privileged required are high, it is not a default configuration, and there are other options to abuse the privileges these roles have. However, I still think that temporary passwords should not immediately give access to long term keys. From a pentester point of view, I also find it an interesting attack since it is non-disruptive to the actual user, which during a red team or pentest engagement is a big advantage. Since this feature will not be addressed in the immediate future, it is something that could be abused by attackers in the lateral movement / post exploitation stage of their attacks.

My recommendations if you have a setup where these features are present would be as follows:

• Avoid syncing accounts that have privileged rights in Active Directory to Entra ID.
• Make sure to scope the Temporary Access Pass authentication method only to regular users, and not to admin accounts that may be synced from on-premises (even though I just told you not to do that).
• Monitor for assignments of Temporary Access Passes on sensitive accounts, especially in high volume.
• Monitor for large numbers of users signing in “from” the same device, which is the event that is generated when a PRT is issued.
• Require compliant or hybrid joined devices for sign-in to prevent fake devices that are registered by attackers from being used to access applications.

As usual, ROADtools is available via GitHub or via PyPI via pip install roadtx. ROADtools hybrid is available as a collection of standalone scripts on GitHub.

Tokens and limitations

Just to have a short recap, there are different token types in Azure AD that each have their own limitations:

• Access tokens, which can be used to talk to APIs and access resources, for example over the Microsoft Graph. They are tied to a specific client (the application that requested them), and a specific resource (the API that you are accessing).
• Refresh tokens, which are issued to applications to obtain new access tokens, since access tokens have a relatively short lifetime. They can only be used by the application they were issued to, or in some cases by a group of applications.
• Primary Refresh Tokens, which are used for Single Sign On on devices that are Azure AD joined, registered or hybrid joined. They can be used both in browser sign-in flows to web applications and for signing in to mobile and desktop applications running on the device. I have covered Primary Refresh Tokens (PRT) single sign on, stealing, abuse and lateral movement extensively in many of my blogs and talks.

Access tokens are the only tokens that can be used to access data, (Primary) Refresh tokens can be used to request an access token, but cannot be used directly to talk to services that use Azure AD for authentication. The security of these tokens also requires that you can not use an access token to obtain a refresh token, since that would allow you “upgrade” your token to a more powerful token than you had initially.

The requirement to obtain a Primary Refresh Token is that you need to start with a device identity, and then use the users credentials to request a PRT. This limits how these powerful tokens can be issued and makes it harder for attackers to obtain them.

The exception to the rule - special refresh tokens

A while ago I was researching Windows Hello for Business (WHFB) and I spent quite a few times resetting my test systems to analyze the process. During this research I observed some interesting behaviour. If one sets up a new Windows installation, usually it is only needed to authenticate once during the setup process, and that one authentication is used to complete the entire setup flow and also set up WHFB keys. This is interesting, since at the moment we start the setup the device is not yet joined or registered in Azure AD. At the end however, we have a PRT that is used for SSO, and even meets the requirements to provision WHFB keys (which always requires a device identity used through a PRT).

Through analyzing the token flows used during the Windows setup, I found out that the process starts by signing in to a specific application, which gives Windows an access token and a refresh token. The access tokens can be used to join the device to Azure AD and set up the device identity. After the device registration, the refresh token which was issued without a device, is used with the new device identity to request a Primary Refresh Token. To me this is quite a clear violation of the token security architecture. We can use a regular refresh token, that is not tied to a device but is tied to a specific app, to first register a device and then request a more powerful token that can be used in any sign-in scenario.

Technical details

The “upgrade” from normal refresh token to primary refresh token is not possible with every refresh token. It requires a specific application ID (client ID) in the sign-in flow. Windows uses the client ID 29d9ed98-a469-4536-ade2-f981bc1d605e (Microsoft Authentication Broker) and resource https://enrollment.manage.microsoft.com/ for this request. We can emulate this flow with the roadtx gettokens command, which supports several different authentication flows:

If there is a policy that requires MFA to sign in, we can instead use the interactiveauth module:

The resulting refresh token (which is cached in the .roadtools_auth file) can be used to request a token for the device registration service, where we can create the device:

Now that we have a device identity, we can combine this with the same refresh token to obtain a PRT (both refresh tokens shortened for readability):

Tokens resulting from the authentication will contain the same authentication method claims as used during the registration, so any MFA usage will be transferred to the PRT. The PRT that we get can be used in any authentication flow, so we can expand the scope of our limited refresh token to any possible app.

We can also use this to sign in to browser flows:

Provisioning Windows Hello for Business keys

If you set up Windows and WHFB is enabled for your device, it will use the same session to provision the WHFB key for the newly set up device. To do this, we will need an access token with the ngcmfa claim. As long as we did the MFA authentication within the last 10 minutes, the PRT from the previous step is all we need. We can ask Azure AD to give us a token for the device registration service that contains this claim, without requiring further user interaction. To do this, we use the prtenrich command from roadtx, which will ask for this token.

With this new access token, we can provision the new WHFB key. This key can be used to also request new PRTs in the future, without needing access to the users password.

Phishing for Primary Refresh Tokens

Now that we know how the process works, we can change the approach to make it usable for phishing. Phishing PRTs directly is not possible, since this requires an existing device identity to be used during the flow. We cannot trick users or their endpoints in sending us the required information to directly request a PRT. We can however use several methods to ask for a regular refresh token with the right client and resource, to then use that to register a device and ask for a PRT.

Device code phishing

In the authentication step above, we used a username and password to authenticate. However, we can also use the device code flow for this. While Windows does not use this flow for the registration/join process, it is a valid OAuth flow which will give us the same refresh token.

As you can see, the device code flow asks users to enter a code on their own device and complete the authentication, which will provide the tokens on the device it was initiated. This flow is also suitable for phishing, because if we can convince our victim to perform the authentication with a device code, we will obtain tokens on their behalf. This is not a new technique, but has been described by several people in the past. There are also several tool kits that make the whole process easier. If you want to read up on this technique, here are some references:

• https://aadinternals.com/post/phishing/
• https://0xboku.com/2021/07/12/ArtOfDeviceCodePhish.html
• https://github.com/secureworks/squarephish
• https://www.blackhillsinfosec.com/dynamic-device-code-phishing/

So let us assume we convince a user to authenticate, and we receive the refresh token. We can now use this refresh token to:

• Register or join a device to Azure AD if we don’t already have access to a device in the tenant.
• Use the refresh token to ask for a PRT.
• If the user performed “fresh” MFA when authenticating with the device code flow, we can also register WHFB credentials on their account for persistence.

There are a few caveats to this, which you have to take into account if you are performing this attack:

• The device code is only valid for 15 minutes after you initiate the device code flow, which adds extra restrictions if you want to use this for phishing. Some tools account for this by only creating the device code once the user interacts with the email, for example via a QR code.
• Registering or joining devices could be restricted in the tenant to only specific users. In general, joining devices is restricted more often than registering them. Unless there are specific policies that require a certain device status, there won’t be a practical difference in the usability of the token.
• Registering WHFB credentials is only possible if the user actively performed MFA when using the device code. If they use the device code from an existing session their managed device, the MFA claim will be passed on to the refresh token and is most likely not recent enough to provision a WHFB key. In my testing, the cached sign-in status will only be used if the user has an existing session on an unmanaged device, and on browsers that signed in using SSO it will not automatically use the cached login.

The video below shows the attack as a proof of concept. In practical scenarios, you could use your preferred device code phishing framework or method to do the phishing part.

The video above uses the deviceCode2WinHello script that automates all these steps, written by Kai from SpecterOps (see conclusions at the end of the blog). It also uses the roadtx keepassauth module to do the authentication, in reality you would have to convince your victim to do the authentication, but this was easier for the demonstration.

Credential phishing

It is also possible to perform the phishing attack using credential phishing methods, for example with evilginx as framework. If we use a Microsoft 365 phishlet to sign in, for example this one by Jan Bakker, we will obtain the session cookies for the victim. These session cookies can be used with roadtx to ask for the correct tokens, and from there on the attack is the same:

I talked more about this approach at AREA41 in June 2024, the slides, recording and a demo video are available on the talks page.

Prevention and detection

There are not many ways to prevent these attacks. Device code phishing is one of the few methods that is not prevented by requiring a certain MFA strength, since users perform this authentication against the legit Microsoft domains. In addition, there is unfortunately no way to block certain OAuth flows such as the device code flow. The credential phishing approach described above is easier to prevent, since this will happen on a fake website which will prevent some MFA methods from working.

The only real effective way to block this attack is to require a device to be managed via MDM or MAM, by having a Conditional Access policy in place that requires a compliant or hybrid joined device. Complying with this policy would require the newly registered device to also be enrolled in Intune. Provided Intune is locked down sufficiently to block people from enrolling non-corporate or fake devices, our newly registered device won’t be able to become compliant and meet the requirements of these policies. Note that the device registration flow itself is not blocked by policies requiring compliant devices, since this flow is by definition excluded from these policies (you cannot already have a compliant device during device registration). So, if policies are in place that require a compliant or hybrid joined device, it is still possible to obtain a PRT. The PRT can however not be used to authenticate or to enroll the WHFB keys since that would require the device to be compliant or hybrid joined.

Detection of this technique is fortunately easier. Windows will not use the Device Code flow to register or join itself to Azure AD, but it will interactively prompt the user to authenticate. Since the authentication flow is shown in the Sign-in logs, it is quite easy to write detection queries based on the app ID and the authentication flow. An example KQL query would look something like this:

SigninLogs 
| where AppId == "29d9ed98-a469-4536-ade2-f981bc1d605e" //Broker app client id
    and AuthenticationProtocol == "deviceCode"

During my discussions with Microsoft on this topic, I was informed that in some cases the device code flow is used legitimately by the broker application, so this query could yield some false positives. If you find some legit matches with this query, feel free to reach out so we can see if it is possible to fine-tune it to exclude legitimate cases.

Disclosure process

I reported this issue to Microsoft a few months ago, since the ability to upgrade tokens violates the restrictions that should be in place on refresh tokens. While Microsoft acknowledged the issue, they did not consider this worth fixing immediately because of the requirement to phish users to authenticate. This means that this is something that red teams could use on future engagements until there are new mitigations for this technique, and that defenders should be aware of the abuse potential of these authentication flows.

Microsoft did indicate that they are working on new features to mitigate this issues. The mitigations they are considering are as follows:

• Adding additional warnings to the device code flow screen if it is used to authenticate to the broker client, warning the user that this will allow the application to perform Single Sign On on their behalf.
• Adding additional features to Conditional Access that offer more control over when the device code flow is permitted, offering the possibility to restrict or block the device code flow for certain applications or locations, similar to other Conditional Access features.

Conclusion and tools

Due to the ability to upgrade some refresh tokens to Primary Refresh Tokens, attackers have more ways to phish users and compromise accounts. This uses normal token flows that are already available in tool such as the ROADtools Token eXchange toolkit (roadtx), available via GitHub.

While working on this blog, I was having a chat with Kai, who was one of the people in my Azure AD training a few weeks prior. He also figured out the same upgrade technique independently, and wrote a script that performs the steps via a single command.

Attack model

Most attacks in hybrid environments exist of moving laterally from Active Directory towards Azure AD, since the source of identities is the on-premises Active Directory from where the identities are synced to Azure AD. As a result, a compromised Active Directory can almost always result in a compromised Azure AD. I have covered several of these attack paths in the past, during various talks and blogs:

• Overwriting Azure AD admin credentials via a sync bug
• Adding additional credentials to service principals via the Azure AD connect sync account
• Abusing Seamless Single Sign-on to impersonate identities in the cloud via Kerberos

Attacks from Azure AD to on-prem AD are much rarer, since in many cases AD does not sync much information from Azure AD and the writeback functions that exist use the permission model of Active Directory to prevent changing information of Tier 0 resources such as Domain Admins. The Cloud Kerberos Trust feature is an exception on this, since it creates a Read Only Domain Controller (RODC) in AD and stores its credentials in Azure AD. This effectively gives Azure AD highly privileged keys that it can use to authenticate most accounts in Active Directory. While we can’t extract these keys from Azure AD, not even with Global Admin, there are some other attack paths that we can abuse to achieve Domain Admin in Active Directory. This attack path assumes the following starting prerequisites:

• The attacker has obtained Global Admin privileges in Azure AD.
• The attacker has network connectivity to at least one Domain Controller of the on-premises Active Directory.
• The Cloud Kerberos Trust feature is set up and working properly.

The network connectivity part makes this not an attack that can be done from a fully external perspective, but if there is any VPN between Azure hosted resources and an on-premises domain, or a VPN configuration is rolled out via Intune, this should not be too hard to obtain. This is also a valid attack if an attacker is in an Active Directory network and has obtained Global Admin privileges but not yet Domain Admin privileges for some reason.

The Cloud Kerberos Trust

Cloud Kerberos Trust was added as a method to enable signing in to Active Directory connected resources with accounts that use a passwordless authentication method. Like the name implies, passwordless methods do not involve a password, so it is not possible for Windows to calculate an NT hash or Kerberos keys for the account. Since Active Directory does not have a native implementation for things such as FIDO2 keys, a trust with Azure AD is established and Azure AD is given a set of keys that it can use to issue Kerberos tickets for Active Directory. The setup is usually performed with a PowerShell script that creates a Read Only Domain Controller (RODC) in AD. This RODC does not really exist as a Windows server in Active Directory, but instead is more like a virtual account that is purely used to establish this trust. The RODC consists of two important components:

• The RODC computer account, named AzureADKerberos$. The presence of this account is also a good indicator that Cloud Kerberos is in use in the domain.
• A secondary krbtgt account named krbtgt_AzureAD. This account contains the Kerberos keys used for tickets that Azure AD creates. The SAM account name of this account will include the key ID, for example krbtgt_9898.

The RODC computer account and its secondary krbtgt account are linked together through the msDS-KrbTgtLinkBl attribute. This is important because an RODC comes with a set of restrictions which are set on the RODC computer account, but also apply to any tickets issued by the secondary krbtgt. As such, while Azure AD could technically issue tickets for users with administrator privileges, such as Domain Admins, these tickets will be refused by the AD domain controllers because the RODC is not allowed to issue tickets for them. This is managed in the attributes msDS-RevealOnDemandGroup and msDS-NeverRevealGroup, which are summarized in the GUI as the “Password Replication Policy”:

We see that since “Domain Users” is in the default scope, any user in the domain, excluding the users that are in any group explicitly denied, can be authenticated from Azure AD. While this includes most default high-privilege groups, in a real domain there will likely be more users with equivalent privileges that are not in any of those groups, so these will be our targets later on.

How Azure AD issues Kerberos tickets

If a Cloud Kerberos Trust is set up, Azure AD will issue partial Kerberos tickets when a user authenticates on Windows using a hybrid identity. This process occurs at the same time a Primary Refresh Token (PRT) is requested. Windows indicates it wants a TGT with the parameter tgt=true in the request. The request itself is a signed JWT that contains the users credentials or a Windows Hello assertion to authenticate. I’ve talked about the content of this request several times, for example in my TROOPERS talk from last year, and some more this year at Insomnihack. The important part here is the tgt parameter, which will cause Azure AD to include at least a cloud TGT that can be used for Azure AD Kerberos (mostly relevant when you use Azure AD connected fileshares over SMB), and if configured also a TGT for AD:

The response will have the tgt_cloud and if configured and applicable to the account we authenticate with also the tgt_ad parameter:

The clientKey parameter is the TGT session key, sent encrypted in JWE (JSON web encryption) format. Windows will first decrypt the session key of the PRT using the transport key of the device. Once it has the PRT session key, it can use that to decrypt the TGT session key. We call this a partial TGT because unlike a regular TGT, this does not include all the information of the user, simply because Azure AD does not have the full list of attributes or groups from the user account. The result is a TGT with a PAC that contains only the base attributes such as the user security identifier (SID) and their name. Windows can exchange this partial TGT for a full TGT by requesting a service ticket for the krbtgt service. The krbtgt service is normally used during the initial TGT request operation, but it can also be used in this flow to request a full TGT. The request is sent in a TGS-REQ message to a Domain Controller:

The Domain Controller will reply with a TGS-REP message containing a new TGT, now including a full PAC with all the users attributes and group memberships. This TGT is encrypted with the primary krbtgt keys of the domain, and can be used to request service tickets for services accepting Kerberos authentication.

NTLM Authentication

Having a Kerberos TGT still leaves a gap in authentication scenarios. After all, what if the user wants to authenticate to a service that doesn’t support Kerberos and only accepts NTLM authentication? For this Windows would need the NT hash to calculate the correct challenge/response for authentication. Having an NT hash implies that there is still a password, something we wanted to avoid by going passwordless in the first place. So Microsoft came up with an extension to the Kerberos protocol that allows Windows to obtain the NT hash of a user when exchanging a (partial) TGT signed using a secondary krbtgt key for a full one signed with the primary krbtgt key. Note that while this is only possible with secondary krbtgt keys signed tickets, this scenario is specifically designed for passwordless authentication and real RODCs do not use these protocol extensions. The exchange process, including the NT hash recovery was researched by Leandro Cuozzo, who wrote a nice technical blog about it and added support for this to the impacket library.

The key in this process is including the KERB-KEY-LIST-REQ field in the PADATA part of the request. This behaviour is documented in MS-KILE and indicates that if encountered, the KDC should include the long-term secrets in the reply. The long-term secrets in this case being the NT hash of the user accounts password (I have tried to recover the AES keys too this way, but that does not seem to work). As we can see in the screenshot in the previous section, Windows does include this in the request as the PA-DATA type 161. If we look at the response below, we see that the NT hash is included in the encrypted part of the response. Windows can decrypt this using the TGT session key and load the NT hash into memory.

Using Cloud Kerberos Trust with roadtx

The process of requesting a PRT for Azure AD or hybrid users has been part of roadtx since its release last year. Requesting a PRT will automatically include a request for a TGT, and the resulting TGT will be included in the .prt file. Roadtx will automatically decrypt the TGT session key as well and include that in the .prt file so that other tools can use it as well. As an example, I’m obtaining a PRT here for a hybrid account. This assumes I have previously registered or joined a device to this Azure AD tenant, which can be done with the roadtx device module, for which the certificate and key is stored in the talkdevice.pem and talkdevice.key respectively. Something interesting to note here is that while this mechanism is designed for passwordless authentication methods, Azure AD will also include the TGT if we authenticate with a password. With the password we could as well request a full TGT directly from Active Directory, but this will be relevant later in this blog.

Because this is an account that exists in both Active Directory and Azure AD, Azure AD includes the partial TGT with the PRT. This TGT can be extracted from the .prt file and exchanged for a full TGT with some utilities in the roadtools_hybrid repository, which saves it in a ccache file. Ccache files are compatible with impacket, so we can use the getST.py script to upgrade our partial TGT to a full one, as long as we have network connectivity to a Domain Controller.

This TGT we can use to authenticate to Active Directory connected services. We can also recover the NT hash of the user by using a slightly different script. The partialtofulltgt.py script in the roadtools_hybrid toolkit combines both steps, taking either the partial TGT from the .prt file directly, or loading it from the ccache file that we saved it to. It will also automatically use the KERB-KEY-LIST-REQ option to ask the DC nicely to put the NT hash in the response:

In this case the NT hash is not really secret since we already knew the password at the beginning, but if we are doing any lateral movement in Azure AD between hybrid identities, having the NT hash could allow us to obtain the password for this user if it is weak enough and we manage to crack it.

Abusing Cloud Kerberos Trust to obtain Domain Admin

To abuse the knowledge from the previous sections, we need to take a closer look at how Azure AD determines for which user it would issue a partial TGT and what information to put in this TGT. The Azure Portal shows the various properties of our hybrid account that are relevant under the “on-premises” section:

Azure AD uses the “On-premises SAM account name” and “On-premises security identifier” attributes to generate the ticket. As a Global Admin, one would assume that we can edit those, and maybe obtain a ticket for any user account in the AD domain, including those who are not synced. Modifying these attributes is not as easy as it sounds though, since the Microsoft Graph and the Azure AD Graph both disallow this, indicating these are read-only attributes. There is a third way to update accounts, which is more flexible in what it allows or not. This is the API Active Directory Connect uses to create and update synced users. Normally, this API is only used by “On-Premises Directory Synchronization Service Account”, which has the “Directory Synchronization Accounts” role. As a Global Admin, we could create a new sync account and obtain the same privileges. However, we don’t need to do this since the Global Admin role itself also allows usage of the sync API. I assume this is because the AD Connect account used to be a Global Admin itself, and some environments may still be operating in that way. When analyzing how Azure AD connect updates accounts, we run into this ugly mix of binary and textual data:

This is WCF binary xml, a standard used in .NET to transfer XML data in binary format. Lucky for me, there is an open source python parser that was released by ENRW many years ago. There are even some recent patches for this that fix compatibility issues with the synchronization API, contributed by @AndreasLrx and @sfonteneau. Using this library to decode the WCF binary data, we get a much more readable XML document:

We can use this API call to modify the SAM name and SID of any hybrid user, and then if we authenticate, we get a partial TGT containing the modified SID.

Note that we can do the same with AADInternals, which also supports the binary XML format, and updates to synced users over this protocol via the Set-AADIntAzureADObject cmdlet.

Attack prerequisites

For the attack to succeed and give us Domain Admin privileges, we have a few requirements:

• Privileges to modify accounts via the Synchronization API. We already mentioned that Global Admin or AD Connect sync account would work in this case. The Hybrid Identity Administrator role also would provide the neccessary permissions, since this can manage AD Connect and create new sync accounts.
• At least one hybrid account which we can modify and also authenticate to. This could be the same account as in the previous point, but since best practices indicate that hybrid accounts should not have highly privileged roles it is unlikely that the admin account is synced from on-premises.
• A victim account to target in Active Directory. While we could use this attack on any already synced account without the need to modify their attributes, we cannot have duplicate on-premises security identifiers in our Azure AD tenant, so to modify an account and obtain the ticket we need to have an account that is not synced.

There are several methods to obtain access to a hybrid account. They all vary slightly in how much noise it generates and whether the real user that we are targeting can keep working or that their authentication will break.

• Obtain the password for any synced account (for example using spraying, on-premises lateral movement, etc).
• Reset the password for a hybrid account via an Admin Portal, this would also reset it in Active Directory if password writeback is enabled.
• Change the password for a synchronized Azure AD account using the Synchronization API. This leaves the original password in Active Directory in place, but will cause a disconnect between the password in Azure AD and AD. We could obtain the NT hash for this account via the TGT upgrade request, and if we can recover the original password from the NT hash we could set the password back later.
• Assign passwordless credentials to the account. It used to be possible to provision Windows Hello for Business keys directly on an account, as I talked about at various conferences this year, but this has been fixed. An alternative workaround is to assign a Temporary Access Pass (TAP) to an account, set up the passwordless methods that way, and then obtain a PRT with them.
• Create a new user account with a known password via the synchronization API and set the target SID directly.

Lastly, we will need an account to target in the on-premises Active Directory that has Domain Admin or equivalent privileges, but is not denied in the replication configuration of the RODC. In any large domain, there are probably several accounts that have equivalent privileges without being explicitly in the Domain Admins group. For this scenario however, we will focus on an account that should be present in any domain that is set up as hybrid. The ideal victim for this attack is in fact the Active Directory account that is used by the AD Connect Sync service. This account is not synced to Azure AD, so its SID is available to target, and it has Domain Admin equivalent privileges because of its ability to synchronize password hashes (assuming Password Hash Sync is in use). If the domain uses the express installation, its name will start with MSOL_. If it has a different name, you should be able to find this by listing all the accounts that have Directory Replication privileges on the domain object.

The full attack

Now that we know the requirements, lets go through the full attack. We have a Global Admin account dirkjan@iminyour.cloud to perform the attack with, and a hybrid account that we can modify to perform our attack hybrid@hybrid.iminyour.cloud. In this case we know the password for the hybrid account, which is all we need to get a PRT for the account. We also queried the Sync account, which is called MSOL_9c3bf742d8e9 in my tenant and has security identifier S-1-5-21-1414223725-1888795230-1473887622-1104.

The first step is obtaining an access token for the Global Admin. The synchronization service uses the same resource ID as the Azure AD Graph API, so we can use roadtx to get a token for our admin account. We can do this using the gettokens command if we don’t need MFA, or use the interactiveauth to have an interactive window that supports MFA as well. In my example my credentials are stored in a KeePass database so I use the keepassauth command:

Next, we can modify the hybrid@hybrid.iminyour.cloud identity with the modifyuser.py script from roadtools_hybrid. An important parameter here is the SourceAnchor, since this is used to match the user with the Azure AD account. In the portal, this is called the “On-premises immutable ID” and in ROADrecon you can find this as the immutableId attribute on the user object. We can also use a non-existing SourceAnchor to create a new user, this just introduces an extra step to add a password to the account. We also supply the target SAM name and desired SID to the tool, which will change these on the hybrid@hybrid.iminyour.cloud user object:

We can confirm in the Azure Portal that the users properties have been changed:

Now the account is modified and we can request a PRT for this user, including the partial TGT. It is best to wait a minute to make sure our change is synchronized properly, but usually this is quite fast:

With the partial TGT we can request the full TGT and recover the NT hash, this time for the MSOL account:

With the full TGT (or the NT hash) we can talk to the Domain Controller and perform a DCSync attack, synchronizing all the hashes, including the hash of the full KRBTGT account, which allows us to forge our own TGTs, essentially elevating our access to full Domain Admin.

As a last step, it is advisable to change the account back to its original SAM name and SID using the modifyuser.py, or to delete the account if we created a new one. This step is optional, since from what I have seen Azure AD connect will pick up the change and reverse the change automatically.

Defenses and detection

The Cloud Kerberos Trust introduces a trust from Active Directory to Azure AD. If the Azure AD tenant is fully compromised, this would allow attackers to move laterally between synchronized identities via one of the methods from the previous section. This is not something that can be fully prevented, so one of the best defenses here is to use the tools available in Azure AD to protect your highly privileged identities. In addition, highly privileged users should exist in the environment they are managing only. That means no synced accounts in Azure AD administrator roles, and to not sync AD admin accounts to Azure AD.

The RODC object that Azure AD creates also offers some possibilities for defenses. Like a normal RODC, you could add additional accounts and groups to the “Denied password replication” list. If you have highly privileged groups, it would make sense to deny those from Cloud Kerberos Trust, though this does mean they can no longer use passwordless methods to authenticate to on-premises resources since this blocks both the Kerberos authentication as well as the NT hash recovery. In any case, adding accounts that do not need to authenticate with passwordless methods (such as the MSOL sync account) would be a good starting point:

Impersonating an account that is denied will cause the attack to fail with a KDC_ERR_TGT_REVOKED error.

On the detection side, there is some good and bad news. The bad news is that Azure AD does not log changes to the SAM name and SID property, so you have no way of creating targeted detections for this specific attack. The good news is that there are some ways to still identify parts of it. The change to the hybrid object is logged and shows the actor (our Global Admin) as well as the modified “LastDirSyncTime” property. The “LastDirSyncTime” property only gets updated when the synchronization API is used and not during regular user modifications.

Since in normal operations Global Admin accounts should not be using the synchronization API, this is a clear sign of something irregular going on. The other actions, such as resetting passwords or setting passwordless authentication methods on accounts are part of an admins normal work, so creating detections for those may be more noisy.

Tooling and credits

The tools are available on the ROADtools and ROADtools hybrid GitHub pages. Thanks to the following people for their prior work:

• Timo Schmid, @AndreasLrx and @sfonteneau for the python-wcfbin library.
• DrAzureAD for some helpful details on how the AD Sync protocol works and his implementation in AADInternals.
• Leandro Cuozzo for his blog on Cloud Kerberos Trust and the Key List attack.

Lastly, while finalizing this blog I also noticed that Daniel Heinsen and Elad Shamir gave a talk on a similar topic yesterday. While I have not yet seen the talk, I wanted to give a shout-out to them for their work as well and I’m looking forward to reading their approach on this topic.

• Register and join devices to Azure AD.
• Request Primary Refresh Tokens from user credentials or other valid tokens.
• Use Primary Refresh Tokens in a similar way as the Web Account Manager (WAM) in Windows does.
• Perform several different Oauth2 token redemption flows.
• Perform interactive logins based on Browser SSO by injecting the Primary Refresh Token into the authentication flow.
• Add SSO capabilities to Chrome via the Windows 10 accounts plugin and a custom browsercore implementation.
• Automate sign-ins, MFA and token requesting to various resources in Azure AD by using Selenium.
• Possibility to load credentials and MFA TOTP seeds from a KeePass database to use in (semi-)automated flows.

In this blog I will describe the tools features and show some demonstrations of the cool stuff you can do with it. You can also skip directly to GitHub or read the Wiki for details on each command.

roadtx structure

roadtx is structured as a wrapper tool around features implemented in roadlib. With the release of roadtx, a new class has been added to roadlib with all device authentication logic, containing functions that register/join devices and can request or use Primary Refresh Tokens in the same way that Windows uses them. In roadtx itself, there is a class with helper functions for Selenium-based authentication and support for intercepting browser requests to add SSO features to the browser window.

The main function of roadtx itself is about 400 lines of code to construct an (I hope) straightforward collection of commands with their parameters. It also has about 300 lines of code to deal with the commands and call library functions with the data needed. The actual device logic being in roadlib means that it is possible to re-use it in other tools or to make light standalone tools without needing all the roadtx specific dependencies.

I’ve also tried to make it intuitive and straightforward to use roadtx, reducing the command line arguments needed to perform specific actions. For example, roadtx device will register a device with randomized defaults, and functions dealing with Primary Refresh Tokens will by default load the PRT from a roadtx.prt file, so you don’t have to specify it every time you use a function.

Using roadtx

Devices and Primary Refresh Tokens

Most of the modules of roadtx are designed around Primary Refresh Tokens and device identities. To obtain a PRT, we must first register a device in Azure AD. Registering a device requires an access token to the device registration service resource. The access token must be a token without a device claim, so you cannot use single sign-on or an existing PRT to request one. There are a few ways to obtain such a token with roadtx, where some methods support MFA and others do not. MFA could be required to register a device, depending on tenant settings. If it is not, you can request a token for the device registration service (specified here through the devicereg alias) with only a username and password:

roadtx gettokens -u myuser@mytenant.com -p password -r devicereg

If MFA is required, you can use the device authentication flow to request the tokens from a browser window somewhere:

roadtx gettokens --device-auth -r devicereg

Alternatively, we can already skip ahead a bit to the functionalities shown later in this blog, and use a Selenium based window for MFA, while autofilling the username + password:

roadtx interactiveauth -u myuser@mytenant.com -p password -r devicereg

Any of the commands above with save an access token to the .roadtools_auth file. The device registration command will automatically load it from this file. You can customize what you want for device properties with various commandline parameters to the roadtx device module:

We register an Azure AD joined device with the name “blogdevice”:

roadtx device -n blogdevice
Saving private key to blogdevice.key
Registering device
Device ID: 5f138d8b-6416-448d-89ef-9b279c419943
Saved device certificate to blogdevice.pem

We get two pieces of data that identify our device. The first is the device certificate saved in blogdevice.pem, which is issued by Azure AD and identifies our device. The second part is the blogdevice.key file, which contains the private key of the certificate and is also used as transport key. Now that we have the device certificate, we can do operations that require a device identity. The most useful one is requesting a Primary Refresh Token, since that will enable us to add Single Sign On capabilities to our (interactive or automated) token requests.

Requesting a Primary Refresh Token

A primary refresh token is most often requested with a username and password. When you log in to an Azure AD joined or hybrid joined workstation with your username and password, Windows immediately requests a PRT from Azure AD. I’ve talked about the technicalities behind this flow at my Troopers and Romhack talks in the past, so if you’re interested in the technicalities have a read through those slides. To request a PRT with roadtx, run the roadtx prt command, specify the device cert/key and the username + password to use, and you get a PRT:

roadtx prt -u myuser@mytenant.com -p password --key-pem blogdevice.key --cert-pem blogdevice.pem

The command will give us a PRT (in the form of an encrypted token), and a session key that we need to use the PRT. The PRT is by default saved to roadtx.prt, where it can be picked up by other roadtx modules.

A PRT is by default valid for 90 days, but we can renew it at any time to extend the validity for another 90 days with the renew action:

roadtx prt -a renew
Renewing PRT
Saved PRT to roadtx.prt

Note that the PRT we requested here is only based on a password, so any authentication that requires MFA will fail even if we use the PRT. We can also upgrade or “enrich” the PRT with an MFA claim, this is shown in the next section on Selenium based authentication.

Using Primary Refresh Tokens on the command line

Once we have a PRT, we can use it to sign in to resources that accept Azure AD authentication. You can do this either with the roadtx gettokens command, and specify the PRT and session key on the command line, or use the roadtx prtauth command. The difference between the two is that the gettokens command implements authentication that is based on how Chrome does Single Sign On in the browser. This method is slightly hacky and if it fails won’t give you any feedback.

The prtauth module instead emulates the Web Account Manager (WAM) that Windows uses if you request access tokens from an app or native process. The WAM acts like a token broker, and requests tokens on behalf of other clients. It uses a combination of signed requests and encrypted responses to prevent exposing the tokens in transit, all done using the PRT session key. roadtx implements these flows and is able to perform the same authentication. In practice, you can use this module with any client that is either marked as public or has a redirect URL for a native app. By default, the roadtx prtauth module with use the Azure AD PowerShell Module client ID and the Azure AD graph as resource, but you can specify any other client ID or resource URL either by its full part or as an alias (listable with roadtx listaliases):

roadtx prtauth
Tokens were written to .roadtools_auth

Example using the Azure CLI as client ID and requesting tokens for the Azure Resource Manager:

roadtx prtauth -c azcli -r azrm     
Tokens were written to .roadtools_auth

There’s also other options you can use to specify other resources or the correct redirect URL for the app you are using:

Selenium based Azure AD authentication

Command line based token requests and usage are nice, but often you will encounter some flow that either requires a browser window to do Multi Factor Authentication, or you simply want to use your PRT in an interactive way to browse things like the Azure Portal or just read your mail using a stolen PRT. roadtx supports this in various ways, via methods based on Selenium. For Selenium based methods to work you first need to download the gecko driver since roadtx uses Selenium and the gecko driver to control the browser window (based on Firefox). You should either put the geckodriver in your PATH, in the directory you run the roadtx commands from, or any other location if you want to specify the path manually each time.

The principle of Selenium based operations in roadtx is simple: it launches a browser window, tries to autofill any credentials that you supplied to the command, and let you fill in the rest by hand. If you have your accounts set up correctly, it will do the authentication fully automatically. I use this frequently for research purposes where dealing with multiple identities, need to get tokens for different resources, and/or am testing with MFA enabled. It can also be used to automatically inject PRTs into the authentication flow and to use them to browse sites with automatic authentication.

Interactive authentication

In the simplest form, roadtx will launch a browser for you, request a token for the indicated service, fill in any credentials you specified, and obtain tokens. Example:

roadtx interactiveauth -u myuser@mytenant.com -p password

If MFA is required, you can enter that and obtain a token with MFA claim. If not, it will capture the output and save the requested tokens. You can specify the client ID you want to use with -c and the resource to authenticate to with -r. Here’s a short demo:

KeePass credentials based authentication

If you’re dealing with many different accounts during research, copy/pasting credentials and entering MFA information becomes quite tedious. roadtx supports sourcing credentials and TOTP based MFA information from a kdbx file (KeePass file) or KeePass XML export. To use this, use the roadtx keepassauth command. It accepts a KeePass file with the -kp parameter or if you leave this parameter out it tries to load roadtx.kdbx from the current directory. The password of the KeePass file can be specified with -kpp or via the KPPASS environment variable. The only required parameter is the username, which it will look up in the KeePass file. It will autofill the password and also the OTP code if “Mobile app OTP” is enabled as an MFA method on the account. This requires the TOTP seed to be stored in the otp additional parameter of the identity in the KeePass file. For instructions on how to set this up and some caveats of using KeePass files, see the roadtx wiki.

Here is another demo of authentication to the Microsoft Graph using an account that requires MFA, the credentials and OTP are automatically loaded from the KeePass file:

Aside from requesting tokens directly, you can also use this as an interactive browser window with auto authentication. To do this, specify a URL manually that will redirect you to the Microsoft sign-in page. For example, using -url https://myaccount.microsoft.com will open a browser, authenticate you, and go to the “My account” page. You can use --keep-open to keep the browser window open after authentication, which makes it possible to browse to other pages from an authenticated perspective. Example:

roadtx keepassauth -url https://myaccount.microsoft.com --keep-open -u myuser@mytenant.com -kp accounts.kdbx -kpp keepassfilepassword

Primary Refresh Token authentication in browser

A more interesting scenario is using a Primary Refresh Token that you either registered yourself or that you stole from a legitimate endpoint during a red team to create an interactive browser experience. Lets assume that we dumped a PRT and session key using Mimikatz from an endpoint (this is only possible if it doesn’t use a Trusted Platform Module). We can use this PRT on the command line, or we can automatically inject that into our Selenium browser session. roadtx does this by proxying the browser traffic through itself and injecting a PRT cookie at various points during authentication. On the victim endpoint, we can use Mimikatz to dump the PRT and session key, with the following commands:

privilege::debug
sekurlsa::cloudap

Mimikatz gives us the PRT and encrypted session key (the KeyValue of the ProofOfPossesionKey field), which we can decrypt from a SYSTEM context.

token::elevate
dpapi::cloudapkd /keyvalue:cryptedkey /unprotect

The cloudapkd function will give us the clear session key (if not stored in TPM), and a derived key. We will need the clear key for roadtx:

To make our life easier, we renew the PRT first, which will save it in roadtx.prt:

roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>

Now we can request tokens using the interactive browser with roadtx browserprtauth. If we use the roadtx describe command, we see the access token includes an MFA claim because the PRT I used in this case also had an MFA claim.

roadtx browserprtauth
roadtx describe < .roadtools_auth

Similar to the previous command, we can also use this for interactive browsing in the Selenium window:

Primary Refresh Token usage with other accounts

An interesting use case for stolen Primary Refresh Tokens is that you can also use them for other accounts to add device claims to the authentication. For example, if there is a conditional access policy that requires a compliant or hybrid joined corporate device to access specific resources, the device claim originates from the primary refresh token used during authentication. This claim can also be used for other users. So if I have a stolen PRT from a compliant device for user tpmtest@iminyour.cloud, I can use this PRT with the credentials of newlowpriv@iminyour.cloud to sign in and pass the compliancy test.

In this example we still have the stolen PRT from tpmtest@iminyour.cloud used in the example above saved as roadtx.prt. I can use this PRT together with the credentials of newlowpriv that are stored in my KeePass file to sign in to Microsoft Teams and access data there with the roadtx browserprtinject command.

roadtx browserprtinject -u newlowpriv@iminyour.cloud -r msgraph -c msteams

The issued access token will contain the deviceid claim, which is the device from which we stole the PRT. Since this device is Intune managed and compliant, it passes the compliancy requirement:

Adding MFA claims to an existing PRT

Moving back from the PRTs that we stole and back to the PRT we registered earlier using a username + password combination. If we want to have a PRT with MFA claim, we have to use an interactive session that will request a special refresh token from Azure AD for “enriching” our PRT. The command for this is roadtx prtenrich, which like the previous commands accepts an identity in a KeePass file to autofill the MFA information, or you can do this by hand.

roadtx prtenrich -u newlowpriv@iminyour.cloud
Got refresh token. Can be used to request prt with roadtx prt -r <refreshtoken>

The result is a special refresh token that we can use to request a new PRT. For this we go back to the roadtx prt module:

roadtx prt -r <refreshtoken> -c blogdevice.pem -k blogdevice.key

The new PRT is written to disk and when we use it to request tokens we see the MFA claim:

We can use this PRT to obtain tokens for resources that require MFA using any of the above methods.

Single sign on in Windows using Chrome and a custom browsercore

In my first blog on PRTs I described the process that Chrome uses to do Single Sign On in Windows. It uses the browsercore.exe helper program to request PRT cookies to sign in automatically. For roadtx I wrote a small utility called browsercore.py, which can be used as a replacement for browsercore.exe. By doing so, you can use a Primary Refresh Token from roadtx (or one that you stole elsewhere) to automatically authenticate in your Chrome browser on your attacker controlled host. You don’t need to have a Selenium window, but can use the PRT directly just as if you were on the victims machine in a legitimate browser.

The custom SSO requires a few steps to set up:

• You should put the browsercore.py and manifest.json files in some location on disk, for example in C:\browsercore\.
• Install roadtx and place a roadtx.prt file in the same directory.
• Modify HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.microsoft.browsercore to point to C:\browsercore\manifest.json.
• Test whether everything works using bctest.py
• Clear any existing cookies in Chrome for login.microsoftonline.com

Full install instructions are on the ROADtools wiki. After setup, Chrome should use the PRT automatically during sign in. The first time it may need a hint for the username to work properly.

With this setup you can browse any Azure AD connected resource with SSO and the claims from the PRT, including device status and cached MFA information.

Other utilities

There are a few other utilities in roadtx, mostly to make my own research easier:

• roadtx decrypt can decrypt encrypted responses given a PRT session key or a device transport key
• roadtx getotp can calculate an OTP code from a seed or from the otp property stored in a KeePass file (if you need to do MFA for that user)
• roadtx codeauth can perform the OAuth2 code redemption flow for public and confidential clients.
• roadtx listaliases lists all the aliases that are supported for resources and clients. If you need any other aliases that you use frequently feel free to open an issue or send me a message.

Tool download, future work and credits

As always the tools are available and open source on GitHub and on pypi with pip install roadtx. This toolkit was developed during my research of the past years and I will keep adding new stuff to it as that research progresses. Many of the commands currently only work in managed environments (so not in federated), simply because I have not had the time yet to set up a lab with federation.

Thanks to DrAzureAD for developing AADInternals, which inspired the initial device registration development and was a helpful resource on several implementation details. Also a shoutout to TokenTactics which implements many token request/refresh related flows in Powershell.

Background

After reading Oddvar’s blog, I wondered what rights are granted to users when the option “The following user or group can join this computer to the domain”. So I did some tests and set this value to a newly created user “computeracltest”. After creating this computer object, we see that various Access Control Entries (ACEs) are set to this new computer, granting rights to the account we chose. As usual, the GUI is not really helpful here since it shows weird blank values and some instances of “special” which are quite ambiguous.

The “effective access” view is more practical and shows us some interesting additional information: the user can write to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, which is the attribute that gives us access to configure Resource-Based Constrained Delegation.

How we got that access is not quite clear from the ACE view. Some of the ACEs may not be adequately understood by the GUI. So instead, let us look at the raw ACL and what its entries mean. My preferred tool to make these entries readable is the ACL parsing logic of BloodHound.py, which has some extensive parsing logic and debug printing built-in. Because I did this analysis with a newly created user, the only ACEs that matter are those set to that specific user. If we print any ACE we encounter that applies to this user’s SID, which can be done by modifying these lines in BloodHound.py, we can see what ACEs we have.

The ACEs can be separated by type, which is based on the flags of the ACE. ACE numbers 1-4 and 7 have the flag ADS_RIGHT_DS_WRITE_PROP, which indicates that this ACE controls access for writing to a property, indicated by the GUID in ObjectType. ACE number 5 and 6 have the ADS_RIGHT_DS_SELF flag, which is a bit confusing name for a validated write according to the documentation. Validated writes also allow you to write to a property, but the write is subject to additional validation. An example is ACE number 5, which is the validated write to the DNS hostname with restrictions. ACE number 8 is a simpler ACE not restricted to a specific property but with the ADS_RIGHT_DS_CONTROL_ACCESS flag. This flag controls extended rights, and since there is no specific extended right specified, this ACE grants the “all extended rights” permissions that Oddvar wrote about in his blog.

Ignoring these leaves us with a few ACEs to inspect, each of which grants write access to a specific property. The property IDs are mapped to names in the Active Directory schema, but we can also put the GUIDs in Google to find the corresponding property in the Microsoft documentation. This gives the following properties:

1. 5F202010-79A5-11D0-9020-00C04FC2D4CF: User-Logon property set.
2. BF967950-0DE6-11D0-A285-00AA003049E2: Description attribute.
3. BF967953-0DE6-11D0-A285-00AA003049E2: Display-Name attribute.
4. 3E0ABFD0-126A-11D0-A060-00AA006C33ED: SAM-Account-Name attribute.
5. Validated write to DNS host name (I’ve written about this right before).
6. Validated write to service principal name.
7. 4C164200-20C0-11D0-A768-00AA006E0529: User-Account-Restrictions property set.

The above pages give us several attributes, but none that make it clear why we have the rights on the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. For this, we have to dig deeper into numbers 1 and 7, which are property sets instead of single attributes.

Property sets in Active Directory

If you don’t know what property sets are or how exactly they work, don’t worry, I didn’t either before diving into this. Some searching in the documentation teaches us that a property set maps to multiple properties, so you don’t have to create an ACE for every single property you want to grant access to. Unfortunately, the documentation for the property sets linked in the list above is not updated beyond Server 2012, so it doesn’t tell us what properties are included in these sets on more modern OS versions. Back to querying this from the AD schema, where all these properties are defined. When we look at the properties of the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, we see that it references attributeSecurityGUID 4C164200-20C0-11D0-A768-00AA006E0529:

This is the same GUID as we saw for “User-Account-Restrictions” that we saw for ACE number 7 above. A look at the Extended Rights configured in the Configuration partition of AD shows us the same GUID for the User-Account-Restrictions property set.

We can use this information to reconstruct all the property sets and the properties they contain in the default AD schema by creating a mapping between the properties and their set (if any). I’ve written a short python script that does just that, which gives us all the attributes contained in the User-Account-Restrictions property set, including msDS-AllowedToActOnBehalfOfOtherIdentity.

With this, we can conclude that it’s ACE number 7 that gives us the rights to modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute, which allows us to configure Resource-Based Constrained Delegation.

Abusing the “Everyone” case and more abuse options

To go back to our original idea, when an admin adds a computer to the domain and gives “everyone” or “authenticated users” the permission to join the computer to the domain, these groups also get the permission to configure RBCD. If we add this extra logic to the BloodHound data collector and run it again, we will see these new “AddAllowedToAct” edges showing up in our data. There is a second case in which these permissions get set, which is when a computer object is created via LDAP, in which case the user that created the account will get the permissions that allow them to configure RBCD. This may be another lateral movement opportunity in case an attacker compromises an account that is commonly used to join machines to the domain.

After adding the new ACL property logic to BloodHound.py, and diffing the output with SharpHound, we see the extra AddAllowedToAct edges showing up:

Loading this data into BloodHound, we can use the following query to find our nice new edges. Note: the edge was renamed to WriteAccountRestrictions after merging into the main BloodHound code. Both SharpHound and BloodHound.py now report this as WriteAccountRestrictions, so the query changes from the naming used above:

MATCH p=(g)-[:WriteAccountRestrictions]->(c:Computer) WHERE NOT g.highvalue RETURN p

Or to focus on cases exploitable from any authenticated user, the following query is useful:

MATCH p=(g)-[:WriteAccountRestrictions]->(c:Computer) WHERE g.objectid ENDS WITH "S-1-1-0" OR g.objectid ENDS WITH "-513" OR g.objectid ENDS WITH "S-1-5-11" OR g.objectid ENDS WITH "-515" RETURN p

This shows the following result in my test lab, since I added a computer with the “everyone” permissions to the domain:

We can configure RBCD by modifying the object over LDAP, for example by using rbcd.py from impacket. As a general reminder: to exploit this, you would need access to a computer account in most cases, which you can either do by dumping the credentials of an existing host from the registry, or by registering a new computer object in AD if that is allowed (which it is by default). In this case, I’m abusing ICORP-W10 as an account for which I dumped the password.

As the last step, we can obtain a service ticket impersonating a Domain Admin account to access the victim host:

If this was a real computer instead of only a pre-created account, we could use this ticket to login in over SMB and for example run secretsdump.

Mitigating and monitoring

If you’re on the blue side, you can perform the same BloodHound queries to identify misconfigured computer objects. For the actual mitigation, remove the vulnerable ACEs on these objects. I recommend removing any ACE that was set to allow the specific user or group to domain join the computer, which are similar to the screenshot in the beginning of this blog and are all scoped to that user/group and set to “This object only”. At the minimum, remove the Write account restrictions and the Special (which means “All extended rights” in this case) ACEs.

Modifying the msDS-AllowedToActOnBehalfOfOtherIdentity attribute is not monitored by default in AD. Assuming you already have “Audit Directory Service Changes” audit logging enabled, an auditing entry (SACL) needs to be added to monitor changes to this attribute. You could configure this on the domain root or on all OUs/containers that contain computer objects. It should apply to “Descendant computer objects” and the property to monitor is Write msDS-AllowedToActOnBehalfOfOtherIdentity as shown below:

Once this is set up, event ID 5136 will be logged whenever RBCD is changed on a computer object, which should rarely occur since I’ve yet to hear from someone using this legitimately.

Other changes to BloodHound.py

This feature is now present in version 1.3.0 of BloodHound.py which is available from GitHub or via PyPi. There have been other improvements/optimizations that are included in this release:

• Session enumeration via the HKU registry hive is now supported thanks to @itm4n.
• BloodHound.py will automatically chunk large JSON files to prevent huge files in large networks that the GUI crashes on while ingesting.
• When doing DCOnly collection, BloodHound.py will use its memory more efficiently and not cache everything when not needed.
• You can now supply a file with computer hostnames for session/loggedon/etc enumeration that will restrict enumeration to only those computers.
• Connections to LDAP that time out/are lost during data gathering are automatically re-established if possible.
• A new tool createforestsidcache.py is available that creates a cache of all objects in the entire forest. This creates massive speedups for multi-domain AD environments with a lot of cross-domain privileges.
• Bugfixes and general improvements.
• Python 2 support is dropped, only Python 3 is supported now.

Something that is not quite new but was not publicly announced before is BloodHound.py’s capabilities to gather information about credentials stored on hosts in scheduled tasks or as part of services. While this method requires administrator privileges to collect, it does gather credentials that could be recoverable from hosts that aren’t always gathered using other session collection methods. You can activate these collection methods by adding experimental to your list of collection methods.

Tools

The new ACL edge has been added to both BloodHound.py and the official BloodHound and it’s SharpHound data collector. The edge was renamed to WriteAccountRestrictions for clarity. If you have the latest version of BloodHound it should support this out-of-the-box without additional requirements. I think this kind of attack pattern may be common in the wild, but I don’t have any solid data on it, so if you find some instances of it when this is configured in real environments (either from the red side or the blue side), please let me know!

Kerberos over DNS

If you’re familiar with Kerberos you know that DNS is a critical component in having a working Kerberos infrastructure. But did you know that DNS in Active Directory also supports authenticated operations over DNS using Kerberos? This is part of the “Secure dynamic updates” operation, which is used to keep the DNS records of network clients with dynamic addresses in sync with their current IP address. The following image shows the steps involved in the dynamic update process:

The steps are as follows (following the packets above from top to bottom). In this exchange the client is a Windows 10 workstation and the server is a Domain Controller with the DNS role.

1. The client queries for the Start Of Authority (SOA) record for it’s name, which indicates which server is authoritative for the domain the client is in.
2. The server responds with the DNS server that is authorative, in this case the DC icorp-dc.internal.corp.
3. The client attempts a dynamic update on the A record with their name in the zone internal.corp.
4. This dynamic update is refused by the server because no authentication is provided.
5. The client uses a TKEY query to negotiate a secret key for authenticated queries.
6. The server answers with a TKEY Resource Record, which completes the authentication.
7. The client sends the dynamic update again, but now accompanied by a TSIG record, which is a signature using the key established in steps 5 and 6.
8. The server acknowledges the dynamic update. The new DNS record is now in place.

Let’s take a closer look at steps 5 and 6. The TKEY query is actually sent over TCP because its quite a bit larger than the maximum 512 bytes allowed over UDP. This is primarily because of the rather large TKEY additional record, which contains structures we often see for Kerberos authentication:

It turns out this query contains a full GSSAPI and SPNEGO structure containing a Kerberos AP-REQ. This is essentially a normal Kerberos authentication flow to a service. The reply contains again a GSSAPI and SPNEGO structure indicating authentication succeeded, and replying with an AP-REP. This AP-REP contains a new session key that can be used by the client to sign their DNS queries via a TSIG record. Note that the encAPRepPart is normally encrypted with the session key that only the client and the server know, but because I loaded the Kerberos keys of various systems in my test domain into a keytab that Wireshark accepts, we can decrypt the whole exchange to see what it contains.

The concept of this flow is fairly simple (the actual implementation is not). The client uses Kerberos to authenticate and securely exchange a session key, and then uses that session key to sign further update queries. The server can store the key and the authenticated user/computer and process the updates in an authenticated manner without having to tie an authentication to a specific TCP socket, as later queries may be sent over UDP.

Abusing DNS authentication

If we are in a position to intercept DNS queries, it is possible to trick the victim client into sending us a Kerberos ticket for the real DNS server. This interception can be done in the default Windows configuration by any system in the same (V)LAN using mitm6. mitm6 advertises itself as a DNS server, which means that the victim will send the SOA to our fake server, and authenticate using Kerberos if we refuse their dynamic update. Now this is where it gets a bit tricky. Usually the DNS server role will be running on a Domain Controller. So the service ticket for the DNS service will already be suitable for services running on the DC, since they use the same account and we can change the service name in the ticket. This means we can relay this ticket to for example LDAP. However, if we take a closer look at the authenticator in the TKEY query, we see that the flag that requests integrity (signing) is set.

This will automatically trigger LDAP signing, which makes the whole attack fail since we can’t interact with LDAP afterwards without providing a valid cryptographic signature on each message. We can’t produce this signature since we relayed the authentication and do not actually possess the Kerberos keys required to decrypt the service ticket and extract the session key.

This initially made me hit a wall for two reasons:

1. At the time there weren’t any default high value services known that would accept authentication with the integrity flag set, but not enforce it on a protocol level.
2. The client specifically requests the “dns” service class in the SPN they use in their Kerberos ticket request. This SPN is only set on actual DNS servers, so the number of legitimate hosts to relay to would be quite low.

Revisiting this after reading James’ blog, I realized neither of these are an issue with todays knowledge:

1. Since the AD CS research was published by Lee Christensen and Will Schroeder, we have a high-value endpoint that is present in most AD environments, and provides code execution possibilities on the victim, as described in my last blog on AD CS relaying.
2. As James describes in his blog, many service classes will actually implicitly map to the HOST class. As it turns out, this includes DNS, so when our victim requests a ticket for the DNS service, this actually works for any account with the HOST SPN. This is set on all computer accounts in the domain by default, so any service running under these accounts can be targeted.

With these 2 solved, there’s nothing really that prevents us from forwarding the Kerberos authentication we receive on our fake DNS server to AD CS. When that is done we can request certificates for the computer account we relayed, and use the NT hash recovery technique or the S4U2Self trick that I talked about in my previous blog. Using these techniques we can get SYSTEM access on the victim computer, which effectively makes this a reliable RCE as long as an AD CS http endpoint is available for relaying.

Changes to krbrelayx and mitm6

Originally, krbrelayx was not really a relaying tool. Instead it was capturing Kerberos TGTs by using unconstrained delegation configured (system) accounts, and using those TGTs in the same manner as ntlmrelayx can use incoming NTLM authentication. Since there is now a use-case to actually relay Kerberos authentication, I’ve updated the functionality in krbrelayx to make it possible to run in relay mode instead of in unconstrained delegation mode. It will actually default to this mode if you don’t specify any NT hashes or AES keys that could be used to extract information from incoming Kerberos authentication. In short, krbrelayx can now be used to relay Kerberos authentication, though only relaying to HTTP and LDAP is supported. As for mitm6, I’ve added the option to specify a relay target, which will be the hostname in the authorative nameserver response when a victim asks queries the SOA record. This will make the victim request a Kerberos service ticket for the service we are targeting rather than for the legitimate DNS server.

One thing to note that this works best when the AD CS server that is targeted is not the DC that the victim is using for Kerberos operations. If they are on the same host (such as in smaller or lab environments) targeting the server which is both a KDC and AD CS server may result in the victim sending it’s Kerberos ticket requests (TGS-REQ) to you instead of the DC. While you could proxy this traffic, this is beyond the scope of this project and you may end up not getting any authentication data.

There is one final hurdle that we have to take. The Kerberos AP-REQ actually does not tell us which user is authenticating, this is only specified in the encrypted part of the Authenticator. So we don’t know which user or machine account is authenticating to us. Luckily for us, this does not really matter in the default AD CS templates scenario, since these allow any name to be specified as CN and it is overwritten by the name in Active Directory anyway. To obtain the best results however, I recommend you scope the attack to one host at the time using mitm6, and to specify that hostname with --victim in krbrelayx so it will fill in the fields correctly.

Attack example

Let’s see how this looks in practice. First we set up krbrelayx, specifying the AD CS host (in my lab adscert.internal.corp) as target, and specifying the IPv4 address of the interface as interface to bind the DNS server on. This prevents conflicts with DNS servers that commonly listen on the loopback adapter on for example Ubuntu.

sudo krbrelayx.py --target http://adscert.internal.corp/certsrv/ -ip 192.168.111.80 --victim icorp-w10.internal.corp --adcs --template Machine

Then we set up mitm6, using the name of the AD CS host as relay target:

sudo mitm6 --domain internal.corp --host-allowlist icorp-w10.internal.corp --relay adscert.internal.corp -v

We wait for our victim to get an IPv6 address and connect to our rogue server:

The screenshot shows the victim tried to update their DNS record, which we refused to do because of the lack of authentication. The authentication is sent via TCP to the DNS server of krbrelayx, which accepts this and forwards it to AD CS:

On the wire, we see the expected flow:

• The victim (192.168.111.73) queries for a SOA record of their hostname.
• We indicate that our rogue DNS server is the authoritative nameserver, to which the victim will send their dynamic update query.
• The query is refused by mitm6, which will indicate to the victim that they need to authenticate their query.
• The client talks to the KDC to get a Kerberos ticket for the service we indicated.
• The client establishes a TCP connection to krbrelayx and sends a TKEY query containing the Kerberos ticket.
• The ticket is forwarded to the AD CS host which results in our authentication succeeding and a certificate being issued.

With this certificate we can use PKINITtools (or Rubeus on Windows)to authenticate using Kerberos and impersonate a Domain Admin to gain access to our victim (in this case icorp-w10):

python gettgtpkinit.py -pfx-base64 MIIRFQIBA..cut...lODSghScECP5hGFE3PXoz internal.corp/icorp-w10$ icorp-w10.ccache

With smbclient.py we can list the C$ drive to prove we have admin access:

Defenses

This technique abuses insecure defaults in Windows and Active Directory. The primary issues here are the preferrence of IPv6 by Windows, and the bad security defaults on the AD CS web applications. These can be mitigated as follows:

Mitigating mitm6

mitm6 abuses the fact that Windows queries for an IPv6 address even in IPv4-only environments. If you don’t use IPv6 internally, the safest way to prevent mitm6 is to block DHCPv6 traffic and incoming router advertisements in Windows Firewall via Group Policy. Disabling IPv6 entirely may have unwanted side effects. Setting the following predefined rules to Block instead of Allow prevents the attack from working:

• (Inbound) Core Networking - Dynamic Host Configuration Protocol for IPv6(DHCPV6-In)
• (Inbound) Core Networking - Router Advertisement (ICMPv6-In)
• (Outbound) Core Networking - Dynamic Host Configuration Protocol for IPv6(DHCPV6-Out)

Mitigating relaying to AD CS

The default CertSrv site does not use TLS, this should be enforced first before further protections can be enabled. After enabling TLS with a valid certificte, enabling Extended Protection for authentication in IIS will prevent relay attacks. This should be enabled on all the web-based enrollment features of AD CS on all individual CA servers that offer this service.

Tools

All the tools mentioned in this blog are available as open source tools on GitHub.

• mitm6 https://github.com/dirkjanm/mitm6
• krbrelayx https://github.com/dirkjanm/krbrelayx
• PKINITtools https://github.com/dirkjanm/PKINITtools

Thanks to all the people mentioned in this blog and my previous posts on these topics for their research and tool contributions.

Background - the state of NTLM relaying

I’ve written quite some times about NTLM relaying ever since I started contributing to ntlmrelayx in 2017. Despite NTLM relaying mitigations that were introduced ever since the first NTLM relay attacks that were introduced around 2001, the past few years have seen many exploits, but hardly any new mitigations to make this horrible protocol more secure. Even the scheduled change to enforce LDAP signing and channel binding by default, which was supposed to be deployed in 2020, ultimately did not ship, likely due to many third-party products not being compatible with this. This meant that in the default state with fully up-to-date systems, it was possible to:

• Relay NTLM authentication occurring over HTTP to LDAP, resulting in computer account takeover
• Relay authentication over SMB to HTTP endpoints, but not to LDAP because of a signing requirements mismatch. Since no research was published on high-value default HTTP endpoints, this prevented exploitation of ways to get authenticated SMB connections via the infamous Printer Bug.

This all changed when Lee Christensen and Will Schroeder published their whitepaper on abusing Active Directory Certificate Services. In this whitepaper they describe an attack called ESC8, which involves NTLM relaying to the HTTP interface part of the certificate service, which issues certificates. Because this interface accepts NTLM authentication without support for signing, it is possible to:

1. Request an authenticated back-connect with the Printer Bug over MS-RPRN, as long as the spool service is running on the victim system.
2. Receive this authentication and relay this to the certificate services web interface.
3. Request a certificate on behalf of the victim system.
4. Use the issued certificate to impersonate the victim system.
5. Either use the privileges of the victim system directly (for example in the case of a Domain Controller), or use Kerberos features to request a service ticket with administrative access to the host itself or request the NT hash for the system account which allows you to create a silver ticket.

The printer bug has already been known for quite a while and has been a component in many attacks. Disabling the printer spooler service has been a common recommendation ever since, and has recently been brought to light again with the PrintNightmare exploit, which also relied on the spooler service being active. It was kind of a given that other methods must exist for coercing authentication via RPC methods, and I expect some are also keeping these methods private. Following the AD CS release, Lionel Gilles released a new proof-of-concept way to exploit this last week called PetitPotam. Unlike the printer bug, which uses MS-RPRN and requires authentication, this attack is an alternative method that does not rely on the printer spooler service being active, and does not require authentication when attacking a Domain Controller. This makes it an even more valuable attack alternative, as there is no official way as of now to disable this authenticated callback and there is no indication of a fix in sight.

Exploring AD CS relaying

After Will and Lee published their whitepaper, I was curious whether I could reproduce their attack on relaying to the certificate services web interface. ntlmrelayx is plugin based and quite modular, so the only thing that would likely be required is changing the http attack method to post the right data. After ensuring the web enrolment service is installed in my lab, I went to have a look at the source code of the service. This source is stored in C:\Windows\system32\CertSrv\en-US on the server where the AD CS service is installed (in my case and in many others this will probably be the Domain Controller). I imagine the last folder may be different if you installed your system in a different language. Since the pages are written in classic ASP, it is not that hard to read the source code. The copyright mentions 1998 - 1999, which is always a great sign if you’re looking for things with a less than ideal security configuration.

When visiting the AD CS web interface at http://dc-hostname/certsrv/, we can authenticate using NTLM and a machine account. An easy way to obtain a machine account is with impacket’s addcomputer.py, which can be used as any authenticated user to add a new computer account by default (note that we’re only doing this to understand the attack in the lab, this is not required for the final attack). We can then use NTLM to authenticate to the AD CS web service (it’s easier to do this from a non-domain joined computer or from a browser that doesn’t perform Single Sign On). In this case I’m using Chrome, which can perform NTLM auth by using the computername$@domain.fqdn syntax in the credential prompt. This lets us authenticate as a computer account to the web service. Upon following the certificate request process, we get the following error message: “No certificate templates could be found. You do not have permission to request a certificate from this CA, or an error occurred while accessing the Active Directory.”. At first I thought this indicated a problem with my setup, because computer certificate templates are available by default. After some debugging and reading the source I found the reason in certsgcl.inc:

As we can see in the highlighted section, whenever the “choice” of certificate templates is rendered in the web page, the server does not actually query for machine templates. The reasoning behind this is probably that machines are not quite supposed to use the guided way of requesting certificates, so it doesn’t make sense to render them. Does this mean that we can’t request machine certificates via this interface? Not quite, as the page where the final request is submitted does not actually perform this check but simply submits the request to the CA, so we could use any certificate template here. I’ve patched the file and added the constant to also search for machine templates, and the template appears in the UI:

Now we can submit a basic request. The only requirement is that we selected the correct template (Computer) and use the hostname of our newly created computer as Common Name. Note that this must match the dNSHostname attribute of the computer object, so make sure you run addcomputer.py with the -method LDAPS option otherwise this won’t be the case for our test account. We can create this with openssl, and then submit the request. We see that is immediately issued to us, because the default Computer template does not require approval.

Requesting this with the dev tools open will show us the POST request, which goes to certfnsh.asp.

With this information we can build our custom AD CS relay attack. The template for the http attack in ntlmrelayx begins with an authenticated session. Building on this we can create a private key and certificate on the fly, and submit this request to the CA. After submitting the request, we get the certificate that was issued to us and use it to authenticate.

The template that can be used depends on the account that is relayed. For a member server or workstation, the template would be “Computer”. For Domain Controllers this template gives an error because a DC is not a regular server and is not a member of “Domain Computers”. So if you’re relaying a DC then the template should be “DomainController” to match.

I did not initially want to publish the exploit code because Will and Lee also held off publishing theirs, but of course several people managed to reproduce the same attack pattern as above based on the whitepaper. A pull request for impacket soon appeared by user ExAndroidDev, which implements more or less the same code. If you’re curious about my implementation, I included a proof-of-concept version of the http attack file in the PKINITtools repository. If you want to play with this template you’ll have to change the template and the domain manually before copying it to the correct impacket directory and running ntlmrelayx. Below is an example of the attack running:

Note that this is fully unauthenticated (a feature of PetitPotam when used against DC’s) and instantly escalates to Domain Controller privileges.

Abusing the obtained certificate - diving into PKINIT

To actually use these certificates for Kerberos with PKINIT, we can use either Rubeus or kekeo. Both of these tools have the downside that they only work on Windows. Originally I wanted to see if I could also port the PKINIT functionality to impacket, because if I could manage to get a regular TGT from the initial PKINIT operation this would allow us to use it with the other impacket tools such as secretdump and smbclient without any additional changes. I went down the rabbit hole of implementing the PKINIT ASN1 structures in impacket, but soon found out that the PKINIT specification itself uses structures from a multitude of different RFCs for it’s cryptographic operations. I did some more searching for projects that already used PKINIT in Python and found that AzureADJoinedMachinePTC has an impacket based implementation, and that SkelSec’s minikerberos has a custom implementation as well. Both these implementations are written for Azure AD joined devices to use SMB and authenticate with certificates. This differs from our goal because Azure AD uses user-to-user (U2U) Kerberos without a central KDC. The PKINIT process is embedded in NegoEx over SMB. For using certificates in Active Directory, we don’t need the U2U implementation or the NegoEx parts. But most of the code for PKINIT was already there so I decided to built forth on that rather than reinvent the wheel. The minikerberos project was the implementation of choice because AzureADJoinedMachinePTC does not actually implement the required signing operations in Python, but uses Windows API’s for that, which prevents it on working on other operating systems.

I will save you the rant about ASN1 and about the many hours it took me to figure out that Active Directory for some reason does not consider Diffie-Hellman parameters generated by the cryptography library strong enough (without documentation I could find about the requirements or about why this is), so I had to borrow some known-safe primes instead. The end result of this is a simple command line tool that can take a certificate and private key, either in PFX or in PEM format, and request a TGT using PKINIT.

Obtaining the NT hash of the impersonated computer account

One of the features described in the whitepaper from Will and Lee is the ability to obtain the original NT hash for an account by using the certificate. This is described as “THEFT5” in the whitepaper. The reason behind this is that when certificate authentication is used and a TGT is obtained, there has to be some way for the account performing the authentication to fall back to NTLM authentication if Kerberos is not supported. For that reason, the KDC will supply the NT hash of the account in the PAC that is added to the TGT (if you’re not sure what a PAC is or what is in there, I recommend you read my blog on forest trusts).

There is some interesting process involved in this. Whenever PKINIT authentication is used, the KDC adds the NT hash in an encrypted format to the PAC. This is encrypted with the same key as that is negotiated between the KDC and the client for encrypting the session key for the TGT. This key is negotiated with Diffie-Hellman key exchange or is encrypted using the public key of the certificate, depending on the implementation. The result of this is a key called the “AS reply key” in the documentation in MS-PAC. The PAC is contained inside the TGT, which is encrypted with one of the Kerberos keys of the krbtgt account. This makes it impossible for our client to actually read the PAC.

The way to read the PAC and to access the NT Hash is done via the Kerberos user to user (U2U) extensions. This extension introduces an option called ENC-TKT-IN-SKEY, which encrypts the resulting service ticket using the session key from a supplied TGT rather than with the key of the target service/user. This session key is in our possession (we need it to use our TGT), so we can use this to decrypt the service ticket, containing the PAC. The whole process is as follows:

1. Request a TGT using PKINIT and note down the AS reply key (the gettgtpkinit.py tool prints the key for you as you can see in the screenshot above).
2. Request a service ticket to ourself, while supplying the ENC-TKT-IN-SKEY option and adding the TGT that was issued to us to the “additional tickets” section of the TGS-REQ
3. The KDC will copy over the PAC, with the encrypted NT hash, to the ticket that is issued, and will encrypt this ticket with the session key of our TGT (which is known to us)
4. Using the session key we can decrypt the ticket, extract the PAC, and parse + decrypt the NT hash using the AS reply key

The proof-of-concept for this, which is mostly based on getPac.py from impacket and on reading the kekeo source code is called getnthash.py. Here’s a demo:

Abuse

With the NT hash in our possession (which is the NT hash of the computer account that we originally relayed), we can perform attacks as that account using any tool that supports hashes for machine authentication. Alternatively, to get access to the original host we could use the hash as RC4 Kerberos key to create a silver ticket, which can contain any user claim and will be accepted by the host.

Using S4U2Self to obtain access to the relayed machine

There is another approach to obtain access to the machine we originally relayed. Aside from using the NT hash for a silver ticket, we can also use the TGT from earlier directly. This can be done via S4U2Self. If you’re not familiar with this, the S4U2Self extension makes it possible for a Kerberos service to request a ticket on behalf of anyone towards itself, as long as the service has an SPN registered. This is also (ab)used in many delegation scenario’s, and was documented as attack by Elad Shamir. The relevant bit is that because we have a TGT for the system we want to attack, we can request a legitimate service ticket for any user that is accepted by the original system (since it’s encrypted with it’s own service key). I once again wrote a small command line tool for this based on some minikerberos example, which is called gets4uticket.py. You should supply the ccache containing the TGT and an SPN that belongs to the system for which the TGT was issued. Then we can ask for a ticket for any user, in this case the “Administrator” user.

This ticket does indeed have Administrative access on my domain controller, as demonstrated by the ability to list the contents of the c$ drive:

Other abuse avenues of PetitPotam

PetitPotam also makes it possible to cause a backconnect over WebDAV, provided the webdav service is running. The advantage of WebDAV is that authentication happens over HTTP, which can be relayed to LDAP in the default configuration. This makes it possible to perform attacks based on Resource Based Constrained Delegation, similar to previous blogs on this topic. Maximus recently wrote a nicely summarized Gist on this which contains the required steps and ways to get the WebDAV service running.

Defenses

There has already been written a lot about defenses on this topic, and there are extensive guidelines on mitigating relaying to AD CS in Lee and Will’s whitepaper. There is also the official Microsoft recommendation. Personally I’d like to summarize the possible defenses as follows:

• Mitigate NTLM relaying attacks as much as possible by enforcing security features on sensitive services, such as LDAP signing + channel binding on the DCs and HTTPS + enhanced protection on IIS based services.
• Prevent services from authenticating to arbitrary workstations by disallowing traffic initiated from servers to workstations. An allowlist of required connections could be used if server to workstation traffic is required for some services.
• Disable known vulnerable services as much as possible (Spooler Service).
• Work on phasing out NTLM entirely.

Credits / Thanks / Tools

As stated before, not much of this is my original work, and all credits go to the people referenced already in this post. The tools/adaptions shown in this blog are available on my GitHub under PKINITtools.