DCSync est une attaque de credential dumping qui exploite le protocole légitime de réplication des contrôleurs de domaine Active Directory, le MS-DRSR (Directory Replication Service Remote Protocol), pour extraire à distance les hashes NTLM de n'importe quel compte du domaine, y compris le compte hautement privilégié krbtgt. Référencée sous l'identifiant T1003.006 dans le framework MITRE ATT&CK (catégorie OS Credential Dumping), cette technique a été formalisée et opérationnalisée en 2015 par Benjamin Delpy et Vincent Le Toux via le module lsadump::dcsync de Mimikatz. Sa puissance redoutable provient de trois caractéristiques uniques : elle ne nécessite aucune exécution de code sur le contrôleur de domaine cible, elle s'effectue à distance depuis n'importe quelle machine du domaine via les API RPC standard, et elle abuse une fonctionnalité légitime du protocole de réplication AD plutôt qu'une vulnérabilité corrigeable. Conséquence directe : il n'existe aucun CVE associé à DCSync — c'est un abus de feature documentée par Microsoft. Le pré-requis est la possession des privilèges étendus Replicating Directory Changes et Replicating Directory Changes All, attribués par défaut aux groupes Domain Admins, Enterprise Admins et BUILTIN\Administrators. Cette page entity-first détaille le fonctionnement protocolaire, les outils d'exécution (Mimikatz, Impacket secretsdump, Invoke-DCSync), les stratégies de détection (Event 4662, Defender for Identity, Splunk ES), les contre-mesures de mitigation (audit ACL DRS, rotation krbtgt biannuelle, segmentation Tier 0) et les enchaînements offensifs typiques avec BloodHound et le Golden Ticket. Que vous soyez analyste SOC, pentester certifié OSCP/OSEP, architecte AD ou RSSI, maîtriser DCSync est indispensable pour défendre votre infrastructure Microsoft en 2026.

L'essentiel à retenir sur DCSync

  • Identifiant MITRE : T1003.006 — OS Credential Dumping: DCSync.
  • Protocole abusé : MS-DRSR (Directory Replication Service Remote Protocol), API DRSGetNCChanges.
  • Pré-requis : permissions Replicating Directory Changes + Replicating Directory Changes All sur le naming context du domaine.
  • Comptes éligibles par défaut : Domain Admins, Enterprise Admins, BUILTIN\Administrators, Domain Controllers.
  • Cible privilégiée : compte krbtgt pour forger un Golden Ticket persistant.
  • Outils principaux : Mimikatz (lsadump::dcsync), Impacket secretsdump.py, Invoke-DCSync (PowerShell), DSInternals.
  • CVE : aucun — abus de fonctionnalité légitime, pas de patch possible sans casser la réplication.
  • Détection clé : Event ID 4662 avec GUID 1131f6aa, 1131f6ad et 89e95b76 sur naming context.
  • Mitigation : audit et restriction des ACL DRS, monitoring DRSR depuis hosts non-DC, rotation krbtgt 2x tous les 6 mois.

Définition de DCSync

DCSync est une technique d'attaque post-exploitation sur Active Directory qui permet à un attaquant disposant de privilèges suffisants d'impersonner un contrôleur de domaine légitime et de demander la réplication des secrets d'authentification (hashes NTLM, clés Kerberos, historique de mots de passe) depuis un DC du domaine. L'attaquant n'a besoin d'aucun accès physique ou logique au contrôleur de domaine ciblé : il opère depuis une machine quelconque du réseau, en émettant les appels RPC qu'un DC légitime effectuerait pour synchroniser sa base.

Le terme "DCSync" combine "DC" (Domain Controller) et "Sync" (synchronisation) et reflète exactement le comportement attendu : faire croire à un DC qu'il dialogue avec un autre DC réclamant ses données de réplication. La technique est référencée par MITRE ATT&CK sous le code T1003.006 dans la catégorie OS Credential Dumping, sous-technique de T1003, et figure parmi les attaques les plus utilisées dans les compromissions AD documentées par les CSIRT depuis 2016.

DCSync se distingue des techniques classiques d'extraction de NTDS.dit (copie offline de la base AD, ntdsutil, vssadmin) par son caractère chirurgical : l'attaquant peut viser un compte unique, ou tous les comptes, sans manipulation de fichiers, sans création de Volume Shadow Copy, sans téléchargement de NTDS.dit complet. Cette précision explique pourquoi DCSync reste l'outil de prédilection pour cibler exclusivement krbtgt, étape clé vers le Golden Ticket.

Histoire et contexte d'apparition

L'origine technique de DCSync remonte aux fondations mêmes d'Active Directory introduit avec Windows 2000. Le protocole MS-DRSR documenté publiquement par Microsoft décrit les appels RPC permettant à des contrôleurs de domaine de répliquer leurs partitions (Domain NC, Configuration NC, Schema NC). Pendant quinze ans, ces API ont été considérées comme strictement internes à l'infrastructure DC, sans matérialisation offensive grand public.

En 2015, deux chercheurs français révolutionnent la perception de cette surface d'attaque : Benjamin Delpy (auteur de Mimikatz) et Vincent Le Toux (auteur de PingCastle) co-développent le module lsadump::dcsync intégré à Mimikatz. Leur conférence à BlueHat IL 2015 démontre publiquement comment l'API DRSGetNCChanges peut être invoquée par tout client RPC disposant des bonnes permissions, sans privilèges d'administration locale sur le DC.

Les jalons historiques majeurs incluent :

  • 1999-2000 : Microsoft documente MS-DRSR pour interopérabilité (open specs).
  • 2014 : Sean Metcalf (adsecurity.org) publie ses premières analyses sur les permissions de réplication AD.
  • 2015 : Delpy et Le Toux publient DCSync via Mimikatz, formalisation de l'attaque.
  • 2016 : intégration dans Impacket (secretsdump.py) par Alberto Solino.
  • 2017 : NotPetya et premières campagnes ransomware utilisent DCSync pour extraction krbtgt.
  • 2018 : ajout de la détection DCSync dans Microsoft Advanced Threat Analytics (ATA), précurseur de Defender for Identity.
  • 2019-2020 : BloodHound intègre l'edge "GetChanges" et "GetChangesAll" pour identifier les principals capables de DCSync.
  • 2021-2024 : DCSync devient incontournable dans les rapports DFIR (Mandiant M-Trends, CrowdStrike GTR).
  • 2025-2026 : Microsoft renforce la télémétrie via Defender for Identity v3 et alertes Sentinel natives.

Principe technique : abuser MS-DRSR et DRSGetNCChanges

Le cœur de l'attaque réside dans l'API RPC DRSGetNCChanges exposée par chaque contrôleur de domaine sur le port dynamique RPC associé au service drsuapi. Cette API, légitimement utilisée par les DCs entre eux pour répliquer leurs partitions, accepte des paramètres précisant le naming context cible (DC=corp,DC=local), un filtre d'attributs et un cookie de réplication.

Lorsqu'un client RPC autorisé invoque DRSGetNCChanges en spécifiant le FilterAttributeSet incluant les attributs sensibles (unicodePwd, ntPwdHistory, lmPwdHistory, supplementalCredentials), le DC sollicité retourne les valeurs chiffrées correspondantes. Mimikatz et Impacket implémentent ensuite côté client la logique de déchiffrement des blobs (utilisant la clé de session négociée), de conversion en hashes NTLM lisibles et d'export en format pwdump ou john.

L'élégance offensive de DCSync repose sur trois propriétés combinées :

  • Aucune exécution sur DC : tout se passe via RPC réseau, pas d'agent, pas de service installé.
  • Aucune lecture de fichier : la base NTDS.dit n'est pas touchée, pas de Volume Shadow Copy.
  • Légitimité protocolaire : les paquets sont indistinguables d'une réplication inter-DC standard sauf par l'origine (host non-DC).

Pré-requis : permissions de réplication étendues

DCSync exige trois extended rights sur le naming context (DN du domaine) ciblé, attribués via les ACL de l'objet domain root :

  • Replicating Directory Changes (GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2) : permet la lecture des modifications standard.
  • Replicating Directory Changes All (GUID 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2) : étend la lecture aux attributs sensibles (hashes, clés Kerberos).
  • Replicating Directory Changes In Filtered Set (GUID 89e95b76-444d-4c62-991a-0facbeda640c) : nécessaire pour la réplication filtrée RODC.

Par défaut, ces droits sont accordés aux principals suivants :

  • Domain Admins du domaine ciblé.
  • Enterprise Admins de la forêt.
  • BUILTIN\Administrators.
  • Domain Controllers (groupe machine).
  • Comptes possédant explicitement les droits via délégation manuelle (très fréquent en pratique sur les domaines anciens — terrain favori pour escalade post-Kerberoasting).

L'identification des principals capables de DCSync est l'un des cas d'usage premiers de BloodHound via la requête Cypher recherchant les edges GetChanges + GetChangesAll sur le domaine. Cette analyse fait souvent émerger des comptes de service ou utilisateurs oubliés disposant historiquement de ces privilèges (ex: comptes d'anciens outils de synchronisation, services d'exchange legacy, comptes de monitoring).

Exécution avec Mimikatz

L'implémentation de référence reste celle du module lsadump::dcsync de Mimikatz. Sa syntaxe est concise et se prête à l'automatisation. L'exécution se fait depuis n'importe quelle machine du domaine, sous le contexte d'un utilisateur disposant des permissions DRS.

Commandes typiques :

  • lsadump::dcsync /domain:corp.local /user:krbtgt — extraction du hash NTLM et des clés Kerberos AES de krbtgt (préparation Golden Ticket).
  • lsadump::dcsync /domain:corp.local /user:Administrator — extraction du compte Administrator.
  • lsadump::dcsync /domain:corp.local /all /csv — extraction de tous les comptes en sortie CSV.
  • lsadump::dcsync /domain:corp.local /user:krbtgt /dc:DC01.corp.local — ciblage explicite d'un DC précis (utile si certains DCs ont des télémétries différentes).
  • lsadump::dcsync /domain:corp.local /user:krbtgt /authuser:legituser /authdomain:corp /authpassword:Pwd123! /authntlm — authentification explicite avec credentials autres que le contexte courant.

La sortie inclut le hash NTLM, le hash LM (généralement vide sur AD moderne), l'historique des mots de passe (pwdHistory), les clés Kerberos (AES256, AES128, DES, RC4) et les supplemental credentials (clear-text si stockés via passwordReversibleEncryption). Cette richesse explique pourquoi un seul DCSync sur krbtgt fournit toute la matière nécessaire à un Golden Ticket TGT.

Exécution avec Impacket secretsdump

Impacket secretsdump.py, développé par Alberto Solino et la communauté SecureAuth/Fortra, est l'équivalent Linux/Python de Mimikatz pour DCSync. Il s'agit du standard de facto en pentest depuis Kali ou Parrot et figure dans toutes les distributions offensives modernes.

Commandes signature :

  • secretsdump.py corp.local/legituser:Pwd123!@dc01.corp.local -just-dc-ntlm — extraction de tous les hashes NTLM via DCSync.
  • secretsdump.py corp.local/legituser:Pwd123!@dc01.corp.local -just-dc-user krbtgt — extraction ciblée du compte krbtgt.
  • secretsdump.py -hashes :ntlmhash corp.local/legituser@dc01.corp.local -just-dc — DCSync via Pass-the-Hash.
  • secretsdump.py -k -no-pass corp.local/legituser@dc01.corp.local -just-dc — DCSync via ticket Kerberos déjà présent (KRB5CCNAME).
  • secretsdump.py corp.local/legituser:Pwd123!@dc01.corp.local -just-dc-ntlm -history — inclut l'historique des mots de passe pour analyse de réutilisation.

L'avantage opérationnel d'Impacket est sa portabilité totale : aucun binaire signé requis, exécution depuis Linux, intégration native avec les frameworks CrackMapExec/NetExec, BloodyAD, Certipy. Les pentesters l'utilisent en chaînage direct avec d'autres modules Impacket (psexec, wmiexec, ntlmrelayx).

Exécution PowerShell : Invoke-DCSync et DSInternals

Plusieurs implémentations PowerShell offrent un DCSync natif sans dépendance binaire externe, particulièrement utiles pour passer sous les radars EDR qui surveillent mimikatz.exe.

  • Invoke-DCSync (Nikhil Mittal / Nishang) : module PowerShell qui réimplémente l'attaque via les API .NET DirectoryServices et les structures DRSR. Syntaxe : Invoke-DCSync -DumpForest -Users @("krbtgt","Administrator").
  • DSInternals (Michael Grafnetter) : framework PowerShell complet pour interagir avec AD à bas niveau, inclut Get-ADReplAccount qui utilise DRSR. Standard académique, utilisé aussi par les défenseurs pour audit.
  • ADModule + Get-ADReplAccount : équivalent natif via le RSAT et DSInternals.
  • PowerView (PowerSploit) : ne réalise pas DCSync directement mais cartographie les ACL DRS via Get-DomainObjectAcl.

L'usage PowerShell présente cependant un inconvénient : il déclenche fréquemment AMSI et est journalisé par ScriptBlockLogging (Event 4104). Les pentesters expérimentés combinent obfuscation (Invoke-Obfuscation, Chimera) et bypass AMSI avant exécution.

Cibles privilégiées : krbtgt, Domain Admins, comptes de service

Tous les comptes ne se valent pas pour un attaquant. Le triage des cibles d'un DCSync suit une logique d'impact opérationnel et de persistance.

Le compte krbtgt est la cible numéro un absolue. Son hash NTLM (et ses clés AES Kerberos) signe l'intégralité des TGT du domaine. Le posséder permet de forger un Golden Ticket valide jusqu'à dix ans, accordant une persistance même après réinitialisation des mots de passe utilisateurs ou désactivation des comptes. Un seul DCSync krbtgt = compromission complète et durable du domaine.

Le compte Administrator du domaine (RID 500) et tous les Domain Admins permettent l'authentification interactive et le mouvement latéral sans forge de ticket. Particulièrement utiles si le compte n'a pas été inclus dans Protected Users.

Les comptes de service à haute valeur (services SQL, IIS, SharePoint, Exchange privilégié, comptes de sauvegarde) offrent des accès ciblés sur les applications critiques. Combinés au Kerberoasting, ils peuvent ouvrir des chemins d'escalade alternatifs.

Les comptes ADCS (CA enrollment agents, EFS recovery agents) permettent l'usurpation de certificats. Les comptes machine de DCs autorisent à leur tour des Silver Tickets sur les services CIFS/HOST/LDAP des DCs.

Enfin, l'extraction complète du domaine (option /all) sert à la phase de cracking offline massif via hashcat (mode 1000 NTLM), permettant de retrouver des mots de passe en clair pour des analyses de réutilisation cross-domain.

Chaîne d'attaque : DCSync → Golden Ticket → Pass-the-Hash

DCSync s'inscrit dans une chaîne offensive bien établie qui démultiplie son impact. Le pattern canonique observé dans 80% des compromissions AD documentées suit cette séquence :

  1. Compromission initiale : phishing, exploitation de service exposé, supply chain.
  2. Énumération AD : SharpHound + BloodHound pour cartographier les chemins.
  3. Escalade vers compte avec droits DRS : Kerberoasting, ACL abuse, ADCS ESC1-ESC15, NTLM relay.
  4. DCSync sur krbtgt : extraction du hash via Mimikatz ou secretsdump.
  5. Forge Golden Ticket : kerberos::golden /user:Admin /domain:corp.local /sid:S-1-5-21-... /krbtgt:<hash> /id:500 /ptt.
  6. Persistance : Golden Ticket valide jusqu'à 10 ans, indépendant des changements de mot de passe.
  7. Mouvement latéral : Pass-the-Ticket, Pass-the-Hash, exécution distante sur tous les serveurs.

L'alternative courante remplace le Golden Ticket par un Silver Ticket ciblé (forge à partir du hash machine d'un DC ou d'un serveur applicatif), plus furtif car ne sollicitant pas le KDC mais limité à un service spécifique.

Cette chaîne explique pourquoi la défense AD doit traiter DCSync non comme une attaque isolée mais comme un point pivot dans une séquence : couper l'amont (réduction des principals avec DRS) ou l'aval (rotation krbtgt agressive) reste la priorité.

Détection : Event ID 4662 et signatures réseau

La détection native sous Windows repose principalement sur l'Event ID 4662 du journal Security ("An operation was performed on an object"), généré lorsque l'audit DS Access est activé sur le domaine. La requête de réplication produit cet événement avec une Properties contenant les GUIDs caractéristiques :

  • 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 — Replicating Directory Changes.
  • 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 — Replicating Directory Changes All.
  • 89e95b76-444d-4c62-991a-0facbeda640c — Replicating Directory Changes In Filtered Set.

La règle de détection canonique consiste à journaliser tout Event 4662 incluant ces GUIDs dont le SubjectUserName n'est pas un compte machine de DC (filtrage du suffixe $ sur des hosts non-DC, ou exclusion par allowlist explicite des comptes ordinateurs DC). L'absence de filtre génère un volume ingérable car la réplication inter-DC légitime produit ces événements en continu.

Pré-requis de configuration GPO :

  • Audit Policy > DS Access > Audit Directory Service Access = Success.
  • SACL configurée sur l'objet domain root (dsa.msc > propriétés du domaine > Security > Advanced > Auditing) pour auditer "Everyone" sur "Replicating Directory Changes" et "Replicating Directory Changes All".

Cette détection capture toutes les variantes d'outils (Mimikatz, secretsdump, Invoke-DCSync, DSInternals) car elles aboutissent toutes au même appel RPC.

Détection avancée : Defender for Identity, Sentinel, Splunk ES

Au-delà de la détection brute via Event 4662, plusieurs solutions XDR/SIEM offrent une détection comportementale plus précise et exploitable opérationnellement.

Microsoft Defender for Identity (anciennement Azure ATP) reste la référence native. La règle Suspected DCSync attack (replication of directory services) détecte toute réplication initiée depuis un host non-DC connu, avec corrélation des comptes utilisateurs source. L'intégration avec Microsoft Defender XDR remonte l'alerte dans le Security Operations Center unifié et corrèle avec les événements MDE et Sentinel.

Microsoft Sentinel propose des analytic rules KQL natives ciblant DCSync, exemple :

  • SecurityEvent | where EventID == 4662 | where Properties contains "1131f6ad" | where TargetUserName !endswith "$"

Splunk Enterprise Security fournit des correlation searches dans le Security Content Update (SCU) catégorie endpoint_credential_access, exploitant les sourcetypes WinEventLog:Security et l'add-on Splunk for Microsoft Windows.

QRadar, Elastic Security, Sumo Logic, Exabeam, ArcSight incluent tous des règles équivalentes basées sur l'Event 4662 ou des heuristiques réseau (volumétrie DRSR depuis hôte inhabituel).

Au niveau réseau, des outils comme Zeek (avec scripts dédiés DRSR) ou Suricata (avec règles SID Emerging Threats spécifiques) peuvent détecter les sessions RPC drsuapi initiées depuis IPs non-DC. Les solutions NDR commerciales (Vectra, Darktrace, ExtraHop) automatisent cette analyse.

Mitigation : restreindre les permissions DRS

La défense contre DCSync repose sur une approche en couches, sans pouvoir bloquer la fonctionnalité protocolaire elle-même (sous peine de casser la réplication AD inter-DC).

Réduction du périmètre des principals avec droits DRS : audit régulier (PowerShell Get-ADObject -Filter * -SearchBase "DC=corp,DC=local" -Properties ntsecuritydescriptor) pour identifier toutes les ACE explicites accordant Replicating Directory Changes. Toute délégation hors Domain Admins / Enterprise Admins / Domain Controllers doit être justifiée et documentée. Les comptes hérités d'anciens outils (DirSync, AD Connect mal configuré, comptes de monitoring obsolètes) sont à supprimer.

Modèle Tier 0/1/2 : appliqué strictement, il garantit que les comptes capables de DCSync ne sont jamais utilisés sur des machines non-Tier 0 (postes admin, serveurs applicatifs). Combiné aux Authentication Policies/Silos, il empêche le vol de credentials des admins via Mimikatz sur stations compromises.

Rotation krbtgt biannuelle : le script Microsoft New-KrbtgtKeys.ps1 automatise la double rotation du compte krbtgt. La première rotation invalide les Golden Tickets antérieurs ; la seconde rotation, après propagation de la première sur tous les DCs (réplication AD complète), invalide définitivement les Golden Tickets forgés depuis l'ancien hash. Calendrier recommandé : 2 rotations à 24-48h d'intervalle, tous les 6 mois, et systématiquement après tout incident de sécurité.

Audit DCSync Continous : déploiement de SACL sur le domain root pour générer Event 4662 sur toute opération DRS. Forwarding centralisé vers SIEM avec règle de détection.

Protected Users group : les comptes admin membres ne peuvent pas être Pass-the-Hash, ne mettent pas en cache leurs credentials, et utilisent uniquement Kerberos AES.

LAPS et solutions JIT/JEA : suppression des mots de passe partagés, accès administratif éphémère.

Indicateurs de compromission (IoC) typiques

Lors d'une réponse à incident, plusieurs IoC orientent vers une exécution de DCSync :

  • Event 4662 avec GUID 1131f6aa et 1131f6ad, SubjectUserName ne se terminant pas par $ ou non listé comme DC.
  • Connexions RPC sortantes vers le port dynamique drsuapi depuis hosts non-DC (workstations, serveurs applicatifs).
  • Chargement de DLL sur la machine attaquante : samlib.dll, vaultcli.dll, cryptdll.dll, hid.dll.
  • Process Sysmon Event 1 : exécution de mimikatz.exe, secretsdump.py, rubeus.exe sur poste utilisateur.
  • Volumétrie LSASS : pic d'accès à LSASS sur DC source de réplication.
  • Authentification anormale : compte de service ou utilisateur ordinaire effectuant soudain des opérations RPC vers DCs.
  • Fichiers post-extraction : présence de .ntds, fichiers CSV de hashes, secretsdump.txt, dump krbtgt.kirbi sur disque.
  • Forge ultérieure de TGT : Event 4768 (TGT request) avec ServiceName = krbtgt et durée de vie inhabituelle (10 ans par défaut Mimikatz).
  • Connexions BloodHound : enrichissement préalable via SharpHound (Events 4624 type 3, requêtes LDAP volumineuses).

La corrélation temporelle de ces événements (énumération BloodHound + DCSync + Golden Ticket forgé sous 24-48h) est le pattern canonique des attaques humaines (hands-on-keyboard) documentées dans les rapports Mandiant M-Trends et CrowdStrike Global Threat Report.

Outils alternatifs et écosystème

L'écosystème DCSync s'est considérablement enrichi. Au-delà des trois implémentations canoniques (Mimikatz, Impacket, Invoke-DCSync), de nombreux outils intègrent ou complètent la technique :

  • BloodHound + SharpHound : identification graphique des principals avec edges GetChanges et GetChangesAll. Requête Cypher : MATCH p=shortestPath((n)-[:GetChanges|GetChangesAll*1..]->(d:Domain)) RETURN p. Voir notre guide BloodHound.
  • NetExec (ex-CrackMapExec) : module --ntds dcsync qui automatise via SMB/RPC.
  • BloodyAD : framework Python d'exploitation AD, fonction dcSync intégrée.
  • DSInternals (Michael Grafnetter) : Get-ADReplAccount en PowerShell, usage défensif aussi pour audit des hashes faibles.
  • dcsync.py (impacket-examples) : script standalone minimaliste.
  • SafetyKatz, SharpKatz : portage .NET de Mimikatz incluant DCSync, exécution via Cobalt Strike execute-assembly.
  • nxc (NetExec) avec module ldap et smb : énumération + DCSync chaîné.
  • Kekeo (gentilkiwi, complément Mimikatz) : fonctions Kerberos avancées, complément naturel post-DCSync.
  • pingcastle (Vincent Le Toux) : audit défensif identifiant les principals avec droits DRS.
  • Locksmith, Certify, Certipy : ADCS exploitation, alternative à DCSync via certificats (ESC1-ESC15).

Mapping MITRE ATT&CK et frameworks de référence

DCSync est officiellement référencé dans MITRE ATT&CK sous l'identifiant T1003.006, sous-technique de T1003 (OS Credential Dumping), tactique Credential Access (TA0006). La fiche officielle attack.mitre.org/techniques/T1003/006 documente :

  • Procedure examples : APT29 (Cozy Bear), Earth Lusca, FIN6, Indrik Spider (Evil Corp), Sandworm, Volt Typhoon.
  • Software : Mimikatz (S0002), Impacket (S0357), PsExec, SharpHound (S0521), DCSync (T1003.006 standalone).
  • Mitigations : M1015 (Active Directory Configuration), M1026 (Privileged Account Management), M1027 (Password Policies), M1028 (Operating System Configuration).
  • Detections : DS0026 (Active Directory Object Access), DS0029 (Network Traffic), DS0017 (Command Execution).

Au niveau frameworks complémentaires, DCSync apparaît dans :

  • NIST SP 800-53 Rev.5 : contrôles AC-2 (Account Management), AC-6 (Least Privilege), AU-2 (Audit Events), SI-4 (System Monitoring).
  • CIS Controls v8 : Control 5 (Account Management), Control 6 (Access Control Management), Control 8 (Audit Log Management).
  • ANSSI guide ADM : recommandations spécifiques sur l'audit des permissions de réplication.
  • Microsoft Securing Privileged Access (SPA) : roadmap incluant le tier model anti-DCSync.

CVE associés : pourquoi il n'y en a pas

Une particularité essentielle de DCSync est l'absence totale de CVE associé. La technique n'exploite aucune vulnérabilité au sens MITRE/NVD : elle abuse une fonctionnalité légitime documentée du protocole MS-DRSR. Microsoft ne peut pas "patcher" DCSync sans casser la réplication AD inter-DC, qui est le mécanisme fondamental de cohérence d'un domaine.

Cette caractéristique a plusieurs conséquences stratégiques :

  • Pas de KB Microsoft, pas de mise à jour Windows Update résolvant DCSync.
  • La défense relève entièrement de la configuration et de la posture (ACL, audit, monitoring, segmentation Tier).
  • Toute infrastructure AD est intrinsèquement vulnérable jusqu'à ce que l'audit des permissions DRS soit réalisé et durci.
  • L'évolution de Microsoft consiste à renforcer la détection (Defender for Identity, Sentinel) plutôt que d'éliminer la surface.

Notez que des CVE existent pour des attaques voisines exploitant des bugs réels (Zerologon CVE-2020-1472, PrintNightmare CVE-2021-34527, NoPac/SamAccountName CVE-2021-42278/42287) qui peuvent conduire à un DCSync via élévation, mais DCSync lui-même reste un design choice exploité, pas un bug.

FAQ — Questions fréquentes sur DCSync

Qui peut effectuer un DCSync sur un domaine ?

Tout principal AD disposant des extended rights Replicating Directory Changes et Replicating Directory Changes All sur le naming context du domaine peut exécuter DCSync. Par défaut, ces droits sont accordés aux groupes Domain Admins, Enterprise Admins, BUILTIN\Administrators et au groupe machine Domain Controllers. En pratique, les audits PingCastle et BloodHound révèlent fréquemment des comptes inattendus disposant de ces droits par délégation héritée (anciens outils de synchronisation, comptes Exchange legacy, comptes de service de monitoring). L'identification proactive via la requête Cypher BloodHound MATCH p=()-[:GetChanges|GetChangesAll]->(d:Domain) RETURN p est la première étape d'un audit AD sérieux.

Microsoft Defender for Identity détecte-t-il vraiment DCSync ?

Oui, Defender for Identity (anciennement Azure ATP) inclut depuis 2018 la règle native Suspected DCSync attack (replication of directory services) qui détecte tout appel DRSGetNCChanges initié depuis un host n'étant pas un DC légitime du domaine. La détection est très fiable car MDI dispose de la liste exhaustive des DCs et corrèle avec les autres signaux (énumération LDAP préalable, connexions RPC anormales). En 2026, la solution est intégrée au sein de Microsoft Defender XDR et fournit également des recommandations proactives sur les principals disposant de droits DRS excessifs. Toutefois, MDI nécessite l'installation de capteurs sur les DCs et une licence E5/A5 ou Defender for Identity standalone.

À quelle fréquence faut-il faire tourner krbtgt ?

La recommandation Microsoft et ANSSI est une double rotation tous les 6 mois, avec une seconde rotation 24 à 48 heures après la première (le temps de propagation complète de la réplication sur tous les DCs). Cette périodicité limite la fenêtre d'exploitation d'un Golden Ticket forgé à 6 mois maximum. Après tout incident suspect (compromission DA, DCSync détecté, fuite de credentials d'admin), une double rotation immédiate est impérative. Le script Microsoft New-KrbtgtKeys.ps1 automatise la procédure et inclut les vérifications de réplication. Attention : trop de rotations rapprochées peuvent générer des problèmes Kerberos transitoires sur les comptes machine et services.

Que faire après un DCSync détecté ?

La réponse à incident suite à DCSync confirmé suit un protocole strict : (1) Isolation du host source attaquant (déconnexion réseau, conservation forensique), (2) Identification du compte source via Event 4662 et corrélation, (3) Réinitialisation immédiate du mot de passe de ce compte, (4) Double rotation krbtgt sous 24-48h pour invalider tout Golden Ticket forgé, (5) Réinitialisation des mots de passe de tous les comptes Tier 0 (Domain Admins, Enterprise Admins) et comptes de service critiques, (6) Investigation forensique sur la chaîne de compromission amont (BloodHound, Kerberoasting, ACL abuse), (7) Hunt sur les autres DCs pour traces de persistance (Skeleton Key, AdminSDHolder backdoor, DCShadow), (8) Communication CSIRT/CERT et notification éventuelle ANSSI/CNIL si données personnelles compromises.

Peut-on bloquer DCSync sans casser la réplication AD ?

Non, pas au niveau protocolaire — MS-DRSR doit rester opérationnel pour la réplication inter-DC. La stratégie défensive consiste à restreindre les principals autorisés et à détecter les abus. Concrètement : (1) auditer toutes les ACL accordant Replicating Directory Changes et révoquer toute attribution non justifiée, (2) appliquer le modèle Tier 0 strict pour empêcher l'usage des comptes admin sur stations utilisateurs, (3) déployer Authentication Policies/Silos pour restreindre les machines depuis lesquelles les DA peuvent s'authentifier, (4) activer SACL audit sur le domain root et router Event 4662 vers SIEM, (5) déployer Defender for Identity ou solution NDR avec détection DCSync. Cette approche défense-en-profondeur réduit la surface sans toucher à la fonctionnalité légitime.

DCSync fonctionne-t-il sur Azure AD / Entra ID ?

Non, DCSync est strictement une attaque Active Directory on-premises. Entra ID (Azure AD) ne réplique pas via MS-DRSR mais via des protocoles cloud-native (synchronisation Microsoft Graph). Cependant, dans une architecture hybride (AD Connect, Entra Connect Sync), un DCSync on-premise capturant le compte MSOL_xxx ou un Golden Ticket admin peut compromettre par rebond Entra ID via les délégations de synchronisation. Les attaques équivalentes sur Entra ID portent d'autres noms : Solorigate-style golden SAML, token theft, abus d'application enterprise avec privilèges Directory.ReadWrite.All. La défense passe par la séparation stricte des privilèges hybrides et l'usage de comptes cloud-only pour les Global Admins.

Pour aller plus loin : ressources et articles approfondis

Pour approfondir la maîtrise des attaques Active Directory et la défense contre DCSync, consultez nos guides spécialisés :

Ressources externes officielles :