Skip to content
Unverified — AI-generated content. Help verify this page

Incident Response & Digital Forensics

When prevention fails — and it will — incident response determines whether a security event becomes a minor disruption or a catastrophic breach. Digital forensics provides the investigative methodology to understand what happened, how it happened, and what was affected. Together, IR and DFIR (Digital Forensics and Incident Response) form the backbone of an organization's ability to survive a cyberattack.

Related: Cybersecurity Overview | Linux Security | Reverse Engineering | DevOps Incident Response


The Incident Response Process

The NIST SP 800-61 framework defines six phases. Each phase has specific objectives, deliverables, and common mistakes.

Phase Details

PhaseObjectiveKey ActivitiesCommon Mistakes
1. PreparationBe ready before incidents happenIR plan, tools, training, contacts, playbooksNo plan exists; tools not tested
2. IdentificationDetect and confirm the incidentAlert triage, log analysis, scope assessmentIgnoring alerts, slow escalation
3. ContainmentLimit blast radiusNetwork isolation, credential reset, short-term fixesWiping evidence, alerting attacker
4. EradicationRemove attacker accessMalware removal, patch vulnerabilities, close backdoorsMissing persistence mechanisms
5. RecoveryRestore normal operationsRebuild systems, restore from clean backups, monitorRestoring from compromised backups
6. Lessons LearnedImprove for next timePost-incident review, update playbooks, address root causeSkipping this phase entirely

Phase 1: Preparation

markdown
# IR Preparation Checklist

## People
- [ ] Incident Response team defined with roles and contact info
- [ ] Escalation paths documented (L1 → L2 → L3 → CISO → Legal → PR)
- [ ] External contacts ready: legal counsel, law enforcement, IR retainer firm
- [ ] Regular tabletop exercises (quarterly minimum)

## Process
- [ ] IR plan documented, approved, distributed
- [ ] Playbooks for common scenarios (ransomware, data breach, insider threat)
- [ ] Communication templates (internal, customer, regulatory)
- [ ] Evidence handling procedures (chain of custody)

## Technology
- [ ] SIEM deployed and tuned (Splunk, ELK, or similar)
- [ ] EDR on all endpoints (CrowdStrike, SentinelOne, Defender)
- [ ] Network monitoring (Zeek, Suricata, full packet capture)
- [ ] Forensic toolkit ready (write-blockers, forensic workstation, tools)
- [ ] Backup and recovery tested (not just "we have backups")

Phase 2: Identification

Phase 3: Containment

Do Not Tip Off the Attacker

During containment, avoid actions that alert the attacker to your awareness. Do not immediately change passwords, disable accounts, or block IPs unless the attacker is actively exfiltrating data. Premature containment can cause the attacker to destroy evidence, deploy ransomware, or activate backup access.

bash
# Short-term containment
# Isolate affected system from network (not power off — preserve memory!)
# On Linux:
iptables -A INPUT -j DROP
iptables -A OUTPUT -j DROP
# Or disconnect network cable while keeping power on

# On network equipment:
# Move affected VLAN to quarantine
# Block attacker IPs at firewall

# Take memory snapshot BEFORE any other changes
# See Memory Forensics section below

# Long-term containment
# Rebuild systems from clean images
# Reset ALL credentials (assume they are compromised)
# Revoke and reissue certificates
# Enable enhanced logging and monitoring

Memory Forensics with Volatility

Memory forensics captures and analyzes the contents of RAM. It reveals running processes, network connections, loaded malware, encryption keys, and artifacts that disappear when a system is powered off.

Memory Acquisition

bash
# Linux — use LiME (Linux Memory Extractor)
sudo insmod lime-$(uname -r).ko "path=/tmp/memory.lime format=lime"

# Alternative: /proc/kcore (may not capture everything)
sudo dd if=/proc/kcore of=/tmp/memory.raw bs=1M

# Windows — use WinPMEM or DumpIt
winpmem_mini_x64.exe memory.raw

# Alternative: FTK Imager (GUI)
# Or: Magnet RAM Capture

Volatility 3 Analysis

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

# List running processes
vol -f memory.raw windows.pslist
vol -f memory.raw windows.pstree    # Tree view (shows parent-child)
vol -f memory.raw windows.psscan    # Finds hidden/terminated processes

# Network connections
vol -f memory.raw windows.netscan
vol -f memory.raw windows.netstat

# Look for injected code
vol -f memory.raw windows.malfind

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

# Extract DLLs loaded by a process
vol -f memory.raw windows.dlllist --pid 1234

# Command line arguments
vol -f memory.raw windows.cmdline

# Registry hives (passwords, persistence)
vol -f memory.raw windows.registry.hivelist
vol -f memory.raw windows.registry.printkey --key "Software\Microsoft\Windows\CurrentVersion\Run"

# Detect rootkits
vol -f memory.raw windows.ssdt     # System Service Descriptor Table hooks
vol -f memory.raw windows.callbacks # Kernel callbacks

# Extract files from memory
vol -f memory.raw windows.filescan | grep -i "password\|secret\|key"
vol -f memory.raw windows.dumpfiles --virtaddr 0xfa8001234567

# Linux memory analysis
vol -f memory.lime linux.pslist
vol -f memory.lime linux.bash      # Bash history from memory
vol -f memory.lime linux.check_syscall  # Syscall table hooks
vol -f memory.lime linux.lsmod     # Loaded kernel modules

Memory Forensics Checklist

ArtifactVolatility PluginWhat It Reveals
Processespslist, pstree, psscanRunning programs, hidden processes
Networknetscan, netstatActive connections, C2 communication
Injected codemalfindCode injection, process hollowing
DLLsdlllist, ldrmodulesLoaded libraries, DLL injection
HandleshandlesOpen files, registry keys, mutexes
Command historycmdline, consolesCommands executed
Registryprintkey, hivelistPersistence mechanisms, configuration
ServicessvcscanMalicious services
Driversdriverscan, modulesRootkit drivers
Stringsstrings (external)Passwords, URLs, IPs in memory

Disk Forensics

Evidence Acquisition

Chain of Custody

Forensic evidence must maintain chain of custody to be admissible in legal proceedings. Document every step: who handled the evidence, when, what was done, and hash values before and after.

bash
# Create forensic image with dd
sudo dd if=/dev/sda of=/evidence/disk.raw bs=4M status=progress

# Better: use dc3dd (forensic dd with hashing)
sudo dc3dd if=/dev/sda of=/evidence/disk.raw hash=sha256 log=acquisition.log

# Or use Guymager (GUI, supports E01 format)

# Always use a write-blocker when imaging physical drives

# Verify integrity
sha256sum /evidence/disk.raw
# Compare with hash recorded during acquisition

Autopsy — Open Source Forensic Platform

Autopsy provides:
1. Timeline analysis — reconstruct events chronologically
2. File system analysis — deleted files, file carving, slack space
3. Keyword search — find specific terms across entire disk
4. Hash lookup — identify known malicious/good files (NSRL)
5. Web artifact analysis — browser history, downloads, cookies
6. Email parsing — extract and analyze email databases
7. Registry analysis — Windows registry hive parsing
8. Installed programs — identify software and versions

Workflow:
1. Create new case in Autopsy
2. Add forensic image as data source
3. Run ingest modules (hash, keyword, web, recent activity)
4. Review results in categorized views
5. Generate report

FTK Imager — Forensic Imaging and Preview

FTK Imager capabilities:
- Create forensic images (E01, AFF, raw)
- Preview disk contents without modifying
- Mount forensic images as virtual drives
- Extract specific files from images
- Capture memory
- Calculate hashes for verification

Common Forensic Artifacts (Linux)

bash
# Authentication logs
/var/log/auth.log        # SSH logins, sudo usage, PAM
/var/log/secure           # RHEL/CentOS equivalent
/var/log/wtmp             # Login records (binary, use 'last')
/var/log/btmp             # Failed login attempts (use 'lastb')
/var/log/lastlog          # Last login per user

# System logs
/var/log/syslog           # General system log
/var/log/kern.log         # Kernel messages
/var/log/daemon.log       # Daemon logs

# Web server logs
/var/log/apache2/access.log
/var/log/nginx/access.log

# Persistence mechanisms
/etc/crontab
/etc/cron.d/*
/var/spool/cron/crontabs/*
/etc/rc.local
~/.bashrc                 # Shell initialization
~/.profile
/etc/systemd/system/*.service  # Systemd services

# Recently modified files (potential backdoors)
find / -mtime -7 -type f 2>/dev/null | grep -v proc

# SSH artifacts
~/.ssh/authorized_keys    # Authorized public keys
~/.ssh/known_hosts        # Connected hosts
/var/log/auth.log         # SSH connection logs

# Timeline creation with tools
# Plaso (log2timeline) — create super-timeline
log2timeline.py /evidence/timeline.plaso /evidence/disk.raw
psort.py -o l2tcsv /evidence/timeline.plaso "date > '2026-03-15'" > timeline.csv

Log Analysis for Threat Hunting

Splunk Queries

spl
# Find brute force attempts
index=auth sourcetype=linux_secure "Failed password"
| stats count by src_ip, user
| where count > 10
| sort -count

# Detect lateral movement (SSH from internal to internal)
index=auth sourcetype=linux_secure "Accepted publickey"
| where src_ip LIKE "10.%"
| stats count by src_ip, dest_ip, user
| sort -count

# Find unusual process execution
index=sysmon EventCode=1
| where parent_process="cmd.exe" OR parent_process="powershell.exe"
| stats count by process, parent_process, user
| where count < 5
| sort count

# Detect data exfiltration (large outbound transfers)
index=network
| where bytes_out > 100000000 AND dest_port!=443 AND dest_port!=80
| stats sum(bytes_out) as total_bytes by src_ip, dest_ip, dest_port
| sort -total_bytes

# PowerShell suspicious commands
index=windows sourcetype=WinEventLog:Microsoft-Windows-PowerShell/Operational
| search "EncodedCommand" OR "Invoke-Expression" OR "IEX" OR "DownloadString"
| table _time, user, ScriptBlockText

# Detect persistence via scheduled tasks
index=windows sourcetype=WinEventLog:Security EventCode=4698
| table _time, user, TaskName, TaskContent

# Hunt for DNS tunneling
index=dns
| eval query_length=len(query)
| where query_length > 50
| stats count by src_ip, query
| where count > 100

ELK Stack (Elasticsearch + Logstash + Kibana)

json
// Elasticsearch query: failed SSH logins in last 24h
{
  "query": {
    "bool": {
      "must": [
        { "match": { "message": "Failed password" } },
        { "range": { "@timestamp": { "gte": "now-24h" } } }
      ]
    }
  },
  "aggs": {
    "by_source_ip": {
      "terms": { "field": "source.ip", "size": 20 },
      "aggs": {
        "by_user": {
          "terms": { "field": "user.name", "size": 10 }
        }
      }
    }
  }
}
json
// Detect unusual outbound connections
{
  "query": {
    "bool": {
      "must": [
        { "range": { "destination.port": { "gte": 1024 } } },
        { "range": { "network.bytes": { "gte": 10000000 } } }
      ],
      "must_not": [
        { "terms": { "destination.port": [443, 80, 8443, 8080] } }
      ]
    }
  }
}

Chain of Custody

Chain of Custody Form

FieldExample
Case numberIR-2026-0042
Evidence IDEVD-001
Description1TB Samsung SSD from web server prod-web-01
Hash (acquisition)SHA256: a1b2c3d4e5f6...
Acquired byJane Smith, GCFA
Date/time acquired2026-03-20 14:32:00 UTC
Methoddc3dd with write-blocker
Storage locationEvidence locker B, shelf 3
Transfer logEach person who handles it signs and dates

Threat Hunting with MITRE ATT&CK

MITRE ATT&CK provides a knowledge base of adversary tactics and techniques. Use it to structure threat hunts by searching for evidence of specific techniques.

High-Priority Hunt Hypotheses

ATT&CK TechniqueIDWhat to Hunt ForData Source
Initial Access: PhishingT1566Emails with attachments/links, macro executionEmail gateway, EDR
Execution: PowerShellT1059.001Encoded commands, unusual scriptsWindows Event 4104
Persistence: Scheduled TaskT1053New tasks, modified tasksWindows Event 4698
Persistence: Registry Run KeysT1547.001New Run/RunOnce entriesSysmon Event 13
Defense Evasion: Process InjectionT1055VirtualAllocEx + WriteProcessMemorySysmon Event 8
Credential Access: DCSyncT1003.006Replication requests from non-DCWindows Event 4662
Lateral Movement: PsExecT1570New service creation on remote hostsWindows Event 7045
Exfiltration: DNST1048.003Large/frequent DNS queries, TXT recordsDNS logs, Zeek
C2: BeaconingT1071Regular-interval connections to same hostProxy logs, flow data

Threat Hunting Workflow

bash
# 1. Form a hypothesis
# "An attacker may be using PowerShell to download and execute payloads"

# 2. Define data sources
# Windows PowerShell Operational logs (Event ID 4104)
# Sysmon logs (Event ID 1 - Process Creation)

# 3. Write detection queries
# Splunk:
# index=windows sourcetype=WinEventLog EventCode=4104
# | search ScriptBlockText="*DownloadString*" OR
#          ScriptBlockText="*Invoke-WebRequest*" OR
#          ScriptBlockText="*IEX*" OR
#          ScriptBlockText="*-enc*"
# | table _time, ComputerName, ScriptBlockText

# 4. Analyze results — differentiate legitimate from malicious

# 5. Document findings

# 6. Create permanent detection rules if threats found

IR Playbook: Ransomware

Before Paying Ransom

  1. Payment does not guarantee decryption — 20% of companies that pay do not get their data back
  2. Payment funds criminal organizations
  3. Check NoMoreRansom.org for free decryptors
  4. Consult legal counsel — paying ransom may violate sanctions laws (OFAC)
  5. Report to law enforcement (FBI IC3, local CERT)

DFIR Tools Reference

ToolPurposePlatformCost
Volatility 3Memory forensicsCross-platformFree
AutopsyDisk forensicsCross-platformFree
FTK ImagerForensic imagingWindowsFree
Plaso/log2timelineSuper-timeline creationCross-platformFree
KAPETriage collectionWindowsFree
VelociraptorEndpoint forensics at scaleCross-platformFree
TheHiveIR case managementSelf-hostedFree
CortexObservable analysis automationSelf-hostedFree
MISPThreat intel sharingSelf-hostedFree
SplunkSIEM, log analysisSelf-hosted/CloudFree tier / Enterprise
Elastic SIEMSIEM, detection rulesSelf-hosted/CloudFree tier / Paid
WazuhOpen-source SIEM + EDRSelf-hostedFree
ZeekNetwork traffic analysisLinuxFree
Eric Zimmerman's ToolsWindows forensic parsingWindowsFree

Further Reading


Key Takeaway

  • The first rule of incident response is preserve evidence — never power off a compromised system before capturing memory, and never modify the original evidence
  • Memory forensics with Volatility reveals what disk forensics cannot: running processes, network connections, injected code, and encryption keys that vanish when power is lost
  • MITRE ATT&CK transforms reactive hunting into systematic coverage — structure your threat hunts by technique ID to find gaps in detection
Hands-On Lab

Lab: Memory Forensics Investigation

  1. Download a memory sample from the MemLabs challenge series (MemLabs Lab 1 for beginners)
  2. Identify the OS profile using vol -f memory.raw windows.info
  3. List running processes with windows.pslist and windows.pstree — identify suspicious processes
  4. Check network connections with windows.netscan — look for connections to unusual IPs or ports
  5. Run windows.malfind to find potential code injection
  6. Extract suspicious processes and strings from their memory regions
  7. Check for persistence mechanisms: registry Run keys using windows.registry.printkey
  8. Document your findings as IOCs and map each to a MITRE ATT&CK technique
CTF Challenge

Challenge: The Ransomware Incident

A company was hit by ransomware at 3:47 AM. You have a memory dump from the affected server and a disk image. The ransomware encrypted all files with a .locked extension. Find: the ransomware process, its C2 server IP, the encryption key stored in memory, and the initial infection vector.

Hints:

  1. Check pslist for processes spawned around 3:45-3:50 AM
  2. Use netscan to find outbound connections from the suspicious process
  3. The encryption key is a 32-byte AES key stored near the process's heap
  4. Check the browser history and email client for the initial phishing link
Answer

Run windows.pstree to find svcupdate.exe (PID 4892) spawned by outlook.exe at 3:46 AM — indicating a phishing email with a malicious attachment. Run windows.netscan to find svcupdate.exe connected to 185.234.56.78:443. Dump the process memory and search for the AES key pattern. Check windows.cmdline to find it was launched from C:\Users\victim\Downloads\invoice.exe. Flag: CTF{memory_never_lies_volatility_wins}.

:::

Common Misconceptions

  • "Powering off a compromised system preserves evidence" — Powering off destroys volatile memory evidence (running processes, network connections, encryption keys). Always capture memory first.
  • "Backups make ransomware harmless" — Attackers now exfiltrate data before encrypting, threatening public disclosure. Also, backups may be compromised or stale.
  • "You should immediately change all passwords during an incident" — Premature credential changes can alert the attacker, causing them to accelerate damage or deploy additional backdoors. Coordinate credential rotation with containment.
  • "Restoring from backup means the incident is over" — The vulnerability that enabled the attack still exists, backdoors may persist, and the attacker may still have valid credentials. Full eradication is required.
  • "SIEM alerts mean you are detecting attacks" — Alerts only cover what you have rules for. Most advanced attacks use techniques with no existing detection rules, which is why threat hunting is essential.
Quiz

1. According to NIST SP 800-61, what are the six phases of incident response?

a) Detect, Respond, Recover, Report, Review, Repeat b) Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned c) Plan, Scan, Exploit, Report, Remediate, Verify d) Alert, Triage, Investigate, Contain, Close, Document

Answer

b) The NIST framework defines: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned.

2. What Volatility 3 plugin detects code injection in running processes?

a) windows.pslist b) windows.netscan c) windows.malfind d) windows.dlllist

Answer

c) windows.malfind identifies suspicious memory regions in processes that have both write and execute permissions and contain potential shellcode or injected code.

3. Why must forensic images be hashed during acquisition?

a) To compress the image b) To verify integrity and maintain chain of custody for legal proceedings c) To encrypt the evidence d) To identify the file system type

Answer

b) Hashing the image at acquisition time proves the evidence has not been modified. Any change to the image would produce a different hash, breaking the chain of custody.

4. What is the primary purpose of a SIEM correlation rule?

a) To store log data efficiently b) To combine multiple low-fidelity events into a high-confidence alert c) To encrypt log data d) To forward logs to email

Answer

b) Correlation rules combine multiple events (e.g., failed logins from one IP followed by a successful login followed by data access) into a single high-confidence alert that would be missed by individual event monitoring.

5. During a ransomware incident, what should you check BEFORE restoring from backup?

a) Whether the backup is recent enough b) Whether the backup itself is clean and the infection vector has been eliminated c) Whether the backup software is up to date d) Whether the CEO approves

Answer

b) Backups may contain the malware or the vulnerability that enabled the attack. Verify backups are clean and ensure the entry vector is patched and backdoors are removed before restoring.

:::

One-Liner Summary: When prevention fails, incident response determines whether a security event becomes a headline or a lessons-learned meeting.

"What I cannot create, I do not understand." — Richard Feynman