Trouver et supprimer les droits DCSync dans AD

Le DCSync n'est pas un exploit. C'est le protocole de réplication d'annuaire (MS-DRSR) qui fait exactement ce pour quoi il a été conçu, à la demande de quelqu'un qui ne devrait pas le demander. Tout principal détenant deux droits étendus sur le contexte de nommage du domaine peut réclamer à un DC, via le réseau, les données de mot de passe de chaque compte, y compris krbtgt. Des outils comme Mimikatz et secretsdump d'Impacket en font une opération d'une ligne, qui ne laisse aucun fichier sur le DC.

Savoir qui détient ces droits est donc l'une des questions d'ACL les plus importantes de tout domaine, et l'une des moins vérifiées. Le guide de référence sur les ACL présente la requête de base. Ce guide couvre l'audit complet : chaque droit équivalent au DCSync, les valeurs par défaut attendues, la manière de retirer le reste en toute sécurité et la détection de l'usage des droits qui doivent rester.

Les droits qui, combinés, donnent le DCSync

Les autorisations de réplication sont des droits étendus (droits de contrôle d'accès) accordés sur la tête du contexte de nommage, c'est-à-dire l'objet domaine lui-même (par exemple DC=corp,DC=example,DC=com) :

Le DCSync des secrets nécessite Get-Changes plus Get-Changes-All. Mais il faut aussi compter les droits qui permettent de les accorder ou qui les impliquent :

• GenericAll sur l'objet domaine inclut tous les droits étendus.
• AllExtendedRights, une ACE ExtendedRight avec un ObjectType vide, couvre tous les droits de contrôle d'accès.
• WriteDACL ou WriteOwner sur l'objet domaine permet à son détenteur de s'accorder les deux droits à tout moment.
• L'appartenance à tout groupe détenant l'un des droits ci-dessus, y compris par imbrication.

Un audit qui ne cherche que les deux GUID passe à côté des quatre derniers cas. Les outils d'analyse des chemins d'attaque les modélisent tous comme une seule arête DCSync.

Mesurer : énumérer chaque principal capable de répliquer

Les valeurs rightsGuid sont identiques dans toutes les forêts : on peut donc les coder en dur. Signalez chaque ACE qui accorde le DCSync ou permet de l'obtenir :

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

$getChanges    = [guid]'1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'
$getChangesAll = [guid]'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
$filteredSet   = [guid]'89e95b76-444d-4c62-991a-0facbeda640c'
$empty         = [guid]::Empty

$findings = foreach ($ace in ($acl.Access | Where-Object { $_.AccessControlType -eq 'Allow' })) {
    $r = $ace.ActiveDirectoryRights
    $why = switch ($true) {
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::GenericAll) } { 'GenericAll'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::WriteDacl) }  { 'WriteDACL'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::WriteOwner) } { 'WriteOwner'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight) -and $ace.ObjectType -eq $empty } { 'AllExtendedRights'; break }
        { $ace.ObjectType -eq $getChangesAll } { 'Get-Changes-All'; break }
        { $ace.ObjectType -eq $getChanges }    { 'Get-Changes'; break }
        { $ace.ObjectType -eq $filteredSet }   { 'Get-Changes-In-Filtered-Set'; break }
    }
    if ($why) { [PSCustomObject]@{ Principal = $ace.IdentityReference.Value; Right = $why; Inherited = $ace.IsInherited } }
}
$findings | Sort-Object Principal, Right | Format-Table -AutoSize

Développez ensuite les groupes en membres effectifs, car une ACE accordée à « IT-Sync-Operators » n'est pas plus sûre que l'appartenance à ce groupe :

$findings.Principal | Sort-Object -Unique | Where-Object { $_ -notmatch '^(NT AUTHORITY|BUILTIN)\\' } |
    ForEach-Object {
        $name = $_.Split('\')[-1]
        $obj = Get-ADObject -Filter "sAMAccountName -eq '$name'" -Properties objectClass
        if ($obj.objectClass -eq 'group') {
            Get-ADGroupMember $obj -Recursive | Select-Object @{n='ViaGroup';e={$name}}, SamAccountName, objectClass
        }
    }

Exécutez la même requête sur chaque domaine de la forêt. Chaque domaine a son propre contexte de nommage et sa propre ACL.

Auditer : comparer à l'ensemble attendu

Dans un domaine par défaut, les principaux qui détiennent des droits de réplication sur l'objet domaine sont :

• Domain Controllers et Enterprise Domain Controllers : les DC eux-mêmes.
• Enterprise Read-only Domain Controllers : Get-Changes uniquement. Les RODC ne reçoivent pas Get-Changes-All.
• Administrators (intégré), par lequel Domain Admins et Enterprise Admins l'obtiennent, en plus des larges droits par défaut que ces groupes détiennent sur l'objet domaine.
• SYSTEM.

Tout le reste doit avoir un propriétaire et une justification. Constats fréquents et conduite à tenir :

Autres contextes de nommage, domaines et forêts

Le contexte de nommage du domaine est l'endroit où résident les secrets de mot de passe : c'est donc là que le DCSync compte le plus. Les partitions Configuration et Schéma ont aussi leurs propres ACL de réplication. Elles ne contiennent aucun hachage de mot de passe, mais des droits d'écriture sur Configuration peuvent affecter tous les domaines de la forêt (sites, objets AD CS, configuration Exchange). Exécutez la même requête sur (Get-ADRootDSE).configurationNamingContext et examinez tout ce qui n'est pas un groupe d'administration intégré ou un DC.

Dans une forêt multidomaine, répétez l'audit dans chaque domaine. Une attribution dans un domaine enfant expose les comptes de ce domaine, et les Enterprise Admins de la racine peuvent de toute façon tout atteindre. À travers les approbations de forêt, les droits de réplication ne franchissent pas la frontière, sauf si quelqu'un a explicitement accordé une ACE à un principal étranger. Une telle attribution apparaît dans vos résultats sous forme de SID non résolu ou de principal de sécurité étranger, et doit toujours faire l'objet d'une investigation.

Vérifiez whenChanged sur l'objet domaine et votre historique d'événements 5136 pour savoir quand une ACE inattendue est apparue. Une attribution de réplication non standard sans trace de changement est une technique de persistance classique.

Appliquer : retirer ce qui n'a pas de propriétaire

Retirez des ACE individuelles, pas des principaux entiers, afin de ne pas supprimer d'autres droits par accident. Sauvegardez d'abord le descripteur de sécurité complet :

$domainDN = (Get-ADDomain).DistinguishedName
(Get-Acl "AD:\$domainDN").Sddl | Out-File "C:\Tier0\Backup\domain-root-$(Get-Date -f yyyyMMdd).sddl"

$acl    = Get-Acl "AD:\$domainDN"
$target = 'CORP\svc-oldaudit'
$acl.Access | Where-Object {
    $_.IdentityReference.Value -eq $target -and -not $_.IsInherited -and
    $_.ObjectType -in @([guid]'1131f6aa-9c07-11d1-f79f-00c04fc2dcd2', [guid]'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2')
} | ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "AD:\$domainDN" -AclObject $acl

Si vous trouvez une attribution que personne ne sait expliquer, surtout si elle est récente ou détenue par un utilisateur peu privilégié, ne vous contentez pas de la supprimer pour passer à autre chose. Traitez-la comme une compromission possible. Préservez les preuves (la sauvegarde SDDL, les événements 5136 et 4662, l'historique d'ouverture de session du compte), partez du principe que tous les hachages du domaine ont pu être copiés et planifiez des réinitialisations d'identifiants en partant du sommet : krbtgt deux fois avec une réplication entre les deux, comptes Tier 0, comptes de service, puis tous les autres. Retirer l'ACE empêche les usages futurs. Cela ne change rien aux hachages déjà dérobés.

Pour les comptes qui doivent conserver ces droits :

• Intégrez-les au modèle d'administration Tier 0. Ils ne se connectent qu'à des systèmes Tier 0, ont des mots de passe longs et aléatoires ou gérés, et sont exclus de la délégation.
• Si le produit le permet, accordez Get-Changes uniquement et vérifiez si la fonctionnalité dépendant des secrets est réellement utilisée.
• Privilégiez un groupe dédié par produit (par exemple T0-Repl-EntraConnect) détenteur de l'ACE, afin que les changements d'appartenance apparaissent dans l'audit des modifications de groupes.

Vérifier et détecter

Relancez le script de mesure et comparez le résultat à votre liste approuvée. La sortie doit désormais correspondre exactement à l'ensemble attendu. Planifiez le script chaque semaine et alertez sur toute différence.

Pour la détection, activez Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > DS Access > Audit Directory Service Access (Success) sur les DC, et vérifiez que l'objet domaine dispose d'une SACL auditant Everyone pour les droits de contrôle d'accès de réplication. Alertez ensuite sur :

• L'événement 4662 lorsque l'objet est l'objet domaine, que le masque d'accès vaut 0x100 (Control Access), que les propriétés contiennent {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} ou {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} et que le sujet n'est pas un compte d'ordinateur de DC. Mettez le compte Entra Connect en liste d'autorisation par son nom, et uniquement depuis son serveur.
• L'événement 5136 sur l'objet domaine lorsque nTSecurityDescriptor est modifié. Quiconque ajoute des droits de réplication apparaît ici. La référence des ID d'événements détaille les champs des deux événements.

Testez l'alerte en laboratoire : accordez les deux droits de réplication à un compte de test dédié, utilisez-le pour demander la réplication des secrets d'un seul utilisateur de laboratoire (par exemple avec un outil DCSync autorisé comme Impacket secretsdump), et vérifiez qu'une alerte 4662 se déclenche en nommant le compte de test. La réplication normale entre DC pendant la même période ne doit pas déclencher d'alerte. Retirez ensuite à nouveau l'attribution.

Ce que cela casse

• La synchronisation du hachage de mot de passe s'arrête si vous retirez les droits du compte de connecteur Entra Connect. Conservez ces droits et durcissez plutôt le compte.
• Les outils d'audit de mots de passe et d'ITDR qui comparent les hachages à des listes de fuites ont besoin de Get-Changes-All. Le retirer désactive cette fonctionnalité. Décidez en connaissance de cause si le bénéfice justifie un identifiant Tier 0 supplémentaire.
• La préparation Exchange historique peut réajouter WriteDACL si quelqu'un relance un ancien /PrepareAD. Consignez le correctif dans votre procédure d'exploitation Exchange.
• Les scripts de synchronisation personnalisés basés sur les contrôles DirSync ont besoin de Get-Changes. Le retirer les fait échouer avec un accès refusé. Faites-les passer autant que possible à des lectures LDAP ciblées.

Pour aller plus loin : le guide de référence sur les ACL, nettoyage d'AdminSDHolder et de SDProp pour l'autre ACL qui contrôle les objets privilégiés, et rotation du mot de passe krbtgt si une attribution DCSync inexpliquée laisse penser que les hachages ont déjà quitté le bâtiment.