AdminSDHolder SDProp Backdoor Active Directory : le processus horaire d'un accès privilégié permanent

Qu'est-ce que AdminSDHolder et SDProp

AdminSDHolder SDProp backdoor Active Directory persistence est la technique que ce guide détaille en profondeur : comment les attaquants implantent un accès privilégié permanent, comment les défenseurs le détectent, et comment y remédier avant que cela ne devienne un risque durable. AdminSDHolder est un objet conteneur qui se trouve dans CN=AdminSDHolder,CN=System,DC=<domaine>,DC=<tld> dans chaque domaine AD, et SDProp — le Security Descriptor Propagator — est le processus en arrière-plan qui copie son ACL sur chaque objet qu'il protège, par défaut une fois par heure (Microsoft Learn — Appendix C: Protected Accounts and Groups in Active Directory).

SDProp s'exécute toutes les 60 minutes (par défaut) sur le contrôleur de domaine détenant le rôle PDC Emulator (PDCE). Il compare les permissions sur AdminSDHolder avec celles des comptes et groupes protégés du domaine — et là où elles diffèrent, il écrase l'ACL de l'objet pour qu'elle corresponde exactement à celle d'AdminSDHolder. L'intervalle est contrôlé par la valeur DWORD AdminSDProtectFrequency sous HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters sur le PDCE, valide de 60 à 7200 secondes ; la plupart des environnements n'y touchent jamais et fonctionnent simplement avec la valeur par défaut de 60 minutes.

Les groupes et comptes intégrés suivants sont protégés par AdminSDHolder/SDProp dans chaque domaine AD :

Deux effets de bord marquent chaque objet protégé : l'attribut adminCount est positionné à 1, et l'héritage de l'ACL depuis l'OU parente est désactivé de façon permanente — jusqu'à ce que quelque chose le supprime explicitement. Microsoft a conçu SDProp pour empêcher les comptes privilégiés d'hériter silencieusement de permissions plus faibles si quelqu'un les déplace dans l'annuaire. C'est le même mécanisme sous-jacent que les attaquants exploitent déjà pour l'abus d'ACL et le DCSync sur des objets individuels — ce backdoor déplace simplement l'abus d'un niveau, sur l'objet modèle qui alimente d'un coup chaque compte protégé.

AdminSDHolder SDProp Backdoor Active Directory, Étape par Étape

La technique n'est pas nouvelle — Sean Metcalf l'a documentée en 2015 — et elle fonctionne encore exactement comme décrit aujourd'hui, car elle exploite un mécanisme intentionnel plutôt qu'un bug (AD Security — Sneaky Active Directory Persistence #15). Contrairement à d'autres chemins d'attaque Active Directory qui enchaînent plusieurs mauvaises configurations pour atteindre Domain Admin, celui-ci ne nécessite qu'une seule écriture sur un seul objet.

Étape 1 — Ajouter une ACE Malveillante sur AdminSDHolder

Un attaquant qui peut déjà écrire sur CN=AdminSDHolder,CN=System,DC=... — généralement parce qu'il est Domain Admin/Enterprise Admin, ou qu'il a obtenu WriteDacl/GenericWrite dessus via un abus d'ACL préalable — accorde à un compte à faible privilège ou jetable un Full Control (ou GenericAll) directement sur l'objet AdminSDHolder. Dans l'écrit original de Metcalf, un compte utilisateur ordinaire se voit accorder le contrôle total sur AdminSDHolder lui-même. Rien ne change concernant ce compte — il n'est toujours membre d'aucun groupe privilégié, et il reste anodin lors d'une revue de routine des appartenances aux groupes.

Étape 2 — Attendre (ou Forcer) la Propagation par SDProp

Lors de son prochain cycle — jusqu'à 60 minutes plus tard — SDProp copie l'ACL d'AdminSDHolder, ACE malveillante incluse, sur chaque compte et groupe avec adminCount=1 : Domain Admins, Enterprise Admins, l'objet utilisateur de chaque membre existant, et tout compte ajouté à ces groupes par la suite. Le compte jetable n'a jamais besoin de rejoindre Domain Admins ; il lui suffit d'avoir des droits de modification sur les objets qui comptent. Le cycle peut aussi être forcé immédiatement — par un administrateur qui teste un changement, ou par un attaquant impatient de confirmer que le backdoor a bien pris — via Ldp.exe, en positionnant l'attribut RunProtectAdminGroupsTask à 1 sur le rootDSE (Microsoft Learn — Appendix C).

Étape 3 — Continuer à Utiliser des Droits qui N'apparaissent Jamais comme Appartenance à un Groupe

Comme l'ACE réside sur l'objet modèle plutôt que sur un compte unique, elle revient à chaque exécution de SDProp — même après qu'un défenseur ait repéré la permission malveillante sur l'objet utilisateur d'un Domain Admin et l'ait supprimée à cet endroit. Tant que le correctif n'est pas appliqué à AdminSDHolder lui-même, le cycle SDProp suivant la réapplique silencieusement partout. C'est ce qui en fait de la persistance plutôt qu'une simple élévation de privilège ponctuelle : les rotations de mot de passe, la désactivation de compte ou le retrait du compte de l'attaquant de Domain Admins ne changent rien, car ce compte n'a jamais été membre — il a obtenu ses droits via le modèle d'ACL. C'est aussi ce qui le distingue de l'imbrication dangereuse de groupes classique : l'imbrication se cache dans l'appartenance aux groupes, cette technique se cache dans une seule ACL que la plupart des administrateurs ne pensent jamais à vérifier.

Les défenseurs peuvent inventorier les cibles candidates et les artefacts résiduels de cette technique avec une seule requête LDAP :

Get-ADObject -LDAPFilter "(&(admincount=1)(|(objectcategory=person)(objectcategory=group)))" -Properties MemberOf,Created,Modified,AdminCount

Tout résultat dont le MemberOf n'inclut plus de groupe protégé, ou dont les permissions effectives semblent sans rapport avec son rôle réel, mérite d'être investigué plus avant avant de supposer qu'il s'agit d'une dette de nettoyage légitime.

Détection

Le mécanisme ne touche qu'un seul objet, donc la détection est étroite mais fiable — à condition que la bonne politique d'audit et la bonne SACL soient déjà en place.

Deux conditions doivent être réunies avant que l'événement 5136 ne se déclenche : la sous-catégorie Politique d'audit avancée → DS Access → Auditer les modifications du service d'annuaire doit être activée, et une SACL couvrant le descripteur de sécurité (ou « Write All Properties ») doit exister sur l'objet AdminSDHolder lui-même. Aucune des deux n'est activée par défaut dans la plupart des environnements. La règle de détection publiée par Elastic pour cette technique précise dépend de ces deux conditions pour se déclencher — sa requête est event.code:5136 and host.os.type:"windows" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*, cartographiée sur MITRE ATT&CK T1098 (Account Manipulation) et T1078.002 (Valid Accounts: Domain Accounts), classée en sévérité élevée (Elastic — AdminSDHolder Backdoor detection rule). La règle Splunk Security Content équivalente confirme la même logique 5136/nTSecurityDescriptor et le même prérequis de SACL (Splunk Security Content — Windows AD AdminSDHolder ACL Modified).

Auditer l'ACL Directement

Les journaux d'événements n'aident qu'une fois l'audit activé — une revue d'ACL ponctuelle fonctionne quel que soit l'état de la politique d'audit et constitue un premier contrôle raisonnable dans un environnement qui n'a jamais activé l'audit des modifications du service d'annuaire :

Get-Acl -Path "AD:\CN=AdminSDHolder,CN=System,DC=corp,DC=local" | Select-Object -ExpandProperty Access

Passez en revue chaque entrée du résultat en la comparant à la base de référence connue de la section remédiation ci-dessous. Tout élément qui n'est pas un principal intégré connu mérite d'être escaladé immédiatement, que la journalisation soit en place ou non.

Remédiation

Réponse Immédiate

1. Auditez l'ACL d'AdminSDHolder dès maintenant. Comparez ses trustees à une base de référence connue (Domain Admins, Enterprise Admins, Administrators, SYSTEM, et tout compte de service explicitement délégué) et supprimez tout élément inattendu — comme le formule Metcalf, « ceux-ci devraient rester à leur valeur par défaut ».
2. Forcez SDProp à s'exécuter immédiatement après la remédiation, via Ldp.exe → RunProtectAdminGroupsTask=1 sur le rootDSE, plutôt que d'attendre jusqu'à 60 minutes pour confirmer que le correctif s'est propagé (Microsoft Learn — Appendix C).

Durcissement Continu

3. Activez l'audit des modifications du service d'annuaire et positionnez une SACL sur AdminSDHolder afin que les futures modifications génèrent l'événement 5136, comme décrit dans la section détection ci-dessus.
4. Inventoriez chaque objet avec adminCount=1 avec la requête LDAP présentée plus haut et rapprochez-le de l'appartenance actuelle aux groupes protégés. Pour les comptes confirmés comme n'appartenant plus à un groupe protégé, réinitialisez adminCount et ne réactivez l'héritage qu'après avoir confirmé que l'appartenance au groupe a bien disparu — le réinitialiser en premier permettrait à SDProp d'annuler le correctif au prochain passage. Ces comptes orphelins constituent la même dette de nettoyage que celle couverte dans Comptes Obsolètes et Sur-Privilégiés.
5. Restreignez qui peut écrire sur AdminSDHolder. Seuls les Domain Admins, Enterprise Admins, et Administrators peuvent le modifier ou en prendre possession par défaut — maintenez cet état. Tout GenericWrite ou WriteDacl délégué sur le conteneur System, ou sur AdminSDHolder spécifiquement, constitue un risque permanent et doit être traité comme Tier 0.

Comment EtcSec Détecte Cela

L'audit Active Directory d'EtcSec vérifie ADMIN_SD_HOLDER_MODIFIED pour les trustees inattendus ou les droits dangereux (Full Control, GenericAll, WriteDacl, WriteOwner) sur l'ACL de l'objet AdminSDHolder, ADMINSDHOLDER_BACKDOOR pour le motif spécifique d'un principal non privilégié détenant ces droits, et ADMIN_COUNT_ORPHANED pour les comptes toujours marqués adminCount=1 après avoir quitté un groupe protégé — une dette de nettoyage qui à la fois masque de véritables backdoors et gonfle votre nombre de comptes privilégiés. Ce backdoor apparaît rarement seul : il est fréquemment retrouvé aux côtés d'une dérive plus large des accès privilégiés, donc les deux contrôles méritent d'être exécutés ensemble dans le cadre d'un audit de routine plutôt que traités comme des constats isolés.