La question
Une activité inhabituelle est signalée sur un poste Windows. PowerShell a-t-il été utilisé ? Une persistance a-t-elle été créée ? Et peut-on démontrer ces deux réponses à partir d'artefacts qu'un tiers pourrait vérifier ? Ce laboratoire — un TP du module Digital Forensics à l'EMSI Tanger — documente toute la démarche, de la préparation du support de collecte à la conclusion forensique, sur une machine Windows 10 virtualisée.
Dumps mémoire, images disque et collectes restent hors de Git. Le dépôt contient la méthode, les scripts, les captures commentées et les empreintes qui permettent de vérifier les preuves.
Trois sources indépendantes, une même seconde
Le résultat qui compte : la persistance est datée à la seconde près par des sources qui ne dépendent pas les unes des autres. La clé Run a été écrite pour la dernière fois à 17:55:21 UTC ; le fichier Prefetch de reg.exe a été créé à 17:55:21 UTC.
- Création du dossier
C:\AtomicRedTeamDisque - Exécution du test T1059.001-17 (PowerShell)Sortie du test
- Création de
CMD.EXE-4A81B364.pfPrefetch - Écriture de la clé Run et première exécution de
reg.exeRegistre + Prefetch - Fin du dump mémoire
incident_ram.memFichier - Capture de
tasklist.txtFichier
Le laboratoire : quatre choix de conception
- Outils portables sur support externe. Rien n'est installé sur la victime, pour limiter l'empreinte du live response.
- Destination ≠ source. Toute écriture va vers le support, jamais vers le
C:de la victime. - Une VM sans carte réseau. Le disque contient des échantillons de malware ; la VM ne peut atteindre aucun réseau. Atomic Red Team est donc installé hors ligne, depuis des fichiers préparés à l'avance.
- Partage restreint. Seul le dossier de collecte est exposé à la VM, pas le disque hôte entier.
Méthode : on capture d'abord ce qui disparaît le plus vite
L'ordre suit la RFC 3227, l'ordre de volatilité : mémoire, puis état vivant, puis disque, puis triage ciblé. Les images E01 et RAW sont toutes deux produites dans le premier exercice pour les comparer : l'E01 apporte compression, métadonnées de dossier et empreinte intégrée vérifiée par blocs ; le RAW offre une compatibilité maximale mais exige une empreinte externe.
Exercice 1 — Acquisition et préservation
Mémoire, disque physique entier, triage ciblé
La capture mémoire avec pagefile donne un dump de 4,5 Go, cohérent avec les 4 Go de RAM de la VM. La source du disque est le disque physique entier, ce qui inclut le MBR, l'espace non alloué et la partition de récupération ; l'acquisition dure 36 min 39 s. FTK relit ensuite toute l'image et compare les empreintes : MD5 et SHA-1 calculé = stocké = rapport, aucun bad block sur 104 857 600 secteurs.
KAPE n'image pas le disque ; il collecte des artefacts ciblés avec la cible !SANS_Triage : 4 010 fichiers copiés sur 4 536 en 2 304 s — ruches du registre, $MFT, journal USN, 142 fichiers Prefetch, 156 journaux d'événements.
Exercice 2 — Investigation d'un incident simulé
Deux techniques MITRE ATT&CK sont simulées avec Atomic Red Team : exécution PowerShell (T1059.001, test 17) et persistance par clé Run du registre (T1547.001, test 1). Un snapshot est pris avant la simulation et aucun nettoyage n'est lancé, pour garder les traces. L'image disque est ensuite vérifiée deux fois — dans la VM puis sur le poste d'analyse — avec des résultats identiques.
Ce que dit le disque
Le dossier AtomicRedTeam est présent à la racine de l'image, créé à 17:51:21 UTC : l'installation de l'outil est elle-même visible. Le Prefetch conserve la trace de l'exécution des programmes : REG.EXE-E7E8BD26.pf est créé et modifié à 17:55:21, et CMD.EXE-4A81B364.pf à 17:54:39 — une seconde après la simulation PowerShell, car Atomic Red Team lance ses commandes par cmd.exe.
Ce que dit le registre — et ce que personne n'avait demandé
NTUSER.DAT est exporté avec ses journaux de transaction. La ruche est « sale » (prélevée sur un système en marche) : les journaux .LOG1 et .LOG2 sont donc rejoués en mémoire, sans toucher au fichier exporté. La clé Run contient la valeur simulée, Atomic Red Team → C:\Path\AtomicRedTeam.exe.
Elle contient aussi quatre autres entrées, dont trois suspectes : un faux nom de mise à jour pointant vers C:\temp\evil.exe, une valeur au nom aléatoire lançant un script PowerShell caché avec contournement de la politique d'exécution, et un nom de type hash pointant vers njRAT.exe. Le registre date la clé, pas chaque valeur : ces entrées sont donc consignées, non attribuées à la simulation. Le disque vient d'une VM de laboratoire déjà utilisée pour l'analyse de malwares.
Corrélation
| Question d'investigation | Artefacts | Conclusion |
|---|---|---|
| PowerShell a-t-il été utilisé ? | Prefetch PowerShell · sortie du test · Prefetch de cmd.exe | Oui. Exécution à 17:54:38, lanceur une seconde plus tard. Le tasklist seul ne suffit pas : il prouve un PowerShell à 18:24, pas celui de la simulation. |
| Une persistance a-t-elle été créée ? | Clé Run de NTUSER.DAT · Prefetch de reg.exe | Oui. Dernière écriture 17:55:21, seconde exacte de la première exécution de reg.exe. |
| Les preuves sont-elles intègres ? | Empreintes RAM · vérification E01 | Oui. MD5 et SHA-1 identiques dans la VM et sur la machine d'analyse, aucun bad block. |
Limites et réserves
Une conclusion forensique ne vaut que par la liste de ce qu'elle ne prouve pas. Le dépôt les énonce lui-même :
- Le disque source n'est pas une image de victime vierge : il vient d'une VM de laboratoire déjà utilisée pour l'analyse de malwares.
- Ordre d'acquisition, exercice 1 : l'état réseau et processus précède le dump RAM d'environ cinq minutes, ce qui s'écarte de la RFC 3227.
- L'acquisition live laisse une trace : FTK Imager et KAPE tournent dans le système analysé.
- La mémoire a été acquise et préservée, pas analysée — étape suivante, avec Volatility 3.
- L'horloge de la VM avance d'une heure ; toutes les heures sont converties en UTC.
Ce que j'ai appris
- Un artefact est un indice ; deux qui concordent à la seconde sont une preuve.
- Consigner n'est pas attribuer. Trois entrées Run suspectes ont été trouvées ; aucune ne pouvait être datée individuellement, donc aucune n'a été imputée à la simulation.
- Les obstacles pratiques ont leur place dans le rapport. Un programme élevé ne voit pas les lecteurs réseau de la session standard (résolu avec des chemins UNC) ; vérifier une E01 à travers un dossier partagé a pris trois heures à 2,4 Mo/s.
Le dépôt contient la méthodologie, les 28 captures annotées, les fiches de chaîne de traçabilité, le journal horodaté et trois scripts PowerShell pour la capture de l'état volatil, le hachage des preuves et l'installation hors ligne d'Atomic Red Team.