AWS Cloud Forensics: Investigating Security Incidents in AWS Environments

AWS cloud forensics works differently from traditional endpoint forensics in important ways. The traditional approach — acquiring a disk image, collecting memory dumps, examining process tables — applies to EC2 instances but is often unnecessary. AWS provides rich audit logs, immutable API call history, and metadata about every resource that ever existed in an account. These data sources often reveal the full picture of an incident without requiring access to instance-level artifacts.

Understanding the available evidence sources and how to query them efficiently determines whether a cloud forensics investigation takes 2 hours or 2 days.

Evidence Sources in AWS

CloudTrail: The primary evidence source for API-level activity. Every AWS API call — console actions, CLI commands, SDK calls, service-to-service calls — generates a CloudTrail event with the action, principal, timestamp, source IP, and affected resources. CloudTrail is the cloud equivalent of a process audit log and network log combined. Preserved for 90 days in CloudTrail Event History; longer if you've configured S3 delivery.

VPC Flow Logs: Network connection metadata for all ENI traffic. Reveals which IPs connected to which resources, port and protocol information, and data transfer volumes. Essential for understanding data exfiltration and lateral movement that doesn't appear in API logs.

CloudWatch Logs: Application and service logs. Lambda function output, ECS container logs, EC2 application logs shipped to CloudWatch, RDS audit logs. Contains application-layer events that don't appear in CloudTrail.

AWS Config: Configuration snapshots of AWS resources at points in time. Essential for answering "what was the configuration of this resource at time T?" — when was a security group rule added, when was an S3 bucket made public, what IAM policies were attached to a role before the incident.

S3 Access Logs: Object-level access to S3 buckets. Not enabled by default — must be configured per bucket. Essential for investigating S3 data access during an incident. CloudTrail data events for S3 provide similar (and often more detailed) information if enabled.

Investigation Methodology

A structured investigation methodology prevents missing evidence and ensures completeness:

Establish the timeline. Start by establishing when the incident began. For credential compromise, this is typically the first API call from an unusual source IP. For unauthorized resource creation, it's the CreateInstance or equivalent API call. Query CloudTrail filtered by the relevant principal and time range to build a chronological sequence of events.

-- Athena query: all actions by a specific access key in a 24-hour window
SELECT eventtime, eventname, awsregion, sourceipaddress, requestparameters
FROM cloudtrail_logs
WHERE useridentity.accesskeyid = 'AKIAIOSFODNN7EXAMPLE'
  AND eventtime >= '2026-07-22T00:00:00Z'
  AND eventtime < '2026-07-23T00:00:00Z'
ORDER BY eventtime;

Identify all affected resources. For each resource created or modified during the incident window, document the resource ID, type, region, and current state (still running, terminated, deleted). This inventory drives the eradication phase.

Determine data access scope. Query for GetObject, GetSecretValue, Decrypt, and similar data-access API calls. Determine whether any sensitive data (customer records, secrets, financial data) was accessed. This determination drives notification decisions.

Check for persistence mechanisms. Search for IAM changes (CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole), new EC2 instances with unusual user data, Lambda function creation, CloudFormation stack creation with backdoor resources. Attackers often establish multiple persistence mechanisms before being detected.

EC2 Instance Forensics

For incidents involving compromised EC2 instances, instance-level forensics may be needed to understand how malware operated or what data was accessed at the OS level. AWS forensic approach:

Snapshot before termination. Create an EBS snapshot of all volumes attached to the compromised instance before terminating it. The snapshot preserves the disk state for analysis. Store snapshots in an isolated forensics account to prevent contamination.

Memory capture (if needed). AWS doesn't provide direct memory dumping for EC2 instances. Options: use SSM Run Command to execute a memory capture tool on the instance while it's running (avwm fora, LiME for Linux), or use AWS Systems Manager to collect volatile data. This requires the SSM agent to be installed and the instance to still be running.

Forensic instance analysis. Mount the snapshot on a forensics EC2 instance in an isolated VPC. Analyze the filesystem using standard forensics tools: check bash history, cron jobs, user accounts, installed packages, and running services at the time of snapshot.

Evidence Preservation

Evidence preservation is required for legal proceedings and certain compliance frameworks. For AWS evidence:

CloudTrail logs: Export relevant log files from S3 to an isolated bucket with a legal hold (Object Lock). The exported logs include CloudTrail's log file integrity validation signatures, proving the logs haven't been modified since creation.

EBS snapshots: Create forensic snapshots with clear tagging indicating the incident context. Store in an isolated account. Note the timestamp, the instance ID, and the incident reference in the snapshot description.

Configuration state: Export AWS Config snapshots for affected resources to document their configuration at the time of the incident. Config timeline data shows configuration changes leading up to and following the incident.

Establish chain of custody documentation for any evidence that may be used in legal proceedings: who created the evidence artifact, when, what commands were run, and who has had access since creation.

GuardDuty and Detective Integration

AWS Detective automates much of the investigation work described above. Detective ingests CloudTrail, VPC Flow Logs, and GuardDuty findings and builds behavioral graphs that visualize entity relationships over time. When investigating a GuardDuty finding, clicking "Investigate in Detective" opens a pre-built investigation view showing all related entities (IP addresses, roles, instances) and their activity patterns.

Detective significantly reduces investigation time for complex incidents — instead of writing Athena queries to find all resources associated with a specific role, Detective's entity behavior graph shows them automatically. The service is most valuable for organizations that regularly investigate security incidents or want to reduce the time investment per investigation.

Related Reading

• AWS incident response plan — the process context for forensic investigation
• Account compromise response — applying forensics to the most common incident type
• CloudTrail forensic analysis — deep dive on CloudTrail investigation techniques
• VPC Flow Logs — network evidence collection for forensics

FAQ

How long are CloudTrail logs available for investigation?

CloudTrail Event History (accessible in the console) retains the past 90 days of management events. If you've configured CloudTrail to deliver logs to S3, logs are available as long as the S3 objects exist (subject to lifecycle policies). For forensics purposes, configure S3 lifecycle policies that retain CloudTrail logs for at least 1 year, with Glacier archival for years 2-7 to meet common regulatory retention requirements.

Can I trust that CloudTrail logs haven't been tampered with?

CloudTrail log file integrity validation creates cryptographic hash chains that allow detection of tampering. Each log file's SHA-256 hash is recorded in a digest file, and digest files are chained together. If any log file is modified or deleted, the integrity validation process detects the gap or hash mismatch. Use the aws cloudtrail validate-logs command to verify integrity before using logs as evidence in legal proceedings.

Is there a way to speed up CloudTrail log analysis without Athena setup?

CloudTrail Event History in the console supports filtering by event name, username, resource name, and time range — sufficient for quick investigations. CloudTrail Lake provides a managed event data store that supports SQL queries without the Athena setup overhead. For organizations that do incident investigations regularly, CloudTrail Lake's faster query interface and longer default retention (7 years) may justify its cost over the DIY Athena approach.