3.2.1. Capturing Forensic Artifacts

First Principle: Forensic evidence is volatile and perishable. The first action in any incident response must be capturing evidence before it disappears — terminated instances lose RAM, rotated logs are overwritten, and attackers actively destroy their tracks.

What to Capture (In Priority Order):

1. EBS Snapshots — Full disk image of compromised instances. Create BEFORE any other action.
2. Memory Dump — RAM contents including running processes, network connections, and encryption keys in memory. Requires SSM Agent or memory capture tool.
3. CloudTrail Logs — API call history showing attacker actions. Already stored in S3 (if Trail is configured).
4. VPC Flow Logs — Network metadata showing communication patterns. Already streaming (if enabled).
5. Instance Metadata — Security groups, IAM role, user data, tags. Query via describe-instances.

Evidence Preservation Best Practices:

• Snapshot to a forensic account — Copy EBS snapshots to a dedicated forensic account that the attacker can't access
• Enable Object Lock on evidence buckets — Prevent anyone (including admins) from deleting or modifying stored evidence
• Tag evidence — Mark snapshots and logs with incident ID, timestamp, and chain-of-custody metadata
• Hash everything — SHA-256 hashes of evidence files establish integrity for legal proceedings

⚠️ Exam Trap: NEVER terminate a compromised EC2 instance before capturing an EBS snapshot and memory dump. Termination destroys volatile evidence. Isolate with a security group swap (block all traffic) instead.

Scenario: An EC2 instance is confirmed compromised. Your automated workflow: (1) applies a quarantine security group allowing no traffic, (2) creates EBS snapshots of all attached volumes, (3) executes SSM Run Command to capture a memory dump to S3, (4) copies snapshots to the forensic account.

Reflection Question: Why is the quarantine-then-capture sequence critical, and what specific evidence would be lost if you terminated the instance immediately?