Az - Enregistrement d’appareil

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Informations de base

Quand un appareil rejoint AzureAD, un nouvel objet est créé dans AzureAD.

Lors de l’enregistrement d’un appareil, l’user is asked to login with his account (demande de MFA si nécessaire), puis il demande des jetons pour le service d’enregistrement d’appareil et demande ensuite une confirmation finale.

Ensuite, deux RSA keypairs sont générés sur l’appareil : la device key (public key) qui est envoyée à AzureAD et la transport key (private key) qui est stockée dans le TPM si possible.

Ensuite, l’object est généré dans AzureAD (pas dans Intune) et AzureAD renvoie à l’appareil un certificate signé par celui-ci. Vous pouvez vérifier que l’device is AzureAD joined et obtenir des informations sur le certificate (par exemple s’il est protégé par TPM).:

dsregcmd /status

Après l’enregistrement de l’appareil, un Primary Refresh Token est demandé par le module LSASS CloudAP et remis à l’appareil. Avec le PRT est aussi fournie la clé de session chiffrée de sorte que seul l’appareil puisse la déchiffrer (en utilisant la clé publique de la transport key) et elle est nécessaire pour utiliser le PRT.

Pour plus d’informations sur ce qu’est un PRT, consultez :

Az - Primary Refresh Token (PRT)

TPM - Trusted Platform Module

Le TPM protège contre l’extraction de clés depuis un appareil éteint (si protégé par PIN) et contre l’extraction du matériel privé depuis la couche OS.
Mais il ne protège pas contre le sniffing de la connexion physique entre le TPM et le CPU ou contre l’utilisation du matériel cryptographique du TPM pendant que le système est en fonctionnement depuis un processus disposant des droits SYSTEM.

Si vous consultez la page suivante, vous verrez que stealing the PRT peut être utilisé pour obtenir l’accès comme l’utilisateur, ce qui est avantageux car le PRT est stocké sur les appareils, donc il peut leur être volé (ou, s’il n’est pas volé, abusé pour générer de nouvelles clés de signature) :

Az - Primary Refresh Token (PRT)

Enregistrement d’un appareil avec des tokens SSO

Il serait possible pour un attaquant de demander un token pour le service d’enregistrement d’appareils Microsoft depuis l’appareil compromis et de l’enregistrer :

# 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

Ce qui vous donnera un certificat que vous pouvez utiliser pour demander des PRTs à l’avenir. Permettant ainsi de maintenir la persistance et de contourner la MFA parce que le PRT original utilisé pour enregistrer le nouvel appareil avait déjà les permissions MFA accordées.

Tip

Notez que pour réaliser cette attaque vous aurez besoin des autorisations pour register new devices. De plus, enregistrer un appareil ne signifie pas que l’appareil sera autorisé à s’enrôler dans Intune.

Caution

Cette attaque a été corrigée en septembre 2021 car vous ne pouvez plus enregistrer de nouveaux appareils en utilisant des SSO tokens. Cependant, il est toujours possible d’enregistrer des appareils de manière légitime (en ayant le username, password et MFA si nécessaire). Check: roadtx.

Écraser un ticket d’appareil

Il était possible de request a device ticket, overwrite celui courant de l’appareil, et durant le flux steal the PRT (donc pas besoin de le voler depuis le TPM). Pour plus d’infos voir cette conférence.

Caution

Cependant, cela a été corrigé.

Remplacer la clé WHFB

Voir les slides originales ici

Résumé de l’attaque :

  • Il est possible de remplacer la clé WHFB enregistrée d’un appareil via SSO
  • Cela déjoue la protection TPM car la clé est interceptée lors de la génération de la nouvelle clé
  • Cela fournit aussi de la persistance

Les utilisateurs peuvent modifier leur propre propriété searchableDeviceKey via l’Azure AD Graph, cependant, l’attaquant doit disposer d’un appareil dans le tenant (enregistré à la volée ou ayant volé cert + key d’un appareil légitime) et d’un jeton d’accès valide pour l’AAD Graph.

Ensuite, il est possible de générer une nouvelle clé avec :

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

et ensuite PATCH les informations du searchableDeviceKey :

Il est possible d’obtenir un jeton d’accès d’un utilisateur via device code phishing et d’abuser des étapes précédentes pour voler son accès. Pour plus d’informations, consultez :

Az - Primary Refresh Token (PRT)

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks