Live response Windows : quoi capturer, et dans quel ordre

Couper l'alimentation d'un hôte Windows compromis détruit les processus en cours, les connexions réseau actives, les sessions ouvertes et les volumes déchiffrés qui expliquent souvent ce que faisait l'attaquant. Ce guide montre comment choisir entre live response et imagerie directe, quoi capturer et dans quel ordre, à quels outils se fier et comment documenter l'empreinte que vous laissez. Vous repartirez avec une checklist de collecte qui fonctionne sur un portable isolé comme sur un parc entier.

C'est l'équivalent Windows d'un playbook de live response Linux, et il se place entre le guide de démarrage et le guide de tri avec KAPE et Velociraptor de cette série.

Live response ou imagerie directe ?

Passez en live quand l'état volatil compte pour les questions auxquelles vous devez répondre, ce qui est le cas de la plupart des intrusions :

• Compromission active : un beacon, un shell distant ou un opérateur interactif. Les connexions, les lignes de commande et le code injecté n'existent qu'en RAM.
• Chiffrement intégral du disque : si BitLocker ou un produit tiers est déverrouillé maintenant, une image faite machine éteinte peut être illisible sans clé de récupération. Vérifiez avec manage-bde -status avant que quiconque touche à l'alimentation.
• Serveurs impossibles à arrêter : contrôleurs de domaine, hyperviseurs et bases de production sont en général triés en live et imagés plus tard, voire jamais.
• Volume : cinquante hôtes suspects se trient à distance, ils ne s'imagent pas.

Imagez d'abord (ou uniquement) quand l'affaire a de bonnes chances d'aller devant un tribunal avec des exigences probatoires strictes et qu'aucune question ne porte sur l'état volatil, quand l'hôte est déjà éteint (ne le rallumez pas « pour voir »), ou quand vous soupçonnez un malware destructeur déclenché par l'activité. Consignez votre raisonnement dans tous les cas : vos notes de chaîne de possession doivent expliquer pourquoi vous avez touché un système en fonctionnement.

L'ordre de volatilité sous Windows

La RFC 3227 pose le principe : on collecte d'abord ce qui est le plus volatil. Appliqué à Windows, l'ordre de volatilité donne ceci :

En pratique, les étapes 2 à 7 prennent quelques minutes avec un script : leur ordre interne compte moins que le fait de prendre la mémoire en premier et de ne pas redémarrer.

Préparer des outils de confiance

Ne lancez jamais d'outils depuis le disque suspect. Un attaquant peut placer un binaire piégé plus tôt dans le PATH, détourner une DLL voisine ou modifier les profils PowerShell. Montez un kit de réponse sur un support en lecture seule ou dédié, ou poussez-le via votre EDR :

• Des binaires autonomes ou liés statiquement si possible (WinPmem, Sysinternals, Velociraptor).
• Des appels par chemin complet, y compris pour les binaires natifs : C:\Windows\System32\netstat.exe, pas netstat.
• PowerShell lancé avec -NoProfile -ExecutionPolicy Bypass pour que les profils utilisateur et machine ne s'exécutent pas.
• Toutes les sorties écrites sur un support externe ou réseau, jamais sur le C: suspect, où elles écraseraient de l'espace non alloué que vous voudrez peut-être carver plus tard.
• L'horloge de l'analyste et celle de l'hôte relevées au départ. w32tm /query /status et un horodatage UTC permettent de corriger un décalage ensuite (voir UTC et heure locale).

# En-tête de session : qui, où, quand (UTC) et source de temps
$Out = 'E:\IR\HOST01'
New-Item -ItemType Directory -Path $Out -Force | Out-Null
"Analyst: $env:USERNAME  Host: $env:COMPUTERNAME  UTC: $((Get-Date).ToUniversalTime().ToString('o'))" |
  Out-File "$Out\00_header.txt"
w32tm /query /status >> "$Out\00_header.txt"
manage-bde -status   >> "$Out\00_header.txt"

Étape 1 : acquérir la mémoire en premier

La mémoire contient l'arborescence des processus, y compris ceux terminés ou masqués, les structures réseau, l'historique des commandes, des données déchiffrées et du code injecté qu'aucun artefact disque ne montrera. Acquérez-la avant toute autre commande, car chacune la modifie.

# WinPmem (le nom exact du binaire dépend de la version téléchargée)
E:\tools\winpmem_mini_x64.exe E:\IR\HOST01\mem.raw

# Hachage immédiat
Get-FileHash -Algorithm SHA256 E:\IR\HOST01\mem.raw |
  Export-Csv E:\IR\HOST01\hashes.csv -NoTypeInformation -Append

Les outils d'acquisition mémoire chargent un pilote noyau, ce qui crée en général un service et un événement 7045 dans le journal System. C'est attendu : notez-le. Si vous ne pouvez pas acquérir la mémoire (pas d'outil validé, pilote bloqué), collectez au moins hiberfil.sys et pagefile.sys plus tard avec un outil de copie brute, et gardez en tête que la sortie live devient votre seule vue sur l'état volatil. L'analyse est traitée dans le guide d'analyse mémoire.

Étape 2 : processus, réseau et sessions

Processus avec lignes de commande et parents

tasklist n'affiche ni les lignes de commande ni les parents. Passez par CIM, qui renvoie les deux avec le chemin de l'exécutable et l'heure de création :

Get-CimInstance Win32_Process |
  Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine,
    @{n='Created';e={$_.CreationDate.ToUniversalTime().ToString('o')}} |
  Export-Csv "$Out\processes.csv" -NoTypeInformation

tasklist /svc /fo csv > "$Out\tasklist_svc.csv"   # services hébergés par chaque svchost

Les lignes de commande des processus protégés ou appartenant à d'autres utilisateurs exigent une invite élevée. Sysinternals pslist -t donne une vue arborescente, et sigcheck peut hacher et vérifier la signature de chaque image en cours d'exécution.

Connexions réseau et PID propriétaires

Get-NetTCPConnection |
  Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State, OwningProcess, CreationTime |
  Export-Csv "$Out\tcp.csv" -NoTypeInformation
Get-NetUDPEndpoint | Select-Object LocalAddress, LocalPort, OwningProcess, CreationTime |
  Export-Csv "$Out\udp.csv" -NoTypeInformation

C:\Windows\System32\netstat.exe -anob > "$Out\netstat_anob.txt"   # -b exige l'élévation

Croisez OwningProcess avec la liste des processus : un rundll32.exe ou un powershell.exe avec une connexion établie vers une IP externe est déjà une piste en soi.

Sessions, partages et état réseau en cache

quser                         > "$Out\sessions_quser.txt"
qwinsta                       >> "$Out\sessions_quser.txt"
net session                   > "$Out\net_session.txt"    # sessions SMB entrantes
net use                       > "$Out\net_use.txt"        # lecteurs mappés sortants
klist sessions                > "$Out\klist_sessions.txt" # sessions d'ouverture et LUID
Get-SmbShare | Export-Csv "$Out\smb_shares.csv" -NoTypeInformation
Get-DnsClientCache | Export-Csv "$Out\dns_cache.csv" -NoTypeInformation
Get-NetNeighbor    | Export-Csv "$Out\arp.csv" -NoTypeInformation
route print                   > "$Out\routes.txt"
netsh advfirewall show allprofiles > "$Out\firewall.txt"
Get-ChildItem \\.\pipe\ | Select-Object Name > "$Out\named_pipes.txt"

Le cache DNS révèle souvent des domaines de C2 résolus quelques minutes plus tôt, même quand la connexion elle-même est fermée. Les named pipes aident à repérer les noms par défaut des frameworks de post-exploitation courants, même si les opérateurs les renomment régulièrement.

Handles, DLL et presse-papiers

handle.exe -a -accepteula et listdlls.exe montrent les fichiers, clés de registre et modules ouverts par processus. Ils sont lents sur un serveur chargé : ciblez les PID suspects (handle -p <PID>). Le presse-papiers est propre à chaque session utilisateur : un collecteur qui tourne en SYSTEM ne le voit pas. Ne le récupérez que si vous travaillez dans la session de l'utilisateur, et regardez sinon l'historique du presse-papiers sur disque.

Étape 3 : instantané de la persistance et de la configuration

Capturez la surface de démarrage automatique pendant que le système tourne, car certains mécanismes (abonnements WMI, tâches masquées) s'énumèrent plus facilement en live. Le guide de chasse à la persistance explique comment interpréter chaque entrée.

E:\tools\autorunsc64.exe -accepteula -nobanner -a * -c -h -s -vt:0 > "$Out\autoruns.csv"
schtasks /query /fo csv /v > "$Out\schtasks.csv"
Get-CimInstance Win32_Service |
  Select-Object Name, State, StartMode, StartName, PathName, ProcessId |
  Export-Csv "$Out\services.csv" -NoTypeInformation
Get-CimInstance -Namespace root/subscription -ClassName __EventConsumer |
  Export-Csv "$Out\wmi_consumers.csv" -NoTypeInformation
Get-LocalUser | Export-Csv "$Out\local_users.csv" -NoTypeInformation
Get-LocalGroupMember Administrators | Export-Csv "$Out\local_admins.csv" -NoTypeInformation

Vérifiez que -vt est désactivé ou que votre politique l'autorise : soumettre des hashs à un service en ligne peut alerter un attaquant qui surveille ses échantillons.

Étape 4 : collecte de tri des artefacts disque

Une fois le volatil sécurisé, collectez les artefacts persistants nécessaires à la chronologie : ruches de registre, journaux d'événements, $MFT, $UsnJrnl, Prefetch, Amcache, SRUM, données de navigateur et historique PowerShell. Les fichiers verrouillés exigent un accès NTFS brut, ce que font précisément KAPE et Velociraptor. Voir la collecte de tri et le guide d'acquisition pour le choix des targets.

E:\kape\kape.exe --tsource C: --tdest E:\IR\HOST01\kape --target KapeTriage --vhdx HOST01 --zip HOST01

Commandes natives, Sysinternals, Velociraptor ou KAPE ?

Un bon kit s'appuie sur Velociraptor ou l'EDR pour la couverture et garde un lot scripté natif plus Sysinternals en secours quand les agents manquent.

Consoles EDR et collecte à distance à grande échelle

La plupart des EDR incluent un shell de live response. Microsoft Defender for Endpoint Live Response propose des commandes comme processes, connections, getfile et run pour des scripts déposés, et peut collecter un package d'investigation. CrowdStrike Falcon Real Time Response et SentinelOne RemoteOps offrent des capacités comparables. Les noms de commandes, les limites de taille de fichier et les rôles autorisés à lancer des scripts changent selon les versions et les licences : vérifiez votre tenant avant l'incident.

Pour les questions à l'échelle du parc (« quels hôtes ont résolu ce domaine ? », « où ce service est-il installé ? »), les hunts Velociraptor sont l'approche de référence. Des artefacts comme Windows.System.Pslist, Windows.Network.Netstat, Windows.Network.ArpCache, Windows.System.DNSCache et Windows.Sysinternals.Autoruns renvoient des résultats structurés que l'on peut empiler entre hôtes. Leurs noms évoluent d'une version à l'autre : confirmez-les dans la liste d'artefacts de votre serveur.

# Collecte hors ligne avec un binaire Velociraptor local (sans serveur ; vérifiez les options avec --help)
velociraptor.exe artifacts collect Windows.System.Pslist Windows.Network.Netstat `
  --output E:\IR\HOST01\velo_live.zip

L'accès distant laisse lui-même des traces : ouvertures de session réseau (4624, type d'ouverture de session 3), installations de service pour les outils de type PsExec et activité WinRM. Le guide du mouvement latéral les recense ; elles apparaîtront dans votre chronologie à côté de celles de l'attaquant.

Préserver les sorties : hashs, horodatages, notes

• Hachez chaque fichier de sortie (SHA-256) dès son écriture et conservez la liste des hashs à part des preuves.
• Tenez un journal au fil de l'eau : commande, heure de début (UTC), analyste, résultat, erreurs éventuelles. Start-Transcript vers votre dossier de sortie aide.
• Gardez la sortie brute, pas seulement des synthèses parsées. Les parseurs s'améliorent ; le texte brut, lui, ne revient pas.
• Empaquetez le dossier en ZIP ou VHDX, hachez-le et copiez-le hors du support de collecte avant l'analyse.

Get-ChildItem $Out -File -Recurse | Get-FileHash -Algorithm SHA256 |
  Export-Csv "$Out\..\HOST01_manifest.csv" -NoTypeInformation

Documenter sa propre empreinte

La live response modifie le système. L'objectif n'est pas d'éviter tout changement (impossible) mais de les connaître pour que personne ne prenne vos outils pour ceux de l'attaquant :

Consignez noms d'outils, hashs et chemins dans vos notes. Ne renommez rien : un winpmem clairement nommé dans le Prefetch s'exclut plus facilement qu'une chaîne aléatoire.

Pièges

• Faire confiance à la sortie en mode utilisateur. Les rootkits hookent les API derrière tasklist, netstat et dir. Comparez les résultats live avec une image mémoire (par exemple Volatility windows.pslist face à windows.psscan) et avec des données réseau capturées hors de l'hôte.
• Lancer des outils depuis le disque suspect. Un cmd.exe piégé ou une DLL déposée à côté de votre outil peut mentir ou exécuter des charges avec vos privilèges.
• RDP interactif avec un admin du domaine. Il laisse des identifiants réutilisables dans LSASS sur un hôte compromis. Utilisez un compte IR restreint et des ouvertures de session réseau ; le guide sur l'accès aux identifiants montre ce que les attaquants récoltent.
• Écrire la sortie sur C:. Cela écrase des clusters libres et pollue le journal USN avec vos propres fichiers.
• Redémarrer ou « nettoyer » d'abord. Un redémarrage vide la mémoire et les caches ; un scan antivirus complet met des échantillons en quarantaine et modifie des milliers de dates d'accès.
• Oublier le chiffrement. Éteindre un hôte BitLocker sans clé de récupération peut vous fermer l'accès au disque.
• Alerter l'attaquant. Envoyer des hashs à des services publics ou tuer des processus avant d'avoir cadré l'incident permet à un opérateur actif de changer d'infrastructure. Contenez après avoir collecté, en coordination avec le responsable de la réponse.
• Supposer que le processus malveillant tourne encore. Les outils éphémères ont disparu ; appuyez-vous sur la mémoire, le Prefetch et les journaux pour ce qui s'est déjà terminé, comme décrit dans le guide des preuves d'exécution.

Checklist de live response

1. Décider et documenter pourquoi l'hôte est examiné en live, qui l'a autorisé, et les horloges de l'hôte et de l'analyste en UTC.
2. Vérifier le chiffrement avec manage-bde -status ; sécuriser les clés de récupération si nécessaire.
3. Acquérir la mémoire avec un outil de confiance vers un stockage externe ou réseau ; la hacher.
4. Capturer l'état réseau : points de terminaison TCP et UDP avec PID, cache DNS, ARP, routes, profil de pare-feu.
5. Capturer les processus : PID, parent, chemin, ligne de commande, heure de création, services par processus, signatures.
6. Capturer les sessions : utilisateurs interactifs, sessions SMB entrantes, lecteurs mappés, sessions d'ouverture.
7. Photographier la persistance : autoruns, services, tâches planifiées, consumers WMI, administrateurs locaux.
8. Collecter les artefacts de tri avec KAPE ou Velociraptor via un accès NTFS brut.
9. Hacher et empaqueter toutes les sorties, rédiger un manifeste, copier le tout hors du support de collecte.
10. Consigner votre empreinte : outils, hashs, chemins, comptes et heures, pour pouvoir filtrer votre activité dans la chronologie.
11. Passer la main au confinement seulement une fois la collecte terminée et vérifiée, puis procéder à l'imagerie complète si l'affaire l'exige.