Forensic Active Directory : logs des contrôleurs de domaine

Les contrôleurs de domaine voient chaque ticket Kerberos, chaque validation NTLM d'un compte du domaine et chaque modification d'utilisateur, de groupe ou de stratégie. Ce guide vous montre quels journaux vivent sur un DC, quel event ID répond à quelle question, comment repérer DCSync, la falsification de l'annuaire, l'abus de GPO et le vol de NTDS.dit, et comment fusionner les preuves de plusieurs DC en un seul récit. Il suppose les bases du guide forensic des journaux d'événements Windows.

Ce que contient un contrôleur de domaine

Un DC est un serveur Windows doté de rôles supplémentaires : tous les artefacts habituels d'une machine s'appliquent. En plus :

Les fiches NTDS.dit et stratégies de groupe décrivent la structure de la base et des dossiers de GPO. La présentation des journaux d'événements couvre le format EVTX lui-même.

Prérequis de la stratégie d'audit

Avant de chasser, vérifiez ce que les DC étaient configurés pour enregistrer. La plupart des événements intéressants d'un DC proviennent des sous-catégories de l'Advanced Audit Policy, et plusieurs exigent en plus une SACL sur les objets de l'annuaire.

# Stratégie d'audit effective sur un DC
auditpol /get /category:*

# Stratégie résultante pour l'OU Domain Controllers, pour savoir d'où elle vient
gpresult /h C:\temp\dc-gpresult.html

Les sous-catégories qui comptent le plus :

• Account Logon : Credential Validation (4776), Kerberos Authentication Service (4768, 4771), Kerberos Service Ticket Operations (4769, 4770).
• Account Management : User Account Management (4720 à 4726, 4738, 4740, 4767), Security Group Management (4727 à 4737, 4754 à 4758), Computer Account Management (4741 à 4743).
• DS Access : Directory Service Access (4662) et Directory Service Changes (5136 à 5141). Les deux dépendent des SACL : sans entrée d'audit sur l'objet, rien n'est journalisé.
• Logon/Logoff et Detailed Tracking (4688 avec ligne de commande) pour l'activité sur le DC lui-même.

Vérifiez aussi la taille du journal Security. Sur un DC chargé, la taille par défaut ne couvre parfois que quelques heures de trafic Kerberos. Si les journaux partent vers un SIEM, cette copie est peut-être la seule dont vous disposez.

Événements Kerberos

Kerberos est l'authentification par défaut d'un domaine, et chaque demande de ticket est journalisée par le DC qui l'a servie.

• 4768, demande de TGT. Nom du compte, adresse du client, type de chiffrement du ticket et type de pré-authentification. Un chiffrement 0x17 (RC4) dans un environnement en AES, ou un type de pré-authentification 0 (pas de pré-auth) pour un utilisateur, évoque une rétrogradation ou de l'AS-REP roasting.
• 4769, demande de ticket de service. Nom du service (le compte portant le SPN), adresse du client et type de chiffrement. Un même compte demandant en peu de temps des tickets RC4 pour de nombreux comptes de service, c'est le schéma du Kerberoasting.
• 4770 : ticket renouvelé. 4771, échec de pré-authentification : le code d'échec 0x18 signifie mauvais mot de passe. Beaucoup de 4771 depuis une même adresse sur de nombreux comptes, c'est du password spraying.
• 4776, validation d'identifiants NTLM sur le DC pour les comptes du domaine. Les codes d'erreur comme 0xC000006A (mauvais mot de passe) et 0xC0000064 (utilisateur inconnu) distinguent le spraying des fautes de frappe. Le champ station de travail est fourni par le client et peut être vide ou falsifié.

# Candidats Kerberoasting : tickets de service RC4
chainsaw search -t 'Event.System.EventID: =4769' --json ./DC01/Logs |
  jq -r 'select(.Event.EventData.TicketEncryptionType=="0x17")
         | [.Event.System.TimeCreated_attributes.SystemTime,
            .Event.EventData.TargetUserName,
            .Event.EventData.ServiceName,
            .Event.EventData.IpAddress] | @tsv'

Les noms de champs de la sortie JSON de Chainsaw suivent la structure EVTX et peuvent changer d'une version à l'autre : ajustez les chemins jq après avoir examiné un enregistrement.

Modifications de comptes et de groupes

Ces événements sont la colonne vertébrale de tout constat de persistance ou d'élévation de privilèges dans AD. Tous indiquent le sujet (qui a agi) et la cible (ce qui a changé).

Surveillez l'enchaînement « 4720 puis 4728 vers un groupe privilégié en quelques minutes » et les modifications de groupes protégés par AdminSDHolder. Un 4738 dont le champ UserAccountControl montre le flag « Don't Require Preauth » nouvellement activé, c'est un attaquant qui prépare une cible d'AS-REP roasting. Les noms de comptes ne suffisent pas : utilisez le SID cible (voir identifiant de sécurité), car les noms peuvent être réutilisés.

DCSync et le 4662

DCSync détourne le protocole de réplication de l'annuaire : un compte non-DC disposant des droits de réplication demande à un DC les données de mots de passe, exactement comme le ferait un autre DC. Sur le DC, cela apparaît sous forme de 4662 (une opération a été effectuée sur un objet) sur l'objet racine du domaine, avec un champ Properties contenant les GUID de droits d'accès étendus :

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 : DS-Replication-Get-Changes
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 : DS-Replication-Get-Changes-All
• 89e95b76-444d-4c62-991a-0facbeda640c : DS-Replication-Get-Changes-In-Filtered-Set

Excluez les comptes machine des DC (noms en $ appartenant à l'OU Domain Controllers) et les comptes Azure AD Connect ou autres comptes de synchronisation documentés. Ce qui reste, surtout un compte utilisateur ou le compte machine d'un poste de travail, est un candidat DCSync. Associez-le à un 4624 type 3 du même compte depuis une IP source qui n'est pas un DC.

Cela ne fonctionne que si l'audit Directory Service Access est actif et si la SACL de l'objet domaine audite ces droits. Beaucoup d'environnements n'ont ni l'un ni l'autre : un résultat vide n'est donc pas un résultat propre. La détection réseau du trafic DRSUAPI depuis des machines non-DC est le complément. L'attribution initiale des droits apparaît sous forme de 5136 sur le nTSecurityDescriptor de l'objet domaine, si l'audit Directory Service Changes est actif.

Modifications de l'annuaire : 5136 à 5141

Avec l'audit Directory Service Changes et une SACL, les DC journalisent les modifications au niveau des attributs :

• 5136 : attribut modifié, avec le nom de l'attribut, l'ancienne et la nouvelle valeur (sous forme de deux événements, avec les types d'opération « valeur supprimée » et « valeur ajoutée »).
• 5137 créé, 5138 restauré, 5139 déplacé, 5141 supprimé.

Ils sont bien plus détaillés que les événements Account Management : modifications de nTSecurityDescriptor (portes dérobées par ACL), de servicePrincipalName (Kerberoasting ciblé), de msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD), de sIDHistory et des attributs de GPO. Le piège reste la SACL : les SACL par défaut ne couvrent qu'une partie de l'annuaire.

Abus de GPO

Un objet de stratégie de groupe modifié pousse du code sur chaque ordinateur auquel il s'applique, ce qui en fait un vecteur favori des déploiements de rançongiciel.

• Côté annuaire : 5136 sur un objet groupPolicyContainer, typiquement versionNumber et gPCMachineExtensionNames qui changent, et 5137 pour de nouvelles GPO ou de nouveaux liens (gPLink sur une OU).
• Côté SYSVOL : fichiers nouveaux ou modifiés sous \\<domaine>\SYSVOL\<domaine>\Policies\{GUID}\, comme Machine\Preferences\ScheduledTasks\ScheduledTasks.xml, Machine\Scripts\Startup\ ou Groups.xml. Les horodatages de la $MFT et les accès 5145 aux partages (si l'audit est actif) indiquent quand et depuis où.
• Côté client : Microsoft-Windows-GroupPolicy/Operational sur les postes enregistre le traitement, et les tâches planifiées ou services résultants montrent ce qui s'est réellement exécuté.

D'anciens fichiers Groups.xml contenant un attribut cpassword constituent aussi une exposition d'identifiants à signaler, la clé de chiffrement étant publique.

Traces de vol de NTDS.dit

Voler la base donne à l'attaquant tous les hashes hors ligne. Méthodes courantes : IFM via ntdsutil, cliché instantané de volume avec vssadmin ou diskshadow, ou lecture brute du disque.

• Traces de processus : Prefetch de NTDSUTIL.EXE, VSSADMIN.EXE, DISKSHADOW.EXE, ESENTUTL.EXE, plus 4688 ou événement 1 de Sysmon avec des lignes de commande comme ac i ntds / ifm / create full.
• Événements ESENT du journal Application : 325 (base créée), 326 (attachée) et 327 (détachée) pour une copie de ntds.dit dans un chemin inhabituel sont la trace IFM classique. Le chemin indiqué dans le message est le champ clé.
• VSS : création de clichés instantanés dans les journaux System et Application, et clichés qui ne correspondent à aucune planification de sauvegarde.
• Fichiers : ntds.dit et une copie de la ruche SYSTEM dans C:\Windows\Temp, C:\ProgramData ou un partage, souvent compressés juste après. Consultez le journal USN s'ils ont été supprimés.

Voir forensic de l'accès aux identifiants pour les mêmes techniques sur les serveurs membres et les postes de travail.

Indicateurs de golden et silver tickets

Les tickets forgés contournent l'étape d'émission par le DC : la preuve est donc surtout une absence. Aucun de ces indicateurs n'est concluant seul :

• Golden ticket (TGT forgé) : des 4769 ou des logons pour un compte sans 4768 correspondant sur aucun DC pendant la durée de vie du ticket ; du chiffrement RC4 dans un domaine en AES seul ; des noms de comptes inexistants ou qui ne correspondent pas au SID ; des logons qui continuent après une réinitialisation de mot de passe. Certains outils anciens produisaient des anomalies de champs, comme un format inhabituel du champ domaine, mais l'outillage moderne imite les vrais tickets.
• Silver ticket (ticket de service forgé) : un 4624 sur un serveur membre sans 4769 correspondant sur aucun DC, puisque le DC n'est jamais contacté. Il faut les journaux du serveur et ceux des DC côte à côte pour le voir.
• Contexte : un DCSync ou un vol de NTDS.dit plus tôt dans la chronologie rend la falsification plausible, car l'attaquant détient alors les clés de krbtgt ou des comptes de service.

La réponse robuste est opérationnelle : réinitialiser deux fois le mot de passe de krbtgt, en respectant l'espacement recommandé par Microsoft, et réinitialiser les comptes de service.

Corréler plusieurs DC

• Collectez chaque DC inscriptible et chaque RODC, pas seulement l'émulateur PDC. L'authentification est répartie par site.
• Normalisez en UTC et comparez les horloges des DC entre elles ; Kerberos tolère un décalage, votre chronologie non.
• Dédoublonnez les événements répliqués : un 4740 peut apparaître sur le DC qui l'a traité et sur le PDC.
• Utilisez les métadonnées de réplication quand les journaux ont disparu. repadmin /showobjmeta ou ADTimeline montrent quand chaque attribut d'un objet a changé pour la dernière fois et sur quel DC la modification est née, même des années après.

# Historique des modifications d'attributs d'un compte suspect
repadmin /showobjmeta DC01 "CN=svc-backup,OU=Service Accounts,DC=corp,DC=example"

# Chronologie Hayabusa de tous les journaux collectés sur un DC
hayabusa csv-timeline -d .\DC01\Logs -o DC01_hayabusa.csv

Outils

• Hayabusa et Chainsaw : tri basé sur Sigma avec des règles pour le Kerberoasting, DCSync, les modifications de groupes et l'effacement des journaux. Lancez-les par DC, puis fusionnez.
• EvtxECmd : CSV normalisé de tous les EVTX, à pivoter dans Timeline Explorer.
• PingCastle : évaluation de posture, pas de la forensic, mais il montre vite les faiblesses que l'attaquant a probablement exploitées (délégation, administrateurs obsolètes, mots de passe GPP, audit manquant).
• ADTimeline (ANSSI) : construit une chronologie des modifications d'objets AD à partir des métadonnées de réplication, qui survivent à la rotation des journaux.

Les options changent selon les versions : vérifiez --help sur celle que vous utilisez.

Pièges

• Conclure « pas de DCSync » faute de 4662. Sans la SACL et la sous-catégorie d'audit, DCSync est invisible dans le journal Security.
• Ne collecter qu'un seul DC. Vous raterez l'essentiel des événements Kerberos et NTLM et sous-estimerez le périmètre.
• Faire confiance au nom de station du 4776. Il vient du client. Utilisez l'IP quand elle existe, et le 4624 sur la machine source.
• Signaler chaque ticket RC4. Des applications anciennes et des approbations utilisent encore RC4. Établissez d'abord une référence.
• Ignorer les comptes machine. Un compte $ de poste de travail qui réplique ou modifie des objets, c'est exactement ce que vous cherchez.
• Oublier que le DC est aussi une machine. Examinez ses services, tâches planifiées, Prefetch et traces de mouvement latéral, avec le guide RDP, PsExec et WinRM.

Démarche d'enquête sur un DC

1. Listez chaque DC et RODC, vérifiez la synchronisation horaire, et collectez les journaux Security, System, Application, Directory Service, DNS Server et DFS Replication, plus SYSVOL et les artefacts système.
2. Notez la stratégie d'audit effective et la rétention des journaux de chaque DC.
3. Lancez Hayabusa ou Chainsaw par DC et fusionnez les résultats dans une chronologie UTC unique.
4. Chassez les abus d'authentification : spraying 4771/4776, 4768 sans pré-auth, rafales de 4769 en RC4.
5. Passez en revue les modifications de comptes et de groupes (4720, 4722 à 4726, 4728/4732/4756, 4738, 4740) visant des cibles privilégiées.
6. Vérifiez les 4662 portant les GUID de réplication et les 5136 à 5141 touchant ACL, SPN, délégation et GPO.
7. Cherchez le vol de NTDS.dit : exécution de ntdsutil/vssadmin, ESENT 325/326/327, activité VSS, copies de ntds.dit égarées.
8. Là où les journaux manquent, datez les modifications avec les métadonnées de réplication (ADTimeline, repadmin /showobjmeta).
9. Évaluez les indicateurs de tickets forgés et, si des identifiants ont été exposés, planifiez la réinitialisation de krbtgt et des comptes de service.