Skip to content

Latest commit

 

History

History
138 lines (88 loc) · 7.98 KB

az-device-registration.md

File metadata and controls

138 lines (88 loc) · 7.98 KB
Raw

Az - Device Registration

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Basic Information

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).:

dsregcmd /status

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:

{% content-ref url="az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md" %} az-primary-refresh-token-prt.md {% endcontent-ref %}

TPM - Trusted Platform Module

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):

{% content-ref url="az-lateral-movement-cloud-on-prem/pass-the-prt.md" %} pass-the-prt.md {% endcontent-ref %}

Registering a device with SSO tokens

It would be possible for an attacker to request a token for the Microsoft device registration service from the compromised device and register it:

# Initialize SSO flow
roadrecon auth prt-init
.\ROADtoken.exe <nonce>

# Request token with PRT with PRT cookie
roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>

# Custom pyhton script to register a device (check roadtx)
registerdevice.py

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.

{% hint style="success" %} 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. {% endhint %}

{% hint style="danger" %} 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. {% endhint %}

Overwriting a device ticket

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.

{% hint style="danger" %} However, this was fixed. {% endhint %}

Overwrite WHFB key

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:

roadtx genhellokey -d <device id> -k tempkey.key

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:

{% content-ref url="az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md" %} az-phishing-primary-refresh-token-microsoft-entra.md {% endcontent-ref %}

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}