Learn Ethical Hacking (#76) - Digital Forensics Deep Dive - Evidence That Holds Up

avatar

Learn Ethical Hacking (#76) - Digital Forensics Deep Dive - Evidence That Holds Up

leh-banner.jpg

What will I learn

  • Digital forensics methodology -- the systematic process of collecting, preserving, and analyzing digital evidence;
  • Disk forensics -- creating forensic images, file system analysis, and recovering deleted files;
  • Memory forensics -- analyzing RAM captures with Volatility to find malware, credentials, and hidden processes;
  • Timeline analysis -- reconstructing what happened, when, and in what order;
  • Windows forensic artifacts -- registry hives, prefetch, amcache, shimcache, and event logs as evidence;
  • Linux forensic artifacts -- bash history, auth logs, journal, and file timestamps;
  • Chain of custody -- ensuring evidence is admissible in court;
  • Defense: preparing your systems for forensic readiness before an incident occurs.

Requirements

  • A working modern computer running macOS, Windows or Ubuntu;
  • Autopsy or FTK Imager installed;
  • Volatility 3 installed (pip install volatility3);
  • Understanding of incident response from Episode 51;
  • The ambition to learn ethical hacking and security research.

Difficulty

  • Advanced

Curriculum (of the Learn Ethical Hacking Series):

Learn Ethical Hacking (#76) - Digital Forensics Deep Dive - Evidence That Holds Up

Solutions to Episode 75 Exercises

Exercise 1: Persistence hunt on lab Windows VM (abbreviated).

Hunt report -- HUNT-2026-043: Windows Persistence Mechanisms

Scheduled tasks found: 4
  - GoogleUpdate (legitimate -- Google Chrome updater)
  - OneDriveStandaloneUpdater (legitimate -- OneDrive)
  - MicrosoftEdgeUpdateTaskMachine (legitimate -- Edge)
  - Maintenance (SUSPICIOUS -- runs C:\temp\beacon.exe at boot,
    created during episode 41 Metasploit exercise, artifact from lab)

Services found: 1 suspicious
  - PSEXESVC (artifact from episode 34 PsExec lateral movement exercise)

Registry run keys: 1 suspicious
  - HKCU\...\Run\Updater -> C:\Users\user\AppData\update.exe
    (artifact from episode 63 persistence exercise)

WMI subscriptions: 0 (clean)

Verdict: 3 persistence artifacts from earlier lab exercises.
All removed. No indication of unauthorized persistence.

Finding your own lab artifacts is actually one of the best forensic training exercises you can do. The three persistence mechanisms discovered here -- a scheduled task from the Metasploit exercise in episode 41, a service left behind by PsExec in episode 34, and a registry run key from the persistence exercise in episode 63 -- represent the three most common Windows persistence techniques in real-world attacks. The scheduled task running C:\temp\beacon.exe at boot is the most dangerous because it executes with whatever privilege the task was created under (and if the lab VM was running as admin, that is SYSTEM-level persistence). The PSEXESVC service is PsExec's calling card -- Sysinternals PsExec installs a temporary service on the remote machine to execute commands, and when PsExec does not clean up after itself (which happens if the session terminates abnormally), the service stays installed. And the registry run key writing to \AppData\update.exe is the classic malware persistence trick: name your binary something that sounds like a legitimate updater, drop it in AppData where the user has write permission, and it runs every time the user logs in.

The fact that all three were identified and attributed to specific lab exercises shows the value of methodical enumeration. In a real investigation, you would find similar artifacts mixed in with hundreds of legitimate entries -- Google's updater, OneDrive's sync service, Edge's maintenance tasks -- and the challenge is separating the malicious from the mundane. That seperation is exactly what forensic analysis adds: not just finding things, but documenting them with enough context and evidence to determine what they are and how they got there. The WMI subscriptions check (coming back clean) is equally important to document -- a null result in a specific category means you checked it and can confirm it was not used, rather than leaving it as an unknown.

Exercise 2: Lateral movement hunt (abbreviated).

Authentication anomalies (7-day window):

First-time access: t1-srvadm1 authenticated to WS02 (workstation)
  on May 17 at 22:14. t1-srvadm1 is a Tier 1 server admin account.
  This violates tiered administration -- investigate.
  Verdict: lab testing from episode 72. Expected.

Admin from non-admin workstation: 0 (tiering GPO working correctly)
After-hours auth: 3 events (all from lab exercises, expected)

The tiered administration violation is the highlight here. A Tier 1 server admin account (t1-srvadm1) authenticating to a regular workstation (WS02) is exactly the kind of anomaly that separates a lateral movement hunt from a general log review. If you implemented the tiering model from episode 72 correctly, server admin accounts should NEVER touch workstations -- their credentials are scoped to servers only, and a GPO should prevent interactive logon at the workstation tier. The fact that this violation was traced back to a lab testing session from episode 72 is the correct outcome: you broke the rule deliberately during the exercise, and the hunt correctly identified the resulting anomaly. In a real environment, the same finding without a lab explanation would trigger immediate investigation -- because an attacker who has compromised a Tier 1 credential and is using it to access a workstation is doing exactly what Kerberos-based lateral movement looks like.

The "after-hours auth: 3 events" finding is interesting because it highlights how context shapes interpretation. Three after-hours authentication events from a SOC analyst running penetration tests at 10 PM is completely expected. Three after-hours authentication events from a marketing intern's account at 3 AM is a red flag. The SIEM query can surface the events, but a human analyst (or a forensic investigator reconstructing a timeline after the fact) must provide the context that determines whether each event is legitimate or suspicious. This is the same judgment call that separates automated monitoring from active investigation.

Exercise 3: Hunt hypotheses (abbreviated).

Hypothesis 1: "An attacker may have Kerberoasted service accounts"
  Data: Event 4769 (TGS requests with RC4 encryption)
  Query: EventCode=4769 TicketEncryptionType=0x17
  Positive: >5 RC4 TGS requests from single source in 1 hour

Hypothesis 2: "An attacker may have established C2 via DNS tunneling"
  Data: DNS query logs
  Query: dns.query length > 50 chars, grouped by base domain
  Positive: >100 long queries to single domain in 24 hours
  [... 3 more hypotheses ...]

The structure of these hypotheses is what makes them forensically useful, not just operationally useful. Each hypothesis specifies exactly what data to look at (Event 4769, DNS query logs), exactly what to query for (RC4 encryption type, long subdomain labels), and exactly what constitutes a positive finding (thresholds: >5 requests or >100 queries). That level of specificity matters enormously when the context shifts from "are we being attacked right now?" to "can we prove what happened 3 months ago?" A forensic investigator working the same case would use these identical queries against historical data -- but with the additional burden of documenting the methodology so thoroughly that it can withstand cross-examination in court. The Kerberoasting hypothesis connects directly to episode 33 (Active Directory attacks), and the DNS tunneling hypothesis connects to the C2 hunting techniques from episode 75. Both are techniques that leave durable artifacts in log data (event logs and DNS query logs persist for months if your retention is configured properly), which makes them excellent candidates for forensic analysis long after the fact.

Episode 75 covered threat hunting -- proactively searching through your environment's data for indicators of compromise that no alert rule covers. Hypothesis-driven hunts, persistence enumeration, lateral movement pattern analysis, C2 beaconing detection, and building the organizational maturity to make hunting a continuous capability rather than an ad-hoc activity. That episode gave you the skills to FIND attacker activity in your environment. But finding it is only the first step. Once you have found evidence that a compromise occurred, a completely different set of questions takes over: What exactly happened? When did it start? What did the attacker access? How did they get in? And critically -- can you prove all of this in a way that holds up in court?

When the Attack Is Over, the Investigation Begins

Incident response (episode 51) focuses on containment and recovery -- stopping the bleeding and getting systems back to operational status as fast as possible. The IR team isolates compromised machines, blocks attacker infrastructure, resets credentials, and restores from backups. The goal is speed: minimize damage, minimize downtime, get back to normal. Digital forensics focuses on understanding. A forensic analyst does not care (initially) about getting the system back online. They care about preserving the evidence before it is destroyed, analyzing it methodically, building a complete timeline of attacker activity, and documenting everything with the rigor required for legal proceedings.

Forensics is where the technical meets the legal. A forensic analyst who finds malware on a server but cannot prove the chain of custody for the disk image has evidence that is inadmissible. The analysis is technically correct but legally worthless. The malware was there, the analyst found it, but the court cannot trust the finding because the evidence handling process was flawed. Maybe someone modified the disk between acquisition and analysis. Maybe the image was not a perfect copy. Maybe the analyst worked on the original drive instead of a forensic copy and inadvertently changed file timestamps. Process matters as much as skill -- and that is what makes forensics a distinct discipline from incident response, penetration testing, or threat hunting. You can be technically brilliant and still produce useless results if your methodology is sloppy.

The Forensic Process

1. IDENTIFICATION
   What systems are relevant? What evidence might exist?
   Scope the investigation before touching anything.

2. PRESERVATION
   Create forensic copies (images) of all evidence.
   NEVER analyze the original -- always work on copies.
   Document everything: who, what, when, where, how.

3. COLLECTION
   Acquire evidence in order of volatility:
   1. CPU registers and cache (gone in nanoseconds)
   2. Memory (RAM) -- gone when power is lost
   3. Network connections -- transient
   4. Running processes -- transient
   5. Disk -- persistent but can be overwritten
   6. Removable media -- persistent
   7. Logs on remote servers -- persistent

4. ANALYSIS
   Examine evidence methodically. Build a timeline.
   Correlate across sources. Document every finding.

5. REPORTING
   Document findings in a format suitable for legal proceedings.
   Clear, factual, no speculation. Evidence-supported conclusions.

The order of volatility in step 3 is the single most important concept in forensic collection and the one that gets violated most often by first responders who do not have forensic training. When an incident is discovered, the natural instinct is to "shut it down" -- pull the power cable, turn off the server, stop the bleeding. But the moment you cut power, you lose everything in RAM: running processes, active network connections, encryption keys (including BitLocker keys that will lock you out of the disk forever), and potentially the only copy of the malware that was running in memory without touching disk (so-called fileless malware). Memory is the second most volatile evidence source after CPU registers. If you do not capture it before powering off, it is gone permanently.

This is why the first responder's job is to PRESERVE, not to fix. Before anything else: capture memory (using tools like WinPmem on Windows or LiME on Linux -- we covered acquisition briefly in episode 51). Then capture network state (netstat, packet captures). Then image the disk. Only then can you safely power down the system. The order matters because each step preserves evidence that would be destroyed by the next action. Turning off the machine destroys memory evidence but preserves disk evidence. Leaving the machine running preserves memory evidence but risks the attacker detecting the investigation and wiping their tracks (which is a real risk -- some malware includes anti-forensic routines that detect when memory acquisition tools are loaded). Forensic investigators live in this tension between "capture everything before it disappears" and "don't tip off the attacker."

The reporting step is where many technically skilled analysts fall short. A forensic report is not a technical write-up for your team. It is a legal document that may be read by lawyers, judges, and juries who have no technical background. "The process with PID 4832 loaded a DLL from C:\Users\Public\msupdate.dll which established a TCP connection to 203.0.113.42:443" is technically precise but legally useless without context. The report must explain what a PID is, what a DLL is, why loading one from C:\Users\Public\ is unusual, what a TCP connection is, and why connecting to that specific IP address is significant. This is hard for technical people. We are trained to be precise and concise. Forensic reporting requires precision AND accessibility -- which are different skills entirely.

Disk Forensics

# Step 1: Create a forensic image (bit-for-bit copy)
# ALWAYS use a write blocker for physical drives

# Using dc3dd (forensic dd with hashing)
dc3dd if=/dev/sda of=/evidence/disk.raw hash=sha256 \
    log=/evidence/acquisition.log

# Using FTK Imager (Windows, GUI)
# File > Create Disk Image > Physical Drive > Raw (dd)
# FTK calculates MD5 + SHA1 during acquisition

# Step 2: Verify the image
sha256sum /evidence/disk.raw
# Compare against the hash in acquisition.log
# If they match: the image is a perfect copy. Proceed.
# If they don't: something went wrong. Re-acquire.

# Step 3: Mount the image read-only for analysis
mkdir /mnt/evidence
mount -o ro,loop,noexec /evidence/disk.raw /mnt/evidence

# Step 4: Analyze with Autopsy (open-source forensic platform)
# https://www.autopsy.com/
autopsy
# Create case > Add data source > disk image
# Autopsy automatically:
# - Parses file systems (NTFS, ext4, FAT)
# - Recovers deleted files (from unallocated space)
# - Extracts web browser history, email, documents
# - Identifies known bad files (hash matching against NSRL)
# - Builds timeline of file system activity

The write blocker mentioned in step 1 is a hardware device that sits between the evidence drive and the analysis workstation. It allows read operations but physically prevents write operations -- and "physically" is the key word. A software write blocker (like mounting with -o ro on Linux) can theoretically be bypassed by a kernel bug, a misconfigured mount, or the analyst accidentally remounting read-write. A hardware write blocker provides a guarantee that the evidence drive cannot be modified, period. This matters in court: a defense attorney can argue that a software write-protect might have failed, but they cannot argue that a hardware write blocker allowed writes -- it is physically impossible by design.

The dc3dd tool is the forensic version of the standard Unix dd command. Regular dd copies bytes but does not calculate hashes during the copy. dc3dd calculates a SHA-256 hash as it reads each block, producing both the forensic image and the integrity hash in a single pass. This is important because the hash is what proves the image is a perfect bit-for-bit copy of the original drive. If someone later questions whether the image was modified after acquisition, you can recalculate the SHA-256 hash and compare it against the acquisition log. If the hashes match, the image is identical to the original at the time of acquisition. If they do not match, the image has been tampered with and the evidence is compromised. This is the mathematical foundation of forensic integrity -- a 256-bit hash makes accidental modification detectable and intentional modification computationally infeasible ;-)

Autopsy is the open-source forensic platform that most beginners will use (and many professionals as well -- commercial tools like EnCase and X-Ways cost thousands of dollars per license). Autopsy does an impressive amount of automated analysis: it parses multiple file system types, recovers deleted files from unallocated disk space, extracts web browsing history and email, and cross-references file hashes against the NSRL (National Software Reference Library, a database of known-good software hashes maintained by NIST). The NSRL matching is particularly useful because it lets you quickly filter out known operating system files, common application binaries, and other expected files -- reducing the haystack so you can focus on the needles. A file whose hash does NOT appear in the NSRL is not necessarily malicious, but it is unknown, and unknown files on a compromised system deserve closer inspection.

Recovering Deleted Files

When a file is "deleted," the data is not immediately erased.
The file system marks the space as available but the actual
bytes remain on disk until overwritten by new data.

Forensic tools exploit this:
- Autopsy: "Deleted Files" view shows recoverable files
- Scalpel/PhotoRec: carve files from raw disk based on file headers
  scalpel -b -o /output/ /evidence/disk.raw
  # Recovers JPEGs, PDFs, Office docs, etc. from unallocated space

- Strings extraction: find text in unallocated space
  strings /evidence/disk.raw | grep -i "password\|secret\|key"

What attackers try to do: secure deletion (overwrite with zeros/random)
  shred -vfz -n 5 evidence.txt    # overwrite 5 times + zeros
  But: SSDs with wear leveling may retain old data in spare sectors
  that shred cannot reach. Full disk encryption is the only reliable
  defense against forensic recovery on SSDs.

The gap between what users THINK "delete" means and what actually happens on disk is one of the most consistently exploitable facts in digital forensics. When you right-click a file and press "Delete," the operating system removes the file's entry from the directory listing and marks the disk sectors as available for reuse. The actual data -- every byte of the file's content -- remains on the physical disk until those sectors happen to be allocated to a new file and overwritten. On a traditional spinning hard drive, this can take weeks or months (or never, if the disk has plenty of free space). This is why forensic tools like Scalpel and PhotoRec can carve files from raw disk images by scanning for known file headers (JPEG images start with FF D8 FF, PDF files start with %PDF-, ZIP archives start with PK) -- the file system says nothing is there, but the data is still physically present.

The SSD complication is real and increasingly important. Solid-state drives use wear leveling to distribute writes evenly across all memory cells, which means the SSD controller may move data to a different physical location during normal operation. When shred overwrites a file 5 times, it is writing to the logical sectors -- but the SSD controller may have already moved the original data to spare sectors that are invisible to the operating system. Those spare sectors still contain the old data, and a forensic examiner with direct access to the NAND flash chips (using specialized hardware) can potentially recover it. Full disk encryption (BitLocker, LUKS, FileVault) is the only reliable defense because even if the old data is recoverable from spare sectors, it is encrypted and cannot be read without the key.

Memory Forensics with Volatility

Memory forensics analyzes a snapshot of RAM. Memory contains everything the system was doing at the moment of capture: running processes, open network connections, loaded DLLs, registry hives, encryption keys, clipboard contents, and even plaintext passwords. If disk forensics tells you what the system HAS, memory forensics tells you what the system was DOING -- and that distinction is often the difference between "we found malware on the disk" and "we can prove the malware was actively running and communicating with a command server at 14:32 UTC."

# Acquire memory (see episode 51 for acquisition)
# Linux: LiME module
# Windows: WinPmem, Magnet RAM Capture

# Analyze with Volatility 3
# https://github.com/volatilityfoundation/volatility3

# Identify the OS profile
vol -f memory.raw windows.info

# List all running processes
vol -f memory.raw windows.pslist
# Shows: PID, PPID, name, start time, threads, handles
# Look for: suspicious names, unusual parent-child relationships

# Show process tree (parent-child relationships)
vol -f memory.raw windows.pstree
# Word spawning PowerShell? Outlook spawning cmd? -> malicious

# Find hidden/terminated processes (rootkit detection)
vol -f memory.raw windows.psscan
# psscan finds processes in memory that pslist does not show
# Difference between pslist and psscan = hidden process = rootkit

# Dump a suspicious process's memory
vol -f memory.raw windows.memmap --pid 4832 --dump

# Network connections
vol -f memory.raw windows.netscan
# Shows: all TCP/UDP connections and listening ports
# Look for: connections to unusual external IPs (C2)

# Extract credentials from memory
vol -f memory.raw windows.hashdump
# Dumps SAM hashes (like mimikatz but offline)

# DLL analysis
vol -f memory.raw windows.dlllist --pid 4832
# List DLLs loaded by a specific process
# Look for: DLLs loaded from unusual paths (\Temp\, \AppData\)

# Command line history
vol -f memory.raw windows.cmdline
# Shows the full command line for every process
# Encoded PowerShell commands are visible here

# Registry analysis from memory
vol -f memory.raw windows.registry.hivelist
vol -f memory.raw windows.registry.printkey \
    --key "Software\\Microsoft\\Windows\\CurrentVersion\\Run"

The pstree output is where the real detective work happens. In a healthy Windows system, process parent-child relationships follow predictable patterns: explorer.exe spawns applications the user opens, services.exe spawns system services, svchost.exe instances are children of services.exe. When you see WINWORD.EXE spawning powershell.exe, which spawns cmd.exe, which spawns certutil.exe -- that is a phishing attack in action. The user opened a Word document containing a macro, the macro launched PowerShell, PowerShell ran a command shell, and the command shell used certutil (a legitimate Windows certificate utility) to download a payload. Every step uses a legitimate Windows process, which is why antivirus might miss it -- but the parent-child chain is completely abnormal and immediately visible in the process tree. We used exactly this attack chain in episode 41 with Metasploit.

The psscan vs pslist comparison deserves special attention because it is the definitive rootkit detection technique in memory forensics. windows.pslist walks the operating system's active process list -- the same list that Task Manager shows you. If a rootkit has manipulated this list (a technique called DKOM -- Direct Kernel Object Manipulation) to hide a process, pslist will not show it because the OS itself does not know it exists. windows.psscan, on the other hand, scans raw memory for process structures by looking for their headers (the _EPROCESS structure in Windows) regardless of whether they are linked into the active process list. Any process that psscan finds but pslist does not is either a terminated process whose memory has not yet been overwritten, or a process that has been deliberately hidden -- and the second possibility means you have found a rootkit. Having said that, the absence of hidden processes does not mean the system is clean -- modern rootkits can hide from both techniques by operating entirely within existing legitimate processes (process hollowing, which we covered in episode 63).

The hashdump capability is particularly relevant because it demonstrates that credential extraction is not limited to running Mimikatz on a live system. A forensic analyst with a memory dump can extract password hashes offline, weeks or months after the incident. This has implications in both directions: for the investigator, it means you can determine what credentials the attacker potentially compromised even after the system is wiped and rebuilt. For the defender, it means that any system whose memory was captured while credentials were in use should have ALL those credentials rotated -- because the attacker may also have dumped memory during their time inside the network.

Timeline Analysis

The most powerful forensic technique: reconstruct a unified timeline of ALL system activity.

# Autopsy: Timeline view
# Combines: file system timestamps (MAC times), event logs,
# browser history, registry modifications, and log files
# into a single chronological view.

# Manual timeline with Plaso (log2timeline)
# https://github.com/log2timeline/plaso
log2timeline.py timeline.plaso /evidence/disk.raw
psort.py -o l2tcsv timeline.plaso -w timeline.csv

# The CSV contains every timestamped event on the system:
# - File creation, modification, access times
# - Registry key modifications
# - Event log entries
# - Browser history visits
# - Prefetch file executions
# - $MFT entries (NTFS metadata)

# Filter for the investigation timeframe
grep "2026-05-15" timeline.csv | head -50

# A forensic timeline answers:
# "At 14:32:15, the user opened a phishing email attachment.
#  At 14:32:18, Word spawned PowerShell.
#  At 14:32:19, PowerShell downloaded beacon.exe from C2.
#  At 14:32:22, beacon.exe established a connection to 203.0.113.42.
#  At 14:33:01, the attacker ran whoami.
#  At 14:35:47, the attacker ran mimikatz and dumped credentials.
#  At 14:38:12, the attacker connected to the domain controller
#  using stolen credentials."

Plaso (Python Log2Timeline) is the gold standard for forensic timeline generation because it understands dozens of different timestamp formats from dozens of different sources and normalizes them all into a single chronological view. A single disk image might contain NTFS file system timestamps (in Windows FILETIME format -- 100-nanosecond intervals since January 1, 1601), Windows Event Log timestamps (in XML format), browser history timestamps (Chrome stores timestamps as microseconds since January 1, 1601 -- yes, a different base than NTFS despite both being Windows), and Linux syslog timestamps (in MMM DD HH:MM:SS format with no year). Without a tool that understands all of these formats and normalizes them to a common timeline, cross-source correlation is practically impossible. With Plaso, you get a single CSV where events from every source are sorted chronologically, and you can see that the file was downloaded at 14:32:19 (from the NTFS $MFT entry), the process was created at 14:32:20 (from Sysmon Event 1 in the Windows Event Log), and the network connection was established at 14:32:22 (from Sysmon Event 3). Three different data sources, three different timestamp formats, one coherent story.

The example timeline (from phishing attachment at 14:32:15 to domain controller compromise at 14:38:12) illustrates something that should terrify every defender: six minutes from initial access to domain admin. This is not hypothetical -- it is a realistic timeline for a well-prepared attacker against a poorly segmented network. The forensic timeline proves exactly when each step occurred, which is critical for determining the blast radius of the compromise. Everything the attacker accessed BEFORE 14:38:12 was done with the original user's credentials. Everything AFTER 14:38:12 was done with stolen domain admin credentials -- which means every system in the domain is potentially compromised from that point forward. This timeline is what allows the incident response team to scope the remediation correctly: they do not need to rebuild every machine in the company, only those accessed by the compromised admin credential after the timestamp when it was stolen.

Windows Forensic Artifacts

Artifact               Location                          What it reveals
Prefetch               C:\Windows\Prefetch\              Programs executed + timestamps
Amcache                C:\Windows\appcompat\Programs\    Program execution history + hashes
ShimCache              SYSTEM registry hive              Programs executed (even deleted ones)
UserAssist             NTUSER.DAT registry               GUI programs run by user + count
BAM/DAM                SYSTEM registry hive              Background/Desktop Activity Monitor
Jump Lists             %AppData%\Microsoft\Windows\      Recent files opened per application
                       Recent\AutomaticDestinations\
$MFT                   NTFS Master File Table            Every file ever created (inc. deleted)
$UsnJrnl               NTFS Change Journal               File system change log
Event Logs             C:\Windows\System32\winevt\Logs\  Security, System, Application events
PowerShell History     %AppData%\...\PSReadLine\         Full PowerShell command history
                       ConsoleHost_history.txt
Browser History        %AppData%\Local\Google\Chrome\    URLs, downloads, search queries
RDP Bitmap Cache       %AppData%\Local\Microsoft\        Screenshots of RDP sessions
                       Terminal Server Client\Cache\

Each artifact tells part of the story. The forensic analyst
combines them all into a complete narrative.

The Prefetch directory is one of the most valuable forensic artifacts on Windows because it records evidence of program execution even after the program has been deleted. When Windows runs a program for the first time, it creates a .pf file in C:\Windows\Prefetch\ that contains the program name, the last 8 execution timestamps, the run count, and a list of files the program accessed during its first 10 seconds of execution. An attacker who runs mimikatz.exe, dumps credentials, and then deletes mimikatz.exe from disk has destroyed the binary -- but the Prefetch file MIMIKATZ.EXE-ABCD1234.pf remains, and it proves that mimikatz was executed, when it was executed, and how many times it was run. ShimCache (also called AppCompatCache) provides similar evidence through a completely different mechanism -- it records programs that the Application Compatibility engine evaluated for compatibility shims, which includes every executable that was run or even just accessed by the file system.

The RDP Bitmap Cache is the artifact that forensic analysts love and attackers forget about. When a user connects to a remote machine via Remote Desktop Protocol, the local machine caches bitmap tiles of the remote desktop session to reduce bandwidth usage. These cached tiles persist on disk after the RDP session ends. A forensic examiner can reconstruct partial screenshots of what the attacker saw on remote machines during their RDP sessions -- which can reveal what files they opened, what tools they ran, and what data they accessed. The tiles are not complete screenshots (they are small rectangular fragments), but tools like BMC-Tools can reassemble them into recognizable images. For an investigation where the question is "what did the attacker do on the domain controller?", the RDP bitmap cache on the machine they connected FROM can provide visual evidence of exactly what they saw and did.

The $MFT (Master File Table) and $UsnJrnl (Update Sequence Number Journal) are NTFS metadata structures that record every file system operation. The $MFT is the master index of every file and directory on an NTFS volume -- including entries for files that have been deleted (the MFT entry persists until it is overwritten by a new file's entry). The $UsnJrnl is a change log that records every file creation, modification, deletion, and rename event. Together, these two artifacts can tell you that a file named beacon.exe was created in C:\Temp\ at 14:32:19, renamed to svchost.exe at 14:32:25 (an obvious attempt to disguise it), and deleted at 15:45:03 (cleanup after the attack). The file is gone from disk, but the MFT and journal prove it existed and document its entire lifecycle.

Linux Forensic Artifacts

# Key artifacts on a compromised Linux system:

# Authentication: who logged in, from where, when
/var/log/auth.log          # SSH logins, sudo usage, su
/var/log/secure             # RHEL equivalent
last -f /var/log/wtmp       # login history
lastb -f /var/log/btmp      # failed login attempts

# Command history: what they typed
/home/*/.bash_history       # bash command history
/root/.bash_history         # root command history

# System journal: systemd logs
journalctl --since "2026-05-15" --until "2026-05-16"

# File timestamps: when files were created/modified
find / -newermt "2026-05-15" -not -path "/proc/*" \
    -not -path "/sys/*" -ls

# Cron jobs: persistence mechanisms
/etc/crontab
/etc/cron.d/*
/var/spool/cron/crontabs/*

# Network: what connections existed
/var/log/syslog | grep -i "connect\|listen\|accept"
ss -tlnp                   # current connections (if system is live)

# Package history: what was installed
/var/log/apt/history.log    # Debian/Ubuntu
/var/log/yum.log            # RHEL/CentOS

Linux forensics has fewer artifact types than Windows (no Prefetch, no Amcache, no ShimCache, no registry) but the forementioned artifacts that do exist are often more informative because Linux logs tend to be more verbose and more easily parseable. The auth.log is the single most important artifact on a compromised Linux system because it records every authentication event in plain text: who logged in, from which IP address, at what time, whether they used password or key-based authentication, and every sudo command they ran. An attacker who gains SSH access and escalates to root via sudo leaves a complete trail in auth.log -- assuming the attacker does not delete the log (which is why centralized logging from episode 74 is critical: the SIEM copy of auth.log survives even if the attacker deletes the local copy).

The .bash_history artifact is both incredibly useful and incredibly fragile. Every command typed in a bash shell is recorded in the user's .bash_history file -- including commands the attacker ran to download tools, create backdoors, exfiltrate data, and cover their tracks. The problem is that .bash_history is trivially easy to suppress or destroy. An attacker who runs unset HISTFILE at the start of their session prevents any subsequent commands from being recorded. An attacker who runs history -c && rm ~/.bash_history at the end of their session destroys the existing history. And an attacker who uses sh instead of bash bypasses history recording entirely because /bin/sh does not use the readline history mechanism. For this reason, forensic investigators never rely on bash_history alone -- it is a bonus when it exists, but its absence does not mean nothing happened. The forementioned journalctl output and process accounting logs (if enabled via auditd) provide complementary evidence that is harder for the attacker to suppress.

Chain of Custody

Without chain of custody, evidence is inadmissible.

Chain of custody documentation:

Evidence Item: Dell Optiplex 7090 Desktop, S/N: ABC123DEF456
  Date/Time Acquired: 2026-05-16 14:30 UTC
  Acquired By: Jane Smith, Forensic Analyst, Badge #4472
  Location Acquired: Office 3B, floor 2, building A
  Method: Write-blocked imaging with Tableau T35u
  Image Hash (SHA-256): a4f3e2d1c0b9...
  Stored In: Evidence locker #7, room 101
  Access Log:
    2026-05-16 14:30 - Jane Smith - acquired
    2026-05-16 15:00 - Jane Smith - placed in locker
    2026-05-17 09:00 - Jane Smith - removed for analysis
    2026-05-17 17:00 - Jane Smith - returned to locker

Every person who touches the evidence is documented.
Every movement is logged. The hash proves integrity.
If any link in the chain is broken, a defense lawyer will argue
the evidence was tampered with.

Chain of custody is the concept that most technical people understand in theory but underestimate in practice. In a criminal case, the defense attorney's job is to create reasonable doubt about the prosecution's evidence. If the forensic analyst cannot account for the evidence at every moment from acquisition to courtroom presentation, the defense will argue that someone could have planted evidence, modified files, or contaminated the disk image during the undocumented gap. It does not matter whether tampering actually occurred -- the possibility that it COULD have occurred is sufficient to cast doubt. This is why every transfer, every access, every moment the evidence leaves the analyst's physical control must be documented with timestamps and signatures.

The hash-based integrity verification is the mathematical backbone of the entire chain. At the moment of acquisition, the SHA-256 hash of the disk image is recorded. Every time the evidence is accessed for analysis, the hash is recalculated and compared against the original. If the hashes match, the evidence has not been modified since acquisition -- and this is a mathematical certainty, not an assertion. SHA-256 produces a 256-bit hash with a collision resistance of 2^128 operations. No known technology can produce a different file with the same SHA-256 hash, which means a hash match is proof of integrity that no defense attorney can reasonably challenge. This is the same principle that underlies blockchain transaction verification, digital certificate validation, and software supply chain security (as we covered in episode 45) -- cryptographic hashing provides tamper-evident seals that are computationally unbreakable.

The practical implication for your career is this: if you want to work in forensics, you must be meticulous about documentation. Every tool you run, every setting you configure, every output you record must be logged with timestamps. If you mount a disk image and run a grep command, document the exact command, the exact parameters, and the exact output. If you cannot reproduce your results by following your own documentation, no court will accept your findings. This level of documentation feels excessive when you are doing it, but it is the difference between a forensic investigation that results in a conviction and one that gets thrown out on procedural grounds.

Defense: Forensic Readiness

Prepare BEFORE an incident -- not during:

1. Central log collection (SIEM from episode 74)
   Logs on the compromised machine may be deleted by the attacker.
   Logs forwarded to a central SIEM are safe.

2. Extended log retention
   Keep security logs for 12+ months. Investigations often
   discover breaches that started months ago.

3. Sysmon deployment (episode 72)
   Sysmon logs process creation with command lines and hashes.
   Without Sysmon, Windows process creation events have no
   command line -- drastically reducing forensic value.

4. NTP synchronization
   All systems must use the same time source. Timeline analysis
   fails if clocks are out of sync. Even 5 minutes of drift
   makes event correlation unreliable.

5. Full disk encryption with documented key management
   If a device is stolen, encryption protects the data.
   But the forensic team must have access to decryption keys
   for their OWN investigation.

6. Memory acquisition capability
   Have tools (WinPmem, LiME) pre-deployed or readily available.
   Memory evidence is lost the moment the system is powered off.

Every item in this list connects directly to capabilities we have built throughout the defense arc of this series. Central log collection (episode 74) ensures that forensic evidence survives even when the attacker compromises the source machine and deletes local logs -- a common anti-forensic technique. The attacker can delete /var/log/auth.log on the compromised server, but the copy that was forwarded to your SIEM 3 seconds after each event was generated is intact and tamper-proof. Sysmon deployment (episode 72) is arguably the single highest-value forensic preparation step on Windows because default Windows event logging does NOT record command line arguments for process creation events. Without Sysmon, Event 4688 tells you that powershell.exe was launched -- but not what it did. With Sysmon Event 1, you see the full command line: powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4A... -- and that encoded string is the payload that reveals the entire attack.

NTP synchronization sounds mundane but its absence has derailed more forensic investigations than most people realize. Timeline analysis is the most powerful forensic technique we covered today -- reconstructing a minute-by-minute narrative of attacker activity by correlating events across multiple sources. But if the SIEM server's clock is 3 minutes ahead of the workstation's clock, and the workstation's clock is 7 minutes behind the domain controller's clock, the timeline becomes incoherent. Events that occurred in sequence appear simultaneous or out of order. The download that preceded the execution appears to have happened AFTER the execution. The lateral movement to the domain controller appears to have happened before the credential theft that made it possible. Every system in your environment must synchronize to the same NTP source with sub-second accuracy, or your forensic timeline is unreliable -- and an unreliable timeline is vulnerable to challenge in court.

The memory acquisition capability is the item that requires the most advance preparation because you cannot install acquisition tools AFTER an incident begins without contaminating the evidence. If you discover a compromise and then install WinPmem on the compromised machine, the installation process modifies the file system (creating forensic artifacts that did not exist before your intervention) and loads a kernel driver into memory (which changes the memory state you are trying to capture). The best practice is to have memory acquisition tools pre-deployed on a network share or USB drive that is ready to go at a moment's notice. When an incident is detected, the first responder plugs in the USB, runs the acquisition tool (which runs from the USB, not from the compromised disk), and captures RAM to an external drive. No installation, no modification to the evidence system, no contamination.

The AI Slop Connection

AI is being integrated into forensic analysis at an accelerating pace. AI can parse millions of timeline events and surface anomalies that a human analyst would take weeks to find. AI can classify malware samples by behavioral similarity to known families. AI can reconstruct attack narratives from fragmented evidence across dozens of systems. These are genuine advances -- the scale of modern forensic investigations (terabytes of disk images, billions of log events, hundreds of endpoints) exceeds what any human team can process manually, and AI provides the ability to search that volume at machine speed.

But AI forensic conclusions require human validation, and this is where the legal dimension makes forensics different from threat hunting or incident response. An AI that says "this file is malicious based on behavioral similarity to known ransomware" is providing an assessment, not a forensic finding. In court, the analyst must explain the methodology: what features were extracted, what training data the model was built on, what the false positive rate is, why the model's classification should be trusted in this specific case. "The AI said so" is not expert testimony. The analyst IS the expert, and the AI is a tool the expert used -- no different from Autopsy, Volatility, or Plaso. The forensic community is still working out how to present AI-assisted findings in legal proceedings, and until that framework is established, the safest approach is to use AI for hypothesis generation and candidate identification, but verify every conclusion with traditional forensic methods that can be explained step-by-step to a non-technical audience. Understanding how malware behaves -- statically and dynamically -- is a skill that builds directly on the forensic capabilities we covered today, and it is where the field is heading next.

Exercises

Exercise 1: Create a forensic disk image of a lab VM. Use dc3dd (Linux) or FTK Imager (Windows). Verify the hash. Then open the image in Autopsy. Navigate the file system, recover at least one deleted file, and examine the browser history. Document the entire acquisition process with chain of custody information: evidence item description, acquisition timestamp, method used, hash value, storage location. Save the chain of custody form and your Autopsy findings to ~/lab-notes/disk-forensics.md.

Exercise 2: Capture a memory image of a running Windows VM (use WinPmem or Magnet RAM Capture). Then analyze it with Volatility 3: (a) list running processes (windows.pslist), (b) identify the process tree and flag any unusual parent-child relationships (windows.pstree), (c) compare pslist and psscan output to check for hidden processes, (d) extract network connections (windows.netscan), (e) check command line history (windows.cmdline). Document every finding with timestamps and your interpretation. Save to ~/lab-notes/memory-forensics.md.

Exercise 3: Build a forensic timeline for a simulated incident. On a lab VM: (a) download a file via the browser, (b) execute it, (c) create a scheduled task for persistence, (d) connect to an external IP using netcat or curl. Then image the disk and use Plaso (log2timeline) or Autopsy's timeline feature to reconstruct the events. Verify that your timeline matches the actions you performed -- every action should appear as a timestamped event from at least one evidence source. Document the timeline with evidence source attribution for each event. Save to ~/lab-notes/forensic-timeline.md.

Thanks for reading!

@scipio

stem stemsocial steemstem security programming
0
0
0.000
0 comments