Forensics Fundamentals

Digital forensics is the discipline of collecting, preserving, and analyzing evidence from compromised systems -- done correctly, it reveals the full attack narrative; done poorly, it destroys the evidence needed to understand what happened and prevent recurrence

When to Use

• A security incident has occurred and evidence must be collected from compromised systems
• Building forensic readiness capabilities before an incident occurs
• Analyzing logs across multiple systems to reconstruct an attack timeline
• Determining the scope of a breach -- what the attacker accessed, modified, or exfiltrated
• Collecting evidence that may be needed for legal proceedings or regulatory reporting
• Evaluating indicators of compromise (IOCs) shared by threat intelligence sources

Threat Context

Forensic capability determines whether an organization can answer the four critical questions after a breach: How did the attacker get in? What did they access? Are they still in the environment? How do we prevent this from happening again? Without forensic evidence, these questions remain unanswered:

• Sony Pictures (2014): The attackers (attributed to North Korea) wiped hard drives and deleted logs to cover their tracks. Forensic investigators had to reconstruct the attack from network device logs, email server backups, and fragments recovered from partially wiped drives. The investigation took months because primary evidence had been destroyed. Organizations with centralized, immutable logging would have preserved critical evidence regardless of the attacker's wiper activity.
• SolarWinds SUNBURST (2020): Forensic analysis of the SUNBURST backdoor required reverse engineering the malware, correlating DNS logs (the backdoor used DNS for C2 beaconing), analyzing Active Directory logs for lateral movement, and examining email server access logs. The forensic complexity was extreme because the malware was specifically designed to evade detection -- it delayed execution for 12-14 days, checked for analysis tools, and mimicked legitimate Orion API traffic.
• Capital One (2019): Forensic investigation revealed that a misconfigured WAF allowed the attacker to execute server-side request forgery (SSRF) against the EC2 metadata service, obtaining IAM role credentials. CloudTrail logs showed the attacker using those credentials to list and download S3 buckets containing 106 million customer records. The forensic trail was clear because AWS CloudTrail was enabled -- without it, the scope of the breach would have been unknown.
• Norsk Hydro (2019): LockerGoga ransomware encrypted systems across 40 countries. Forensic analysis of the unencrypted backup systems and network logs revealed the initial access vector (a phishing email three months earlier), the lateral movement path (through Active Directory), and the attacker's dwell time. This forensic reconstruction informed the rebuild strategy and identified security gaps.

Instructions

1. Understand evidence types and the order of volatility. Evidence exists on a spectrum from highly volatile (lost in seconds) to persistent (survives power loss). Collect the most volatile evidence first:

   • CPU registers and cache (nanoseconds): Practically uncollectable in post-incident forensics. Relevant only in live debugging or hardware-level analysis.
   • Memory (RAM) (lost on power off): Contains running processes, network connections, decrypted data, encryption keys, injected code, and attacker tools that never touch disk. Capture with LiME (Linux Memory Extractor), WinPMEM (Windows), or cloud-native memory acquisition (AWS EC2 memory dump via hibernation, Azure VM memory capture).
   • Network state (changes continuously): Active connections (

     netstat

     /

     ss

     ), routing tables, ARP cache, DNS cache. Capture before any network isolation actions.
   • Running processes (changes continuously): Process list with full command lines, open file handles, loaded libraries, network sockets per process. On Linux:

     /proc

     filesystem provides rich per-process data. Capture before any containment actions.
   • Disk (persists across power cycles): File system contents, deleted files (recoverable until overwritten), file timestamps (created, modified, accessed), swap space, page files, hibernation files. Image with

     dd

     ,

     dc3dd

     , or FTK Imager. Use write-blockers to prevent modification during imaging.
   • Logs (persists but may rotate): Application logs, system logs, authentication logs, firewall logs, proxy logs, DNS query logs. Export and hash immediately. Remote/centralized logs are more trustworthy than local logs on the compromised system.
   • Configuration (persists): System configuration, application configuration, cron jobs, scheduled tasks, startup scripts, user accounts. Compare against known-good baselines to identify attacker modifications.

2. Collect evidence without modifying it. The forensic principle of non-contamination requires that evidence collection does not alter the evidence:

   • Disk imaging: Use a hardware write-blocker between the source disk and the forensic workstation. This physically prevents writes to the source. Create a bit-for-bit image using

     dd if=/dev/sda of=/evidence/image.raw bs=4k conv=noerror,sync

     or

     dc3dd

     (which adds hashing during imaging). Compute SHA-256 hashes of both the source and the image to verify integrity.
   • Memory acquisition: Memory acquisition tools (LiME, WinPMEM) necessarily modify a small amount of memory when they load. This is accepted and documented. Run the tool from external media (USB drive) to minimize footprint on the target system.
   • Log collection: Copy logs to a separate system; do not analyze on the compromised host. Hash each log file after export. If the attacker had root access, local logs may have been tampered with -- cross-reference with centralized logging infrastructure.
   • Cloud environments: Use cloud provider APIs for evidence collection. AWS: create EBS snapshots, export CloudTrail logs, capture VPC Flow Logs. Azure: create disk snapshots, export Activity Logs, capture NSG Flow Logs. GCP: create disk snapshots, export Cloud Audit Logs, capture VPC Flow Logs. These API-based methods are non-destructive.

3. Maintain chain of custody. For evidence to be admissible in legal proceedings and credible in regulatory investigations, every transfer of evidence must be documented:

   • Record who collected the evidence, when (timestamp), from what system (hostname, IP, serial number), using what tool and method.
   • Record every person who accessed the evidence, when, and for what purpose.
   • Store evidence on encrypted, access-controlled media with tamper-evident seals for physical storage.
   • Compute and record cryptographic hashes (SHA-256) at collection time and verify them before every analysis session.
   • Use a chain of custody form (physical or digital) with fields for: evidence ID, description, date/time collected, collected by, hash value, storage location, and a transfer log (date, from, to, purpose).

4. Reconstruct the attack timeline. The timeline is the primary forensic deliverable -- a chronological narrative of the attacker's actions:

   • Normalize timestamps: Convert all log sources to UTC. Clock skew between systems causes events to appear out of order. Verify NTP configuration on all systems and note any clock drift observed during collection.
   • Correlate across sources: An authentication log shows a login at 14:32 UTC. The web server log shows the same user accessing /admin at 14:33. The database audit log shows a bulk export at 14:35. The firewall log shows an outbound connection to an external IP at 14:37. Each source provides a partial view; correlation reveals the full narrative.
   • Identify key events: Initial compromise (how the attacker got in), persistence establishment (how they ensured continued access), privilege escalation (how they gained higher privileges), lateral movement (how they moved to other systems), data access (what they viewed or copied), data exfiltration (how they removed data from the environment).
   • Fill gaps: Missing evidence does not mean nothing happened. If the attacker had access to a system with no logging, assume the worst case for scope assessment and note the evidence gap in the timeline.

5. Identify and document indicators of compromise (IOCs). IOCs are observable artifacts that indicate a system has been compromised:

   • Network IOCs: IP addresses, domain names, URLs used for command-and-control, data exfiltration, or malware delivery. Include port numbers and protocols.
   • Host IOCs: File hashes (MD5, SHA-1, SHA-256) of malware, backdoors, or attacker tools. File paths where malware was installed. Registry keys modified (Windows). Cron jobs or systemd units added (Linux). User accounts created by the attacker.
   • Behavioral IOCs: Unusual process execution patterns, anomalous network traffic volumes, off-hours access, access to sensitive resources by accounts that do not normally access them.
   • Share IOCs: Use STIX (Structured Threat Information Expression) format for machine- readable IOC sharing. Share with ISACs (Information Sharing and Analysis Centers), peer organizations, and threat intelligence platforms via TAXII (Trusted Automated Exchange of Intelligence Information) feeds. Sharing IOCs helps other organizations detect the same attacker.

Details

• Memory forensics -- what lives only in RAM: Memory contains information that never touches disk and is lost forever on power off: in-progress network connections and their contents (pre-encryption for TLS sessions), decrypted versions of encrypted data, encryption keys for full-disk encryption (BitLocker, LUKS) that could unlock the disk image, injected code that was loaded directly into process memory without writing to disk (fileless malware), clipboard contents, command history in running shells, and credentials cached by the operating system (LSASS on Windows, which stores NTLM hashes, Kerberos tickets, and plaintext passwords in some configurations). Tools like Volatility Framework analyze memory dumps to extract this information.

• Log analysis patterns for common attack types: Brute force: many failed logins followed by a success from the same source. Credential stuffing: failed logins across many accounts from a distributed set of IPs. Privilege escalation: a normal user account suddenly accesses admin endpoints. Data exfiltration: unusually large responses to API calls, bulk download patterns, or connections to unfamiliar external IP addresses. Lateral movement: a compromised server making authentication requests to other internal servers using credentials it should not possess. Web shell: a web server process spawning command-line processes (e.g., Apache httpd spawning

  /bin/sh

  ).

• Cloud forensics differences: In cloud environments, you typically cannot access the physical hardware or hypervisor layer. Evidence collection relies on provider APIs. Advantages: disk snapshots are instantaneous and non-destructive, cloud audit logs (CloudTrail, Activity Log, Cloud Audit Logs) cannot be deleted by the attacker if properly configured (send to a separate account/project with restricted access). Challenges: memory acquisition may not be possible for all instance types, network captures require prior VPC Flow Log enablement, ephemeral instances (serverless, containers) may leave minimal forensic artifacts.

Anti-Patterns

1. Modifying evidence during collection. Running analysis tools on the compromised system, which modifies file access timestamps, loads libraries into memory, and creates temporary files. Use a forensic workstation for analysis, not the compromised host. If live collection is necessary (memory dump), document the tool's footprint and accept the minimal contamination.

2. Analyzing on the live compromised system. Installing and running forensic tools directly on the compromised host. The attacker may have installed rootkits that hide processes, files, and network connections from the operating system. Analysis on the live system sees what the rootkit allows. Analysis of a disk image on a clean forensic workstation reveals the rootkit itself.

3. Incomplete timeline with unexplained gaps. Building a timeline that shows the initial compromise and the data exfiltration but skips the intermediate steps. The gaps likely contain lateral movement and persistence mechanisms. If the attacker established persistence that the timeline does not account for, remediation will be incomplete and the attacker will regain access.

4. No chain of custody documentation. Collecting evidence but not recording who collected it, when, and how it was stored and accessed. If the incident leads to legal action (lawsuit, criminal prosecution, regulatory enforcement), evidence without chain of custody may be inadmissible. Even for internal investigations, undocumented evidence handling undermines the credibility of the findings.

5. Collecting only one type of evidence. Gathering disk images but not memory. Exporting application logs but not network logs. Each evidence type reveals different aspects of the attack. Memory shows the attacker's active tools. Disk shows persistence mechanisms. Logs show the timeline. Network captures show data exfiltration. A comprehensive investigation requires multiple evidence types correlated together.