# Az - Registrazione del dispositivo

{{#include ../../banners/hacktricks-training.md}}

## Informazioni di base

Quando un dispositivo si unisce a AzureAD viene creato un nuovo oggetto in AzureAD.

Durante la registrazione di un dispositivo, all'**utente viene richiesto di accedere con il suo account** (richiedendo MFA se necessario), quindi vengono richiesti token per il servizio di registrazione del dispositivo e infine viene mostrata una richiesta di conferma.

Poi, sul dispositivo vengono generate due RSA keypairs: la **device key** (**public** key) che viene inviata a **AzureAD** e la **transport** key (**private** key) che viene memorizzata nel TPM se possibile.

Poi, l'**object** viene generato in **AzureAD** (non in Intune) e AzureAD restituisce al dispositivo un **certificate** firmato da esso. Puoi verificare che il **device is AzureAD joined** e informazioni sul **certificate** (come se è protetto da TPM).:
```bash
dsregcmd /status
```
Dopo la registrazione del dispositivo un **Primary Refresh Token** viene richiesto dal modulo LSASS CloudAP e fornito al dispositivo. Con il PRT viene anche consegnata la **chiave di sessione crittografata in modo che solo il dispositivo possa decifrarla** (usando la chiave pubblica del transport key) ed è **necessaria per usare il PRT.**

Per maggiori informazioni su cos'è un PRT consulta:

{{#ref}}
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
{{#endref}}

### TPM - Trusted Platform Module

Il **TPM** **protegge** contro l'**estrazione** delle chiavi da un dispositivo spento (se protetto da PIN) e dall'estrazione del materiale privato dallo strato OS.\
Ma non **protegge** contro lo **sniffing** della connessione fisica tra il TPM e la CPU o contro l'**uso del materiale crittografico** nel TPM mentre il sistema è in esecuzione da un processo con diritti **SYSTEM**.

Se consulti la pagina seguente vedrai che il **furto del PRT** può essere usato per ottenere accesso come l'**utente**, il che è significativo perché il **PRT è memorizzato sui dispositivi**, quindi può essere rubato da essi (o, se non rubato, abusato per generare nuove chiavi di firma):

{{#ref}}
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
{{#endref}}

## Registering a device with SSO tokens

Sarebbe possibile per un attaccante richiedere un token per il Microsoft device registration service dal dispositivo compromesso e registrarlo:
```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 **certificato che puoi usare per chiedere PRTs in futuro**. Pertanto mantenendo persistenza e **bypassing MFA** perché il token PRT originale usato per registrare il nuovo dispositivo **aveva già i permessi MFA concessi**.

> [!TIP]
> Nota che per eseguire questo attacco avrai bisogno dei permessi per **registrare nuovi dispositivi**. Inoltre, registrare un dispositivo non significa che il dispositivo sarà **consentito per l'enrol in Intune**.

> [!CAUTION]
> Questo attacco è stato corretto a settembre 2021 in quanto non è più possibile registrare nuovi dispositivi usando SSO tokens. Tuttavia, è ancora possibile registrare dispositivi in modo legittimo (avendo username, password e MFA se necessario). Controlla: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md).

## Sovrascrivere un device ticket

Era possibile **richiedere un device ticket**, **sovrascrivere** quello corrente del dispositivo e durante il flusso **rubare il PRT** (quindi non c'è bisogno di rubarlo dal TPM). Per maggiori info [**vedi questo talk**](https://youtu.be/BduCn8cLV1A).

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

> [!CAUTION]
> Tuttavia, questo è stato corretto.

## Overwrite WHFB key

[**Check the original slides here**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)

Riepilogo dell'attacco:

- È possibile **sovrascrivere** la **registered WHFB** key da un **device** via SSO
- Scongela la protezione TPM in quanto la chiave viene **sniffed during the generation** della nuova key
- Questo fornisce anche **persistence**

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

Gli utenti possono modificare la propria proprietà searchableDeviceKey tramite l'Azure AD Graph, tuttavia l'attaccante deve avere un device nel tenant (registrato al volo o avendo rubato cert + key da un dispositivo legittimo) e un token di accesso valido per l'AAD Graph.

Poi, è possibile generare una nuova chiave con:
```bash
roadtx genhellokey -d <device id> -k tempkey.key
```
e poi effettuare un PATCH delle informazioni di searchableDeviceKey:

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

È possibile ottenere un access token da un utente tramite **device code phishing** e sfruttare i passaggi precedenti per **rubare il suo accesso**. Per maggiori informazioni consulta:

{{#ref}}
az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
{{#endref}}

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

## Riferimenti

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