Az - Cloud Kerberos Trust
Cet article 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.
Informations de base
Confiance
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 est créé. Ce compte contient les clés Kerberos utilisées pour les tickets créés par Azure AD.
Par conséquent, si ce compte est compromis, il pourrait être possible de se faire passer pour n'importe quel utilisateur... bien que ce ne soit pas vrai car ce compte est empêché de créer des tickets pour tout groupe AD privilégié commun comme les Administrateurs de domaine, les Administrateurs d'entreprise, les Administrateurs...
Cependant, dans un scénario réel, il y aura des utilisateurs privilégiés qui ne sont pas dans ces groupes. Ainsi, le nouveau compte krbtgt, s'il est compromis, pourrait être utilisé pour se faire passer pour eux.
TGT Kerberos
De plus, lorsqu'un utilisateur s'authentifie sur Windows en utilisant une identité hybride Azure AD, Azure AD émettra un ticket Kerberos partiel avec le PRT. Le TGT est partiel car AzureAD a des informations limitées sur l'utilisateur dans l'AD local (comme l'identifiant de sécurité (SID) et le nom).
Windows peut ensuite échanger ce TGT partiel contre un TGT complet en demandant un ticket de service pour le service krbtgt.
NTLM
Comme il peut y avoir des services qui ne prennent pas en charge l'authentification Kerberos mais NTLM, il est possible de demander un TGT partiel signé en utilisant un krbtgt secondaire incluant le champ KERB-KEY-LIST-REQ dans la partie PADATA de la demande et ensuite obtenir un TGT complet signé avec la clé krbtgt primaire incluant le hachage NT dans la réponse.
Abus de la confiance Kerberos Cloud pour obtenir l'administrateur de domaine
Lorsque AzureAD génère un TGT partiel, il utilisera les détails qu'il possède sur l'utilisateur. Par conséquent, si un administrateur global pouvait modifier des données comme le SID et le nom de l'utilisateur dans AzureAD, lors de la demande d'un TGT pour cet utilisateur, le SID serait différent.
Il n'est pas possible de le faire via le Microsoft Graph ou l'Azure AD Graph, mais il est possible d'utiliser l'API Active Directory Connect utilisée 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 le faire avec AADInternals et mettre à jour les utilisateurs synchronisés via la Set-AADIntAzureADObject cmdlet.
Prérequis de l'attaque
Le succès de l'attaque et l'obtention des privilèges d'administrateur de domaine dépendent de certains prérequis :
La capacité de 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 possibilité 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 dans 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, ce qui nécessite la modification d'un compte non synchronisé pour obtenir le ticket.
De plus, ce compte doit posséder des privilèges équivalents à ceux de l'administrateur de domaine mais ne doit pas être membre de 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 de l'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 une installation express, ce compte est préfixé par MSOL_. Pour d'autres instances, le compte peut être ciblé en énumérant tous les comptes dotés de privilèges de réplication de répertoire sur l'objet de domaine.
L'attaque complète
Consultez l'article original : https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/
Dernière mise à jour