AWS Cloud Forensics: Using AWS Services for Digital Investigations

Forensics starts before the incident

In a data center, an investigator can pull a disk from a server. On AWS, evidence lives in logs, snapshots and API records, and much of it only exists if someone turned it on beforehand. An investigation that starts with “we never enabled data events” or “the instance was terminated by Auto Scaling” has already lost evidence.

This post covers the three things to get right: the evidence sources to enable now, how to capture an EC2 instance without destroying volatile data, and how to preserve evidence so it stands up to scrutiny. The AWS Security Incident Response Guide is the reference to read alongside it.

Evidence sources to enable now

AWS CloudTrail

CloudTrail records API activity in your accounts. Event history is on by default but keeps only the last 90 days of management events in each Region, and it does not include data events. For investigations you need more:

• An organization trail (or CloudTrail Lake event data store) covering all accounts and Regions, delivered to a central log archive account.
• Log file integrity validation turned on, so you can show that delivered log files were not changed or deleted.
• Data events for sensitive resources, such as S3 object-level reads and writes on buckets that hold regulated data, and Lambda invocations where relevant. Data events are billed separately, so choose them deliberately.

VPC Flow Logs

VPC Flow Logs record metadata about IP traffic to and from network interfaces: source and destination addresses, ports, protocol, bytes, and whether traffic was accepted or rejected. They do not capture packet contents. Enable them at least on VPCs that host production workloads, and send them to a central S3 bucket. If you need packet contents for a specific investigation, VPC Traffic Mirroring can copy traffic from an elastic network interface to an analysis appliance.

Amazon S3 server access logs

Server access logs record requests made to a bucket. AWS delivers them on a best-effort basis, so they are useful context but not a complete record. For a complete, reliable record of object-level API activity, use CloudTrail data events.

Service and application logs

Load balancer access logs, Amazon CloudFront logs, AWS WAF logs, Amazon Route 53 Resolver query logs, Amazon EKS audit logs and your own application logs often answer the questions CloudTrail cannot, such as which request or user session triggered an action. Set retention on each so the evidence is still there months later.

Amazon GuardDuty and Amazon Detective

Amazon GuardDuty analyzes CloudTrail events, VPC Flow Logs and DNS logs, among other sources, to detect suspicious activity and generate findings. Its Malware Protection for EC2 feature can scan the EBS volumes attached to an instance, either automatically when a finding suggests malware or on demand, and can be configured to retain the snapshots when malware is found.

Amazon Detective builds a behavior graph from CloudTrail, VPC Flow Logs and GuardDuty findings, with up to a year of historical event data. It helps answer scoping questions: which roles this IP address used, what else this instance talked to, and whether this API call is unusual for this principal. Enable both through a delegated administrator account in AWS Organizations so coverage includes every member account.

Set up a forensics account

AWS guidance recommends a dedicated forensics account, separate from production and from the log archive, where evidence is copied and analyzed. It should:

• Be reachable only by the incident response team, through roles with tightly scoped permissions.
• Hold an evidence bucket with S3 Versioning and S3 Object Lock enabled.
• Contain prebuilt analysis instances (an AMI with your forensic tools) in an isolated VPC with no route to the internet.
• Own the AWS KMS customer managed keys used to encrypt evidence.

Build this account before you need it. Setting it up during an incident wastes the hours when evidence is easiest to collect.

Capturing an EC2 instance

When an instance is suspected of compromise, the order of operations matters. A typical sequence:

1. Protect the instance from automation. Enable termination protection, detach it from its Auto Scaling group, and deregister it from load balancer target groups so it is not replaced or terminated.
2. Capture memory first. Memory holds running processes, network connections, encryption keys and malware that never touches disk. The AWS Security Incident Response Guide says to capture memory before isolation or shutdown, because those steps can destroy volatile data. Use a memory acquisition tool you have tested in advance, run it through AWS Systems Manager Run Command or a prepared script, and write the image straight to the evidence bucket rather than to the instance’s own disk.
3. Isolate the instance. Replace its security groups with an isolation security group that allows only the access your responders need. Be aware that security group changes do not always cut existing tracked connections immediately, so add network ACL rules if you need to stop established traffic.
4. Snapshot every EBS volume. EBS snapshots capture data written to the volume, not data held only in memory, which is why step 2 comes first. Tag each snapshot with the case ID, instance ID, time and who took it.
5. Share or copy the snapshots to the forensics account. You cannot share snapshots encrypted with the default AWS managed key, so copy them with a customer managed key and share that key with the forensics account.
6. Analyze copies, not originals. In the forensics account, create volumes from the snapshots and attach them read-only to an analysis instance. Keep the original snapshots untouched.

Collect instance metadata as well: the instance profile, security groups, network interfaces, AMI ID, launch time and recent console output. AWS publishes Guidance for Automated Forensics Orchestrator for Amazon EC2 and EKS, with sample code that automates much of this sequence.

Preserving evidence in Amazon S3

New S3 buckets have ACLs disabled by default: Object Ownership is set to Bucket owner enforced, and access is controlled by bucket policies and IAM. Keep it that way for evidence buckets, and write a bucket policy that allows only the forensics roles.

S3 has no bucket snapshots. To make evidence tamper-resistant, use S3 Versioning and S3 Object Lock, which stores objects in a write-once-read-many (WORM) model:

• Compliance mode prevents any user, including the root user, from deleting or overwriting a locked object version until its retention period ends. Use it for evidence that must not change.
• Governance mode blocks deletion except by users with the s3:BypassGovernanceRetention permission. Use it while you test retention settings.
• Legal hold protects an object version with no end date until someone with permission removes it, which suits evidence tied to an open case.

Object Lock requires versioning, and it protects specific object versions; a simple delete only adds a delete marker on top.

Chain of custody

Technical controls make evidence trustworthy; documentation makes it usable. For each item, record what it is, where it came from, when and by whom it was collected, and every access since. Practical steps:

• Calculate a hash (for example SHA-256) of each memory image and exported file at collection time, and store the hashes separately.
• Use tags and a case log to link snapshots, objects and findings to the case ID.
• Rely on CloudTrail in the forensics account to show who accessed which evidence and when.
• Involve your legal team early if the investigation may lead to litigation or law enforcement.

Working with 9Acts

9Acts is an AWS Advanced Tier Services Partner and holds the AWS Level 1 MSSP Competency. If you want to prepare your AWS environment for incident response before you need it, see our security and compliance service.