Volatile Evidence Acquisition in Cloud Environments

Volatility Order in Cloud Forensics

RFC 3227 (Guidelines for Evidence Collection and Archiving, IETF 2002) established the order of volatility for digital evidence: collect the most volatile evidence first. In cloud environments, this order applies but with cloud-specific items added.

Cloud volatility order (most to least volatile):

Priority	Evidence Type	Lifetime	How to Capture
1	Memory (RAM) contents	Destroyed on instance stop	Live memory dump (see below)
2	Running processes, open connections	Destroyed on instance stop	SSM Run Command + ps, netstat
3	Instance metadata	Available until termination	IMDS query during live session
4	Temporary files in /tmp	Destroyed on instance stop	SSM Run Command + find /tmp
5	Application logs in /var/log	Survive termination if EBS-backed, destroyed if instance store	Copy to S3 immediately
6	EBS volume content	Persists as snapshot after termination	Take EBS snapshot before isolation
7	CloudWatch Logs	Configurable retention (1 day–10 years)	Export to forensic S3 bucket
8	CloudTrail logs	90 days by default; 180 days with S3 retention	Copy to forensic S3 bucket
9	S3 objects	Persist until deleted	Copy to forensic S3 bucket with Object Lock
10	Billing records	12+ months	Export from Cost Explorer

Live Memory Acquisition

Memory forensics in cloud environments is limited — you cannot attach a USB memory forensics device to an EC2 instance. Options:

Option 1: LiME via SSM Run Command

LiME (Linux Memory Extractor) is a loadable kernel module that dumps physical memory to a file or network socket. Deploy via AWS Systems Manager Run Command (no SSH required):

# SSM document to capture memory
aws ssm send-command \
  --instance-ids i-INSTANCEID \
  --document-name "AWS-RunShellScript" \
  --parameters commands='[
    "insmod /tmp/lime-5.10.0.ko path=/tmp/memory.lime format=lime",
    "aws s3 cp /tmp/memory.lime s3://ir-forensics-bucket/memory/instance-i-INSTANCEID-$(date +%s).lime",
    "sha256sum /tmp/memory.lime > /tmp/memory.lime.sha256",
    "aws s3 cp /tmp/memory.lime.sha256 s3://ir-forensics-bucket/memory/"
  ]'

LiME must be pre-compiled for the specific kernel version running on the instance. Maintain a library of LiME modules for all AMI kernel versions in use.

Option 2: Analyse Process Memory via /proc

When loading a kernel module is not possible, user-space memory for specific processes can be captured via /proc:

# Get PID of suspicious process
ps aux | grep suspicious

# Dump memory maps for PID 1234
cat /proc/1234/maps > /tmp/proc_1234_maps.txt

# Dump memory segments (requires root)
for mem in $(awk '{print $1}' /proc/1234/maps | grep -v '\['); do
  start=$(echo $mem | cut -d'-' -f1)
  end=$(echo $mem | cut -d'-' -f2)
  dd if=/proc/1234/mem bs=1 skip=$((16#$start)) count=$((16#$end - 16#$start)) \
     of=/tmp/mem_${start}_${end}.bin 2>/dev/null
done

Live Network State Capture

Before isolating a compromised instance, capture its network state:

# Established connections (which external IPs is the instance talking to?)
ss -tunap

# Network interface configuration
ip addr show
ip route show

# ARP table (identifies other hosts the instance communicated with locally)
arp -n

# Open listening ports (what services is the attacker running?)
ss -tlnp

These commands execute in under 1 second and capture the network state at a specific moment. Run them via SSM Run Command to avoid alerting the attacker (if an active session exists).

EBS Snapshot Before Isolation

Before applying the quarantine Security Group, take an EBS snapshot:

# Get EBS volume IDs for the instance
aws ec2 describe-instances --instance-ids i-INSTANCEID \
  --query 'Reservations[*].Instances[*].BlockDeviceMappings[*].Ebs.VolumeId'

# Create snapshot
aws ec2 create-snapshot \
  --volume-id vol-VOLUMEID \
  --description "Forensic snapshot: incident-2024-0703 pre-isolation"

# Tag the snapshot for evidence tracking
aws ec2 create-tags \
  --resources snap-SNAPSHOTID \
  --tags Key=ForensicEvidence,Value=incident-2024-0703 \
         Key=CollectedBy,Value=investigator-email \
         Key=CollectedAt,Value=$(date -u +%Y-%m-%dT%H:%M:%SZ)

Container and Serverless Evidence

ECS/Fargate containers:

• No persistent storage to snapshot
• Container logs in CloudWatch Logs are the primary evidence source
• Container image (ECR) can be pulled and analysed for malware
• If ECS Task was attached to an EFS volume, mount and snapshot the EFS

Lambda functions:

• Function code can be downloaded: aws lambda get-function --function-name NAME
• Execution logs in CloudWatch Logs (max retention configured by owner)
• X-Ray traces (if enabled) provide execution timeline
• Environment variables visible in function configuration (document these before any change)
• Lambda layers can contain malicious code — download and hash all layers

Ephemeral Resources: The Race Against Termination

Auto-scaling groups terminate instances based on health checks and scaling policies — without regard to whether forensic investigation is in progress. When responding to an incident on an auto-scaled instance:

1. Immediately remove the instance from the auto-scaling group:

aws autoscaling set-instance-protection \
  --instance-ids i-INSTANCEID \
  --auto-scaling-group-name MY-ASG \
  --protected-from-scale-in

2. Suspend Auto Scaling for the group (if the entire fleet is compromised):

aws autoscaling suspend-processes \
  --auto-scaling-group-name MY-ASG \
  --scaling-processes Terminate

This buys time for evidence collection before auto-scaling terminates the instance.