Az - Cloud Kerberos Trust

Reading time: 9 minutes

Ce post est un résumé de https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/ qui peut être consulté pour plus d'informations sur l'attaque. Cette technique est également commentée dans https://www.youtube.com/watch?v=AFay_58QubY.

Vue d'ensemble de la relation de confiance Kerberos

Cloud Kerberos Trust (Entra ID -> AD) -- Cette fonctionnalité (partie de Windows Hello for Business) établit une confiance unidirectionnelle où l'AD sur site fait confiance à Entra ID pour émettre des tickets Kerberos pour l'AD. L'activer crée un objet ordinateur AzureADKerberos$ dans l'AD (apparaissant comme un contrôleur de domaine en lecture seule) et un compte lié krbtgt_AzureAD (un KRBTGT secondaire). Entra ID détient les clés pour ces comptes et peut émettre des TGT Kerberos "partiels" pour les utilisateurs de l'AD. Les contrôleurs de domaine AD honoreront ces tickets, mais avec des restrictions similaires à celles des RODC : par défaut, les groupes à privilèges élevés (Domain Admins, Enterprise Admins, etc.) sont refusés et les utilisateurs ordinaires sont autorisés. Cela empêche Entra ID d'authentifier les administrateurs de domaine via la confiance dans des conditions normales. Cependant, comme nous le verrons, un attaquant avec des privilèges Entra ID suffisants peut abuser de ce design de confiance.

Pivotement d'Entra ID vers l'AD sur site

Scénario : L'organisation cible a Cloud Kerberos Trust activé pour l'authentification sans mot de passe. Un attaquant a obtenu des privilèges de Global Administrator dans Entra ID (Azure AD) mais ne contrôle pas encore l'AD sur site. L'attaquant a également un point d'accès avec un accès réseau à un contrôleur de domaine (via VPN ou une VM Azure dans un réseau hybride). En utilisant la confiance cloud, l'attaquant peut tirer parti du contrôle Azure AD pour obtenir un accès de niveau Domain Admin dans l'AD.

Prérequis :

• Cloud Kerberos Trust est configuré dans l'environnement hybride (indicateur : un compte RODC AzureADKerberos$ existe dans l'AD).

• L'attaquant a des droits de Global Admin (ou Hybrid Identity Admin) dans le locataire Entra ID (ces rôles peuvent utiliser l'API de synchronisation AD Connect pour modifier les utilisateurs Azure AD).

• Au moins un compte utilisateur hybride (existe à la fois dans l'AD et l'AAD) que l'attaquant peut authentifier. Cela pourrait être obtenu en connaissant ou en réinitialisant ses identifiants ou en assignant une méthode sans mot de passe (par exemple, un Temporary Access Pass) pour générer un Primary Refresh Token (PRT) pour celui-ci.

• Un compte cible AD sur site avec des privilèges élevés qui n'est pas dans la politique de "refus" par défaut des RODC. En pratique, une excellente cible est le compte de synchronisation AD Connect (souvent nommé MSOL_*), qui a des droits DCSync (réplication) dans l'AD mais n'est généralement pas membre des groupes d'administrateurs intégrés. Ce compte n'est généralement pas synchronisé avec Entra ID, rendant son SID disponible pour une usurpation sans conflit.

Étapes de l'attaque :

1. Obtenir l'accès à l'API de synchronisation Azure AD : En utilisant le compte Global Admin, acquérir un jeton d'accès pour l'API de Provisioning (sync) Azure AD. Cela peut être fait avec des outils comme ROADtools ou AADInternals. Par exemple, avec ROADtools (roadtx) :

# Using roadtx to get an Azure AD Graph token (no MFA)
roadtx gettokens -u <GlobalAdminUPN> -p <Password> --resource aadgraph

(Alternativement, Connect-AADInt d'AADInternals peut être utilisé pour s'authentifier en tant qu'administrateur global.)

2. Modifier les attributs On-Prem d'un utilisateur hybride : Profitez de l'API de synchronisation Azure AD pour définir l'identifiant de sécurité (SID) et le SAMAccountName onPremises d'un utilisateur hybride choisi pour correspondre au compte AD cible. Cela indique effectivement à Azure AD que l'utilisateur cloud correspond au compte on-prem que nous voulons usurper. En utilisant l'outil open-source ROADtools Hybrid :

# Example: modify a hybrid user to impersonate the MSOL account
python3 modifyuser.py -u <GlobalAdminUPN> -p <Password>\
--sourceanchor <ImmutableID_of_User>\
--sid <TargetAD_SID> --sam <TargetAD_SAMName>

Le sourceAnchor (ID immuable) de l'utilisateur est nécessaire pour identifier l'objet Azure AD à modifier. L'outil définit le SID on-prem et le nom de compte SAM de l'utilisateur hybride sur les valeurs de la cible (par exemple, le SID et le SAM du compte MSOL_xxxx). Azure AD interdit normalement de modifier ces attributs via Graph (ils sont en lecture seule), mais l'API du service de synchronisation le permet et les administrateurs globaux peuvent invoquer cette fonctionnalité de synchronisation.

3. Obtenir un TGT partiel d'Azure AD : Après modification, authentifiez-vous en tant qu'utilisateur hybride auprès d'Azure AD (par exemple, en obtenant un PRT sur un appareil ou en utilisant leurs identifiants). Lorsque l'utilisateur se connecte (surtout sur un appareil Windows joint au domaine ou à Entra), Azure AD émettra un TGT Kerberos partiel (TGT_AD) pour ce compte car la confiance Kerberos Cloud est activée. Ce TGT partiel est chiffré avec la clé AzureADKerberos$ RODC et inclut le SID cible que nous avons défini. Nous pouvons simuler cela en demandant un PRT pour l'utilisateur via ROADtools :

roadtx getprt -u <HybridUserUPN> -p <Password> -d <DeviceID_or_Cert>

Cela génère un fichier .prt contenant le TGT partiel et la clé de session. Si le compte était un mot de passe uniquement cloud, Azure AD inclut toujours un TGT_AD dans la réponse PRT.

4. Échanger le TGT partiel contre un TGT complet (sur AD) : Le TGT partiel peut maintenant être présenté au contrôleur de domaine sur site pour obtenir un TGT complet pour le compte cible. Nous le faisons en effectuant une demande TGS pour le service krbtgt (le service TGT principal du domaine) -- essentiellement en mettant à niveau le ticket vers un TGT normal avec un PAC complet. Des outils sont disponibles pour automatiser cet échange. Par exemple, en utilisant le script de ROADtools Hybrid :

# Use the partial TGT from the PRT file to get a full TGT and NTLM hash
python3 partialtofulltgt.py -p roadtx.prt -o full_tgt.ccache --extract-hash

Ce script (ou équivalents d'Impacket) contactera le contrôleur de domaine et récupérera un TGT valide pour le compte AD cible, y compris le hachage NTLM du compte si l'extension Kerberos spéciale est utilisée. L'extension KERB-KEY-LIST-REQ est automatiquement incluse pour demander au DC de renvoyer le hachage NTLM du compte cible dans la réponse chiffrée. Le résultat est un cache d'identifiants (full_tgt.ccache) pour le compte cible ou le hachage de mot de passe NTLM récupéré.

5. Impersonner la cible et élever les privilèges au niveau d'administrateur de domaine : Maintenant, l'attaquant contrôle effectivement le compte AD cible. Par exemple, si la cible était le compte MSOL d'AD Connect, il a des droits de réplication sur le répertoire. L'attaquant peut effectuer une attaque DCSync en utilisant les identifiants de ce compte ou le TGT Kerberos pour extraire les hachages de mots de passe d'AD (y compris le compte de domaine KRBTGT). Par exemple :

# Using impacket's secretsdump to DCSync as the MSOL account (using NTLM hash)
secretsdump.py 'AD_DOMAIN/<TargetSAM>$@<DC_IP>' -hashes :<NTLM_hash> LOCAL

Cela extrait tous les hachages de mots de passe des utilisateurs AD, donnant à l'attaquant le hachage KRBTGT (lui permettant de forger des tickets Kerberos de domaine à volonté) et effectuant effectivement des privilèges Domain Admin sur AD. Si le compte cible était un autre utilisateur privilégié, l'attaquant pourrait utiliser le TGT complet pour accéder à n'importe quelle ressource de domaine en tant que cet utilisateur.

6. Nettoyage : En option, l'attaquant peut restaurer le onPremisesSAMAccountName et le SID d'origine de l'utilisateur Azure AD modifié via la même API ou simplement supprimer tout utilisateur temporaire créé. Dans de nombreux cas, le prochain cycle de synchronisation Azure AD Connect annulera automatiquement les modifications non autorisées sur les attributs synchronisés. (Cependant, à ce stade, les dégâts sont faits -- l'attaquant a des privilèges DA.)

Références

• Obtaining Domain Admin from Azure AD via Cloud Kerberos Trust