Modification de AdminSDHolder – Fonctionnement et stratégies de défense

Qu'est-ce que la modification AdminSDHolder ?

AdminSDHolder est un conteneur spécial dans AD (CN=AdminSDHolder,CN=System,DC=...) qui contient un descripteur de sécurité utilisé pour protéger les comptes et groupes privilégiés. Le processus SDProp copie périodiquement ce descripteur sur les objets dont l'attribut adminCount est égal à 1, assurant que ces objets conservent une ACL renforcée et ne sont pas affaiblis par l'héritage normal des ACL. Un attaquant qui peut modifier l’ACL de AdminSDHolder — ou créer un objet privilégié avec des ACL manipulées ou adminCount — peut avoir ce changement automatiquement appliqué à de nombreux comptes privilégiés via SDProp.

Comment fonctionne la modification de AdminSDHolder ?

Ci-dessous se trouve une chaîne d'attaque typique montrant comment les adversaires abusent d'AdminSDHolder et des comportements associés.

1. Obtenez une première position

L'attaquant obtient un accès dans le domaine — par exemple : un utilisateur de domaine avec peu de privilèges, un compte de service compromis, un administrateur délégué (Opérateurs de compte, Admin de schéma, etc.), ou des informations d'identification d'automatisation mal configurées. Ils peuvent également exploiter une interface de gestion exposée ou un hôte vulnérable.

2. Reconnaître la protection AD et les ACL

À partir du point d'ancrage, l'attaquant énumère les objets de l'annuaire pour découvrir l'objet AdminSDHolder et sa liste de contrôle d'accès (ACL), qui a les permissions d'écriture/modification sur AdminSDHolder et CN=System, l'ensemble des comptes avec adminCount=1, et l'appartenance à des groupes privilégiés. Outils : PowerShell Get-ACL, requêtes LDAP, scripts ADSI.

3. Identifier un chemin de modification

L'attaquant recherche un chemin qui permet de modifier les ACL sur AdminSDHolder (par exemple, un utilisateur délégué de manière incorrecte ou un groupe trop permissif tel que les opérateurs de compte ou un compte de service avec des droits d'écriture DS). Les comptes d'automatisation/de service avec des droits d'écriture AD élevés ou les comptes abandonnés avec des permissions persistantes sont des cibles attrayantes.

4. Modifier AdminSDHolder ou ACL d'objet protégé

Si autorisé, l'attaquant modifie le descripteur de sécurité AdminSDHolder pour ajouter une ACE accordant à un principal choisi des droits puissants (WriteDacl, FullControl, WriteProperty). Alternativement, ils peuvent changer les ACLs sur un compte protégé individuel ou définir adminCount=1 sur un compte de porte dérobée. Méthodes : Set-ACL, LDIF, ldapmodify, API Windows natives.

5. Attendez que SDProp se propage

SDProp s'exécute périodiquement sur les contrôleurs de domaine et propage le descripteur AdminSDHolder à tous les objets où adminCount=1. Une fois la propagation effectuée, l'ACE malveillant est appliqué aux comptes protégés — souvent les administrateurs de domaine — accordant à l'attaquant un accès élevé persistant.

6. Utilisez des droits élevés pour persister et vous déplacer latéralement

Avec les nouvelles ACL, l'attaquant peut prendre le contrôle des comptes d'administrateur de domaine (si autorisé), lire/modifier la configuration sensible (GPOs, trusts), créer des principaux de service supplémentaires ou des comptes d'admin cachés, et maintenir une persistance qui survit à une simple remédiation si les changements d'ACL ne sont pas détectés.

✱ Variante : Modification directe de adminCount ou de SD d'un seul objet

Un attaquant capable de modifier des objets individuels peut définir adminCount=1 sur un compte choisi, le rendant cible pour SDProp, ou remplacer directement le descripteur de sécurité d'un compte à haute valeur. Les deux variantes peuvent donner un accès privilégié durable.

Diagramme de flux d'attaque

Exemple : Perspective de l'organisation

Un attaquant compromet un compte de service utilisé par un outil de sauvegarde obsolète. Ce compte de service a une permission d'écriture déléguée sur un sous-arbre sous CN=System. L'attaquant écrit une ACE accordant à leur compte attaquant le contrôle total sur AdminSDHolder, attend la propagation de SDProp, puis utilise les privilèges élevés résultants pour prendre le contrôle des comptes d'administrateur de domaine et exporter les secrets de domaine.

Exemples (modèles du monde réel)

Conséquences de la modification de AdminSDHolder

Modifier le descripteur AdminSDHolder ou les objets protégés peut avoir des effets dévastateurs :

Conséquences financières

La compromission de comptes privilégiés peut entraîner le vol de propriété intellectuelle, de dossiers financiers ou de données personnelles des clients, suivie d'amendes réglementaires, de coûts de réponse aux incidents, de frais juridiques et de demandes de rançon éventuelles.

Perturbation opérationnelle

Un compromis de domaine sape l'authentification et l'autorisation dans tout l'environnement. Les services peuvent être désactivés, AD peut nécessiter une remédiation ou une reconstruction minutieuse, et les opérations commerciales peuvent s'arrêter pendant la récupération.

Dommages à la réputation

La preuve d'un compromis de domaine indique des échecs de sécurité importants et peut nuire à la confiance des clients, aux relations avec les partenaires et à la réputation publique.

Impact juridique et réglementaire

L'exposition de données réglementées peut déclencher des actions de conformité, des enquêtes et des amendes liées au GDPR, HIPAA ou à des réglementations spécifiques à l'industrie.

Cibles communes : Qui est à risque ?

Comptes protégés par AdminSDHolder

Domain Admins, Enterprise Admins, Schema Admins, Administrators

Comptes de service et principaux non humains délégués

Des comptes de service se sont accidentellement vu accorder des droits d'écriture sur des conteneurs système

Automatisation héritée

Outils de sauvegarde, agents de surveillance, scripts DevOps avec des capacités d'écriture AD

De grands domaines AD mal audités

De nombreuses permissions déléguées et comptes obsolètes

Évaluation des risques

Comment prévenir la modification de AdminSDHolder

La prévention nécessite de réduire ceux qui peuvent modifier AdminSDHolder et d'améliorer la détection & la gouvernance.

Hygiène des ACL et délégations

Restreignez les permissions sur CN=AdminSDHolder : seul un ensemble minimal de principaux à haut privilège de confiance devrait avoir WriteDacl, WriteOwner ou FullControl. Auditez les permissions déléguées sous CN=System et révoquez les droits excessifs. Évitez d'accorder l'écriture AD aux comptes de service non privilégiés ; utilisez des identités privilégiées dédiées et contrôlées pour l'automatisation.

Privileged Access Management (PAM)

Utilisez l'accès JIT/juste-à-temps pour les tâches d'administration plutôt que des privilèges permanents. Utilisez des comptes de service gérés (gMSA) et des certificats/secrets à courte durée pour les services lorsque c'est possible.

Renforcement & Contrôle des comptes

Renforcez l'accès d'urgence / les comptes break-glass, désactivez ou supprimez les comptes de service obsolètes/inutilisés, et appliquez la gestion du cycle de vie.

Contrôle des changements & Séparation des fonctions

Exigez l'approbation de plusieurs personnes pour les modifications apportées aux objets AD critiques (AdminSDHolder, listes de contrôle d'accès racine de domaine). Consignez et examinez les tickets de changement liés aux modifications des ACL.

Vérifications de référence & d'intégrité

Conservez une copie de référence du descripteur de sécurité AdminSDHolder et comparez-le périodiquement à l'objet actif ; alertez en cas de modification. Analysez régulièrement les objets adminCount=1 et les comptes inattendus dans les groupes privilégiés.

Stratégies de détection, d'atténuation et de réponse

Détection

• Auditez et alertez sur les écritures dans CN=AdminSDHolder : activez l'audit du service d'annuaire (DS Access) pour capturer les modifications d'AdminSDHolder et générer des alertes pour les changements d'attributs nTSecurityDescriptor ou de DACL.
• Surveillez les modifications du adminCount : alertes lorsque adminCount est défini sur 1 pour les comptes inhabituels.
• Alertez sur les nouvelles ACE accordant aux principaux non-admin des droits élevés sur les objets protégés.
• Surveillez les pics de modifications des comptes protégés (réinitialisations de mots de passe, changements de listes de contrôle d'accès).
• Surveillez les changements d'appartenance aux groupes privilégiés et les ajouts inattendus.

Réponse

1. Supprimez immédiatement les ACE malveillants et restaurez AdminSDHolder au dernier descripteur de sécurité connu comme bon (ou à partir d'une sauvegarde vérifiée).
2. Révoquez l'accès de l'attaquant : désactivez les comptes, faites tourner les identifiants, révoquez les certificats/secrets des comptes de service qui ont été utilisés.
3. Invalidez les sessions d'authentification lorsque cela est possible (forcez la purge des tickets Kerberos, exigez une réauthentification).
4. Effectuez une évaluation de l'intégrité du domaine et de l'impact : énumérez où l'ACE malveillant a été propagé, identifiez les comptes privilégiés compromis et recherchez des artefacts latéraux.
5. Effectuez des réinitialisations de credentials pour les comptes privilégiés affectés et faites tourner les secrets de service.
6. Traquez la persistance : vérifiez les principaux services créés, les tâches planifiées, les GPO avec des scripts malveillants ou les entrées de délégation modifiées.

Atténuation

• Limitez l'exposition future en supprimant les délégations d'écriture inutiles, en renforçant les contrôles et en mettant en œuvre Privileged Access Management/JIT pour les activités d'administration.
• Améliorez l'audit et intégrez des alertes dans les playbooks de réponse aux incidents pour accélérer la détection et l'endiguement.

Comment Netwrix peut aider

Netwrix Threat Prevention vous aide à arrêter l'abus de AdminSDHolder en détectant et en bloquant les modifications non autorisées d'objets AD critiques en temps réel. Il crée un historique d'audit complet et résistant à la manipulation pour les modifications d'objets et d'attributs, et peut automatiquement alerter ou empêcher des actions à risque telles que les modifications de DACL et les modifications de groupes privilégiés ou de GPO, réduisant ainsi le délai de persistance et de prise de contrôle du domaine. Les équipes peuvent personnaliser les politiques pour verrouiller les conteneurs sensibles et appliquer une réponse immédiate lorsque AdminSDHolder ou des comptes protégés sont touchés, renforçant la Data Security That Starts with Identity.

Impact spécifique à l'industrie

Évolution des attaques & tendances futures

• Automatisation de la reconnaissance des ACL — les attaquants automatisent les recherches de conteneurs système inscriptibles et de permissions déléguées dans de grands domaines AD.
• La combinaison avec d'autres attaques AD — L'abus de AdminSDHolder est combiné avec des chaînes Golden Ticket / DCSync / abus de ACL pour une persistance robuste.
• L'exposition de la chaîne d'approvisionnement et DevOps — la fuite des identifiants d'automatisation dans les pipelines continue d'apparaître comme vecteurs pour les modifications déléguées des ACL.
• Moins d'actions bruyantes, plus de discrétion — les attaquants préfèrent les manipulations des ACL/DACL car elles se fondent dans l'activité légitime des administrateurs.

Statistiques clés & Télémétrie (contrôles suggérés)

• Pourcentage de domaines avec des permissions d'écriture non standard sur CN=System ou AdminSDHolder (mesure de l'hygiène).

• Nombre de comptes avec adminCount=1 et sans activité d'administration légitime récente.

• Nombre de comptes de service avec des privilèges d'écriture AD dans l'environnement.

Réflexions finales

La modification de AdminSDHolder est une technique discrète et à fort impact : en attaquant le mécanisme utilisé par AD pour protéger les comptes privilégiés, les attaquants peuvent obtenir une élévation de privilèges durable et étendue au domaine qui survit à de nombreuses étapes de remédiation simples. Se défendre contre cela nécessite une gouvernance stricte des ACL, une délégation basée sur le principe du moindre privilège, des contrôles d'accès privilégiés robustes (Privileged Access Management/JIT), un audit continu de AdminSDHolder et des objets adminCount, et des playbooks de réponse répétés pour retirer rapidement les ACE malveillants et faire tourner les identifiants impactés.