Az - Cloud Kerberos Trust
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.
Basic Information
Trust
Lorsqu'une relation de confiance est établie avec Azure AD, un Read Only Domain Controller (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...
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 y compris le hachage NT dans la réponse.
Abusing Cloud Kerberos Trust to obtain 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 Global Admin 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 Global Admins 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.
Attack prerequisites
Le succès de l'attaque et l'obtention des privilèges de 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 de Global Admin 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 Domain Admin 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.
The full attack
Check it in the original post: https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Last updated
