Lacunes de configuration de la politique d'audit Active Directory : les catégories que personne n'active avant d'avoir besoin des journaux

Que sont les lacunes de configuration de la politique d'audit Active Directory

La plupart des équipes Active Directory supposent que si le journal d'événements Security se remplit, l'environnement est « audité ». Ce n'est pas le cas — pas de la façon qui compte pour détecter une attaque. Les lacunes de configuration de la politique d'audit Active Directory sont les sous-catégories que Windows livre désactivées, à moitié configurées, ou silencieusement écrasées, si bien que les événements dont un investigateur aurait besoin plus tard n'ont jamais été générés. Windows organise ce qui est journalisé dans une Configuration Avancée de la Politique d'Audit composée de 10 catégories subdivisées en dizaines de sous-catégories — passées des 9 catégories de base d'origine à 53 sous-catégories granulaires à partir de Windows Vista et Windows Server 2008 (le nombre a encore augmenté depuis, les versions ultérieures de Windows ayant ajouté des sous-catégories comme Group Membership et PNP Activity), comme le décrit l'historique de Microsoft sur les politiques d'audit avancées de Windows Server. Chaque sous-catégorie est un interrupteur indépendant. Laissez-en une désactivée, et chaque événement qu'elle aurait généré n'existe tout simplement jamais — aucun log à consulter plus tard, aucune lacune à remarquer dans une revue d'incident, rien.

En pratique, quatre angles morts reviennent sans cesse dans les environnements AD dont la politique d'audit n'a jamais été délibérément revue, et qui correspondent directement à ce que recherchent nos vérifications d'audit de sécurité Active Directory :

• Account Management laissé aux valeurs par défaut de Windows au lieu d'être pleinement activé (succès et échec), si bien que les changements d'utilisateurs, d'ordinateurs et de groupes ne sont que partiellement, voire pas du tout, journalisés.
• Account Logon (la catégorie qui couvre réellement l'authentification Kerberos sur les contrôleurs de domaine) purement et simplement désactivée — celle-ci est désactivée par défaut, même sur les serveurs.
• Policy Change qui ne couvre pas les sous-catégories qui comptent au-delà de celle que Windows journalise déjà pour vous.
• Aucun compte honeypot ou leurre nulle part dans l'annuaire, donc aucun déclencheur à taux de faux positifs quasi nul pour l'énumération ou l'abus d'identifiants.

Chacune est mineure prise isolément. Ensemble, elles signifient que les catégories qui détecteraient la création de privilèges, l'abus d'identifiants et un attaquant effaçant ses traces sont précisément celles qui ont le moins de chances de journaliser quoi que ce soit. Ces lacunes s'ajoutent aux autres priorités de durcissement couvertes dans Durcir Active Directory : Que Verrouiller en Premier — la politique d'audit reçoit rarement la même attention que les ACL ou l'isolation du Tier 0, précisément parce qu'un log manquant ne s'annonce pas de lui-même. Contrairement à une ACL dangereuse ou un groupe sur-privilégié, une sous-catégorie d'audit désactivée ne produit aucun artefact sur lequel tomber lors d'une revue de routine — la seule façon de la détecter est d'aller vérifier directement la politique effective, sur le contrôleur de domaine, plutôt que de supposer que l'éditeur de GPO raconte toute l'histoire.

Comment Fonctionne Réellement la Politique d'Audit Windows — Et Où Elle Échoue Silencieusement

Microsoft publie un tableau de recommandations de référence précisément pour cette raison : la politique par défaut de Windows Server laisse plusieurs sous-catégories pertinentes pour l'identité désactivées, et seul un sous-ensemble des sous-catégories Account Management journalise les échecs par défaut. Deux valeurs par défaut ressortent spécifiquement pour AD :

• Audit Credential Validation (la sous-catégorie sous Account Logon qui gouverne la validation des mots de passe NTLM et Kerberos) est livrée en No | No — complètement désactivée — sur Windows Client comme sur Windows Server. La recommandation de référence de Microsoft la relève à Yes | Yes sur les serveurs (les contrôleurs de domaine dont il est question ici) et à Yes | No sur les clients, et les trois autres sous-catégories Account Logon (Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events) n'ont aucune valeur par défaut du tout.
• Audit Policy Change (sous Policy Change) est par défaut en Yes | No — succès uniquement. La référence Microsoft recommande Yes | Yes.

Ce deuxième point compte à cause d'un détail que Microsoft documente directement sur l'événement lui-même : l'Event ID 4719 (« System audit policy was changed ») « est toujours journalisé quel que soit le paramétrage de la sous-catégorie Audit Policy Change ». C'est rassurant pour cet événement que les admins connaissent généralement déjà — mais Authentication Policy Change et Authorization Policy Change sont des sous-catégories distinctes, activées indépendamment, au sein de la même catégorie Policy Change, et aucune des deux ne bénéficie de ce même laissez-passer gratuit. Si elles ne sont pas explicitement activées, un attaquant qui relâche discrètement les paramètres de délégation Kerberos ou une attribution de privilège ne laisse rien derrière lui.

Le Piège du Recouvrement Legacy-vs-Avancé

Il existe un second piège, plus opérationnel, et c'est la même catégorie de problème que les mauvaises configurations GPO qui transforment Group Policy en vecteur d'attaque : même quand une GPO active correctement une sous-catégorie avancée, ce paramètre peut être silencieusement écrasé par la Politique de Sécurité Locale héritée à 9 catégories, à moins que le domaine n'active aussi « Audit : forcer les paramètres de sous-catégorie de politique d'audit (Windows Vista ou ultérieur) à remplacer les paramètres de catégorie de politique d'audit » — la valeur de registre SCENoApplyLegacyAuditPolicy sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa, selon la documentation Microsoft pour cette politique. Sautez cette étape, et la GPMC peut afficher chaque sous-catégorie correctement configurée pendant que le contrôleur de domaine continue silencieusement d'appliquer l'ancienne politique au niveau catégorie à la place.

Cet article traite délibérément de la question de savoir si ces catégories sont même activées. Ce qu'il faut faire une fois qu'elles le sont — quels event IDs précis surveiller et comment construire la logique de détection — est couvert dans Supervision Active Directory : Les Event IDs de Sécurité qui Comptent.

Détection : Vérifier ce qui est Réellement Activé, Pas ce que la GPO Prétend

Vérifier la Politique Effective avec auditpol

Ne faites pas confiance à la seule Console de Gestion des Stratégies de Groupe. Exécutez auditpol directement sur un contrôleur de domaine pour voir la politique effective :

# Politique d'audit effective complète sur ce DC
auditpol /get /category:*

# Uniquement les catégories couvertes par cet article
auditpol /get /category:"Account Logon"
auditpol /get /category:"Account Management"
auditpol /get /category:"Policy Change"

# Confirmer que le paramètre GPO de recouvrement legacy a bien été appliqué
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name SCENoApplyLegacyAuditPolicy -ErrorAction SilentlyContinue

Si une sous-catégorie affiche « No Auditing », les événements du tableau ci-dessous ne sont pas générés sur cette machine — point final, rien à chasser plus tard :

Pourquoi un Compte Honeypot Referme la Boucle

Un honey user est un compte AD leurre sans privilège réel, placé de sorte que les outils d'énumération (BloodHound, password sprayers, scripts de Kerberoasting) le trouvent et l'essaient comme n'importe quelle autre cible. Comme un utilisateur ou service légitime ne le touche jamais, tout 4768/4769/4624 contre ce compte est un signal à quasiment 100 % de confiance — l'inverse du problème de fatigue d'alerte bruyante que les trois autres catégories peuvent créer une fois activées. Des leurres efficaces nécessitent des métadonnées et un placement réalistes, pas un nom évident comme honeypot-admin-01, selon les recommandations en matière de technologie de déception dans ce domaine. Le même principe sous-tend la détection de l'abus d'ACL et des chemins DCSync : une demande de réplication provenant d'un compte qui n'a aucune raison de répliquer est exactement le type de signal peu bruyant et à forte confiance que ces catégories d'audit existent pour révéler.

À vérifier également : les attaquants qui parviennent à désactiver la journalisation exécutent MITRE ATT&CK T1562.002 — Impair Defenses: Disable Windows Event Logging, une technique d'évasion défensive qui cible spécifiquement la politique d'audit couverte par cet article. Un environnement qui n'a jamais activé ces catégories en premier lieu offre à cette technique une victoire gratuite qu'elle n'aurait pas autrement.

Remédiation : Combler les Quatre Lacunes

Corriger d'Abord Account Logon et Account Management

1. Activez Account Logon intégralement, succès et échec, via Default Domain Controllers Policy → Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Account Logon : Credential Validation, Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events.
2. Alignez Account Management sur la référence Microsoft (succès et échec) pour User Account Management, Security Group Management, Computer Account Management et Other Account Management Events — pas seulement la valeur par défaut succès uniquement.

Compléter Policy Change et Verrouiller le Recouvrement GPO

3. Complétez Policy Change : activez Authentication Policy Change et Authorization Policy Change en plus de la sous-catégorie Audit Policy Change déjà partiellement activée, afin que la falsification de la politique Kerberos et des attributions de privilèges génère réellement des événements.
4. Configurez le recouvrement legacy de la GPO (« Audit : forcer les paramètres de sous-catégorie de politique d'audit... »), à l'échelle du domaine, puis relancez la vérification auditpol /get ci-dessus sur un DC après un gpupdate /force — vérifiez la politique effective, ne faites pas simplement confiance à l'éditeur de GPO.

Déployer un Compte Leurre et Alerter sur 4719

5. Déployez au moins un compte honeypot par domaine, avec des attributs et un placement de groupe réalistes, et alertez sur tout événement d'authentification le concernant.
6. Transférez tout ce qui précède vers un SIEM et alertez sans condition sur l'Event ID 4719 — la recommandation même de Microsoft est de traiter tout changement non planifié de la politique d'audit comme un déclencheur d'investigation prioritaire, puisque les attaquants désactivent l'audit spécifiquement pour opérer sans laisser de preuves.

Considérez ceci comme une vérification récurrente, pas un projet ponctuel : la reconstruction d'un contrôleur de domaine, une nouvelle GPO qui réinitialise le paramètre de recouvrement legacy, ou une migration vers une nouvelle forêt peuvent silencieusement réintroduire l'une de ces quatre lacunes, et aucune d'elles n'apparaîtra comme une alerte — elles apparaîtront simplement comme une absence, des mois plus tard, dans un incident où les logs dont vous aviez besoin n'ont jamais été écrits. Intégrer cette vérification dans un workflow d'audit AD récurrent est le seul moyen fiable de détecter la dérive avant qu'elle ne compte.

Comment EtcSec Détecte Cela

EtcSec vérifie les objets Group Policy Active Directory lors de chaque audit pour exactement ces lacunes : AUDIT_POLICY_WEAK signale les sous-catégories laissées en dessous de la référence Microsoft, DC_AUDIT_POLICY_INCOMPLETE signale les contrôleurs de domaine où la politique effective ne correspond pas à ce que la GPO prétend, ANSSI_R38_ADVANCED_AUDIT_NOT_ENABLED vérifie la conformité à la recommandation ANSSI R38 pour la couverture de la politique d'audit avancée, et NO_HONEYPOT_ACCOUNTS signale les annuaires sans aucun compte leurre nulle part dans le périmètre.