Dans cet article, nous allons continuer de voir des cas d'usage de la fonctionnalité List Object Mode. Il fait suite à l'article Dissimulation d'objets Active Directory via la fonctionnalité List Object Mode
Maintenant que notre compte d'attaquant est dissimulé, il faut pouvoir dissimuler son appartenance à un groupe.
Pour cela, nous allons utiliser l'attribut primaryGroupId.
Concept
La documentation technique nous apprend l'information suivante sur cet attribut:
The user is a member of its primary group, although the group is not listed in the user's memberOf attribute. Likewise, a group object's member attribute will not list the user objects whose primaryGroupID is set to the group.
On comprend vite l'intérêt pour un attaquant d'utiliser cet attribut.
Combiné à la technique précédente, nous avons facilement un compte Domain Admins invisible et non "répertorié" comme membre du groupe.
Prérequis
Cette technique nécessite de modifier la partition de configuration pour activer le mode List Object, 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 ainsi que l'appartenance au groupe.
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
La technique est relativement simple. On ajoute tout d'abord le compte dans le groupe Domain Admins. J'utilise les commandes net qui se basent sur l'énumération SAM et non LDAP car le compte intruder n'est pas visible.
Si je liste les membres du groupe Domain Admins, avec une commande Powershell par exemple, je ne vois pas le compte.
En revanche si je passe par la console DSA je le vois bien comme membre du groupe.
Ce qui est confirmé par les Metadata.
Je passe ensuite le groupe Domain Admins en tant que groupe primaire du compte de l'attaquant. Pour me faciliter la tâche, j'utilise une Cmdlet Powershell avec le compte Intruder.
Si on vérifie à nouveau l'appartenance au groupe. On voit tout d'abord que le compte est passé en Absent dans les Metadata.
Et qu'il n'est plus visible par la console DSA.
Le seul moyen de retrouver le compte est d'utiliser l'énumération SAM.
Dans l'article précédent, j'ai indiqué qu'il est plus intéressant de dissimuler le compte via une OU que de rendre directement le compte invible. En effet, dans cet exemple, le compte va être protégé par le SDProp et donc l'ACL du compte va être écrasée par celle de l'AdminSDHolder. Si j'avais fait la modification en enlevant les droits List Object sur le compte il serait redevenu visible après traitement par le SDProp.
Contre-mesures et détection
Comme toujours, 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 utilisera en priorité la journalisation pour détecter l'ajout dans le groupe "Domain Admins". Les Metadata rapportent l'information bien qu'elles indiquent que le compte est absent du groupe. Elles permettent toutefois de retrouver le compte et son emplacement dans l'annuaire.
On peut aussi utiliser comme on vient de le voir l'énumération SAM.
Un petit rappel toutefois. Dans cet exemple j'ai utilisé le groupe "Domain Admins" qui est normalement plus surveillé. Il faut bien penser que la compromission de l'annuaire est un moyen et non une fin. Si l'attaquant créé plusieurs comptes et utilise la même technique pour les ajouter à des groupes donnant accès à des ressources, il est peu probable que ce soit détecté à moins d'analyser les logs AD, les logs d'accès aux ressources, les Metadata de tous les groupes et les comparer avec une énumération SAM.
Dans le cadre d'une remédiation suite à compromission, il faut donc être en mesure d'identifier ce type de "backdoor" en amont de la remédiation dès le début de la réponse à incident et éviter les actions précipitées inutiles telles que la réinitailisation des mots de passe des comptes de domaine ou du KRBTGT.
Merci de m'avoir lu.
Dans le prochaine article nous utiliserons encore cette technique pour cibler cette fois les Stratégies de groupe.
Aucun commentaire:
Enregistrer un commentaire