Forensics CTF Methodology: What to Look For and Where

At DEF CON CTF 2025, the forensics category stumped dozens of experienced teams — not because the challenges were obscure, but because players had no systematic approach. They chased rabbit holes while the real artifacts sat untouched in /var/log and inside a single PCAP. A solid forensics methodology beats raw tool knowledge every time.

Here is the approach that works: triage fast, go wide before you go deep, and let the artifacts tell you where to look next.

Step 1: Triage the Evidence — Disk Images First

When you receive a disk image, your first job is not to open a hex editor. It is to understand the filesystem layout, identify interesting timestamps, and surface recently modified files. autopsy is popular in CTFs, but fls and mactime from The Sleuth Kit give you faster command-line triage.

Start by listing all files with their MAC times and piping the output into a timeline:

# Mount the image and build a body file
fls -r -m / challenge.img > bodyfile.txt

# Generate a sorted timeline
mactime -b bodyfile.txt -d 2026-08-01 2026-09-01 | head -40

Sample output might look like this:

Mon Aug 12 2026 03:17:42,4096,m.c,d/drwxr-xr-x,1000,1000,/home/ctfuser/.config/systemd/user
Mon Aug 12 2026 03:17:43,512,m.c,-/-rwxr-xr-x,1000,1000,/home/ctfuser/.config/systemd/user/persist.service
Mon Aug 12 2026 03:17:55,218,m.c,-/-rw-r--r--,0,0,/etc/cron.d/updater

Three files modified within 13 seconds at 3 AM. That cluster is your lead. An attacker dropped a persistence service and a cron job in the same session. Your next move: extract and read both files, then check /var/log/auth.log for login events just before 03:17. In CTFs, flag strings are often embedded inside exactly these kinds of planted artifacts.

Step 2: Memory Dumps — Processes, Network, and Injected Code

Memory forensics is where most beginners stall. The secret is knowing which Volatility plugins to run first and in what order. Start with process listing, then network connections, then look for anomalies like process hollowing or injected shellcode.

Assume you have a Linux memory dump called ctf-mem.lime captured from a machine at 192.0.2.47:

# Identify the profile (Volatility 3 auto-detects on Linux)
vol -f ctf-mem.lime linux.pslist

# Check network connections at time of capture
vol -f ctf-mem.lime linux.netstat

Output snippet:

PID    PPID   COMM            
1      0      systemd
847    1      sshd
1203   847    sshd
1204   1203   bash
1389   1204   python3
1390   1389   sh

Offset   Proto  LocalAddr            RemoteAddr           State
0x...    TCP    192.0.2.47:443       192.0.2.200:58312    ESTABLISHED

A python3 process spawned a shell, and that shell has an outbound connection on port 443 to 192.0.2.200. That is a classic reverse shell pattern. In a CTF this often means the flag is stored in the memory of that python3 process or was written to a temp file during execution. Dump the process memory directly:

vol -f ctf-mem.lime linux.memmap --pid 1389 --dump
strings pid.1389.dmp | grep -i "flag{"

Run strings against the dump and grep for the flag format. You would be surprised how often this works on the first try. If it does not, look for Base64 blobs or XOR-encoded strings near the suspicious process.

Step 3: PCAP Analysis — Filter Aggressively, Reconstruct Sessions

Network captures in CTFs almost always contain either an exfiltrated flag or credentials used during the challenge scenario. Do not scroll through Wireshark frame by frame. Use tshark to filter and NetworkMiner or tcpflow to reconstruct streams.

# Extract all HTTP objects from the capture
tshark -r traffic.pcap --export-objects http,./extracted/

# See all unique DNS queries — a fast way to spot C2 or encoded data
tshark -r traffic.pcap -Y dns -T fields -e dns.qry.name | sort -u

If you see DNS queries like ZmxhZ3tiYXNlNjRfZG5zX2V4ZmlsfQ==.c2.evilhost.net, that is Base64-encoded data in a DNS name — a textbook DNS exfiltration technique. Decode the subdomain label:

echo "ZmxhZ3tiYXNlNjRfZG5zX2V4ZmlsfQ==" | base64 -d
# Output: flag{base64_dns_exfil}

Done. The flag was hiding in plain sight inside DNS traffic. Always check DNS queries before diving into TCP stream reconstruction — it takes thirty seconds and pays off frequently in CTF scenarios.

What To Do Now

Download the Volatility 3 repository and grab a free memory sample from the MemLabs CTF series on GitHub. Run linux.pslist and linux.netstat against it right now. Map what you see against the methodology above — suspicious parent-child process chains, unexpected network connections, and process names that do not match their PPID. Build this muscle memory before competition day, and the triage phase of any forensics CTF challenge will cost you minutes instead of hours.