Supervision Sécurité AD : Événements Clés

Qu'est-ce que la supervision Active Directory ?

La supervision Active Directory est la combinaison de la politique d'audit, de la collecte d'événements, de la corrélation et de l'analyse de référence nécessaire pour détecter les attaques d'identité contre les contrôleurs de domaine et les comptes privilégiés. De nombreux environnements AD génèrent des événements Windows Security, mais beaucoup moins génèrent les bons événements et les acheminent vers des détections qu'un analyste peut réellement exploiter.

La supervision AD ne se limite pas à la rétention des logs. C'est la discipline consistant à choisir les sous-catégories qui comptent, à prouver que les événements sont bien présents sur les contrôleurs de domaine, et à construire des détections autour du comportement de l'attaquant plutôt que du volume brut.

Un programme de supervision AD utile part des chemins d'attaque que les défenseurs doivent réellement pouvoir voir : l'abus de tickets Kerberos, le DCSync, les modifications de groupes privilégiés, les écritures sur les objets d'annuaire, l'authentification NTLM, l'émission de certificats et le mouvement latéral vers les serveurs sensibles.

Comment fonctionne la supervision Active Directory

L'audit de sécurité Windows est contrôlé par la Politique d'Audit Avancée et ne produit des données utiles que si les bonnes sous-catégories sont activées.

Un pipeline de supervision concret ressemble à ceci :

1. La Politique d'Audit Avancée active les événements dont vous avez besoin
2. Le journal d'événements Windows stocke localement les événements Security
3. WEF ou un agent transmet les événements vers une plateforme centrale
4. La corrélation SIEM transforme ces événements en détections et en investigations

L'échec le plus courant reste l'étape une : le collecteur et le SIEM existent, mais les sous-catégories AD clés n'ont jamais été activées sur les contrôleurs de domaine qui comptent.

La documentation de Microsoft Defender for Identity renforce ce constat en listant les événements Windows requis pour les capteurs et l'infrastructure associée. La liste inclut des événements d'identité essentiels comme 4662, 4728, 4732, 4756 et 4776. Si vos contrôleurs de domaine ne génèrent pas et ne transmettent pas ces événements, la logique de détection en aval ne peut pas récupérer les preuves manquantes.

La chaîne d'attaque sans supervision

DCSync - Pas d'audit d'accès au service d'annuaire

Sans Audit Directory Service Access, l'événement 4662 ne donne pas aux défenseurs la visibilité attendue sur l'abus des droits de réplication. L'événement 4662 est généré lorsqu'une opération est effectuée sur un objet Active Directory, mais la configuration de l'audit d'objet et de la SACL reste déterminante pour une couverture utile.

Kerberoasting - Pas de visibilité sur les tickets Kerberos

Sans la collecte et la revue de 4769, les demandes inhabituelles de tickets de service se fondent dans le trafic normal et les demandes fortement chiffrées en RC4 sont faciles à manquer. Microsoft documente l'événement 4769 comme un événement de demande TGS généré sur les contrôleurs de domaine. Les mises à jour Windows récentes exposent des champs Kerberos supplémentaires, ce qui peut améliorer l'investigation lorsqu'ils sont disponibles.

Abus de groupe privilégié - Pas d'alerte sur les changements d'appartenance

Sans couverture pour 4728, 4732 et 4756, un attaquant peut ajouter un compte backdoor à un groupe privilégié et compter sur le fait que les administrateurs ne le remarqueront qu'après coup. Ces événements correspondent aux changements d'appartenance des groupes de sécurité globaux, locaux et universels.

Abus de délégation ou de GPO - Pas de visibilité sur les changements

Sans 5136 et l'audit des changements associé, des modifications d'annuaire à fort impact peuvent survenir avec très peu de contexte pour l'investigation. L'événement 5136 est généré lorsqu'un objet du service d'annuaire est modifié, et il devient plus utile lorsqu'il est associé à l'attribut modifié et au contexte de l'objet.

Détection

Configuration essentielle de la politique d'audit

Déployer via GPO : Configuration Ordinateur > Paramètres Windows > Paramètres de Sécurité > Configuration avancée de la politique d'audit

Référence des Event ID critiques

Requêtes de détection SIEM (Elastic KQL)

Détection DCSync :

event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*") AND
NOT winlog.event_data.SubjectUserName: ("*$")

Détection Kerberoasting :

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

Changement de groupe privilégié :

event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: ("Domain Admins" OR "Enterprise Admins" OR "Schema Admins")

Conseil : commencez par un petit ensemble de détections à haute confiance que l'équipe examinera réellement. DCSync, les changements de groupe privilégié et l'abus de tickets de service apportent généralement bien plus de valeur qu'un large ensemble de règles non maintenu.

Mapping des champs et validation du parseur

Avant d'écrire une logique de détection complexe, validez le mapping des champs pour votre SIEM. Le même événement Windows peut arriver avec des noms de champs différents selon le connecteur, l'agent ou la couche de normalisation. Pour chaque détection critique, vérifiez que :

• l'Event ID est analysé de façon cohérente
• les champs de compte séparent les comptes utilisateur, domaine et machine
• les champs de poste source et d'adresse client sont conservés
• les champs de chiffrement de ticket sont présents pour les détections Kerberos
• les champs d'objet et d'attribut d'annuaire sont conservés pour 4662 et 5136
• les champs de demande de certificat et de modèle sont conservés pour les événements AD CS

Une règle qui fonctionne en laboratoire mais perd un champ critique en production n'est pas une couverture.

Remédiation

Action rapide : activez Directory Service Access, Directory Service Changes et les sous-catégories Kerberos sur tous les contrôleurs de domaine avant tout autre réglage.

1. Déployer la politique d'audit avancée via GPO

auditpol /get /category:*

auditpol /set /subcategory:"Directory Service Changes" /success:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable

2. Augmenter la capacité du journal Security

La taille par défaut du journal Security est souvent trop petite pour des contrôleurs de domaine à forte activité.

wevtutil sl Security /ms:1073741824 /rt:false /ab:true

La capacité du journal doit être dimensionnée selon le volume réel d'événements. Les domaines à forte activité Kerberos et les DC très sollicités peuvent écraser rapidement les preuves si les journaux Security restent aux valeurs par défaut, trop faibles.

3. Transmettre centralement les événements des contrôleurs de domaine

winrm quickconfig
wecutil cs subscription.xml
gpupdate /force

La transmission doit préserver le XML des événements ou les champs normalisés requis pour la détection. Si votre collecteur supprime Properties, ObjectDN, TicketEncryptionType ou les champs de poste source, les règles à forte valeur se dégradent en alertes génériques.

4. Établir des références avant d'ajuster les seuils

Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4768} |
    Group-Object {$_.TimeCreated.Hour} |
    Select-Object Name, Count |
    Sort-Object Name

Utilisez ces références pour comprendre le volume normal de trafic Kerberos et d'ouvertures de session avant d'introduire des seuils d'anomalie.

5. Associer les détections aux chemins d'attaque

Ne supervisez pas les Event ID de façon isolée. Associez chaque détection au chemin d'attaque qu'elle soutient :

• le DCSync nécessite les événements de droits de réplication et les changements d'annuaire privilégiés
• le Kerberoasting nécessite la visibilité sur les tickets de service, le contexte de chiffrement et l'inventaire des comptes de service
• l'abus de délégation nécessite la visibilité sur les changements d'attribut et l'authentification inhabituelle de comptes machine
• le relais NTLM nécessite la validation NTLM, les ouvertures de session cibles et les actions consécutives spécifiques au service
• l'abus AD CS nécessite le contexte de demande, d'émission et de modèle de certificat

Ce mapping évite que le programme de supervision ne devienne une liste d'événements déconnectés.

Comment EtcSec détecte cela

EtcSec vérifie la couverture de la politique d'audit dont les défenseurs ont besoin pour investiguer les principaux chemins d'attaque AD révélés ailleurs dans le rapport.

Les constats liés à la supervision mettent en évidence les sous-catégories d'audit manquantes, la rétention insuffisante et d'autres lacunes qui laisseraient un abus d'identité à forte valeur invisible ou difficile à reconstituer.

Détections à mettre en œuvre en premier

Si l'équipe de supervision ne peut déployer que quelques règles à forte valeur dans un premier temps, commencez par les attaques à la fois courantes et opérationnellement exploitables :

• l'abus des droits de réplication et les tentatives de DCSync
• les changements d'appartenance aux groupes privilégiés
• les demandes suspectes de tickets de service associées au Kerberoasting
• les modifications d'objets d'annuaire à fort impact, comme les écritures GPO ou de délégation
• l'activité d'émission de certificats pour les environnements avec ADCS
• les schémas de validation NTLM et d'ouverture de session réseau pour les investigations de relais ou de mouvement latéral

Ces détections créent une base utile sans noyer les analystes sous des alertes de faible qualité.

Revue de la rétention et de la couverture

La supervision Active Directory doit aussi inclure une revue de la rétention. Un contrôleur de domaine peut produire de gros volumes d'événements Kerberos, d'ouverture de session et de gestion de comptes, et un petit journal Security local peut écraser exactement les preuves nécessaires pendant une réponse à incident. Passez en revue ensemble la taille maximale du journal Security, la latence de transmission, les échecs d'ingestion SIEM et la rétention en stockage chaud. Si le SIEM conserve 90 jours de données consultables mais que le collecteur supprime silencieusement des Event ID à fort volume pendant les périodes chargées, la politique de rétention apparente n'est pas la couverture d'investigation réelle.

Pour les preuves Tier-0, définissez quels événements doivent rester consultables pendant toute la fenêtre de réponse. Les changements de groupes privilégiés, les modifications d'objets d'annuaire, l'émission de certificats, l'accès aux objets pertinent pour le DCSync et les événements Kerberos à forte valeur ne doivent pas être traités comme de la télémétrie de débogage jetable. Ce sont les preuves qui permettent aux défenseurs de reconstituer ce qui a changé, qui l'a changé, et si le même chemin a été réutilisé après remédiation.

Validation après les changements de politique d'audit

Après avoir modifié la politique d'audit, confirmez que la chaîne de supervision fonctionne de bout en bout :

• vérifiez que les événements attendus apparaissent sur les contrôleurs de domaine concernés
• confirmez que ces mêmes événements atteignent votre collecteur ou SIEM sans délai excessif ni pertes silencieuses
• testez au moins une action administrative contrôlée et une action Kerberos bénigne pour valider l'analyse et le mapping des champs
• passez en revue la rétention pour vous assurer que les preuves critiques sont toujours présentes quand les investigateurs en ont besoin
• confirmez que 4662 et 5136 incluent le contexte d'objet et d'attribut nécessaire aux investigations d'annuaire
• confirmez que 4769 inclut les informations de chiffrement et de service nécessaires aux investigations Kerberos
• confirmez que les événements AD CS sont présents si des services de certification existent dans l'environnement

Contrôles associés

Cet article se lit naturellement avec Sécurité des Mots de Passe Active Directory : Erreurs Critiques, Attaques NTLM Relay : Détection et Prévention, Mauvaises Configurations GPO : Vecteur d'Attaque AD, Comptes Obsolètes et Sur-Privilégiés : Le Risque Caché dans Active Directory, et Délégation Kerberos : Non Contrainte à RBCD. Une bonne supervision est ce qui permet aux équipes de prouver que ces problèmes ont été corrigés et de détecter s'ils réapparaissent.

Références principales

• Vue d'ensemble de la collecte d'événements pour Defender for Identity
• Configurer l'audit des événements Windows pour Defender for Identity
• 4662 : une opération a été effectuée sur un objet
• 4769 : un ticket de service Kerberos a été demandé
• 5136 : un objet du service d'annuaire a été modifié
• Audit de la gestion des groupes de sécurité