Digital Forensics Basics: Acquisition, Order of Volatility, Analysis

Forensics is the discipline of answering questions about a system without changing the answers.

That constraint is the whole subject. An administrator investigating a suspicious machine logs in, opens folders, runs tools and reboots it, and in doing so overwrites timestamps, flushes memory, rotates logs and destroys the record of what happened. A forensic examiner asks the same questions in an order and by a method that leaves the evidence intact and can prove it did.

This guide covers the process: preserving state, acquiring images, the artifacts that answer common questions, and building a timeline. It is an orientation rather than a certification course.

Scope: Incident Response 101 owns the response process this sits inside, Intro to Malware Analysis owns what you do with a sample once recovered, and Windows Event IDs for Security owns the specific events worth reading. This page owns the method.

The four principles

Different jurisdictions phrase these differently and they amount to the same four rules.

1. Do not change the evidence. No action should alter data that may later be relied on.
2. If you must change it, be competent and explain why. Live acquisition changes memory by running. That is acceptable when the alternative is losing memory entirely, provided the person doing it understands the effect and records it.
3. Keep a record. An audit trail complete enough that another examiner following it reaches the same result.
4. Someone is responsible. A named person accountable for the process being followed.

Chain of custody is how the third and fourth become concrete: who collected what, when, from where, who has held it since, and the hash values proving it did not change in between. A gap in that record is a hole nobody can fill later.

Order of volatility

Evidence disappears at different rates, so collection order is decided by what vanishes first. RFC 3227's ordering, condensed:

The operational consequence: capture memory before doing anything that ends the machine's uptime. Every minute a compromised machine runs, memory changes; the moment it powers off, it is gone completely. The instinct to pull the plug destroys the richest evidence available.

Remote logs are worth pulling forward in practice. They sit at position five by volatility and they are frequently the shortest-lived evidence in the incident, because a 30-day retention on a firewall or a 7-day retention on a SaaS audit log expires on a clock nobody controls. Preserve them first even though they are not the most volatile.

Acquisition

Memory

Capture with a tool that runs from external media and writes to external media, so the machine's own disk is not modified more than necessary.

# Linux, AVML produces a LiME-format image
sudo ./avml /mnt/evidence/host01-mem.lime
sha256sum /mnt/evidence/host01-mem.lime | tee host01-mem.sha256

On Windows the common tools are WinPmem, DumpIt and the acquisition modules of commercial suites. Whatever the tool, hash the output immediately and record the tool, its version, the operator and the time.

Acquiring memory from a running system unavoidably changes that system: the tool loads, allocates and runs. This is the second principle in action, and it is documented rather than avoided.

Disk

Two decisions: dead-box or live, and full image or targeted collection.

For dead-box acquisition, the disk is removed or the machine booted from forensic media, connected through a write blocker, and imaged.

# Raw image with verification, via a write blocker
sudo dc3dd if=/dev/sdb of=/mnt/evidence/host01.dd hash=sha256 log=host01.log
 
# Or the EWF container format, which compresses and stores metadata and hashes
sudo ewfacquire -t /mnt/evidence/host01 -d sha256 /dev/sdb

Raw (dd) images are simple and large. E01 and similar containers compress, embed case metadata, and store checksums per block so corruption is detectable. Either is fine as long as the hash is recorded and verifiable.

Live acquisition is the reality for servers that cannot be taken down, encrypted volumes that would become unreadable, and cloud instances. Targeted collection with a triage tool, gathering event logs, registry hives, execution artifacts and filesystem metadata rather than every byte, is often the better trade: it collects the artifacts that answer the questions in minutes rather than imaging a 4 TB volume over a weekend.

For cloud instances, acquisition means snapshotting the volume through the provider API, preserving the snapshot in a controlled account, and separately exporting the control plane logs. The instance's disk is only half the evidence; the API audit log is the other half, and it is the half that shows what the attacker did with the credentials.

Verification

# At acquisition
sha256sum host01.dd > host01.sha256
 
# Before analysis, on the working copy
sha256sum -c host01.sha256

Two hashes matching is what lets you say the copy is the original. Some workflows record both MD5 and SHA-256, MD5 for compatibility with older tooling and SHA-256 because MD5 collisions are constructible. Never analyse the original: verify, copy, work on the copy.

Analysis

Memory

Volatility 3 is the standard open-source framework.

# What was running
vol -f host01-mem.lime windows.pslist
vol -f host01-mem.lime windows.pstree          # parent/child relationships
 
# Network state at capture
vol -f host01-mem.lime windows.netscan
 
# Injected code in legitimate processes (was windows.malfind before the rename)
vol -f host01-mem.lime windows.malware.malfind
 
# Command lines, which pslist alone does not show
vol -f host01-mem.lime windows.cmdline
 
# Pull a process image out for analysis
vol -f host01-mem.lime windows.dumpfiles --pid 4812

The process tree is usually the fastest route to an answer. Legitimate process ancestry is predictable, so a shell whose parent is an office application, a browser spawning a scripting host, or lsass.exe with an unexpected parent are all visible at a glance. The malfind plugin finds executable memory regions with no backing file on disk, which is the shape of injected code and of the fileless techniques in What Is Fileless Malware.

Disk and filesystem

The Sleuth Kit and Autopsy handle the general case: browsing the filesystem, recovering deleted files, carving unallocated space, and examining metadata.

On Windows, a set of artifacts answers most questions:

The $MFT deserves a note, because it records four timestamps per file in two separate attributes, and that redundancy is what catches timestamp manipulation.

On Linux, the equivalents are /var/log including auth.log and wtmp, shell history files, systemd unit files and timers, cron entries, and the timestamps in the filesystem itself.

Timelines

Individual artifacts are facts. A timeline is what turns them into a narrative.

# Build a super timeline from an image
log2timeline.py --storage-file host01.plaso host01.dd
psort.py -o l2tcsv -w host01-timeline.csv host01.plaso \
  "date > '2026-08-01 00:00:00' AND date < '2026-08-20 00:00:00'"

A super timeline merges filesystem metadata, event logs, registry keys, browser data and application logs into one ordered sequence. The value is in adjacency: a phishing email received at 09:12, an attachment opened at 09:14, a process created at 09:14, a scheduled task registered at 09:15 and an outbound connection at 09:16 is a complete initial-access narrative that no single artifact contains.

Two disciplines make timelines usable. Normalise everything to UTC, because mixed local times produce sequences that never happened. And filter to a window around the events of interest, since an unfiltered super timeline of a workstation runs to millions of rows.

Anti-forensics

Attackers interfere with all of this, and the interference is itself evidence.

Log clearing. Windows records event ID 1102 when the security log is cleared, so the act of hiding leaves a mark. A log that starts abruptly at a time matching other activity is a finding.

Timestomping. Setting file timestamps to blend in. The $MFT stores timestamps in both $STANDARD_INFORMATION and $FILE_NAME, and common tools alter only the first, so a mismatch between them indicates manipulation. Timestamps with zeroed sub-second precision are another tell, since genuine ones rarely land on a round value.

Secure deletion and wiping. Overwritten data is gone, and the absence has a shape: a gap in a sequence, a file referenced by a registry key that no longer exists, an entry in the MFT with no data.

Memory-only execution. Nothing is written to disk, so a disk image shows nothing. This is the case memory acquisition exists for.

Encryption. Encrypted archives staged for exfiltration cannot be read, and their existence, size and timing still establish what was taken and when.

State absence carefully. "No evidence of X" and "evidence that X did not happen" are different claims, and the difference matters when logging was never enabled in the first place.

A working sequence

For a suspected compromise on a single Windows host:

1. Do not reboot, do not reimage, do not log in as a domain administrator. That last one places privileged credentials on a machine an attacker may control.
2. Preserve the short-lived evidence first. Extend or export retention on the relevant firewall, proxy, EDR, email and identity logs before they roll.
3. Document the state. Photographs of the screen, who was logged in, what was running, network connectivity.
4. Capture memory to external media, and hash it.
5. Capture volatile state: connections, processes, logged-on sessions, ARP and routing.
6. Decide on containment. Network isolation preserves the machine for imaging while cutting the attacker off, and it is almost always better than powering off.
7. Acquire the disk, or run a triage collection if a full image is impractical.
8. Verify hashes, copy, analyse the copy.
9. Build a timeline and write the findings with the artifact that supports each one.

The verdict

The technical part of forensics is learnable from tool documentation. The part that decides whether an investigation produces answers is procedural: collect in order of volatility, capture memory before it disappears, never work on the original, hash everything, and write down what you did as you do it.

The most common failure in real incidents is not a missed artifact. It is that somebody rebooted the machine, reimaged it, or logged in with a domain administrator account before anyone thought to preserve it, and the answers were destroyed by the response.

Related guides

• Incident Response 101
• Intro to Malware Analysis
• Windows Event IDs for Security
• What Is Fileless Malware
• Malware Persistence Techniques