# Az - Device Registration {{#include ../../banners/hacktricks-training.md}} ## 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).: ```bash 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: {{#ref}} az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}} ### 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): {{#ref}} az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}} ## 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: ```bash # Initialize SSO flow roadrecon auth prt-init .\ROADtoken.exe # Request token with PRT with PRT cookie roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-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**. > [!TIP] > 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**. > [!CAUTION] > 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**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md). ## 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**](https://youtu.be/BduCn8cLV1A).
> [!CAUTION] > However, this was fixed. ## Overwrite WHFB key [**Check the original slides here**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf) 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: ```bash roadtx genhellokey -d -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: {{#ref}} az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}}
## References - [https://youtu.be/BduCn8cLV1A](https://youtu.be/BduCn8cLV1A) - [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g) - [https://www.youtube.com/watch?v=AFay_58QubY](https://www.youtube.com/watch?v=AFay_58QubY) {{#include ../../banners/hacktricks-training.md}}