Note : Mise à jour le 30 mars 2022
Lors d’une précédente Hybrid Identity Protection Conference, plusieurs d’entre nous avons évoqué l’utilisation persistante d’Active Directory comme cible privilégiée 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 utilisateurs afin d’accéder à des niveaux de privilèges de plus en plus élevés au sein d’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. En conséquence, de nombreuses recherches et discussions en matière de sécurité ont porté sur les différentes voies d’intrusion au sein d’AD. Diverses méthodes ingénieuses exploitent des autorisations AD mal déléguées pour prendre le contrôle d’entités de sécurité AD privilégiées. L’une de ces méthodes consiste à parvenir à un stade où l’attaquant peut s’implanter durablement dans l’environnement sans être détecté. Et l’un des moyens d’y parvenir est de créer ou de prendre le contrôle d’un compte utilisateur privilégié dans AD, puis de dissimuler ce compte aux regards indiscrets des administrateurs.
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 !
