Stratégie d'audit de sécurité Windows et investigation des journaux d'événements — devenir une équipe IT capable de lire un 4625

« Un compte se verrouille sans arrêt depuis hier soir. Trouvez la cause. » « Vérifiez si quelqu’un tente de se connecter avec le compte d’un ancien employé. » « Pouvez-vous dire quand et qui a exécuté quoi sur ce serveur ? » — ce sont les demandes qui atterrissent sans prévenir chez les responsables informatiques d’une PME, ou chez un développeur qui livre des systèmes chez un client. Et ce sur quoi l’on finit par s’appuyer, c’est le journal d’événements Security de Windows.

Ouvrez l’Observateur d’événements, toutefois, et deux réalités vous attendent. Soit l’événement que vous voulez n’a jamais été enregistré (la stratégie d’audit n’était pas activée), soit il est enseveli sous un déluge d’événements et illisible (le journal est plein de bruit et a gonflé). L’audit de sécurité est quelque chose que l’on « obtient si on l’active », mais tant que vous n’avez pas conçu ce qu’il faut enregistrer et jusqu’où, il ne vous aidera pas le jour où cela compte.

flowchart TB
    accTitle: Les deux réalités qui attendent dans l'Observateur d'événements
    accDescr: Ouvrez l'Observateur d'événements et il y a deux réalités, soit la stratégie d'audit n'était pas activée donc l'événement voulu n'a jamais été enregistré, soit le journal est plein de bruit et a gonflé donc l'événement est enseveli sous un déluge d'entrées, ce qui signifie qu'il faut concevoir ce qu'il faut enregistrer et jusqu'où
    open["Ouvrir l'Observateur d'événements"] --> real{"Quelle réalité attend ?"}
    real -->|Non enregistré| none["L'événement voulu n'a jamais été enregistré"]
    real -->|Enseveli| noise["Illisible sous un déluge d'événements"]
    none -.-> cause1["Stratégie d'audit désactivée"]
    noise -.-> cause2["Plein de bruit et devenu énorme"]
    none --> design["Concevoir ce qu'il faut enregistrer et jusqu'où"]
    noise --> design

Figure 1 : Soit « non enregistré », soit « enseveli et illisible ». Les deux viennent de n’avoir jamais conçu la portée de ce qu’il faut enregistrer.

Cet article sépare deux choses : les paramètres qui gardent les journaux dont une investigation a besoin, et la procédure pour trouver la cause dans les journaux que vous avez. Il couvre le fonctionnement de la stratégie d’audit (les deux systèmes, de base et avancé), les sous-catégories qu’un environnement de petite ou moyenne taille devrait activer au minimum, la lecture de 4624/4625/4740/4688, la conception de la capacité du journal Security, et l’investigation avec PowerShell. Les explications techniques s’appuient sur des sources primaires à la date d’août 2026.

Si les articles déjà traités sur ce site — l’audit NTLM, la signature SMB, BitLocker et le pare-feu — portent sur le durcissement des défenses, celui-ci porte sur rendre possible de confirmer après coup ce qui s’est passé, et c’est la suite qui les relie.

1. D’abord la conclusion

Pour rendre vos journaux utilisables pour une investigation, alignez trois choses : enregistrer ce dont vous avez besoin, lire le bon élément sur la bonne machine, et le préserver avant qu’il ne disparaisse. L’important est de ne pas s’arrêter à l’activation de l’audit.

Si vous allez configurer l’audit : uniformisez côté avancé et n’enregistrez que le nécessaire

• La stratégie d’audit existe en deux systèmes, « de base » et « avancé » (Advanced Audit Policy), et il ne faut pas les mélanger. Microsoft indique explicitement qu’utiliser les deux laisse les résultats d’audit dans un état inattendu. Uniformisez-vous côté avancé (plus de 40 sous-catégories).¹
• Pour vérifier l’état actuel, exécutez auditpol /get /category:*. Cela liste les paramètres d’audit actuellement en vigueur, qu’ils viennent d’une GPO ou d’une configuration locale.²
• N’activez pas « tout ». Activer des sous-catégories qui génèrent d’énormes volumes d’événements enterre les événements qui comptent dans le bruit, et affecte aussi les performances. Partez des recommandations de référence de Microsoft et n’ajoutez que ce dont vous avez besoin.³⁴

Si vous enquêtez maintenant : vérifiez la machine d’enregistrement et les champs, pas seulement l’ID d’événement

• Une ouverture de session réussie est 4624 et un échec est 4625. Pour 4624, vous lisez « de quel type d’ouverture de session il s’agit » d’après le type d’ouverture de session (2 = interactive, 3 = réseau, 10 = Bureau à distance, etc.).⁵
• Pour 4625, les codes Status/Sub Status indiquent la raison de l’échec. L’ensemble standard est 0xC0000064 = le nom d’utilisateur n’existe pas, 0xC000006A = mot de passe erroné, 0xC0000072 = compte désactivé, 0xC0000234 = compte verrouillé.⁶
• La machine sur laquelle un événement est enregistré est fixe. 4624/4625 vont à la machine à laquelle on a accédé, la validation des informations d’identification (4776) va à la machine qui a autorité sur ces informations (un contrôleur de domaine pour un compte de domaine), et l’échec de préauthentification Kerberos (4771) va à un contrôleur de domaine. Consulter la mauvaise machine vous fera diagnostiquer à tort « il n’y a pas de journal ».⁶⁷⁸

Nécessaire dans les deux cas : concevoir la conservation des journaux et le traitement des informations sensibles

• Pour le journal Security, la conception du contenant (taille maximale et conservation) est la moitié du travail. Si la conservation est réglée sur l’écrasement, les événements les plus anciens disparaissent un par un. Vérifiez la taille maximale et le nombre d’enregistrements avec Get-WinEvent -ListLog Security, et étendez-la en partant du nombre de jours que vous devez conserver.⁹¹⁰
• L’enregistrement de la ligne de commande pour la création de processus (4688) est puissant, mais la contrepartie est le risque de voir des secrets atterrir en clair dans le journal. Passez vos scripts en revue avant de l’activer.¹¹¹²

Choisissez où lire selon votre objectif ou votre symptôme

Si une demande d’investigation vous a déjà été remise, préservez le journal avec la méthode de 6.3, vérifiez les notes sur les machines d’enregistrement et la synchronisation des horloges à la section 7, puis lisez l’événement concerné à la section 4. Si vous remettez de l’ordre dans les paramètres, vérifiez l’état actuel aux sections 2 et 5, puis passez à la section 3.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (34 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Fondamentaux de la stratégie d’audit — ne pas mélanger « de base » et « avancé »

2.1. Comprendre la différence d’emplacement et de granularité

La stratégie d’audit Windows existe en deux systèmes.¹

• Stratégie d’audit de base : les neuf paramètres de catégorie sous « Stratégies locales > Stratégie d’audit ». C’est l’ancien système, antérieur à Windows Vista.
• Stratégie d’audit avancée (Advanced Audit Policy Configuration) : les plus de 40 paramètres de sous-catégorie sous « Paramètres de sécurité > Configuration avancée de la stratégie d’audit ». Chaque catégorie de base est décomposée en plusieurs sous-catégories ; la seule catégorie de base « Auditer les événements d’ouverture de session de compte », par exemple, correspond à quatre sous-catégories côté avancé. Activer une catégorie côté de base équivaut à activer toutes les sous-catégories correspondantes, ce qui enregistre d’énormes volumes d’événements qui ne vous intéressent pas.¹

2.2. Uniformisez côté avancé et empêchez le côté de base de l’écraser

Le point important est que les deux systèmes ne sont pas compatibles. Microsoft indique explicitement de ne pas utiliser à la fois la stratégie d’audit de base et la stratégie d’audit avancée, parce que les résultats d’audit se retrouvent dans un état inattendu.

Lorsque vous appliquez la stratégie d’audit avancée par Stratégie de groupe, les paramètres d’audit existants de l’ordinateur sont d’abord effacés, puis les paramètres avancés sont appliqués, et à partir de là seul le côté avancé vous donne un contrôle fiable.

Dans un environnement qui utilise le côté avancé, activez l’option de sécurité « Audit : forcer les paramètres de sous-catégorie de la stratégie d’audit (Windows Vista ou version ultérieure) à remplacer les paramètres de catégorie de la stratégie d’audit » afin que le côté de base n’écrase pas vos paramètres (elle est activée par défaut sur les machines autonomes).¹⁴

flowchart TB
    accTitle: La relation entre la stratégie d'audit de base et avancée
    accDescr: La stratégie d'audit de base et la stratégie d'audit avancée ne sont pas compatibles et les utiliser toutes les deux laisse les résultats d'audit dans un état inattendu, donc uniformisez côté avancé et activez le forçage des paramètres de sous-catégorie pour empêcher le côté de base de les écraser
    basic["Stratégie d'audit de base (9 catégories)"] --> both{"Utiliser les deux ?"}
    adv["Stratégie d'audit avancée (plus de 40 sous-catégories)"] --> both
    both -->|Oui| bad["Résultats d'audit dans un état inattendu"]
    both -->|Non| unify["Uniformiser côté avancé"]
    unify --> force["Activer le forçage des paramètres de sous-catégorie"]
    force -.-> guard["Empêche les paramètres de base d'écraser"]

Figure 2 : Les deux systèmes ne sont pas compatibles. Uniformisez côté avancé et utilisez le paramètre « forcer » pour empêcher le côté de base de l’écraser.

2.3. Utilisez auditpol pour vérifier la stratégie réellement en vigueur

Vérifier l’état actuel tient en une seule commande. Exécutez-la depuis une invite de commandes administrateur.²

L’exemple suivant montre trois opérations distinctes : afficher l’état actuel, en faire une sauvegarde avant une modification, et restaurer. Vérifiez d’abord l’affichage, et prenez une sauvegarde avant de modifier. La ligne /restore est ce que vous exécutez lorsque vous devez restaurer, pas une étape à enchaîner juste après l’affichage pour vérifier l’état actuel.

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

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

La sortie d’auditpol est « la stratégie en vigueur comme résultat », qu’elle vienne d’une GPO ou d’une configuration locale. Cela la rend aussi utile pour recouper lorsque des paramètres que vous croyez distribuer par GPO n’ont pas pris effet.

Notez que modifier les paramètres d’audit eux-mêmes enregistre l’événement 4719, donc « l’audit avait été discrètement désactivé » est aussi traçable après coup.¹²

flowchart TB
    accTitle: Ce qu'auditpol montre est la stratégie résultante
    accDescr: La sortie d'auditpol est la stratégie d'audit en vigueur comme résultat qu'elle vienne d'une GPO ou de paramètres locaux, donc elle peut servir à recouper lorsque des paramètres GPO n'ont pas pris effet, et les modifications des paramètres d'audit eux-mêmes restent traçables après coup via l'événement 4719
    gpo["Paramètres distribués par GPO"] --> eff["La stratégie en vigueur comme résultat"]
    local["Paramètres locaux"] --> eff
    eff --> get["Lister avec auditpol /get"]
    get -.-> diff["Utilisable pour recouper quand la GPO n'a pas été appliquée"]
    change["Modification des paramètres d'audit eux-mêmes"] -.-> e4719["4719 est enregistré et traçable après coup"]

Figure 3 : auditpol renvoie « les paramètres en vigueur » quel que soit leur origine. Les modifications des paramètres d’audit eux-mêmes restent dans 4719.

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

3.1. Pourquoi « tout activer » est une erreur

La raison pour laquelle « activez simplement tout » est une mauvaise idée est claire. Microsoft avertit, par exemple, que l’audit des sous-catégories d’utilisation des privilèges jusqu’au succès produit de tels volumes d’événements que trouver les autres entrées devient difficile, et qu’il y a aussi un impact sur les performances.⁴ Le contenant du journal (section 5) est fini, donc plus vous enregistrez de bruit, moins il reste de jours de conservation pour les événements dont vous avez réellement besoin. La conception de l’audit, c’est décider ce qu’il ne faut pas enregistrer.

flowchart TB
    accTitle: Pourquoi tout activer est une mauvaise idée
    accDescr: Activer chaque sous-catégorie génère d'énormes volumes d'événements qui enterrent les événements qui comptent dans le bruit et affectent les performances, et dans un contenant de journal fini cela entame aussi la durée de conservation des événements dont vous avez besoin
    all["Activer chaque sous-catégorie"] --> flood["Énormes volumes d'événements"]
    flood --> noise["Les événements qui comptent sont ensevelis"]
    flood --> perf["Impact sur les performances"]
    flood --> keep["La durée de conservation est entamée"]
    noise --> lesson["La conception de l'audit, c'est décider ce qu'il ne faut pas enregistrer"]
    perf --> lesson
    keep --> lesson

Figure 4 : « Tout activer » enterre les événements qui comptent. La conception de l’audit, c’est décider ce qu’il ne faut pas enregistrer.

3.2. Partez de la référence et choisissez les traces dont vous avez besoin

Microsoft publie des recommandations de référence et des recommandations renforcées séparément pour les postes de travail et les serveurs, et c’est le point de départ.³ Par-dessus, le tableau ci-dessous organise les choses du point de vue « au minimum, voilà ce que je veux pouvoir lire pendant un incident » d’un environnement de petite ou moyenne taille. C’est le tableau de décision de cet article, construit à partir des recommandations de Microsoft comme point de départ, pas une liste de paramètres à appliquer uniformément à tous les environnements.

3.3. Pour ceux qui s’enregistrent en masse, restreignez les cibles et la fenêtre temporelle

À l’inverse, il est plus sûr de ne pas toucher par défaut à l’audit d’accès aux objets pour le système de fichiers et le Registre, à l’utilisation des privilèges, ni aux sous-catégories de filtre de paquets (5152 et assimilés). Ceux-ci font leurs preuves avec une configuration SACL étroitement ciblée ou une fenêtre limitée dans le temps pendant le triage ; les ouvrir en grand en permanence dévorera votre journal.⁴

flowchart TB
    accTitle: Comment traiter les sous-catégories à fort volume
    accDescr: L'audit d'accès aux objets pour le système de fichiers et le Registre, l'utilisation des privilèges et les sous-catégories de filtre de paquets dévorent le journal lorsqu'ils restent ouverts en grand en permanence, et ne font leurs preuves qu'avec une configuration SACL étroitement ciblée ou une fenêtre limitée dans le temps pendant le triage
    heavy["Sous-catégories à fort volume"] --> use{"Comment les activez-vous ?"}
    heavy -.-> ex1["Audit d'accès aux objets"]
    heavy -.-> ex2["Utilisation des privilèges et sous-catégories de filtre de paquets"]
    use -->|Ouvertes en grand en permanence| eat["Dévorent le journal"]
    use -->|SACL étroitement ciblée| ok1["Font leurs preuves"]
    use -->|Fenêtre limitée pendant le triage| ok2["Font leurs preuves"]

Figure 5 : Ne laissez pas l’accès aux objets ou l’utilisation des privilèges ouverts en grand en permanence. Ils ne font leurs preuves qu’avec des cibles et des fenêtres temporelles restreintes.

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

Vérifiez trois choses comme un ensemble : de quel événement il s’agit, sur quelle machine il reste, et quel champ regarder. Les ouvertures de session commencent en 4.1 et 4.2, les verrouillages en 4.3, les modifications de compte en 4.4, et les opérations qui ont été exécutées en 4.5 et 4.6. Dans une investigation réelle, préservez d’abord le journal avec la méthode de 6.3.

4.1. 4624 — Triez les ouvertures de session réussies par type d’ouverture de session

4624 est « Un compte s’est connecté », et il est enregistré sur la machine où la session d’ouverture de session a été créée, c’est-à-dire la machine à laquelle on a accédé.⁵ Comme il s’enregistre en grand nombre, commencez par le trier par type d’ouverture de session lorsque vous le lisez.⁵

Après le tri par type, regardez le compte, la source et le privilège

Les autres champs à regarder sont le nom de compte sous « New Logon », l’adresse source sous « Network Information », le « Authentication Package » (NTLM ou Kerberos), et l’« Elevated Token » (s’il s’agit d’une session d’administration). Si vous voulez suivre uniquement les ouvertures de session administratives, vous pouvez aussi utiliser 4672 (privilèges spéciaux attribués à une nouvelle ouverture de session), qui s’enregistre avec le même ID d’ouverture de session.⁵

flowchart TB
    accTitle: La procédure pour trier les 4624
    accDescr: Parce que 4624 s'enregistre en grand nombre, triez-le d'abord par type d'ouverture de session, puis vérifiez le nom de compte et la source, le package d'authentification et le jeton élevé, et recoupez les ouvertures de session administratives avec le 4672 portant le même ID d'ouverture de session
    ev["4624 ouverture de session réussie"] --> type["Trier par type d'ouverture de session"]
    type --> fields["Vérifier les champs principaux"]
    fields -.-> f1["Nom de compte et source"]
    fields -.-> f2["Package d'authentification"]
    fields -.-> f3["Jeton élevé"]
    fields --> admin["Suivre le privilège d'administration"]
    admin -.-> e4672["Le 4672 avec le même ID d'ouverture de session"]

Figure 6 : Triez 4624 par type d’ouverture de session avant de lire les champs. Corrélez les ouvertures de session privilégiées avec 4672.

4.2. 4625 — Fixez la raison de l’échec avec les codes Status/Sub Status

4625 est « Un compte n’a pas pu se connecter », et il est enregistré sur la machine où l’ouverture de session a été tentée.⁶ Plutôt que le libellé du champ « Failure Reason », lire les codes hexadécimaux Status/Sub Status est l’approche fiable. L’ensemble standard est le suivant.⁶

D’abord, lisez la raison de l’échec d’après Status/Sub Status

• 0xC0000064 : le nom d’utilisateur n’existe pas. Une série de ceux-ci dans une courte fenêtre est un signe d’attaque par énumération de comptes
• 0xC000006A : mot de passe erroné. Une série de ceux-ci contre un compte précis est un signe d’attaque par essai de mots de passe
• 0xC000006D : nom d’utilisateur ou informations d’authentification incorrects
• 0xC000006F : en dehors des heures autorisées
• 0xC0000070 : depuis un poste de travail non autorisé
• 0xC0000072 : compte désactivé par un administrateur (les tentatives contre le compte d’un ancien employé apparaissent ici)
• 0xC000015B : le type d’ouverture de session demandé n’est pas accordé sur cette machine
• 0xC0000193 : compte expiré
• 0xC0000234 : compte verrouillé

Combinez le compte cible, la source et la raison de l’échec

« Qui, d’où, et pourquoi cela a échoué » se fixe par l’ensemble de trois : le compte cible, la source (nom de poste / adresse IP), et ce code. La section 6.2 a du PowerShell qui extrait les trois en une passe.

flowchart TB
    accTitle: Le flux pour fixer la raison d'un échec 4625
    accDescr: Fixez la raison d'un échec 4625 avec le code hexadécimal Status/Sub Status, lisez les signes d'une attaque d'après le motif des codes, puis identifiez-la avec l'ensemble de trois qui ajoute le compte cible et la source
    ev["4625 échec de connexion"] --> code["Vérifier le code Sub Status"]
    code --> sign{"Quel est le motif des codes ?"}
    sign -->|Une série de 0xC0000064| enum["Signe d'énumération de comptes"]
    sign -->|Une série de 0xC000006A| guess["Signe d'essai de mots de passe"]
    sign -->|0xC0000072| disabled["Tentative contre le compte d'un ancien employé"]
    enum --> triple["Le fixer avec l'ensemble de trois"]
    guess --> triple
    disabled --> triple
    triple -.-> t1["Compte cible + source + code"]

Figure 7 : Fixez la raison avec le code, et lisez-la avec le compte cible et la source comme un ensemble de trois.

4.3. 4740 — L’origine d’un verrouillage est le « Caller Computer Name »

Trouver l’origine : le nom de l’ordinateur appelant dans 4740

4740 est « Un compte d’utilisateur a été verrouillé » (la sous-catégorie est Audit User Account Management). Le champ qui pilote cet événement est « Caller Computer Name », qui enregistre de quel ordinateur provenait la tentative d’ouverture de session qui a déclenché le verrouillage.¹⁶ Le geste standard est d’identifier ici le poste d’origine, puis de passer ce poste au crible pour les anciennes informations d’identification qui y restent.

Dans la plupart des cas, la cause est quelque chose qui continue d’utiliser d’anciennes informations d’identification après un changement de mot de passe : informations d’identification enregistrées, une session RDP restée déconnectée, ou un service ou une tâche configuré avec l’ancien mot de passe.

flowchart TB
    accTitle: Le geste standard pour enquêter sur un verrouillage de compte
    accDescr: Identifiez le poste d'origine d'après le nom de l'ordinateur appelant dans 4740, et passez ce poste au crible pour les informations d'identification enregistrées, les sessions Bureau à distance restées déconnectées, et les services ou tâches configurés avec l'ancien mot de passe
    ev["4740 verrouillage survenu"] --> caller["Vérifier le nom de l'ordinateur appelant"]
    caller --> src["Identifier le poste d'origine"]
    src --> sweep["Passer au crible les anciennes informations d'identification"]
    sweep -.-> c1["Informations d'identification enregistrées"]
    sweep -.-> c2["Sessions RDP restées déconnectées"]
    sweep -.-> c3["Services et tâches avec l'ancien mot de passe"]

Figure 8 : Identifiez l’origine d’après le « Caller Computer Name » de 4740, puis passez ce poste au crible pour les anciennes informations d’identification.

Trouver la trace de l’échec : regardez le côté qui l’a accepté, pas l’origine

Il y a une mise en garde. 4625 s’enregistre sur l’ordinateur qui a accepté la tentative d’ouverture de session. Si la cause est une ouverture de session réseau depuis le poste d’origine vers un serveur de fichiers ou similaire, aucun 4625 ne reste dans le journal Security du poste d’origine lui-même ; la trace reste dans le 4625 du serveur de destination, ou, pour un compte de domaine, dans 4776 (NTLM) / 4771 (échec de préauthentification Kerberos) sur le DC.⁷⁸ Lorsque « il n’y a rien dans le journal du poste d’origine », allez regarder le côté qui a accepté.

Le flux de l’investigation peut s’organiser ainsi : trouver l’origine d’après l’appelant dans 4740, recouper chronologiquement le 4625 de la destination et le 4776/4771 du DC, puis vérifier les informations d’identification enregistrées, les services, les tâches, etc. sur le poste d’origine. Trouver l’origine et trouver où les événements d’échec sont enregistrés sont deux choses différentes.

flowchart TB
    accTitle: Les machines où la trace d'un échec reste
    accDescr: Un échec d'ouverture de session réseau ne reste pas sur le poste d'origine lui-même mais s'enregistre dans le 4625 du serveur de destination qui a accepté la tentative, et pour un compte de domaine la trace reste aussi dans 4776 ou 4771 sur le DC
    src["Poste d'origine (pas de 4625 propre)"] -->|Ouverture de session réseau| target["Serveur de destination"]
    target -.-> e4625["4625 est enregistré"]
    src -->|Authentification de compte de domaine| dc["Contrôleur de domaine"]
    dc -.-> e4776["4776 (NTLM) / 4771 (Kerberos)"]

Figure 9 : 4625 reste du côté qui a accepté la tentative. S’il n’y a rien sur le poste d’origine, regardez le serveur de destination et le DC.

4.4. La famille 4720 — Création, modification de compte et ajouts à un groupe

Séparez les modifications de compte des modifications d’appartenance à un groupe

Les événements de gestion des comptes s’enchaînent : 4720 (un compte d’utilisateur a été créé)¹⁷, 4726 (supprimé), 4738 (modifié), puis les ajouts et retraits de membres côté groupe.

Notez que les modifications d’appartenance à un groupe se répartissent entre ID d’événement selon le type de groupe. Les groupes locaux sont 4732/4733, les groupes globaux 4728/4729, et les groupes universels 4756/4757.¹⁴ Domain Admins est un groupe global, donc un ajout s’y enregistre dans 4728 — faites de 4732 seul votre condition d’alerte et vous manquerez précisément ce que vous voulez le plus voir.

Un ajout inattendu à un groupe d’administrateurs mérite une investigation même isolé

Au quotidien, ce sont des traces du travail du support, mais « un utilisateur standard a soudain été ajouté à un groupe d’administrateurs » ou « un compte que personne ne connaît a été créé » est un sujet d’investigation immédiat même en occurrence unique. Microsoft liste aussi un ajout inattendu de membre à un groupe privilégié comme exemple d’événement sur lequel alerter individuellement.³

flowchart TB
    accTitle: Types de groupes et événements d'ajout de membre
    accDescr: Un ajout de membre à un groupe se répartit entre ID d'événement selon le type de groupe, enregistré en 4732 pour un groupe local, 4728 pour un groupe global et 4756 pour un groupe universel, donc un ajout au groupe global Domain Admins apparaît en 4728
    add["Membre ajouté à un groupe"] --> kind{"Quel type de groupe ?"}
    kind -->|Local| lg["Enregistré en 4732"]
    kind -->|Global| gg["Enregistré en 4728"]
    kind -->|Universel| ug["Enregistré en 4756"]
    gg -.-> da["Les ajouts à Domain Admins atterrissent ici"]
    lg -.-> miss["Surveiller seulement 4732 les rate"]

Figure 10 : L’ID d’événement d’un ajout de membre se sépare selon le type de groupe. Un ajout à Domain Admins est 4728.

4.5. 4688 — Création de processus. L’enregistrement de la ligne de commande est un interrupteur séparé

Ce que l’audit de création de processus vous dit

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

Conserver la ligne de commande exige un paramètre séparé et d’abord une revue

Par défaut, toutefois, les arguments de ligne de commande ne sont pas enregistrés. Ce n’est que lorsque vous activez séparément le paramètre de 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) que les arguments apparaissent dans le champ « Process Command Line » de 4688.¹¹¹² C’est en pratique obligatoire pour suivre des lancements suspects tels que powershell -EncodedCommand ..., mais ne l’activez qu’après avoir compris le risque de fuite de secrets dans le journal décrit à la section 7. Lisez d’abord la section 7, corrigez les endroits qui passent des secrets en arguments, puis configurez-le.

flowchart TB
    accTitle: La relation entre 4688 et l'enregistrement de la ligne de commande
    accDescr: Activer l'audit de création de processus enregistre le compte, le chemin de l'exécutable et le processus parent dans 4688, mais les arguments de ligne de commande ne sont enregistrés qu'une fois un paramètre de Stratégie de groupe séparé activé, ce qui comporte le risque de voir des secrets apparaître en clair
    audit["Activer l'audit de création de processus"] --> ev["4688 est enregistré"]
    ev -.-> base["Compte, chemin, processus parent"]
    ev --> args{"Voulez-vous aussi les arguments ?"}
    args -->|Laissé au défaut| none["La ligne de commande est vide"]
    args -->|Activer la GPO supplémentaire| cmd["Les arguments sont enregistrés"]
    cmd -.-> risk["Risque de secrets en clair"]

Figure 11 : L’enregistrement de la ligne de commande de 4688 est un interrupteur séparé. L’activer exige d’abord de passer en revue le risque de fuite de secrets.

4.6. 4698 — Une tâche planifiée a été créée

4698 est « Une tâche planifiée a été créée », et il enregistre le nom de la tâche et le XML complet de la définition de tâche (y compris la commande à exécuter). Parce qu’enregistrer une tâche est la technique standard qu’utilise un logiciel malveillant pour survivre à un redémarrage, Microsoft recommande de surveiller les événements de création de tâche.¹⁵ Même dans les environnements qui utilisent beaucoup de tâches à des fins métier, une création n’est pas un événement quotidien, donc le bruit reste limité.

flowchart TB
    accTitle: Persistance par enregistrement de tâche et 4698
    accDescr: Les logiciels malveillants enregistrent couramment des tâches planifiées pour survivre à un redémarrage, donc surveiller le 4698 enregistré à la création d'une tâche permet de suivre la définition de tâche jusqu'à la commande qu'elle exécute
    mal["Persistance d'un logiciel malveillant"] --> task["Enregistrer une tâche pour survivre"]
    task --> ev["4698 est enregistré"]
    ev -.-> xml["XML complet y compris la commande à exécuter"]
    ev --> watch["Le détecter en surveillant la création de tâche"]
    watch -.-> low["La création n'est pas un événement quotidien, donc peu de bruit"]

Figure 12 : L’enregistrement de tâche, technique classique de persistance, reste dans 4698. Le XML complet de la définition permet de la suivre jusqu’à la commande.

Pour savoir si le journal lui-même a été effacé, vérifiez aussi 1102

Un autre à garder en tête est 1102, « Le journal d’audit a été effacé ». Effacer le journal Security laisse toujours cet événement, donc lorsque « le journal est vide » vous pouvez dire s’il s’agissait d’une opération délibérée ou de quelque chose qui a mal tourné.¹⁸

flowchart TB
    accTitle: Utiliser 1102 pour trier un journal effacé
    accDescr: Effacer le journal Security laisse toujours un 1102, donc lorsque le journal est vide, vérifier la présence d'un 1102 indique si l'effacement était une opération effectuée par quelqu'un ou quelque chose qui a mal tourné
    empty["Le journal est vide"] --> rule["L'effacement laisse toujours un 1102"]
    rule --> check{"Y a-t-il un 1102 ?"}
    check -->|Oui| op["Quelqu'un a effectué un effacement"]
    check -->|Non| acc["Suspecter que quelque chose a mal tourné"]

Figure 13 : Effacer le journal Security laisse toujours un 1102. Pour un journal vide, la présence de 1102 sépare une opération délibérée de quelque chose qui a mal tourné.

5. Concevoir le contenant du journal — taille maximale et conservation

5.1. Quand il est plein, qu’est-ce qui est perdu, les anciennes traces ou les nouvelles ?

Avant d’ajouter des stratégies d’audit, vérifiez le récipient qui doit les accueillir. Le journal Security a une taille maximale et un mode de conservation, et en mode écrasement (la configuration de facto standard), une fois la taille maximale atteinte les nouveaux événements écrasent les plus anciens. En mode conservation (ne pas écraser), à l’inverse, ce sont les nouveaux événements qui sont rejetés une fois le journal plein.¹⁰ Les deux comportements sont une cause de « le journal avait disparu avant que je m’en aperçoive », donc comprendre l’état actuel vient d’abord.

5.2. Déduisez la capacité dont vous avez besoin d’après les jours réellement conservés

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

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

Get-WinEvent -ListLog renvoie ensemble la configuration du journal et le nombre d’enregistrements.⁹ L’écart entre « l’horodatage de l’événement le plus ancien » et le présent est la durée de conservation dont vous disposez réellement, et si elle n’atteint pas votre propre exigence (le nombre de jours auxquels vous voulez pouvoir remonter pendant une investigation d’incident), vous élargissez la taille maximale. Le paramètre peut se distribuer avec wevtutil sl Security /ms:<bytes> ou par Stratégie de groupe.¹⁰

Pensez la capacité en termes de « combien de jours voulons-nous garder ». Ajouter des sous-catégories d’audit augmente le volume d’événements, donc revérifiez les jours réellement conservés après avoir changé les paramètres. Il vous faut aussi une pratique opérationnelle d’export selon un calendrier avant que les événements ne soient écrasés, ou de les centraliser sur une autre machine.

flowchart TB
    accTitle: Conception de la capacité en partant de la durée de conservation
    accDescr: Vérifiez la configuration et le nombre d'enregistrements avec le paramètre ListLog de Get-WinEvent, déduisez la durée de conservation réellement disponible d'après l'horodatage de l'événement le plus ancien, et élargissez la taille maximale si elle n'atteint pas le nombre de jours auxquels vous voulez remonter pendant une investigation d'incident
    check["Vérifier la configuration et le nombre d'enregistrements avec ListLog"] --> oldest["Vérifier l'horodatage de l'événement le plus ancien"]
    oldest --> days["Calculer la durée de conservation réellement disponible"]
    days --> enough{"Satisfait-elle l'exigence ?"}
    enough -->|Oui| keep["Garder la taille actuelle"]
    enough -->|Non| grow["Élargir la taille maximale"]
    grow -.-> how["Configurer avec wevtutil sl ou GPO"]

Figure 14 : Confirmez les jours réellement conservés, et réglez la taille maximale en partant du nombre de jours auxquels vous voulez remonter.

5.3. CrashOnAuditFail n’est pas un paramètre qui résout un manque de capacité

Notez que les options de sécurité incluent « Audit : arrêter le système immédiatement s’il est impossible de consigner les audits de sécurité » (ce que l’on appelle couramment CrashOnAuditFail). Lorsqu’il est activé et que les audits de sécurité ne peuvent plus être enregistrés, le système s’arrête avec l’erreur STOP C0000244. C’est un paramètre pour des exigences de certification où la piste d’audit ne doit absolument pas être perdue, et il est désactivé par défaut.

Microsoft lui-même met en garde qu’il peut être transformé en DoS dans lequel un attaquant arrête délibérément un serveur en générant d’énormes volumes d’événements, donc ce n’est pas quelque chose à activer à la légère dans un environnement ordinaire de petite ou moyenne taille.¹⁹

flowchart TB
    accTitle: Comportement lorsque le journal est plein
    accDescr: La configuration de conservation existe sous deux formes, mode écrasement et mode ne pas écraser, et lorsque les audits ne peuvent plus être enregistrés en mode ne pas écraser, le paramètre séparé CrashOnAuditFail arrête le système avec l'erreur STOP C0000244 s'il est activé
    full["Le journal Security atteint la taille maximale"] --> mode{"Quelle est la configuration de conservation ?"}
    mode -->|Mode écrasement| ow["Les événements les plus anciens sont écrasés"]
    mode -->|Ne pas écraser| drop["Les nouveaux événements sont rejetés"]
    ow -.-> lost["Les deux font disparaître le journal avant que vous ne vous en aperceviez"]
    drop -.-> lost
    drop --> caf{"CrashOnAuditFail est-il aussi activé ?"}
    caf -->|Oui| crash["Le système s'arrête avec l'erreur STOP C0000244"]

Figure 15 : La configuration de conservation est soit l’écrasement, soit le rejet. CrashOnAuditFail est un paramètre séparé qui arrête le système lorsque l’audit ne peut pas être enregistré.

6. L’investigation en pratique — filtres, Get-WinEvent et export

L’ordre dans lequel vous travaillez réellement est « préserver en 6.3, puis analyser en 6.1 ou 6.2 ». Cette section passe en revue chaque outil d’investigation. Pour un cas isolé, utilisez l’Observateur d’événements ; lorsque le volume est important ou que l’investigation se répète, utilisez PowerShell.

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

Pour une investigation isolée, l’Observateur d’événements suffit. Ouvrez le journal Security et spécifiez l’ID d’événement (4625, par exemple) et la plage horaire sous « Filtrer le journal actuel ». Enregistrez les conditions que vous consultez régulièrement avec « Créer un affichage personnalisé », et elles sont à un clic la fois suivante. Si vous voulez restreindre par autre chose que l’ID d’événement, par exemple un compte précis, vous pouvez modifier directement la requête XPath dans l’onglet XML de la boîte de dialogue de filtre.

6.2. Extraction avec Get-WinEvent

Pour les investigations à grand volume, à conditions multiples, ou selon un calendrier récurrent, passez au Get-WinEvent de PowerShell. L’essentiel est d’utiliser -FilterHashtable, qui fait prendre effet le filtre côté serveur.⁹

flowchart TB
    accTitle: Choisir entre les outils d'investigation
    accDescr: Une investigation isolée se traite avec le filtre de l'Observateur d'événements, les conditions que vous consultez régulièrement se sauvegardent comme affichage personnalisé, et les investigations à grand volume, à conditions multiples ou selon un calendrier récurrent passent à Get-WinEvent
    q{"Quel type d'investigation ?"}
    q -->|Isolée| viewer["Filtrer dans l'Observateur d'événements"]
    q -->|Conditions que vous revoyez| view["Enregistrer comme affichage personnalisé"]
    q -->|Grande, multi-conditions, planifiée| ps["Passer à Get-WinEvent"]
    ps -.-> hash["Filtrer avec FilterHashtable"]

Figure 16 : Observateur d’événements pour les cas isolés, affichages personnalisés pour les répétitions, Get-WinEvent lorsque le volume est important.

Restreignez par ID et plage horaire, puis extraire le compte cible, la source et la raison de l’échec

La première moitié ci-dessous récupère les événements 4625 des dernières 24 heures. La seconde extrait les champs individuels du XML et est un exemple qui compte les occurrences par combinaison de compte, Status, SubStatus et source. Le tableau final n’est pas une liste chronologique d’événements individuels ; il montre combien de fois chaque combinaison s’est produite, par ordre décroissant.

# 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, d'où, et pourquoi » en 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

Réutilisez le motif pour lire les champs dont vous avez besoin dans le XML sur d’autres événements

Une fois que vous avez ce motif pour extraire EventData de la représentation XML d’un événement, vous pouvez le réutiliser de la même façon pour 4624 ou 4688. La conception du filtrage de Get-WinEvent (quand utiliser FilterHashtable plutôt que XPath, et comment corriger une requête lente) est traitée en détail dans « Examiner les journaux d’événements en pratique avec Get-WinEvent — La rapidité du filtrage détermine le temps d’investigation ».

flowchart TB
    accTitle: Le motif de mise en forme pour extraire EventData
    accDescr: Convertissez un événement récupéré avec Get-WinEvent en sa représentation XML, extraire chaque champ EventData et le mettre en forme en tableau, et réutilisez ce motif de la même façon pour 4624 et 4688 autant que pour 4625
    get["Récupérer avec Get-WinEvent"] --> xml["Convertir l'événement en sa représentation XML"]
    xml --> pull["Extraire EventData"]
    pull --> shape["Mettre en forme en tableau et agréger"]
    shape -.-> reuse["De la même façon pour 4624 et 4688"]

Figure 17 : Le motif consistant à extraire EventData de la représentation XML vers un tableau est réutilisable lorsque l’ID d’événement change.

6.3. Exporter avec wevtutil

En règle générale, les journaux de la machine sous investigation doivent être exportés et sécurisés d’abord, avant que l’écrasement ne les enlève.¹⁰

rem Préserver tout le journal Security en evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem Exporter seulement 4625, restreint avec XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

Analysez l’evtx sauvegardé sur une autre machine

Le .evtx exporté peut s’analyser sur une autre machine exactement de la même façon, avec Get-WinEvent -Path C:\logs\security-20260801.evtx.⁹ L’habitude de préserver avant d’analyser est le même raisonnement que « sécurisez d’abord le dump » dans une investigation de plantage (voir « Introduction à la collecte des dumps de crash Windows - WER/ProcDump/WinDbg »).

flowchart TB
    accTitle: Le flux de préserver avant d'analyser
    accDescr: Exportez et sécurisez le journal Security de la machine sous investigation dans un fichier evtx avec wevtutil epl, puis analysez-le de la même façon sur une autre machine en pointant Get-WinEvent vers le chemin
    target["Machine sous investigation"] --> export["Préserver en evtx avec wevtutil epl"]
    export --> copy["L'emporter sur une autre machine"]
    copy --> analyze["Analyser avec Get-WinEvent -Path"]
    export -.-> note["Le sécuriser avant que l'écrasement ne l'enlève"]

Figure 18 : Préserver d’abord, analyser ensuite. Une fois sécurisé en evtx, vous pouvez l’examiner de la même façon sur une autre machine.

7. Pièges — quatre dans lesquels il est facile de tomber sur le terrain

7.1. Des secrets qui voyagent sur la ligne de commande de 4688

Activez l’enregistrement de la ligne de commande et les arguments de tous les processus vont dans le journal Security en clair. Microsoft indique explicitement que « tous les utilisateurs ayant un accès en lecture aux événements de sécurité peuvent lire les arguments de ligne de commande de tout processus créé avec succès, et ces arguments peuvent contenir des données sensibles telles que des mots de passe ».¹² S’il existe ne serait-ce qu’une application métier ou un script qui lance quelque chose comme myapp.exe /user:admin /password:P@ssw0rd, c’est une divulgation du secret à quiconque peut lire le journal.

Avant de l’activer, trouvez et corrigez les endroits qui passent des secrets en arguments. Le même niveau de traitement est alors exigé partout où les journaux sont préservés et transférés.

flowchart TB
    accTitle: L'ordre pour activer l'enregistrement de la ligne de commande
    accDescr: Avant d'activer l'enregistrement de la ligne de commande pour 4688, trouvez les applications métier et les scripts qui passent des secrets en arguments, gardez l'ordre de les corriger avant d'activer le paramètre, et exigez le même niveau de traitement pour les destinations de préservation et de transfert des journaux
    audit["Trouver les secrets passés en arguments"] --> found{"Y en a-t-il ?"}
    found -->|Oui| fix["Corriger les endroits qui les passent"]
    found -->|Non| on["Activer l'enregistrement de la ligne de commande"]
    fix --> on
    on -.-> dest["Même niveau de traitement pour la préservation et le transfert"]

Figure 19 : L’enregistrement de la ligne de commande, c’est « les trouver, les corriger, puis activer ». Inversez l’ordre et vous divulguez les secrets.

7.2. Fonctionner sans connaître le comportement lorsque le journal est plein

En mode écrasement les anciennes traces disparaissent silencieusement, avec l’écrasement désactivé les nouveaux événements sont rejetés, et avec CrashOnAuditFail activé le système lui-même s’arrête (section 5).¹⁰¹⁹ La bonne approche est de savoir quel comportement vous avez choisi et de mettre en place un mécanisme qui « les collecte avant qu’ils ne disparaissent » (exports planifiés ou plateforme de collecte de journaux).

7.3. Contrôleurs de domaine et postes de travail exigent des journaux différents

4624/4625 s’enregistrent sur la machine à laquelle on a accédé.⁵⁶ La validation des informations d’identification d’un compte de domaine (le 4776 de NTLM), en revanche, s’enregistre sur la machine qui a autorité sur ces informations, ce qui pour un compte de domaine est un DC⁷, et l’échec de préauthentification Kerberos (4771) s’enregistre uniquement sur un DC.⁸ « Il n’y a pas de 4625 sur le serveur de fichiers » ne signifie pas « il n’y a pas eu d’attaque » ; vous n’avez le tableau complet qu’une fois que vous recoupez aussi 4776/4771 sur le DC. Pour le déroulement réel de chaque protocole d’authentification, voir « NTLM et Kerberos expliqués en images — Pourquoi l’authentification « retombe »-t-elle sur NTLM ? ».

7.4. Si les horloges ne sont pas synchronisées, vous ne pouvez pas recouper

Aligner les journaux de plusieurs machines pour suivre « quel poste a produit un 4625 juste avant ce 4740 » suppose que les horloges de ces machines concordent. Dans un environnement de domaine, Kerberos lui-même fixe une limite supérieure au décalage d’horloge (5 minutes par défaut), et au-delà l’authentification elle-même commence à échouer.²⁰ Du point de vue de l’investigation, un décalage de quelques secondes — sans parler de cinq minutes — suffit à vous faire mal lire l’ordre des événements, donc placez une vérification de l’état de synchronisation de w32time tout au début de votre procédure d’investigation.

De plus, les horodatages d’événements sont stockés en UTC et affichés selon le fuseau horaire de la machine qui les consulte, donc lorsque vous lisez un evtx apporté d’un site à l’étranger ou d’un serveur réglé sur UTC, n’oubliez pas de convertir le fuseau horaire.

flowchart TB
    accTitle: La synchronisation des horloges comme prérequis du recoupement
    accDescr: Une investigation qui aligne les journaux de plusieurs machines par ordre chronologique suppose que les horloges de ces machines concordent, car un décalage de quelques secondes suffit à mal lire l'ordre des événements et un décalage au-delà des cinq minutes par défaut fait échouer l'authentification Kerberos elle-même, donc placez une vérification w32time au début de la procédure
    merge["Recouper les journaux de plusieurs machines"] --> pre["Suppose que les horloges concordent"]
    pre --> skew{"De combien les horloges sont-elles décalées ?"}
    skew -->|En accord| ok["Vous pouvez les suivre chronologiquement"]
    skew -->|Quelques secondes de décalage| misread["Mal lire l'ordre des événements"]
    skew -->|Au-delà des 5 minutes par défaut| kerb["L'authentification Kerberos échoue"]
    pre -.-> first["Placer la vérification w32time au début de la procédure"]

Figure 20 : Recouper plusieurs machines suppose que les horloges sont alignées. Même quelques secondes de décalage mènent à mal lire l’ordre des événements.

8. Synthèse

Pour utiliser le journal Security de Windows pour une investigation, concevez ensemble trois choses : la portée de ce que vous enregistrez, l’endroit et les champs que vous lisez, et le mécanisme qui le préserve.

Lorsque vous remettez de l’ordre dans les paramètres

Ne mélangez pas la stratégie d’audit « de base » et « avancée » ; uniformisez côté avancé. Vérifiez l’état actuel avec auditpol /get /category:*, et partez du tableau de décision de la section 3, construit autour de l’ouverture de session, de la gestion des comptes et de la création de processus, avec les recommandations de référence de Microsoft comme point de départ. « Tout activer » rend l’investigation plus difficile par le bruit et le gonflement.

Le contenant du journal (taille maximale et mode de conservation) est la moitié de la conception de l’audit. Vérifiez les jours réellement conservés, décidez de la taille en partant de votre exigence, et exportez ou centralisez avant que les événements ne disparaissent. N’activez l’enregistrement de la ligne de commande de 4688 qu’après avoir passé en revue le risque de fuite de secrets.

Lorsque vous enquêtez

Préserver d’abord, analyser ensuite. Sécurisez le journal avec wevtutil epl, vérifiez la machine d’enregistrement de chaque événement et la synchronisation des horloges, et seulement alors commencez à lire. Utilisez le filtre de l’Observateur d’événements pour les cas isolés, et Get-WinEvent -FilterHashtable pour les investigations qui se répètent.

Les points clés à la lecture sont le type d’ouverture de session pour 4624, Status/Sub Status pour 4625, le nom de l’ordinateur appelant pour 4740, et le processus parent et la ligne de commande pour 4688. Ne jugez pas d’après l’ID d’événement seul : confirmez quelle information a été enregistrée où, et recoupez les journaux dont vous avez besoin.

Articles connexes

• Examiner les journaux d’événements en pratique avec Get-WinEvent — La rapidité du filtrage détermine le temps d’investigation
• La fin de NTLM va-t-elle bloquer vos applications métier ? — Comment collecter les journaux d’audit et dans quel ordre éliminer les dépendances
• NTLM et Kerberos expliqués en images — Pourquoi l’authentification « retombe »-t-elle sur NTLM ?
• Signature SMB et liaison de canal LDAP ── boucler « l’autre moitié » des contre-mesures NTLM en pratique
• Introduction au journal des événements Windows et à ETW — placer les journaux de votre application métier sur les mécanismes standard de l’OS
• Introduction à la collecte des dumps de crash Windows - WER/ProcDump/WinDbg

Domaines de conseil associés

Chez Komura Soft LLC, nous assurons le conseil sur la stratégie d’audit et la conception des journaux dans un environnement Windows, l’investigation de « quand, qui, et quoi » à partir des journaux d’événements, et l’analyse des causes des incidents que les applications métier provoquent autour de l’authentification et de l’audit. Commencer par « on m’a demandé de regarder les journaux, mais par où commencer ? » convient parfaitement.

• Analyse de dysfonctionnements et des causes racines
• Conseil technique et revue de conception
• Nous contacter

Références

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.

Nous n'avons configuré aucune stratégie d'audit, pourquoi 4624 et 4625 sont-ils déjà enregistrés dans le journal Security ?

Parce que Windows a des sous-catégories d'audit activées par défaut. La sous-catégorie « Audit Logon », par exemple, 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. En restant sur les paramètres par défaut, toutefois, de nombreux événements utiles à l'investigation ne sont pas enregistrés, comme la validation des informations d'identification (4776) et la création de processus (4688). 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é stratégie 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 ?

Confirmez d'abord le principe : 4625 est enregistré sur « l'ordinateur où l'ouverture de session 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 « Audit Logon ». Pour un compte de domaine, la trace se trouve souvent plutôt dans la validation des informations d'identification (4776) ou l'échec de préauthentification Kerberos (4771) sur le contrôleur de domaine ; quand vous ne pouvez pas identifier le poste, il est souvent plus rapide de commencer côté DC. Si vous ne trouvez toujours rien, vérifiez si les anciennes entrées n'ont pas déjà disparu par écrasement (comparez la taille maximale du journal et l'horodatage de l'événement le plus ancien).

Faut-il activer l'enregistrement de la ligne de commande pour la création de processus (4688) ?

Sa valeur d'investigation est très élevée, mais c'est un paramètre à n'activer qu'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 cet ordre : d'abord vérifier si vos propres scripts passent des secrets en argument de ligne de commande, corriger les cas trouvés, puis seulement activer le paramètre.

Quelle devrait être la taille maximale du journal Security ?

La bonne approche consiste à partir de « combien de jours voulons-nous garder sous la main » ; il n'existe pas de chiffre universel. Le paramétrage actuel et son comportement réel se vérifient avec Get-WinEvent -ListLog Security ; l'écart entre l'horodatage de l'événement le plus ancien et l'heure actuelle donne « le nombre de jours réellement conservés en ce moment ». Ajouter des sous-catégories d'audit augmente le volume d'événements, donc revérifiez toujours cette durée de conservation réelle après un changement de configuration. Une réponse à incident a souvent besoin de journaux vieux de plusieurs semaines ou plusieurs mois : il est donc rassurant d'exporter le journal régulièrement avant qu'il ne disparaisse par écrasement, ou de le centraliser sur une autre machine via un mécanisme de collecte.

Comment enquêter sur la cause d'un verrouillage de compte (4740) ?

Le champ « Caller Computer Name » de l'événement 4740 est le premier indice. Il enregistre l'ordinateur d'origine de l'échec d'ouverture de session qui a déclenché le verrouillage. Attention toutefois : la trace de l'échec lui-même (4625) reste du côté qui a accepté la tentative d'ouverture de session, pas du côté de son origine. Si la cause est une ouverture de session réseau, suivez chronologiquement le 4625 du serveur de destination, 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 de détenir d'anciennes informations d'identification après un changement de mot de passe : informations d'identification enregistrées, session Bureau à distance restée déconnectée, et services ou tâches planifiées configurés avec l'ancien mot de passe. Si les verrouillages se répètent, vérifiez aussi que la synchronisation des horloges n'a pas dérivé.

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.