Handle evidence and documentation before moving to reading resources.

Opening Framing: Building the Record

Incidents end, but their impact continues. Legal proceedings, regulatory inquiries, insurance claims, and internal reviews all depend on the documentation created during response. Poor documentation makes incidents invisible—lessons aren't learned, and the organization remains vulnerable.

Beyond the immediate incident, documentation enables improvement. Post-incident reviews identify what worked and what didn't. Metrics demonstrate SOC value. Reports inform leadership decisions.

This week covers evidence handling, incident documentation, report writing, and post-incident activities that turn incidents into organizational learning.

Key insight: Documentation quality determines whether an incident makes the organization stronger or just older.

1) Digital Evidence Fundamentals

Digital evidence requires special handling to maintain integrity:

Evidence Principles:

Authenticity:
- Is this evidence what it claims to be?
- Can we prove it hasn't been modified?
- Hash values verify integrity

Reliability:
- Was it collected properly?
- Are the tools trustworthy?
- Is the process repeatable?

Completeness:
- Do we have everything relevant?
- Are there gaps in the evidence?
- What might be missing?

Chain of Custody:
- Who has handled the evidence?
- Where has it been stored?
- Is there a complete record?

Types of Digital Evidence:

Volatile Evidence (disappears when power lost):
- RAM contents
- Running processes
- Network connections
- Logged-in users
- Clipboard contents
- Temporary files

Non-Volatile Evidence (persists):
- Hard drive contents
- Log files
- Registry entries
- Configuration files
- User files

Network Evidence:
- Packet captures
- Flow data
- Firewall logs
- Proxy logs
- DNS logs

Cloud Evidence:
- Cloud provider logs
- SaaS application logs
- API access logs
- Configuration snapshots

Evidence Integrity:

Hash Verification:

Before analysis:
$ sha256sum evidence.img
a1b2c3d4e5f6... evidence.img

After analysis:
$ sha256sum evidence.img
a1b2c3d4e5f6... evidence.img

Hashes match = evidence unchanged

Common hash algorithms:
- MD5 (legacy, collision vulnerabilities)
- SHA-1 (deprecated)
- SHA-256 (current standard)

Always hash:
- Before and after acquisition
- When transferring evidence
- When beginning analysis
- When completing analysis

Key insight: Evidence that can't be proven authentic is worthless in legal proceedings. Treat all evidence as potentially needed in court.

2) Evidence Collection Procedures

Systematic collection ensures nothing is missed:

Collection Checklist - Windows System:

Volatile (collect first, system running):
□ Current date/time
□ Running processes (tasklist, Get-Process)
□ Network connections (netstat -ano)
□ Logged-in users (query user)
□ Open files (openfiles)
□ Clipboard contents
□ Memory dump (WinPMEM, DumpIt)

Non-Volatile:
□ Event logs (Security, System, Application)
□ Registry hives
□ Prefetch files
□ Browser history/cache
□ Recent files
□ User profiles
□ Scheduled tasks
□ Services
□ Full disk image (if warranted)

Linux Collection:

Collection Checklist - Linux System:

Volatile:
□ Current date/time (date)
□ Running processes (ps aux)
□ Network connections (netstat -tulpn, ss)
□ Logged-in users (who, w)
□ Open files (lsof)
□ Memory dump (LiME)

Non-Volatile:
□ /var/log/* (all logs)
□ /etc/* (configuration)
□ ~/.bash_history (user history)
□ Cron jobs (/etc/cron*, crontab -l)
□ /tmp and /var/tmp
□ User home directories
□ Installed packages
□ Full disk image (dd, dc3dd)

Collection Tools:

Memory Acquisition:
- WinPMEM (Windows)
- LiME (Linux)
- DumpIt (Windows, easy)
- F-Response (enterprise)

Disk Imaging:
- FTK Imager (Windows, free)
- dc3dd (Linux)
- Guymager (Linux GUI)
- EnCase (commercial)

Triage Collection:
- KAPE (Windows artifacts)
- Velociraptor (cross-platform)
- CyLR (cross-platform)
- UAC (Unix-like Artifacts Collector)

Live Response:
- GRR Rapid Response
- OSQuery
- Velociraptor
- PowerShell scripts

Remote Collection Considerations:

When physical access isn't possible:

EDR-based collection:
- Memory snapshots
- File retrieval
- Process dumps
- Works over network

Agent-based tools:
- Velociraptor
- GRR
- Requires pre-deployed agent

PowerShell remoting:
- Invoke-Command for Windows
- Requires proper access

SSH for Linux:
- Remote command execution
- Secure file transfer

Cloud environments:
- API-based log export
- Snapshot VMs before changes
- Cloud forensics tools

Key insight: Have collection procedures documented and tools ready BEFORE incidents occur. Scrambling during an incident leads to missed evidence.

3) Incident Documentation

Comprehensive documentation throughout the incident:

Incident Timeline:

Living document updated throughout incident:

Time (UTC)   | Event                           | Source    | Actor
─────────────────────────────────────────────────────────────────────
2024-01-15   |                                 |           |
09:15:00     | Phishing email received         | Email GW  | External
09:23:00     | User opened attachment          | EDR       | mjohnson
09:23:15     | Macro executed PowerShell       | Sysmon    | System
09:24:00     | C2 connection established       | Firewall  | Malware
09:45:00     | Alert triggered                 | SIEM      | Automated
09:52:00     | Alert triaged, escalated        | Ticket    | Analyst1
10:05:00     | IR team engaged                 | Comms     | SOC Lead
10:15:00     | Endpoint isolated               | EDR       | Analyst2
...

Include:
- All significant events
- Investigation actions
- Decisions made
- Communications sent

Investigation Notes:

Document as you investigate:

Query Log:
- What you searched for
- Where you searched
- What you found
- Timestamp of search

Format example:
[2024-01-15 10:23 UTC] - Analyst: JSmith
Query: index=windows host=FIN-WS-042 EventCode=4688
Source: Splunk
Result: Found PowerShell execution at 09:23:15
        Command: powershell -enc [base64]
        Parent: WINWORD.EXE
Significance: Confirms macro executed PowerShell

Why document queries:
- Reproducibility
- Peer review
- Legal defensibility
- Training value

Decision Log:

Record all significant decisions:

[2024-01-15 10:15 UTC]
Decision: Isolate endpoint FIN-WS-042
Made by: John Smith (IR Lead)
Rationale: Active C2 communication, risk of lateral movement
Alternatives considered: 
- Block C2 at firewall only (rejected: attacker might have other C2)
- Wait for more analysis (rejected: active threat too risky)
Impact: User mjohnson unable to work until remediation

Why document decisions:
- Accountability
- Learn from outcomes
- Defend choices later
- Train future responders

Key insight: Your notes are the organizational memory of the incident. Write as if someone else will need to understand everything in six months.

4) Incident Reports

Formal reports capture the complete incident story:

Incident Report Structure:

1. Executive Summary (1 page max)
   - What happened (one paragraph)
   - Impact (business terms)
   - Current status
   - Key recommendations

2. Incident Overview
   - Timeline summary
   - Systems affected
   - Data affected
   - Threat actor assessment

3. Technical Analysis
   - Attack vector
   - Techniques used (ATT&CK mapping)
   - Indicators of compromise
   - Forensic findings

4. Response Actions
   - Detection timeline
   - Containment measures
   - Eradication steps
   - Recovery actions

5. Impact Assessment
   - Business impact
   - Data exposure
   - Regulatory implications
   - Financial impact

6. Recommendations
   - Immediate actions
   - Short-term improvements
   - Long-term changes

7. Appendices
   - Detailed timeline
   - IOC list
   - Evidence inventory
   - Tool outputs

Writing for Different Audiences:

Executive Summary (for leadership):
- Business impact first
- No technical jargon
- Clear recommendations
- One page maximum

Example:
"On January 15, an employee clicked a phishing link that 
installed malware on their workstation. The malware was 
active for 4 hours before detection. Our investigation 
found no evidence of data theft, but the attacker had 
access to financial documents. We've contained the 
threat and are implementing additional email security 
controls to prevent similar incidents."

Technical Report (for security team):
- Detailed findings
- Specific techniques
- Exact IOCs
- Remediation steps

Legal/Compliance Report:
- Factual, objective language
- Evidence chain documented
- Regulatory requirements addressed
- Timeline precise

IOC Documentation:

IOC Report Format:

Type        | Value                        | Context
────────────────────────────────────────────────────────
IP          | 185.XX.XX.XX                | C2 server
Domain      | malicious-update[.]com      | Payload delivery
Hash (MD5)  | d41d8cd98f00b204e9800998ecf8427e | Malware dropper
Hash (SHA256)| a1b2c3...                  | Malware payload
Email       | attacker@phishing[.]com     | Phishing sender
URL         | hxxps://evil[.]com/payload  | Download URL
File Path   | C:\Windows\Temp\update.exe  | Malware location
Registry    | HKCU\Software\Microsoft\... | Persistence

Defang IOCs in reports:
- evil.com → evil[.]com
- https:// → hxxps://
- Prevents accidental clicks

Key insight: Reports are products. They should be clear, complete, and useful to their intended audience.

5) Post-Incident Activities

Learning from incidents prevents repetition:

Post-Incident Review (Lessons Learned):

Schedule: Within 1-2 weeks of incident closure
Attendees: All involved in response
Duration: 1-2 hours

Agenda:
1. Timeline review (what happened)
2. What worked well
3. What could improve
4. Action items

Key questions:
- How was the incident detected?
- Could we have detected it earlier?
- Was containment effective?
- Did we have the right tools/access?
- Was communication effective?
- What will we do differently?

Blameless Post-Mortems:

Focus on systems, not individuals:

Instead of:
"John should have caught this alert sooner"

Ask:
"Why did the alert not get prioritized?"
"What would have helped identify this faster?"
"How can we improve the process?"

Benefits:
- People share honestly
- Root causes identified
- Systemic issues fixed
- Culture of learning

Document improvements, not blame

Metrics and Reporting:

Post-incident metrics:

Detection metrics:
- Time to detect (how long was attacker active?)
- Detection source (what found it?)
- Detection method (alert, hunt, external?)

Response metrics:
- Time to respond (first action)
- Time to contain (bleeding stopped)
- Time to eradicate (threat removed)
- Time to recover (back to normal)

Impact metrics:
- Systems affected
- Data exposed
- Business downtime
- Financial impact

Track trends over time:
- Are we detecting faster?
- Are we responding better?
- Are similar incidents recurring?

Improvement Implementation:

Turn lessons into action:

Detection improvements:
- New alert rules
- Additional log sources
- Hunting queries
- Threat intel updates

Process improvements:
- Playbook updates
- Procedure clarifications
- Communication templates
- Escalation criteria

Technical improvements:
- Tool deployments
- Configuration changes
- Architecture updates
- Control implementations

Track implementation:
| Improvement | Owner | Due | Status |
|-------------|-------|-----|--------|
| Add PowerShell logging | IT | 1/30 | Done |
| Update phishing playbook | SOC | 2/1 | In Progress |
| Deploy email filtering | IT | 2/15 | Planned |

Key insight: Incidents that don't result in improvements are wasted pain. Extract maximum learning from every incident.

Real-World Context: Documentation That Matters

Documentation has real consequences:

Legal Proceedings: Incident documentation may be subpoenaed in lawsuits. Clear, factual, contemporaneous notes are credible. Vague, after-the-fact reconstruction is not.

Regulatory Inquiries: Regulators want to see that you responded appropriately. Documentation proves you followed procedures, made reasonable decisions, and acted promptly.

Insurance Claims: Cyber insurance claims require documentation of what happened, when, and what was done. Poor documentation can result in denied claims.

Organizational Learning: Without documentation, the same incidents repeat. With good documentation, each incident makes the organization more resilient.

Key insight: Documentation created under pressure, in real-time, is more credible than documentation created later. Build the habit of documenting as you go.

Guided Lab: Incident Documentation

Practice creating complete incident documentation.