Analyse forensique des journaux Windows : EVTX et event IDs

Les journaux d'événements sont ce qui se rapproche le plus d'une boîte noire sur un poste Windows : connexions, lancements de processus, installations de services, PowerShell et accès distants y sont consignés dès que l'audit le permet. À la fin de ce guide, vous saurez où se trouvent les journaux et comment ils tournent, quels canaux et quels event IDs répondent à quelles questions, ce que la politique d'audit par défaut laisse passer sans rien dire, et comment récupérer des preuves après un effacement.

Format EVTX et emplacement

Depuis Windows Vista, les journaux sont stockés en XML binaire dans des fichiers .evtx sous %SystemRoot%\System32\winevt\Logs. Chaque canal a son propre fichier, et le / du nom de canal devient %4 sur disque : Microsoft-Windows-PowerShell/Operational est donc stocké dans Microsoft-Windows-PowerShell%4Operational.evtx. XP et Server 2003 utilisaient l'ancien format .evt dans System32\config. La fiche journaux d'événements Windows résume l'organisation.

En interne, un fichier EVTX commence par un en-tête de 4 Ko (signature ElfFile) suivi de chunks de 64 Ko (signature ElfChnk). Chaque chunk contient des enregistrements qui débutent par les octets magiques 2A 2A 00 00 et portent leur propre EventRecordID et leur horodatage. Les enregistrements s'appuient sur des templates stockés dans le chunk, ce qui aura son importance plus loin : un chunk est suffisamment autonome pour être analysé seul une fois carvé depuis l'espace libre.

Le chemin d'un journal classique peut être modifié. Vérifiez HKLM\SYSTEM\CurrentControlSet\Services\EventLog\<LogName> (valeur File) et, pour les canaux récents, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\<Channel> avant de considérer que le dossier par défaut est complet.

Rétention, taille et rotation

Les journaux ont une limite de taille, pas de durée. Sous Windows 7 et versions ultérieures, Security, System et Application sont fixés par défaut à environ 20 Mo, et beaucoup de canaux Operational sont bien plus petits (souvent autour de 1 Mo). Une fois plein, le comportement par défaut est d'écraser les événements les plus anciens. Deux autres modes existent : archiver le journal quand il est plein (valeur AutoBackupLogFiles, qui laisse des fichiers Archive-<Log>-<horodatage>.evtx à côté du journal actif) et ne pas écraser.

Conséquences concrètes :

• Sur un contrôleur de domaine ou un serveur de fichiers chargé, le journal Security peut ne couvrir que quelques heures. Notez toujours l'enregistrement le plus ancien de chaque journal avant d'affirmer « aucun événement trouvé ».
• Les GPO d'entreprise augmentent souvent les tailles : lisez le MaxSize réel au lieu de supposer les valeurs par défaut.
• Les journaux transmis à un SIEM ou à un collecteur Windows Event Forwarding peuvent survivre à la copie locale. Demandez-les tôt.

# Taille, mode et nombre d'enregistrements d'un journal
wevtutil gl Security
Get-WinEvent -ListLog Security, System, 'Microsoft-Windows-PowerShell/Operational' |
  Select-Object LogName, MaximumSizeInBytes, LogMode, RecordCount, FileSize

# Plus ancien événement conservé dans un fichier collecté
Get-WinEvent -Path E:\case\Logs\Security.evtx -Oldest -MaxEvents 1 | Select-Object TimeCreated, RecordId

Les canaux qui comptent

Le détail RDP est sur la fiche connexions RDP, PowerShell sur la fiche PowerShell, Defender sur la fiche Windows Defender, WMI et BITS sur les fiches dépôt WMI et jobs BITS. Certains canaux, TaskScheduler en particulier, peuvent être désactivés ou minuscules selon la build et la configuration : leur absence ne prouve pas qu'il ne s'est rien passé.

Les event IDs Security essentiels

Connexions et sessions

4624 (connexion réussie) et 4625 (échec de connexion) forment la colonne vertébrale de toute timeline d'intrusion. Le champ qui leur donne du sens est LogonType (voir type de logon) :

Pour un 4625, lisez Status et SubStatus : 0xC000006A correspond à un mauvais mot de passe sur un compte valide, 0xC0000064 à un utilisateur inexistant, 0xC0000234 à un compte verrouillé. Une rafale de 0xC0000064 sur de nombreux noms évoque du password spraying ou de l'énumération ; des 0xC000006A répétés sur un seul compte, du bruteforce.

4634 est une déconnexion et 4647 une déconnexion initiée par l'utilisateur ; associez-les au 4624 via TargetLogonId pour obtenir la durée de session, en sachant que les connexions réseau se ferment souvent en quelques secondes. 4648 (connexion avec identifiants explicites) montre un compte saisissant les identifiants d'une autre identité, classique avec runas et les outils de mouvement latéral ; il est journalisé sur la machine source. 4672 (privilèges spéciaux attribués) suit un 4624 dès que la nouvelle session dispose de privilèges de niveau administrateur : 4624 plus 4672 avec le même logon ID signifie une session d'administration.

Création de processus

4688 enregistre un nouveau processus avec son chemin d'image, le processus parent (Windows 10 et ultérieurs) et le type d'élévation du jeton. Il n'est produit que si Audit Process Creation est activé, et le champ CommandLine n'est renseigné que si la stratégie Include command line in process creation events est configurée (valeur ProcessCreationIncludeCmdLine_Enabled sous HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit). Ce paramètre est natif depuis Windows 8.1 et Server 2012 R2 ; les systèmes plus anciens nécessitaient une mise à jour. Rattachez un 4688 à sa session via SubjectLogonId, qui correspond au TargetLogonId du 4624 d'origine.

Persistance et modifications de comptes

• 4697 (Security) et 7045 (System) : un service a été installé. Le 7045 est écrit par le Service Control Manager quelle que soit la politique d'audit ; le 4697 exige Audit Security System Extension. Voir la fiche services.
• 4698 : tâche planifiée créée, avec le XML complet de la tâche dans l'événement. 4699 suppression, 4702 modification. Nécessite Audit Other Object Access Events. Voir la fiche tâches planifiées.
• 4720 compte créé, 4722 compte activé, 4724 tentative de réinitialisation du mot de passe par un autre compte, 4728 membre ajouté à un groupe global de sécurité, 4732 membre ajouté à un groupe local de sécurité (par exemple Administrateurs).

Altération

• 1102 : le journal Security a été effacé, avec le compte responsable. Il est écrit quelle que soit la politique d'audit.
• 104 (System) : un autre journal a été effacé.
• 4719 : la politique d'audit système a été modifiée. Un attaquant qui coupe l'audit des processus ou des connexions juste avant d'agir, c'est un signal fort.
• 1100 : le service Event Log s'est arrêté. Sans redémarrage correspondant (6006, puis 6005 au boot suivant), cela mérite qu'on s'y attarde.

Politique d'audit : ce qui est journalisé par défaut, et ce qui ne l'est pas

La politique d'audit par défaut varie selon la version de Windows et est généralement écrasée par les GPO du domaine : ne devinez jamais. Récupérez auditpol /get /category:* sur le système vivant, ou reconstituez la politique effective à partir de la ruche Security et des fichiers GPO sur une machine éteinte. En première approximation, sur un client Windows 10/11 standard :

• Journalisé : ouvertures et fermetures de session (4624, 4625, 4634, 4647), connexions spéciales (4672), gestion des comptes et des groupes de sécurité (4720, 4732...), changement de politique d'audit (4719), effacement du journal (1102), et 7045 dans System.
• Non journalisé : création de processus (4688), événements objet des tâches planifiées (4698), installation de service côté Security (4697), accès aux fichiers et au registre, et le détail des tickets de service Kerberos sur les postes membres.

Les catégories manquantes sont la première raison pour laquelle une investigation « ne trouve rien » dans le journal Security. Quand elles sont désactivées, rabattez-vous sur Prefetch, Amcache, les canaux TaskScheduler et PowerShell, et Sysmon s'il est présent.

# Politique d'audit effective sur un hôte vivant
auditpol /get /category:*

# La capture de la ligne de commande est-elle activée ?
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit' -ErrorAction SilentlyContinue

Sysmon : l'essentiel

Sysmon est un pilote et un service Sysinternals gratuits qui écrivent une télémétrie riche, issue d'ETW, dans Microsoft-Windows-Sysmon/Operational. Sa valeur dépend entièrement du fichier de configuration déployé : collectez la configuration (dans le registre ou sur le partage de déploiement) en même temps que le journal. Les cinq IDs les plus utiles :

Le ProcessGuid est unique par instance de processus, contrairement aux PID qui sont réutilisés : pivotez dessus pour reconstruire l'arbre des processus. Également utiles : 7 (image chargée), 8 (CreateRemoteThread), 10 (accès à un processus, par exemple lsass.exe) et 19 à 21 (abonnements WMI).

PowerShell : 4103 et 4104

Le 4104 (script block logging) enregistre le texte des blocs de script au moment de leur compilation, une fois résolues les couches d'obfuscation comme -EncodedCommand ou les chaînes passées à Invoke-Expression. Il s'active via la valeur de stratégie EnableScriptBlockLogging sous HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging. Même sans cette stratégie, PowerShell 5 journalise en 4104 de niveau avertissement les blocs qu'il juge suspects, ce qui sauve régulièrement des investigations. Les scripts longs sont découpés en plusieurs 4104 partageant un ScriptBlockId, numérotés par MessageNumber et MessageTotal : réassemblez-les avant de les lire.

Le 4103 (module logging) enregistre le détail de l'exécution du pipeline et les paramètres liés pour les modules configurés sous ModuleLogging. Plus bruyant, il montre les commandes réellement exécutées avec leurs arguments. Le journal classique Windows PowerShell ajoute les 400/403 (démarrage et arrêt du moteur) avec un champ HostApplication contenant la ligne de commande de lancement, disponible même sur les hôtes sans autre journalisation PowerShell.

# Réassembler les script blocks d'un journal Operational collecté
Get-WinEvent -FilterHashtable @{Path='E:\case\Logs\Microsoft-Windows-PowerShell%4Operational.evtx'; Id=4104} |
  ForEach-Object {
    $d = ([xml]$_.ToXml()).Event.EventData.Data
    [pscustomobject]@{
      Time    = $_.TimeCreated.ToUniversalTime()
      BlockId = ($d | Where-Object Name -eq 'ScriptBlockId').'#text'
      Part    = ($d | Where-Object Name -eq 'MessageNumber').'#text'
      Text    = ($d | Where-Object Name -eq 'ScriptBlockText').'#text'
    }
  } | Sort-Object BlockId, {[int]$_.Part}

Récupérer des journaux effacés

Un 1102 ou un 104 vous dit qu'un journal a été effacé et par qui. Récupérer le contenu est un autre travail, et l'anti-forensics efface rarement toutes les copies :

1. Volume Shadow Copies. Un cliché instantané antérieur à l'effacement contient les anciens .evtx intacts. Montez-le, ou laissez EvtxECmd traiter directement les shadow copies. Voir la fiche Volume Shadow Copies.
2. Carving de chunks EVTX. L'effacement crée un nouveau fichier ; les clusters de l'ancien sont libérés, pas écrasés. Comme chaque chunk ElfChnk de 64 Ko est autodescriptif, le file carving de l'espace non alloué (ainsi que des images mémoire, du pagefile et de l'hiberfil) peut récupérer des chunks entiers. Des outils comme EVTXtract (Willi Ballenthin) tentent aussi de reconstruire des enregistrements isolés dont les templates manquent.
3. Archives et copies transmises. Cherchez les Archive-*.evtx, les données SIEM, la télémétrie EDR et les sauvegardes.
4. Les autres canaux. Effacer Security ne touche ni PowerShell/Operational, ni TaskScheduler/Operational, ni Sysmon. Les attaquants les oublient souvent.

Cherchez aussi les altérations qui évitent le 1102 : un service Event Log arrêté (1100, ou un trou entre enregistrements sans redémarrage), des sauts d'EventRecordID, ou un journal dont le premier enregistrement démarre longtemps après le dernier boot. Le guide anti-forensics va plus loin.

Outils

EvtxECmd

EvtxECmd, d'Eric Zimmerman, convertit les EVTX en CSV normalisé. Ses maps (un YAML par canal et par event ID) extraient les champs utiles d'EventData dans des colonnes homogènes comme UserName, RemoteHost ou ExecutableInfo, ce qui rend le filtrage dans Timeline Explorer très rapide.

# Mettre à jour les maps, puis traiter un dossier de journaux collectés
EvtxECmd.exe --sync
EvtxECmd.exe -d E:\case\Logs --csv E:\out --csvf evtx.csv

# Quelques IDs seulement, depuis un fichier unique
EvtxECmd.exe -f E:\case\Logs\Security.evtx --csv E:\out --inc 4624,4625,4648,4672,4688

# Inclure les shadow copies d'un volume monté, avec dédoublonnage
EvtxECmd.exe -d F:\Windows\System32\winevt\Logs --vss --dedupe --csv E:\out

Hayabusa et Chainsaw

Tous deux appliquent des règles de détection de type Sigma sur un dossier entier de journaux en quelques minutes, ce qui en fait d'excellents premiers passages.

# Hayabusa : mise à jour des règles, timeline, synthèse des connexions
hayabusa update-rules
hayabusa csv-timeline -d ./Logs -o hayabusa.csv
hayabusa logon-summary -d ./Logs

# Chainsaw : chasse Sigma et recherche par mot-clé
chainsaw hunt ./Logs -s sigma/ --mapping mappings/sigma-event-logs-all.yml -r rules/
chainsaw search mimikatz -i ./Logs

Traitez leurs résultats comme des pistes, pas comme des conclusions : les règles se déclenchent sur l'outillage d'administration, et un résultat vide signifie seulement qu'aucune règle n'a matché.

Get-WinEvent

Natif, scriptable, et parfait pour des questions ciblées sur des journaux vivants ou collectés. Utilisez -FilterHashtable ou -FilterXPath pour que le filtrage se fasse dans l'API plutôt que de tout faire passer par Where-Object.

# Connexions RDP et réseau sur une fenêtre de temps, avec les champs clés
$start = [datetime]'2026-09-20T00:00:00Z'
Get-WinEvent -FilterHashtable @{Path='E:\case\Logs\Security.evtx'; Id=4624; StartTime=$start} |
  ForEach-Object {
    $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    if ($d.LogonType -in '3','10') {
      [pscustomobject]@{ Time=$_.TimeCreated.ToUniversalTime(); User=$d.TargetUserName
        Type=$d.LogonType; Ip=$d.IpAddress; Workstation=$d.WorkstationName; LogonId=$d.TargetLogonId }
    }
  }

# Services installés, directement depuis le journal System
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; Id=7045}

Erreurs fréquentes

• Lire les heures en heure locale. TimeCreated est stocké en UTC ; l'Observateur d'événements et certains exports affichent l'heure locale. Normalisez en UTC avant toute fusion, comme expliqué dans UTC et heure locale.
• Considérer les event IDs comme globaux. Un ID n'a de sens qu'avec son provider et son canal : le 4104 de PowerShell/Operational n'a rien à voir avec un autre 4104.
• Conclure à l'absence sur un résultat vide sans vérifier la politique d'audit ni l'enregistrement le plus ancien conservé.
• Faire aveuglément confiance à WorkstationName. Il est fourni par le client et peut être falsifié ou vide ; privilégiez IpAddress et corrélez avec l'hôte source.
• Ignorer les petits canaux. TerminalServices, TaskScheduler, Defender et WMI-Activity contiennent souvent la seule trace d'une action.

Méthode de chasse

1. Collecter tous les .evtx (target KAPE EventLogs ou Velociraptor), ainsi que les shadow copies, les ruches SYSTEM et SOFTWARE et la sortie d'auditpol si la machine est vivante. Le guide acquisition et triage couvre la partie collecte.
2. Établir la couverture : pour chaque journal important, notez la taille, le mode de rétention, l'enregistrement le plus ancien et les catégories d'audit activées.
3. Chercher d'abord les altérations : 1102, 104, 1100, 4719, trous dans les record IDs.
4. Lancer Hayabusa ou Chainsaw pour obtenir des pistes rapidement, puis tout traiter avec EvtxECmd pour la vue complète.
5. Cadrer l'authentification : 4624/4625 par type de logon, IP source et compte ; 4648 et 4672 ; RDP 1149 et 21/24/25. Les connexions distantes suspectes alimentent le guide mouvement latéral.
6. Suivre la session : chaînez TargetLogonId vers 4688 ou Sysmon 1, puis vers 4104, 7045, 4698 et les événements Defender. Les découvertes de persistance se poursuivent dans chasser la persistance Windows.
7. Timeline : fusionnez le CSV obtenu avec les artefacts du système de fichiers et du registre dans une super timeline, le tout en UTC.

Les recommandations de Microsoft sur la politique d'audit méritent d'être lues en parallèle de vos constats, à la fois pour savoir ce qui aurait dû être journalisé et pour conseiller le client sur ce qu'il faut activer la prochaine fois.