Journaux d'événements Windows : les ID à connaître

Quand un poste redémarre seul, qu’un compte se verrouille chaque matin ou qu’on soupçonne une intrusion, la première source est le même fichier : les journaux d’événements. Il en existe des milliers de types ; dans une petite structure, une vingtaine d’identifiants suffisent pour répondre à l’essentiel des questions courantes. Cet article les liste avec leur sens, explique comment les filtrer et rappelle un prérequis qu’on oublie souvent : sans stratégie d’audit, certains événements n’existent pas.

Prérequis : activer l’audit

Les événements de sécurité ne sont pas tous écrits par défaut. Microsoft précise que le comportement de journalisation par défaut varie selon la version et l’édition, que beaucoup de paramètres d’audit sont sur « Non configuré », et que certains événements demandent une configuration explicite.

• Où : secpol.msc en local, ou une stratégie de groupe (GPO) dans « Configuration avancée de la stratégie d’audit » (Advanced Audit Policy Configuration), sous les paramètres de sécurité.
• Quoi activer (succès et échec) au minimum : Audit Logon, Audit Logoff, Audit Account Lockout, Audit Special Logon (catégorie Ouvrir/fermer la session) ; Audit User Account Management et Audit Security Group Management (catégorie Gestion des comptes) ; sur les contrôleurs de domaine, Audit Kerberos Authentication Service et Audit Kerberos Service Ticket Operations (catégorie Ouverture de session de compte).
• En ligne de commande (administrateur) : auditpol /set /subcategory:"Logon" /success:enable /failure:enable.
• Taille du journal : un journal Sécurité trop petit écrase les anciens événements, ceux d’une intrusion de la semaine dernière compris. Augmentez-la.

Journal Sécurité : connexions

4672 apparaît dès qu’une session reçoit un privilège sensible (par exemple SeDebugPrivilege ou SeBackupPrivilege) : les comptes SYSTEM en génèrent en permanence, donc ce qui compte est un compte utilisateur inattendu dans cette liste.

Les types d’ouverture de session (LogonType)

Dans 4624 et 4625, le champ LogonType dit comment la session a été ouverte :

• 2 Interactive : clavier devant la machine.
• 3 Network : accès réseau (partage de fichiers, par exemple).
• 4 Batch : tâche exécutée sans intervention de l’utilisateur.
• 5 Service : démarrage d’un service.
• 7 Unlock : déverrouillage du poste.
• 8 NetworkCleartext : réseau, mot de passe transmis à l’authentification sous forme non hachée.
• 9 NewCredentials : nouveaux identifiants pour les connexions sortantes (runas /netonly, par exemple).
• 10 RemoteInteractive : Bureau à distance (RDP).
• 11 CachedInteractive : identifiants mis en cache, sans contacter le contrôleur de domaine.

Des échecs 4625 de type 10 en rafale venant d’une adresse inconnue évoquent un Bureau à distance exposé qu’on attaque. Des échecs de type 3 répétés peuvent venir d’un partage ou d’un service qui présente un mot de passe périmé : le champ Source Network Address aide à trancher.

Journal Sécurité : comptes et groupes

Un 4720 suivi d’un 4728 ou 4732 qui ajoute le nouveau compte à un groupe d’administrateurs, hors de toute demande, mérite une explication immédiate. Pour 4740, le champ Caller Computer Name donne la machine d’où venaient les tentatives qui ont verrouillé le compte : c’est le moyen le plus rapide de trouver le poste qui garde un vieux mot de passe en mémoire.

Journal Sécurité : Kerberos (contrôleurs de domaine)

• 4768 : un ticket d’authentification Kerberos (TGT) a été demandé. Un code résultat 0x6 signifie que le nom d’utilisateur n’existe pas : en série, c’est un indice d’énumération de comptes.
• 4769 : un ticket de service Kerberos a été demandé.
• 4771 : la pré-authentification Kerberos a échoué. Le code 0x18 signifie un mauvais mot de passe ; beaucoup d’événements en peu de temps peuvent indiquer une attaque par force brute.

Ces trois événements ne sont générés que sur les contrôleurs de domaine. Les détails de l’annuaire sont dans l’aide-mémoire Active Directory.

Journal Sécurité : le signal d’alarme

• 1102 : le journal d’audit a été effacé. Microsoft recommande de l’investiguer : il n’y a normalement aucune raison d’effacer le journal Sécurité à la main.
• 4719 : la stratégie d’audit du système a été modifiée.
• 4697 : un service a été installé dans le système (Windows 10 et Windows Server 2016 ou plus récent, sous-catégorie Audit Security System Extension).

Journal Système : redémarrages

• 41 (Kernel-Power, niveau critique) : le système a redémarré sans arrêt propre, enregistré au démarrage suivant. Coupure de courant, écran bleu ou arrêt forcé au bouton ; un code d’erreur (BugcheckCode) à zéro oriente plutôt vers l’alimentation.
• 1074 : un arrêt ou un redémarrage a été demandé par un processus ou un utilisateur (shutdown.exe y inscrit le motif).
• 6006 : arrêt normal.
• 6008 : l’arrêt précédent n’était pas prévu. Il peut aussi apparaître après un arrêt forcé par un programme alors que le poste est verrouillé.

Après l’installation des mises à jour du Patch Tuesday, ces événements permettent de distinguer un redémarrage demandé (1074) d’un arrêt sauvage (41, 6008).

Filtrer : Observateur d’événements et PowerShell

Dans l’Observateur d’événements, ouvrez « Journaux Windows », puis « Sécurité » ou « Système », et utilisez « Filtrer le journal actuel » ou « Créer une vue personnalisée » pour saisir un ou plusieurs ID.

En PowerShell (exécuté en administrateur pour lire le journal Sécurité), Get-WinEvent avec -FilterHashtable filtre à la source, plus efficacement qu’un Where-Object :

# Redémarrages inattendus et demandés, sur 7 jours
Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 41, 1074, 6006, 6008
    StartTime = (Get-Date).AddDays(-7)
}

# Le journal d'audit a-t-il été effacé ?
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 1102 }

Détecter une rafale d’échecs de connexion

$echecs = Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddHours(-1)
}
$echecs | ForEach-Object {
    $d = @{}
    ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{ Compte = $d['TargetUserName']; Source = $d['IpAddress']; Type = $d['LogonType'] }
} | Group-Object Compte, Source, Type |
    Sort-Object Count -Descending |
    Select-Object -First 10 Count, Name

Des dizaines d’échecs pour un même compte et une même adresse en une heure : verrouillez, bloquez la source et vérifiez le champ Status de l’événement (0xC000006A mauvais mot de passe, 0xC0000064 compte inexistant, 0xC0000072 compte désactivé). Pour un mail d’hameçonnage reçu juste avant, lisez ses en-têtes. Toutes les commandes utiles sont dans l’aide-mémoire des événements Windows.

Sources

• Microsoft Learn : Appendix L, événements à surveiller
• Microsoft Learn : événement 4624
• Microsoft Learn : événement 4625
• Microsoft Learn : événement 4672
• Microsoft Learn : événement 4740
• Microsoft Learn : événement 4768
• Microsoft Learn : événement 4771
• Microsoft Learn : événement 4697
• Microsoft Learn : événement 1102
• Microsoft Learn : événement 41 (Kernel-Power)
• Microsoft Support : événement 6008
• Microsoft Learn : paramètres avancés de la stratégie d’audit
• Microsoft Learn : auditpol set
• Microsoft Learn : Get-WinEvent