Sécurité Active Directory : qu’est-ce que l’attaque DCSync ?

I. Présentation

Dans cet article, nous allons étudier l’attaque DCSync en environnement Active Directory. Nous verrons quel est le principe de cette attaque, quel est son impact sur un domaine Active Directory, ses conditions d’exploitation, mais aussi comment identifier si votre domaine est vulnérable et appliquer un correctif si c’est le cas.

Dans un second article qui fera office de suite, nous nous intéresserons également aux possibilités de détection de l’exploitation de cette attaque via les journaux d’évènements, mais aussi par l’analyse du trafic réseau.

L’attaque DCSync a été mise en lumière en 2015 par deux chercheurs en cybersécurité français (cocorico !), que sont Benjamin Delpy (créateur de Mimikatz) et Vincent Le Toux (créateur de PingCastle). Vous verrez lors de la description de cette attaque qu’on ne peut pas vraiment parler de “découverte” dans le sens d’une CVE, mais c’est l’ajout dans Mimikatz d’une fonctionnalité permettant l’exploitation de DCSync qui a démocratisé cette attaque.

DCSync est une attaque qui possède son propre TTP au sein du framework MITRE ATT&CK (T1003.006 – OS Credential Dumping: DCSync) et est encore aujourd’hui activement exploitée par des acteurs malveillants connus lors de cyberattaques d’envergure :

• Durant la compromission de l’entreprise SolarWinds en 2020, le groupe APT29 affilié à la Russie a utilisé DCSync.
• L’implémentation de DCSync dans Mimikatz a été utilisée en 2021 par le groupe Earth Lusca, affilié à la Chine.

II. L’attaque DCSync

A. Domain Controller Synchronization

DCSync signifie Domain Controller Synchronization. Ce n’est pas une vulnérabilité à proprement parler, mais plutôt une fonctionnalité de l’Active Directory qui permet aux contrôleurs de domaine de se synchroniser entre eux.

Lorsqu’un attaquant exploite DCSync au sein d’un domaine, il simule le comportement d’un contrôleur de domaine souhaitant effectuer une réplication auprès d’un autre contrôleur de domaine en utilisant le protocole MS-DRSR (Directory Replication Service Remote Protocol). Cela lui permet de récupérer l’intégralité des objets de l’Active Directory, incluant les hashs des mots de passe des objets utilisateur.

Par défaut, les membres des groupes « Admins du domaine« , « Administrateurs« , « Administrateurs d’entreprise » et « Contrôleur de domaine » ont les privilèges nécessaires pour légitimement effectuer une synchronisation avec le contrôleur de domaine.

En cela, l’attaque DCSync ne fait pas partie des opérations qu’un attaquant va utiliser en premier lors de son attaque pour compromettre un poste ou un compte utilisateur. Cette attaque apparaît généralement plus tard dans le chemin de compromission et constitue même l’une des dernières étapes. En effet, en récupérant le hash du mot de passe de tous les utilisateurs du domaine, l’attaquant récupère également ceux de tous les utilisateurs privilégiés (membres du groupe « Admins du domaine« ) et peut alors réutiliser ces hashs pour s’authentifier avec l’identité de ces utilisateurs, notamment via une attaque de type « pass the hash » ou en tentant de casser les hashs récupérés.

Cette attaque peut aussi mener à la compromission du compte « krbtgt« , utilisé par le service Kerberos pour la création de tickets, ou encore à la création d’un Golden Ticket, un ticket Kerberos ultra-privilégié permettant à l’attaquant de garder un accès au domaine malgré le changement de mot de passe des comptes utilisateur.

Vous aurez peut-être remarqué que dans la catégorisation du framework MITRE ATT&CK, DCSync est catégorisé dans les tactiques relatives au « Credential Access« . Le but de l’opération est, en effet, de récupérer des identifiants (donc ceux des administrateurs du domaine) via l’exploitation de permissions trop élevées accordées à un objet du domaine que l’attaquant a compromis.

Dans certains cas, DCSync peut être utilisé comme un moyen de persistance par les attaquants. Suite à la compromission du domaine et l’obtention du plus haut niveau de privilège, les attaquants peuvent accorder les permissions nécessaires à un compte utilisateur « lambda », qui ne lèvera pas de soupçons particuliers, afin de pouvoir revenir sur le domaine plus tard avec ce compte.

B. Les permissions DS-Replication-Get-Changes et DS-Replication-Get-Changes-All

Dans le cadre du fonctionnement standard d’un domaine Windows, plusieurs contrôleurs de domaine peuvent cohabiter au sein d’un même domaine (il s’agit même d’une bonne pratique). Ces derniers ont alors besoin de se synchroniser entre eux afin d’avoir les mêmes informations (utilisateurs nouvellement créés, récemment verrouillés, changements de GPO, etc.).

Par exemple, un RODC (Read Only Domain Controller) n’effectuera jamais de modifications sur les objets de l’AD, mais il devra souvent se synchroniser avec les DC principaux afin d’avoir les dernières modifications. De même, un serveur Microsoft Entra Connect (anciennement Azure AD Connect) aura besoin de tels droits pour synchroniser votre instance Entra ID et votre Active Directory local.

Lorsqu’un contrôleur de domaine souhaite obtenir la liste des dernières modifications sur les objets de l’Active Directory auprès d’un autre, il va simplement effectuer une demande de synchronisation, que l’on nomme également dans l’environnement Active Directory « réplication« .

Ce processus est décrit les chapitres suivants de notre cours complet sur les notions de base de l’Active Directory :

Pour pouvoir effectuer une réplication avec le contrôleur de domaine principal, un contrôleur de domaine aura besoin de privilèges spécifiques. Le contrôleur de domaine principal devra vérifier que la demande de synchronisation provient bien d’un objet authentifié de l’Active Directory qui possède les permissions « DS-Replication-Get-Changes » et « DS-Replication-Get-Changes-All« .

Voyons à présent à quoi servent précisément ces permissions :

• DS-Replication-Get-Changes : cette permission permet à un objet ou à un compte de lire les modifications apportées aux objets de l’Active Directory depuis la dernière synchronisation. Cela inclut les modifications sur les attributs des objets tels que les utilisateurs, les groupes, et les ordinateurs. Elle est nécessaire pour les processus de réplication entre les contrôleurs de domaine, garantissant que chaque contrôleur dispose d’une copie à jour de l’annuaire Active Directory.
• DS-Replication-Get-Changes-All : cette permission étend la précédente en permettant également la lecture des modifications apportées aux objets protégés, tels que les mots de passe des utilisateurs et d’autres attributs sensibles. Elle offre un accès plus complet à l’ensemble des données modifiées.

C’est donc grâce à ces permissions que le contrôleur de domaine va autoriser la demande de synchronisation.

Si des permissions et une authentification sont nécessaires, quel est le problème ?

Le problème est que bien souvent, ces deux permissions ne sont pas assignées uniquement aux contrôleurs de domaine et qu’il est fréquent que des objets utilisateurs ou des groupes les possèdent. En cas de compromission de ces comptes, l’attaquant aura la possibilité de se faire passer pour un DC auprès d’un autre DC et de récupérer la totalité des données du domaine.

Dans les faits, l’attaquant va donc énumérer les objets du domaine depuis un compte faiblement privilégié compromis, identifier quels sont les objets qui possèdent les permissions « DS-Replication-Get-Changes » et « DS-Replication-Get-Changes-All« , puis chercher à compromettre ces objets afin de pouvoir profiter de leurs permissions.

Dans d’autres cas, c’est l’attaquant lui-même qui, ayant obtenu un niveau de privilège suffisant (administrateur du domaine), va s’ajouter ces permissions à un compte utilisateur afin de pouvoir facilement récupérer l’intégralité du contenu de la base NTDS.DIT.

Le principal danger autour de DCSync réside donc bien dans le fait que des permissions excessives soient accordées à des objets qui n’en ont pas besoin, et que ces objets finissent par être compromis.

III. Mon domaine est-il vulnérable à DCSync ?

Si vous avez bien suivi, vous avez compris que la réponse est nécessairement oui. Nativement, certains objets ou comptes privilégiés disposent nativement des permissions nécessaires à DCSync. Néanmoins, il faut que ces objets soient aussi peu nombreux et maîtrisés que possible.

A. Qui possède ces permissions sur mon domaine ?

Nous allons à présent voir comment identifier les objets d’un domaine qui possède les permissions « DS-Replication-Get-Changes » et « DS-Replication-Get-Changes-All« .

Au sein de l’interface « Utilisateurs et Ordinateurs Active Directory« , il faut accéder à l’affichage « Fonctionnalités avancées » pour pouvoir afficher l’onglet « Sécurité » dans les propriétés d’un objet :

Il nous faut ensuite effectuer un clic droit sur la racine de notre domaine, puis « Propriétés« , et enfin accéder à l’onglet “Sécurité”. Nous devrons alors parcourir tous les objets affichés et chercher ceux qui ont les permissions « Réplication des changements de répertoire » et « Réplication de toutes les modifications de l’annuaire » :

Dans l’exemple ci-dessus, nous voyons que le groupe « Administrateurs » possède bien ces permissions et ses membres peuvent donc réaliser un DCSync.

C’est également via cet onglet que vous pourrez retirer les permissions de DCSync aux objets qui n’en ont pas besoin, et donc appliquer un correctif efficace pour sécuriser votre Active Directory.

La recherche via l’interface graphique est un peu fastidieuse. Nous pouvons utiliser PowerShell pour avoir une vue plus condensée. Je vous propose pour cela un petit script commenté qui effectue une recherche sur les ACE de l’objet domaine et affiche celles qui concernent les permissions recherchées :

TODO : ACCEDER A LA RESSOURCE + Dépot Github List-DCSyncPermissions.ps1

Voici ce que donne l’exécution de ce script sur mon domaine :

Nous voyons ici que plusieurs objets possèdent les permissions dangereuses relatives à DCSync. La présence des groupes « Administrateurs« , « Contrôleurs de domaine » et « Enterprise Domain Controllers » est normale et attendue. Cependant, deux comptes utilisateur et un groupe possèdent ces permissions, ce qui n’est pas normal du tout. La compromission de ces comptes utilisateur ou d’un membre du groupe « imprimantes » permettra à l’attaquant de réaliser une attaque DCSync.

Dans de tels cas, il est nécessaire d’investiguer sur les raisons qui ont amené les administrateurs à paramétrer de tels droits, de les supprimer s’ils ne sont pas nécessaires et d’investiguer dans les journaux d’évènements afin de voir si une attaque DCSync a été réalisée sur votre domaine.

Pour aller plus loin, sachez également que les utilisateurs privilégiés du domaine peuvent eux-mêmes s’ajouter les droits nécessaires à la réalisation d’une attaque DCSync. En effet, si des utilisateurs possèdent des droits élevés sur l’objet “domaine” en lui-même, alors ils seront habilités à se rajouter les permissions « DS-Replication-Get-Changes » et « DS-Replication-Get-Changes-All« , pour ensuite exploiter l’attaque DCSync.

Il faut comprendre que tous les administrateurs du domaine peuvent réaliser une opération DCSync. Leur compromission entraîne de fait la possibilité pour l’attaquant de récupérer tous les hashs de mot de passe des utilisateurs du domaine et autres données de la base NTDS.DIT.

Il faut donc veiller à ce que les droits au sein de l’AD respectent le principe de moindre privilège, cela en allant au-delà d’une simple vérification des permissions évoquées dans cet article.

B. Détecter DCSync via PingCastle

L’outil PingCastle, créé et maintenu par Vincent Le Toux (racheté récemment par l’éditeur Netwrix), permet assez simplement de récupérer la liste des objets possédant les permissions « DS-Replication-Get-Changes » et « DS-Replication-Get-Changes-All » au sein d’un domaine.

Voici à quoi ressemble la détection des permissions DCSync dans le rapport web de PingCastle (Section « Admin Groups > Delegations > AD Database Access« ) :

Pour en savoir plus sur l’utilisation de PingCastle et l’interprétation de ses résultats pour améliorer la sécurité de votre Active Directory, consultez notre article sur ce sujet :

C. Détecter DCSync via BloodHound

L’outil BloodHound peut également être utilisé afin de lister les objets disposant des permissions « DS-Replication-Get-Changes » et « DS-Replication-Get-Changes-All » sur l’objet « Domain » au sein d’un domaine Active Directory.

Nous pouvons voir que BloodHound remonte plus d’objets que nos analyses via PowerShell et PingCastle. Cela, car il inclut comme pouvant DCSync les objets qui sont directement ou indirectement administrateur du domaine ainsi que ceux possédant d’autres droits sur l’objet racine du domaine. Ces objets peuvent à tout moment s’ajouter les droits de DCSync, et sont donc indirectement en capacité de réaliser cette attaque.

Pour aller plus loin sur la maîtrise de BloodHound afin de rechercher des vulnérabilités au sein de l’Active Directory, je vous oriente vers notre cours complet sur BloodHound :

D. Exploitation de DCSync via Impacket

Nous allons à présent voir comment un attaquant peut exploiter DCSync sur un domaine Active Directory et à quoi ressemble, dans les faits, cette exploitation.

Une fois que l’attaquant a identifié les objets de l’Active Directory qui possèdent les permissions souhaitées, il doit les compromettre. Cette compromission ne fait bien sûr pas partie de l’attaque DCSync en elle-même, mais composera le chemin d’attaque final menant à la compromission du domaine, de la forêt, et de toute l’entreprise. Une fois que l’attaquant a compromis un tel compte, plusieurs outils peuvent être utilisés pour réaliser l’attaque DCSync, la démocratisation de cette attaque a, en effet, mené les développeurs d’outils offensifs à l’intégrer rapidement. Ainsi, voici une liste non exhaustive d’outils offensifs connus intégrant l’exploitation de DCSync :

• Mimikatz (Windows)
• Impacket (Linux)
• Metasploit (Linux)
• Crackmapexec / netexec (Linux)
• Powershell Empire (Windows)

Dans mon exemple, je suppose avoir compromis le compte utilisateur “COLE_MUNOZ”, qui possède les permissions permettant de DCSync. J’utilise alors le script “impacket-secretsdump” provenant de la suite Impacket pour récupérer tous les hashs des mots de passe des objets utilisateur du domaine visé :

# Exploitation de DCSync via impacket
impacket-secretsdump -just-dc IT-CONNECT.TECH/(email protected)

Pour information, Impacket est intégré nativement à la distribution Kali Linux.

Voici le résultat obtenu :

En retour, l’outil récupère les hashs des mots de passe de tous les utilisateurs du domaine, incluant celui de l’administrateur du domaine.

Bien que l’attaque DCSync permette de récupérer la totalité des informations de l’Active Directory, la plupart des outils offensifs ne récupèrent que les informations intéressantes du point de vue de l’attaquant (login et hash des mots de passe).

Si l’on jette un œil aux échanges réseau réalisés durant l’exploitation de DCSync, voici ce que l’on obtient :

On observe dans un premier temps une authentification NTLM classique (challenge/response), suivie d’échanges RCP sur le port TCP/135 :

• Découverte des services via RPC Endpoint Mapper (EPM) : le client (l’attaquant utilisant DCSync) utilise le protocole RPC (Remote Procedure Call) avec DCERPC (Distributed Computing Environment / Remote Procedure Calls) et l’EPM sur le port TCP/135 pour découvrir les services disponibles et notamment le service DRSUAPI.

• Connexion authentifiée au service DRSUAPI : une fois le service identifié, le client y établit une session afin de pouvoir l’utiliser.

• Utilisation du protocole DRSUAPI pour la synchronisation des données : le client souhaitant DCSync utilise le protocole de réplication MS-DRSR (Microsoft Directory Replication Service Remote Protocol) via le service DRSUAPI pour effectuer des requêtes de synchronisation des données. Comme nous pouvons le voir dans le détail des requêtes faites par le client :

IV. Se protéger de l’attaque DCSync

Maintenant que nous en savons plus sur ce qu’est l’attaque DCSync et son impact sur le domaine, nous pouvons évoquer les moyens de se protéger de cette attaque.

Étant donné que cette attaque n’exploite pas un défaut de configuration ou une vulnérabilité qui pourrait être corrigée dans de futures versions de Windows, les remédiations ne sont pas aussi simples et concrètes que pour d’autres faiblesses. Il est important de garder à l’esprit que l’attaque DCSync exploite une fonctionnalité native à tout contrôleur de domaine (la réplication/synchronisation) et qu’en cela, il n’est pas possible de simplement la désactiver.

A. Contrôle des permissions dangereuses de l’Active Directory

Le point le plus important est donc de s’assurer qu’aucune permission dangereuse n’existe au sein de votre domaine (plus facile à dire qu’à faire). Nous avons vu précédemment comment lister les objets de l’Active Directory possédant les permissions dangereuses relatives à DCSync. L’idée est donc de réaliser un contrôle des objets ayant les permissions de DCSync fréquemment.

Ainsi, la réalisation de revues fréquentes, mais également d’audit et tests d’intrusion orientés autour de l’Active Directory permettront de relever les chemins d’attaque existants et les éventuelles permissions dangereuses encore présentes pour ensuite les supprimer. Nous avons notamment vu que certains objets n’ont pas directement les permissions de DCSync mais peuvent se l’ajouter ou l’obtenir facilement en fonction des vulnérabilités et possibilités d’élévation de privilège existantes au sein d’un Active Directory.

Pour aller plus loin, l’implémentation du Tiering Model de Microsoft permet également d’améliorer la robustesse de l’Active Directory et d’éviter l’assignation de permissions excessives aux objets de l’Active Directory. Notez tout de même que le Tiering Model n’est pas une solution directe pour se protéger de DCSync mais plus une recommandation globale sur l’organisation sécurisée d’un Active Directory.

B. Contrôler l’accès à DSRUAPI avec RPCFirewall

La solution open-source RPCFirewall permet d’appliquer des règles de filtrage au service RPC du contrôleur de domaine. Comme pour un pare-feu classique qui permet d’autoriser ou de refuser l’accès à un port en fonction d’une adresse IP source (entre autres), RPCFirewall permet, par l’intermédiaire d’une DLL, d’autoriser ou refuser l’accès à un service RPC en fonction de différents critères, comme l’adresse IP source.

Cela permet de contrôler et de réduire la surface d’attaque des services RPC sur un système Windows, cible de nombreuses vulnérabilités et attaques en raison de leur utilisation importante (PetitPotam, PrintNightmare, ZeroLogon, etc.).

Grâce à RPCFirewall, nous pouvons, par exemple, refuser l’utilisation de DSRUAPI à tout hôte n’étant pas dans notre liste blanche de contrôleurs de domaine, ce qui bloquera de fait toute tentative de DCSync depuis un autre système du réseau.

RPCFirewall peut être techniquement difficile à maîtriser, il faut pour cela bien connaître le fonctionnement des OS Windows, d’un Active Directory et d’un système d’information dans son ensemble.

La configuration suivante permet, par exemple, de n’autoriser l’accès au service RPC DSRUAPI uniquement à l’adresse « 192.168.56.102 » :

# Configuration RPCFirewall pour contrôler l’accès au service DSRUAPI
fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 addr:192.168.56.102 opnum:3 action:allow
fw:uuid:e3514235-4b06-11d1-ab04-00c04fc2dcd2 opnum:3 action:block

Sans aller dans les détails de RPCFirewall, il faut ici utiliser l’UUID correspondant au service RPC que nous souhaitons cibler (liste partielle de mappings des UUID MS-RPC). On commence alors par les directives d’autorisation en spécifiant l’adresse IP des DC autorisés, puis une règle de blocage.

Dès lors, l’attaque DCSync réalisée depuis le poste d’un attaquant sera bloquée, car il n’aura pas accès au service RPC nécessaire :

Il faut également savoir que RPCFirewall peut être utilisé en mode “audit” uniquement. Dès lors, sa fonction sera uniquement la journalisation des appels RPC, incluant les services utilisés et les adresses IP appelantes, parfait pour pouvoir espérer lever des alertes concernant une attaque DCSync :

On retrouve ici (1) l’adresse IP du système ayant effectué la demande de réplication, (2) l’UUID du service RPC requêté et (3) le nom de l’utilisateur authentifié ayant effectué la requête. Cela nous permet donc de voir plus facilement qu’une adresse IP n’étant pas un contrôleur de domaine a effectué une demande de synchronisation auprès du service DSRUAPI. Ces différents éléments pourront alors facilement être utilisés pour lever une alerte au sein d’un SIEM.

Attention toutefois, RPCFirewall n’est pas une solution officielle de Microsoft et l’utiliser sur un contrôleur de domaine peut avoir différents impacts. Il est ainsi recommandé de connaître et de maîtriser cette solution avant implémentation dans un système d’information de production.

C. Surveillance active et détection

En plus de ces différentes solutions, la plus commune et recommandée est de mettre en place des moyens permettant la détection de l’attaque DCSync. Cela doit alors passer par une surveillance en temps réel du système d’information, des échanges réseau et des journaux d’évènements (ainsi que leur bonne configuration).

Ce dernier élément est traité dans la seconde partie de cet article (qui est déjà bien assez long comme cela :D).

V. Conclusion

Nous avons vu dans cet article ce qu’est l’attaque DCSync, son impact sur le domaine et quelques pistes de remédiation pour s’en protéger. La plus importante d’entre elles reste bien sûr le contrôle fréquent des permissions permettant de DCSync, mais aussi plus globalement la surveillance des activités du SI et du domaine.

Pour aller plus loin sur ce sujet et explorer les pistes de détection de l’attaque DCSync sur un domaine, je vous donne rendez-vous dans la deuxième partie de cet article :