KomuraSoft LLC
Nous contacter
Menu

Politique d'audit de sécurité Windows et investigation des journaux d'événements — devenir capable de lire un 4625

· · Windows, Sécurité, Journal des événements, Politique d'audit, Conception des journaux, PowerShell, Systèmes d'information

« Depuis hier soir, un compte se verrouille sans arrêt. Peux-tu trouver la cause ? » « Je voudrais vérifier si quelqu’un a tenté de se connecter avec le compte d’un employé parti. » « Sur ce serveur, peut-on savoir qui a fait quoi, et quand ? » — ce sont des demandes que reçoivent, un jour ou l’autre et sans prévenir, les responsables informatiques de PME ou les développeurs qui livrent des systèmes chez leurs clients. Et la bouée de sauvetage, dans ces cas-là, c’est le journal d’événements Security de Windows.

Mais en ouvrant réellement l’Observateur d’événements, deux réalités attendent. Soit l’événement recherché n’a jamais été enregistré (la politique d’audit correspondante n’était pas activée), soit il est englouti sous un volume d’événements illisible (le journal a gonflé sous le bruit). L’audit de sécurité, une fois activé, enregistre bien les événements — mais sans une conception réfléchie de ce qu’il faut enregistrer et jusqu’où, il ne sert à rien le jour où l’on en a vraiment besoin.

Cet article détaille, sur la base des sources officielles à la date d’août 2026, le mécanisme de la politique d’audit (les deux systèmes, de base et avancé), les sous-catégories à activer au minimum dans un environnement de PME, la lecture des ID d’événement classiques comme 4624/4625/4740/4688, le dimensionnement du journal Security, et la façon d’investiguer avec PowerShell. Si les articles que nous avons publiés sur ce site — l’audit NTLM, la signature SMB, BitLocker, le pare-feu — traitaient de « renforcer les défenses », celui-ci porte sur « pouvoir vérifier après coup ce qui s’est passé » : c’est la suite qui relie ces sujets entre eux.

1. La conclusion, d’abord

  • Il existe deux systèmes de politique d’audit, « de base » et « avancé » (Advanced Audit Policy), et il ne faut jamais les mélanger. Microsoft précise clairement qu’utiliser les deux ensemble produit des résultats d’audit imprévisibles. Uniformisez-vous sur le système avancé (plus de 40 sous-catégories).1
  • Pour vérifier l’état actuel, utilisez auditpol /get /category:*. Peu importe que le paramètre provienne d’une GPO ou d’une configuration locale, cette commande liste tout ce qui est effectivement en vigueur.2
  • N’activez jamais « tout » d’un coup. Activer des sous-catégories qui génèrent un grand volume d’événements noie les événements réellement importants dans le bruit, avec en plus un impact sur les performances. Partez des recommandations de référence de Microsoft et n’ajoutez que ce qui est nécessaire.34
  • Une connexion réussie est 4624, un échec est 4625. Pour 4624, le type de connexion (2 = interactive, 3 = réseau, 10 = bureau à distance, etc.) permet de distinguer la nature de la connexion.5
  • Pour 4625, les codes Status/Sub Status indiquent la raison de l’échec. Les classiques : 0xC0000064 = nom d’utilisateur inexistant, 0xC000006A = mot de passe erroné, 0xC0000072 = compte désactivé, 0xC0000234 = compte verrouillé.6
  • L’endroit où un événement est enregistré est déterminé à l’avance. 4624/4625 sont enregistrés sur la machine accédée, tandis que la validation des informations d’identification (4776) et l’échec de préauthentification Kerberos (4771) sont enregistrés sur le contrôleur de domaine. Se tromper de machine à consulter fait diagnostiquer à tort « il n’y a pas de journal ».678
  • La conception du contenant du journal Security (taille maximale et rétention) représente la moitié du travail. En mode d’écrasement, les anciens événements disparaissent au fur et à mesure. Vérifiez la taille maximale et le nombre d’entrées avec Get-WinEvent -ListLog Security, puis dimensionnez en fonction du nombre de jours de rétention nécessaire.910
  • L’enregistrement de la ligne de commande pour la création de processus (4688) est puissant, mais au prix du risque de voir des secrets apparaître en clair dans le journal. Vérifiez vos scripts avant de l’activer.1112

2. Les fondamentaux de la politique d’audit — ne pas mélanger « de base » et « avancé »

La politique d’audit de Windows se décline en deux systèmes.1

  • Politique d’audit de base : les 9 paramètres de catégorie situés dans « Stratégies locales > Stratégie d’audit ». C’est l’ancien système, antérieur à Windows Vista.
  • Politique d’audit avancée (Advanced Audit Policy Configuration) : plus de 40 paramètres de sous-catégorie situés dans « Paramètres de sécurité > Configuration avancée de la stratégie d’audit ». Chaque catégorie de base y est décomposée en plusieurs sous-catégories : par exemple, une seule catégorie de base « Auditer les événements de connexion aux comptes » correspond à quatre sous-catégories côté avancé. Activer une catégorie côté base équivaut à activer toutes les sous-catégories correspondantes, ce qui enregistre en masse même des événements sans intérêt.1

Ce qui compte, c’est que ces deux systèmes ne sont pas compatibles entre eux. Microsoft précise clairement : « n’utilisez pas à la fois le système de base et le système avancé, les résultats d’audit deviendraient imprévisibles ». Lorsqu’une stratégie de groupe applique la politique d’audit avancée, les paramètres d’audit existants de cet ordinateur sont d’abord effacés avant que les paramètres avancés ne s’appliquent, et par la suite, seul le système avancé permet un contrôle fiable. Dans un environnement qui utilise le système avancé, activez l’option de sécurité « Audit : forcer les paramètres de sous-catégorie de la stratégie d’audit » pour empêcher les paramètres du système de base de venir écraser les vôtres (elle est activée par défaut sur les machines autonomes).14

Vérifier l’état actuel tient en une seule commande, à exécuter dans une invite de commandes administrateur.2

rem Liste, sous-catégorie par sous-catégorie, les paramètres d'audit actuellement en vigueur
auditpol /get /category:*

rem Sauvegarde avant modification (CSV) et restauration
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

La sortie d’auditpol reflète « la politique effectivement en vigueur », qu’elle provienne d’une GPO ou d’un paramètre local. Elle sert aussi à recouper le cas où un paramètre censé être distribué par GPO ne s’applique pas. Notez que toute modification de la configuration d’audit elle-même enregistre l’événement 4719, ce qui permet de retracer après coup un cas de « l’audit s’est retrouvé désactivé sans qu’on s’en aperçoive ».12

3. Le tableau de décision des sous-catégories à activer au minimum

La raison pour laquelle « activer tout par précaution » est une mauvaise idée est claire. Par exemple, auditer jusqu’au succès les sous-catégories liées à l’utilisation des privilèges fait exploser le volume d’événements, ce qui rend difficile la recherche d’autres entrées et affecte aussi les performances, avertit Microsoft.4 Le contenant du journal (chapitre 5) étant de taille finie, plus on enregistre de bruit, plus le nombre de jours de rétention des événements réellement nécessaires se réduit. Concevoir l’audit, c’est décider ce qu’on ne va pas enregistrer.

Microsoft publie des recommandations de référence et des recommandations renforcées, séparément pour les postes de travail et les serveurs ; c’est le point de départ.3 Le tableau suivant organise cela du point de vue d’un environnement de PME : « qu’est-ce qu’il faut absolument pouvoir lire en cas d’incident ? ».

Sous-catégorie (catégorie) ID d’événement principaux Ce qu’on peut savoir Recommandation pour une PME
Connexion (Connexion/Déconnexion) 4624 / 4625 Succès/échec de connexion, type de connexion, origine Succès + échec. À partir de Windows 10 1809, succès et échec sont déjà activés par défaut3
Connexion spéciale (idem) 4672 / 4964 Occurrence d’une connexion avec privilèges administrateur Succès
Verrouillage de compte (idem) 4625 Échec de connexion sur un compte en cours de verrouillage Échec (4625 est un événement d’échec ; il n’existe pas d’événement de succès pour cette sous-catégorie)13
Gestion des comptes d’utilisateurs (Gestion des comptes) 4720 / 4726 / 4738 / 4740 Création, suppression, modification, verrouillage de comptes Succès + échec
Gestion des groupes de sécurité (idem) 4728 / 4732 / 4756 (ajout), 4729 / 4733 / 4757 (retrait) Ajout/retrait de membre dans un groupe administrateur ou autre (global/local/universel) Succès (il n’existe pas d’événement d’échec pour cette sous-catégorie)14
Validation des informations d’identification (Connexion aux comptes) 4776 Succès/échec de l’authentification NTLM. Les comptes de domaine sont enregistrés côté DC7 Succès + échec
Service d’authentification Kerberos (idem, DC uniquement) 4768 / 4771 Émission de TGT et échec de préauthentification (mot de passe erroné, etc.)8 Succès + échec sur le DC
Création de processus (Suivi détaillé) 4688 Qui a lancé quoi, à partir de quel processus parent Succès. Lisez l’avertissement du chapitre 7 avant d’activer l’enregistrement de la ligne de commande
Autres événements d’accès aux objets (Accès aux objets) 4698 Création d’une tâche planifiée (technique classique de persistance d’une attaque)15 Envisager le succès
Modification de la stratégie d’audit (Modification de stratégie) 4719 Modification de la configuration d’audit elle-même Succès + échec

À l’inverse, il est plus prudent de ne pas toucher, par défaut, à l’audit d’accès aux objets du système de fichiers ou du registre, à l’utilisation des privilèges, ou aux événements de type filtre de paquets (5152, etc.). Ces catégories ne sont utiles qu’avec une SACL ciblée sur des objets précis, ou pendant une période d’investigation limitée dans le temps ; les laisser en permanence à plein régime dévore le journal.4

4. Comment lire les ID d’événement classiques

4.1. 4624 — distinguer une connexion réussie par le type de connexion

4624 signifie « le compte s’est connecté avec succès », et il est enregistré sur la machine où la session de connexion a été créée (celle qui a été accédée).5 Comme il s’agit d’un événement très fréquent, la première chose à faire pour le lire, c’est de le trier par type de connexion.5

Type de connexion Nom Signification en pratique
2 Interactive Connexion à la console de ce PC
3 Network Accès via le réseau (dossier partagé, outil d’administration, etc.). Le plus fréquent, car il apparaît autant de fois qu’il y a de postes
4 Batch Exécution par lots (tâche planifiée, etc.)
5 Service Démarrage d’un service (gestionnaire de contrôle des services)
7 Unlock Déverrouillage de l’écran
8 NetworkCleartext Connexion réseau où le mot de passe a été transmis en clair au package d’authentification
9 NewCredentials Duplication avec des informations d’identification différentes (équivalent de runas /netonly)
10 RemoteInteractive Bureau à distance
11 CachedInteractive Connexion avec des informations d’identification mises en cache (impossible de joindre le DC)

Les champs à examiner en parallèle sont le nom de compte sous « Nouvelle connexion », l’adresse d’origine sous « Informations réseau », le « package d’authentification » (NTLM ou Kerberos), et le « jeton élevé » (session avec privilèges administrateur ou non). Pour ne suivre que les connexions avec privilèges administrateur, on peut aussi utiliser 4672 (attribution de privilèges spéciaux), enregistré avec le même identifiant de connexion.5

4.2. 4625 — déterminer la raison de l’échec par les codes Status/Sub Status

4625 signifie « le compte a échoué à se connecter », et il est enregistré sur la machine où la connexion a été tentée.6 Pour être sûr, mieux vaut lire le code hexadécimal Status/Sub Status que le libellé du champ « Raison de l’échec ». Voici les classiques.6

  • 0xC0000064 : nom d’utilisateur inexistant. Une série rapprochée dans un court laps de temps est un signe d’attaque par énumération de comptes
  • 0xC000006A : mot de passe erroné. Une série rapprochée sur un même compte est un signe d’attaque par devinette de mot de passe
  • 0xC000006D : nom d’utilisateur ou informations d’authentification incorrects
  • 0xC000006F : en dehors de la plage horaire autorisée
  • 0xC0000070 : depuis un poste de travail non autorisé
  • 0xC0000072 : compte désactivé par un administrateur (les tentatives sur un compte d’employé parti apparaissent ici)
  • 0xC000015B : le type de connexion demandé n’est pas autorisé sur cette machine
  • 0xC0000193 : compte expiré
  • 0xC0000234 : compte en cours de verrouillage

« Qui, depuis où, et pourquoi l’échec » se détermine avec ce trio : le compte visé, l’origine (nom de poste de travail/adresse IP) et ce code. Le chapitre 6 propose un script PowerShell pour extraire ces trois informations en une seule fois.

4.3. 4740 — l’origine d’un verrouillage se trouve dans le « nom de l’ordinateur appelant »

4740 signifie « le compte d’utilisateur a été verrouillé » (sous-catégorie : gestion des comptes d’utilisateurs). Le champ clé de cet événement est « Nom de l’ordinateur appelant » (Caller Computer Name) : il enregistre de quel ordinateur provenait la tentative de connexion qui a déclenché le verrouillage.16 Le réflexe standard consiste à identifier ce poste d’origine, puis à rechercher sur ce poste les informations d’identification obsolètes qui y traînent. La cause est presque toujours quelque chose qui continue d’utiliser d’anciennes informations d’identification après un changement de mot de passe (informations d’identification enregistrées, session de bureau à distance restée déconnectée, service ou tâche planifiée configuré avec un ancien mot de passe).

Une précaution : 4625 est enregistré sur l’ordinateur qui a reçu la tentative de connexion. Si la cause est une connexion réseau depuis le poste d’origine vers un serveur de fichiers par exemple, le journal Security du poste d’origine lui-même ne contiendra aucun 4625 ; la trace se trouvera plutôt dans le 4625 du serveur accédé, ou, pour un compte de domaine, dans le 4776 (NTLM) / 4771 (échec de préauthentification Kerberos) côté DC.78 Quand « rien n’apparaît dans le journal du poste d’origine », allez regarder du côté de celui qui a reçu la tentative.

4.4. La série 4720 — création, modification de compte et ajout à un groupe

Les événements de gestion des comptes forment une série numérotée : 4720 (création d’un compte utilisateur)17, 4726 (suppression), 4738 (modification), et les ajouts/retraits de membres côté groupe. Attention : pour les changements de membres d’un groupe, l’ID d’événement dépend du type de groupe. Les groupes locaux utilisent 4732/4733, les groupes globaux 4728/4729, les groupes universels 4756/4757.14 Domain Admins étant un groupe global, un ajout à ce groupe est enregistré en 4728 — si vous ne surveillez que 4732, vous manquerez précisément l’événement le plus important à voir. Au quotidien, ce sont des traces d’opérations de support technique, mais « un utilisateur standard soudainement ajouté à un groupe administrateur » ou « un compte inconnu de tous vient d’être créé » doit déclencher une investigation immédiate, même pour une occurrence unique. Microsoft cite d’ailleurs l’ajout inattendu d’un membre à un groupe à privilèges comme exemple d’événement à alerter dès la première occurrence.3

4.5. 4688 — création de processus, l’enregistrement de la ligne de commande est un interrupteur séparé

4688 signifie « un nouveau processus a été créé » ; à chaque création de processus, il enregistre le compte créateur, le chemin de l’exécutable du nouveau processus, le processus parent et le type d’élévation de jeton.11 C’est un événement d’une grande valeur d’investigation, capable de répondre à « qui a exécuté quoi sur ce serveur ».

Cependant, les arguments de ligne de commande ne sont pas enregistrés par défaut. Il faut activer séparément la stratégie de groupe « Inclure la ligne de commande dans les événements de création de processus » (Modèles d’administration > Système > Audit de la création de processus) pour que le champ « Ligne de commande du processus » de 4688 contienne les arguments.1112 C’est un paramètre pratiquement indispensable pour suivre des lancements suspects du type powershell -EncodedCommand ..., mais activez-le seulement après avoir compris le risque de fuite de secrets décrit au chapitre 7.

4.6. 4698 — création d’une tâche planifiée

4698 signifie « une tâche planifiée a été créée » ; il enregistre le nom de la tâche et le XML complet de la définition de tâche (y compris la commande exécutée). Comme l’enregistrement d’une tâche planifiée est un moyen classique pour un logiciel malveillant de survivre à un redémarrage, Microsoft recommande de surveiller les événements de création de tâche.15 Même dans un environnement qui utilise beaucoup les tâches planifiées pour le travail quotidien, une création n’est pas un événement quotidien, donc le bruit reste limité.

Un autre événement à retenir est 1102, « le journal d’audit a été effacé ». L’effacement du journal Security laisse toujours cet événement, ce qui permet de distinguer un incident d’une manipulation volontaire quand « le journal est vide ».18

5. La conception du contenant du journal — taille maximale et rétention

Avant d’ajouter des politiques d’audit, vérifiez le contenant qui va les recevoir. Le journal Security possède une taille maximale et un mode de rétention : en mode d’écrasement (la configuration par défaut), une fois la taille maximale atteinte, les nouveaux événements écrasent les plus anciens. À l’inverse, en mode de rétention (sans écrasement), quand le journal est plein, ce sont les nouveaux événements qui sont rejetés.10 Les deux comportements peuvent produire un « je m’aperçois qu’il n’y a plus de journal », donc commencez par vérifier l’état actuel.

# Vérifier le contenant du journal Security : mode de rétention, taille maximale, nombre d'entrées actuel
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# Combien de jours sont réellement conservés en ce moment (date de l'événement le plus ancien)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog renvoie d’un coup la configuration et le nombre d’entrées du journal.9 L’écart entre « la date de l’événement le plus ancien » et la date actuelle donne le nombre de jours réellement conservés ; si cela ne suffit pas au besoin de votre organisation (le nombre de jours voulu pour remonter en cas d’incident), augmentez la taille maximale. Ce paramètre se configure avec wevtutil sl Security /ms:<nombre d'octets> ou par stratégie de groupe.10

Notez qu’il existe, dans les options de sécurité, un paramètre appelé « Audit : arrêter immédiatement le système s’il n’est pas possible de journaliser les audits de sécurité » (couramment appelé CrashOnAuditFail). Si l’audit ne peut plus être enregistré alors que ce paramètre est actif, le système s’arrête avec l’erreur STOP C0000244. C’est un paramètre destiné à des exigences d’authentification où la perte de la piste d’audit est absolument inacceptable, désactivé par défaut. Microsoft avertit lui-même qu’un attaquant pourrait le détourner en DoS en générant volontairement un flot d’événements pour arrêter le serveur : ce n’est pas un paramètre à activer à la légère dans un environnement de PME classique.19

6. La pratique de l’investigation — filtres, Get-WinEvent, export

6.1. Filtrer avec l’Observateur d’événements

Pour une investigation ponctuelle, l’Observateur d’événements suffit. Ouvrez le journal Security, puis indiquez un ID d’événement (par exemple 4625) et une période via « Filtrer le journal actuel ». Pour une condition que vous consultez régulièrement, enregistrez-la via « Créer une vue personnalisée » : ce sera un clic la prochaine fois. Si vous voulez filtrer non seulement par ID d’événement mais aussi par compte particulier, l’onglet XML de la boîte de dialogue de filtre permet d’éditer directement une requête XPath.

6.2. Extraire avec Get-WinEvent

Pour une investigation portant sur un grand nombre d’entrées, plusieurs conditions, ou une exécution régulière, basculez vers Get-WinEvent de PowerShell. Le point clé est d’utiliser -FilterHashtable, qui applique le filtre côté serveur.9

# Récupérer les échecs de connexion (4625) des dernières 24 heures
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# Mettre en forme « qui, depuis où, pourquoi » sous forme de tableau
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Garder sous la main ce modèle qui extrait EventData depuis la représentation XML de l’événement permet de le réutiliser tel quel pour 4624 comme pour 4688. La conception des filtres de Get-WinEvent (le choix entre FilterHashtable et XPath, comment corriger une requête lente) est détaillée dans « Investiguer efficacement les journaux d’événements avec Get-WinEvent ».

6.3. Exporter avec wevtutil

Le principe, pour le journal d’une machine à investiguer, est de commencer par l’exporter pour le mettre en sécurité, avant qu’il ne disparaisse par écrasement.10

rem Sauvegarder tout le journal Security au format evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem N'exporter que les 4625, filtrés par XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

Le fichier .evtx exporté peut être analysé de la même façon sur une autre machine, avec Get-WinEvent -Path C:\logs\security-20260801.evtx.9 L’habitude de sécuriser d’abord et d’analyser ensuite relève de la même logique que « d’abord récupérer le dump » en investigation de plantage (voir « Introduction à la collecte des dumps de plantage Windows »).

7. Les pièges — quatre erreurs fréquentes sur le terrain

(1) Des secrets se retrouvent dans la ligne de commande de 4688. Activer l’enregistrement de la ligne de commande fait entrer les arguments de tous les processus dans le journal Security, en clair. Microsoft précise explicitement que « tout utilisateur ayant un accès en lecture aux événements de sécurité peut lire les arguments de ligne de commande de n’importe quel processus, et ces arguments peuvent contenir des secrets tels que des mots de passe ».12 Si un seul de vos scripts ou de vos applications métier lance quelque chose comme myapp.exe /user:admin /password:P@ssw0rd, c’est une divulgation de secret à tous ceux qui peuvent consulter le journal. Avant d’activer ce paramètre, recensez et corrigez tous les endroits où un secret est passé en argument de ligne de commande. Le même niveau de protection doit s’appliquer à l’endroit où le journal est conservé ou transféré.

(2) Exploiter le journal sans connaître son comportement une fois plein. En mode d’écrasement, les anciennes traces disparaissent silencieusement ; en mode sans écrasement, ce sont les nouveaux événements qui sont rejetés ; si CrashOnAuditFail est actif, c’est le système entier qui s’arrête (chapitre 5).1019 La bonne pratique consiste à savoir précisément quel comportement est en place, et à mettre en place un mécanisme de « collecte avant disparition » (export régulier ou plateforme de centralisation des journaux).

(3) Le journal à consulter n’est pas le même sur un contrôleur de domaine et sur un poste. 4624/4625 sont enregistrés sur la machine accédée.56 En revanche, la validation des informations d’identification d’un compte de domaine (4776 pour NTLM) est enregistrée sur la machine qui fait autorité sur ces informations d’identification, c’est-à-dire le DC pour un compte de domaine7, et l’échec de préauthentification Kerberos (4771) n’est enregistré que sur le DC.8 « Pas de 4625 sur le serveur de fichiers » ne veut pas dire « pas d’attaque » : ce n’est qu’en recoupant aussi les 4776/4771 côté DC que l’on obtient une vue d’ensemble. Pour comprendre comment circule chaque protocole d’authentification, voir « NTLM et Kerberos expliqués en schémas ».

(4) Sans synchronisation horaire, impossible de recouper. Aligner les journaux de plusieurs machines pour retracer « quel poste a émis un 4625 juste avant ce 4740 » suppose que les horloges de chaque machine sont synchronisées. Dans un environnement de domaine, Kerberos lui-même impose une limite à l’écart d’horloge toléré (5 minutes par défaut) ; au-delà, l’authentification elle-même commence à échouer.20 Du point de vue de l’investigation, même un écart de quelques secondes — sans même parler de 5 minutes — peut faire mal interpréter l’ordre chronologique des événements ; placez donc la vérification de l’état de synchronisation de w32time en tout premier dans votre procédure d’investigation. Par ailleurs, l’heure d’enregistrement d’un événement est stockée en UTC et affichée selon le fuseau horaire de la machine de consultation : en lisant un fichier .evtx rapatrié d’une filiale à l’étranger ou d’un serveur configuré en UTC, n’oubliez pas de reconvertir le fuseau horaire.

8. Conclusion

  • La politique d’audit se décline en deux systèmes, « de base » et « avancé » ; les mélanger produit des résultats imprévisibles. Uniformisez-vous sur le système avancé, vérifiez l’état actuel avec auditpol /get /category:*, puis concevez à partir de là.
  • « Tout activer » tue l’investigation par le bruit et le gonflement du journal. Partez des recommandations de référence de Microsoft, et commencez par le tableau de décision du chapitre 3, centré sur la connexion, la gestion des comptes et la création de processus.
  • 4624 se lit par le type de connexion, 4625 par les codes Status/Sub Status, 4740 par le nom de l’ordinateur appelant, 4688 par le processus parent et la ligne de commande — chaque événement a son point clé à examiner.
  • Le contenant du journal (taille maximale, mode de rétention) représente la moitié de la conception de l’audit. Vérifiez le nombre de jours réellement conservés, dimensionnez en fonction du besoin, et exportez ou centralisez avant que ça ne disparaisse.
  • N’activez l’enregistrement de la ligne de commande de 4688 qu’après avoir vérifié le risque de fuite de secrets. La différence de machine où chaque événement est enregistré et la synchronisation horaire sont des prérequis à toute investigation de recoupement.
  • Commencez l’investigation par les filtres de l’Observateur d’événements ; passez à Get-WinEvent -FilterHashtable pour ce qui se répète ; sécurisez avec wevtutil epl. Ne renversez jamais l’ordre : d’abord sécuriser, ensuite analyser.

Articles connexes

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge le conseil sur la politique d’audit et la conception des journaux dans un environnement Windows, l’investigation de « qui a fait quoi, et quand » à partir des journaux d’événements, et l’analyse des causes d’incidents que rencontrent les applications métier autour de l’authentification et de l’audit. Vous pouvez nous solliciter même au stade de « on m’a demandé de regarder les journaux, mais je ne sais pas par où commencer ».

Références

  1. Microsoft Learn, Advanced security auditing FAQ. Sur la différence entre la politique d’audit de base (9 paramètres sous les stratégies locales) et la politique d’audit avancée, sur le fait qu’activer une catégorie côté base équivaut à activer toutes les sous-catégories correspondantes, sur l’incompatibilité entre les deux qui rend les résultats d’audit imprévisibles en cas d’utilisation combinée, sur le fait qu’appliquer le système avancé par stratégie de groupe efface les paramètres d’audit existants, sur la nécessité d’activer « Audit : forcer les paramètres de sous-catégorie de la stratégie d’audit », et sur le fait que minimiser le volume d’événements passe par l’identification des ressources, activités et utilisateurs importants à cibler. ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, auditpol. Sur le fait que la commande auditpol permet d’afficher (/get), de définir (/set), de sauvegarder en CSV (/backup), de restaurer (/restore) et d’effacer (/clear) la politique d’audit système. ↩ ↩2

  3. Microsoft Learn, System Audit Policy recommendations. Sur le tableau des valeurs par défaut de Windows, des recommandations de référence et des recommandations renforcées, séparément pour les postes de travail et les serveurs, sur le fait que ces recommandations ne sont qu’un point de départ que chaque organisation doit examiner et tester selon ses menaces et sa tolérance au risque, sur le fait que la sous-catégorie de connexion est déjà activée par défaut en succès et en échec à partir de Windows 10 1809, sur l’importance de surveiller aussi les postes de travail et pas seulement les serveurs, sur des exemples d’événements à alerter dès la première occurrence comme l’ajout inattendu d’un membre à un groupe à privilèges, et sur l’approche consistant à détecter une hausse soudaine des échecs de connexion par comparaison à une base de référence. ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings. Sur la possibilité d’une gestion fine avec plus de 40 sous-catégories d’audit, sur le fait que laisser ce paramètre activé est une bonne pratique, avec une valeur par défaut Activé sur les postes clients, serveurs membres et DC, et sur l’avertissement selon lequel un paramètre générant un grand volume d’événements, comme l’activation complète de la sous-catégorie d’utilisation des privilèges, rend difficile de trouver d’autres entrées dans le journal de sécurité et peut avoir un impact important sur les performances. ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, 4624(S): An account was successfully logged on. Sur le fait que 4624 est enregistré sur l’ordinateur accédé lors de la création d’une session de connexion, sur la liste des types de connexion (2=Interactive, 3=Network, 4=Batch, 5=Service, 7=Unlock, 8=NetworkCleartext, 9=NewCredentials, 10=RemoteInteractive, 11=CachedInteractive), sur l’indicateur de jeton élevé (Elevated Token), sur le package d’authentification (NTLM/Kerberos/Negotiate) et le Package Name de NTLM (NTLM V1/V2/LM), et sur la corrélation avec des événements comme 4672 via l’identifiant de connexion. ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, 4625(F): An account failed to log on. Sur le fait que 4625 est enregistré sur l’ordinateur où la tentative de connexion a eu lieu (le poste lui-même en cas de tentative sur un poste utilisateur), sur le fait que ses sous-catégories sont Verrouillage de compte et Connexion, sur la signification des codes Status/Sub Status (0xC0000064=nom d’utilisateur invalide, 0xC000006A=mot de passe erroné, 0xC000006D=nom d’utilisateur ou informations d’authentification incorrects, 0xC000006F=en dehors de la plage horaire autorisée, 0xC0000070=poste de travail non autorisé, 0xC0000072=compte désactivé, 0xC000015B=type de connexion non autorisé, 0xC0000193=compte expiré, 0xC0000234=verrouillage), et sur le fait qu’une série de 0xC0000064 peut être le signe d’une attaque par énumération de comptes. ↩ ↩2 ↩3 ↩4 ↩5

  7. Microsoft Learn, 4776(S, F): The computer attempted to validate the credentials for an account. Sur le fait que 4776 est enregistré à chaque validation d’informations d’identification via l’authentification NTLM, sur le fait qu’il n’est enregistré que sur l’ordinateur faisant autorité sur ces informations d’identification (le contrôleur de domaine pour un compte de domaine, l’ordinateur local pour un compte local), et sur le fait que les succès comme les échecs y sont enregistrés. ↩ ↩2 ↩3 ↩4

  8. Microsoft Learn, 4771(F): Kerberos pre-authentication failed. Sur le fait que 4771 est enregistré à chaque échec d’émission d’un TGT Kerberos par le KDC (mot de passe erroné, expiration, etc.), et sur le fait que cet événement n’est généré que sur un contrôleur de domaine. ↩ ↩2 ↩3 ↩4

  9. Microsoft Learn, Get-WinEvent (Microsoft.PowerShell.Diagnostics). Sur l’obtention de la configuration du journal (LogMode, MaximumSizeInBytes, RecordCount) via -ListLog, sur le filtrage efficace via une table de hachage LogName/Id/StartTime etc. avec -FilterHashtable, sur la lecture d’un fichier .evtx enregistré via -Path, et sur la récupération des événements les plus anciens ou d’un nombre donné via -Oldest / -MaxEvents. ↩ ↩2 ↩3 ↩4

  10. Microsoft Learn, wevtutil. Sur la définition, via set-log (sl), de la taille maximale (/ms) et du mode de rétention (/rt), sur le fait qu’un mode de rétention à true conserve les événements existants et rejette les nouveaux une fois le journal plein, qu’à false les nouveaux événements écrasent les plus anciens, sur l’export d’un journal d’événements vers un fichier via export-log (epl) et le filtrage par requête XPath avec l’option /q, et sur l’exécution de requêtes via query-events (qe). ↩ ↩2 ↩3 ↩4 ↩5

  11. Microsoft Learn, 4688(S): A new process has been created. Sur le fait que 4688 est enregistré à chaque démarrage d’un nouveau processus, sur les informations incluses (compte créateur, chemin de l’exécutable du nouveau processus, nom du processus créateur/parent, type d’élévation de jeton), et sur le fait que le champ Process Command Line est vide par défaut et n’est renseigné qu’après activation de la stratégie de groupe « Inclure la ligne de commande dans les événements de création de processus ». ↩ ↩2 ↩3

  12. Microsoft Learn, Command line process auditing. Sur le fait que l’enregistrement de la ligne de commande nécessite à la fois l’audit de création de processus de la politique d’audit avancée et le paramètre « Inclure la ligne de commande dans les événements de création de processus » (Modèles d’administration > Système > Audit de la création de processus, non configuré par défaut), sur l’avertissement selon lequel l’activation enregistre en clair les informations de ligne de commande de tous les processus dans le journal des événements de sécurité, tout utilisateur ayant un accès en lecture pouvant alors lire des arguments contenant potentiellement des secrets comme des mots de passe, et sur le fait qu’un écrasement de la politique d’audit avancée par la configuration de base enregistre l’événement 4719, ce que le paramètre « forcer » permet d’éviter. ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn, Audit Account Lockout. Sur le fait que la sous-catégorie Verrouillage de compte audite les échecs de connexion sur un compte en cours de verrouillage, que l’événement généré est 4625(F), qu’il n’existe pas d’événement de succès pour cette sous-catégorie et qu’activer l’audit de succès n’a donc pas de sens, et sur le fait que l’audit des échecs est recommandé pour tous les types d’ordinateur. ↩

  14. Microsoft Learn, Audit Security Group Management. Sur le fait que cette sous-catégorie audite la création, la modification, la suppression de groupes de sécurité ainsi que l’ajout et le retrait de membres, sur le fait que les ID d’événement pour l’ajout/retrait de membre diffèrent selon le type de groupe (4732/4733 pour un groupe local, 4728/4729 pour un groupe global, 4756/4757 pour un groupe universel), sur l’existence d’événements propres aux groupes de domaine comme 4728, et sur le fait qu’il n’existe pas d’événement d’échec pour cette sous-catégorie, l’audit des succès étant recommandé pour tous les types d’ordinateur. ↩ ↩2

  15. Microsoft Learn, 4698(S): A scheduled task was created. Sur le fait que 4698 est enregistré à chaque création d’une tâche planifiée, sur le fait que sa sous-catégorie est Autres événements d’accès aux objets, sur le fait que le XML complet de la définition de tâche, incluant la commande exécutée, y est enregistré, et sur le fait que, les logiciels malveillants utilisant couramment les tâches planifiées pour persister après un redémarrage, la surveillance des événements de création de tâche est recommandée, en particulier sur les machines importantes. ↩ ↩2

  16. Microsoft Learn, 4740(S): A user account was locked out. Sur le fait que 4740 est enregistré à chaque verrouillage d’un compte utilisateur, sur le fait que sa sous-catégorie est Gestion des comptes d’utilisateurs, et sur le fait que le champ Caller Computer Name enregistre le nom de l’ordinateur d’origine de la tentative de connexion ayant provoqué le verrouillage. ↩

  17. Microsoft Learn, 4720(S): A user account was created. Sur le fait que 4720 est enregistré à chaque création d’un nouvel objet utilisateur, sur un contrôleur de domaine, un serveur membre ou un poste de travail, et sur le fait que sa sous-catégorie est Gestion des comptes d’utilisateurs. ↩

  18. Microsoft Learn, 1102(S): The audit log was cleared. Sur le fait que l’événement 1102 est enregistré à chaque effacement du journal d’audit de sécurité Windows. ↩

  19. Microsoft Learn, Audit: Shut down system immediately if unable to log security audits. Sur le fait que, lorsque ce paramètre est actif, l’impossibilité d’enregistrer un audit de sécurité arrête le système avec le message STOP C0000244 {Audit Failed}, sur le fait que sa valeur par défaut est Désactivé, sur le fait qu’il peut être détourné en DoS en générant volontairement un grand nombre d’événements de sécurité pour forcer l’arrêt, et sur le risque que des données d’application deviennent inutilisables à la suite d’un arrêt soudain. ↩ ↩2

  20. Microsoft Learn, Maximum tolerance for computer clock synchronization. Sur le fait que Kerberos v5 utilise des horodatages comme mesure anti-rejeu, ce qui impose un écart d’horloge maximal toléré entre le client et le contrôleur de domaine (5 minutes par défaut et recommandé), au-delà duquel l’horodatage n’est plus considéré comme authentique. ↩

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Je n'ai configuré aucune politique d'audit, pourtant le journal Security contient déjà des 4624 et des 4625 : pourquoi ?
Parce que Windows a des sous-catégories d'audit activées par défaut. Par exemple, la sous-catégorie « Connexion » a le succès et l'échec activés par défaut à partir de Windows 10 version 1809, donc 4624 (succès) et 4625 (échec) sont enregistrés même sans aucune configuration. Cela dit, en restant sur les paramètres par défaut, de nombreux événements utiles à l'investigation, comme la validation des informations d'identification (4776) ou la création de processus (4688), ne sont pas enregistrés. Vous pouvez vérifier ce qui est activé dans votre environnement avec auditpol /get /category:*. À partir de là, la pratique standard consiste à activer explicitement, côté politique d'audit avancée, les sous-catégories manquantes.
Je veux enquêter sur un échec de connexion, mais je ne trouve pas de 4625 dans le journal Security du serveur visé. Où dois-je regarder ?
Commencez par vérifier ce principe : 4625 est enregistré sur « l'ordinateur où la connexion a été tentée ». Pour un échec de connexion sur le poste d'un utilisateur, c'est le poste ; pour un échec d'accès à un serveur de fichiers, c'est le serveur de fichiers. Ensuite, vérifiez avec auditpol /get /category:* si l'audit des échecs est activé pour la sous-catégorie « Connexion ». Pour un compte de domaine, la trace se trouve souvent aussi dans la validation des informations d'identification (4776) ou l'échec de préauthentification Kerberos (4771) côté contrôleur de domaine ; quand vous ne pouvez pas identifier le poste, il est même souvent plus rapide d'enquêter directement côté DC. Si vous ne trouvez toujours rien, vérifiez si les anciennes entrées n'ont pas disparu par écrasement du journal (taille maximale du journal et date de l'événement le plus ancien).
Faut-il activer l'enregistrement de la ligne de commande pour la création de processus (4688) ?
C'est un paramètre d'une grande valeur d'investigation, mais qu'il faut activer seulement après en avoir compris le risque. Une fois activé, les arguments de ligne de commande de tous les processus sont enregistrés en clair dans le journal Security. S'il existe ne serait-ce qu'un seul script ou une seule application métier qui passe un mot de passe ou une clé API en argument de ligne de commande, ce secret devient visible pour toute personne pouvant lire le journal Security. Microsoft précise lui-même cette mise en garde. Nous recommandons de d'abord vérifier si vos propres scripts passent des secrets en argument de ligne de commande, de corriger les cas trouvés, puis d'activer le paramètre — dans cet ordre.
Quelle devrait être la taille maximale du journal Security ?
La bonne approche consiste à partir de « combien de jours je veux garder sous la main », il n'existe pas de chiffre universel. Le paramétrage actuel et son résultat réel se vérifient avec Get-WinEvent -ListLog Security ; l'écart entre la date de l'événement le plus ancien et la date actuelle donne « le nombre de jours réellement conservés en ce moment ». Comme ajouter des sous-catégories d'audit augmente aussi le volume d'événements, revérifiez toujours ce nombre de jours réel après un changement de configuration. Une réponse à incident nécessite souvent des journaux vieux de plusieurs semaines à plusieurs mois : il est donc plus sûr de les exporter régulièrement avant qu'ils ne disparaissent par écrasement, ou de les centraliser sur une autre machine via un mécanisme de collecte de journaux.
Comment enquêter sur la cause d'un verrouillage de compte (4740) ?
Le champ « Nom de l'ordinateur appelant » (Caller Computer Name) de l'événement 4740 est le premier indice. Il enregistre l'ordinateur d'origine de l'échec de connexion qui a déclenché le verrouillage. Attention toutefois : la trace de l'échec lui-même (4625) reste du côté qui a reçu la tentative de connexion, pas du côté de son origine. Si la cause est une connexion réseau, suivez chronologiquement le 4625 du serveur accédé, ou, pour un compte de domaine, le 4776/4771 du contrôleur de domaine. Sur le poste identifié comme origine, recherchez ensuite ce qui continue d'utiliser d'anciennes informations d'identification après un changement de mot de passe : informations d'identification enregistrées, session de bureau à distance restée déconnectée, service ou tâche planifiée configuré avec un ancien mot de passe. Si les verrouillages se répètent, vérifiez aussi que la synchronisation horaire n'est pas décalée.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.

Nous contacter
Retour au blog