Attaquez avec Entra Connect : Techniques Avancées – Partie 2

Maintenant que nous savons comment ajouter des identifiants à un utilisateur sur site, posons la question suivante :

“En ayant accès à un compte de synchronisation dans le Domaine A, pouvons-nous ajouter des identifiants à un utilisateur dans un autre domaine au sein du même tenant Entra ?”

C’est un défi de taille, surtout si nous avons très peu de privilèges dans Entra. Rappelons-nous de la première partie : par défaut, la seule information que nous pouvons synchroniser est la propriété msDS-KeyCredentialLink. Pour comprendre comment tirer parti de cela, il est essentiel de se familiariser avec les principes fondamentaux du moteur de synchronisation Entra et le fonctionnement de ses règles :

Introduction aux règles

Nous n’avons pas encore examiné de règle concrète, alors regardons la première règle définie dans l’éditeur de règles.

Notez que la direction n’est pas affichée ici, mais je présente les règles entrantes dans l’éditeur des règles de synchronisation. La direction est définie dans la définition XML. Le “Système Connecté” correspond à l’espace de connexion d’où provient l’objet source (dans ce cas, hybrid.hotnops.com). L’objet AD étant un utilisateur, l’objet de l’espace de connexion est un “utilisateur” et sa représentation dans le métavers est appelée “personne”. Le type de lien “Provision” indique que “créer un objet dans le métavers si celui-ci n’existe pas encore”. Pour résumer, cette règle indique au moteur de synchronisation de créer un objet dans le métavers pour tout utilisateur dans l’espace de connexion. N’oubliez pas que le connecteur est responsable de l’énumération LDAP et de la peuplade de tous les utilisateurs AD dans l’espace de connexion.

Ensuite, le filtre de portée détermine quels objets seront provisionnés. Ici, nous voyons que si l’objet de l’espace de connexion a la propriété isCriticalSystemObject non définie sur “true” ET que adminDescription ne commence pas par “User_”, alors l’objet sera provisionné. Gardez à l’esprit que l’objet existe toujours dans l’espace de connexion, même s’il ne sera pas projeté dans le métavers.

Enfin, les règles de “jointure” sont cruciales à comprendre. Elles décrivent la logique qui crée les liens entre les objets du métavers et de l’espace de connexion, établissant ainsi de réelles relations MSSQL. Dans ce cas, la règle stipule que le ms-DS-ConsistencyGuid de l’objet de l’espace de connexion doit correspondre au sourceAnchorBinary de l’objet du métavers. Si la propriété ms-DS-ConsistencyGuid n’existe pas, l’objetGUID est utilisé. Il est également important de noter que les jointures se produisent tant pour les flux d’attributs entrants (d’un espace de connexion vers le métavers) que sortants (du métavers vers l’espace de connexion).

Enfin, la liste des transformations indique quelles propriétés d’objet doivent être modifiées. Notez que le langage pour ces transformations est essentiellement VBA. Dans ce cas, deux propriétés seront définies sur la personne du métavers :

1. cloudFiltered  – Cela sera important plus tard. Il s’agit d’une règle assez large qui décrit une liste de motifs de chaînes, comme si le sAMAccountName commençait par “krbtgt_” ou “AAD_”, etc. Si “true”, alors une propriété appelée cloudFiltered sera définie sur “true” sur l’objet du métavers.
2. sourceAnchorBinary  – Vous vous souvenez de cela dans la règle de jointure ? Dans cette règle, le sourceAnchorBinary est défini sur l’objet du métavers pour correspondre soit au ms-DS-ConsistencyGuid soit à l’objectId.

Nous avons maintenant parcouru une règle de provisionnement complète, mais notez que la plupart des règles ne provisionnent rien ; elles sont plutôt liées à des objets existants et certaines transformations sont projetées dans le métavers.

Jusqu’à présent, nous avons décrit le flux d’un côté du métavers, alors comment une propriété circule-t-elle de l’autre côté ? Regardons les deux règles qui nous intéressent. Commençons par examiner comment les utilisateurs sont provisionnés dans Entra :

Le type de lien est “Provision”, ce qui signifie qu’un nouvel objet sera créé dans l’espace de connexion d’Entra. Le connecteur Entra (Sync Agent) utilisera cette création d’objet pour déclencher une nouvelle création d’utilisateur dans Entra.

Cet aspect est vraiment crucial. Si nous examinons le filtre, les objets ne sont provisionnés dans l’espace de connexion d’Entra que si toutes ces conditions sont remplies. Rappelons-nous que certains de nos comptes privilégiés, tels que le compte “MSOL”, “krbtgt” et les noms de compte “AAD_”, sont définis pour être filtrés par le cloud. Cela signifie qu’ils sont projetés dans le métavers, mais le provisionnement d’utilisateur Entra est simplement bloqué par le moteur de synchronisation.

Dernière règle, je vous promets. Regardons comment les utilisateurs Entra sont reliés aux utilisateurs sur site :

<pCela signifie que si un utilisateur Entra ayant un point d’ancrage source correspond à un objet du métavers avec le même point d’ancrage, ils seront liés ensemble.

Le voyez-vous ?

Il existe des objets partiellement liés dans le métavers, et nous pouvons déclencher un lien en créant un nouvel utilisateur avec le point d’ancrage source correspondant.

En termes simples, les objets CloudFiltered ne peuvent pas être provisionnés seulement ! AKA Filtrage Sortant. Si nous pouvons provisionner nous-mêmes l’utilisateur Entra, nous pouvons compléter la règle de jointure entrante et prendre le contrôle du compte utilisateur dans un autre domaine, à condition que le compte MSOL puisse écrire leur propriété msDS-KeyCredentialLink.

Et en reliant cela, parce que nous pouvons contrôler le mot de passe et la création de l’utilisateur depuis le compte de synchronisation compromis dans le Domaine A, nous pouvons ensuite ajouter les identifiants WHFB discutés dans la première partie de cette série de blogs et ajouter des identifiants à un utilisateur potentiellement privilégié.

Avant de continuer, cette attaque a certaines mises en garde importantes :

Le compte MSOL utilisé pour les flux d’attributs a par défaut des permissions d’écriture au niveau de l’OU “Users”. Si un compte utilisateur a l’héritage désactivé, alors MSOL ne pourra pas écrire dessus et cette attaque n’affectera pas le compte.

Étape 1

Depuis le Beacon dans hybrid.hotnops.com, nous devons identifier un compte que nous aimerions prendre le contrôle et déterminer le point d’ancrage source dont nous avons besoin.

Pour ce faire, nous voulons trouver des objets du métavers partiellement synchronisés. Pour cette démonstration, nous pouvons exécuter :

#> dsquery * "CN=Users,DC=hybrid,DC=hotnops,DC=com" -attr *

Avec les résultats, nous désirons repérer tout compte correspondant à notre règle “CloudFiltered”, définie ici. Dans notre cas, il y a un compte nommé “AAD_cb48101f-7fc5–4d40-ac6c-09b22d42a3ed”. Ce sont des comptes de connecteurs plus anciens installés avec AAD Connect Sync. Si vous identifiez un compte qui pourrait être filtré par le cloud, vous aurez besoin de l’ObjectID correspondant associé au compte figurant dans les résultats de dsquery. Dans notre cas, l’ID de l’objet est :

0A08E28B-5D21–4960-A25A-F724F1E96155

Étant donné que l’ObjectId est utilisé comme point d’ancrage source, nous souhaitons créer un nouvel utilisateur Entra avec ce point d’ancrage pour qu’il soit relié à notre compte “AAD_” ciblé. Pour convertir le UUID en point d’ancrage source, nous devons simplement convertir le UUID en un blob binaire où chaque section est little endian. J’ai un script à ce sujet ici, mais il existe probablement des moyens plus simples.

./uuid_to_sourceAnchor.py 0A08E28B-5D21–4960-A25A-F724F1E96155

Nous devons maintenant utiliser notre compte de synchronisation dans federated.hotnops.com pour créer un nouvel utilisateur avec ce point d’ancrage source pour établir un lien avec notre utilisateur cible dans hybrid.hotnops.com. Pour cela, il vous faut obtenir les identifiants du compte ADSync et utiliser l’API de provisionnement. Vous aurez besoin d’obtenir un jeton d’accès pour le compte ADSync, ce que je démontre dans la vidéo liée ci-dessus. Une fois le jeton obtenu, vous devrez utiliser AADInternals pour créer le compte.

#> Set-AADIntAzureADObject -AccessToken $token -SourceAnchor $sourceAnchor -userPrincipalName  -accountEnabled $true

À ce stade, nous avons exécuté l’étape 1. Nous avons un nouvel utilisateur dans Entra avec un point d’ancrage correspondant, et nous devons maintenant attendre jusqu’à 30 minutes (par défaut) pour que le domaine cible exécute une synchronisation Entra, moment auquel l’utilisateur Entra et le “AAD_cb48101f-7fc5–4d40-ac6c-09b22d42a3ed” sur site se lieront.

Étape 2

Une fois l’utilisateur créé, ajoutez un msDS-KeyCredentialLink au nouvel utilisateur Entra comme documenté dans le premier article de cette série.

Étape 3 : Profits

Une fois que l’agent de synchronisation d’Entra sur hybrid.hotnops.com exécutera la prochaine synchronisation, il utilisera la règle de jointure “Entrant de AAD – Jointure Utilisateur” pour lier l’utilisateur Entra à l’objet du métavers associé au compte “AAD_cb48101f-7fc5–4d40-ac6c-09b22d42a3ed” sur site.

À partir de là, nous utiliserons notre Beacon dans hybrid.hotnops.com et les méthodes documentées dans le blog sur les Identifiants d’Ombre pour hausser nos privilèges.

À la suite de l’enregistrement d’une clé Windows Hello For Business (WHFB) sur votre utilisateur Entra créé, vous disposerez d’une clé appelée “winhello.key”. Pour l’utiliser avec Rubeus, nous devons la formater en fichier PFX. Voici les étapes :

openssl req -new -key ./winhello.key -out ./winhello_cert_req.csr
openssl x509 -req -days 365 -in ./winhello_cert_req.csr -signkey ./winhello.key -out ./winhello_cert.pem
openssl pkcs12 -export -out aad.pfx -inkey ./winhello.key -in ./winhello_cert.pem

Maintenant, nous devons retourner à notre Beacon sur hybrid.hotnops.com et télécharger le PFX :

beacon> upload aad.pfx

Ensuite, exécutez la commande Rubeus :

beacon> rubeus asktgt /user:AAD_cb48101f-7fc5–4d40-ac6c-09b22d42a3ed /certificate:C:PathToaad.pfx /password:"certPassword" /domain:hybrid.hotnops.com /dc:DC1-HYBRID.hotnops.com /getcredentials /ptt

Félicitations ! Votre processus Beacon dispose désormais d’un jeton pour votre compte ciblé.

Prévention

Identifier tous les utilisateurs partiellement synchronisés

Pour nous, un utilisateur partiellement synchronisé est celui ayant un objet dans l’espace de connexion sur site, une projection dans le métavers, mais pas d’objet dans l’espace de connexion d’Entra. La raison de leur existence, comme mentionné précédemment, est due au filtrage sortant. Pour déterminer quels utilisateurs sont partiellement synchronisés, nous pouvons interroger tous les objets dans les espaces du métavers et de connexion pour voir lesquels n’ont pas d’objet dans l’espace de connexion d’Entra. Le script pour cela est ici, et voici un exemple de sortie :

Identifier tous les utilisateurs privilégiés héritant des permissions de l’OU Users

Lorsque Entra Connect est installé, un compte de connecteur Active Directory Domain Services (AD DS) est créé avec le schéma de dénomination “MSOL_”. Ce compte est responsable de la synchronisation des hashes (oui, il a des privilèges DCSync) et de la lecture/écriture des propriétés sur les utilisateurs pour supporter les flux d’attributs. En conséquence, le compte MSOL a un accès en écriture étendu sur tous les utilisateurs dans l’OU “Users”. Cela signifie que cette attaque peut affecter tout utilisateur qui hérite de ses listes de contrôle d’accès discrétionnaires (DACL) de l’OU Users (ce qui inclut pratiquement tous les utilisateurs). Ceci est généralement vrai pour toute attaque de synchronisation ; toutefois, quelque chose que j’ai appris durant cette recherche est que les utilisateurs ajoutés à des groupes sensibles de privilèges comme les Administrateurs de Domaine auront automatiquement leur héritage désactivé. Même lorsque je le réactive, un script intervient et le désactive à nouveau. Cela m’a conduit à cet article sur technet qui affirme que tout groupe AD marqué comme “protégé” recevra systématiquement un modèle DACL appliqué, situé à CN=AdminSDHolder,CN=System,DC=hybrid,DC=hotnops,DC=com.

Alors, quels utilisateurs sont “protégés” ?

Tout utilisateur ayant la propriété adminCount définie sur “1”. En fin de compte, tant que l’attribut msDS-KeyCredentialLink de la cible est modifiable par le compte MSOL ET qu’il est partiellement synchronisé, alors il est susceptible à cette attaque. J’ai fourni un cmdlet PowerShell pour lister tous les utilisateurs qui héritent de leurs DACL de l’OU Users :

Détection

La détection de cette mauvaise configuration/ attaque peut être difficile, mais il y a quelques signaux solides que quelque chose ne tourne pas rond. Si des utilisateurs dans l’espace de connexion Entra ont une projection dans le métavers avec un attribut “cloudFiltered” défini sur “true”, alors il y a un problème. Vous pouvez utiliser le cmdlet PowerShell ici pour vérifier ces utilisateurs. Bien que cela ne détecte pas tous les objets du métavers pouvant être détournés, cela couvre le cas le plus évident des utilisateurs filtrés par le cloud.

Références

Configurateur de filtrage de Microsoft Entra Connect Sync — Microsoft Entra ID

Identifiants d’ombre : abus de la mappage de comptes de confiance clé pour prise de contrôle de compte | par Elad Shamir | Posts par des membres de l’équipe SpecterOps

Gerenios/AADInternals : Module PowerShell AADInternals pour administrer Azure AD et Office 365

DEF CON 32 — Abuser de Windows Hello sans main coupée — Ceri Coburn, Dirk Jan Mollema

Présentation des outils ROADtools Token eXchange (roadtx) — Automatisation de l’authentification Azure AD, abus/usage abusif de Primary Refresh Token et enregistrement de l’appareil — dirkjanm.io

Un article de aadinternals.com sur les attaques Azure AD via l’abus de l’API de synchronisation — pdf

La série Entra Connect Attacker Tradecraft : Partie 2 a été publiée à l’origine dans Posts Par des membres de l’équipe SpecterOps sur Medium, où les gens continuent la conversation en mettant en avant et en répondant à cet article.

*** Cet article est une réédition du blog du réseau des blogueurs en sécurité de Posts Par des membres de l’équipe SpecterOps – Medium, rédigé par hotnops. Lisez l’article original ici :