Auditer Active Directory : journaux, alerting et détection de compromission

Une infrastructure Active Directory non auditée est une boîte noire pour la sécurité. Les attaques modernes ne défoncent plus la porte du DC : elles compromettent un poste utilisateur, escaladent vers un compte privilégié, se déplacent latéralement, exfiltrent. Tout ce parcours laisse des traces dans les journaux Windows et Active Directory — à condition que l’audit soit activé, collecté, conservé et analysé. Ce tutoriel pose les bases : politique d’audit avancée, configuration des journaux, collecte centralisée, détection des signaux classiques (Kerberoasting, AS-REP Roasting, DCSync, élévation de privilège).

Prérequis : un domaine AD avec DC fonctionnel (cf. Promouvoir le premier contrôleur de domaine). Panorama : Windows Server 2025 et Active Directory pour PME.

Prérequis

• Un ou plusieurs DC Windows Server 2025.
• Un compte Domain Admin pour pousser les GPO d’audit.
• Un serveur de collecte des événements (Windows Event Forwarding, Wazuh, ELK, Microsoft Sentinel — selon le budget).
• Pour la PME : au moins le Windows Event Forwarding natif, gratuit et largement suffisant.
• Connaissances en lecture de journaux Windows (Event IDs, filtrage XPath).
• Niveau attendu : intermédiaire à avancé.
• Temps estimé : 2 heures pour le setup initial, plus 1 heure par investigation.

Étape 1 — Comprendre la politique d’audit avancée

Windows distingue deux niveaux de politique d’audit : la politique classique (10 catégories grossières, héritée de NT) et la politique d’audit avancée (60+ sous-catégories fines, depuis Server 2008). Toute infrastructure moderne utilise l’avancée — la classique génère trop de bruit et manque de granularité.

Les sous-catégories critiques à activer en PME :

• Account Logon → Credential Validation (Success + Failure) — événements 4776 sur le DC qui valide les hashs.
• Account Logon → Kerberos Authentication Service (S + F) — événements 4768/4771 sur TGT.
• Account Logon → Kerberos Service Ticket Operations (S + F) — événements 4769 sur service tickets.
• Account Management (S + F) — toute création/modification de compte ou groupe.
• Logon/Logoff → Logon (S + F) — ouvertures de session 4624/4625.
• Logon/Logoff → Special Logon (S) — 4672, élévation de privilège.
• DS Access → Directory Service Changes (S) — modifications d’objets AD.
• Privilege Use → Sensitive Privilege Use (S + F) — utilisation de droits sensibles type SeBackup, SeDebug.

Étape 2 — Pousser la GPO d’audit sur les DC

Créer une GPO SEC-Audit-DCs liée à l’OU Domain Controllers. Éditer dans Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration. Pour chaque sous-catégorie listée ci-dessus, activer Configure → Audit Success and Failure.

Activer aussi le forçage de la politique avancée sur la politique classique (Security Options → Audit: Force audit policy subcategory settings… = Enabled), sinon Windows ignore parfois la politique fine.

Appliquer et vérifier sur un DC :

gpupdate /force
auditpol /get /category:*

La sortie doit lister les sous-catégories ciblées avec Success and Failure. Si certaines restent en No Auditing, vérifier que la GPO est bien liée et que Authenticated Users a les droits de lecture/application.

Étape 3 — Augmenter la taille des journaux Security

Par défaut, le journal Security est plafonné à 20 Mo — il se vide en quelques heures sur un DC actif. On augmente à 4 Go minimum pour conserver une fenêtre exploitable.

Limit-EventLog -LogName Security -MaximumSize 4GB -OverflowAction OverwriteAsNeeded

Pour rendre ce paramètre permanent via GPO : Computer Configuration → Policies → Administrative Templates → Windows Components → Event Log Service → Security → Specify the maximum log file size = 4194240 KB.

Vérifier :

Get-EventLog -List | Where-Object Log -eq Security

La taille maximale doit être de 4 Go. Sur un DC actif d’une PME 50 postes, cela offre une rétention typique de 7 à 14 jours en journal local.

Étape 4 — Configurer Windows Event Forwarding

Pour la conservation longue durée et la corrélation, on agrège les journaux sur un serveur collecteur. Windows Event Forwarding (WEF) est natif, gratuit, sans agent supplémentaire.

Sur le serveur collecteur (un Windows Server 2025 dédié, par exemple SRV-LOGS) :

wecutil qc /q
winrm quickconfig -q
Set-Service WinRM -StartupType Automatic
Start-Service WinRM

Créer une subscription qui collecte les événements depuis les DC. Le plus simple : import d’un XML pré-construit. Un exemple de subscription qui collecte 4624, 4625, 4672, 4768, 4769, 4776 depuis tous les DC :

<Subscription>
  <SubscriptionId>DC-Security-Events</SubscriptionId>
  <SubscriptionType>SourceInitiated</SubscriptionType>
  <Enabled>true</Enabled>
  <ContentFormat>RenderedText</ContentFormat>
  <LogFile>ForwardedEvents</LogFile>
  <Query>
    <![CDATA[
      <QueryList>
        <Query Path="Security">
          <Select Path="Security">
            *[System[(EventID=4624 or EventID=4625 or EventID=4672
              or EventID=4768 or EventID=4769 or EventID=4776)]]
          </Select>
        </Query>
      </QueryList>
    ]]>
  </Query>
</Subscription>

Importer :

wecutil cs dc-security.xml

Côté DC, une GPO pousse l’URL du collecteur et autorise NETWORK SERVICE à lire le journal Security :

• Computer Configuration → Policies → Administrative Templates → Windows Components → Event Forwarding.
• Configure target Subscription Manager = Server=http://srv-logs.ad.entreprise.com:5985/wsman/SubscriptionManager/WEC,Refresh=60.

Dans les 5 minutes après gpupdate /force côté DC, les événements arrivent sur le collecteur dans le journal Forwarded Events.

Étape 5 — Détecter les ouvertures de session anormales

L’événement 4624 indique une ouverture de session réussie. Sa propriété LogonType précise le mode : 2 (interactive locale), 3 (réseau), 10 (RDP), etc. Les signaux à chasser :

• Logon interactif (type 2) sur un DC par un compte non-admin → enquête immédiate.
• Logon RDP (type 10) sur un DC depuis une IP qui n’est pas celle des admins → potentiel mouvement latéral.
• Volume soudain d’événements 4625 (échec d’authentification) sur un compte → tentative de bruteforce.

Requête XPath pour les logons RDP sur DC :

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} |
  Where-Object {$_.Properties[8].Value -eq 10} |
  Select-Object TimeCreated, @{n='User';e={$_.Properties[5].Value}}, @{n='IP';e={$_.Properties[18].Value}}

Étape 6 — Détecter Kerberoasting

Le Kerberoasting consiste à demander des tickets de service (TGS) pour des comptes de service ayant un SPN, puis à brute-forcer les hashs hors ligne. La détection repose sur le volume d’événements 4769 émis par un même compte vers de nombreux SPN différents.

$start = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4769; StartTime=$start} |
  Group-Object -Property {$_.Properties[0].Value} |
  Sort-Object Count -Descending |
  Select-Object -First 10 Name, Count

Un compte qui demande 50+ tickets différents en une heure est suspect. Configurer une alerte Sentinel / Wazuh sur ce pattern.

Étape 7 — Détecter AS-REP Roasting

L’AS-REP Roasting cible les comptes pour lesquels la pré-authentification Kerberos est désactivée (DONT_REQ_PREAUTH). L’attaquant peut demander un TGT directement sans connaître le mot de passe, et brute-forcer le hash. Vérifier qu’aucun compte du domaine n’a cette propriété :

Get-ADUser -Filter 'UserAccountControl -band 4194304' `
  -Properties UserAccountControl |
  Select-Object Name, UserAccountControl

La sortie doit être vide. Si un compte apparaît, identifier pourquoi (application legacy ?) et le corriger. Côté détection en temps réel : alerte sur événements 4768 avec PreAuthType=0.

Étape 8 — Détecter DCSync

DCSync est l’utilisation de l’API de réplication d’AD pour récupérer tous les hashs depuis un DC, abusée par les attaquants qui ont compromis un compte Domain Admin ou un compte ayant les droits Replicating Directory Changes. L’événement 4662 sur GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 (Replicating Directory Changes All) est le signal.

$gid = '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4662; StartTime=(Get-Date).AddDays(-7)} |
  Where-Object { $_.Message -match $gid } |
  Select-Object TimeCreated, @{n='Account';e={
    ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'SubjectUserName' | ForEach-Object '#text'
  }}

Seuls les comptes machine des DC et le compte krbtgt doivent apparaître normalement. Tout autre compte = compromission critique.

Aparté — Pourquoi le compte krbtgt mérite une attention particulière

Le compte krbtgt est invisible mais c’est le compte le plus puissant du domaine. C’est son mot de passe qui signe tous les TGT Kerberos émis par les DC. Un attaquant qui obtient ce hash peut forger des tickets Golden Ticket valables sans contrainte de temps, sans authentification réelle, avec n’importe quels groupes — autrement dit, persister indéfiniment dans le domaine même après réinitialisation des mots de passe des comptes admin.

La bonne pratique : faire pivoter le mot de passe krbtgt deux fois tous les 180 jours. Deux fois parce que les DC conservent le hash actuel et le hash précédent (pour la transition douce des tickets en cours) ; deux rotations rapprochées invalident complètement l’ancien hash.

# Télécharger le script officiel Microsoft
# New-KrbtgtKeys.ps1 depuis le repo GitHub Microsoft
.\New-KrbtgtKeys.ps1 -OU 'OU=Domain Controllers,DC=ad,DC=entreprise,DC=com' -mode Single -ResetCount 2

Programmer cette rotation deux fois par an dans le calendrier de l’IT. C’est l’une des actions de cybersécurité au meilleur rapport bénéfice/effort sur un environnement Active Directory.

Étape 9 — Lancer une analyse PingCastle hebdomadaire

PingCastle (édition Community) est un outil gratuit pour auditer sa propre infrastructure — l’audit pour le compte d’un tiers nécessite une licence commerciale PingCastle for Service Providers. La Community Edition audite la santé et la posture sécurité d’un domaine en quelques minutes. Il produit un rapport HTML noté de 0 (parfait) à 100 (catastrophe), avec recommandations détaillées.

# Télécharger depuis pingcastle.com
.\PingCastle.exe --healthcheck --server ad.entreprise.com
.\PingCastle.exe --report --xmls .

Programmer une tâche planifiée hebdomadaire qui exécute PingCastle et publie le HTML résultant sur un partage interne. Suivre l’évolution du score est un indicateur direct de la posture sécurité — il doit baisser au fil des durcissements.

Étape 10 — Surveiller les modifications sensibles avec une alerte temps réel

Plutôt que d’analyser les journaux a posteriori, configurer des alertes en temps réel sur les événements à fort signal. Le mécanisme natif : Task Scheduler déclenché sur un Event ID, qui exécute un script PowerShell d’alerte.

# Tâche planifiée déclenchée sur événement 4728 (ajout à un groupe sensible)
$action = New-ScheduledTaskAction -Execute 'powershell.exe' `
  -Argument '-NoProfile -File C:\Admin\alert-group-change.ps1'

$trigger = New-CimInstance -CimClass (Get-CimClass MSFT_TaskEventTrigger root/Microsoft/Windows/TaskScheduler) `
  -ClientOnly -Property @{
    Subscription = '<QueryList><Query Path="Security"><Select Path="Security">*[System[(EventID=4728 or EventID=4732 or EventID=4756)]]</Select></Query></QueryList>'
    Enabled = $true
  }

Register-ScheduledTask -TaskName 'Alert-Sensitive-Group' `
  -Action $action -Trigger $trigger `
  -User 'NT AUTHORITY\SYSTEM' -RunLevel Highest

Le script PowerShell associé envoie un e-mail dès qu’un compte est ajouté à Domain Admins, Enterprise Admins ou Schema Admins. C’est rapide à mettre en place, gratuit, et capture les cas les plus critiques sans nécessiter de SIEM. Pour une PME, c’est souvent suffisant comme première ligne de détection — on monte vers Wazuh ou Sentinel quand le périmètre justifie l’investissement.

Étape 11 — Activer Microsoft Defender for Identity (optionnel)

Pour les PME qui ont une souscription Microsoft 365 E5 ou un abonnement standalone Defender for Identity, le service apporte une détection comportementale managée : Kerberoasting, AS-REP, DCSync, Pass-the-Hash, etc. Un capteur léger s’installe sur chaque DC et envoie les métadonnées d’authentification au cloud Microsoft qui applique des modèles ML.

Setup minimal :

• Tenant Entra ID avec licence Defender for Identity.
• Télécharger le sensor depuis le portail Defender, l’installer sur chaque DC.
• Configurer un compte de service en lecture seule pour les requêtes LDAP de découverte.
• Attendre 30 jours de baseline avant que les alertes deviennent pertinentes.

L’apport de Defender for Identity est triple. D’abord la couverture comportementale : les modèles ML détectent des combinaisons d’actions individuellement anodines mais collectivement suspectes, par exemple une énumération LDAP suivie d’une demande de tickets pour comptes admin. Ensuite la corrélation cross-domaine : les signaux d’un poste compromis remontent au DC et à la console Defender unifiée Microsoft 365. Enfin la cartographie automatique des chemins de compromission privilégiés, en complément ou en remplacement de BloodHound. Le revers : la dépendance à un service cloud et au licensing E5, plus le coût d’environ 5 € par utilisateur et par mois en standalone — à mettre en balance avec la valeur d’une détection automatisée des attaques modernes sur AD. Pour une PME qui ne souscrit pas à E5, l’enchaînement WEF + tâches planifiées + PingCastle hebdomadaire couvre 80 % des cas usuels avec un coût opérationnel raisonnable. Une approche hybride pragmatique consiste à activer Defender for Identity uniquement sur les DC en pilote pendant trois mois, mesurer la pertinence des alertes générées sur l’environnement réel, puis décider d’étendre ou d’arrêter — la facture s’aligne sur la valeur observée plutôt que sur une promesse théorique.

Erreurs fréquentes

Vérification finale

La politique d’audit avancée est appliquée sur les DC, les journaux ont une rétention raisonnable, WEF agrège les événements critiques sur un collecteur, des requêtes PowerShell détectent Kerberoasting, AS-REP, DCSync et logons anormaux, PingCastle audite la posture chaque semaine, et le score s’améliore avec le temps. Active Directory n’est plus une boîte noire : chaque tentative suspecte laisse une trace, et chaque trace peut déclencher une alerte.

Pour une vue d’ensemble revoyez Windows Server 2025 et Active Directory pour PME. Pour étendre la sécurité aux postes : Durcissement Windows : GPO, BitLocker, Defender, AppLocker et LAPS.

Ressources officielles

• Audit policy recommendations — Microsoft Learn
• Advanced security audit policy settings — Microsoft Learn
• Windows Event Forwarding for intrusion detection — Microsoft Learn
• PingCastle official documentation
• Microsoft Defender for Identity — Microsoft Learn