Hands-On Edition · 20 Labs

Run Every Core Forensics Technique Yourself

Twenty self-contained lab exercises across foundations, disk forensics, memory forensics, and network forensics. Every lab builds its own evidence first (so you're not hunting for sample files), then walks through the exact commands to analyse it, with expected output and a checkpoint to confirm you got the right result.

Platform

Ubuntu or Kali Linux VM

Privileges

sudo access

Disk space

~5 GB free

Network

Internet for package install only

Memory Forensics

Five labs using Volatility 3 against memory images you capture yourself: acquisition, process/network triage, hunting for code injection, dumping artefacts back out of memory, and recovering an encryption key during its live-memory window.

▸

Acquire a Memory Image with AVML

Memory LAB 3.1

Time: 20 min Tools: avml, sha256sum

Run a marker process so it's identifiable in memory, capture a full RAM image with AVML, hash it immediately, and confirm the marker process is present in the raw bytes.

Install AVML

AVML is a single static binary from Microsoft. Download the release for Linux:

bash

cd ~/dfir && mkdir -p lab3.1 && cd lab3.1
wget -O avml https://github.com/microsoft/avml/releases/latest/download/avml
chmod +x avml
./avml --help

Start a "marker" process with a unique, searchable string

This simulates the malicious or notable process you'll later find in the memory dump.

bash

# Run a process with a distinctive command-line argument, in the background
sleep 600 --DFIR-MARKER-c2server.evil.example &
echo "Marker PID: $!"

Acquire the full memory image

This may take a few minutes depending on how much RAM your VM has allocated.

bash

sudo ./avml memory.lime
ls -lh memory.lime

Expected output

A file memory.lime roughly the size of your VM's allocated RAM (e.g. a 2GB VM produces a file close to 2GB).

Hash the image immediately

bash

sha256sum memory.lime | tee memory.lime.sha256

Confirm the marker string is physically present in the raw dump

Before any framework parses it, the raw bytes already contain the evidence — this is what makes memory forensics possible.

bash

strings memory.lime | grep "DFIR-MARKER"

Expected output

sleep 600 --DFIR-MARKER-c2server.evil.example appears at least once — proof the command line of a running process is captured verbatim in RAM.

Checkpoint

memory.lime was created and is roughly the size of allocated RAM
I hashed the image immediately after acquisition
strings located my DFIR-MARKER command line inside the raw dump

▸

Process and Network Triage with Volatility 3

Memory LAB 3.2

Time: 30 min Tools: Volatility 3 (pip), python3-venv

Install Volatility 3, run it against the image from Lab 3.1, and use pstree, cmdline, and netscan to find your marker process and its parent.

Install Volatility 3

bash

cd ~/dfir && mkdir -p lab3.2 && cd lab3.2
python3 -m venv volenv
source volenv/bin/activate
pip install volatility3

Run pstree against the memory image from Lab 3.1

Volatility 3 needs to identify the kernel/symbol layout — for a Linux image, generate a symbol table first if prompted, or pass --single-location directly. The first run takes longer as it builds caches.

bash

python3 -m volatility3.cli.vol -f ~/dfir/lab3.1/memory.lime linux.pstree

Expected output

A process tree showing PIDs and parent-child relationships. Locate the sleep process from Lab 3.1 and note its PID and PPID (parent process ID).

Confirm the command line for that PID

bash

python3 -m volatility3.cli.vol -f ~/dfir/lab3.1/memory.lime linux.psaux | grep -i marker

Expected output

A row showing the sleep 600 --DFIR-MARKER-c2server.evil.example command line, with its PID matching what you found in step 1.

List active network connections at the time of capture

bash

python3 -m volatility3.cli.vol -f ~/dfir/lab3.1/memory.lime linux.sockstat

Expected output

A list of open sockets per process at the moment of capture — including any SSH session you used to run the commands, which is itself a normal artefact you'd need to rule out during a real investigation.

Build a one-line triage summary

bash

echo "PID, PPID, and command line of marker process:" > triage_summary.txt
python3 -m volatility3.cli.vol -f ~/dfir/lab3.1/memory.lime linux.psaux | grep -i marker >> triage_summary.txt
cat triage_summary.txt

Checkpoint

linux.pstree ran successfully and showed a process tree
linux.psaux confirmed the DFIR-MARKER command line and its PID
I noted the PPID of the marker process and identified what shell/session spawned it

▸

Hunt for Suspicious Memory Regions

Memory LAB 3.3

Time: 25 min Tools: Volatility 3, /proc

Compare a process's memory mappings via /proc on a live system against what Volatility reports from your memory image, and identify which mapped regions are backed by files versus anonymous (potentially injected) memory.

On the live system, inspect your own shell's memory map

This shows what "normal" memory mappings look like for a legitimate process — your baseline for comparison.

bash

echo $$
cat /proc/$$/maps | head -20

Expected output

A list of memory regions, most showing a path on the right (e.g. /usr/bin/bash, /usr/lib/x86_64-linux-gnu/libc.so.6) — these are file-backed. A few lines with [heap], [stack], or no path at all are normal anonymous regions every process has.

Find the same process in your memory image with Volatility

bash

cd ~/dfir/lab3.2
source volenv/bin/activate

# List memory maps for all processes (this can be a large output)
python3 -m volatility3.cli.vol -f ~/dfir/lab3.1/memory.lime linux.proc.Maps --pid <PID_FROM_STEP_1>

Expected output

A similar list of mapped regions for the same PID, reconstructed entirely from the memory image — this should broadly match what /proc/PID/maps showed live, since the dump captured that process's state.

Identify what an injected/suspicious mapping would look like

Without real malware, document the red flags so you'd recognise them:

Reference: red flags in a maps listing

Observation	Why it matters
Region with rwx (read+write+execute) permissions	Legitimate code is rarely both writable and executable at once — this combination is a classic injection indicator.
Executable region with no file path	Normal executable code maps back to a file on disk (the binary or a library). Anonymous executable memory often means code was written directly into RAM.
A well-known system process (e.g. bash, sshd) with an unusually large number of anonymous mappings	Could indicate a loader or injected shellcode allocated extra memory regions.

Search your own process's maps for any rwx regions

bash

cat /proc/$$/maps | grep rwx

Expected output

Likely no output (empty) — a normal bash shell has no rwx regions. This confirms what "clean" looks like, so a hit on a real case stands out by contrast.

Checkpoint

I reviewed /proc/PID/maps for a live process and identified file-backed vs anonymous regions
linux.proc.Maps reproduced a similar mapping list from the memory image
I confirmed my own shell has no rwx memory regions, establishing a clean baseline

▸

Recover File Contents from Memory

Memory LAB 3.4

Time: 20 min Tools: strings, grep, Volatility 3

Open a file on the live system so its contents enter the page cache, capture memory, then recover the file's text content directly from the RAM image — without ever touching the disk copy during analysis.

Create a "sensitive" file and read it into memory

bash

mkdir -p ~/dfir/lab3.4 && cd ~/dfir/lab3.4
echo "API_KEY=sk-DFIR-LAB-3f9a8b2c1d4e5f6a7b8c9d0e" > secret_config.env

# Read it so its contents are cached in RAM
cat secret_config.env

Capture memory again with AVML

bash

sudo ~/dfir/lab3.1/avml memory2.lime
sha256sum memory2.lime > memory2.lime.sha256

Search the raw memory image for the secret value

bash

strings memory2.lime | grep "API_KEY"

Expected output

API_KEY=sk-DFIR-LAB-3f9a8b2c1d4e5f6a7b8c9d0e — the full secret, recovered from a raw RAM dump with a basic string search, demonstrating why secrets in memory matter even if a disk is encrypted.

Use Volatility to list open file handles for your shell

bash

cd ~/dfir/lab3.2
source volenv/bin/activate
python3 -m volatility3.cli.vol -f ~/dfir/lab3.4/memory2.lime linux.lsof --pid $$

Expected output

A list of open file descriptors for your shell's PID — note that $$ refers to your current shell, which may differ from the shell active at capture time. If the PID doesn't match, use linux.pstree first to find the correct PID for the shell that ran step 1.

Checkpoint

I created secret_config.env and displayed its contents before capturing memory
strings on memory2.lime recovered the full API_KEY value
I can explain why this matters for systems using full-disk encryption

▸

Recover an Encryption Key from a Memory Dump

Memory LAB 3.5

Time: 25 min Tools: openssl, python3, AVML, strings/grep

Generate an AES key inside a running process, capture memory while the key is resident, then locate the raw key bytes in the dump — demonstrating the "window between key generation and key wipe" that makes memory-based key recovery possible.

Write a small script that generates and holds an AES key

The script generates a random 256-bit key, prints it (so we know what to search for), and then sleeps — keeping the key resident in its process memory the whole time.

bash

mkdir -p ~/dfir/lab3.5 && cd ~/dfir/lab3.5

cat > keyholder.py << 'EOF'
import os, time, binascii

key = os.urandom(32)  # 256-bit AES key
print("Generated key (hex):", binascii.hexlify(key).decode())
print(f"PID: {os.getpid()}")
print("Holding key in memory for 120 seconds...")
time.sleep(120)
EOF

python3 keyholder.py > keyinfo.txt &
sleep 1
cat keyinfo.txt

Expected output

A line showing Generated key (hex): <64 hex characters> and the process PID. Record the hex key value — this is your "ground truth" for the search.

Capture memory while the key is still resident

The script sleeps for 120 seconds, giving you a window to capture memory before it exits and the key is freed.

bash

sudo ~/dfir/lab3.1/avml memory_key.lime
sha256sum memory_key.lime > memory_key.lime.sha256

Search the dump for the printed hex representation of the key

Because the script printed the key as hex text to stdout, that text representation is likely cached in memory too — search for it first as a sanity check.

bash

# Extract the hex key value you recorded in step 1, then search for it
KEY_HEX=$(grep "Generated key" keyinfo.txt | awk '{print $NF}')
echo "Searching for: $KEY_HEX"

strings memory_key.lime | grep "$KEY_HEX"

Expected output

The hex string appears at least once in the dump — the printed text output was buffered in the process's memory at capture time.

Search for the raw binary key bytes (not just the hex text)

The actual 32 raw key bytes held by the Python key variable are a different — and more realistic — target than the printed text. Convert the hex back to raw bytes and grep the binary dump for that exact byte sequence.

bash

# Convert hex string back to raw binary, write to a small file
echo -n "$KEY_HEX" | xxd -r -p > key.bin
ls -la key.bin   # should be exactly 32 bytes

# Search the memory dump for this exact 32-byte sequence
grep -aboF "$(cat key.bin)" memory_key.lime | head -5

Expected output

At least one byte-offset match (e.g. 1483920192:...), confirming the raw 32-byte AES key — the actual key material that would be used to encrypt/decrypt data — is physically present in RAM. If no match is found, the key may have been in a CPU register or already garbage-collected at the moment of capture; note this as a real limitation of the technique.

Let the process exit and confirm the key disappears

bash

# Wait for the keyholder script to finish
wait

# Capture memory again now that the process has exited
sudo ~/dfir/lab3.1/avml memory_after.lime

# Search again -- this time the exact byte sequence should be much less likely to appear
grep -aboF "$(cat key.bin)" memory_after.lime | head -5

Expected output

Typically no match (or far fewer matches) — once the process exits, its memory is freed and eventually reused, illustrating the "window between key generation and key wipe": capture timing is everything in this technique.

Checkpoint

I recorded the hex AES key printed by keyholder.py
strings located the printed hex text inside memory_key.lime
grep -aboF located the raw 32-byte key in the dump while the process was alive
I compared results before vs after process exit and can explain the difference

Network Forensics

Six labs: capture and filter your own traffic with tcpdump/Wireshark, reconstruct a full TCP conversation, simulate and detect DNS beaconing, analyse email headers for spoofing indicators, generate and correlate flow-level connection logs, and examine TLS certificates for red flags.

▸

Capture and Filter Live Traffic

Network LAB 4.1

Time: 20 min Tools: tcpdump, Wireshark or tshark

Capture live traffic to a .pcap file while generating known HTTP and DNS activity, then apply display filters to isolate just that traffic.

Install required tools

sudo apt install tcpdump tshark curl -y (Wireshark GUI optional: sudo apt install wireshark)

Identify your network interface

bash

ip -brief link show

Expected output

A list of interfaces — typically eth0 or enp0s3 for the primary network adapter. Use this name in the next step.

Start a capture, then generate traffic in another terminal

Run the capture in one terminal (it will run for 20 seconds), and in a second terminal — opened immediately — run the curl commands.

terminal 1

mkdir -p ~/dfir/lab4.1 && cd ~/dfir/lab4.1
sudo timeout 20 tcpdump -i <your_interface> -w capture.pcap

terminal 2

curl -s http://example.com > /dev/null
nslookup example.com

Inspect the capture summary

bash

tshark -r capture.pcap -q -z io,phs

Expected output

A protocol hierarchy showing percentages for dns and http (or tls if example.com redirected to https) among the captured frames.

Apply display filters to isolate DNS and HTTP traffic

bash

# Show only DNS queries and responses
tshark -r capture.pcap -Y "dns"

# Show only HTTP requests, with method and host
tshark -r capture.pcap -Y "http.request" -T fields -e ip.dst -e http.host -e http.request.method

Expected output

The DNS filter shows the query for example.com and its A-record response. The HTTP filter shows a GET request with host example.com (if the connection wasn't upgraded to HTTPS).

Checkpoint

capture.pcap was created and contains traffic
The protocol hierarchy shows dns and http/tls entries
I isolated the DNS query for example.com using a display filter

▸

Reconstruct a Full TCP Conversation

Network LAB 4.2

Time: 20 min Tools: netcat, tcpdump, tshark

Capture a plaintext conversation between a local "client" and "server" using netcat, then reassemble the full TCP stream from the .pcap to read the conversation as the application saw it.

Start a capture on the loopback interface

terminal 1

mkdir -p ~/dfir/lab4.2 && cd ~/dfir/lab4.2
sudo tcpdump -i lo -w stream.pcap port 9999

Start a netcat "server" listening on port 9999

terminal 2

nc -l -p 9999

Connect as a "client" and exchange messages

In a third terminal, connect and type a message. Switch to terminal 2 and type a reply. Then close both with Ctrl+C and stop the tcpdump in terminal 1 with Ctrl+C.

terminal 3

nc 127.0.0.1 9999
# Type: USER admin
# Type: PASS S3cr3tPass!

terminal 2 (reply)

# Type: 230 Login successful

Reassemble the TCP stream from the capture

bash

# List TCP streams found in the capture
tshark -r stream.pcap -q -z conv,tcp

# Follow stream 0 and print it as ASCII
tshark -r stream.pcap -q -z follow,tcp,ascii,0

Expected output

The full reconstructed conversation, including USER admin, PASS S3cr3tPass!, and 230 Login successful — all sent in plaintext over individual TCP segments, now readable as one continuous exchange.

Checkpoint

stream.pcap captured the loopback exchange on port 9999
tshark conv,tcp listed at least one TCP stream
The follow,tcp,ascii output showed both sides of the conversation, including the plaintext "password"

▸

Detect DNS Beaconing Patterns

Network LAB 4.3

Time: 20 min Tools: bash, tcpdump, tshark, awk

Generate a synthetic "beaconing" pattern — repeated DNS queries at a fixed interval — capture it, then write a short analysis that flags the regular interval as suspicious.

Start a capture for 35 seconds

terminal 1

mkdir -p ~/dfir/lab4.3 && cd ~/dfir/lab4.3
sudo timeout 35 tcpdump -i any -w beacon.pcap port 53

Generate a fixed-interval DNS query loop

This simulates malware "phoning home" to a C2 domain every 10 seconds.

terminal 2

for i in 1 2 3; do
  nslookup beacon-c2.dfir-lab.example
  sleep 10
done

Extract the timestamps of each query to that domain

bash

tshark -r beacon.pcap -Y "dns.qry.name contains \"beacon-c2\"" \
  -T fields -e frame.time_relative -e dns.qry.name

Expected output

Three lines (one per query, possibly more if retries occurred) with relative timestamps roughly 0.0, 10.0, and 20.0 — a near-perfect 10-second interval.

Calculate the intervals programmatically

bash

tshark -r beacon.pcap -Y "dns.qry.name contains \"beacon-c2\"" \
  -T fields -e frame.time_relative | awk 'NR>1{print $1-prev} {prev=$1}'

Expected output

A series of values close to 10.0 — the inter-query interval. In a real investigation, intervals this consistent (low variance) across dozens or hundreds of queries to an unfamiliar domain are a strong beaconing indicator.

Checkpoint

beacon.pcap captured at least 3 queries to beacon-c2.dfir-lab.example
I extracted relative timestamps for each query
Calculated intervals were consistently close to 10 seconds

▸

Analyse Email Headers for Spoofing

Network LAB 4.4

Time: 15 min Tools: bash, text editor

Examine a provided raw email header sample, trace the Received chain, and determine whether SPF/DKIM results indicate spoofing.

Save a sample header to a file

This sample represents a phishing email claiming to be from a finance department.

bash

mkdir -p ~/dfir/lab4.4 && cd ~/dfir/lab4.4
cat > sample_header.txt << 'EOF'
Received: from mx.victimcorp.com (mx.victimcorp.com [198.51.100.10])
        by mailgw.victimcorp.com with ESMTP id a1b2c3
        for <employee@victimcorp.com>; Tue, 14 Mar 2026 09:14:05 +0000
Received: from smtp-relay.attacker-host.net (203.0.113.77)
        by mx.victimcorp.com with ESMTP id d4e5f6
        for <employee@victimcorp.com>; Tue, 14 Mar 2026 09:14:02 +0000
Authentication-Results: mx.victimcorp.com;
    spf=fail smtp.mailfrom=ceo@victimcorp.com;
    dkim=none (no signature found)
From: "CEO - Victim Corp" <ceo@victimcorp.com>
Reply-To: finance.urgent@attacker-host.net
Subject: URGENT: Wire transfer needed before EOD
EOF
cat sample_header.txt

Trace the Received chain bottom-to-top

bash

grep "^Received:" sample_header.txt | tac

Expected output

Reading bottom-to-top (the order mail actually travelled), the message originated from smtp-relay.attacker-host.net (203.0.113.77) — not from any victimcorp.com infrastructure — before being relayed to mx.victimcorp.com.

Check the authentication results

bash

grep -A2 "Authentication-Results" sample_header.txt

Expected output

spf=fail for smtp.mailfrom=ceo@victimcorp.com, and dkim=none — both checks failed, meaning the receiving server could not verify this message actually came from victimcorp.com's authorised mail servers.

Compare the From and Reply-To domains

bash

grep -E "^(From|Reply-To):" sample_header.txt

Expected output

From: ceo@victimcorp.com but Reply-To: finance.urgent@attacker-host.net — any reply to this "urgent" request would go straight to the attacker's domain, not to the real CEO.

Write a one-paragraph verdict

Based on steps 2–4, write a short summary (3–4 sentences) stating whether this email is spoofed and what evidence supports that conclusion. Save it as verdict.txt.

bash

nano verdict.txt

Checkpoint

I traced the Received chain and identified the true originating host
I identified that both SPF and DKIM failed/were absent
I noted the From/Reply-To domain mismatch and wrote a verdict

▸

Generate and Correlate Flow-Level Connection Logs

Network LAB 4.5

Time: 25 min Tools: tshark, awk, Zeek (optional)

Convert a packet capture into flow-style connection records (the kind NetFlow or Zeek's conn.log would produce), then correlate those flow records against firewall-style log lines to spot an anomalous high-volume connection.

Generate mixed traffic: some normal, one high-volume connection

terminal 1

mkdir -p ~/dfir/lab4.5 && cd ~/dfir/lab4.5
sudo timeout 25 tcpdump -i any -w flows.pcap

terminal 2

# A few small, normal-looking requests
curl -s http://example.com > /dev/null
curl -s http://example.org > /dev/null

# One "high-volume" transfer -- simulate exfiltration with a larger download
curl -s https://speed.hetzner.de/100MB.bin -o /tmp/bigfile --max-time 15 || true

Convert the capture into flow-style records with tshark

Each line below approximates one NetFlow/conn.log record: source, destination, port, protocol, and total bytes per conversation.

bash

tshark -r flows.pcap -q -z conv,ip > flow_summary.txt
cat flow_summary.txt

Expected output

A table of IP-to-IP conversations with columns for packets and bytes in each direction. One row — corresponding to the 100MB download — should show a Bytes total dramatically larger than the others (likely megabytes vs. a few KB).

Build a simplified conn.log-style CSV

bash

echo "src_ip,dst_ip,dst_port,proto,bytes" > conn.csv
tshark -r flows.pcap -q -z conv,ip | grep -E "^[0-9]" | \
  awk '{gsub(/<-+>/,",",$0); print $1","$3","$NF}' >> conn.csv 2>/dev/null

# Simpler, reliable alternative: per-packet byte totals grouped by destination
tshark -r flows.pcap -T fields -e ip.dst -e frame.len | \
  awk '{sum[$1]+=$2} END {for (ip in sum) print ip","sum[ip]}' | sort -t, -k2 -rn > dst_bytes.csv

cat dst_bytes.csv

Expected output

dst_bytes.csv lists destination IPs sorted by total bytes received, descending. The IP associated with the 100MB download should be at the top, with a byte total an order of magnitude larger than the example.com/example.org entries.

Create a synthetic firewall log and correlate by IP

Real investigations correlate flow data against firewall/proxy logs by matching IPs and timestamps. Simulate that correlation here.

bash

# Grab the top destination IP from your flow analysis
TOP_IP=$(head -1 dst_bytes.csv | cut -d, -f1)
echo "Top talker by bytes: $TOP_IP"

# Synthetic firewall log -- one line per allowed connection
cat > firewall.log << EOF
2026-03-14 09:10:01 ALLOW 10.0.0.15 -> 93.184.216.34:80 proto=TCP
2026-03-14 09:10:03 ALLOW 10.0.0.15 -> 96.7.128.175:80 proto=TCP
2026-03-14 09:10:05 ALLOW 10.0.0.15 -> $TOP_IP:443 proto=TCP
EOF

# Correlate: does the top flow-bytes IP appear in the firewall log?
grep "$TOP_IP" firewall.log

Expected output

The firewall log line for the high-volume IP is printed — in a real SOC workflow, this is the moment an analyst pivots from "this connection moved a lot of data" (flow data) to "this connection was explicitly allowed at 09:10:05" (firewall log), narrowing the investigation to a specific rule or time window.

Checkpoint

flows.pcap captured both the small requests and the large download
dst_bytes.csv shows one destination IP with a byte count far above the others
I correlated that IP against a synthetic firewall log entry

▸

TLS Certificate Analysis

Network LAB 4.6

Time: 20 min Tools: openssl, tshark

Generate a self-signed certificate (the kind malware C2 infrastructure commonly uses), inspect its fields with OpenSSL, then capture and examine a real TLS handshake to compare a legitimate certificate against the red flags identified in the self-signed one.

Generate a self-signed certificate, as a C2 server might

bash

mkdir -p ~/dfir/lab4.6 && cd ~/dfir/lab4.6

openssl req -x509 -newkey rsa:2048 -keyout c2.key -out c2.crt \
  -days 3 -nodes \
  -subj "/CN=update-service.dfir-lab.example"

Inspect the certificate's fields

bash

openssl x509 -in c2.crt -noout -text | head -30

Expected output

Note three things in the output: Issuer and Subject are identical (self-signed — no trusted CA vouches for it), the Validity period is only 3 days (malware certs are often short-lived to evade blocklists), and there's no Subject Alternative Name matching a well-known organisation.

Start a TLS server using this certificate and capture the handshake

terminal 1

cd ~/dfir/lab4.6
sudo timeout 20 tcpdump -i lo -w tls_handshake.pcap port 8443 &

openssl s_server -accept 8443 -cert c2.crt -key c2.key -www &
sleep 1

terminal 2

curl -sk https://127.0.0.1:8443/ > /dev/null
sleep 3
# Stop the server
pkill -f "s_server"

Extract certificate details directly from the captured handshake

bash

tshark -r tls_handshake.pcap -Y "tls.handshake.type == 11" \
  -T fields -e x509ce.dNSName -e x509sat.uTF8String -e tls.handshake.certificate

Expected output

Fields extracted from the Certificate message in the handshake, including the CN value update-service.dfir-lab.example — demonstrating that certificate metadata is visible in plaintext during the handshake even though the application data that follows is encrypted.

Compare against a real-world certificate

bash

# Fetch and inspect a real site's certificate for comparison
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | \
  openssl x509 -noout -issuer -subject -dates

Expected output

Field	Self-signed C2 cert	Real-world cert
Issuer	Same as Subject (self-signed)	A recognised CA (e.g. DigiCert, Let's Encrypt)
Validity	3 days	Typically 60–398 days
Subject	Arbitrary, attacker-chosen CN	Matches the legitimate domain

Checkpoint

I generated a self-signed cert and identified Issuer == Subject
I captured a TLS handshake and extracted the certificate CN from the pcap
I compared Issuer/Validity/Subject between the self-signed cert and a real CA-issued cert

Digital Forensics Hands-On Labs

Run Every Core Forensics Technique Yourself

Forensic Foundations

Verify Evidence Integrity with Hashing

Mount Evidence Read-Only (Software Write Blocking)

Capture Evidence in Order of Volatility

Build a Chain-of-Custody Log

Disk & File System Forensics

Create and Verify a Forensic Disk Image

Recover Deleted Files from Unallocated Space

File Carving by Signature

Extract Metadata and Detect Hidden Data

MACB Timestamp Analysis & Ransomware Simulation

Memory Forensics

Acquire a Memory Image with AVML

Process and Network Triage with Volatility 3

Hunt for Suspicious Memory Regions

Recover File Contents from Memory

Recover an Encryption Key from a Memory Dump

Network Forensics

Capture and Filter Live Traffic

Reconstruct a Full TCP Conversation

Detect DNS Beaconing Patterns

Analyse Email Headers for Spoofing

Generate and Correlate Flow-Level Connection Logs

TLS Certificate Analysis