Tôt ou tard, pendant le pentest, la tâche se pose de compromettre la forêt entière - à condition qu'il y ait des droits dans l'un des domaines. À de tels moments, de nombreuses questions se posent concernant les fiducies, leurs propriétés et les attaques elles-mêmes. Essayons de tout comprendre.

La confiance entre les domaines est utilisée pour authentifier les utilisateurs d'un domaine sur le contrôleur d'un autre domaine. En d'autres termes, pour que les utilisateurs du domaine A puissent avoir accès aux ressources du domaine B. La structure du domaine peut être de deux types:

• Arbres de domaine
• forêts de domaine.

Lors de la création d'une arborescence de domaines entre les domaines, par défaut, les approbations transitives sont établies. Tous les ordinateurs ont en commun:

• catalogue global
• espace de noms
• régime.

Les arbres de domaine peuvent être combinés en forêts. Lors de la création d'une forêt de domaine, des approbations transitives sont établies et tous les ordinateurs de la forêt partagent les éléments suivants:

• catalogue global
• régime.

Le tableau ci-dessous montre les types d'approbation entre les domaines et leurs propriétés.


Plus clairement, les types d'approbations entre domaines sont illustrés dans l'image ci-dessous.

Transitivité

La transitivité est nécessaire pour définir la confiance en dehors des deux domaines entre lesquels elle a été formée et est utilisée pour étendre les relations de confiance avec d'autres domaines. Si nous ajoutons un domaine enfant au domaine, une relation d'approbation bidirectionnelle est établie entre les domaines parent et enfant. Ces relations sont transitives, c'est-à-dire si le domaine A approuve le domaine D et le domaine D approuve le domaine E, le domaine A approuve également le domaine E.



La confiance non transitoire peut être utilisée pour refuser la confiance avec d'autres domaines.

Direction

Un chemin de relation d'approbation est une série de relations d'approbation entre des domaines auxquels des demandes d'authentification doivent être reçues. En d'autres termes, avant d'authentifier un utilisateur, la confiance entre les domaines est déterminée. Pour que les utilisateurs du domaine A accèdent aux ressources du domaine D, le domaine D doit approuver le domaine A.

La direction de la confiance est de deux types:

• unilatéral;
• bilatérale.

La confiance unidirectionnelle est un chemin d'authentification unidirectionnel créé entre deux domaines. Dans une approbation unidirectionnelle entre le domaine A et le domaine B, les utilisateurs du domaine B ont accès aux ressources du domaine A. Cependant, les utilisateurs du domaine A n'ont pas accès aux ressources du domaine B. Ce type d'approbation n'est pas transitoire.

La confiance bilatérale est une combinaison de deux relations de confiance unidirectionnelles. Dans une confiance bidirectionnelle entre les domaines A et B, leurs utilisateurs ont accès aux ressources des deux domaines. Ce type de confiance est transitoire.

La direction de la confiance est toujours opposée à la direction de l'accès. Diagramme représentatif de Microsoft ci-dessous:

Liens pour des types d'approbation plus approfondis:

• Confiance externe
• Royaume
• La forêt
• Raccourci

Kerberos entre domaines approuvés

Prenons un exemple. Le client tente d'accéder au serveur.


Les changements commencent à partir du point 4: un ticket TGT inter-domaine apparaît, le soi-disant ticket de référence, qui est crypté / signé avec une clé inter-domaine créée à partir d'un mot de passe de confiance. Un mot de passe approuvé est défini lors de l'établissement de l'approbation et est connu des deux contrôleurs de domaine. À l'aide du ticket TGT inter-domaines, un utilisateur du domaine 1 peut demander un ticket TGS pour accéder aux ressources du domaine 2.

NTLM entre domaines approuvés

1. Le client envoie une demande d'authentification directement à la ressource elle-même, située dans un autre domaine, à laquelle il souhaite accéder.
2. Le serveur reçoit une demande du client et lui envoie une réponse CHALLENGE_MESSAGE, qui contient une séquence aléatoire de 8 octets. Il s'agit du Server Challenge.
3. Le client, après avoir reçu la séquence Server Challenge du serveur, crypte cette séquence avec son mot de passe, puis envoie au serveur une réponse qui contient 24 octets.
4. Le serveur envoie une requête et une réponse au contrôleur de son domaine B.
5. Dans le cas d'une authentification entre approbations, la logique suivante est effectuée:
   
   
   • Relations d'approbation de direction vérifiées.
     
     • Les informations d'identification du client sont envoyées au domaine A pour s'authentifier.
     • S'il n'y a pas de relation d'approbation, la transitivité est vérifiée avec le domaine A.
     
     
   • Vérification de la transivité entre les domaines
     
     • En cas de transitivité entre les domaines, une demande d'authentification est envoyée au domaine suivant dans le chemin de confiance. Ce contrôleur de domaine répète le processus, vérifiant les informations d'identification de l'utilisateur par rapport à sa base de données de comptes de sécurité.
     • S'il n'y a pas de transitivité, un message d'accès refusé est renvoyé au client.
     
     
   
   6-8. La réponse avec la décision d'authentifier le client.
   
   

   Attaques entre approbations entre domaines

   
   Donc, pour mener une attaque, nous avons besoin d'informations sur les relations de confiance dans notre domaine.
   
   

   Cotation des fiducies

   
   Il existe 3 méthodes principales pour répertorier les approbations dans un domaine:
   
   
   1. via l'API Win32;
   2. via les méthodes .NET;
   3. via LDAP.
   
   API Win32
   
   L'énumération est effectuée en appelant la fonction DsEnumerateDomainTrusts , qui renvoie la structure DS_DOMAIN_TRUSTSA . En utilisant cette méthode, le SID et le GUID du domaine cible, les indicateurs et les attributs caractérisant la confiance actuelle dans le domaine sont renvoyés.
   
   
   Drapeaux

   DS_DOMAIN_DIRECT_INBOUND	Énumérer les domaines qui approuvent directement le domaine dont ServerName est membre.
   DS_DOMAIN_DIRECT_OUTBOUND	Énumérer les domaines directement approuvés par le domaine dont ServerName est membre.
   DS_DOMAIN_IN_FOREST	Énumérer les domaines qui sont membres de la même forêt qui a ServerName comme membre.
   DS_DOMAIN_NATIVE_MODE	Énumérer les domaines où le domaine principal s'exécute en mode natif Windows 2000.
   DS_DOMAIN_PRIMARY	Énumérer les domaines qui sont le domaine principal du domaine dont ServerName est membre.
   DS_DOMAIN_TREE_ROOT	Énumérer les domaines qui se trouvent à la racine de la forêt dont ServerName est membre.

   
   
   
   
   Attributs

   
   
   

   TRUST_ATTRIBUTE_NON_TRANSITIVE	Interdisez la transitivité.
   TRUST_ATTRIBUTE_UPLEVEL_ONLY	Le lien d'approbation n'est pas valide pour les systèmes d'exploitation clients antérieurs à Windows 2000.
   TRUST_ATTRIBUTE_FILTER_SIDS	Domaines de quarantaine.
   TRUST_ATTRIBUTE_FOREST_TRANSITIVE	Le lien d'approbation peut contenir des informations d'approbation de forêt.
   TRUST_ATTRIBUTE_CROSS_ORGANIZATION	Cette approbation concerne un domaine / forêt qui ne fait pas partie de cette entreprise.
   TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL	La confiance est traitée comme externe à des fins de limite de confiance.
   TRUST_ATTRIBUTE_WITHIN_FOREST	La confiance est interne à cette forêt.

   
   
   
   BloodHound collecte des informations à l'aide de la méthode API Win32.
   
   
   
   .Net
   
   La méthode GetCurrentDomain de l'espace de noms [System.DirectoryServices.ActiveDirectory.Domain] est utilisée, qui renvoie une instance de la classe System.DirectoryServices.ActiveDirectory.Domain . Cette classe implémente la méthode GetAllTrustRelationships , qui renvoie toutes les approbations du domaine actuel.
   
   

   ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships() 

   
   L'utilisation de cette méthode est implémentée dans le module Get-DomainTrust dans PowerView .
   
   
   
   Un des avantages de cette méthode est sa simplicité. L'information est facile à lire et à comprendre, mais son volume est beaucoup plus petit que lors de l'énumération par d'autres méthodes.
   
   LDAP
   
   Les informations d'approbation de domaine sont stockées dans Active Directory en tant que classe d' objet de la classe trustedDomain .
   
   Exemple d'utilisation:
   
   

    dsquery * -filter "(objectClass=trustedDomain)" -attr * 

   
   
   
   PowerView utilise cette méthode par défaut.
   
   
   
   Avec des informations sur les domaines et les types d'approbation, vous pouvez accéder directement à l'attaque elle-même. Considérez 2 options:
   
   
   1. Nous avons réussi à compromettre le domaine et nous avons des droits d'administrateur de domaine.
   2. Nous n'avons pas de droits d'administrateur de domaine.
   
   

   Avec des droits d'administrateur sur l'un des domaines

   
   Selon le domaine compromis, plusieurs vecteurs d'attaque peuvent être distingués:
   
   
   

   Non.	Démarrer le domaine Position de l'attaquant	Domaine attaqué	Technique d'attaque	Relation de confiance
   1	Racine	Enfant	Golden Ticket + Groupe Admin Entreprise	Inter-royaume (2 voies)
   2	Enfant	Enfant	Fonctionnement de l'historique SID	Parent-enfant inter-royaumes (2 voies)
   3	Enfant	Racine	Fonctionnement de l'historique SID Trust Trust Operation	Racine d'arbre inter-domaines (2 voies)
   4	Forêt 1	Forêt 2	Bug d'imprimante	Forêt inter-royaumes ou Approbation externe (bidirectionnelle)

   
   Il convient de noter que pour une mise en œuvre réussie de tous les vecteurs, une confiance bilatérale entre les domaines est nécessaire.
   
   

   1. Historique de l'opération SID

   
   L'historique SID a été introduit pour faciliter la migration des utilisateurs d'un domaine à un autre. L'attribut contient les objets SID précédents. Chaque fois qu'un objet passe d'un domaine à un autre, un nouveau SID est créé, qui devient un objectSID. Le SID précédent est ajouté à la propriété sIDHistory.
   
   Chaque forêt a un groupe d'utilisateurs Enterprise Admins qui n'existe que dans le domaine racine et dispose de droits d'administrateur local sur les contrôleurs de domaine de tous les domaines enfants de la forêt. Cette attaque a été démontrée pour la première fois par Sean Metcalf au BlackHat USA 2015 . L'essence de l'attaque est que nous émettons un ticket d'or avec l'ajout d'un SID supplémentaire du groupe Enterprise Admins. Cela se fait en ajoutant des ExtraSids dans la structure KERB_SID_AND_ATTRIBUTES , qui est envoyée dans la structure KERB_VALIDATION_INFO .
   
   
   
   Démo d'attaque:
   
   
   
   Impacket a un script qui automatise tout cela.
   
   

   2. Golden Admin + Enterprise Admin Group

   
   Ayant des droits d'administrateur dans le domaine racine, nous pouvons créer un Golden Ticket avec l'ajout d'un utilisateur au groupe Enterprise Admins (519).
   
   

    Kerberos::golden /domain:<domain> /sid:<domain_SID> /krbtgt:<ntlm_hash_krbtgt_user> /user:<user> /groups:500,501,513,512,520,518,519 /ptt 

   
   Comme décrit ci-dessus, Enterprise Admin dispose de droits d'administrateur local sur les domaines DC Child. Ainsi, nous pourrons compromettre tous les domaines enfants de la forêt.
   
   

   3. Fonctionnement des tickets de fiducie

   
   Pour accéder à une ressource à l'aide du protocole Kerberos, vous avez besoin d'un ticket TGS, qui est chiffré avec le hachage NTLM du mot de passe du compte de service. Un contrôleur de domaine stocke uniquement des hachages de mots de passe utilisateur pour son domaine. Ainsi, lorsqu'un utilisateur du domaine A a besoin d'accéder à une ressource du domaine B, une clé inter-domaine est utilisée. Cette clé est créée sur la base d'un mot de passe approuvé, qui est défini lors de la création de relations d'approbation entre les domaines de la même forêt. Dans la base de données de mots de passe (NTDS.dit) sur le contrôleur de domaine, vous pouvez trouver des utilisateurs avec le signe $ à la fin. Leur mot de passe est également utilisé pour créer des clés inter-domaines. Pour créer un ticket TGT inter-domaines, nous avons besoin d'un hachage de mot de passe de ce compte.
   
   

    Kerberos::golden /user:<user> /domain:<domain> /sid:<sid_domain> /sids:<extra_sid_entrprice_admin_group_from _another_domain> /aes256:<aes256_trust_user_password> /service:krbtgt /target:<target_domain> /ptt 

   
   Démo d'attaque:
   
   
   
   L'attaque est particulièrement pertinente lorsque le service IS a remarqué une menace et a changé le mot de passe krbtgt 2 fois. Dans ce cas, nous pourrons créer des tickets d'or en utilisant un mot de passe de confiance entre les domaines.
   
   

   4. Bug d'imprimante

   
   Le protocole distant du système d'impression Windows (MS-RPRN) a la méthode RpcRemoteFindFirstPrinterChangeNotification (Ex) activée par défaut, qui vous permet de forcer l'authentification sur tout ordinateur exécutant le service Spouleur sur l'hôte spécifié à l'aide du protocole Kerberos ou NTLM. Dans le cas de c NTLM, nous pouvons exécuter NTLM-relay, ou commencer à casser le mot de passe de l'ordinateur (ne jamais décocher). Dans le cas de Kerberos, une machine compromise avec délégation illimitée est nécessaire. Ensuite, nous pouvons prendre un ticket TGT et développer une attaque.
   
   Démo d'attaque:
   
   
   
   La figure ci-dessous montre les étapes illustrées dans la vidéo.
   
   
   
   

   Nous n'avons pas de droits d'administrateur de domaine

   
   Un peu de théorie. Carlos Garsia dans son rapport a donné un excellent tableau qui illustre les propriétés de différents types de groupes.
   
   
   
   Parmi les fonctionnalités, il convient de considérer que les groupes AD Domain Local et AD Global sont répliqués sans membres de groupe dans le catalogue global et que les groupes AD Universal sont répliqués avec les utilisateurs.
   

   En raison de la façon dont les groupes sont énumérés par le catalogue global, les résultats d'une recherche de lien arrière [c.-à-d. Les membres peuvent varier, selon que vous recherchez le catalogue global (port 3268) ou le domaine (port 389), le type de groupes auxquels l'utilisateur appartient (groupes globaux vs groupes locaux de domaine).

   Dans le cas où nous n'avons pas de droits d'administrateur de domaine, nous énumérons les objets. Nous sommes intéressés par:
   
   1. Utilisateurs d'un autre domaine disposant de droits d'administrateur local sur les machines de notre domaine.
   2. Utilisateurs d'autres domaines membres de groupes de domaines d'utilisateurs. Groupes contenant des utilisateurs d'un autre domaine.
   3. Responsables ACL étrangers.
   
   

   1. Utilisateurs d'un autre domaine disposant de droits d'administrateur local sur les machines de notre domaine

   
   Recherchez les utilisateurs d'un autre domaine qui sont des administrateurs locaux sur les hôtes de notre domaine dans BloodHound:
   
   

    MATCH (c:Computer) OPTIONAL MATCH p1 = (u1)-[:AdminTo]->(c) WHERE NOT u1.domain = c.domain WITH p1,c OPTIONAL MATCH p2 = (u2)-[:MemberOf*1..]->(:Group)-[:AdminTo]->(c) WHERE NOT u2.domain = c.domain RETURN p1,p2 

   
   
   
   Commande dans PowerView :
   
   

    Get-NetLocalGroupMember <server> 

   
   

   2. Utilisateurs d'autres domaines, composés de groupes de domaines d'utilisateurs. Groupes contenant des utilisateurs d'un autre domaine

   
   Comme mentionné ci-dessus, les utilisateurs qui sont membres de groupes Universal uniquement sont répliqués dans le catalogue global. Pour illustrer cette fonctionnalité, nous interrogerons les groupes du catalogue global qui contiennent au moins un utilisateur et une demande LDAP directe au contrôleur de domaine.
   
   

    Get-DomainGroup -Properties name, grouptype, member, DistinguishedName -LDAPFilter '(member=*)' -SearchBase "GC://jet.lab" 

   
   
   
   Lors de l'exécution d'une requête dans le catalogue global, nous ne voyons qu'un seul groupe Universal Group de type AD Universal du domaine one.jet.lab.
   
   Si nous exécutons une requête LDAP directe sur one.jet.lab, nous verrons d'autres groupes de type AD Domain local et AD Global.
   
   
   
   Ceci est important à prendre en compte lors de l'énumération des utilisateurs et des groupes.
   
   Commandes dans PowerView :
   
   

    Get-DomainForeignUser -Domain <Domain> Get-DomainForeignGroupMember -Domain <Domain> 

   
   
   
   
   
   

   3. Directeurs étrangers de l'ACL

   
   Le descripteur de sécurité ntSecurityDescriptor (https://docs.microsoft.com/en-us/windows/win32/adschema/a-ntsecuritydescriptor) est accessible à tous les utilisateurs des domaines approuvés et est répliqué dans le catalogue global. Ainsi, nous pouvons interroger tous les DACL pour tous les objets dans les domaines de confiance et filtrer les utilisateurs d'autres domaines.
   
   

    Get-DomainObjectAcl -Domain jet.lab -ResolveGuids | ?{$_.SecurityIdentifier -like 'SID_Domain*'} 

   
   
   
   Nous avons donc réussi à identifier l'utilisateur Mike du domaine forestc.lab, qui avait des droits sur le groupe mondial dans le domaine jet.lab.
   
   Le filtrage PS SID et l'authentification sélective sont utilisés pour la protection entre les forêts. Une attaque entre les forêts avec le filtrage SID a activé dirkjan sur son blog . Le 9 juillet également, Microsoft a publié une mise à jour qui désactive la délégation TGT entre les forêts par défaut. Maintenant, tout, l'histoire avec la délégation illimitée et le compromis d'une forêt à l'autre en utilisant le protocole Kerberos ne fonctionne plus.