Qu'est-ce qu'une attaque DCSync : détection et prévention

DCSync est une attaque qui permet à un adversaire de simuler le comportement d'un contrôleur de domaine (DC) et de récupérer les données de mot de passe via la réplication de domaine. L'utilisation classique de DCSync est comme prélude à une attaque Golden Ticket car il peut être utilisé pour récupérer le hash KRBTGT.

Plus précisément, DCSync est une commande dans l'outil open-source Mimikatz. Elle utilise des commandes dans le Directory Replication Service Remote Protocol (MS-DRSR) pour simuler le comportement d'un contrôleur de domaine et demander à d'autres contrôleurs de domaine de répliquer des informations — exploitant des fonctions valides et nécessaires de Active Directory qui ne peuvent être ni désactivées ni désactivées.

Le processus d'attaque

L'attaque DCSYNC fonctionne comme suit :

1. L'attaquant découvre un contrôleur de domaine pour demander une réplication.
2. L'attaquant demande la réplication de l'utilisateur en utilisant la GetNCChanges
3. Le DC renvoie les données de réplication au demandeur, y compris les hachages de mot de passe.

Droits requis

Certains droits très privilégiés sont nécessaires pour exécuter une attaque DCSync. Étant donné qu'il faut généralement un certain temps à un attaquant pour obtenir ces permissions, cette attaque est classée comme une attaque de fin de chaîne d'attaque .

En général, les administrateurs, les administrateurs de domaine et les administrateurs d'entreprise disposent des droits nécessaires pour exécuter une attaque DCSync. Plus précisément, les droits suivants sont requis :

• Réplication des modifications de l'annuaire
• Réplication de tous les changements de Directory

Réplication des modifications de l'ensemble filtré dans Directory Management

Comment les solutions Netwrix peuvent vous aider à détecter et contrecarrer les attaques DCSync

Détection

Netwrix Threat Manager surveille tout le trafic de réplication de domaine pour détecter les signes de DCSync. Il ne dépend pas des journaux d'événements ou de la capture de paquets réseau. Sa méthode de détection principale consiste à trouver des modèles de comportement correspondant à DCSync, y compris l'activité de réplication entre un contrôleur de domaine et une machine qui n'est pas un contrôleur de domaine.

La solution fournit un résumé clair de l'activité suspecte, ainsi qu'une visualisation illustrant quel utilisateur a perpétré l'attaque, le domaine et l'utilisateur ciblé, et des preuves à l'appui de l'attaque. Si le même utilisateur exécute plusieurs attaques DCSync, ces informations critiques seront également incluses.

Réponse

Pour exécuter DCSync, un attaquant a besoin de privilèges élevés, donc la clé pour contrecarrer une attaque est de bloquer immédiatement l'escalade de privilèges. La réponse standard consistant à désactiver le compte utilisateur peut ne pas suffire, car au moment où vous détectez l'attaque en cours, l'attaquant dispose probablement d'une multitude d'autres ressources et options à sa disposition.

Netwrix Threat Prevention fournit des politiques de blocage qui peuvent empêcher un compte ou un poste de travail d'exécuter une réplication supplémentaire, ce qui peut ralentir une attaque et donner plus de temps aux intervenants pour éliminer complètement la menace.

Netwrix Threat Manager prend en charge ces étapes de réponse en fournissant des détails sur l'auteur de l'attaque DCSync, les sources, les cibles et les objets interrogés.

Qu'est-ce qu'une attaque DCSync ?

Les attaquants y accèdent plus souvent via ce type de délégation résiduelle que par un compte administrateur compromis, car les droits de réplication sont attribués aux comptes de service lors des migrations et intégrations, puis jamais révoqués.

Cependant, DCSync lui-même n’a pas de correctif, car il utilise la même interface de réplication que les contrôleurs de domaine utilisent pour rester synchronisés, et le bloquer casserait Active Directory. Le trafic résultant ressemble à une réplication ordinaire pour quiconque consulte rapidement les journaux.

Comment fonctionne une attaque DCSync

Seules 26 % des organisations sont pleinement confiantes que leur Active Directory est exempt de mauvaises configurations permettant l'escalade de privilèges, selon le Netwrix 2026 Data and Identity Security Report. Cette incertitude est bien fondée, car DCSync nécessite une seule autorisation déléguée sur un compte de service oublié pour fournir tous les hachages de mot de passe du domaine.

La séquence se termine en quelques secondes et ne nécessite aucune exécution de code sur le contrôleur de domaine.

1. L'attaquant cible n'importe quel domain controller dans le domaine

Une attaque DCSync est une technique d'intrusion où un adversaire simule un contrôleur de domaine (DC) et récupère des données de mot de passe via la réplication de domaine. Elle précède généralement une attaque Golden Ticket.

3. Le contrôleur de domaine ciblé renvoie les hachages de mot de passe

Aucun accès préalable sur cette machine spécifique n’est nécessaire, car la requête circule sur le réseau comme tout autre trafic de réplication. Tout contrôleur de domaine y répondra.

2. L’attaquant se fait passer pour un contrôleur de domaine pour demander la réplication

DCSync est également le nom d'une commande dans l'outil open-source Mimikatz. La commande utilise le Directory Replication Service Remote Protocol (MS-DRSR) pour usurper l'identité d'un contrôleur de domaine et demander aux contrôleurs réels de répliquer les informations de l'annuaire, abusant de la réplication AD qui fonctionne exactement comme prévu. MITRE la suit sous le nom T1003.006 dans OS Credential Dumping, et il n'y a aucune vulnérabilité sous-jacente à corriger.

L'attaquant appelle IDL_DRSGetNCChanges dans l'interface de réplication MS-DRSR, également connue sous le nom de DRSUAPI, et demande des données de réplication utilisateur en se faisant passer pour un contrôleur de domaine. L'appel est une utilisation légitime de l'API de réplication, ce n'est pas une requête malformée ou inhabituelle, donc cela ne déclenche pas les défenses au niveau du protocole.

Le contrôleur de domaine répond avec des données de réplication, y compris les hachages de mots de passe, car l'interface ne peut pas distinguer un contrôleur de domaine légitime d'un compte disposant des autorisations appropriées.

4. Les outils existants exécutent la demande

Quels droits une attaque DCSync nécessite

Les Administrators, Domain Admins et Enterprise Admins détiennent par défaut les droits nécessaires. Comme ces privilèges prennent du temps à être obtenus, DCSync apparaît généralement tard dans la kill chain. Les permissions spécifiques sont :

• Répliquer les modifications de Directory (DS-Replication-Get-ChangesExpand)

Le module PowerShell DSInternals l'expose via Get-ADReplAccountExpand. L'extraction des données de mot de passe utilisateur avec Mimikatz DCSync couvre toute la séquence de commandes.

Le module lsadump::dcsync de Mimikatz reste la mise en œuvre la plus connue, et d'autres outils effectuent la même requête de réplication. secretsdump.py d'Impacket l'exécute sur le réseau, et le module DSInternals PowerShell l'expose via Get-ADReplAccountExpand.

• Répliquer Directory Changes All (DS-Replication-Get-Changes-AllExpand)
• Réplication des modifications de Directory dans un ensemble filtré (nécessaire uniquement dans certains environnements)

Deux autres permissions ouvrent la même porte et apparaissent rarement lors d’un examen de l’appartenance aux groupes privilégiés. Un compte disposant de GenericAll (contrôle total) ou AllExtendedRights au niveau du domaine peut exécuter DCSync sans appartenir à un groupe privilégié.

Ce que font les attaquants avec les hachages

Tout compte disposant de ces droits délégués dans le contexte de nommage de domaine peut répliquer. Les comptes de service Entra Connect, généralement nommés avec le préfixe MSOL_, détiennent légitimement ces droits, tout comme les comptes qui les ont hérités d'une migration ou d'une intégration oubliée depuis longtemps.

Les droits de réplication qui rendent DCSync possible sont des permissions ; les hashes qu’il retourne ne le sont pas. Un hash est un matériel d’identification, la représentation cryptographique d’un mot de passe, et en posséder un permet à un attaquant d’usurper l’identité de celui à qui il appartient sans jamais connaître le mot de passe réel. Ce que fait l’attaquant ensuite dépend du compte dont il a extrait le hash.

Hash KRBTGT : Forger des tickets pour n’importe quel compte du domaine

Énumérer qui détient les droits aujourd’hui est la vérification d’exposition la moins coûteuse disponible, car la délégation se trouve dans les listes de contrôle d’accès (ACL) qu’un outil d’évaluation d’annuaire lit directement, et analyse des chemins d’attaque montre comment ces droits s’enchaînent.

Les attaquants obtiennent ces droits via privilege escalation, donc tout compte qui les détient nécessite la même privileged account management discipline qu’un Domain Admin, pas un accès permanent jamais réexaminé.

Hachages de comptes réguliers : Déplacez-vous latéralement sans rien craquer

Une exécution de DCSync qui atteint le compte KRBTGT transforme le vol d'identifiants en compromission de domaine. Le hash KRBTGT signe chaque ticket Kerberos dans le domaine. Un attaquant le détenant peut falsifier des Ticket Granting Tickets (TGT) pour n'importe quel compte sans toucher aux identifiants de ce compte, et cet accès falsifié survit à une réinitialisation normale du mot de passe du compte usurpé. Seule une réinitialisation de KRBTGT invalide les tickets falsifiés.

Matériel d’identifiants plus faible : craquer hors ligne un mot de passe en clair

Comment détecter une attaque DCSync

Les hachages NT LAN Manager (NTLM) pour les comptes réguliers et privilégiés alimentent Pass-the-Hash directement. Un attaquant s’authentifie en tant que ce compte en rejouant le hachage lui-même, il n’est donc pas nécessaire de le craquer avant que les identifiants puissent être utilisés ailleurs dans le domaine.

Trois endroits peuvent détecter une requête DCSync, et chacun détecte quelque chose de différent : le journal des événements du contrôleur de domaine, le réseau lui-même, et le comportement de l’identité effectuant la requête.

Les clés Kerberos et l'historique des mots de passe stockés récupérés dans la même réponse de réplication sont cassés hors ligne lorsque le type de hachage est suffisamment faible pour que cela soit pratique. Les mots de passe en clair apparaissent directement uniquement pour les comptes configurés avec un chiffrement réversible, un paramètre qui mérite d'être audité pour cette raison exacte.

Activez l’audit de Directory Service et les alertes sur les GUID de réplication

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 pour DS-Replication-Get-ChangesExpand
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 pour DS-Replication-Get-Changes-AllExpand

Surveillez le trafic pour la réplication depuis un hôte non DC

Comportement d'identité de base pour détecter ce qu'un seul événement ne peut pas

Activez d'abord la Advanced Audit Policy pour Directory Service Access, car Windows la désactive par défaut et l'ID d'événement 4662 ne se déclenchera pas sans elle. Une fois activée, surveillez spécifiquement ces GUID de propriétés de réplication, identifiés par identifiant unique global (GUID) plutôt que par nom convivial :

Alertez lorsque ces GUID apparaissent sur un compte qui n'est ni un contrôleur de domaine ni un compte de service de réplication connu, et filtrez avant d'alerter, car un volume 4662 non filtré sur un contrôleur de domaine occupé génère du bruit que personne ne lit. Traitez ce signal comme un filet de sécurité plutôt que comme le contrôle principal, car un attaquant qui atteint un contrôleur de domaine peut également effacer ou bloquer les journaux sur lesquels dépend une stratégie uniquement 4662.

Comment prévenir les attaques DCSync

Contrôlez les nouveaux droits de réplication lors du provisioning, pas seulement lors de la prochaine revue

Aucun contrôle au niveau du protocole ne bloque DCSync, la prévention repose donc sur le contrôle de qui peut invoquer la réplication et la réduction des chemins menant à ces droits.

Surveillez un bind DRSUAPI transportant IDL_DRSGetNCChanges depuis tout hôte qui n’est pas un contrôleur de domaine, car la réplication légitime s’effectue uniquement entre contrôleurs de domaine et aucune version bénigne de ce trafic n’existe pour filtrer. Priorisez ce signal par rapport à la détection dans les journaux d’événements, car la surveillance réseau capture la requête que le contrôleur de domaine l’ait enregistrée ou non, ce qui maintient le signal disponible même après qu’un attaquant ait altéré la journalisation de l’endpoint.

Alimentez les événements de réplication dans une plateforme d'Identity Threat Detection qui établit une base de référence pour le comportement normal de chaque compte, car un événement 4662 ou une liaison DRSUAPI peut sembler légitime isolément mais anormal par rapport à l'historique spécifique de ce compte. Ce niveau existe pour détecter le schéma d'un compte qui n'a jamais émis de demande de réplication avant de le faire une fois, ce qu'une liste blanche statique ou une règle ponctuelle peut complètement manquer.

Les droits accordés lors d’une migration ou intégration ont tendance à rester bien après la fin du projet, car retirer un accès que personne ne se souvient d’avoir accordé est plus difficile que de l’avoir accordé au départ.

Examinez et supprimez les droits de réplication que personne ne peut justifier

Restreindre la RPC de réplication aux adresses connues des contrôleurs de domaine

Examinez chaque compte disposant des trois autorisations de réplication ainsi que de GenericAll et AllExtendedRights dans le contexte de nommage de domaine, et supprimez ce que personne ne peut justifier. Répétez la revue selon un calendrier, car de nouvelles intégrations réintroduisent ces droits.

Fermez les chemins que les attaquants utilisent pour atteindre les droits de réplication

Lorsque la topologie le permet, autorisez la réplication des appels de procédure distante (RPC) uniquement entre les adresses de contrôleurs de domaine connus. Cela n'empêchera pas un attaquant disposant déjà de droits de réplication valides, mais bloque les requêtes provenant de tout hôte sans raison légitime.

Comment répondre à une attaque DCSync suspectée

Déterminez ce que l'attaquant a réellement interrogé

Enterprise Key Admins est l’exemple récurrent, car adprep /domainprep sur Windows Server 2016 a accordé à ce groupe un contrôle total sur le Domain Naming Context et ses objets enfants. Microsoft l’a qualifié de bug plutôt que de vulnérabilité et l’a corrigé pour les nouvelles préparations de domaine à partir de la mise à jour 1709, mais les domaines préparés avant cette correction nécessitent un script de remédiation séparé ; les mises à jour du schéma à l’échelle du domaine seules ne le résoudront pas.

Supposez que les hachages ont déjà disparu, car les données ont quitté le domaine avant que l’alerte ne se déclenche. Ce que vous faites ensuite détermine combien de temps cet accès continuera à profiter à l’attaquant.

Exiger une justification documentée et un propriétaire nommé avant que toute nouvelle intégration ou migration reçoive DS-Replication-Get-ChangesExpand, DS-Replication-Get-Changes-AllExpand, GenericAllExpand, ou AllExtendedRightsExpand, plutôt que d'accorder d'abord le droit et de le revoir lors du prochain cycle d'audit.

Examinez l’ID d’événement 4662, Directory Service et les journaux Sysmon pour déterminer quels objets l’attaquant a interrogés avant de décider jusqu’où doivent aller la containment et la remédiation. Ce qui en ressort ici détermine si la réponse s’arrête à un compte ou s’étend à une réinitialisation des identifiants à l’échelle du domaine.

Vérifiez que Zerologon (CVE-2020-1472) est corrigé, car les vulnérabilités accordant des privilèges de domaine court-circuitent directement toute la chaîne d'attaque. Considérez les voies de collecte d'identifiants telles que Kerberoasting comme la manière dont les attaquants obtiennent les droits de réplication dès le départ, et non comme un problème distinct à résoudre plus tard. Les deux correctifs font partie des meilleures pratiques de sécurité Active Directory qui maintiennent sous contrôle les autres chemins privilégiés du domaine.

Réinitialisez KRBTGT deux fois s'il figurait parmi les hachages

Contenez la source, pas seulement le compte impliqué

Désactiver le compte impliqué est un réflexe, mais cela ne suffit pas, car l'attaquant détient désormais des identifiants fonctionnant indépendamment de ce compte. Révoquez plutôt les droits de réplication et les appartenances aux groupes privilégiés, puis isolez l'hôte source.

Comment Netwrix vous aide à détecter et bloquer les attaques DCSync

Trouvez tous les comptes disposant des droits de réplication

L’évaluation, la détection et la prévention se font via différents produits ici, qui fonctionnent ensemble.

Si KRBTGT en faisait partie, réinitialisez le mot de passe KRBTGT deux fois, en laissant un intervalle entre les deux réinitialisations plus long que la durée maximale du ticket (10 heures par défaut) et un cycle complet de réplication. Une seule réinitialisation laisse la clé précédente valide, donc les tickets falsifiés continuent de fonctionner. Lorsque les journaux ne peuvent pas établir la portée, optez par défaut pour une réinitialisation des identifiants à l’échelle du domaine plutôt que de deviner.

Détecter une demande de réplication depuis un hôte non DC

Bloquez la demande de réplication avant qu'elle ne soit terminée

Netwrix PingCastle évalue Active Directory selon ses contrôles cartographiés MITRE ATT&CK, y compris les comptes disposant de droits de réplication en dehors des groupes par défaut, transformant ainsi la revue de délégation ci-dessus en un contrôle répétable.

Ses alertes révèlent le compte à l’origine de la demande, le domaine et le compte ciblés, ainsi que les objets interrogés, ce qui est le détail dont un analyste a besoin pour cadrer l’exécution plutôt que de simplement confirmer qu’elle a eu lieu.

La détection DCSync provient d’une politique de Netwrix Threat Prevention AD Replication Monitoring, les deux produits fonctionnant donc en paire.

Netwrix Threat Manager détecte les techniques de vol d'identifiants contre Active Directory, y compris une demande de réplication émise par une machine qui n'est pas un contrôleur de domaine, et envoie une alerte.

Netwrix Threat Prevention applique des politiques de blocage qui empêchent un compte ou un poste de travail spécifique d’exécuter une réplication supplémentaire. Les deux s’inscrivent dans identity threat detection and response, avec Threat Manager étendant la détection à Entra ID et Threat Prevention appliquant les règles au niveau d’Active Directory sur site.

Par où commencer avec l'exposition DCSync

[EMPLACEMENT IMAGE : Produit, demande au PMM. Besoin d’une capture d’écran du produit Netwrix Threat Manager (toute vue actuelle montrant un événement DCSync détecté avec hôte source, compte ciblé et objets interrogés)]

Les droits de réplication portent la majeure partie de la défense ici, et une liste de délégation que personne n'a revue depuis la dernière migration est la voie d'attaque réaliste. L'énumérer prend un après-midi.

Demandez une démo pour voir comment Netwrix détecte les droits de réplication, identifie une tentative DCSync en direct et bloque la suivante dans votre propre environnement Active Directory.

L’alerte sur la réplication depuis des hôtes qui ne sont pas des contrôleurs de domaine détecte la tentative elle-même, et ce signal reste valable que l’audit de Directory Service ait été activé ou non. Une procédure documentée de réinitialisation KRBTGT décide ensuite combien de temps une exécution réussie continue à profiter à l’attaquant.