DFIR - Digital Forensics and Incident Response
Digital Forensics and Incident Response (DFIR) combines digital forensics (securing and analyzing evidence) with incident response (containing and resolving incidents). Following cyberattacks, DFIR teams secure evidence in a manner admissible in court, reconstruct the attack timeline, identify the initial attack vector, and assist with law enforcement. Core disciplines: Memory Forensics, Disk Forensics, Network Forensics, Malware Analysis.
Digital Forensics and Incident Response (DFIR) is both the fire department and the forensic science of cybersecurity. DFIR teams are called in after security incidents to perform two parallel tasks: stopping the incident and securing evidence that may need to stand up in court.
DFIR Phases
SANS PICERL Model:
Preparation:
→ Incident Response Plan documented and tested
→ DFIR tools available and tested (forensic toolkit)
→ Log retention: at least 12 months (NIS2 requirement!)
→ Evidence chain-of-custody forms ready
→ Contacts at authorities known (BSI, LfDI, police)
→ IR retainer with DFIR service provider agreed upon in advance?
Identification:
→ Anomaly detected: SIEM alert, EDR alert, user report
→ Initial triage: False positive or genuine incident?
→ Scope: Which systems are affected?
→ Severity: Significant incident? (NIS2 reporting trigger!)
Containment:
→ Before forensic evidence is secured: DO NOT restart!
→ Short-term containment: Network isolation, account deactivation
→ Long-term containment: Rebuild parallel systems
→ IMPORTANT: Secure evidence BEFORE containment where possible
Eradication:
→ Remove malware
→ Close backdoors
→ Fix the initial attack vector (patch the vulnerability!)
→ Rotate all compromised credentials
Recovery:
→ Restore systems from verified backups
→ Intensify monitoring (detect reinfection!)
→ Step-by-step return to operation
Lessons Learned:
→ Create an IR report (internal + for authorities if necessary)
→ Root cause analysis
→ Action plan: How do we prevent recurrence?
→ Detection rules based on the attacker’s TTPs
Forensic Evidence Preservation
Chain of Custody – court-admissible evidence preservation:
Basic principle: Preserve evidence without altering it!
→ Original data carriers: never analyze directly
→ Write blockers: physical or software-based write protection
→ Forensic copy (bit-for-bit copy = forensic image)
→ Hash verification: SHA-256 of the original = SHA-256 of the copy
ISO/IEC 27037 - Standard for digital evidence:
→ Identification: What are the relevant sources of evidence?
→ Preservation: Physically secure (deny access)
→ Collection: Create forensic copies
→ Retention: Ensure integrity over time
Memory Forensics (RAM Analysis) - Time-sensitive!:
→ RAM is volatile: Reboot = Loss of all RAM data!
→ Memory contains: running processes, plaintext passwords,
cryptographic keys, network connections, injected code
→ FIRST RAM dump, THEN other steps!
Tools:
Velociraptor: Enterprise IR platform (free), RAM + disk + artifacts
Magnet RAM Capture: free RAM capture (Windows)
WinPmem: Open Source RAM dump (Windows)
LiME (Linux Memory Extractor): Kernel module for Linux RAM
RAM dump command (Velociraptor):
velociraptor.exe artifacts collect Windows.Memory.Acquisition
--args OutputPath=C:\evidence\ram.aff4
Analysis with Volatility 3:
python3 vol.py -f ram.aff4 windows.pslist # Process list
python3 vol.py -f ram.aff4 windows.netscan # Network connections
python3 vol.py -f ram.aff4 windows.cmdline # Command line history
python3 vol.py -f ram.aff4 windows.malfind # Injected code
Disk Forensics:
Write Blocker:
→ Hardware: Tableau, CRU Wiebetech (standard in law enforcement)
→ Software: Arsenal Image Mounter, dc3dd, FTK Imager with Write-Block
Create forensic image:
dd if=/dev/sda bs=512 | tee disk.img | sha256sum > disk.sha256
# Or professionally:
ewfacquire /dev/sda -t evidence -C "Case-2026-001" -D "Server-DC01"
Analysis tools:
→ Autopsy (Open Source): GUI for disk forensics, Windows + Linux
→ FTK (Forensic Toolkit): commercial, industry standard
→ X-Ways Forensics: efficient for large volumes
→ Plaso: Log2Timeline for Supertimeline (all events in a timeline)
Malware Analysis in the DFIR Context
Triage analysis (quick, surface-level):
Static analysis:
→ Check file hash against VirusTotal:
sha256sum malware.exe | cut -d' ' -f1
curl -X POST "https://www.virustotal.com/vtapi/v2/file/report" \
-d "apikey=<key>&resource;=<sha256>"
→ Extract strings: strings -n 8 malware.exe
→ Analyze imports: dumpbin /imports malware.exe (Windows)
→ Suspicious: CreateRemoteThread, VirtualAllocEx, WriteProcessMemory
→ YARA scan: find known patterns
Dynamic Analysis (Sandbox):
→ Cuckoo Sandbox (self-hosted): malware in isolated VM
→ ANY.RUN (online, free): interactive malware analysis
→ Hybrid Analysis (free): automated behavioral analysis
→ Joe Sandbox (commercial): deepest analysis
IOC Extraction for SIEM:
→ IP addresses and domains from network connections
→ File hashes of malware components
→ Registry keys that are created
→ Mutex names (unique identifiers of the malware)
→ User agents of the C2 beacon
Reconstruct incident timeline:
Goal: Attack timeline from initial access to discovery
Windows Event Log Analysis:
→ 4624: Logon successful (who logged in and when?)
→ 4625: Logon failed (brute force?)
→ 4648: Logon with explicit credentials (pass-the-hash?)
→ 4688: Process start (which programs were executed?)
→ 4698: Scheduled task created (Persistence!)
→ 7045: Service installed (Malware as a service!)
→ 4776: NTLM authentication
Windows artifacts:
→ Prefetch: Which programs were executed? (C:\Windows\Prefetch)
→ ShimCache: Program execution history (Registry)
→ Amcache.hve: Detailed program execution information
→ MFT (Master File Table): All file operations with timestamps
→ Browser history, downloads, cache
→ Shellbags: Folders that were opened (lateral movement indicator)
→ SRUM (System Resource Usage Monitor): Program CPU/network usage
Supertimeline with Plaso:
log2timeline.py --storage-file evidence.plaso /mnt/evidence/
psort.py -z UTC evidence.plaso "date > '2026-02-01 00:00:00'"
# → All events chronologically from all sources
Threat Intelligence Integration
Integrate IOCs from DFIR analysis into Threat Intel:
What are IOCs (Indicators of Compromise)?
→ File Hashes: SHA256 of the malware (only useful for known malware!)
→ IP Addresses: C2 servers, download servers
→ Domains: C2 domains, phishing domains
→ URLs: Payload download URLs
→ Email addresses: Senders of spear-phishing
→ Mutex names: Unique identifiers of the malware
→ Registry keys: Persistence mechanisms
→ YARA rules: Byte patterns of the malware
IOC Quality:
→ Pyramid of Pain (David Bianco):
Lowest Pain for Attackers: Hash (easy to change!)
→ IP → Domain → Network Artifacts → Tools → TTPs (Highest Pain!)
→ TTPs (Tactics, Techniques, Procedures) = more valuable IOCs than hashes
MISP (Malware Information Sharing Platform):
→ Open-source IOC-sharing platform
→ AWARE7 shares IOCs via the MISP community
→ Dedicated MISP instance for internal IOC management
misp.github.io - free, GDPR-compliant
STIX/TAXII (Standard for Threat Intelligence Sharing):
→ STIX 2.1: JSON format for structured threat intelligence
→ TAXII 2.1: Transport protocol for STIX feeds
→ Integration: SIEM, TIP, firewalls
Deploying threat intelligence in SIEM:
# Microsoft Sentinel - Threat Intelligence Workbook
# Automatic IOC matching against all logs:
ThreatIntelligenceIndicator
| join (SecurityEvent) on $left.NetworkIP == $right.IpAddress
| where TimeGenerated > ago(24h)
| project TimeGenerated, Computer, IPAddress, ThreatType, Description
```</sha256></key>