Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
When a device joins AzureAD a new object is created in AzureAD.
When registering a device, the user is asked to login with his account (asking for MFA if needed), then it request tokens for the device registration service and then ask a final confirmation prompt.
Then, two RSA keypairs are generated in the device: The device key (public key) which is sent to AzureAD and the transport key (private key) which is stored in TPM if possible.
Then, the object is generated in AzureAD (not in Intune) and AzureAD gives back to the device a certificate signed by it. You can check that the device is AzureAD joined and info about the certificate (like if it's protected by TPM).:
After the device registration a Primary Refresh Token is requested by the LSASS CloudAP module and given to the device. With the PRT is also delivered the session key encrypted so only the device can decrypt it (using the public key of the transport key) and it's needed to use the PRT.
For more information about what is a PRT check:
Az - Primary Refresh Token (PRT)The TPM protects against key extraction from a powered down device (if protected by PIN) nd from extracting the private material from the OS layer. But it doesn't protect against sniffing the physical connection between the TPM and CPU or using the cryptograpic material in the TPM while the system is running from a process with SYSTEM rights.
If you check the following page you will see that stealing the PRT can be used to access like a the user, which is great because the PRT is located devices, so it can be stolen from them (or if not stolen abused to generate new signing keys):
Az - Pass the PRTIt would be possible for an attacker to request a token for the Microsoft device registration service from the compromised device and register it:
Which will give you a certificate you can use to ask for PRTs in the future. Therefore maintaining persistence and bypassing MFA because the original PRT token used to register the new device already had MFA permissions granted.
Note that to perform this attack you will need permissions to register new devices. Also, registering a device doesn't mean the device will be allowed to enrol into Intune.
This attack was fixed in September 2021 as you can no longer register new devices using a SSO tokens. However, it's still possible to register devices in a legit way (having username, password and MFA if needed). Check: roadtx.
It was possible to request a device ticket, overwrite the current one of the device, and during the flow steal the PRT (so no need to steal it from the TPM. For more info check this talk.
However, this was fixed.
Check the original slides here
Attack summary:
It's possible to overwrite the registered WHFB key from a device via SSO
It defeats TPM protection as the key is sniffed during the generation of the new key
This also provides persistence
Users can modify their own searchableDeviceKey property via the Azure AD Graph, however, the attacker needs to have a device in the tenant (registered on the fly or having stolen cert + key from a legit device) and a valid access token for the AAD Graph.
Then, it's possible to generate a new key with:
and then PATCH the information of the searchableDeviceKey:
It's possible to get an access token from a user via device code phishing and abuse the previous steps to steal his access. For more information check:
Az - Phishing Primary Refresh Token (Microsoft Entra)Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
