Audit et détection AD : stratégie d'audit et ID d'événements

Le durcissement de la configuration réduit la surface d'attaque, mais il ne rend pas les attaques contre Active Directory impossibles : il les rend plus difficiles et plus bruyantes. Plus bruyantes, cela n'a d'intérêt que si quelqu'un, ou quelque chose, écoute. La plupart des compromissions AD qui aboutissent à la prise de contrôle du domaine réussissent non pas parce que la détection était techniquement impossible, mais parce que la stratégie d'audit, les SACL et la chaîne de collecte nécessaires pour les voir n'ont jamais été activées. Cet article couvre la configuration concrète de la stratégie d'audit avancée, les ID d'événements qui comptent, les SACL sur les objets sensibles et la chaîne de collecte (WEF, Defender for Identity, honeytokens) pour passer de « nous avons des journaux » à « nous le remarquerions ».

Configurer la stratégie d'audit avancée par GPO

La stratégie d'audit héritée (les neuf catégories de base) est trop grossière. Utilisez la configuration de la stratégie d'audit avancée (Advanced Audit Policy Configuration), appliquée via une GPO liée à l'UO Domain Controllers :

Chemin de stratégie de groupe : Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies

Activez ces sous-catégories (succès et échec, sauf mention contraire) :

Appliquez et vérifiez :

# Appliquer la GPO, puis confirmer les paramètres effectifs sur un DC
auditpol /get /category:*

# Vérifier une sous-catégorie précise
auditpol /get /subcategory:"Directory Service Access"
auditpol /get /subcategory:"Kerberos Service Ticket Operations"

Si auditpol affiche « No Auditing » après une actualisation de la GPO, vérifiez que les paramètres d'audit des stratégies locales (Local Policies) de l'éditeur de stratégie de groupe locale ne remplacent pas la stratégie d'audit avancée : mélanger stratégie d'audit héritée et avancée sur une même machine provoque exactement ce symptôme. Positionnez Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings sur Enabled.

Les ID d'événements qui comptent le plus

La détection de DCSync mérite qu'on y insiste : elle n'apparaît pas sous la forme d'un événement « DCSync » distinct. Elle se manifeste par un événement 4662 portant les deux GUID de réplication ci-dessus, émis par un principal de sécurité qui n'est pas un compte ordinateur de contrôleur de domaine ni un compte de service de réplication désigné. Tout autre principal invoquant ces droits étendus est un indicateur fort d'identifiants volés utilisés pour se faire passer pour un contrôleur de domaine.

SACL sur les objets sensibles

Les événements 4662 et 5136 ne se déclenchent que là où une liste de contrôle d'accès système (SACL) est configurée sur l'objet. Appliquez des SACL, et pas seulement une stratégie d'audit, sur :

• L'objet domaine lui-même (DC=domain,DC=com) : indispensable pour détecter DCSync, puisque les droits de réplication sont évalués à la racine du domaine.
• AdminSDHolder (CN=AdminSDHolder,CN=System,DC=domain,DC=com).
• Les groupes privilégiés : Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators.
• Le compte krbtgt.
• Les GPO liées à l'UO Domain Controllers et à toutes les UO Tier 0.

Configurez-les via Paramètres de sécurité avancés > Audit sur l'objet, ou avec PowerShell :

$path = "AD:\DC=domain,DC=com"
$acl = Get-Acl $path
$sacl = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    [System.Security.Principal.SecurityIdentifier]"S-1-1-0",   # Tout le monde : filtrer ensuite dans le SIEM
    "WriteProperty,ExtendedRight",
    "Success",
    [guid]"1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"                # DS-Replication-Get-Changes
)
$acl.AddAuditRule($sacl)
Set-Acl -Path $path -AclObject $acl

Vérifiez la présence des SACL :

(Get-Acl "AD:\DC=domain,DC=com").Audit | Format-Table IdentityReference, ActiveDirectoryRights, AuditFlags

Windows Event Forwarding vers un collecteur

Les journaux d'événements locaux des contrôleurs de domaine ne constituent pas une preuve durable : un attaquant disposant des droits DA peut les effacer, et les journaux d'un seul DC donnent une image incomplète. Transférez-les vers un collecteur central :

1. Sur le collecteur : wecutil qc pour configurer le service Windows Event Collector.
2. Créez un abonnement (l'initiation par la source est la plus simple à grande échelle) ciblant les sous-catégories d'audit ci-dessus ; diffusez par GPO la valeur de registre SubscriptionManager qui pointe les DC vers le collecteur.
3. Sur les DC, assurez-vous que le service Windows Remote Management (WS-Management) est démarré et que le compte Network Service (utilisé par le service de transfert) peut lire le journal Security : ajoutez NT AUTHORITY\NETWORK SERVICE au groupe intégré Event Log Readers (à l'échelle du domaine sur les DC), ou étendez le SDDL d'accès du canal Security par stratégie de groupe.
4. Vérifiez la réception :

Get-WinEvent -LogName "ForwardedEvents" -MaxEvents 20 -ComputerName <collector>
wecutil gr <SubscriptionName>

Conservez les journaux transférés à un endroit d'où les administrateurs du domaine audité ne peuvent pas les supprimer : une couche distincte de gestion des journaux ou de SIEM, idéalement dans une frontière d'approbation/d'administration différente de celle des DC surveillés.

Microsoft Defender for Identity et honeytokens

Microsoft Defender for Identity déploie des capteurs sur les DC et les serveurs AD FS et corrèle la télémétrie réseau et les événements pour détecter la reconnaissance, l'utilisation de golden tickets, DCSync et les schémas de mouvement latéral, sans que vous ayez à construire chaque règle de détection à la main. C'est un complément solide, et non un substitut, à la stratégie d'audit et aux SACL ci-dessus, car Defender for Identity consomme lui-même la télémétrie ETW/d'audit locale du DC.

Comptes honeytoken : créez des comptes leurres sans aucun usage métier légitime, idéalement avec un nom ou un SPN attractif, aucune activité d'ouverture de session et un mot de passe d'apparence plausible (mais inutilisé), et déclenchez une alerte sur toute tentative d'authentification les visant. Defender for Identity permet nativement de marquer des comptes comme honeytokens ; sans lui, créez des alertes directement sur les événements 4768/4769/4624 dont le principal cible est le compte honeytoken. Une seule occurrence est un signal très fiable, puisqu'aucun processus légitime ne devrait jamais y toucher.

Ce que cela casse

Rien de fonctionnel : l'audit est passif. Le coût réel est le volume des journaux : activer largement l'audit Directory Service Access (4662), au lieu de limiter les SACL aux objets réellement sensibles, peut générer un volume d'événements énorme sur des DC chargés et saturer à la fois la rétention locale et votre collecteur WEF. Dimensionnez le stockage du collecteur et la capacité d'ingestion du SIEM à partir d'un pilote sur un sous-ensemble de DC avant de déployer la stratégie d'audit sur toute la forêt, et préférez des SACL ciblées à un « tout auditer ».

Une fois la détection en place, associez-la au durcissement des contrôleurs de domaine pour réduire ce que les attaquants peuvent faire avant que vous ne les voyiez, et à la sécurité des objets et des ACL pour réduire l'ensemble des objets dont la compromission est suffisamment grave pour justifier une SACL.