350 lines
10 KiB
Markdown
350 lines
10 KiB
Markdown
# FILE: MOD6_Incident_Response.md
|
|
# MODULE 6: INCIDENT RESPONSE & DIGITAL FORENSICS
|
|
|
|
## Learning Objectives
|
|
- Follow NIST Incident Response lifecycle (PICERL)
|
|
- Acquire forensic disk and memory images
|
|
- Analyze artifacts with Autopsy and Volatility
|
|
- Reconstruct attack timelines from logs and forensics
|
|
- Write comprehensive incident response reports
|
|
|
|
---
|
|
|
|
## NIST IR LIFECYCLE
|
|
|
|
**PICERL Framework:**
|
|
1. **Preparation:** Tools, procedures, training
|
|
2. **Identification:** Detect and validate incidents
|
|
3. **Containment:** Limit damage (short-term & long-term)
|
|
4. **Eradication:** Remove threat from environment
|
|
5. **Recovery:** Restore systems to normal operation
|
|
6. **Lessons Learned:** Post-incident review
|
|
|
|
---
|
|
|
|
## LAB 6.1: DISK FORENSICS WITH AUTOPSY
|
|
|
|
### Acquire Disk Image
|
|
|
|
```bash
|
|
# On Proxmox, snapshot compromised Metasploitable VM
|
|
qm snapshot 401 forensics-image --description "Post-compromise forensic capture"
|
|
|
|
# Export disk image
|
|
qm stop 401
|
|
dd if=/dev/pve/vm-401-disk-0 of=/root/metasploitable_forensics.dd bs=4M
|
|
# Or use FTK Imager on Windows for E01 format
|
|
|
|
# Calculate hash (evidence integrity)
|
|
md5sum /root/metasploitable_forensics.dd > metasploitable.md5
|
|
sha256sum /root/metasploitable_forensics.dd > metasploitable.sha256
|
|
```
|
|
|
|
### Analyze with Autopsy
|
|
|
|
```
|
|
1. Install Autopsy (on analyst workstation or Kali):
|
|
sudo apt install autopsy
|
|
|
|
2. Start Autopsy:
|
|
autopsy
|
|
# Opens browser to http://localhost:9999/autopsy
|
|
|
|
3. Create New Case:
|
|
- Case Name: Metasploitable Compromise Investigation
|
|
- Description: Analysis of MOD3 exploitation artifacts
|
|
- Investigator: [Your Name]
|
|
|
|
4. Add Data Source:
|
|
- Type: Disk Image
|
|
- Path: /root/metasploitable_forensics.dd
|
|
- Import method: Calculate hash
|
|
- Ingest modules: Select all
|
|
|
|
5. Key Analysis Areas:
|
|
|
|
TIMELINE ANALYSIS:
|
|
- Tools > Generate Timeline
|
|
- Filter by date of compromise
|
|
- Look for: File modifications, command execution, new processes
|
|
|
|
WEB ARTIFACTS:
|
|
- Data Artifacts > Web History
|
|
- Check for attacker tool downloads
|
|
|
|
FILE ANALYSIS:
|
|
- Deleted Files > Recover
|
|
- Look in /tmp, /var/tmp for attacker tools
|
|
- Search for .bash_history files
|
|
|
|
KEYWORD SEARCH:
|
|
- Search: "backdoor", "shell", "exploit"
|
|
- Search IPs: 10.10.2.50 (Kali attacker)
|
|
|
|
HASH ANALYSIS:
|
|
- File > Hash Lookup
|
|
- Compare against NSRL (known good files)
|
|
- Identify unknown binaries (potential malware)
|
|
```
|
|
|
|
### Key IOCs to Document
|
|
- New user accounts created
|
|
- Modified /etc/passwd, /etc/shadow
|
|
- Suspicious cron jobs
|
|
- Backdoor files in /tmp, /var/www
|
|
- SSH authorized_keys modifications
|
|
- Large outbound network transfers
|
|
|
|
---
|
|
|
|
## LAB 6.2: MEMORY FORENSICS WITH VOLATILITY
|
|
|
|
### Capture Memory Dump
|
|
|
|
```bash
|
|
# From Proxmox, capture running VM memory
|
|
virsh dump 401 /root/metasploitable_memory.dump --memory-only
|
|
|
|
# Or use LiME (Linux Memory Extractor) from within VM
|
|
git clone https://github.com/504ensicsLabs/LiME
|
|
cd LiME/src
|
|
make
|
|
sudo insmod lime-$(uname -r).ko "path=/tmp/memory.lime format=lime"
|
|
```
|
|
|
|
### Analyze with Volatility 3
|
|
|
|
```bash
|
|
# Install Volatility 3
|
|
git clone https://github.com/volatilityfoundation/volatility3
|
|
cd volatility3
|
|
python3 setup.py install
|
|
|
|
# Identify OS profile
|
|
vol -f /root/metasploitable_memory.dump banners.Banners
|
|
|
|
# List processes
|
|
vol -f /root/metasploitable_memory.dump linux.pslist.PsList
|
|
|
|
# Find suspicious processes (look for bash, nc, python shells)
|
|
vol -f /root/metasploitable_memory.dump linux.pslist.PsList | grep -E "bash|nc|python"
|
|
|
|
# View command line arguments
|
|
vol -f /root/metasploitable_memory.dump linux.cmdline.CmdLine
|
|
|
|
# Network connections
|
|
vol -f /root/metasploitable_memory.dump linux.netstat.Netstat
|
|
# Look for connections to 10.10.2.50:4444 (reverse shell)
|
|
|
|
# Extract process memory
|
|
vol -f /root/metasploitable_memory.dump -o /tmp/dump linux.proc.Maps --pid 1234 --dump
|
|
|
|
# Bash history from memory
|
|
vol -f /root/metasploitable_memory.dump linux.bash.Bash
|
|
|
|
# Loaded kernel modules (rootkit detection)
|
|
vol -f /root/metasploitable_memory.dump linux.lsmod.Lsmod
|
|
```
|
|
|
|
---
|
|
|
|
## LAB 6.3: NETWORK FORENSICS
|
|
|
|
### PCAP Analysis from MOD3 Exploitation
|
|
|
|
```bash
|
|
# Analyze saved packet capture from Wireshark
|
|
|
|
# Extract files transferred over HTTP
|
|
tcpflow -r exploit_traffic.pcap -o extracted_files/
|
|
|
|
# Reconstruct TCP streams
|
|
for stream in $(tshark -r exploit_traffic.pcap -T fields -e tcp.stream | sort -u); do
|
|
tshark -r exploit_traffic.pcap -q -z follow,tcp,ascii,$stream
|
|
done
|
|
|
|
# Find reverse shell traffic
|
|
tshark -r exploit_traffic.pcap -Y "tcp.dstport == 4444" -T fields -e frame.time -e ip.src -e ip.dst -e tcp.payload
|
|
|
|
# DNS exfiltration detection (long domain names)
|
|
tshark -r exploit_traffic.pcap -Y "dns.qry.name.len > 50" -T fields -e dns.qry.name
|
|
```
|
|
|
|
### Using NetworkMiner (GUI alternative)
|
|
|
|
```
|
|
1. Install NetworkMiner (Windows or Linux)
|
|
2. Open exploit_traffic.pcap
|
|
3. View tabs:
|
|
- Hosts: See attacker (10.10.2.50) and victim (10.10.4.10)
|
|
- Files: Auto-extracted files transferred
|
|
- Credentials: Captured plaintext passwords
|
|
- Sessions: TCP conversations
|
|
- DNS: Domain lookups
|
|
```
|
|
|
|
---
|
|
|
|
## LAB 6.4: LOG ANALYSIS FOR IR
|
|
|
|
### Linux System Log Analysis
|
|
|
|
```bash
|
|
# Authentication logs
|
|
sudo grep "Failed password" /var/log/auth.log | wc -l
|
|
# Count brute-force attempts
|
|
|
|
# Successful logins after failures
|
|
sudo grep "Accepted password" /var/log/auth.log | tail -n 20
|
|
|
|
# New user creation
|
|
sudo grep "useradd" /var/log/auth.log
|
|
|
|
# Sudo command execution
|
|
sudo grep "COMMAND" /var/log/auth.log
|
|
|
|
# Cron job modifications
|
|
sudo grep "cron" /var/log/syslog
|
|
|
|
# Web server access logs
|
|
tail -n 100 /var/log/apache2/access.log
|
|
# Look for exploit payloads in URLs
|
|
grep -E "\.\.\/|<script|UNION|cmd=" /var/log/apache2/access.log
|
|
```
|
|
|
|
### Timeline Creation
|
|
|
|
```bash
|
|
# Combine all logs by timestamp
|
|
cat /var/log/auth.log /var/log/syslog /var/log/apache2/access.log | sort -k1,3 > combined_timeline.txt
|
|
|
|
# Or use log2timeline (Plaso)
|
|
log2timeline.py --storage_file timeline.plaso /var/log/
|
|
psort.py -o l2tcsv -w timeline.csv timeline.plaso
|
|
```
|
|
|
|
---
|
|
|
|
## LAB 6.5: INCIDENT REPORT WRITING
|
|
|
|
### Report Structure
|
|
|
|
```markdown
|
|
# INCIDENT RESPONSE REPORT
|
|
**Case ID:** IR-2026-02-001
|
|
**Incident Type:** Unauthorized Access - Exploitation
|
|
**Severity:** CRITICAL
|
|
**Status:** Contained
|
|
**Date Range:** 2026-02-11 14:00 - 15:30 UTC
|
|
**Analyst:** [Your Name]
|
|
|
|
## EXECUTIVE SUMMARY
|
|
On February 11, 2026, at approximately 14:00 UTC, an unauthorized actor exploited a vulnerable FTP service (vsftpd 2.3.4) on production server 10.10.4.10, gaining root-level access. The attacker performed credential harvesting and established persistence via SSH key injection. The incident was contained at 15:30 UTC with no evidence of data exfiltration.
|
|
|
|
## TIMELINE OF EVENTS
|
|
| Time (UTC) | Event | Source |
|
|
|------------|-------|--------|
|
|
| 14:00:15 | Port scan detected from 10.10.2.50 | Suricata IDS |
|
|
| 14:15:32 | vsftpd backdoor triggered | auth.log |
|
|
| 14:16:05 | Root shell established on port 6200 | netstat, PCAP |
|
|
| 14:18:22 | /etc/shadow downloaded | File integrity monitoring |
|
|
| 14:20:45 | SSH authorized_keys modified | auth.log |
|
|
| 14:25:10 | Incident detected by SOC analyst | Security Onion alert |
|
|
| 15:30:00 | Server isolated, attacker access terminated | Firewall logs |
|
|
|
|
## INDICATORS OF COMPROMISE (IOCs)
|
|
**Network:**
|
|
- Attacker IP: 10.10.2.50
|
|
- C2 Port: 6200 (vsftpd backdoor)
|
|
- Reverse shell: 10.10.2.50:4444
|
|
|
|
**File System:**
|
|
- /root/.ssh/authorized_keys (modified 2026-02-11 14:20:45)
|
|
- /tmp/.hidden_shell.sh (created 2026-02-11 14:17:00)
|
|
- MD5: a3f5b8c9e2d1f4a6b7c8d9e0f1a2b3c4
|
|
|
|
**Processes:**
|
|
- PID 6543: /bin/bash (spawned by vsftpd, uid=0)
|
|
|
|
## ROOT CAUSE ANALYSIS
|
|
1. **Vulnerability:** vsftpd 2.3.4 contains hardcoded backdoor (CVE-2011-2523)
|
|
2. **Lack of Patching:** Service running outdated version (released 2011)
|
|
3. **Detection Gap:** IDS signature existed but alert was not tuned for priority response
|
|
4. **Network Segmentation Failure:** Victim server allowed outbound connection to attacker network
|
|
|
|
## CONTAINMENT ACTIONS
|
|
1. Isolated server at network layer (pfSense block rule)
|
|
2. Terminated attacker SSH sessions (killed PIDs)
|
|
3. Disabled vsftpd service (systemctl stop vsftpd)
|
|
4. Changed all system passwords
|
|
5. Removed unauthorized SSH keys
|
|
|
|
## ERADICATION
|
|
1. Rebuilt server from clean snapshot (pre-compromise)
|
|
2. Patched vsftpd to version 3.0.5
|
|
3. Removed attacker-created user accounts
|
|
4. Cleared cron jobs
|
|
|
|
## RECOVERY
|
|
1. Validated system integrity (rkhunter, chkrootkit)
|
|
2. Restored from secure backup
|
|
3. Monitored for 48 hours (no reinfection)
|
|
4. Returned to production 2026-02-13 10:00 UTC
|
|
|
|
## LESSONS LEARNED
|
|
**What Went Well:**
|
|
- IDS detected reconnaissance phase
|
|
- Forensic artifacts preserved due to snapshot policy
|
|
- Incident contained within 90 minutes of detection
|
|
|
|
**What Needs Improvement:**
|
|
- Vulnerability management process (vsftpd was 15 years old!)
|
|
- Alert prioritization (scan alerts should trigger immediate investigation)
|
|
- Egress filtering (victim should not reach Red Team network)
|
|
|
|
## RECOMMENDATIONS
|
|
1. **Immediate:** Implement vulnerability scanning (weekly, automated)
|
|
2. **Short-term:** Deploy application whitelisting on critical servers
|
|
3. **Long-term:** Implement zero-trust architecture (segment victim networks further)
|
|
4. **Process:** Conduct tabletop exercises quarterly
|
|
|
|
## APPENDICES
|
|
- Appendix A: Full network packet capture (exploit_traffic.pcapng)
|
|
- Appendix B: Disk forensic image hash (SHA256: abc123...)
|
|
- Appendix C: Memory dump analysis (Volatility output)
|
|
- Appendix D: Log files (auth.log, syslog, apache2 access.log)
|
|
```
|
|
|
|
---
|
|
|
|
## KNOWLEDGE CHECK
|
|
|
|
1. **What are the 6 phases of NIST incident response?**
|
|
- Answer: Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned
|
|
|
|
2. **Why must forensic images be hashed?**
|
|
- Answer: Prove integrity and chain of custody for legal admissibility
|
|
|
|
3. **What Volatility command lists running processes?**
|
|
- Answer: `linux.pslist.PsList` (or `windows.pslist` for Windows)
|
|
|
|
4. **Name 3 IOCs from the example incident**
|
|
- Answer: Attacker IP 10.10.2.50, modified authorized_keys, vsftpd backdoor port 6200
|
|
|
|
---
|
|
|
|
## DELIVERABLES
|
|
|
|
- [ ] Disk forensic image with hash values
|
|
- [ ] Memory dump with Volatility analysis report
|
|
- [ ] PCAP file from exploitation phase
|
|
- [ ] Complete incident timeline (spreadsheet)
|
|
- [ ] Full incident response report (10+ pages)
|
|
- [ ] Lessons learned presentation
|
|
|
|
---
|
|
|
|
**END OF MODULE 6**
|
|
|
|
Proceed to **MOD7: Web Application Security** to expand attack surface knowledge.
|