# 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/pass-the-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 <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**.

> [!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).

<figure><img src="../../images/image (32).png" alt=""><figcaption></figcaption></figure>

> [!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**

<figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>

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 <device id> -k tempkey.key
```

and then PATCH the information of the searchableDeviceKey:

<figure><img src="../../images/image (36).png" alt=""><figcaption></figcaption></figure>

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-phishing-primary-refresh-token-microsoft-entra.md
{{#endref}}

<figure><img src="../../images/image (37).png" alt=""><figcaption></figcaption></figure>

## 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}}


