Az - Cloud Kerberos Trust

Reading time: 6 minutes

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

Vérifiez les plans d'abonnement !
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

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.

Lorsqu'une confiance est établie avec Azure AD, un contrôleur de domaine en lecture seule (RODC) est créé dans l'AD. Le compte d'ordinateur RODC, nommé AzureADKerberos$. De plus, un compte krbtgt secondaire nommé krbtgt_AzureAD. Ce compte contient les clés Kerberos utilisées pour les tickets que crée Azure AD.

Par conséquent, si ce compte est compromis, il pourrait être possible d'usurper l'identité de n'importe quel utilisateur... bien que cela ne soit pas vrai car ce compte est empêché de créer des tickets pour tout groupe AD privilégié commun comme Domain Admins, Enterprise Admins, Administrators...

caution

Cependant, dans un scénario réel, il y aura des utilisateurs privilégiés qui ne sont pas dans ces groupes. Donc le nouveau compte krbtgt, s'il est compromis, pourrait être utilisé pour les usurper.

Kerberos TGT

De plus, lorsqu'un utilisateur s'authentifie sur Windows en utilisant une identité hybride, Azure AD délivrera un ticket Kerberos partiel avec le PRT. Le TGT est partiel car AzureAD a des informations limitées sur l'utilisateur dans l'AD sur site (comme l'identifiant de sécurité (SID) et le nom).
Windows peut alors échanger ce TGT partiel contre un TGT complet en demandant un ticket de service pour le service krbtgt.

NTLM

Comme il pourrait y avoir des services qui ne prennent pas en charge l'authentification Kerberos mais NTLM, il est possible de demander un TGT partiel signé avec une clé krbtgt secondaire en incluant le champ KERB-KEY-LIST-REQ dans la partie PADATA de la demande, puis d'obtenir un TGT complet signé avec la clé krbtgt principale incluant le hachage NT dans la réponse.

Abus de la confiance Cloud Kerberos pour obtenir les privilèges Domain Admin

Lorsque AzureAD génère un TGT partiel, il utilisera les détails qu'il a sur l'utilisateur. Par conséquent, si un administrateur global pouvait modifier des données comme l'identifiant de sécurité et le nom de l'utilisateur dans AzureAD, lors de la demande d'un TGT pour cet utilisateur, l'identifiant de sécurité serait différent.

Il n'est pas possible de faire cela via Microsoft Graph ou Azure AD Graph, mais il est possible d'utiliser l'API que Active Directory Connect utilise pour créer et mettre à jour les utilisateurs synchronisés, ce qui peut être utilisé par les administrateurs globaux pour modifier le nom SAM et le SID de tout utilisateur hybride, et ensuite, si nous nous authentifions, nous obtenons un TGT partiel contenant le SID modifié.

Notez que nous pouvons faire cela avec AADInternals et mettre à jour les utilisateurs synchronisés via la cmdlet Set-AADIntAzureADObject.

Prérequis de l'attaque

Le succès de l'attaque et l'obtention des privilèges Domain Admin dépendent de la satisfaction de certains prérequis :

La capacité à modifier des comptes via l'API de synchronisation est cruciale. Cela peut être réalisé en ayant le rôle d'administrateur global ou en possédant un compte de synchronisation AD Connect. Alternativement, le rôle d'administrateur d'identité hybride suffirait, car il accorde la capacité de gérer AD Connect et d'établir de nouveaux comptes de synchronisation.
La présence d'un compte hybride est essentielle. Ce compte doit être modifiable avec les détails du compte de la victime et doit également être accessible pour l'authentification.
L'identification d'un compte victime cible au sein d'Active Directory est une nécessité. Bien que l'attaque puisse être exécutée sur n'importe quel compte déjà synchronisé, le locataire Azure AD ne doit pas avoir répliqué les identifiants de sécurité sur site, nécessitant la modification d'un compte non synchronisé pour obtenir le ticket.
De plus, ce compte doit posséder des privilèges équivalents à ceux d'un administrateur de domaine mais ne doit pas être membre des groupes d'administrateurs AD typiques pour éviter la génération de TGT invalides par le RODC AzureAD.
La cible la plus appropriée est le compte Active Directory utilisé par le service de synchronisation AD Connect. Ce compte n'est pas synchronisé avec Azure AD, laissant son SID comme une cible viable, et il détient intrinsèquement des privilèges équivalents à ceux d'un administrateur de domaine en raison de son rôle dans la synchronisation des hachages de mots de passe (en supposant que la synchronisation des hachages de mots de passe est active). Pour les domaines avec installation express, ce compte est préfixé par MSOL_. Pour d'autres cas, le compte peut être identifié en énumérant tous les comptes dotés de privilèges de réplication d'annuaire sur l'objet de domaine.

L'attaque complète

Vérifiez-le dans le post original : https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/

tip