Premiers pas en investigation forensique Windows

L'investigation forensique Windows consiste à reconstituer ce qui s'est passé sur un système à partir des traces qu'il laisse. Rançongiciel, vol de données par un employé, compte administrateur compromis ou simple connexion suspecte : dans tous les cas, le système d'exploitation a enregistré bien plus que ce que l'attaquant ou l'utilisateur imagine. Ce guide sert de point d'entrée à tout le site. Il présente l'état d'esprit de l'enquêteur, ce qu'il faut collecter et dans quel ordre, les grands domaines de preuves (chacun renvoyant vers son guide dédié), les outils gratuits utilisés par les professionnels et un plan concret pour les 48 premières heures d'un dossier.

Ce qu'est la forensique Windows

La forensique est avant tout une reconstruction rigoureuse. On collecte des preuves, on préserve leur intégrité, on les analyse, puis on présente des conclusions qu'un autre analyste pourrait reproduire à partir des mêmes données. Windows est une cible riche : il garde la trace de l'exécution des programmes, de l'accès aux fichiers et dossiers, des branchements USB, des connexions réseau, des ouvertures de session et des mécanismes de persistance, répartis dans des dizaines de ruches de registre, de journaux d'événements, de bases de données et de structures du système de fichiers. La plupart de ces traces existent pour des raisons de performance ou de compatibilité, pas de sécurité, et c'est justement pour cela que les attaquants les oublient.

Le DFIR (Digital Forensics and Incident Response) combine deux objectifs parfois contradictoires. La réponse à incident veut des réponses vite, pour contenir et redémarrer l'activité. La forensique veut des preuves traitées avec soin, pour que les conclusions tiennent. Un bon praticien fait les deux : il avance vite, mais jamais d'une manière qui détruit des preuves ou rend une conclusion indéfendable.

L'état d'esprit DFIR

Quelques réflexes distinguent une enquête solide d'une suite de suppositions.

Travailler par hypothèses

Partez de la question posée (« l'attaquant a-t-il atteint le serveur de la comptabilité ? ») et transformez-la en hypothèses vérifiables (« une ouverture de session interactive depuis le poste compromis vers FIN-SRV01 a eu lieu entre le 1er et le 3 juin »). Cherchez ensuite les artefacts qui confirment ou réfutent chacune d'elles. Décider à l'avance de ce qui s'est passé puis chercher des confirmations, c'est le meilleur moyen de passer à côté d'une explication innocente.

Corréler, ne jamais se fier à un seul artefact

Un point isolé est une piste. Trois artefacts indépendants qui vont dans le même sens constituent une preuve. Une entrée Prefetch, un SHA-1 dans Amcache et un événement Security 4688 pour le même binaire racontent une histoire bien plus solide que chacun pris seul. L'indépendance compte : deux outils qui lisent la même valeur de registre restent une seule source.

Respecter l'ordre de volatilité

Capturez d'abord les preuves les plus fragiles. L'ordre de volatilité, formalisé dans la RFC 3227, se présente à peu près ainsi :

1. Registres et cache du processeur
2. Mémoire vive : processus, connexions réseau, vision du noyau sur le système
3. État temporaire : routage, cache ARP, sessions ouvertes
4. Disque : système de fichiers, registre, journaux d'événements
5. Journaux distants et supervision (SIEM, EDR, pare-feu)
6. Sauvegardes et supports d'archivage

C'est pourquoi la capture mémoire passe avant tout arrêt de la machine. Une image de la RAM peut révéler du code injecté, des charges déchiffrées et des connexions actives qui n'ont jamais touché le disque.

Tout documenter

Notez les empreintes, les horodatages, les versions d'outils, les commandes exactes et qui a manipulé quoi. Tenez une chaîne de traçabilité pour chaque élément. Vos notes font partie des preuves : si vous ne pouvez pas expliquer comment vous êtes arrivé à une conclusion, elle ne résistera pas à la contradiction.

Raisonner en UTC

Windows stocke la plupart des horodatages en valeurs FILETIME, en UTC, mais certains artefacts, outils et exports utilisent l'heure locale. Vérifiez le fuseau du système dans la ruche SYSTEM (ControlSet00x\Control\TimeZoneInformation), ramenez tout en UTC pendant l'analyse et précisez le fuseau dans le rapport. L'entrée UTC et heure locale détaille les pièges.

Que collecter

On a rarement le temps de tout prendre, et on en a rarement besoin. Décidez en fonction des questions et du contexte juridique.

Une collecte de triage récupère en quelques minutes les fichiers à forte valeur (ruches de registre, journaux d'événements, $MFT, $UsnJrnl, Prefetch, Amcache, SRUM, bases des navigateurs, fichiers LNK et Jump Lists des profils), y compris les fichiers verrouillés grâce à un accès NTFS brut. Pour une image complète, branchez le support source derrière un bloqueur d'écriture, produisez une image E01 ou brute et calculez son empreinte immédiatement.

# Vérifier l'empreinte d'une image par rapport au journal d'acquisition
Get-FileHash -Algorithm SHA256 .\evidence.E01

# Triage KAPE d'un poste allumé vers un conteneur VHDX
.\kape.exe --tsource C: --tdest D:\triage\HOST01 --target !SANS_Triage --vhdx HOST01 --vss

L'option --vss collecte aussi les clichés instantanés (Volume Shadow Copies), qui conservent souvent d'anciennes versions des ruches et des journaux que l'attaquant a nettoyés. Pour le détail des targets, des modules, de la collecte à distance et de la conservation, lisez acquisition et triage avec KAPE et Velociraptor.

Les grands domaines de preuves

Chaque artefact du site relève d'un ou plusieurs de ces domaines, et chacun a son guide.

Registre

Le registre est un ensemble de fichiers de ruches (SYSTEM, SOFTWARE, SAM, SECURITY, NTUSER.DAT, UsrClass.dat) qui contiennent la configuration, l'activité des utilisateurs et des traces d'exécution. Les dates de dernière écriture des clés aident à dater les modifications. Commencez par la forensique du registre Windows.

Journaux d'événements

Les fichiers .evtx de C:\Windows\System32\winevt\Logs enregistrent ouvertures de session, installations de services, création de processus (si l'audit est activé), PowerShell et bien plus. Connaître les principaux identifiants d'événements est indispensable. Voir la forensique des journaux d'événements Windows.

Preuves d'exécution

Le programme a-t-il réellement tourné, ou était-il seulement présent sur le disque ? Prefetch, Amcache, ShimCache, BAM, UserAssist, SRUM et d'autres répondent avec des niveaux de certitude très différents. Le guide des preuves d'exécution les compare côte à côte.

NTFS et système de fichiers

La Master File Table, le journal USN et le $LogFile gardent la trace des créations, renommages et suppressions de fichiers, souvent longtemps après leur disparition. Lisez la forensique NTFS : $MFT, USN et $LogFile.

Activité utilisateur

Les ShellBags, fichiers LNK, Jump Lists et clés MRU montrent quels dossiers et fichiers un utilisateur a ouverts, y compris sur des supports amovibles et des partages réseau. Voir activité utilisateur : ShellBags, LNK et Jump Lists.

Persistance

Clés Run, services, tâches planifiées et abonnements WMI permettent à un attaquant de survivre à un redémarrage. Traquer la persistance sous Windows passe en revue chaque mécanisme et explique comment repérer l'entrée malveillante parmi des centaines d'entrées légitimes.

Mouvement latéral

RDP, PsExec, WMI et WinRM laissent des traces sur la machine source comme sur la cible. La forensique du mouvement latéral indique quels artefacts apparaissent où.

USB et périphériques externes

Le registre, setupapi.dev.log et les journaux d'événements indiquent quels périphériques ont été branchés, quand et par qui. Voir la forensique des périphériques USB.

Mémoire

La RAM montre ce qui tournait au moment de l'acquisition : processus, code injecté, connexions réseau, lignes de commande. La forensique mémoire Windows avec Volatility couvre l'acquisition et les plugins essentiels.

Anti-forensique

Effacement des journaux, timestomping, suppression sécurisée et journalisation désactivée laissent leurs propres traces. Détecter l'anti-forensique sous Windows explique quoi chercher.

Chronologies

Une super timeline rassemble tout ce qui précède dans une seule vue chronologique. Construire une super timeline avec Plaso montre comment la produire et la filtrer.

La boîte à outils gratuite

Une enquête complète est possible sans aucune licence commerciale.

# Télécharger ou mettre à jour tous les EZ Tools (versions .NET 6+)
.\Get-ZimmermanTools.ps1 -Dest C:\Tools\EZ -NetVersion 6

# Parser une collecte KAPE avec l'ensemble de modules EZ Tools
.\kape.exe --msource D:\triage\HOST01 --mdest D:\parsed\HOST01 --module !EZParser

# Premier regard sur une image mémoire avec Volatility 3
vol -f HOST01.raw windows.info
vol -f HOST01.raw windows.pstree
vol -f HOST01.raw windows.netscan
vol -f HOST01.raw windows.cmdline

Les parseurs en ligne sont parfaits quand vous avez un fichier et une question, par exemple un .pf reçu en pièce jointe. Pour traiter un poste entier, les outils en ligne de commande restent la référence, et leurs résultats sont plus faciles à reproduire.

Plan d'action des 48 premières heures

Heures 0 à 4 : cadrer et préserver

1. Validez les questions, le périmètre et les contraintes juridiques. Ouvrez le journal d'enquête dès maintenant.
2. Identifiez les machines touchées à partir des alertes, de l'EDR et du SIEM. Demandez à l'équipe réseau de préserver les journaux pare-feu, proxy, VPN et DNS avant leur rotation.
3. Pour chaque machine allumée et potentiellement compromise : capture mémoire d'abord, puis collecte de triage. Isolez-la (idéalement via l'EDR) plutôt que de l'éteindre.
4. Calculez l'empreinte de tout ce que vous collectez et consignez-la dans la chaîne de traçabilité.

Heures 4 à 12 : trier et trouver un point d'ancrage

1. Parsez les collectes avec les modules KAPE ou les EZ Tools.
2. Cherchez un point d'ancrage : un événement malveillant confirmé et horodaté (une alerte, une ouverture de session 4624 de type 10 suspecte, un nouveau service 7045, un binaire connu comme malveillant dans Amcache).
3. Vérifiez les classiques : artefacts d'exécution, emplacements de persistance, connexions RDP et distantes, journaux PowerShell.

Heures 12 à 36 : élargir à partir de l'ancrage

1. Construisez une chronologie autour de l'ancrage, quelques heures avant et après, puis élargissez.
2. Pivotez sur chaque nouvel indicateur : comptes, IP sources, noms de fichiers, empreintes, noms de services. Recherchez-les sur les autres machines avec des hunts Velociraptor.
3. Consignez les constats dans un tableau simple : heure (UTC), machine, artefact, événement, fichier source, niveau de confiance.

Heures 36 à 48 : consolider

1. Testez explicitement chaque hypothèse : confirmée, réfutée ou non tranchée, et pourquoi.
2. Décidez ce qui nécessite une image complète ou une analyse approfondie.
3. Rédigez un rapport intermédiaire : ce qui est établi, ce qui est suspecté, ce qui reste inconnu, et les prochaines étapes.

Pièges à éviter

• Éteindre d'abord. Couper l'alimentation avant la capture mémoire détruit les preuves volatiles et peut faire perdre des données de registre non encore écrites.
• Lancer les outils depuis le disque suspect. Exécutez les collecteurs depuis un support externe ou un partage réseau, et écrivez les résultats ailleurs.
• Confondre présence et exécution. Une entrée ShimCache ou Amcache prouve qu'un fichier a été vu, pas forcément qu'il a tourné.
• Mélanger les fuseaux horaires. Un décalage d'une ou deux heures entre sources réordonne silencieusement les événements.
• Oublier les clichés instantanés et la mémoire. Les journaux supprimés et les anciennes ruches survivent souvent dans les VSS ; les entrées ShimCache récentes ne vivent qu'en RAM jusqu'à l'arrêt.
• Laisser expirer les journaux. Les journaux d'événements tournent selon leur taille, ceux du cloud et du réseau selon leur rétention. Préservez-les dès le premier jour.
• Conclure sur un seul artefact. Si une seule source étaye un constat, dites-le dans le rapport.

Liste de contrôle

• Questions et périmètre écrits, journal d'enquête ouvert
• Préservation des journaux distants demandée
• Mémoire capturée sur les machines allumées avant tout arrêt
• Collecte de triage (avec VSS) sur chaque machine du périmètre, empreinte calculée et consignée
• Collectes parsées, fuseau du système vérifié, analyse en UTC
• Au moins un point d'ancrage identifié et replacé dans une chronologie
• Chaque conclusion étayée par au moins deux artefacts indépendants
• Rapport intermédiaire avec hypothèses confirmées, réfutées et ouvertes

Gardez l'aide-mémoire des artefacts Windows sous la main : il liste chaque artefact du site avec son emplacement, ce qu'il prouve et comment le collecter. Pour vous entraîner, créez une image d'une VM de test, lancez un programme anodin et essayez de prouver quand il a été exécuté, à l'aide du guide suivant sur les preuves d'exécution.