The question
Unusual activity is reported on a Windows workstation. Was PowerShell used? Was a persistence mechanism created? And can both answers be demonstrated from artefacts that a third party could verify? This lab — coursework for the Digital Forensics module at EMSI Tanger — documents the full path from preparing the collection media to the forensic conclusion, on a virtualised Windows 10 machine.
Memory dumps, disk images and collections stay out of Git. The repository holds the method, the scripts, the annotated captures and the hashes that allow the evidence to be verified.
Three independent sources, one second
The result that matters: the persistence is dated to the second by sources that do not depend on each other. The Run key was last written at 17:55:21 UTC; the Prefetch file of reg.exe was created at 17:55:21 UTC.
- Folder
C:\AtomicRedTeamcreatedDisk - Test T1059.001-17 executed (PowerShell)Test output
CMD.EXE-4A81B364.pfcreatedPrefetch- Run key written and first execution of
reg.exeRegistry + Prefetch - End of the memory dump
incident_ram.memFile tasklist.txtcapturedFile
The lab: four design choices
- Portable tools on external media. Nothing is installed on the victim, to limit the footprint of live response.
- Destination ≠ source. Every write goes to the collection media, never to the victim's
C:. - A VM with no network card. The disk holds malware samples, so the VM can reach no network. Atomic Red Team is therefore installed offline, from files prepared in advance.
- Restricted sharing. Only the collection folder is exposed to the VM, not the whole host disk.
Method: what disappears first is captured first
The order follows RFC 3227, the order of volatility: memory, then live state, then disk, then targeted triage. Both E01 and RAW images are produced in the first exercise to compare them: E01 carries compression, case metadata and a built-in hash verified by blocks; RAW offers maximum compatibility but needs an external hash.
Exercise 1 — Acquisition and preservation
Memory, full physical disk, targeted triage
The memory capture with pagefile gives a 4.5 GB dump, consistent with the VM's 4 GB of RAM. The disk source is the entire physical drive, which includes the MBR, unallocated space and the recovery partition; acquisition takes 36 min 39 s. FTK then re-reads the whole image and compares hashes: MD5 and SHA-1 computed = stored = report, no bad block over 104,857,600 sectors.
KAPE does not image the disk; it collects targeted artefacts with the !SANS_Triage target: 4,010 files copied out of 4,536 in 2,304 s — registry hives, $MFT, USN journal, 142 Prefetch files, 156 event logs.
Exercise 2 — Investigating a simulated incident
Two MITRE ATT&CK techniques are simulated with Atomic Red Team: PowerShell execution (T1059.001, test 17) and persistence through a registry Run key (T1547.001, test 1). A snapshot is taken before the simulation and no clean-up is run, so the traces stay. The disk image is then verified twice — in the VM and on the analysis workstation — with identical results.
What the disk says
The AtomicRedTeam folder is present at the root of the image, created at 17:51:21 UTC: the installation of the tool is itself visible. Prefetch keeps the trace of program execution: REG.EXE-E7E8BD26.pf is created and modified at 17:55:21, and CMD.EXE-4A81B364.pf at 17:54:39 — one second after the PowerShell simulation, because Atomic Red Team launches its commands through cmd.exe.
What the registry says — and what nobody asked
NTUSER.DAT is exported with its transaction logs. The hive is "dirty" (taken from a running system), so the .LOG1 and .LOG2 journals are replayed in memory, without touching the exported file. The Run key holds the simulated value, Atomic Red Team → C:\Path\AtomicRedTeam.exe.
It also holds four other entries, three of them suspicious: a fake update name pointing to C:\temp\evil.exe, a random-named value launching a hidden PowerShell script with an execution-policy bypass, and a hash-like name pointing to njRAT.exe. The registry dates the key, not each value, so these are recorded, not attributed to the simulation: the disk comes from a lab VM already used for malware analysis.
Correlation
| Investigation question | Artefacts | Conclusion |
|---|---|---|
| Was PowerShell used? | PowerShell Prefetch · test output · cmd.exe Prefetch | Yes. Execution at 17:54:38, launcher one second later. The tasklist alone is not enough: it proves a PowerShell at 18:24, not the one from the simulation. |
| Was persistence created? | NTUSER.DAT Run key · reg.exe Prefetch | Yes. Last write 17:55:21, the exact second of the first execution of reg.exe. |
| Is the evidence intact? | RAM hashes · E01 verification | Yes. Identical MD5 and SHA-1 in the VM and on the analysis machine, no bad block. |
Limits and reservations
A forensic conclusion is only as good as the list of what it does not prove. The repository states these itself:
- The source disk is not a clean victim image: it comes from a lab VM already used for malware analysis.
- Order of acquisition, exercise 1: network and process state precede the RAM dump by about five minutes, which departs from RFC 3227.
- Live acquisition leaves a trace: FTK Imager and KAPE run inside the analysed system.
- Memory was acquired and preserved, not analysed — the next step, with Volatility 3.
- The VM clock runs one hour ahead; every time is converted to UTC.
What I learned
- One artefact is a clue; two that agree to the second are evidence.
- Recording is not attributing. Three suspicious Run entries were found; none could be dated individually, so none was blamed on the simulation.
- Practical obstacles belong in the report. An elevated program does not see the network drives of the standard session (solved with UNC paths); verifying an E01 through a shared folder took three hours at 2.4 MB/s.
The repository (written in French) contains the methodology, the 28 annotated captures, the chain-of-custody sheets, the timestamped case notes and three PowerShell scripts for volatile-state capture, evidence hashing and offline Atomic Red Team installation.