Sécurité Active Directory : Comment détecter l’exploitation de DCSync au sein d’un domaine ?

I. Présentation

Dans cet article, nous allons nous intéresser aux possibilités de détection de l’exploitation de DCSync au sein d’un domaine Active Directory. Nous utiliserons pour cela les journaux d’évènements qui permettent de tracer et historiser l’activité des systèmes d’exploitation Windows et de l’Active Directory. De plus, nous effectuerons également l’analyse du trafic réseau qui permet d’identifier une attaque par DCSync avec plus de certitude.

Cet article est la seconde partie de l’article sur l’attaque DCSync et traite des possibilités de détection de cette attaque. Je vous invite au préalable à consulter la première partie qui expose ce qu’est l’attaque DCSync, son impact sur le domaine et évoque quelques moyens de remédiations :

II. Détecter l’exploitation de DCSync via les journaux

A. Les évènements générés par une attaque DCSync

Il existe quelques stratégies d’audit et évènement relatifs aux tâches de réplication entre contrôleurs de domaine. Néanmoins, leur contenu et apparition ne sont pas suffisants pour affirmer qu’une attaque DCSync est en cours. Pour la plupart, ils ne contiennent aucune information sur l’objet source de la demande de réplication (voir Audit Directory Service Replication et Audit Detailed Directory Service Replication).

En conséquence, et contrairement à ce que l’on pourrait espérer, il n’y a pas d’évènement propre à la tâche de réplication du type « Event XXXX: l’IP X.X.X. a demandé une réplication« . Auquel cas, il serait relativement simple de surveiller cet évènement et de lever l’alerte dès qu’une adresse IP n’étant pas l’un de nos DC demande une réplication.

Pour commencer à avoir des signaux intéressants concernant une potentielle attaque DCSync, nous devons dans un premier temps activer une stratégie d’audit spécifique au niveau des contrôleurs de domaine. Il faut alors se rendre dans la GPO qui s’applique aux contrôleurs de domaine (il est déconseillé de modifier celle par défaut « Default Domain Controllers Policy« , préférez en créer une dédiée). Il faut ensuite se rendre dans « Configurateur ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Configuration avancée de la stratégie d’audit > Stratégie d’audit > Accès DS » et enfin sélectionner « Auditer l’accès au service d’annuaire » :

Il faut au moins activer « Succès » pour cette stratégie d’audit, les échecs n’étant pas nécessaires pour notre besoin. Grâce à cette stratégie d’audit, l’Active Directory pourra générer les événements 4662 chaque fois qu’un objet demande l’accès à un autre objet avec des permissions spécifiques, ce qui est le cas lors d’une opération de réplication (DCSync) :

Le problème majeur de ces évènements est qu’ils sont relativement vides en termes de données et ne contiennent aucune information sur l’ordinateur ou l’adresse IP ayant effectué la demande (c’est-à-dire la source).

Cependant, nous pouvons noter que l’objet qui a effectué la demande est journalisé, car la demande doit être faite en étant authentifié sur le domaine (ici, l’utilisateur « IT-CONNECT\COLE_MUNOZ« ). Il peut donc être intéressant de se baser sur cette information pour voir si des objets autres que nos contrôleurs de domaine ont fait de telles demandes d’accès.

Également, l’attribut « Propriétés » peut être utilisé, car il contient les GUID des permissions utilisées dans le cadre de la demande accès : « 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 » pour « DS-Replication-Get-Changes » et « 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 » pour « DS-Replication-Get-Changes-All« .

Attention toutefois, les deux évènements en question étant très génériques, ils sont susceptibles d’être générés à de très nombreuses reprises, au point que leur activation est parfois déconseillée, car entrainant la création d’un trop gros volume d’évènements. Soyez donc bien sûr d’avoir fait les tests nécessaires avant utilisation.

B. Visualisation d’une attaque DCSync dans un SIEM ELK

Maintenant que nous avons paramétré la bonne stratégie d’audit et que nous savons quels évènements regarder lorsqu’une attaque DCSync apparaît, nous pouvons aller plus loin en utilisant un SIEM (ELK dans mon exemple). Pour vous donner une idée de ce qui peut apparaître sur un SIEM ELK lors d’un DCSync, voici le résultat d’une telle opération sur mon environnement de lab :

Il faut ici signaler que l’activité normale d’un domaine entraîne de fait la génération des évènements surveillés (4662). Il est donc nécessaire de vérifier via des tests concrets si la réalisation d’une attaque par DCSync entraîne bien un pic d’activité dans votre environnement ou si cela passe relativement inaperçu.

Nous pouvons également utiliser le contenu de l’attribut « Propriétés » (contenant le GUID du droit d’accès « DS-Replication-Get-Changes » et « DS-Replication-Get-Changes-All« ) pour être plus précis dans notre surveillance d’un tel évènement :

# Requête KQL filtrant les évènements 4662 avec les permissions DS-Replication-Get-Changes et DS-Replication-Get-Changes-All
winlog.event_id: 4662 AND winlog.event_data.Properties: (*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* OR *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*)

Une fois que nous avons isolé ces évènements, nous pouvons utiliser ELK pour nous montrer le top des objets demandeurs (en utilisant l’attribut « Id de sécurité » de l’évènement 4662) :

Dans mon exemple, un seul utilisateur a généré ce type d’évènements. Mais, dans un domaine d’entreprise, il est probable que la liste des contrôleurs de domaine secondaires apparaisse, ainsi que potentiellement d’autres comptes utilisateur, ce qui nécessitera probablement une vérification des permissions.

Il est également possible au niveau des filtres de nos recherches d’exclure les objets machines (ou directement le nom des contrôleurs de domaine). Un autre compte qui sera probablement présent est le compte commençant par « MSOL_« , utilisé par Azure AD Connect pour la réplication de l’Active Directory vers Entra ID, par exemple :

# Requête KQL filtrant les évènements 4662 avec les permissions DS-Replication-Get-Changes et DS-Replication-Get-Changes-All et excluant certains objets légitimes
winlog.event_id: 4662 AND winlog.event_data.Properties: (*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2* OR *1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*) AND (not winlog.event_data.SubjectUserName: $* and not winlog.event_data.SubjectUserName: MSOL*)

Enfin, et parce qu’il faut être conscient des limites de nos systèmes et procédures de détection : l’attaque DCSync peut être utilisée à destination d’un seul objet de l’Active Directory. L’attaquant n’est pas obligé de répliquer la totalité de l’Active Directory. Par exemple :

# Exploitation de DCSYnc via impacket en ne ciblant qu'un compte utilisateur
$ impacket-secretsdump -just-dc IT-Connect.lab/(email protected) -just-dc-user Administrateur
Impacket v0.12.0.dev1 - Copyright 2023 Fortra

Password:
(*) Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
(*) Using the DRSUAPI method to get NTDS.DIT secrets
Administrateur:500:aad3b435b51404eeaad3b435b51404ee:e20e81c5c06ccf288474c581f13423b9:::
(*) Kerberos keys grabbed
Administrateur:aes256-cts-hmac-sha1-96:d839df1355986c26a8928034f292877865c6387f340fbc5fa760f182c9253442
Administrateur:aes128-cts-hmac-sha1-96:90cd2a98e13168174788c30227bedc8b
Administrateur:des-cbc-md5:97803ed67cc7ad25
(*) Cleaning up...

Auquel cas, seuls quelques évènements 4662 seront journalisés :

La détection par volume d’évènements ou “top objet” comme nous venons de le faire n’est donc plus la bonne approche dans ces cas-là.

III. Détecter l’ajout des permissions DCSync via les journaux

En plus de faire en sorte de pouvoir détecter l’exploitation de DCSync, nous pouvons également surveiller toute modification des permissions d’un objet qui viserait à rajouter les permissions dangereuses identifiées permettant de DCSync.

Encore une fois, il est nécessaire de modifier la stratégie d’audit par défaut de nos contrôleurs de domaine pour pouvoir espérer voir cet évènement dans nos journaux de sécurité, car la stratégie d’audit par défaut ne le journalise pas.

Toujours dans la GPO ciblant les contrôleurs de domaine, il faut se rendre dans « Configuration de l’ordinateur > Paramètres Windows > Paramètres de sécurité > Configuration avancée de la stratégie d’audit > Stratégie d’audit » :

Il faut ensuite sélectionner « Auditer les modifications du service d’annuaire » et cocher au minimum « Succès« , les échecs ne nous intéressent pas dans notre cas précis. Suite à l’application de cette GPO et l’ajout d’une ACE à un utilisateur pour lui permettre de DCSync, voici ce que nous pouvons voir dans les journaux de sécurité :

L’évènement 5136 est présent et nous indique une modification sur un objet de l’Active Directory. Au sein de cet évènement, trois éléments sont à regarder :

1. L’utilisateur ayant effectué la modification, ici le compte « Administrateur« .
2. L’objet cible de la modification. Ici, on retrouve le DN du domaine lui-même (« DC=it-connect, DC=tech« ), car c’est sur cet objet qui est la cible de l’ACL permettant à un autre objet de DCSync.
3. Le champ “attribut”, qui contient une sorte de grand blob de données à première vue difficilement interprétable.

Ce champ attribut est en fait l’ACL en elle-même. Si l’on regarde attentivement, on retrouve d’ailleurs les GUID des deux permissions relatives à DCSync, ainsi que le SID des objets auxquels cette permission s’applique :

Nous avons donc dans ces évènements la liste précise des objets du domaine pouvant DCSync. Cela est déjà bon à savoir, car dans le cadre d’une investigation numérique basée sur les journaux d’évènements, c’est une information qui nous permettra de voir si une modification de l’ACL a été réalisée en vue d’opérer une attaque DCSync.

Un filtre intéressant que nous pourrions mettre en place sur un SIEM est de compter le nombre de fois où ces GUID apparaissent afin d’avoir une évolution dans le temps du nombre d’ACE ciblant les permissions permettant de DCSync. Toute modification de ce total signifiera qu’un nouvel objet a obtenu les permissions de DCSync. Il faudra donc positionner une alerte sur cette modification.

Je ne suis pas parvenu à effectuer un compte du nombre d’apparitions d’un terme dans l’attribut d’un évènement via ELK. Si vous êtes parvenus, n’hésitez pas à partager votre solution dans les commentaires ! :-).

En fonction de l’activité de votre Active Directory, il peut facilement être mis en place une surveillance des modifications de l’ACL de l’objet racine du domaine. En théorie, cet objet devrait subir des modifications assez rarement :

# Requête KQL ciblant les modifications de l’objet racine du domaine
event.code:5136 AND winlog.event_data.ObjectDN: "DC=it-connect,DC=tech"

Dans les faits, différents évènements pourront entraîner la modification de cette valeur (ajout d’un compte légitime pour la réalisation de cette opération, par exemple), mais cela reste un évènement relatif à une opération sensible, qu’il est nécessaire de surveiller activement.

IV. Détection de l’attaque DCSync via l’analyse réseau

Dans le cas où vous disposez au sein de votre infrastructure d’un NIDS (Network Intrusion Detection System), celui-ci peut être utilisé pour la détection d’une attaque DCSync.

Un NIDS est un composant de l’architecture réseau conçu pour capter et analyser le trafic réseau en temps réel. Son objectif est de détecter des comportements ou patterns d’attaque en comparant le trafic observé à une base de signatures connues. Cela peut être une adresse IP effectuant un scan réseau, utilisant un outil d’attaque offensif ou encore, opérant une attaque par DCSync sans avoir l’adresse IP d’un contrôleur de domaine.

L’idée au niveau de la détection d’une attaque DCSync par analyse réseau est d’avoir une règle de détection qui s’activera dès qu’un ensemble de paquets signature d’une opération DCSync sera détecté, et que ceux-ci ne proviendront pas d’un contrôleur de domaine. La liste des contrôleurs de domaine de notre domaine sera donc une sorte de white list.

Dans l’article précédent, nous avons regardé un extrait de capture réseau réalisée durant une attaque DCSync, l’utilisation de différents protocoles RPC est notamment une signature de l’utilisation de DCSync. Par exemple pour le NIDS Suricata, nous pouvons utiliser les règles suivantes, issue des travaux de Didier Stevens :

alert tcp !$DC_SERVERS any -> $DC_SERVERS any (msg:"Mimikatz DRSUAPI"; flow:established,to_server; content:"|05 00 0b|"; depth:3; content:"|35 42 51 e3 06 4b d1 11 ab 04 00 c0 4f c2 dc d2|"; depth:100; flowbits:set,drsuapi; flowbits:noalert; reference:url,blog.didierstevens.com; classtype:policy-violation; sid:1000001; rev:1;)

alert tcp !$DC_SERVERS any -> $DC_SERVERS any (msg: »Mimikatz DRSUAPI DsGetNCChanges Request »; flow:established,to_server; flowbits:isset,drsuapi; content: »|05 00 00| »; depth:3; content: »|03 00| »; offset:22; depth:2; reference:url,blog.didierstevens.com; classtype:policy-violation; sid:1000002; rev:1;)

Ces deux règles permettent de surveiller des signaux caractéristiques d’une synchronisation vers un domaine contrôleur. La première cible la demande de bind au service DSRUAPI et la seconde cible les requêtes DCE/RPC « DsGetNCChanges« . Les éléments importants à repérer étant les offset (pour cibler le bon attribut des paquets en fonction de leur position) et le contenu sous forme hexadécimal.

Il est à noter que la directive « !$DC_SERVERS any -> $DC_SERVERS » permet de surveiller explicitement les flux qui ne proviennent pas d’un contrôleur de domaine (exemple, un poste utilisateur) et qui vont vers un contrôleur de domaine. Ce qui exclut de fait les flux légitimes entre les contrôleurs de domaine.

Il faut alors penser à modifier, dans le fichier de configuration « /etc/suricata/suricata.yml« , la variable « $DC_SERVERS » pour qu’elle contienne la liste de nos contrôleurs de domaine (sans oublier le serveur Azure AD Connect) :

# Définition de la variable DC_SERVERS dans le fichier /etc/suricata/suricata.yml
vars:
  # more specific is better for alert accuracy and performance
  address-groups:
  (...)
    DNS_SERVERS: "(192.168.56.102,192.168.56.103,192.168.56.150)"

Dès lors, les alertes émises par Suricata contiendront une trace assez nette de détection de l’attaque DCSync :

$ cat fast.log                                                                                                                 
07/04/2024-21:19:00.164495  (**) (1:1000002:1) Mimikatz DRSUAPI DsGetNCChanges Request (**) (Classification: Potential Corporate Privacy Violation) (Priority: 1) TCP 192.168.56.109:56104 -> 192.168.56.102:49668

En fonction des technologies NIDS utilisées et de leur implémentation, la mise en œuvre de cette détection par le réseau peut bien entendu se faire différemment. Ce qu’il faut retenir est qu’il est possible de détecter une attaque DCSync par l’analyse et la surveillance du réseau en plus des journaux d’évènements.

V. Conclusion

Dans cette seconde partie de l’article sur l’attaque DCSync, nous avons identifié plusieurs moyens de détection de cette attaque. Que ce soit par les journaux d’évènements, quand ils sont bien configurés, par l’ajout de solutions tierces comme RPCFirewall ou par la surveillance du réseau avec des NIDS comme Suricata, il est possible d’identifier et de détecter une attaque DCSync ciblant nos contrôleurs de domaine.