4.1 Forensic Artifact Capture & Chain of Custody

4.1 Forensic Artifact Capture & Chain of Custody

Cloud incident response and digital forensics diverge fundamentally from traditional on-premises investigations. In an on-premises data center, digital forensic examiners often pull physical power cables to freeze machine state, connect hardware write-blockers to physical hard drives, or inspect network taps. In Amazon Web Services (AWS), the underlying physical infrastructure is managed entirely by AWS under the Shared Responsibility Model. Responders cannot physically access hypervisors, server chassis, or physical storage arrays. Instead, cloud forensics operates programmatically through software-defined application programming interfaces (APIs), hypervisor-level snapshotting, and managed orchestration services.

Executing forensic investigations in the cloud requires rigorous adherence to forensic science standards, specifically the RFC 3227 Order of Volatility, while preserving an unbroken, legally defensible chain of custody. A single misstep—such as prematurely rebooting an Amazon EC2 instance or using an interactive SSH session—can destroy vital volatile memory artifacts, alter disk access timestamps, and invalidate evidence in legal proceedings.

---

The RFC 3227 Order of Volatility in AWS

RFC 3227 (Guidelines for Evidence Collection and Archiving) establishes the principle that digital evidence must be captured starting with the most volatile data sources and proceeding to the least volatile. In AWS environments, the order of volatility maps directly to cloud primitives:

Exam Tip: The AWS Certified Security – Specialty exam frequently presents scenarios where an EC2 instance is suspected of being compromised or running cryptomining malware. Questions will offer options to immediately stop (ec2:StopInstances), reboot, or terminate the instance. Never choose to stop, reboot, or terminate an instance before capturing volatile RAM. Stopping an EC2 instance immediately purges the hypervisor-allocated physical memory, permanently destroying unencrypted encryption keys, running malware binaries injected into process memory, and active network connections.

---

Volatile Data Acquisition: Live Memory Capture Mechanics

Capturing the physical memory (RAM) of an EC2 instance running in production presents a technical challenge: how do responders acquire memory without altering the target system?

The Problem with Interactive Logins (SSH / RDP)

Connecting interactively to a compromised machine via SSH or Windows Remote Desktop (RDP) introduces severe forensic contamination:

• Spawns interactive shells (e.g., bash, powershell.exe), altering memory tables and overwriting processor registers.
• Modifies access and change timestamps (atime, ctime) across system directories.
• Appends commands to .bash_history or Windows Event Logs, potentially tipping off an adversary who may have active persistence or anti-forensic wiper scripts configured to execute upon administrative login.
• Allocates memory pages that overwrite the very memory space where malware or cryptographic keys reside.

Non-Interactive Acquisition via AWS Systems Manager Run Command

To minimize forensic footprint and eliminate the need for open administrative network ports (such as TCP port 22 or 3389), security teams use AWS Systems Manager (SSM) Run Command.

Loading diagram...

SSM Run Command communicates with the pre-installed SSM Agent daemon over an outbound HTTPS channel (TCP port 443) via AWS PrivateLink VPC endpoints. This architecture allows command execution even after an instance has been isolated from the public internet.

Memory Acquisition Tooling: LiME and WinPmem

1. Linux Systems (LiME - Linux Memory Extractor): LiME is an open-source kernel module that allows volatile memory acquisition from Linux-based devices. Because LiME operates inside kernel space, it minimizes interaction with user space processes. Pre-compiled LiME kernel modules matching the exact target kernel version (e.g., Amazon Linux 2, Amazon Linux 2023, Ubuntu, RHEL) can be retrieved from a central, read-only S3 repository and loaded via insmod. The memory dump can be written in raw or LiME format to a secondary, dedicated forensic EBS volume, or sent over a network socket (LiME's tcp: output) to a collection host, and then uploaded to Amazon S3.
2. Windows Systems (WinPmem): WinPmem is an open-source physical memory acquisition driver and executable for Windows. It provides a read-only view of physical RAM through an acquisition driver, writing raw memory images (.raw or .dmp) directly to a storage target without requiring interactive desktop sessions.

Evidence-Volume Pipeline

Rather than saving a 64 GB or 128 GB memory dump to the compromised root volume (which would alter disk structures, overwrite deleted unallocated space, and potentially run out of disk space), the acquisition script writes the image to a separately attached evidence volume (or a network listener), hashes it, and then uploads it to Amazon S3:

# Example conceptual snippet executed non-interactively via SSM Run Command
# Loads LiME, writes the image to a separately attached evidence volume
# (/mnt/evidence, not the suspect root disk), then hashes and uploads it
insmod /mnt/evidence/lime-<kernel-release>.ko "path=/mnt/evidence/ram.raw format=raw"
sha256sum /mnt/evidence/ram.raw > /mnt/evidence/ram.raw.sha256
aws s3 cp /mnt/evidence/ram.raw s3://forensic-evidence-vault-111122223333/case-9021/ram.raw \
    --sse aws:kms \
    --sse-kms-key-id arn:aws:kms:us-east-1:111122223333:key/abc-123

---

Automated EBS Snapshot Creation and Isolation

Once volatile memory is captured, the next priority is acquiring the non-volatile block storage volumes (Amazon EBS) attached to the compromised instance. EBS snapshots provide block-level, point-in-time, crash-consistent copies of EBS volumes backed by Amazon S3.

Crash-Consistent Multi-Volume Snapshots

Modern enterprise applications often stripe data across multiple EBS volumes (such as an OS volume, a transaction log volume, and a database data volume). Taking snapshots of individual volumes sequentially can introduce time skews, corrupting database consistency.

AWS provides the ec2:CreateSnapshots API (plural), which takes synchronized, multi-volume crash-consistent snapshots across all EBS volumes attached to an EC2 instance simultaneously. This guarantees that all snapshots share the exact same point-in-time boundary.

Forensic Tagging and Metadata Preservation

Snapshots must be tagged immediately upon creation to establish an auditable record:

{
  "IncidentId": "INC-2026-0929-A",
  "SourceInstanceId": "i-0a1b2c3d4e5f67890",
  "SourceVolumeId": "vol-0123456789abcdef0",
  "Custodian": "arn:aws:iam::111122223333:role/ForensicsOrchestratorRole",
  "AcquisitionTimestamp": "2026-09-29T14:30:00Z",
  "EvidenceClassification": "Confidential-Legal-Hold"
}

---

Automated Forensics Orchestrator for Amazon EC2

Manual forensic acquisition during an active security incident is prone to human error, delays, and accidental evidence corruption. The Automated Forensics Orchestrator for Amazon EC2 (built upon AWS Step Functions, AWS Lambda, Amazon EventBridge, and SSM) implements an automated, repeatable forensic pipeline:

Loading diagram...

Orchestration Steps

1. Trigger: An Amazon GuardDuty high-severity finding (e.g., Backdoor:EC2/C&CActivity.B!DNS) matches an EventBridge rule, passing the instance ID to AWS Step Functions.
2. Volatile Acquisition: Step Functions triggers an SSM Run Command document to extract RAM and volatile system artifacts directly to a centralized S3 evidence bucket.
3. Network Quarantine: The state machine swaps the instance's Security Groups to an isolated Quarantine Security Group.
4. Disk Snapshotting: The state machine invokes ec2:CreateSnapshots across all attached volumes.
5. Cross-Account Transfer: Snapshots are re-encrypted with a shared Customer Managed Key (CMK) and shared with the Forensics account.
6. Forensic Volume Reconstruction: In the Forensics account, an automated worker copies the snapshot, creates a new EBS volume, and attaches it as a non-boot secondary drive to an isolated forensic analysis workstation.

---

Cross-Account Snapshot Sharing and KMS Encryption Architecture

A critical requirement for secure investigations is moving evidence out of the compromised production account and into an isolated, air-gapped Forensics Account. This prevents an attacker who possesses administrative credentials in the production account from deleting snapshots, modifying forensic images, or monitoring the investigation.

However, EBS snapshot sharing across accounts is strictly governed by AWS Key Management Service (AWS KMS) cryptographic boundaries.

Loading diagram...

The Default AWS Managed Key (aws/ebs) Limitation

AWS encrypts EBS volumes by default using the AWS-managed key aws/ebs if no customer key is specified.

The Re-Encryption and Sharing Workflow

To successfully transfer an EBS snapshot to an isolated Forensics account, the following sequence must be followed:

1. Re-encrypt in Source Account (if encrypted with aws/ebs or unencrypted): Responders must copy the snapshot within the source account, specifying a Customer Managed Key (CMK): ec2:CopySnapshot --source-snapshot-id snap-111 --kms-key-id arn:aws:kms:region:source-account:key/cmk-shared.
2. Configure Cross-Account KMS Key Policy: The CMK's key policy in the source account must explicitly grant permissions to the Forensics account (or a specific IAM role within the Forensics account):

{
  "Sid": "AllowForensicsAccountToUseKey",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::222233334444:root"
  },
  "Action": [
    "kms:DescribeKey",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:CreateGrant"
  ],
  "Resource": "*"
}

1. Share the Snapshot: The source account grants volume creation permission to the Forensics account:

aws ec2 modify-snapshot-attribute \
    --snapshot-id snap-cmk-encrypted \
    --attribute createVolumePermission \
    --operation-type add \
    --user-ids 222233334444

1. Copy and Re-Encrypt in the Forensics Account: The Forensics account must immediately copy the shared snapshot into its own account, encrypting the copy with a local Customer Managed Key (CMK-Forensics-Local) owned exclusively by the Forensics account:

aws ec2 copy-snapshot \
    --source-region us-east-1 \
    --source-snapshot-id snap-cmk-encrypted \
    --destination-region us-east-1 \
    --kms-key-id arn:aws:kms:us-east-1:222233334444:key/cmk-forensics-local

Why Is the Destination Copy Mandatory?

If the Forensics account simply creates an EBS volume directly from the shared snapshot without copying it, the source account retains ultimate ownership of the underlying snapshot and the source KMS key. If an adversary in the production account deletes the snapshot or alters the KMS key policy, the forensic volume and ongoing analysis in the Forensics account are disrupted. Copying and re-encrypting the snapshot establishes independent legal custody.

---

Evidence Preservation in Amazon S3: Object Lock and Legal Holds

Forensic artifacts—including memory dumps, process trees, network packet captures (.pcap), and disk bit-stream images (.raw / .E01)—must be protected against tampering, overwriting, and deletion. Amazon S3 provides hardware-grade WORM (Write Once, Read Many) protection via S3 Object Lock.

Prerequisites for S3 Object Lock

• S3 Bucket Versioning: Must be permanently enabled. Object Lock operates by locking specific object versions.
• Enabling Object Lock: You can turn it on when you create a bucket or later on an existing bucket (Amazon S3 enables versioning for you). Once enabled, Object Lock cannot be disabled and versioning cannot be suspended.

Compliance Mode vs. Governance Mode

Exam Tip: For legal proceedings and forensic integrity, S3 Object Lock in Compliance Mode is mandatory. If an exam question asks how to guarantee that neither a rogue administrator, compromised root user credentials, nor an external adversary can delete forensic evidence during an ongoing investigation, the answer is always Compliance Mode.

S3 Legal Holds

In addition to retention periods (which expire after a defined duration, such as 7 years), S3 Object Lock provides a Legal Hold mechanism:

• A Legal Hold is an explicit binary toggle (ON / OFF) applied to an object version.
• It does not have an expiration date; it remains active until explicitly removed by an authorized principal possessing the s3:PutObjectLegalHold permission.
• A Legal Hold can be applied even if an object has no retention period or if its retention period has expired. This provides indefinite preservation while court litigation or regulatory inquiry is underway.

{
  "Status": "ON"
} 
// Applied via: aws s3api put-object-legal-hold --bucket forensic-vault --key case-9021/ram.raw --legal-hold Status=ON

---

Cryptographic Hash Verification & Chain of Custody

A legally defensible digital investigation requires proving that evidence presented during trial or an executive audit is an exact bit-for-bit duplicate of the data that existed on the compromised machine at the moment of acquisition.

Cryptographic Hashing Standards

Responders calculate cryptographic hashes (typically SHA-256) at each stage of the evidence lifecycle:

1. At Inception (Source Instance): When LiME streams memory or dcfldd / dd creates a disk image, the source tool computes a SHA-256 digest.
2. In S3 Vault: Amazon S3 natively supports checking object integrity using SHA-256 checksums (x-amz-checksum-sha256) uploaded in the request header, verifying that zero network transit corruption occurred.
3. In the Forensics Account: When the forensic image or cloned EBS volume is attached to the analysis workstation, the examiner recalculates the SHA-256 checksum and compares it against the recorded manifest.

Source Memory Capture SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Target Forensics S3 SHA-256:   e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Result: Bit-for-Bit Integrity Cryptographically Verified (Match)

The Chain of Custody Log

The chain of custody log is an auditable, tamper-resistant document that records:

• Identity of Custodian: IAM Role ARN, SAML Federation Identity, or responder name.
• Exact Timestamps: Coordinated Universal Time (UTC) timestamps of acquisition, transfer, and receipt.
• Source Resource Identifiers: AWS Account ID, Region, Instance ID, Elastic Network Interface (ENI) ID, Volume ID, and Snapshot ID.
• Tooling and Parameter Specifications: Exact version of LiME/WinPmem, kernel release version, command-line arguments.
• Cryptographic Hashes: Initial SHA-256 checksum, intermediate transfer hashes, and destination validation hashes.
• S3 Object Version ID and KMS Key ARN: Proving immutable location and cryptographic key custody.

---

Specialty Exam Pitfalls & Traps

1. Rebooting to "Clean Memory": Never reboot an instance to inspect it. Stopping or rebooting an EC2 instance flushes volatile memory and releases the underlying physical host allocation, erasing all RAM artifacts.
2. Attempting to Share Snapshots Encrypted with aws/ebs: Default AWS-managed KMS keys do not support cross-account sharing. Snapshots must be copied to a Customer Managed Key (CMK) before sharing.
3. Failing to Copy Shared Snapshots in the Destination Account: Sharing a snapshot grants the destination account read access, but the source account retains ownership. The destination account must copy the snapshot and re-encrypt it with its own CMK to preserve evidence if the source account deletes the original snapshot.
4. Confusing Governance Mode with Compliance Mode: Governance mode allows privileged users with s3:BypassGovernanceRetention to overwrite or delete objects. Only Compliance mode prevents all users, including the root user, from deleting evidence.
5. Interactive SSH Usage: Logging in via SSH or RDP pollutes RAM, alters system files, and updates access timestamps. Always prefer non-interactive execution via AWS Systems Manager Run Command.