01Scope
- Order of volatility and the decision to keep a system running
- RAM acquisition to a verified image file and its hash
- Process trees, loaded modules, handles, network sockets, injected code
- Encryption state: BitLocker, FileVault, VeraCrypt volumes mounted at capture time
- Hibernation and page files as memory remnants on disk
02Questions it answers
- Which processes were running, started by whom, with which command line?
- Which remote addresses was the system connected to at the moment of capture?
- Was malicious code present in memory that leaves no file on disk?
- Were encrypted volumes mounted, and can their keys be preserved lawfully?
- What was on screen and in the clipboard?
03Evidence used
| Source | What it yields | Note |
|---|---|---|
| Physical memory image (raw, LiME, AFF4) | Processes, DLLs, sockets, registry in memory, credentials, decrypted content | Record the tool, driver version, start and end time and the hash of the output; memory changes while it is being read. |
| Volatile command output (process list, network state, logged-on users, ARP, routes) | A human-readable snapshot that cross-checks the memory image | Run from trusted external media; log every command, its time and its hash. |
| hiberfil.sys, pagefile.sys, swapfile.sys, crash dumps | Memory fragments from before the last shutdown | Compressed on modern Windows; content is partial and undated. |
| Screen photographs and the device's displayed clock | Visible state, open applications, clock offset | Take them before touching the keyboard; note the reference time of the camera. |
04How it is approached
Decide, and record why
If the system is on, document the screen and decide between live collection and controlled shutdown based on encryption, remote-wipe risk and the questions asked. The reasoning goes into the notes.
Collect in order of volatility
Registers and cache, memory, network state, running processes, disk, then remote logs and archival media, as RFC 3227 lists them.
Minimise and log your footprint
Every tool you run creates a process, allocates memory and may write to disk. Use known tools from write-protected media, write output to your own media, and log each action with its time.
Analyse with profile and symbols that match the kernel
Identify the exact OS build before parsing memory structures; a wrong profile produces plausible but false process lists.
Corroborate with disk and logs
A process in memory should match an executable on disk, a Prefetch entry, an event 4688 or a service installation; an unmatched process is where the examination focuses.
05Artifacts
The library records behind this area:
06Pitfalls
- Memory acquisition is never perfectly consistent; pages change during the read. Report the capture duration.
- Your own tools appear in the image; label them so they are not reported as suspicious.
- Process names are easily spoofed; identify by path, hash, parent and command line.
- Credentials or keys found in memory may be subject to legal limits on use; preserve, do not exploit, unless authorised.
07What the report states
- System state on arrival (powered, locked, screen content) with photographs and times.
- The order of actions taken on the live system, each with time, tool, version and output hash.
- Memory image size, capture duration, hash and the profile used for analysis.
- Which findings come from memory alone and which are corroborated on disk.
08Questions to ask a report
- Why was the system kept running or shut down, and who made that decision?
- What was executed on the live system, in what order, and what did it change?
- Was the memory image hashed, and is the analysis profile stated?
- Is each memory finding matched to a disk or log artifact?