Digital Forensics: Investigating Security Incidents

Digital forensics is the practice of identifying, preserving, analyzing, and reporting on digital evidence from computers, networks, and storage devices following a security incident — following strict chain of custody and legal procedures.

What You’ll Learn

You’ll follow the complete forensic process (identification, preservation, analysis, reporting), create forensic disk images with FTK Imager and Guymager, perform memory analysis with Volatility, analyze network traffic with Wireshark, build timeline analyses of attacker activity, and maintain proper chain of custody documentation.

Why It Matters

When a security breach occurs, digital forensics determines what happened, how the attacker gained access, what data was stolen, and how to prevent recurrence. Durga Antivirus Pro’s incident response team uses these exact techniques to investigate malware outbreaks in enterprise environments.

Real-World Use

A company discovers ransomware on their file server. The forensics team creates a disk image (write-blocked), captures volatile memory, analyzes network logs with Wireshark to find the initial infection vector (phishing email with malicious attachment), traces lateral movement via RDP logs, and produces a report with timeline, root cause, and remediation steps.

Forensic Investigation Process

flowchart LR
    A[Identification] --> B[Preservation]
    B --> C[Collection]
    C --> D[Examination]
    D --> E[Analysis]
    E --> F[Reporting]
    F --> G[Presentation]
    A --> H[Scope the incident]
    B --> I[Write-block + hash]
    C --> J[Disk + Memory + Network]
    D --> K[Recover artifacts]
    E --> L[Timeline + Correlation]
    style A fill:#dc2626,color:#fff
    style B fill:#2563eb,color:#fff
    style F fill:#059669,color:#fff

Step 1: Preservation — Forensic Disk Imaging

Never boot from the suspect drive. Use a write-blocker and forensic imager:

# Linux with Guymager (GUI disk imager)
sudo guymager

# Or using dd with hashing (Linux)
# Identify the suspect device (do NOT mount it!)
sudo fdisk -l
# /dev/sdb is the suspect drive

# Create forensic image with SHA256 hash
sudo dd if=/dev/sdb of=/evidence/case123/image.dd bs=4M conv=noerror,sync status=progress

# Generate hash for chain of custody
sha256sum /evidence/case123/image.dd > /evidence/case123/image.dd.sha256

# Verify the hash later
sha256sum -c /evidence/case123/image.dd.sha256

Expected output: A bit-for-bit copy of the suspect drive. The SHA256 hash is your fingerprint — if the image file changes by a single bit, the hash changes. This proves the evidence hasn’t been tampered with.

FTK Imager (Windows) Command Line

# FTK Imager CLI — create E01 (EnCase) format with compression
ftkimager.exe \\.\PHYSICALDRIVE2 C:\evidence\case123\image.E01 --e01-case-number "CASE-2025-123" --e01-evidence-number "E01" --e01-description "Suspect laptop SSD" --e01-examiner "Analyst Name" --verify

Expected output: E01 format includes compressed data, metadata (case number, examiner), and built-in integrity checking. Every time you open the image, FTK Imager verifies it hasn’t been modified.

Step 2: Memory Forensics with Volatility

Volatile memory (RAM) contains running processes, network connections, encryption keys, and evidence of rootkits:

# Capture memory (using LiME on Linux or winpmem on Windows)
# First, identify the memory image format
volatility -f memory.raw imageinfo

# List running processes at time of capture
volatility -f memory.raw --profile=Win10x64_19041 pslist

# List network connections
volatility -f memory.raw --profile=Win10x64_19041 netscan

# Extract command-line arguments (often reveals attacker commands)
volatility -f memory.raw --profile=Win10x64_19041 cmdline

# Dump a suspicious process for analysis
volatility -f memory.raw --profile=Win10x64_19041 procdump -p 1234 --dump-dir ./dumps

# Scan for injected code (Malfind)
volatility -f memory.raw --profile=Win10x64_19041 malfind

# Extract registry hives from memory
volatility -f memory.raw --profile=Win10x64_19041 hivelist

# Extract hashed passwords
volatility -f memory.raw --profile=Win10x64_19041 hashdump

Expected output: pslist shows every process running when memory was captured. netscan reveals active network connections — including suspicious outbound connections to unknown IPs on non-standard ports. malfind highlights memory regions with executable code that wasn’t loaded from disk (process injection).

Interpreting Memory Artifacts

# Typical memory forensics findings:
1. svchost.exe running from C:\Users\Public\ — FAKE, real svchost is in C:\Windows\System32
2. PowerShell with encoded command — likely C2 beacon
3. Notepad.exe with mapped memory — possible credential theft
4. Unknown process with outbound connection to 185.234.x.x:4443 — C2 server

Step 3: Network Forensics with Wireshark

# Capture network traffic
sudo tcpdump -i eth0 -w incident.pcap -s 0

# Analyze in Wireshark — key filters:

# Show all HTTP requests (potential C2)
http.request

# Show DNS queries (data exfiltration?)
dns.qry.name contains "."

# Show TLS handshake (find C2 servers)
tls.handshake.type == 1

# Show suspicious ports (non-standard)
tcp.port not in {80,443,22,53} and tcp.flags.syn == 1

# Extract files from traffic (HTTP objects)
# File → Export Objects → HTTP

# Command-line analysis with tshark
tshark -r incident.pcap -Y "http.request" -T fields -e http.host -e http.user_agent -e http.request.uri

# Extract all IP addresses involved
tshark -r incident.pcap -T fields -e ip.src -e ip.dst | sort -u

# Find the most active IPs
tshark -r incident.pcap -T fields -e ip.src | sort | uniq -c | sort -rn | head -10

Expected output: You identify three key artifacts: (1) an HTTP POST to evil.com/upload with a PowerShell payload, (2) DNS TXT queries to a domain that resolves to a known malicious IP, (3) periodic beaconing (HTTPS to same IP every 60 seconds). The attacker’s initial access vector and C2 infrastructure are mapped.

Step 4: Timeline Analysis

Building a timeline of attacker activity is the most critical phase:

# Windows: Extract $MFT (Master File Table) timeline
# Use MFT Dump or analyze with Timeliner in Autopsy

# Linux: Create timeline from MAC (Modify, Access, Change) times
# Using fls and mactime from The Sleuth Kit

fls -r -m /evidence image.dd > body_file.txt
mactime -b body_file.txt -d -z UTC > timeline.csv

# Parse the timeline — look for anomalies
# 2025-06-15 02:30:00 — user logged in (off-hours)
# 2025-06-15 02:31:00 — PowerShell executed
# 2025-06-15 02:32:00 — file downloaded to Downloads folder
# 2025-06-15 02:33:00 — archive.exe executed
# 2025-06-15 02:35:00 — data.zip created from Documents folder
# 2025-06-15 02:36:00 — RDP connection to file-server

Expected output: A chronological timeline showing the attack — initial access (phishing link), execution (PowerShell download cradle), persistence (registry run key), lateral movement (RDP to file server), and exfiltration (FTP upload of archived data). Each event is timestamped and sourced from different artifacts (event logs, file timestamps, registry keys).

Step 5: Chain of Custody Documentation

# CHAIN OF CUSTODY FORM
# Case Number: DF-2025-00123

| Date (UTC) | Time | Item | From | To | Purpose |
|-------------|------|------|------|----|---------|
| 2025-06-15 | 08:30 | Suspect laptop (SN: XYZ123) | CEO Office | Forensics Lab | Initial collection |
| 2025-06-15 | 09:15 | Laptop imaged (E01) | John Doe (Analyst) | Evidence Locker | Preservation |
| 2025-06-16 | 10:00 | Image E01 copy | Evidence Locker | Jane Smith (Analyst) | Analysis |

# Hash verification log:
# SHA256 of original image: a1b2c3d4e5f6...
# SHA256 on transfer to analyst: a1b2c3d4e5f6... ✓ Match

Expected output: Every person who handles the evidence, every transfer, and every access is logged. Hashes are verified at each transfer. This documentation is what makes the evidence admissible in court.

Common Errors

1. Booting from the suspect drive The single biggest forensic error. Booting from a suspect drive changes hundreds of file timestamps, modifies registry keys, creates temporary files, and overwrites free space. Always attach the drive via a write-blocker and image it before any analysis.

2. Not capturing volatile data first Order of volatility: registers → cache → RAM → network connections → running processes → disk → backups. If you turn off the computer to image the disk, you lose all volatile evidence (running processes, network connections, encryption keys in memory).

3. Insufficient documentation “You can’t document what you didn’t document.” Every command, every tool version, every finding must be recorded. If you ran Volatility 2.6 instead of 2.7, the output might differ. If you filtered a packet capture, log the exact filter.

4. Analyzing on the original evidence Never analyze the original image. Make a working copy, hash-verify it, and analyze the copy. If you corrupt the working copy (and you will), the original is still intact.

5. Confirmation bias Don’t look for evidence that supports your theory while ignoring contradictory evidence. If you think it’s a phishing attack but the timeline shows a physical access vector (USB insertion), follow the evidence, not your hypothesis.

Practice Questions

1. What is the order of volatility and why does it matter? The order of volatility dictates what to capture first: CPU registers and cache, then RAM, then network connections, then running processes, then disk, then backups. The most volatile data (RAM) disappears when power is lost; capture it first.

2. How does Volatility detect injected code (Malfind)? Malfind scans memory for pages that are readable, writable, AND executable (RWX) — a rare permission combination for normal executables. It then disassembles the first few instructions and checks for suspicious patterns like call instructions or shellcode.

3. What is the MFT and how does it help forensic analysis? The Master File Table (NTFS) records every file’s metadata — creation time, modification time, access time, size, and parent directory. By analyzing MFT entries, you can determine exactly when files appeared, were modified, or were deleted — creating a complete file system timeline.

4. How do you distinguish legitimate network traffic from C2 beacons? C2 beacons have predictable patterns: periodic intervals (every 60 seconds), consistent packet sizes (small HTTP POST/GET), similar User-Agent strings, and destinations on non-standard ports. Legitimate traffic has variable timing, sizes, and destinations.

5. Challenge: Perform a complete forensic analysis on a provided image Download a forensic challenge image (e.g., from CFReDS or DFIR challenges). Identify the OS, find the malicious executable, determine when it was executed, trace its network connections, identify the data exfiltrated, and write a complete forensic report.

FAQ

What’s Next

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.