Digital forensics & incident response

Everything so far in this course has largely been offensive — finding and exploiting weaknesses. DFIR flips the perspective: when a real incident happens, how do you figure out exactly what occurred, contain it, and recover — while preserving evidence properly enough to support legal or insurance action if needed?

What DFIR actually covers

DFIR combines two closely related disciplines:

• Digital Forensics — the rigorous, evidence-preserving process of examining digital systems to reconstruct what happened.
• Incident Response (IR) — the operational process of detecting, containing, eradicating, and recovering from a security incident.

This six-phase model (based on NIST's incident response framework) is the DFIR analogue of Path 14's five-phase penetration testing methodology — a repeatable, professional structure rather than ad-hoc firefighting.

Phase 1: Preparation

Everything done before an incident occurs to make response actually possible:

• Logging properly configured and centralised (recall Path 12.5's SIEM concepts) — you cannot investigate what wasn't logged.
• An incident response plan, with clear roles and escalation paths, documented and rehearsed before a real crisis.
• Baseline system images/configurations documented, so "what's different from normal" can actually be determined.

Phase 2: Detection & Analysis

Recognising that an incident is actually occurring — often via the SIEM alerts and correlation rules from Path 12.5, or an external notification (a customer report, a law enforcement tip, a bug bounty report per Path 15 revealing active exploitation).

The forensic principle: preserve, then analyse — never the reverse

Never analyse original evidence directly — always work from a verified forensic copy, preserving the original completely untouched. Investigating directly on a live, compromised system risks altering timestamps, overwriting deleted-but-recoverable data, or destroying evidence needed for legal proceedings.

# Creating a forensic disk image with proper integrity verification:
dd if=/dev/sdb of=evidence-image.dd bs=4M status=progress
sha256sum /dev/sdb > original-hash.txt
sha256sum evidence-image.dd > image-hash.txt
# Compare — they MUST match, proving the image is a perfect, unaltered copy

This hash-verification step directly echoes Path 03.6's file integrity lesson — here applied with legal, evidentiary weight. A mismatched hash means the image cannot be trusted as an accurate representation of the original evidence.

Chain of custody

For any incident with potential legal consequences, a documented chain of custody records exactly who handled evidence, when, and what was done to it at every step — essential for evidence to remain admissible if a case ever goes to court, and generally good practice even when litigation isn't anticipated.

Memory forensics

Live system memory (RAM) contains enormously valuable, entirely volatile evidence — running processes, network connections, encryption keys, and malware that may never touch disk at all (recall Path 10.4's "fileless malware" concept):

# Capturing memory for later analysis (must happen BEFORE shutting down
# a potentially-compromised system, since RAM contents are lost on power-off):
# Using tools like FTK Imager, WinPMEM, or LiME (Linux Memory Extractor)

# Analysing a memory capture with Volatility (the standard memory forensics framework):
volatility3 -f memory-dump.raw windows.pslist
volatility3 -f memory-dump.raw windows.netscan

Volatility lets you reconstruct running processes, network connections, and even extract injected malicious code directly from a memory image — often revealing far more than disk-based analysis alone, especially against sophisticated, memory-resident threats.

Timeline analysis

Reconstructing exactly what happened, in order, across the incident:

# log2timeline/plaso — builds a unified, chronological timeline from
# many different log sources and filesystem metadata simultaneously:
log2timeline.py timeline.plaso /path/to/evidence-image.dd
psort.py -o l2tcsv -w timeline.csv timeline.plaso

A properly-built timeline directly answers the questions every stakeholder asks first: when did the attacker first gain access? What did they do, and in what order? When were they finally contained? — precisely mapping onto the kill chain concept from Path 10.3, now reconstructed from real evidence rather than theorised in the abstract.

Sysmon — Windows endpoint logging that actually helps

Default Windows event logging is notoriously thin for real investigative work — Sysmon (System Monitor), a free Sysinternals tool, fills that gap by logging far richer, forensically useful detail: every process creation with its full command line and parent process, every network connection, every file creation of interest, and every registry modification, all with configurable filtering to keep log volume manageable:

<!-- A minimal Sysmon config snippet logging process creation with command lines -->
<Sysmon schemaversion="4.90">
  <EventFiltering>
    <ProcessCreate onmatch="exclude">
      <Image condition="end with">svchost.exe</Image>
    </ProcessCreate>
  </EventFiltering>
</Sysmon>

Once deployed, Sysmon events (visible in Windows Event Viewer or, far more usefully, shipped to a SIEM per Path 12.5) let an investigator answer exactly the kind of question a timeline reconstruction needs: which process spawned powershell.exe with a suspicious base64-encoded argument, and what did that process do next. This is precisely the kind of preparation-phase investment — deploying rich logging before an incident, not scrambling to enable it during one — that separates organisations who can actually investigate an incident from those left guessing.

Phase 3: Containment

Stopping the incident from causing further damage, while preserving evidence wherever possible:

• Short-term containment — immediate isolation (network segmentation, Path 12.1's concept, applied urgently) to stop active damage without necessarily destroying evidence.
• Long-term containment — more thorough measures (rebuilding affected systems from clean images, rotating all potentially-compromised credentials) while a permanent fix is prepared.

For AD-specific incidents (Path 16.3), this is exactly where the KRBTGT password rotation (twice) becomes critical — without it, an attacker who's forged a Golden Ticket retains persistent access even after every other containment step.

Phase 4: Eradication

Completely removing the attacker's presence — every backdoor, every persistence mechanism (recall Path 14.6's persistence concept, now from the defender's side), every malicious account created.

Phase 5: Recovery

Restoring systems to normal operation, ideally from known-clean backups (Path 10.7's 3-2-1 backup rule proving its full value here), with enhanced monitoring during the recovery period specifically watching for any signs the attacker retained access despite eradication efforts.

Phase 6: Lessons Learned

A genuinely critical, often-skipped final phase: a blameless post-incident review answering:

• How did the attacker actually get in? (Root cause, not just symptoms.)
• What detection gaps allowed this to go unnoticed for as long as it did?
• What specific, concrete changes will prevent a recurrence?

This feeds directly back into Phase 1's preparation for the next incident — DFIR is a continuous cycle, not a one-time linear process.

Building your own DFIR practice environment

# SANS SIFT Workstation — a free, pre-configured Linux distribution
# with the full standard DFIR toolkit already installed:
# (Volatility, log2timeline/plaso, Autopsy, and more)

# Autopsy — a free, GUI-based digital forensics platform, good starting
# point for disk image analysis specifically:
autopsy

🧪 Lab — A mini incident timeline exercise

Using your Kali VM (treating it as a hypothetical "compromised" system from your earlier Path 14/11 labs):

1. Review your own bash history, auth logs, and any files created during previous labs in this course:

cat ~/.bash_history
sudo cat /var/log/auth.log 2>/dev/null || sudo journalctl -u ssh
find / -newer /etc/hostname -type f 2>/dev/null | head -50

1. Attempt to reconstruct a rough timeline: when did you first gain a foothold in your Metasploitable labs (Path 14.5)? What commands did you run afterward, in what order?
2. Write a short "incident summary" as if this were a genuine investigation — what happened, when, and what containment/eradication steps would you recommend if this had been a real, unauthorized compromise.

This exercise — looking at your own prior lab activity through a forensic investigator's lens — is a genuinely effective way to internalise how much (or how little) evidence ordinary system usage leaves behind, directly informing both your offensive OPSEC awareness and your defensive logging priorities going forward.

Why must a forensic investigator always work from a verified disk image copy rather than analysing the original, potentially-compromised system directly?

Key terms

• DFIR — Digital Forensics and Incident Response, combining evidence-preservation with operational incident handling.
• Chain of custody — documented record of who handled evidence and when, essential for legal admissibility.
• Memory forensics / Volatility — analysing volatile RAM contents, revealing evidence that never touches disk.
• Timeline analysis / log2timeline — reconstructing chronological incident events from multiple log sources.
• IOC (Indicator of Compromise) — revisited from Path 16.6, the artifacts extracted during DFIR feeding detection efforts elsewhere.

Recap

• DFIR's six-phase model (preparation through lessons learned) mirrors Path 14's methodology, applied to defensive incident handling.
• The cardinal forensic principle: always work from a verified, hash-matched copy, never the original evidence directly.
• Memory forensics (Volatility) reveals volatile evidence, especially critical against fileless/memory-resident threats.
• Containment must balance stopping active damage against preserving evidence for later analysis.
• The lessons-learned phase closes the loop, feeding directly back into improved preparation for future incidents.

References

• NIST SP 800-61 — Computer Security Incident Handling Guide — the official US six-phase framework referenced throughout this lesson.
• Volatility Foundation — the standard memory forensics framework.
• SANS SIFT Workstation — a free, pre-configured DFIR toolkit distribution.
• Autopsy — free, GUI-based digital forensics platform.

Next up → Threat hunting fundamentals