# Az - Cloud Kerberos Trust

{{#include ../../../../banners/hacktricks-training.md}}

**Ce post est un résumé de** [**https://dirkjanm.io/obtaining-domain-admin-from-azure-ad-via-cloud-kerberos-trust/**](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**](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`**. 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 <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>

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](https://aadinternals.com/aadinternals/#set-aadintazureadobject-a).

### Prérequis de l'attaque <a href="#attack-prerequisites" id="attack-prerequisites"></a>

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 <a href="#the-full-attack" id="the-full-attack"></a>

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

{{#include ../../../../banners/hacktricks-training.md}}
