Note : Mise à jour le 30 mars 2022
Lors d'une précédente conférence sur la protection des identités hybrides, plusieurs d'entre nous ont parlé de l'utilisation continue d'Active Directory comme sujet d'intérêt dans les attaques de logiciels malveillants. Qu'il s'agisse d'exploiter AD pour obtenir des informations sur les accès privilégiés, de compromettre des comptes d'utilisateurs qui conduisent à des niveaux de privilèges croissants dans AD ou de cibler délibérément les contrôleurs de domaine AD avec des ransomwares, Active Directory est aujourd'hui une cible de choix. C'est pourquoi il y a eu beaucoup de recherches et de discussions en matière de sécurité sur les différentes voies de compromission dans AD. Diverses méthodes astucieuses tirent parti de permissions AD mal déléguées pour prendre le contrôle de principes de sécurité AD privilégiés. L'une de ces méthodes consiste à faire en sorte que l'attaquant puisse persister dans l'environnement sans être détecté. L'un des moyens d'y parvenir consiste à créer ou à prendre le contrôle d'un compte d'utilisateur privilégié dans AD, puis à cacher ce compte aux yeux des administrateurs indiscrets.
Lecture associée
Par exemple, s'il dispose d'autorisations suffisantes sur un objet utilisateur, un attaquant peut s'approprier l'utilisateur, définir un ACE Deny Read pour tous les utilisateurs sur cet objet, et l'objet est essentiellement caché, comme le montre l'illustration ci-dessous :
Vous pouvez également empêcher l'utilisateur d'être visible par d'autres administrateurs en refusant l'autorisation "List Contents" à tout le monde sur l'OU cachée dans la capture d'écran ci-dessus. Cela empêcherait tout administrateur normal de remarquer la présence de cet utilisateur et un attaquant pourrait potentiellement utiliser le compte sans être découvert (ou du moins trouvé).
Un ami de Semperis, Michael Dubinsky(@MichaelDubinsky), a écrit un excellent article de blog sur ce phénomène de dissimulation, ainsi qu'un script PowerShell pour détecter les objets utilisateur cachés en énumérant les identifiants relatifs (RID) laissés dans le pool AD RID et en essayant ensuite d'atteindre le SID de chaque objet. Si un SID recherché ne peut être trouvé à l'aide d'un appel LDAP standard, le script indiquera que vous n'avez pas accès à cet objet, ce qui pourrait indiquer la présence d'un objet caché.
Notre directeur technique Guy Teverovsky a proposé une approche alternative et un utilitaire, AD Hidden Object Detectorqui permet de trouver des objets Active Directory cachés en utilisant une nouvelle approche. Il utilise essentiellement les mêmes appels API que notre Directory Services Protector pour interroger AD au niveau de la réplication de l'annuaire. Cet appel de niveau inférieur nous permet de déterminer le nombre d'objets dont AD a connaissance, indépendamment des ACL en place sur l'objet, et de le comparer au nombre d'objets pour lesquels nous disposons d'une autorisation. L'outil renvoie ensuite tous les objets qu'il a trouvés par le biais de notre appel de réplication et que nous n'avons pas trouvés par le biais des appels LDAP normaux. L'utilitaire doit être exécuté en tant qu'utilisateur privilégié dans AD, mais il trouve facilement mon objet "Hidden User", comme le montre la sortie de l'utilitaire ci-dessous.
L'avantage de cet utilitaire est qu'il peut trouver n'importe quel type d'objet caché, et pas seulement des objets d'utilisateur. Vous pouvez télécharger l'utilitaire ici AD Hidden Object Detector et l'essayer. Faites-nous savoir ce que vous en pensez et si vous trouvez des objets Active Directory cachés, il est peut-être temps de creuser plus profondément et de voir qui se cache dans les environs !
