Acquisition et triage Windows avec KAPE et Velociraptor

Ce guide explique comment acquérir des preuves sur un système Windows en commençant par les données les plus volatiles, puis comment faire l'image ou le triage du disque sans perdre ce que vous venez de préserver. À la fin, vous saurez choisir entre acquisition à chaud et à froid, capturer la mémoire, imager un disque (BitLocker compris), lancer des collectes de triage avec KAPE et Velociraptor, traiter les VM cloud et tout documenter pour que les preuves tiennent.

L'ordre de volatilité sous Windows

La RFC 3227 a formalisé un principe simple : on collecte d'abord ce qui disparaît le plus vite. Sur un hôte Windows allumé, l'ordre de volatilité ressemble à ceci :

Ce tableau est un repère, pas une règle absolue. Si vous n'avez qu'une seule occasion d'accéder à un portable qui doit être rendu dans l'heure, une collecte de triage bien ciblée peut valoir plus qu'une image mémoire parfaite. L'essentiel est de choisir en connaissance de cause et de noter pourquoi.

Acquisition à chaud ou à froid

Une acquisition à froid (dead-box) se fait sur un système éteint : on image le disque derrière un bloqueur d'écriture. C'est l'option la plus propre du point de vue de l'intégrité, mais on perd la mémoire et, sur un disque chiffré, potentiellement l'accès aux données.

Une acquisition à chaud (live) consiste à exécuter des outils sur le système en fonctionnement. Chaque action laisse une trace : votre outil crée des entrées Prefetch, des clés de registre, des événements et des allocations mémoire. C'est acceptable si vous limitez l'empreinte (outils lancés depuis un support externe, sortie écrite sur un support externe ou un partage réseau) et si vous notez ce que vous avez lancé et quand, pour que l'analyste puisse ensuite distinguer vos actions de celles de l'attaquant.

En réponse à incident, l'acquisition à chaud est la norme : on ne peut pas toujours arrêter un serveur, BitLocker est de plus en plus répandu, et la mémoire contient souvent la seule trace d'un malware sans fichier. L'acquisition à froid reste la référence pour les équipements saisis dans le cadre judiciaire ou RH, quand la machine est déjà éteinte.

Règle pratique : si c'est allumé, laissez allumé jusqu'à la capture mémoire ; si c'est éteint, laissez éteint et imagez à froid.

La mémoire d'abord

La mémoire contient les processus en cours, les connexions réseau, les pilotes chargés, l'historique de commandes, du contenu déchiffré et souvent des clés de chiffrement. C'est aussi la première chose perdue. Capturez-la avant toute action susceptible de provoquer un redémarrage ou de modifier fortement l'état du système.

Outils courants :

• WinPmem (Velocidex, open source) : en ligne de commande, produit une image brute. Le projet est passé d'une version C (winpmem_mini) à une réécriture en Go, et la syntaxe change d'une version à l'autre : vérifiez le README de la build que vous emportez.
• DumpIt (désormais distribué par Magnet Forensics) : un seul exécutable, très peu d'interaction, pratique à confier à un non-spécialiste sur place.
• Magnet RAM Capture : outil graphique gratuit, image brute.

# WinPmem (version winpmem_mini) : image brute vers un support externe
E:\tools\winpmem_mini_x64_rc2.exe E:\case\HOST01\mem.raw

# Calculer le hash immédiatement et le consigner
Get-FileHash E:\case\HOST01\mem.raw -Algorithm SHA256 | Format-List

Points pratiques :

• Écrivez l'image sur un support externe ou réseau, jamais sur le disque du système suspect : vous écraseriez de l'espace non alloué qui peut contenir des preuves supprimées.
• Prévoyez une image de la taille de la RAM installée et vérifiez l'espace libre avant de commencer.
• Les pilotes d'acquisition exigent les droits administrateur. Des pilotes anciens peuvent refuser de se charger, voire déstabiliser le système, quand l'intégrité de la mémoire (HVCI) ou d'autres fonctions de sécurité basées sur la virtualisation sont actives. Testez votre boîte à outils sur les builds Windows récentes avant l'incident, pas pendant.
• Après la mémoire, récupérez hiberfil.sys et pagefile.sys sur le disque : ils contiennent des pages mémoire plus anciennes qui complètent l'image live.

L'analyse de l'image est traitée dans la forensique mémoire Windows avec Volatility.

Image disque

Outils et formats

FTK Imager (Exterro) est le choix habituel sous Windows : il image disques physiques, volumes logiques et même la mémoire, et vérifie le résultat. Sous Linux, ewfacquire (libewf) et dc3dd ou dd font le même travail.

# Linux : image E01 d'un disque derrière bloqueur, avec saisie des métadonnées
ewfacquire -t /cases/HOST01/disk -f encase6 /dev/sdb

# Vérifier le hash stocké par rapport au contenu de l'image
ewfverify /cases/HOST01/disk.E01

# Alternative brute avec dc3dd, hash à la volée
dc3dd if=/dev/sdb of=/cases/HOST01/disk.raw hash=sha256 log=/cases/HOST01/dc3dd.log

Hash et bloqueurs d'écriture

Calculez le hash de la source et de l'image, et consignez les deux. MD5 et SHA-1 restent courants dans les outils forensiques pour des raisons de compatibilité ; ajoutez SHA-256 quand l'outil le permet. Le hash prouve l'intégrité à partir de l'acquisition : il ne prouve pas que la source n'a pas été modifiée avant votre arrivée, d'où l'importance de vos notes.

À froid, branchez le disque via un bloqueur d'écriture matériel. Le blocage logiciel existe, mais il dépend du bon comportement du système d'exploitation. Sous Linux, monter en lecture seule ne suffit pas car certains systèmes de fichiers rejouent leur journal au montage : utilisez blockdev --setro et ne montez pas la source pendant l'acquisition.

Stockage soudé, formats NVMe atypiques et chiffrement lié au matériel rendent le démontage du disque impraticable sur beaucoup de portables récents. Dans ce cas, une image à chaud depuis le système en fonctionnement, ou un démarrage sur un environnement forensique, peut être la seule voie.

BitLocker

BitLocker bouleverse le plan d'acquisition plus que tout autre facteur. Sous Windows 11, le chiffrement de l'appareil (Device Encryption) s'active automatiquement sur de nombreux postes grand public et professionnels, avec une clé de récupération souvent sauvegardée dans un compte Microsoft, Active Directory ou Entra ID. Partez du principe que le disque est chiffré jusqu'à preuve du contraire.

Vérifiez l'état sur le système allumé avant toute action irréversible :

manage-bde -status
# Mot de passe de récupération et autres protecteurs du volume système
manage-bde -protectors -get C:

Vos options, par ordre de préférence :

1. Le système tourne et le volume est déverrouillé : capturez la mémoire, puis faites une image logique du volume (« Logical Drive » dans FTK Imager) ou une collecte de triage. Windows déchiffre de façon transparente, vous obtenez donc les données en clair. Une image physique du même disque ne contiendra que du texte chiffré.
2. Vous avez le mot de passe de récupération : via manage-bde, AD (objets msFVE-RecoveryInformation), Entra ID, Intune ou le compte Microsoft de l'utilisateur. Consignez-le et imagez à froid. Des outils comme bdemount (libbde) ou Arsenal Image Mounter permettent ensuite de déverrouiller l'image.
3. Pas de clé et système éteint : vous n'avez que du chiffré. Ne rallumez pas la machine au hasard : un protecteur TPM seul la déverrouillera au démarrage, mais le démarrage modifie le système.

# Monter une image chiffrée BitLocker avec son mot de passe de récupération (libbde)
bdemount -r 123456-123456-123456-123456-123456-123456-123456-123456 disk.raw /mnt/bde

Le même raisonnement vaut pour les solutions de chiffrement tierces : si c'est déverrouillé maintenant, c'est votre fenêtre.

Collecte de triage avec KAPE

Une collecte de triage copie les fichiers qui répondent à la plupart des questions (registre, journaux d'événements, métadonnées NTFS, artefacts d'exécution et d'activité utilisateur) en quelques minutes au lieu de plusieurs heures. KAPE (Kroll Artifact Parser and Extractor, d'Eric Zimmerman) est l'outil de référence sous Windows. Vérifiez sa licence si vous l'utilisez dans le cadre de missions facturées.

KAPE fonctionne en deux temps :

• Les targets (.tkape) décrivent quoi collecter : chemins, masques de fichiers, récursivité. Les targets composées en regroupent d'autres ; les noms qui commencent par ! désignent par convention des collections prêtes à l'emploi comme !SANS_Triage et !BasicCollection. KapeTriage est une autre target composée très utilisée.
• Les modules (.mkape) décrivent quoi exécuter sur les données collectées, généralement les parseurs d'Eric Zimmerman via le module composé !EZParser.

# Collecter depuis le volume C: allumé, shadow copies incluses, dans un conteneur VHDX
kape.exe --tsource C: --tdest E:\case\HOST01\tout --target !SANS_Triage --vss --vhdx HOST01

# Parser la collecte ensuite, sur le poste d'analyse
kape.exe --msource E:\case\HOST01\tout --mdest E:\case\HOST01\mout --module !EZParser

Quelques précisions sur les options :

• --vss demande à KAPE de collecter aussi depuis chaque shadow copy du volume source, en dédoublonnant les fichiers identiques. On récupère souvent ainsi des ruches et des journaux plus anciens ; en contrepartie, la collecte est plus lente et plus volumineuse. Voir les volume shadow copies.
• --vhdx ou --zip regroupe la sortie dans un conteneur unique, plus simple à hacher et à transporter.
• --tsource peut pointer vers une image montée aussi bien que vers un volume live : les mêmes targets servent donc à froid.
• Fichiers verrouillés : ruches, $MFT, journaux d'événements et journal USN sont utilisés en permanence sur un système allumé. KAPE détecte les fichiers verrouillés et les lit directement sur le volume NTFS brut, ce qui donne une copie exploitable sans arrêter de service.

Lancez kape.exe --sync sur votre poste d'analyse (avec accès Internet) pour mettre à jour targets et modules depuis le dépôt KapeFiles avant de préparer votre kit de terrain.

Collecte de triage avec Velociraptor

Velociraptor est un agent et un framework de collecte open source. C'est le meilleur choix pour collecter sur de nombreux postes, chasser sur tout le parc ou exécuter une logique de collecte qui va au-delà de la copie de fichiers.

L'équivalent des targets KAPE est l'artefact Windows.KapeFiles.Targets, qui réutilise les définitions de KapeFiles. Dans les versions récentes, il a été remplacé par Windows.Triage.Targets et les noms de paramètres ont changé d'une version à l'autre : inspectez l'artefact sur la version que vous utilisez.

# Afficher la définition de l'artefact et ses paramètres pour cette build
velociraptor.exe artifacts show Windows.KapeFiles.Targets

# Collecter en local, sans serveur (les noms de paramètres varient selon la version)
velociraptor.exe artifacts collect Windows.KapeFiles.Targets --args _SANS_Triage=Y --output E:\case\HOST01.zip

Velociraptor lit les fichiers verrouillés via son accessor ntfs, qui analyse directement le volume. C'est aussi ainsi qu'il collecte la $MFT, $UsnJrnl:$J et les flux de données alternatifs.

Collecteur hors ligne

Quand vous ne pouvez pas déployer d'agent (pas de chemin réseau, machine d'un tiers, site isolé), générez un collecteur hors ligne (offline collector) depuis l'interface du serveur : choisissez les artefacts et leurs paramètres, la destination (ZIP local, ou envoi vers S3, un blob Azure, SFTP), et Velociraptor produit un exécutable unique préconfiguré. N'importe qui peut le lancer en administrateur ; il écrit un Collection-<hôte>-<horodatage>.zip contenant les fichiers et un journal de ce qu'il a fait. Ce ZIP peut ensuite être importé dans un serveur pour l'analyse. Pensez à chiffrer le conteneur de sortie avec un certificat : une collecte de triage contient des éléments sensibles (SAM, SECURITY, données de navigateur).

KAPE ou Velociraptor ?

Beaucoup d'équipes utilisent les deux : Velociraptor pour délimiter le périmètre sur tout le parc, KAPE pour les collectes approfondies sur un poste, et les mêmes sorties parsées alimentent une super timeline.

Machines virtuelles dans le cloud

Pour une VM Windows chez AWS, Azure ou Google Cloud, vous ne touchez pas au matériel. L'équivalent de l'image disque est un snapshot du disque virtuel :

# AWS : snapshot du volume EBS, étiqueté avec le numéro de dossier
aws ec2 create-snapshot --volume-id vol-0abc123 --description "CASE-2026-041 HOST01 C:" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=case,Value=CASE-2026-041}]'

# Azure : snapshot d'un disque managé, puis URL SAS temporaire pour exporter le VHD
az snapshot create --resource-group rg-ir --name host01-os-snap --source /subscriptions/<sub>/resourceGroups/rg-prod/providers/Microsoft.Compute/disks/host01-os
az snapshot grant-access --resource-group rg-ir --name host01-os-snap --duration-in-seconds 3600

Ce qu'il faut anticiper :

• La mémoire d'abord, toujours : les fournisseurs ne donnent généralement pas accès à un dump mémoire au niveau de l'hyperviseur. Lancez WinPmem ou un artefact mémoire Velociraptor dans l'invité avant le snapshot ou toute isolation qui arrêterait la VM.
• Isoler sans éteindre : restreignez le security group ou le network security group plutôt que d'arrêter l'instance.
• Cohérence « crash » : le snapshot d'une VM en marche équivaut à un arrachage de prise. Attendez-vous à des ruches « sales » et à des journaux NTFS à rejouer.
• Chiffrement et partage : chez AWS, un snapshot chiffré avec la clé gérée par défaut ne peut pas être partagé avec un autre compte ; copiez-le d'abord avec une clé KMS gérée par le client. Azure Disk Encryption sous Windows, c'est BitLocker dans l'invité avec les clés dans Key Vault : récupérez-les avant d'en avoir besoin.
• Hash : un objet snapshot ne se hache pas directement. Créez-en un volume dans un compte forensique isolé, attachez-le à une instance d'analyse, imagez-le et hachez cette image.
• Journaux cloud : CloudTrail, Azure Activity Log et équivalents sont aussi des preuves, et ils enregistrent vos propres actions de snapshot, ce qui aide la chronologie.

Chaîne de possession et documentation

Une preuve dont on ne peut pas retracer le parcours est une preuve contestable. Tenez un registre de chaîne de possession et des notes prises sur le moment, qui couvrent :

• Qui a collecté quoi, sur quel système (nom d'hôte, numéro de série, étiquette d'inventaire, identifiant d'instance cloud), où et quand, avec des heures en UTC et le décalage d'horloge observé sur le système (voir UTC et heure locale).
• Les commandes exactes et les versions d'outils utilisées, dans l'ordre. Vos actions apparaîtront dans les preuves ; vos notes les expliquent.
• Le hash de chaque image et conteneur à l'acquisition, puis à chaque changement de main.
• Le stockage : où se trouvent les preuves, qui y a accès, et chaque transfert avec signature ou référence de ticket.
• Les décisions et écarts : pourquoi la mémoire n'a pas été capturée, pourquoi un triage plutôt qu'une image complète, pourquoi une étape a échoué.

Erreurs fréquentes

• Éteindre pour « préserver » les preuves : vous perdez la mémoire et peut-être l'accès aux données protégées par BitLocker.
• Écrire la sortie sur le disque suspect : cela écrase l'espace non alloué et pollue la MFT.
• Image physique d'un volume BitLocker déverrouillé sans la clé : vous repartez avec du chiffré.
• Copier les ruches sans leurs .LOG1/.LOG2 : les modifications récentes peuvent n'exister que dans les journaux de transactions. Voir la forensique du Registre Windows.
• Partir avec une boîte à outils périmée : des targets KAPE obsolètes ratent les nouveaux emplacements d'artefacts ; d'anciens pilotes mémoire échouent sur les builds actuelles.
• Ni hash ni notes : la collecte reste utile pour l'enquête mais fragile comme preuve.

Check-list d'acquisition

1. Relevez la scène : état du système, écran, connexions réseau, heure et décalage d'horloge. Photographiez le matériel.
2. Choisissez à chaud ou à froid, et notez pourquoi.
3. À chaud : capturez la mémoire sur un support externe et calculez son hash.
4. Vérifiez BitLocker avec manage-bde -status ; récupérez le mot de passe de récupération sur le poste ou dans l'annuaire.
5. Collectez l'état volatil (processus, réseau, sessions) avec Velociraptor ou des commandes validées.
6. Lancez une collecte de triage (KAPE !SANS_Triage ou Velociraptor) avec les shadow copies ; hachez le conteneur.
7. Si nécessaire, faites une image complète (logique si le volume est chiffré et déverrouillé, physique sinon) et vérifiez-la.
8. Pour une VM cloud : mémoire dans l'invité, isolation par règles réseau, snapshot, copie vers un compte forensique, image et hash.
9. Complétez le registre de chaîne de possession et stockez les preuves sur un support à accès contrôlé.
10. Analysez des copies, jamais les originaux : par exemple avec les artefacts de preuves d'exécution et une super timeline.

Pour replacer ces collectes dans le déroulé global d'une enquête, voir Premiers pas en investigation forensique Windows.