Je vais aborder dans cet article une technique permettant de dissimuler les droits sur un objet Active Directory et notamment les droits étendus (Extended Rights).
Pour cet exemple, je vais dissimuler les droits étendus permettant d'utiliser la technique DCSync.
Pour rappel, les droits étendus consistent en l'exécution de tâches spécifiques sur certains types d'objet, telles que réinitialiser le mot de passe d'un utilisateur.
Ces droits étendus sont visibles dans le conteneur "Extended Rights" de la partition de Configuration.
Concept
Cette technique repose sur l'échange de l'attribut RightsGuid de deux droits étendus.
Il faut donc au préalable identifier quels sont les droits étendus disponibles pour une classe d'objet Active Directory et qui bénéficie d'une délégation sur ces droits étendus.
Pour utiliser la technique DCSync nous avons besoins de 2 droits étendus (DS-Replication-Get-Changes et DS-Replication-Get-Changes-All) sur la partition de domaine (objet de classe domainDNS).
La liste des droits étendus s'appliquant à la classe domainDNS est disponible ici : Extended Rights Reference
En vérifiant qui dispose de droits étendus sur la partition de domaine on s'aperçoit que "Utilisateurs Authentifiés" dispose des 3 droits étendus suivants :
Pour comprendre l'utilité de ces droits vous pouvez vous référer à l'article suivant: Vos administrateurs respectent-ils la politique de mot de passe que vous avez définie ?
Nous avons donc tous les éléments pour mettre en place une backdoor basée sur la substitution de l'attribut RightsGuid de deux droits étendus.
Il nous suffit d'abord d'échanger la valeur de l'attribut RightsGuid entre par exemple DS-Replication-Get-Changes-All et Unexpire-Password puis entre DS-Replication-Get-Changes et Enable-Per-User-Reversibly-Encrypted-Password.
Puis de modifier les droits étendus d'Utilisateurs Authentifiés pour lui affecter les droits pour DCSync.
Au final, l'affichage des droits affectés à Utilisateurs Authentifiés n'aura pas changé alors qu'ils auront des droits pour DCSync.
Prérequis
Cette technique nécessite de modifier la partition de configuration, il faut donc avoir des privilèges "Administrateurs de l'Entreprise".
Il faut aussi modifier les ACL de la partition de domaine, il faut donc avoir les privilèges pour cette modification.
Enfin, afin d'éviter la journalisation de ces modifications, vous pouvez utiliser la technique décrite dans l'article suivant: Éviter la journalisation des modifications d'ACL sur les objets Active Directory
Dans ce cas il faudra aussi avoir les privilèges "Administrateurs du Schéma".
Utilisation de la technique
Les modifications peuvent être effectuée via la console ADSIEdit.msc.
On commence par faire la substitution des RightsGuid.
On peut ensuite vérifier que l'affichage des droits a été modifié.
Si on vérifie pour le groupe "Contrôleurs de domaine" on voit que l'affichage a aussi changé.
Il suffit ensuite de modifier les droits de Utilisateurs Authentifiés pour lui réaffecter les droits d'origine qui ont été substitués par les droits DCSync.
La backdoor est désormais en place et résistera à une analyse basique des droits sur la partition de domaine. Il y a en effet peu de chance que les droits des différents groupes Contrôleurs de domaine soient analysés. L'affichage des droits des autres groupes (Administrateurs, administrateurs du domaine, administrateurs de l'entreprise, SYSTEM) ne sera pas affecté car ils bénéficient de tous les droits étendus sur la partition de domaine. La substitution n'a donc pas d'effet sur eux.
Il reste à vérifier que la backdoor est bien fonctionnelle.
Désormais, tous les utilisateurs authentifiés pourront effectuer une attaque DCSync.
Contre-mesures et détection
Mise à part avec une bonne gestion des comptes à privilèges (via une forêt d'administration par exemple), il est difficile de se prémunir de ce type de technique.
On se concentrera plutôt sur la détection.
Encore une fois les audits par défaut ne remontent pas la substitution des RightsGuid.
En configurant correctement les audits sur la partition de configuration la substitution est bien journalisée. Toutefois cette journalisation peut être éviter avec la technique décrite dans l'article suivant en désactivant l'audit de l'attribut RightsGuid: Éviter la journalisation des modifications d'ACL sur les objets Active Directory
De même pour les évènements d'accès qui sont rarement collectés.
Reste ma méthode préférée, les metadata de réplication Active Directory qui permettent de détecter la substitution des RightsGuid.
Encore une fois, l'analyse des Metadata de réplication présente un grand intérêt lors d'analyse forensic Active Directory.
Comme je l'ai dit dans le précédent article, je mettrais prochainement à disposition un module powershell de forensic Active Directory permettant de détecter ce type de technique.
Merci de m'avoir lu et à bientôt pour de nouveaux articles sur ces sujets.
Aucun commentaire:
Enregistrer un commentaire