TL;DR Executive

  • Les EVTX sont centraux pour reconstruire une intrusion Windows, mais leur valeur dépend fortement de la politique d’audit activée avant l’incident [7][8].
  • Le triptyque minimal pour la chronologie est: authentification (4624/4625), exécution (4688), persistance/changements (4698, 4720) [1][2][3][5][6].
  • La corrélation par Logon ID, ProcessId/NewProcessId, hôte, et horodatage UTC améliore fortement l’attribution d’actions à un acteur [1][3][4].
  • L’anti-forensics via effacement de journaux (1102, wevtutil cl) est fréquent et doit être traité comme signal prioritaire, non comme simple “bruit admin” [4][11][13].
  • Pour réduire la perte de preuve, la collecte centralisée (WEF/WEC) et la rétention longue durée sont des contrôles structurants [10][9].
  • Les outils d’extraction EVTX modernes (libevtx, evtx Rust) facilitent l’industrialisation, mais n’éliminent pas les biais de collecte (logs non activés, rotation, corruption partielle) [12][13].
  • La reconstruction robuste exige une méthode explicite (inclusion/exclusion des sources, contrôle qualité, limites), sinon le risque de surinterprétation demeure élevé [9][14].
  • Niveau de confiance global: modéré à élevé (fort sur les fondamentaux techniques; plus faible sur l’exhaustivité lorsque l’audit n’était pas préconfiguré).

Problématique et objectifs

Question de recherche. Dans quelle mesure les journaux Windows EVTX permettent-ils de reconstruire de façon fiable un incident de sécurité (intrusion, persistance, suppression de traces), et sous quelles conditions probatoires?

Objectifs.

  1. Identifier les événements EVTX les plus utiles à la reconstruction.
  2. Définir une méthode de corrélation défendable techniquement.
  3. Évaluer les limites (anti-forensics, lacunes d’audit, volumétrie, ambiguïtés d’attribution).
  4. Proposer des garde-fous pour améliorer l’admissibilité et la robustesse analytique.

Méthodologie

  • Stratégie de recherche: revue ciblée de sources primaires (Microsoft, NIST, MITRE, RFC) + sources techniques spécialisées (SANS, outils EVTX open-source).
  • Critères d’inclusion: documentation officielle, standards/référentiels, pages techniques explicitant événements/commandes/champs exploitables; publication identifiable; cohérence inter-sources.
  • Critères d’exclusion: contenus non sourcés, billets promotionnels sans détail technique, pages introuvables/404, duplicats.
  • Nombre d’URL analysées: 14/100.
  • Évaluation de crédibilité (grille 0-10):
  • Très forte (8-10): Microsoft Learn, NIST, MITRE ATT&CK, RFC [1]–[11][14].
  • Acceptable avec corroboration (5-7): SANS, README d’outils [12][13].
  • Limites méthodologiques: extraction web partielle (aperçus tronqués), absence d’essais expérimentaux en labo dans ce livrable, dépendance à la télémétrie effectivement activée au moment des faits.

Cadre conceptuel / technique / juridique

Les EVTX représentent une trace système horodatée, structurée, et orientée “événement” (authentification, processus, gestion d’objets, etc.). Leur valeur forensique est surtout corrélative: ils deviennent probants lorsqu’ils sont recoupés entre canaux (Security, System, logs applicatifs) et entre hôtes [7][10].

Sur le plan de la gouvernance, NIST rappelle que la gestion de logs est un processus organisationnel (collecte, stockage, analyse, conservation), pas seulement un paramétrage technique [9].

Pour la conservation de preuve, les principes de collecte/archivage (chaîne de possession, ordre de volatilité, traçabilité des manipulations) restent déterminants pour la recevabilité et la contestabilité de l’analyse [14].

Analyse critique des résultats

1) Reconstruction de la séquence d’accès

Les événements 4624 (succès) et 4625 (échec) fournissent la base de la narration d’accès: type de logon, compte cible, origine réseau, et identifiants de session. Microsoft indique explicitement la possibilité de corrélation via Logon ID [1][2].

La politique d’audit “logon events” précise toutefois que la visibilité varie entre poste local et contrôleur de domaine; ignorer cette dualité mène à des chronologies incomplètes [7].

« This event is logged for any logon failure » (4625) [2].

2) Reconstruction de l’exécution et de la persistance

L’événement 4688 documente la création de processus (nom, parent, contexte de sécurité, parfois ligne de commande), essentiel pour relier un accès à une action technique [3]. Les événements 4698 (tâche planifiée) et 4720 (création de compte) matérialisent des étapes de persistance/escalade fréquentes [5][6].

En pratique, la chaîne analytique typique est: 4624/4625 -> 4688 -> 4698/4720, avec enrichissement par hôte, SID, et fenêtre temporelle [1][2][3][5][6].

« This event generates every time a new process starts » (4688) [3].

3) Détection d’anti-forensics et suppression de traces

L’événement 1102 (“audit log was cleared”) est explicitement recommandé par Microsoft pour surveillance active, car rarement légitime en opération courante [4]. La commande wevtutil cl constitue un vecteur natif d’effacement [11], aligné avec ATT&CK T1070.001 [13].

Ce point est critique: l’effacement d’un journal ne “supprime” pas la valeur probatoire; il crée un fait incriminant à corréler avec d’autres traces (WEF centralisé, logs réseau, EDR, SIEM) [10][13].

« Typically you should not see this event » (1102) [4].

4) Collecte à l’échelle et conservation

WEF/WEC est pertinent pour limiter la perte locale (rotation/altération) et augmenter la profondeur historique. Microsoft distingue un flux baseline et un flux “suspect” plus riche pour investigation [10]. Cette stratégie est cohérente avec NIST, qui insiste sur l’infrastructure et les processus de log management [9].

5) Outils d’extraction et qualité des preuves

Les parseurs EVTX (libevtx, evtx Rust) rendent l’extraction plus reproductible et scriptable, avec fonctionnalités de conversion et récupération partielle [12][13]. Néanmoins, la qualité de l’inférence demeure bornée par:

  • la configuration initiale d’audit,
  • la disponibilité des canaux,
  • la conservation des fichiers,
  • les actions adverses de nettoyage.

Autrement dit, un parseur performant n’annule pas un déficit de télémétrie.

Discussion

La reconstruction d’incident via EVTX est fiable pour établir des faits techniques observables (qui, quoi, quand, où) lorsque les événements clés sont présents et corrélés. La fiabilité baisse lorsque:

  1. l’audit n’était pas activé finement;
  2. les logs ont été effacés/écrasés;
  3. la collecte centralisée est absente;
  4. l’analyse confond causalité et simple coïncidence temporelle.

Implication pratique: pour un contexte litige/expertise, il faut documenter explicitement les “zones aveugles” plutôt que sur-étendre la conclusion. Une conclusion défendable est souvent probabiliste (“hautement compatible avec”) plutôt que catégorique.

Limites et incertitudes

  • Absence de validation expérimentale sur un jeu EVTX réel dans ce livrable.
  • Certaines pages web sont des vues synthétiques; les annexes techniques complètes peuvent exiger accès direct aux docs natives.
  • Variabilité importante entre environnements (poste isolé vs AD, politiques GPO, versions Windows).

Conclusion

Les journaux Windows EVTX restent une source de premier plan pour la reconstruction d’incident, à condition d’être exploités par corrélation multi-événements et multi-sources. Les événements d’authentification (4624/4625), d’exécution (4688), de persistance (4698/4720) et d’anti-forensics (1102) forment un noyau analytique robuste [1]–[6].

La robustesse probatoire dépend moins d’un “event ID magique” que de la qualité de la chaîne complète: configuration d’audit, centralisation (WEF), conservation, méthode d’analyse, et traçabilité de la collecte [9][10][14].

Références

  1. [4624(S) An account was successfully logged on.] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4624
  2. [4625(F) An account failed to log on.] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625
  3. [4688(S) A new process has been created.] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4688
  4. [1102(S) The audit log was cleared.] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-1102
  5. [4698(S) A scheduled task was created.] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698
  6. [4720(S) A user account was created.] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4720
  7. [Audit logon events.] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/basic-audit-logon-events
  8. [NIST SP 800-92 Rev.1 (Draft): Cybersecurity Log Management Planning Guide.] — NIST CSRC, 2023 — https://csrc.nist.gov/pubs/sp/800/92/r1/ipd
  9. [NIST SP 800-92: Guide to Computer Security Log Management.] — NIST, 2006 — https://csrc.nist.gov/pubs/sp/800/92/final
  10. [Use Windows Event Forwarding to help with intrusion detection.] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection
  11. [wevtutil command reference.] — Microsoft Learn, s.d — https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wevtutil
  12. [libevtx: Library and tools to access the Windows XML Event Log (EVTX) format.] — GitHub/libyal, s.d — https://github.com/libyal/libevtx
  13. [MITRE ATT&CK T1070.001: Indicator Removal – Clear Windows Event Logs.] — MITRE ATT&CK, s.d — https://attack.mitre.org/techniques/T1070/001/
  14. [RFC 3227: Guidelines for Evidence Collection and Archiving.] — IETF, 2002 — https://www.rfc-editor.org/rfc/rfc3227

Articles qui pourraient vous intéresser