Incident Response & Digital Forensics

NIST SP 800-61 defines 4 phases:

1. PREPARATION
   - IR policy, procedures, playbooks
   - Trained IR team (CSIRT)
   - Monitoring tools: SIEM, EDR, NDR
   - Incident classification criteria
   - Legal retainer (for attorney-client privilege)
   - Communication plan

2. DETECTION & ANALYSIS
   - Indicators of Compromise (IoCs)
   - Alert triage (true positive vs false positive)
   - Scope assessment: how widespread?
   - Evidence collection and preservation
   - Incident severity classification
   - Notification (legal, regulatory, management)

3. CONTAINMENT, ERADICATION & RECOVERY
   Short-term: isolate infected systems (network block, VLAN)
   Long-term: patch, reimage, rotate credentials
   Eradication: remove malware, backdoors, persistence
   Recovery: restore from clean backups, validate
   Monitoring: watch for re-infection

4. POST-INCIDENT ACTIVITY
   - Lessons learned meeting (within 2 weeks)
   - Root cause analysis (RCA)
   - Process improvements
   - Update playbooks
   - Regulatory reporting (GDPR: 72hr, HIPAA: 60 days)

RFC 3227: "Guidelines for Evidence Collection and Archiving"

Collect most volatile first:
1. CPU registers, cache (microseconds)
2. RAM contents (minutes to hours)
3. Network connections, routing table, ARP cache (minutes)
4. Running processes (minutes)
5. Disk contents (hours to days)
6. Backup media (days to weeks)
7. Printed documents (days to weeks)

Rule: collect before changes occur, even at expense of thoroughness

# dd — bit-for-bit copy with verification
sudo dd if=/dev/sda of=/evidence/disk.img bs=4M conv=noerror,sync
# if=input (source disk), of=output, bs=block size
# conv=noerror: continue on errors; sync: fill error blocks with zeros

# Better: dcfldd (with hashing):
dcfldd if=/dev/sda of=disk.img hash=sha256 hashlog=disk.sha256

# Verify integrity:
sha256sum disk.img > disk.img.sha256
sha256sum -c disk.img.sha256

# FTK Imager (Windows, GUI):
# - Case-preserving format: .E01 (Expert Witness Format)
# - Includes metadata: case number, examiner, date, hash
# - Splits large images into manageable chunks

# Create E01 with FTK Imager CLI:
ftkimager /dev/sda /evidence/disk.E01 --e01 --compress 0

# Mount read-only for analysis:
sudo mount -o ro,noexec,noatime /evidence/disk.img /mnt/evidence
# ALWAYS mount read-only — never modify evidence!

Chain of Custody: documented record of who handled evidence and when

Documentation required:
- Who collected the evidence (name, title)
- When collected (date, time)
- Where collected (physical location, system info)
- How collected (tool used, command run)
- Hash verification before and after
- Storage location, access log

Without proper chain of custody:
- Evidence may be inadmissible in court
- Defense can argue tampering
- Investigation conclusions challenged

Template:
Date/Time: 2024-03-15 14:30:00 UTC
Collected by: Jane Smith, Senior Forensics Analyst
System: Corp-PC-127 (192.168.1.127, Windows 10)
Evidence: RAM dump (memory.raw, 16GB)
Hash: SHA256 = 3b4c5d...
Storage: Evidence server /case/2024-03-15/
Access log: stored in chain_of_custody.pdf

# Key Windows Event Log files:
# C:\Windows\System32\winevt\Logs# - Security.evtx      (logon/logoff, object access, privilege use)
# - System.evtx        (OS events, service changes)
# - Application.evtx   (app errors, service messages)
# - Microsoft-Windows-Sysmon%4Operational.evtx  (if Sysmon installed)
# - Microsoft-Windows-PowerShell%4Operational.evtx

# Critical Event IDs:
# 4624 — Successful logon
# 4625 — Failed logon
# 4648 — Logon with explicit credentials (runas)
# 4688 — Process creation (with command line if policy set)
# 4720 — User account created
# 4732 — Member added to security-enabled local group
# 4768 — Kerberos TGT requested
# 4769 — Kerberos TGS requested (Kerberoasting indicator)
# 7045 — Service installed (malware persistence)
# 1102 — Audit log cleared (attacker covering tracks)

# Parse with python-evtx:
python3 -c "
import Evtx.Evtx as evtx
import Evtx.Views as e_views
with evtx.Evtx('Security.evtx') as log:
    for record in log.records():
        print(record.xml())
" | grep '4624'

# Or use Log Parser (Windows):
LogParser -i:EVT "SELECT TimeGenerated, Message FROM Security WHERE EventID=4624"

# MFT: NTFS index of every file and metadata (including deleted!)
# Located at $MFT in root of NTFS volume

# Extract MFT from image:
# Via FTK Imager: Add Evidence -> Find $MFT -> Export

# Parse with analyzeMFT:
pip3 install analyzeMFT
analyzeMFT.py -f mft.raw -o mft.csv --csv

# Key info in MFT records:
# File name, size, created/modified/accessed/changed (MACE) timestamps
# Even after file deletion: MFT record marked as free but data often recoverable

# MFT analysis shows:
# - When malware was created/modified
# - Timestomping (attacker changed timestamps — all 4 same = suspicious)
# - Files created by attacker tools
# - Lateral movement (files copied from other systems)

# Prefetch: Windows caches startup info for frequently run programs
# C:\Windows\Prefetch\*.pf
# Contains: executable name, run count, last 8 run times, files accessed

# Parse with PECmd (Eric Zimmerman tool):
PECmd.exe -d C:\Windows\Prefetch --csv C:\output.csv

# What it tells us:
# - MALWARE.EXE-ABC12345.pf → malware was EXECUTED on this system!
# - Run count and last run times
# - Files accessed during execution (shows what malware opened)
# Even if malware deleted itself, Prefetch may remain

# Shimcache: registry artifact tracking execution of programs
# HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache

# Amcache: more detailed, stored in C:\Windows\AppCompat\Programs\Amcache.hve
# Contains: full path, SHA1 hash, compile time, first seen time

# Parse with AppCompatCacheParser.exe (Eric Zimmerman):
AppCompatCacheParser.exe -f SYSTEM --csv C:\output.csv

# This reveals programs executed even if:
# - The program was deleted
# - Prefetch is disabled
# - Event logs were cleared

# Plaso (log2timeline) — creates super-timeline from multiple sources
# Collects: event logs, prefetch, MFT, registry, browser history, etc.

# Install:
pip3 install plaso

# Create timeline from disk image:
log2timeline.py --storage-file timeline.plaso disk.img

# Filter and export:
psort.py -o dynamic -w output.csv timeline.plaso

# Query timeline:
pinfo.py timeline.plaso    # info about sources
psort.py timeline.plaso "date > '2024-03-14 00:00:00' AND date < '2024-03-16 00:00:00'"

# Visualize in TimeSketch (web-based):
timesketch_import timeline.plaso

Autopsy: open-source digital forensics platform (GUI)
- Disk image analysis
- File recovery
- Timeline
- Keyword search
- Hash database (known-good/known-bad)
- Registry analysis
- Web browser history

Usage:
1. Create new case
2. Add data source (disk image, local disk, memory)
3. Run ingest modules (hash lookup, keyword search, etc.)
4. Analyze: Timeline, File Types, Deleted Files, etc.

Key features:
- Recover deleted files from unallocated space
- Match against known hash database (NSRL — known-good, whitelist)
- Timeline view: visual of file system activity
- Module: PhotoRec for file carving