DFIR Bootcamp

Digital forensics is a scientific discipline. Every action you take on evidence must be documented, justified, and reproducible. If you cannot explain exactly what you did, in what order, and why — your findings may be challenged or rejected entirely. Courts, HR investigations, and regulatory bodies all require that evidence collection follows a documented, defensible process.

The cardinal rule is never work on original evidence. Every time you open a file on a live system, the operating system modifies timestamps, writes to cache, and potentially overwrites deleted data that could have been recovered. You must acquire a forensic image first, verify its integrity, and work exclusively on the image.

When a user "deletes" a file, almost nothing is deleted. The operating system simply marks the space as available for reuse and removes the file's directory entry. The data itself remains on disk until it is overwritten by new data — which may never happen. Understanding this at a deep level is what allows forensic analysts to recover evidence that suspects believe they have destroyed.

Windows uses NTFS (New Technology File System) on virtually every modern system. Every file on an NTFS volume is an entry in the Master File Table (MFT). The MFT is a database where each record contains: the filename, file size, timestamps (four of them — Created, Modified, MFT Modified, and Accessed, abbreviated MACB), file attributes, and pointers to the actual data on disk.

When a file is deleted, its MFT entry is marked as available but the data remains. The MFT entry itself may persist for a long time — sometimes forever if no new file takes that exact record number. This means you can recover not just the file content but also its original name, path, and timestamps from the MFT even after the file is "deleted."

The Windows Registry is a hierarchical database that stores configuration for virtually every aspect of Windows — installed software, user preferences, hardware configuration, network settings, and critically for forensics: evidence of user activity, program execution, and attacker persistence. Attackers love the registry because it is invisible to most users and survives reboots.

The registry is split across multiple hive files on disk. Understanding which hive contains which information is fundamental: SYSTEM hive contains hardware, services, and network configuration. SOFTWARE hive contains installed applications and OS settings. NTUSER.DAT (per user) contains user-specific settings and is the richest source of user activity evidence. USRCLASS.DAT (per user) contains shell and COM settings including ShellBags.

One of the most common investigative questions is: "Did this program run on this system?" Proving execution matters in malware investigations (did the ransomware actually execute?), insider threat cases (did the employee run a data-exfiltration tool?), and attribution (did this specific tool, associated with a known threat actor, execute on this system?). Windows maintains multiple independent sources of execution evidence — an attacker would need to clean all of them to cover their tracks.

Prefetch files are Windows' way of speeding up application launches. Windows monitors what a program accesses in its first 10 seconds of execution and caches this information. The Prefetch file persists after the program is deleted. Each prefetch file records the executable name, the full path, a hash of the path (for disambiguation), the last 8 run times, the total run count, and the files and directories accessed during the first 10 seconds.

The key investigative technique is convergence of evidence. If Prefetch shows mimikatz.exe ran at 23:14, AmCache contains its SHA1 hash, ShimCache shows it was on the system since 22:58, and BAM shows it communicated on the network — that is four independent sources all pointing to the same conclusion. An attacker who clears the Security event log has not cleared Prefetch, AmCache, ShimCache, or BAM.

Browser data is often the richest source of evidence in insider threat, fraud, and employee misconduct investigations. Browsers store history, downloads, cached content, saved passwords, autofill data, cookies, and session storage — all in SQLite databases that persist even after the user "clears" their history (the database file remains; the records are just marked as deleted and can be recovered).

Chrome stores its data in %LocalAppData%\Google\Chrome\User Data\Default\. The key files are: History (SQLite — browsing history and downloads), Cookies (SQLite), Login Data (SQLite — saved passwords, AES-256 encrypted with DPAPI), Web Data (SQLite — autofill, credit cards), and Cache\ (cached web content — can contain entire web pages, images, and scripts the user visited).

Event logs are the official record of system activity. They are also the first thing sophisticated attackers attempt to clear or manipulate. Detecting anti-forensic activity — an attacker covering their tracks — is itself critical evidence. Event 1102 (Security log cleared) and Event 104 (System log cleared) are findings that immediately escalate the severity of an investigation.

The modern approach to Windows event log analysis uses Hayabusa (free, open-source) — a Sigma-based event log analysis tool that applies hundreds of detection rules to EVTX files and outputs a timeline of suspicious activity. It does in minutes what manual event log review takes days to accomplish.

Memory forensics begins with acquisition — capturing a complete copy of RAM from a running system. Unlike disk imaging, memory acquisition must be done live (the system must be running to capture RAM). This introduces two challenges: the system is still changing while you image it (some inconsistency is unavoidable), and the acquisition tool itself is running in the memory you are trying to capture.

The standard approach is to use a hardware-based or kernel-driver-based acquisition tool that operates below the level of the operating system's security controls. On Windows, WinPmem (free) and DumpIt (free) are the standard choices. For virtual machines, taking a snapshot is even better — a VMware .vmem file or a Hyper-V saved state contains a perfect copy of RAM at that moment.

Volatility 3 is the tool you will spend most of this phase learning. It analyses memory images by applying "plugins" — each plugin extracts a specific type of information from memory. The key insight: Volatility does not just read data, it understands the operating system data structures in memory. It can reconstruct the list of running processes by following the same doubly-linked list that the Windows kernel uses internally.

Process injection is the technique of running malicious code inside a legitimate process to evade detection. From the operating system's perspective, the code is part of explorer.exe or svchost.exe — trusted, signed, expected. From a memory forensics perspective, the injected code leaves specific indicators that Volatility can detect.

The most common injection techniques you will encounter: Classic DLL Injection (LoadLibrary called from target process, leaves a DLL in dlllist), Reflective DLL Injection (DLL loads itself without Windows loader, appears in malfind as executable memory not backed by a file), Process Hollowing (legitimate process started in suspended state, memory replaced with malicious code — the image on disk does not match the image in memory), and Thread Hijacking (malicious code injected into an existing thread's stack).

Wireshark is not just a tool for reading packets — at the forensic level, it is used to reconstruct complete sessions, extract transferred files, decode encrypted traffic (when keys are available), and build statistical models of traffic that reveal C2 beacon patterns. The difference between a beginner and an expert Wireshark user is not speed — it is knowing which questions to ask and how to filter for the answers.

The most powerful forensic feature of Wireshark is file carving from PCAP. Any file transferred over HTTP, SMB, FTP, or SMTP can be extracted directly from the packet capture as a complete file, ready for analysis. This includes malware dropped via drive-by downloads, data exfiltrated via HTTP POST, and documents sent as email attachments.

Wireshark works on individual packet captures. Zeek (formerly Bro) works on live network traffic or stored PCAPs and produces structured log files — one log per protocol — that are infinitely easier to search and correlate than raw packets. Zeek is deployed at enterprise scale to provide retrospective network forensics capability: when an incident is detected, you can query Zeek logs to see all network activity from the past 30 days.

Zeek generates: conn.log (every connection), dns.log (every DNS query and response), http.log (every HTTP request with URL, method, user-agent, response code, and file hash), ssl.log (TLS connection metadata including JA3 fingerprints), files.log (every file transferred with MD5/SHA1 hash — without even extracting the file), and weird.log (protocol violations and anomalies).

Ransomware is the incident type you are most likely to work as a first responder. The playbook for ransomware IR is well-established but demands discipline under intense pressure — executives demanding answers, operations halted, and potentially a clock ticking on a ransom deadline. Your forensic work during a ransomware incident serves multiple purposes simultaneously: containment, root cause analysis, recovery prioritisation, and regulatory reporting.

The first 30 minutes of a ransomware response are the most critical. Every minute the ransomware continues to run, more files are encrypted and more evidence is potentially destroyed. But rushing into isolation without understanding the scope can leave encrypted shares still mounting, or trigger tripwires the attacker has set to detonate additional payloads.

Containment is not remediation. Once you have stopped the immediate bleeding, the hardest part begins: ensuring the attacker is completely evicted. Sophisticated attackers establish multiple persistence mechanisms specifically to survive partial remediation — rebuilding one compromised server while leaving the attacker's foothold on the domain controller means they are back inside within hours.

Complete eviction requires a forensically-grounded understanding of every persistence mechanism the attacker established, every credential they compromised, and every system they touched. The forensic evidence you collected during the investigation now drives the remediation checklist. Do not guess — prove each persistence point from evidence before claiming it is removed.

Cloud forensics is fundamentally different from traditional forensics in four ways: you often cannot image the disk directly (the hypervisor is managed by the cloud provider), evidence may be in regions you did not know about, the attack surface includes cloud-native services (S3 buckets, Lambda functions, IAM roles) that have no on-premise equivalent, and your primary evidence source is cloud-native logging (CloudTrail, Azure Activity Log, GCP Cloud Audit Log) rather than endpoint logs.

The first step in any cloud forensic investigation is preserving the logging — attackers often attempt to disable logging to cover their tracks. Check that CloudTrail is enabled in all regions (attackers frequently operate in regions where logging is not configured). Enable GuardDuty and Security Hub findings as evidence sources if not already active.

As a DFIR analyst you will regularly encounter malware samples — from evidence preservation during IR, from endpoint detection tools, or from threat intelligence feeds. You do not need to be a full reverse engineer, but you need to be able to quickly triage a sample: is this known malware? What family? What does it do? What IOCs does it produce? This is malware triage — getting answers in 15 minutes, not 15 hours.

Static analysis examines the file without executing it. Dynamic analysis executes the file in a controlled environment and observes its behaviour. Do static analysis first — if the file is a known sample identified by hash or a clear packer signature, dynamic analysis may be unnecessary. If static analysis is inconclusive, move to dynamic.