Cloud Forensics

Cloud Forensics is the process of collecting and analyzing evidence from cloud resources after a security incident. Unlike traditional forensics, cloud forensics works with API logs, metadata, and snapshots rather than physical hardware.

AWS Evidence Sources

• CloudTrail: who did what, when, from where (API calls)
• VPC Flow Logs: network traffic metadata (source, destination, ports, bytes)
• EBS snapshots: point-in-time disk images for offline analysis
• Memory dumps: using SSM to capture running memory from EC2 instances
• S3 access logs: who accessed which objects
• GuardDuty findings: correlated threat intelligence

The Forensics Workflow on AWS

The cloud changes the order of operations. On physical hardware you pull the plug and image the disk; on AWS the disk image is one API call away and the machine can keep running while you take it. A sound workflow looks like this: isolate the instance at the network layer (quarantine security group) without stopping it, snapshot every attached EBS volume, capture volatile data (memory, process list) if runtime evidence matters, and only then decide whether to terminate. Stopping or terminating first destroys memory and, for instance store volumes, the disk contents themselves.

Evidence handling discipline matters as much as collection. Tag snapshots with a case identifier at creation time, copy them to a dedicated forensics or security account so a compromised admin in the affected account cannot delete them, and keep CloudTrail as the chain-of-custody record: every snapshot, copy, and share operation is itself logged as an API call. CloudTrail's built-in event history covers the last 90 days; for anything older you need a trail configured to deliver to S3, which is why the trail belongs in your preparation checklist, not your response checklist.

How It Goes Wrong in Practice

The most common self-inflicted wound is evidence destruction by cleanup reflex. An on-call engineer sees a cryptomining process, terminates the instance, and the auto scaling group replaces it with a clean one. Business impact: resolved. Investigation: dead on arrival. The memory, the dropped binaries, the shell history, any instance store data, all gone, and with them the answers to "how did they get in" and "what else did they touch". The attacker's entry point is still there, so the miner is usually back within days. The correct sequence is contain, capture, then destroy.

The second pattern is discovering during an incident that the logs you need were never enabled. VPC Flow Logs, S3 server access logging or data event logging, and long-term CloudTrail delivery are all opt-in. Forensic readiness means turning them on before you need them and protecting the log destination from tampering.

Practical Check: Snapshot a Volume for Evidence

The core evidence-capture command, with tags applied at creation so the artifact is traceable from the moment it exists:

aws ec2 create-snapshot --volume-id vol-1234567890abcdef0 --description "IR case 2026-041 web-1 root volume" --tag-specifications 'ResourceType=snapshot,Tags=[{Key=case,Value=2026-041},{Key=hold,Value=true}]'

Only --volume-id is required. The output includes the SnapshotId and a State field (pending, then completed); the point-in-time capture is fixed when the call is made, even though the copy completes asynchronously. Pair it with CloudTrail history for the affected identity:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=web-app-role --start-time 2026-07-20T00:00:00Z --end-time 2026-07-26T00:00:00Z

Frequently Asked Questions

Should I stop the instance before taking a snapshot?

For forensics, no. An EBS snapshot can be taken while the instance runs, and stopping it destroys memory contents you may want to capture first. Isolate with a restrictive security group, snapshot, capture volatile data, then power down if needed.

How far back can I investigate API activity?

CloudTrail event history queried via lookup-events covers the last 90 days and is rate-limited to 2 requests per second per account per Region. Investigations older than that depend on a trail delivering to S3, or CloudTrail Lake, configured in advance.

Why copy evidence to a separate AWS account?

If the incident involves compromised credentials in the affected account, anything stored there can be deleted by the attacker or by well-meaning cleanup. A dedicated security account with tightly controlled access preserves integrity and supports a defensible chain of custody.

Do snapshots capture everything on the instance?

They capture attached EBS volumes at a point in time, nothing more. Memory contents, running processes, and instance store volumes are not included, which is why volatile data collection through SSM comes before shutdown, and why instance-store-backed workloads need a different evidence plan entirely.