DCSync : qui détient vraiment les droits de réplication de votre domaine ?
Une attaque DCSync ne nécessite ni code sur un contrôleur de domaine ni accès à NTDS.dit : il suffit de deux droits sur la racine du domaine. Les identifiants de tous les comptes, dont krbtgt, sont alors récupérables à distance. Vérifier qui possède ces droits est l'un des contrôles les plus rentables d'un audit AD.
Le principe
Les contrôleurs de domaine se répliquent via le protocole MS-DRSR. Un compte qui dispose des bons droits peut se faire passer pour un contrôleur et demander la réplication des secrets d'un compte, ou de tous. Aucune élévation locale n'est nécessaire : l'opération ressemble à une réplication légitime.
Les droits concernés sont des extended rights positionnés sur l'objet racine du domaine :
| Droit | GUID |
|---|---|
| DS-Replication-Get-Changes | 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 |
| DS-Replication-Get-Changes-All | 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 |
| DS-Replication-Get-Changes-In-Filtered-Set | 89e95b76-444d-4c62-991a-0facbeda640c |
La combinaison des deux premiers donne accès aux données secrètes, donc aux hashs.
Les détenteurs légitimes
Par défaut, on trouve sur la racine du domaine :
- les groupes Domain Controllers et Enterprise Domain Controllers ;
- les groupes Administrators, Domain Admins et Enterprise Admins, directement ou par héritage ;
- Enterprise Read-only Domain Controllers, avec le seul droit « Get-Changes ».
S'y ajoute souvent le compte de synchronisation Microsoft Entra Connect (compte MSOL_ en installation express), qui a besoin de ces droits pour la synchronisation des hashs de mots de passe. C'est légitime, mais ce compte et le serveur qui l'héberge deviennent alors des actifs de niveau 0 et doivent être protégés comme tels.
Trouver les détenteurs inattendus
La revue consiste à lire l'ACL de la racine du domaine et à isoler toute entrée accordant ces GUID à un principal hors de la liste ci-dessus.
$dn = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:$dn"
$acl.Access | Where-Object {
$_.ObjectType -in '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2',
'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
} | Select-Object IdentityReference, ObjectType, AccessControlType
Les trouvailles classiques : un ancien compte de synchronisation d'un outil d'annuaire tiers, un compte de service d'une solution de gestion des identités, un groupe accordé « temporairement » lors d'une migration. Il faut aussi penser aux droits indirects : un principal qui peut modifier l'ACL de la racine (WriteDacl) peut s'accorder DCSync. Certaines installations Exchange anciennes ont historiquement posé ce type de droit ; les mises à jour cumulatives récentes l'ont corrigé, mais l'ACL doit être vérifiée.
À retenir. Tout compte capable de DCSync est équivalent à un administrateur du domaine. Son mot de passe, son poste d'administration et sa supervision doivent suivre les mêmes règles.
Détecter une tentative
Avec la sous-catégorie d'audit Directory Service Access activée et une SACL adaptée sur la racine du domaine, les contrôleurs journalisent l'événement 4662 lorsque ces droits sont exercés. Le champ Properties contient le GUID du droit utilisé. La règle de détection est alors : 4662 avec l'un des GUID de réplication, émis par un compte qui n'est pas un compte ordinateur de contrôleur de domaine ni le compte de synchronisation connu. Les solutions de détection d'identité savent aussi repérer les requêtes de réplication provenant d'une machine qui n'est pas un contrôleur.
Ce qu'un audit vérifie
- La liste exhaustive des principaux disposant des droits de réplication.
- Les principaux capables de modifier l'ACL de la racine du domaine.
- La protection du compte et du serveur de synchronisation Entra Connect.
- La présence de l'audit 4662 et d'une règle d'alerte associée.