Digital Forensics and Memory Analysis

Digital forensics is the discipline of turning a compromised host into a clear, defensible account of what happened — who got in, how, what they touched, and what they left behind. Done correctly, it produces evidence that holds up under scrutiny: in an internal post-mortem, in a legal proceeding, in a regulatory audit. Done sloppily, it produces a story that a competent adversary’s lawyer, or your own incident review board, will dismantle. The difference between the two is not primarily tooling — it is discipline. Discipline about the order in which you collect evidence, discipline about not touching source media, discipline about documenting every action you take, and discipline about keeping a hash chain that proves the evidence you analyzed is identical to the evidence you collected.

This post covers the full forensic workflow for a compromised host: the volatile-first collection order mandated by RFC 3227, sound evidence handling, disk and memory acquisition, memory analysis with Volatility 3, host-artifact recovery and filesystem forensics, and super-timeline construction with plaso and Timesketch. It sits downstream of the incident response playbook — the playbook tells you when to declare an incident and who owns containment; this post covers what the forensic analyst does once you hand them the host. It is not a CTF tutorial. It is a map of a craft that takes years to develop, with honest notes on where it fails.

The Forensic Mindset and the Order of Volatility

Before you touch anything, you need one guiding question: what evidence will disappear first? RAM contents are gone the moment power is cut. Network connection state evaporates seconds after an attacker disconnects. A file’s last-access timestamp can be clobbered by the act of opening it. RFC 3227, Guidelines for Evidence Collection and Archiving, published by the IETF in 2002, formalizes this into the order of volatility — a collection sequence from most ephemeral to most durable.

Order of Volatility (most volatile at top)
==========================================
  +------------------------------------------+
  |  CPU registers, cache, running processes  |  seconds
  +------------------------------------------+
  |  ARP cache, routing table, open sockets   |  seconds–minutes
  +------------------------------------------+
  |  RAM (full physical memory dump)          |  minutes (if powered)
  +------------------------------------------+
  |  Temporary filesystems (/tmp, swap, etc.) |  reboot
  +------------------------------------------+
  |  Disk / storage media                     |  persistent
  +------------------------------------------+
  |  Remote logs, monitoring data             |  persistent (off-host)
  +------------------------------------------+
  |  Archival backups                         |  very persistent
  +------------------------------------------+

The practical implication is that you capture RAM and network state before you image the disk, and you image the disk before you power the machine down or hand it to someone else. This sounds obvious but is routinely violated. IR engineers who have only worked in cloud environments are sometimes unfamiliar with it entirely, because on an ephemeral VM you often have no option but to snapshot a disk and interrogate cloud logs — the RAM is already gone by the time you know you need it.

Network state you can capture quickly with standard OS tools before the memory dump:

1
2
3
4
5

# Capture network state BEFORE anything else disturbs the system
ss -antp > /evidence/network_connections_$(date +%s).txt
ip neigh show > /evidence/arp_cache_$(date +%s).txt
ip route show > /evidence/routes_$(date +%s).txt
ps auxf > /evidence/process_list_$(date +%s).txt

Run these from a trusted binary you brought to the scene on read-only media. Do not trust the system’s own binaries — a rootkit will lie to you. This is not paranoia; it is method.

Evidence Handling and Chain of Custody

Chain of custody matters even when you never go to court. If you cannot demonstrate that your evidence images are identical to the source media, your incident narrative is speculation. The integrity chain has three components: collection, documentation, and verification.

The moment you acquire an artifact, you hash it:

1
2
3

sha256sum /dev/sda > /evidence/sda.sha256
# or, for an already-acquired image:
sha256sum disk.e01 >> /evidence/acquisition_hashes.txt

You record: who collected it, when (UTC timestamp), from what system (hostname, serial numbers, MAC addresses), using which tool and version, and the resulting hash. You store the hash file separately from the image — ideally on write-once media or a signed cloud object store. You re-verify before every analysis session. If the hash doesn’t match, something went wrong in storage or transport and you need to know before you build a case on it.

Work only on copies. The forensic image is the evidence. The original disk goes into a sealed evidence bag and does not come out unless a court orders the original produced. Your analysis environment mounts a copy, or works against a forensic image file that is itself mounted read-only. This principle applies even in the purely corporate context: if your containment action corrupts the evidence, you may never know what persistence mechanism the attacker installed.

The chain of custody log is a living document that follows the evidence: every person who handled it, every time it was moved, every analysis run. In a legal proceeding, gaps in the chain are an attack surface. In an internal investigation, the discipline forces you to be precise about what you actually did versus what you think you did.

Disk Imaging

Tools and Formats

Bit-for-bit disk imaging copies every sector, including slack space, deleted file remnants, and unallocated regions — the forensically interesting parts. The tools of record:

E01 is the practical standard for evidence that needs to be shared across tools — EnCase, Autopsy, Sleuth Kit, AXIOM all read it. Raw is simpler for custom analysis pipelines.

Write Blockers

Before you attach source media to your analysis workstation, you need a write blocker. A write blocker — hardware or software — intercepts all write commands at the bus level and silently drops them, allowing only reads. Without one, the operating system will write to the attached device: updating access timestamps, running automount daemons, writing filesystem journal entries. You will have altered your evidence and you will not know exactly how.

Hardware write blockers (Tableau, WiebeTech, Digital Intelligence) sit between the drive and the analysis workstation at the SATA, USB, or PCIe level. They are the gold standard because they operate below the OS — no kernel bug or misconfiguration can bypass them. Software write blockers (blockdev --setro, hdparm -r1, Linux’s read-only loop mount) are acceptable for triage in environments where hardware blockers are unavailable, but they depend on kernel correctness and should be documented as a limitation.

Acquisition Commands

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# dc3dd — hash the source on the fly, log errors, show progress
dc3dd if=/dev/sdb hash=sha256 hlog=/evidence/sdb_hash.log \
  log=/evidence/sdb_acquisition.log \
  of=/evidence/sdb.img progress=on

# ewfacquire — acquire directly to E01 with metadata
ewfacquire /dev/sdb \
  -t /evidence/sdb_case001 \
  -C "Case 001 — Compromised workstation" \
  -e "Jeff Moon" \
  -f encase6 \
  -c deflate \
  -S 2GiB

# After acquisition, verify the image hash matches the source
sha256sum /dev/sdb > /evidence/sdb_source.sha256
sha256sum /evidence/sdb.img > /evidence/sdb_image.sha256
diff /evidence/sdb_source.sha256 /evidence/sdb_image.sha256

Live vs. Dead Acquisition

Dead acquisition — powering down the system and imaging cold — preserves a static, consistent state. No processes are writing to disk during the image. For most disk forensics, this is preferable.

Live acquisition — imaging a running system — is necessary when you cannot afford downtime (a production database server), when disk encryption requires the live OS to decrypt for you, or when you want to capture swap. Live imaging introduces the risk of inconsistency (the OS is writing while you read) and the risk of altering evidence (your acquisition tool runs as root on a potentially compromised system). Document the tradeoff explicitly.

Memory Acquisition

Why RAM Is the Gold

RAM holds what an attacker is actively doing and what they do not want persisted to disk. A process running from a deleted binary on disk still has its code pages resident in memory. Injected shellcode lives in memory regions that have no corresponding file. Malware that unpacks itself at runtime appears encrypted on disk but clear in RAM. Network connections, including those to C2 infrastructure, appear in the kernel’s socket tables. Encryption keys for at-rest encrypted files may be resident in memory. Credentials harvested by a credential-dumper — mimikatz style — pass through memory. The RAM image is often the single most valuable artifact in a Windows IR.

Acquisition on Linux: AVML and LiME

AVML (Acquire Volatile Memory for Linux), maintained by Microsoft, is the pragmatic choice for Linux incident response. It is a statically linked, Rust-compiled binary — no dependencies, no compilation required on the target. It reads from /dev/crash, /dev/mem, or /proc/kcore depending on availability, and produces output in LiME format (which Volatility 3 can ingest directly) or with Snappy compression for upload to Azure Blob Store. You can drop the binary on a system, run it from a USB mount, and have a usable memory image.

1
2
3
4
5

# AVML — static binary, no compilation, drop and run
./avml /evidence/mem_$(hostname)_$(date +%s).lime

# With compression (larger images, faster upload to blob store)
./avml --compress /evidence/mem_$(hostname)_$(date +%s).lime.snappy

One hard limitation: if the kernel has kernel_lockdown enabled (common on systems with Secure Boot enforcing it), AVML cannot read physical memory. This is increasingly common on modern hardened distributions. Plan for this in your IR capability assessment.

LiME (Linux Memory Extractor), by 504ensicsLabs, is a loadable kernel module (LKM) that minimizes userspace-kernel interaction during acquisition, producing more forensically complete captures. The tradeoff is that you need to compile a matching module for the exact kernel version on the target, which is operationally painful in a diverse fleet. LiME can write to a local file or export over the network via TCP, which avoids writing the image to the target’s disk entirely.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Build and load LiME (requires matching kernel headers)
make -C /lib/modules/$(uname -r)/build M=$(pwd) modules

# Acquire to local file
insmod lime-$(uname -r).ko "path=/evidence/mem.lime format=lime"

# Acquire over network to analyst workstation (avoids writing to target)
# On target:
insmod lime-$(uname -r).ko "path=tcp:4444 format=lime"
# On analyst workstation:
nc <target_ip> 4444 > /evidence/mem.lime

Windows Memory Acquisition

On Windows, the equivalent tools are WinPmem (free, open-source, used by Velociraptor for live collection), Magnet RAM Capture, and the enterprise-grade F-Response and Magnet ACQUIRE. DumpIt is widely used for its single-binary simplicity in rapid-response scenarios. All of these produce images compatible with Volatility 3.

The Acquisition Paradox

Every memory acquisition perturbs the system. Loading a kernel module changes kernel memory. Even the AVML process itself allocates pages and modifies process lists. This is unavoidable. The goal is not zero perturbation — it is minimal, documented perturbation. Record the acquisition tool, its PID during acquisition, and the timestamp. Volatility analysis can then account for artifacts the tool itself introduced.

Memory Analysis with Volatility 3

Architecture: Profiles Replaced by Symbol Tables

Volatility 3 is a ground-up rewrite of Volatility 2 with a fundamentally different approach to OS-specific data structures. In Volatility 2, you selected a “profile” — a pre-built mapping of kernel struct offsets for a specific OS version. In Volatility 3, profiles are replaced by symbol tables: JSON files (optionally compressed as .json.gz) that describe kernel type information for a specific OS version. For Windows, symbol tables are derived from Microsoft’s PDB debug files via pdbconv.py, which ships with Volatility 3. For Linux and macOS, they are generated from DWARF debug information using dwarf2json.

The practical implication: if you have a memory image from an unfamiliar kernel version, you may need to generate a symbol table before analysis. On Linux this means having access to a kernel with debug symbols enabled — either vmlinux-dbg from the distribution’s debuginfo repository, or a kernel you compiled yourself. The Volatility Foundation and JPCERTCC maintain repositories of pre-built Windows symbol tables covering most common versions.

Core Plugin Workflow

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

# Set a short alias for readability
VOL="python3 vol.py -f /evidence/mem.lime"

# --- Process enumeration ---
# pslist: walks the doubly-linked PsActiveProcessHead list (rootkits can unlink from this)
$VOL windows.pslist

# psscan: scans raw memory for EPROCESS structures by pool tag (finds unlinked processes)
$VOL windows.psscan

# pstree: hierarchical parent-child view (spot orphaned processes without plausible parents)
$VOL windows.pstree

# --- Network state ---
# netscan: scans for socket and connection structures (Windows Vista+)
$VOL windows.netscan

# --- DLL and module analysis ---
$VOL windows.dlllist                    # PEB-linked DLLs per process
$VOL windows.ldrmodules                 # Cross-references PEB, VAD, and mapped file list

# --- Command lines ---
$VOL windows.cmdline                    # Process command-line arguments from PEB

# --- Malware hunting ---
# malfind: find VAD regions with PAGE_EXECUTE_READWRITE and no backing file
$VOL windows.malfind

# --- Filesystem and registry ---
$VOL windows.filescan                   # Scan for FILE_OBJECT structs
$VOL windows.dumpfiles --physaddr 0x...  # Extract a file object by physical address

# --- Linux equivalents ---
python3 vol.py -f /evidence/mem.lime linux.pslist
python3 vol.py -f /evidence/mem.lime linux.pstree
python3 vol.py -f /evidence/mem.lime linux.netstat
python3 vol.py -f /evidence/mem.lime linux.malfind

Key Plugins and What They Reveal

Hunting Process Injection and Hollowing

Process hollowing is a technique where an attacker spawns a legitimate process (svchost.exe, explorer.exe) in a suspended state, unmaps its memory, writes malicious code into the now-empty address space, and resumes it. The process appears legitimate in task manager but is executing attacker code. Volatility surfaces this through the combination of psscan (finding the process), malfind (finding regions with executable memory and no mapped file), and ldrmodules (finding that the loaded module list does not match the VAD regions).

A classic malfind hit looks like this: a memory region marked PAGE_EXECUTE_READWRITE with no mapped file path, containing a PE header (MZ) at the region base. The absence of a backing file means no file on disk corresponds to this code — it was injected at runtime. This is not a guarantee of malice (JIT compilers and packers legitimately do similar things) but it is a high-fidelity triage signal that warrants full extraction and static analysis.

dumpfiles extracts the contents of open file handles from memory. This matters because malware sometimes holds a handle to its own binary from a path that no longer exists on disk — the file was deleted after execution. The memory image retains the file content through the FILE_OBJECT.

For host-based log correlation, auditd provides the syscall-level process ancestry and file access records that let you cross-reference what Volatility found in memory against what the kernel actually logged.

Filesystem and Host Artifacts

MACB Timestamps and the MFT

The NTFS Master File Table ($MFT) contains two sets of timestamps for every file: the $STANDARD_INFORMATION attribute (visible to most tools, writable without privilege by normal processes) and the $FILE_NAME attribute (updated by the kernel on directory operations, harder to forge). Timestamp stomping — an attacker backdating $STANDARD_INFORMATION to blend in — is detectable by comparing the two sets: a modified time that is earlier than the file name creation time is physically impossible under normal conditions and is a red flag.

The MACB model (Modified, Accessed, Changed/$MFT-entry-changed, Born/created) organizes the four timestamps that matter for timeline reconstruction. Not all four are meaningful on all filesystems — ext4 has no Birth timestamp in older implementations — but on NTFS all four are present and independently useful.

The NTFS journal ($UsnJrnl, $LogFile) records filesystem operations with timestamps, including file creation, rename, deletion, and attribute changes. Files deleted before you acquired the disk leave journal entries. Autopsy, The Sleuth Kit’s fls/icat, and Plaso all parse the journal. This is often where you find the malware that cleaned itself up.

Log Files, Shell History, and Persistence

The host artifact layer correlates with the memory layer. Bash history files (~/.bash_history, /root/.bash_history) record commands, though they can be cleared or manipulated. For Linux, the auditd syscall logger provides tamper-resistant EXECVE records if it was running and shipping logs off-host. Windows Event Log artifacts (Security 4624/4625 for logon events, 4688 for process creation with command lines if auditing is enabled, 4698/4702 for scheduled task creation) are the Windows equivalent.

Persistence locations to examine on Windows: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and the corresponding CurrentVersion\RunOnce, scheduled tasks under C:\Windows\System32\Tasks, services in HKLM\SYSTEM\CurrentControlSet\Services, startup folders, WMI subscriptions, COM object hijacking, and DLL search-order hijacking. On Linux: crontabs, systemd unit files in /etc/systemd/system/ and ~/.config/systemd/user/, /etc/rc.local, .bashrc/.profile modifications, /etc/ld.so.preload (rootkit classic), SUID binaries, and authorized SSH keys.

For structured log analysis and shipping, the log management workflow matters: logs that were never centralized are logs that may have been purged on the compromised host.

Deleted File Recovery

When a file is “deleted” on most filesystems, the directory entry is removed and the blocks are marked as available, but the data remains until overwritten. On NTFS, the MFT entry is marked as unallocated but often persists with intact timestamps and data pointers until the MFT entry is reused. icat from The Sleuth Kit can extract data from an MFT entry by inode number even after deletion. Carving tools (Foremost, Scalpel, bulk_extractor) scan raw disk space for file signatures regardless of filesystem metadata — useful when the filesystem itself has been partially wiped.

Building the Super-Timeline with plaso

The Concept

A super-timeline fuses timestamps from every artifact source — filesystem MACB timestamps, Windows Event Log entries, browser history, registry last-write times, prefetch execution timestamps, LNK file access times, NTFS journal entries — into a single chronological narrative. The idea is that an attacker cannot manipulate every timestamp source simultaneously; inconsistencies between sources are where the truth shows.

Plaso (Plaso Langar Að Safna Öllu, Icelandic for “it’s all in there”), the engine behind log2timeline, handles the parsing. It ships with hundreds of parsers covering Windows, Linux, macOS, browser, email, and network log formats. The output is a storage file (.plaso) that is queried and exported via psort.py or ingested directly into Timesketch.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Step 1: Run log2timeline against a forensic image or mounted partition
# This is the slow step — a full disk image can take hours
log2timeline.py \
  --storage-file /evidence/case001.plaso \
  --parsers=win7,winevtx,mft,usnjrnl,prefetch,lnk,firefox_history \
  /evidence/sdb.e01

# Step 2: Filter and export to CSV for analysis (psort)
psort.py \
  -o l2tcsv \
  -w /evidence/case001_timeline.csv \
  /evidence/case001.plaso \
  "date > '2026-05-01 00:00:00' and date < '2026-05-15 00:00:00'"

# Step 3: Import into Timesketch for collaborative analysis
timesketch_importer \
  --sketch-name "Case 001 — Compromised Workstation" \
  /evidence/case001.plaso

Timesketch for Analysis

Timesketch (Google, open source) ingests Plaso output and provides a searchable, annotatable timeline interface with multi-analyst collaboration. You can tag events, write stories (narrative annotations against specific timeline ranges), run built-in ML-based analyzers (suspicious process execution, Windows login anomalies), and export findings. The combination of Plaso’s parsing breadth and Timesketch’s analysis UI is the practical standard for timeline work on large datasets.

The super-timeline approach produces enormous output — millions of events for a typical enterprise workstation over a month. Effective use requires filtering: start with known attacker IOCs (known-bad IPs, malware filenames, tool names from your malfind output), build a narrow time window around the first suspicious event, then expand backward to find initial access and forward to find lateral movement and persistence.

Assembling the Incident Narrative

All of this produces evidence. The analyst’s job is to turn evidence into narrative: initial access → execution → privilege escalation → persistence → lateral movement → objective. Every claim in the narrative should be sourced to a specific artifact with a hash-verified provenance.

Acquisition → Analysis → Correlation → Narrative
================================================
  [Memory image]──┐
                  ├─→ [Volatility: processes, network, injection]──┐
  [Disk image]────┤                                                 │
                  ├─→ [Plaso: super-timeline]──────────────────────┼──→ [Incident narrative]
  [Log exports]───┘                                                 │    with artifact citations
                    [Network PCAP]──────────────────────────────────┘

Network forensics from packet captures adds the external dimension — what left the network, what connected in. For deep packet analysis, Wireshark and tshark are the workhorses for extracting C2 traffic patterns, exfiltration, and lateral movement network artifacts. This DFIR work then feeds back into incident response automation — building detections from the TTPs you found so the next instance of this attack is caught earlier.

Where Forensics Fails

Be honest about the limits. Anti-forensics is a discipline: attackers who know forensics use SSD TRIM to ensure deleted data is overwritten immediately, use memory-only implants that leave no disk artifacts, manipulate timestamps aggressively, and use encrypted channels that resist PCAP analysis. A sophisticated attacker with a week of dwell time on a hardened system may leave very little recoverable evidence.

Encryption is a hard stop. A disk encrypted with BitLocker or LUKS where you do not have the key or a memory image containing it is opaque. Full-disk encryption without memory acquisition is a wall. Some schemes leave artifacts — BitLocker recovery keys logged to Active Directory, LUKS headers recoverable, key material sometimes in memory swap — but these are contingencies, not reliable.

Ephemeral and cloud hosts are the modern hard case. A Kubernetes pod that was evicted thirty minutes before you started your investigation has no disk to image and no RAM to capture. You have container logs if they were shipped off-host, control plane audit logs if you had Kubernetes auditing enabled, and network flow data if you had a CNI that exported it. Cloud forensics requires a fundamentally different approach: everything is logs and snapshots, the order-of-volatility principle applies to how quickly cloud providers expire or overwrite those sources, not to physical memory.

The skill and time cost is real. Volatility analysis of a single memory image by an experienced analyst takes hours. A plaso run against a full disk image takes hours more. Building a defensible narrative takes days. Most organizations do not have this capacity in-house, and IR retainer firms charge accordingly. The gap between “we ran Volatility” and “we have a defensible incident timeline” is large.

Finally, the legal-defensibility bar is higher than most internal IR teams realize. Courts have excluded forensic evidence because of documentation gaps, unverified hash chains, unqualified analysts, and software that could not be validated as scientifically reliable. If there is any possibility your investigation will be used in criminal prosecution or civil litigation, engage a forensics firm with court-qualified examiners from the outset.

Verdict

Digital forensics is not about having the right tools — it is about applying them with enough discipline that the results are defensible. Capture volatile evidence first. Hash everything immediately. Work on copies. Document every action. Let the evidence lead the narrative, not the other way around. Volatility 3 and plaso are genuinely powerful, but a sloppily acquired image analyzed by a brilliant analyst is worth less than a carefully acquired image analyzed by a competent one. Build the process before you need it.

Sources

• RFC 3227: Guidelines for Evidence Collection and Archiving — IETF
• Volatility 3 documentation — volatility3.readthedocs.io
• Volatility 3 GitHub repository — volatilityfoundation/volatility3
• AVML — Acquire Volatile Memory for Linux — microsoft/avml
• LiME — Linux Memory Extractor — 504ensicsLabs/LiME
• Plaso (log2timeline) documentation — plaso.readthedocs.io
• Plaso GitHub repository — log2timeline/plaso
• Timesketch — collaborative forensic timeline analysis — google/timesketch
• JPCERTCC Windows Symbol Tables for Volatility 3
• Forensic Disk Acquisition: A Professional Guide — deaddisk.com
• Volatility 3 windows.malfind module documentation
• Order of Volatility — GetAcademy.blog
• AVML on Velociraptor artifact exchange