Lire les fichiers .evtx sans machine Windows
Les journaux d’événements voyagent : depuis un portable saisi, hors d’une image disque, exportés par un client dont le serveur est déjà reconstruit. Ce qui arrive est un fichier .evtx, et l’outil qui l’ouvre — l’Observateur d’événements — n’existe que sous Windows et compose la moitié de ce que vous voyez à partir de DLL présentes sur la machine qui a écrit le journal. Ce guide couvre ce qu’un .evtx contient vraiment, comment en trier un n’importe où avec la visionneuse EVTX locale au navigateur, et les quatre ID d’événement qui répondent à la plupart des premières questions.
Dernière mise à jour:
Le journal n’est jamais sur la machine devant laquelle vous êtes assis
Le schéma est toujours le même. Quelque chose s’est produit — une compromission suspectée, une tempête de verrouillages, un service mort à 03:00 — et la preuve est un journal d’événements Windows que quelqu’un a exporté, imagé ou copié depuis une machine que vous ne pouvez pas démarrer, à laquelle vous ne pouvez pas vous connecter, ou que vous n’avez pas le droit de toucher. Votre propre machine est un Mac, une station Linux ou un portable d’entreprise verrouillé, sans VM Windows en vue. L’Observateur d’événements ne viendra pas à la rescousse.
La bonne nouvelle, c’est qu’un fichier .evtx est un format binaire documenté et autonome. Tout ce que l’Observateur d’événements vous montre sur un enregistrement — à une exception importante près, traitée ci-dessous — se trouve dans le fichier, et un analyseur correct peut le lire n’importe où. La visionneuse EVTX de ce site fait tourner cet analyseur (le crate Rust evtx, compilé en WebAssembly) dans l’onglet de votre navigateur, parce que les journaux d’événements nomment des utilisateurs, des machines et des adresses IP et ne devraient pas plus être téléversés sur un site de conversion aléatoire qu’une capture de paquets. Ce qui suit est la méthode de travail, pas le manuel de l’outil : quoi regarder, dans quel ordre, et ce que les champs vous diront et ne vous diront pas.
Ce qu’il y a réellement dans un fichier .evtx
Un fichier .evtx est un en-tête de 4096 octets suivi d’une suite de blocs de 64 KB. Chaque bloc contient une série d’enregistrements d’événements, et chaque enregistrement est stocké en XML binaire (BinXML) : un bloc System rempli par le système d’exploitation, plus la charge utile propre au fournisseur, sous forme d’EventData ou d’UserData. Ouvrez un enregistrement et vous trouvez des champs, pas de la prose — EventID 4625, un horodatage, un canal, et des valeurs nommées comme IpAddress, TargetUserName et LogonType. Ces champs sont la preuve. Ce sont aussi tout ce qu’un analyseur sur une machine étrangère peut honnêtement vous donner.
Voici l’exception, et elle façonne tout le reste de ce guide : la phrase affichée par l’Observateur d’événements — « Un compte n’a pas pu ouvrir de session » — n’est pas dans le fichier. Windows la compose au moment de l’affichage à partir des DLL de messages qui appartiennent à chaque fournisseur et vivent sur la machine qui a écrit le journal. C’est pourquoi les valeurs de données ressemblent parfois à %%14592 : ce sont des références vers une table de messages que le fichier ne transporte pas. Une visionneuse sur une autre machine peut vous montrer chaque champ enregistré par l’événement, et son XML brut exactement tel que stocké — mais un outil qui présente un texte de message impeccable pour le .evtx de quelqu’un d’autre le reconstruit à partir de ses propres copies de DLL ou le devine. Les champs d’abord, la prose en dernier : c’est l’ordre honnête.
Un dernier fait structurel à connaître avant de citer des chiffres : les blocs du fichier sont indépendants. Un journal extrait d’une image disque, ou copié d’un disque mourant, a souvent des blocs individuels qui ne s’analysent plus. Un bon lecteur signale chaque bloc endommagé avec son décalage en octets et lit tout ce qui l’entoure. Le silence sur ce point — un outil qui rend un journal plus court sans rien dire — est la façon dont des enregistrements disparaissent discrètement d’une enquête.
Commencez par le bloc System
Le bloc System de chaque enregistrement porte le même squelette : Provider (quel composant l’a écrit), EventID (ce qui s’est passé, dans la numérotation de ce fournisseur), Level (de 1 Critique à 5 Détaillé, avec 0 pour les événements sans niveau), Channel (Security, System, Application, et les centaines de journaux opérationnels sous Microsoft-Windows-*), Computer, un horodatage UTC, et l’EventRecordID. Le triage commence par ranger tout un journal dans ce squelette : combien d’enregistrements, sur quelle plage horaire, depuis quels canaux, dominés par quels ID d’événement. Un journal Security composé à 80 % d’un seul ID d’événement raconte en général une seule histoire — un pare-feu qui décide, un service qui s’authentifie en boucle — et le résumé vous le dit avant que vous ayez lu un seul enregistrement.
Citez l’EventRecordID du bloc System lorsque vous référez un enregistrement. Les fichiers extraits, sélectionnés ou réexportés peuvent voir les en-têtes de leurs enregistrements renumérotés par l’outil qui les a produits, tandis que le bloc System conserve l’ID que la machine avait attribué à l’origine — la différence entre « enregistrement 7 de cet extrait » et « EventRecordID 319457858 dans le journal d’origine » compte dès que quelqu’un essaie de reproduire votre constat. Les horodatages méritent le même soin : dans le fichier, ils sont en UTC, toujours. L’Observateur d’événements les convertit à l’heure locale de la machine qui ouvre le journal, et c’est pourquoi deux captures d’écran du même enregistrement peuvent différer de plusieurs heures. Choisissez UTC pour le rapport, et dites-le.
Quatre ID d’événement qui gagnent leur place
1102 — le journal d’audit a été effacé. Le journal Security enregistre sa propre suppression, comme premier événement du nouveau journal. Ses champs nomment l’utilisateur qui l’a effacé. Dans un incident, un 1102 est à la fois une preuve et une frontière : tout ce qui le précède dans ce journal a disparu du fichier que vous avez, et l’effacement lui-même est un fait qui mérite une ligne dans le rapport. Si le plus ancien enregistrement d’un journal est un 1102 dont l’horodatage tombe dans votre fenêtre d’intérêt, dites-le avant que quiconque bâtisse une théorie sur l’absence d’événements antérieurs.
4624 et 4625 — les ouvertures de session, réussies et échouées. Ce sont les bêtes de somme des enquêtes sur les comptes. Les champs qui comptent sont TargetUserName, IpAddress et surtout LogonType : 3 est une ouverture de session réseau, 10 est le Bureau à distance, 2 est une ouverture interactive à la console, 7 est un déverrouillage. Un schéma de force brute se lit comme une rafale de 4625 contre un compte depuis une adresse, suivie — c’est le moment qui compte — d’un 4624. Un seul 4625 est une faute de frappe ; la forme de la séquence est le signal, et c’est pourquoi on filtre et on compte au lieu de faire défiler.
4688 — un processus a été créé. Quand la politique d’audit l’enregistre, chaque 4688 nomme le nouveau processus (NewProcessName), le compte qui l’a lancé et souvent le processus parent — la matière première de « qu’est-ce qui a tourné sur cette machine, et quand ». Deux réserves vous gardent honnête : 4688 n’existe que si « Audit de la création de processus » était activé sur la machine source (son absence ne prouve rien sur ce qui a tourné), et la capture de la ligne de commande est encore un réglage distinct. Traitez une piste 4688 riche comme un cadeau, pas comme un dû.
Ces quatre-là sont un ensemble de départ, pas un programme — le frère d’ouverture de session spéciale de 4624, 4672, l’ouverture à informations d’identification explicites 4648, et l’installation de service 7045 dans le journal System sont les étapes suivantes habituelles. Mais une part remarquable des questions du premier jour — le journal a-t-il été effacé, qui est entré, d’où, et qu’ont-ils exécuté — trouve sa réponse dans 1102, 4624, 4625 et 4688 seuls.
Ce que les champs ne peuvent pas vous dire
La discipline de l’absence est l’essentiel du travail sur les journaux. Le fichier ne peut pas vous montrer des événements que la machine source n’a jamais enregistrés : la politique d’audit décide de ce qui existe, et une machine en configuration par défaut journalise bien moins qu’un enquêteur ne l’espère. Il ne peut pas vous montrer le texte des messages, comme vu plus haut — une référence %% est un pointeur vers une chaîne située sur une machine que vous n’avez pas. Il ne peut pas, à lui seul, prouver une altération ni son absence : des trous dans les ID d’enregistrements apparaissent dans des fichiers honnêtement extraits d’une image comme dans des journaux effacés, et c’est pourquoi l’enregistrement 1102 explicite, et non un trou, est le signal sur lequel s’appuyer.
Et un journal est un seul témoin. Les horodatages viennent de l’horloge de la machine source, qui a pu être fausse ; les comptes apparaissent sous les noms que la machine connaissait ; l’IP d’une ouverture de session réseau est l’adresse que la machine a vue, NAT et VPN compris. Les champs sont exactement ce que la machine a enregistré — pas moins, et la discipline consiste à se rappeler : pas plus.
Une routine de triage en cinq minutes
Première minute : ouvrez le fichier dans la visionneuse EVTX et lisez le résumé avant tout enregistrement — nombre total, plage horaire, canaux et principaux ID d’événement. Notez tout bloc que la visionneuse signale comme illisible, avec son décalage ; cette réserve appartient à vos notes dès le départ, pas à une note de bas de page ultérieure.
Deuxième minute : cherchez 1102. Si le journal a été effacé, toute votre approche change, et l’heure et le compte de l’effacement sont vos premiers faits solides. Troisième minute : filtrez 4625 et regardez la forme — nombre par compte, par adresse source. Une rafale suivie d’un 4624 pour le même compte depuis la même adresse, voilà le constat ; notez les horodatages exacts. Quatrième minute : la fenêtre suspecte étant fixée, filtrez 4688 (et 4624 de type 10, si l’accès à distance est en question) dans cette fenêtre et listez ce qui a tourné et qui s’est connecté. Cinquième minute : exportez les enregistrements filtrés en JSON ou CSV et écrivez le paragraphe tant que les chiffres sont devant vous — ID d’enregistrements, heures UTC, compte, adresses. L’export est votre papier de travail ; le paragraphe, avec la réserve sur les blocs illisibles et la limite du texte de message, est le livrable.
Cette routine ne clôt pas une enquête. Elle transforme un fichier binaire étranger en cinq faits cités et une question suivante défendable, sur la machine qui se trouve devant vous — ce qui est l’essentiel de ce que le triage a jamais été.
Questions fréquentes
J’ai exporté le journal depuis l’Observateur d’événements en CSV ou XML. Puis-je lire cela à la place ?
Ces exports sont autre chose, et de moindre valeur. Un export CSV aplatit chaque événement aux colonnes que l’Observateur d’événements affichait et jette la plus grande partie des EventData structurées — les champs sur lesquels le triage travaille réellement. Si vous avez encore accès à la source, réexportez avec « Enregistrer tous les événements sous… » et choisissez .evtx ; si tout ce que vous avez est le CSV, un tableur vous en dira plus que n’importe quel outil .evtx, parce que ce n’est plus un journal d’événements au sens structuré du terme.
Pourquoi les horodatages ici diffèrent-ils d’une capture d’écran prise dans l’Observateur d’événements ?
Parce que l’Observateur d’événements convertit. Les horodatages à l’intérieur d’un fichier .evtx sont stockés en UTC ; l’Observateur d’événements les affiche à l’heure locale de la machine qui ouvre le journal. Le même enregistrement peut honnêtement apparaître à plusieurs heures d’écart dans deux outils. La visionneuse de ce site reste en UTC et étiquette la colonne en conséquence, et la règle de travail pour les rapports est la même : citez en UTC, nommez le fuseau, et ne mélangez jamais les deux dans une même chronologie.
Les ID d’enregistrements de mon fichier ont des trous. Le journal a-t-il été altéré ?
Des trous seuls ne le prouvent pas. Des enregistrements disparaissent pour des raisons banales — blocs endommagés sur un disque défaillant, fichier extrait d’un espace non alloué, export qui a sélectionné un sous-ensemble — et les fichiers extraits peuvent même voir leurs en-têtes renumérotés tandis que les blocs System conservent les ID d’origine. Un effacement délibéré laisse sa propre trace : l’événement 1102, écrit comme la première entrée du nouveau journal Security, nommant le compte qui l’a effacé. Cherchez cela avant de conclure quoi que ce soit d’une absence.