Ariovis

Chemin d'attaque Active Directory · MITRE ATT&CK T1003.006

DCSync : quand un compte peut demander à Active Directory de lui livrer ses secrets

DCSync ne consiste pas à voler le fichier NTDS.dit ni à ouvrir une session interactive sur un contrôleur de domaine. L'attaque détourne une fonction parfaitement légitime d'Active Directory : la réplication.

Lorsqu'un compte dispose des droits nécessaires, il peut demander à un contrôleur de domaine de lui transmettre des données normalement destinées à un autre contrôleur de domaine. Le problème n'est donc pas seulement « qui est administrateur ? ».

La vraie question

Qui possède, directement ou indirectement, le droit de répliquer les secrets du domaine ?

Comprendre vos chemins d'attaque Active Directory
MITRE ATT&CK
T1003.006 — OS Credential Dumping: DCSync
Tactique
Credential Access
Protocole détourné
MS-DRSR / DRSUAPI (RPC)
Droits clés
Replicating Directory Changes + Replicating Directory Changes All
Cible possible
Comptes du domaine, comptes privilégiés, krbtgt
Niveau
Tier 0 / critique
Signal Windows
Event ID 4662 — sous réserve d'audit configuré
Position dans le chemin
Post-compromission, après obtention de droits puissants

Le chemin d'attaque, étape par étape

DCSync arrive tard dans un chemin d'attaque. Il suppose qu'une identité ait déjà obtenu, ou hérité, de droits de réplication sur le domaine. Rien dans cette séquence n'est automatique : chaque flèche dépend de ce que l'environnement autorise réellement.

  1. 01

    Identité compromise

  2. 02

    Droits de réplication obtenus

    • Replicating Directory Changes
    • + Replicating Directory Changes All
  3. 03

    Requête de réplication vers un contrôleur de domaine

    • MS-DRSR / DRSUAPI / RPC
  4. 04

    Active Directory transmet les données autorisées à la réplication

  5. 05

    Extraction de matériel d'authentification

    • Hashes de comptes du domaine
    • Comptes privilégiés
    • Potentiellement krbtgt
  6. 06

    Impact

    • Usurpation de comptes
    • Mouvement vers le Tier 0
    • Persistance

Si le secret krbtgt est récupéré

Possibilité de Golden Ticket : forger des TGT Kerberos valides pour le domaine

Le problème DCSync n'est pas qu'un outil offensif sache parler au contrôleur de domaine. Le problème est qu'une identité possède le droit de lui demander ses secrets.

Pas besoin de « pirater » le contrôleur de domaine

C'est ce qui rend DCSync particulièrement intéressant à comprendre.

La réplication est indispensable au fonctionnement normal d'Active Directory. Les contrôleurs de domaine utilisent le Directory Replication Service Remote Protocol, ou MS-DRSR, pour maintenir les données du domaine cohérentes.

DCSync détourne cette logique. L'attaquant ne demande pas au contrôleur de domaine d'exécuter un malware. Il se présente comme un principal disposant d'un droit de réplication et demande des données via le protocole prévu pour cela.

Un contrôle de sécurité centré uniquement sur les processus exécutés sur les DC risque donc de passer à côté d'une partie du problème.

À retenir

DCSync est d'abord un problème d'autorisation dans Active Directory avant d'être un problème d'outil offensif.

Le vrai actif critique : les droits de réplication

Deux droits étendus, positionnés sur la tête du domaine, déterminent qui peut demander quoi à un contrôleur de domaine.

DroitRôlePourquoi il est sensible
DS-Replication-Get-ChangesReplicating Directory Changes1131f6aa-9c07-11d1-f79f-00c04fc2dcd2Permet de demander les modifications d'un Naming Context Active Directory.Seul, il ne livre pas les secrets. Il constitue la première moitié du chemin.
DS-Replication-Get-Changes-AllReplicating Directory Changes All1131f6ad-9c07-11d1-f79f-00c04fc2dcd2Étend la réplication aux données secrètes du domaine.C'est lui qui autorise la transmission du matériel d'authentification.

Pour représenter le chemin DCSync classique, il ne suffit pas de dire qu'un seul droit « Replicating Directory Changes » suffit. La combinaison GetChanges + GetChangesAll constitue le cas essentiel à surveiller.

Active Directory possède également le droit DS-Replication-Get-Changes-In-Filtered-Set. Il existe pour certains attributs appartenant au filtered attribute set. Il ne doit pas être présenté comme une troisième permission systématiquement nécessaire à tout DCSync.

On peut disposer du pouvoir sans porter l'étiquette « Domain Admin »

Les groupes d'administration très privilégiés disposent naturellement de capacités permettant d'effectuer des opérations de réplication. Mais Active Directory permet également de déléguer ces droits.

C'est précisément là que la gouvernance devient difficile. Un compte de service, un groupe historique, une délégation ancienne ou une chaîne d'appartenances peut aboutir à un principal capable de demander des secrets du domaine sans apparaître immédiatement comme « administrateur de domaine ».

C'est pourquoi une revue des seuls groupes Domain Admins ou Enterprise Admins ne suffit pas. Il faut analyser les ACL du domaine et les chemins qui permettent d'obtenir ces permissions.

Tous les détenteurs de droits de réplication ne sont pas des attaquants

Ne pas considérer tout compte non-DC possédant ces droits comme malveillant. Certains services légitimes de synchronisation d'identité peuvent disposer de droits de réplication.

Exemple : Microsoft Entra Connect peut nécessiter Replicating Directory Changes et Replicating Directory Changes All pour la Password Hash Synchronization.

La bonne démarche consiste donc à identifier, documenter et réduire les exceptions légitimes, pas à supprimer aveuglément tous les droits.

Mimikatz, Impacket : ils n'inventent pas la faille

Les outils offensifs rendent DCSync accessible. Ils n'en créent pas la condition. Aucune procédure d'exécution n'est décrite ici : seule la compréhension de ce qu'ils exploitent compte pour la défense.

Mimikatz

  • sait utiliser les mécanismes DCSync pour demander les données d'un compte ;
  • s'appuie sur les droits déjà détenus par le contexte utilisé ;
  • ne crée pas magiquement les droits de réplication.

Impacket

  • propose également des capacités permettant d'interagir à distance avec les mécanismes de réplication Active Directory ;
  • illustre qu'il n'est pas nécessaire d'avoir une session interactive ouverte sur le contrôleur de domaine.

BloodHound

  • peut représenter le chemin DCSync lorsqu'un principal dispose des permissions requises ;
  • permet surtout de comprendre comment une identité initialement moins privilégiée finit par atteindre cette capacité.
Le risque n'est pas Mimikatz. Le risque est qu'une identité puisse légitimement demander quelque chose qu'elle ne devrait plus pouvoir demander.

DCSync sur krbtgt : le scénario qui fait basculer le domaine

DCSync peut cibler différents comptes. Lorsque le secret récupéré appartient à un compte utilisateur ou administrateur, il peut notamment permettre d'usurper ce compte selon les mécanismes disponibles.

Le cas krbtgt est différent. Le compte krbtgt porte les clés utilisées par Kerberos pour protéger les Ticket Granting Tickets du domaine. La récupération de son secret peut permettre à un attaquant de fabriquer des tickets Kerberos — le principe du Golden Ticket.

Ce n'est donc pas DCSync seul qui crée le Golden Ticket. La chaîne exacte est la suivante :

  1. 01Droits de réplication
  2. 02DCSync
  3. 03Récupération du secret krbtgt
  4. 04Possibilité de forger des TGT
  5. 05Golden Ticket
Un DCSync sur un compte ordinaire reste grave. Un DCSync sur krbtgt change l'échelle : il compromet la confiance Kerberos de l'ensemble du domaine.

Détecter une réplication légitime utilisée dans un contexte illégitime

Le défi de DCSync est le même que celui de beaucoup d'attaques basées sur l'identité : le protocole utilisé est légitime. La détection doit donc croiser l'identité, la machine source et le comportement observé.

01

Event ID 4662

Une opération a été effectuée sur un objet Active Directory

L'Event ID 4662 n'est pas une alerte DCSync magique. Sa disponibilité dépend notamment de la configuration de l'audit Directory Service Access et des SACL correspondantes. On doit ensuite rechercher les opérations relatives aux droits de réplication et les contextualiser.

02

Source de la réplication

Une réplication provenant d'un contrôleur de domaine connu est normale. Une requête DRSUAPI provenant d'une machine utilisateur, d'un serveur d'administration inattendu ou d'un endpoint non-DC mérite une qualification immédiate.

03

Identité utilisée

Comparer le principal aux comptes autorisés à effectuer des réplications. Détecter notamment :

  • compte utilisateur inattendu ;
  • compte de service inhabituel ;
  • utilisation nouvelle d'un compte habituellement légitime ;
  • changement récent de délégation.
04

Corrélation SIEM

Corréler identité + SourceIP / hostname + DRSUAPI + droits de réplication + contexte temporel.

  • Éviter les règles trop naïves qui considèrent toute réplication comme une attaque.
Détecter DCSync, c'est reconnaître une opération normale effectuée par la mauvaise identité, depuis la mauvaise machine, au mauvais moment.

Supprimer le chemin plutôt que bloquer l'outil

Bloquer une signature d'outil ne retire pas le droit qui rend DCSync possible. La remédiation porte sur les permissions et sur les chemins qui permettent de les atteindre.

  1. 01

    Inventorier

    Identifier tous les utilisateurs, groupes, comptes techniques et services disposant directement ou indirectement de droits de réplication sur le domaine.

  2. 02

    Justifier

    Pour chaque principal :

    • pourquoi possède-t-il ce droit ?
    • quel service l'utilise ?
    • est-il encore nécessaire ?
    • qui en est propriétaire ?
  3. 03

    Réduire

    Supprimer les délégations obsolètes. Réduire les groupes intermédiaires. Isoler et gouverner les comptes de synchronisation légitimes. Éviter d'accorder ces droits à des identités humaines lorsqu'ils ne sont pas nécessaires.

  4. 04

    Surveiller

    Mettre sous surveillance :

    • l'utilisation des droits de réplication ;
    • les changements d'ACL associés ;
    • les nouvelles délégations ;
    • les requêtes depuis des sources inhabituelles.
  5. 05

    Revalider

    Après remédiation, recalculer les chemins d'attaque. Une correction est réellement utile lorsqu'elle supprime le chemin qui permettait d'atteindre la capacité DCSync.

Cette démarche s'inscrit dans une mise sous contrôle plus large du Tier 0. Pour une trajectoire séquencée du constat aux premières remédiations : NIS2 : sécuriser son Active Directory en 90 jours

Une remédiation d'ACL ne suffit plus après compromission

Si une attaque DCSync est confirmée, il faut considérer les secrets récupérés comme potentiellement compromis. La réponse dépend donc des comptes concernés.

Révoquer uniquement le droit de réplication ferme le chemin futur, mais n'annule pas les secrets déjà récupérés.

  • analyser le périmètre réellement demandé ;
  • réinitialiser ou renouveler les secrets exposés ;
  • rechercher l'utilisation ultérieure de ces identifiants ;
  • vérifier les mécanismes de persistance.

Si le secret de krbtgt a pu être compromis

La rotation du compte krbtgt doit suivre la procédure officielle Microsoft. Microsoft documente une réinitialisation en deux temps, avec un délai adapté à la durée de vie des tickets Kerberos. Ce n'est pas une opération banale à lancer immédiatement sans préparation : elle se planifie, se séquence et se vérifie.

Notre conviction : un droit de réplication est un actif Tier 0

DCSync montre parfaitement pourquoi une analyse Active Directory ne peut pas s'arrêter aux vulnérabilités techniques ou aux membres du groupe Domain Admins. Ce sont les relations qui comptent.

  • Une délégation.
  • Un groupe imbriqué.
  • Un compte de synchronisation.
  • Une ACL historique.

Pris isolément, chacun de ces éléments peut sembler acceptable. Mis bout à bout, ils peuvent donner à une identité la capacité d'extraire les secrets du domaine.

Ariovis analyse donc

  • les comptes sensibles ;
  • les groupes ;
  • les délégations ;
  • les ACL ;
  • les droits de réplication ;
  • les chemins permettant de les obtenir ;
  • les remédiations qui suppriment réellement ces chemins.
Évaluer la sécurité de mon Active DirectoryDécouvrir l'offre Sécurité des identités et Active Directory

Un audit reconstitue les chemins. Un pentest contrôlé peut vérifier lesquels sont réellement exploitables. Pentest identités et accès

Techniques liées

Trois techniques de la même collection. Elles ne constituent pas trois étapes obligatoirement successives : chacune s'insère dans un chemin d'attaque selon ce que l'environnement autorise.

Sources techniques

Références de premier rang utilisées pour étayer cette fiche.

Aller plus loin

Les contenus Ariovis qui prolongent directement ce sujet.