14.3 Cloud Forensics: AWS CloudTrail, Azure Activity Logs & Multi-Tenant Evidence Collection

14.3 Cloud Forensics: AWS CloudTrail, Azure Activity Logs & Multi-Tenant Evidence Collection

Quick Answer: Cloud digital forensics differs fundamentally from on-premises investigations because the investigator lacks physical access to hardware. Evidence boundaries are defined by the Shared Responsibility Model: investigators control virtual disks and guest RAM in IaaS, but are limited to platform logs in PaaS, and provider-exposed APIs or compliance exports in SaaS. Cloud investigations rely heavily on audit logging infrastructure: AWS CloudTrail (tracking API actions, IAM identities, and source IPs in JSON), VPC Flow Logs (network traffic telemetry), Azure Activity Logs, and Microsoft Entra ID (Azure AD) sign-in logs. To preserve virtual machine storage, examiners isolate the instance via network security group quarantine, create an EBS snapshot, transfer the snapshot to a clean forensic account, and attach it read-only to a dedicated analysis instance.

---

The Cloud Shared Responsibility Model in Forensics

In cloud computing, legal jurisdiction, evidence custody, and data accessibility depend on the service architecture model defined by the National Institute of Standards and Technology (NIST SP 800-145).

+-------------------------------------------------------------------------+
|           FORENSIC RESPONSIBILITY & EVIDENCE COLLECTION MATRIX          |
+-------------------------------------------------------------------------+
| Layer / Asset          | IaaS (EC2/Azure VM) | PaaS (App Svc) | SaaS (M365) |
|------------------------|---------------------|----------------|-------------|
| Physical Facilities    | Cloud Provider      | Cloud Provider | Cloud Prov. |
| Physical Hardware/Host | Cloud Provider      | Cloud Provider | Cloud Prov. |
| Hypervisor Engine      | Cloud Provider      | Cloud Provider | Cloud Prov. |
| Guest Operating System | CUSTOMER / EXAMINER | Cloud Provider | Cloud Prov. |
| Volatile System RAM    | CUSTOMER / EXAMINER | Cloud Provider | Cloud Prov. |
| Persistent Disk Volume | CUSTOMER / EXAMINER | Cloud Provider | Cloud Prov. |
| Application Runtime    | CUSTOMER / EXAMINER | CUSTOMER/PROV. | Cloud Prov. |
| User Access / IAM      | CUSTOMER / EXAMINER | CUSTOMER/EXAM. | CUSTOMER    |
| Application Data Logs  | CUSTOMER / EXAMINER | CUSTOMER/EXAM. | CUSTOMER    |
+-------------------------------------------------------------------------+

1. Infrastructure as a Service (IaaS)

• Examples: Amazon EC2, Microsoft Azure Virtual Machines, Google Compute Engine.
• Forensic Control: Maximum customer control. The forensic examiner can capture volatile physical memory (using kernel drivers like LiME or WinPmem inside the guest OS), execute live triage, create volume snapshots of virtual block storage (AWS EBS, Azure Managed Disks), and configure network flow logging.
• Provider Boundary: The examiner has zero visibility into the underlying bare-metal server, physical NICs, or hypervisor host memory. Hardware write-blockers cannot be deployed.

2. Platform as a Service (PaaS)

• Examples: AWS Elastic Beanstalk, Azure App Service, Google App Engine, AWS Lambda.
• Forensic Control: Moderate control. The underlying operating system, hypervisor, and hardware are managed and secured by the cloud service provider (CSP). Examiners cannot image the virtual machine disk or dump operating system RAM.
• Forensic Sources: Investigations rely entirely on application execution logs, deployment history, web application server logs, platform metrics, and CSP audit events.

3. Software as a Service (SaaS)

• Examples: Microsoft 365, Google Workspace, Salesforce, Box.
• Forensic Control: Minimal direct control. The CSP manages the entire technology stack.
• Forensic Sources: Investigators possess no infrastructure access. Evidence collection is restricted to provider-exposed administrative audit logs, unified audit logs (e.g., Microsoft Purview Compliance Center), API event streams (e.g., Microsoft Graph API, Google Workspace Reports API), and eDiscovery legal export packages.

---

Forensic Challenges in Multi-Tenant Environments

Cloud investigations present technical, legal, and operational hurdles that do not exist in traditional on-premises forensics:

1. Multi-Tenancy & Co-Mingling of Evidence: In a multi-tenant cloud, dozens of separate corporate entities share the same physical server, storage array, and network switches. Physical seizure of a server is legally impossible because seizing the physical host violates the Fourth Amendment rights and privacy of unrelated third-party tenants.
2. Ephemeral Workloads & Volatility: Modern cloud deployments utilize containers (Docker, Amazon ECS/EKS, Kubernetes) and serverless functions (AWS Lambda). An ephemeral container may spin up, process an unauthorized request, exfiltrate data, and terminate within seconds, erasing all non-persistent memory and unmapped file system changes unless central logging was pre-configured.
3. Absence of Physical Access & Write-Blockers: Examiners cannot connect physical write-blocking bridges (e.g., Tableau, WiebeTech). Cryptographic integrity must be established through API-generated hashes and immutable snapshot policies.
4. Cross-Border Jurisdictional Complexity: A single cloud database may be sharded across data centers in the United States, Ireland, and Germany. Different jurisdictions enforce divergent privacy regulations (e.g., GDPR, CCPA). Legal cross-border acquisitions require navigating the CLOUD Act (Clarifying Lawful Overseas Use of Data Act) or processing Mutual Legal Assistance Treaties (MLAT).

---

Amazon Web Services (AWS) Forensics

AWS provides native logging and auditing services that form the foundation of cloud forensic investigations.

+-------------------------------------------------------------------------+
|                    AWS FORENSIC LOGGING ARCHITECTURE                    |
+-------------------------------------------------------------------------+
|                                                                         |
|  +------------------+         +------------------+                      |
|  |  AWS CloudTrail  |         |  VPC Flow Logs   |                      |
|  | (API Events, IAM |         | (Network Traffic |                      |
|  |  Logins, Actions)|         |  Telemetry: ENI) |                      |
|  +------------------+         +------------------+                      |
|           |                            |                                |
|           v                            v                                |
|  +-----------------------------------------------+                      |
|  |   Amazon S3 Centralized Forensic Repository   |                      |
|  |   • S3 Object Lock (Compliance Mode / WORM)   |                      |
|  |   • CloudTrail Digest File Integrity (SHA256) |                      |
|  +-----------------------------------------------+                      |
|                          |                                              |
|                          v                                              |
|  +-----------------------------------------------+                      |
|  |   Amazon Athena / OpenSearch / Splunk Triage  |                      |
|  |   (SQL Queries for Anomalous API Signatures)  |                      |
|  +-----------------------------------------------+                      |
+-------------------------------------------------------------------------+

1. AWS CloudTrail

CloudTrail is the primary forensic record of all API calls, AWS Management Console actions, and SDK commands executed across an AWS organization.

• Event Types:
  • Management Events (Control Plane): Record configuration and administrative operations, such as RunInstances, CreateUser, AttachVolume, and StopLogging.
  • Data Events (Data Plane): High-volume resource operations, such as S3 object-level APIs (GetObject, PutObject, DeleteObject) and AWS Lambda function executions. Disabled by default due to storage costs; critical for data exfiltration investigations.
• CloudTrail JSON Record Structure:

  {
    "eventVersion": "1.08",
    "userIdentity": {
      "type": "IAMUser",
      "principalId": "AIDAEXAMPLEUSERID",
      "arn": "arn:aws:iam::123456789012:user/compromised_admin",
      "accountId": "123456789012",
      "accessKeyId": "AKIAIOSFODNN7EXAMPLE"
    },
    "eventTime": "2026-09-22T14:12:00Z",
    "eventSource": "ec2.amazonaws.com",
    "eventName": "RunInstances",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "198.51.100.45",
    "userAgent": "aws-cli/2.13.0 Python/3.11.4",
    "requestParameters": {
      "instanceType": "c5.metal",
      "imageId": "ami-0c55b159cbfafe1f0"
    }
  }
  

• Log File Integrity Validation: CloudTrail uses cryptographic hashing to detect log tampering. It generates digest files containing SHA-256 hashes of every log file delivered over the preceding hour, signed with an RSA private key owned by AWS. Examiners validate log integrity using the AWS CLI:

  # Validate CloudTrail log file cryptographic integrity across an S3 bucket
  aws cloudtrail validate-logs \
    --trail-arn arn:aws:cloudtrail:us-east-1:123456789012:trail/ForensicTrail \
    --start-time 2026-09-20T00:00:00Z \
    --end-time 2026-09-22T23:59:59Z
  

2. Amazon VPC Flow Logs

VPC Flow Logs capture network traffic telemetry traversing Elastic Network Interfaces (ENIs) across a Virtual Private Cloud.

• Forensic Utility: Detects command-and-control (C2) communications, unauthorized lateral movement, data exfiltration channels, and port scanning.
• Standard Log Format: <version> <account-id> <interface-id> <srcaddr> <dstaddr> <srcport> <dstport> <protocol> <packets> <bytes> <start> <end> <action> <log-status>
• Sample Entry: 2 123456789012 eni-0a1b2c3d4e 10.0.1.50 198.51.100.45 49152 443 6 150 125400 1695391200 1695391260 ACCEPT OK
  • Protocol 6 = TCP. 125,400 bytes transmitted outward to external IP 198.51.100.45 over HTTPS port 443.
  • action: Evaluates to ACCEPT (permitted by security group/NACL) or REJECT (blocked by firewall rule).

3. Amazon GuardDuty & S3 Access Logs

• GuardDuty: An intelligent threat detection service utilizing machine learning and threat intelligence to analyze CloudTrail management logs, VPC Flow Logs, DNS logs, and EKS audit logs. Generates structured JSON findings (e.g., UnauthorizedAccess:EC2/SSHBruteForce, Recon:IAMUser/TorIPCaller).
• Amazon S3 Server Access Logs: Provides detailed records of every HTTP request made against an S3 bucket, logging requester identity, bucket name, request time, action (REST.GET.OBJECT), HTTP status code, and bytes transferred.

---

EBS Snapshot Acquisition & Forensic Isolation Pipeline

When an Amazon EC2 instance is suspected of compromise, investigators execute an isolated, non-destructive snapshot acquisition methodology.

+-------------------------------------------------------------------------+
|                    AWS FORENSIC EBS ACQUISITION PIPELINE                |
+-------------------------------------------------------------------------+
| 1. QUARANTINE INSTANCE: Apply Isolation Security Group (0 In/Out Rules) |
|    |                                                                    |
| 2. SNAPSHOT VOLUME: aws ec2 create-snapshot --volume-id vol-xxx         |
|    |                                                                    |
| 3. SHARE SNAPSHOT: Share snapshot to Dedicated Isolated Forensic Acct  |
|    |                                                                    |
| 4. CREATE FORENSIC VOLUME: Create EBS volume from snapshot in Sec Acct  |
|    |                                                                    |
| 5. ATTACH READ-ONLY: Attach to Forensic Analysis EC2 as /dev/xvdf       |
|    |                                                                    |
| 6. COMPUTE HASH & MOUNT: Compute sha256sum and mount read-only, noload  |
+-------------------------------------------------------------------------+

Step-by-Step Acquisition Workflow

# Step 1: Quarantine the suspect EC2 instance by swapping security groups
# (Quarantine SG contains 0 inbound rules and 0 outbound rules, cutting off C2)
aws ec2 modify-instance-attribute \
  --instance-id i-0123456789abcdef0 \
  --groups sg-00000000quarantine

# Step 2: Create a point-in-time snapshot of the root EBS volume
aws ec2 create-snapshot \
  --volume-id vol-0123456789abcdef0 \
  --description "Forensic Snapshot - Case 2026-14 - Suspect Instance Root Volume" \
  --tag-specifications 'ResourceType=snapshot,Tags=[{Key=CaseID,Value=CASE-2026-14}]'

# Step 3: Grant access to a separate, isolated forensic AWS account (Account ID: 999999999999)
aws ec2 modify-snapshot-attribute \
  --snapshot-id snap-0123456789abcdef0 \
  --attribute createVolumePermission \
  --operation-type add \
  --user-ids 999999999999

# --- [EXECUTE REMAINING COMMANDS INSIDE ISOLATED FORENSIC ACCOUNT] ---

# Step 4: Create a new EBS volume from the shared snapshot in the forensic availability zone
aws ec2 create-volume \
  --snapshot-id snap-0123456789abcdef0 \
  --availability-zone us-east-1a \
  --volume-type gp3

# Step 5: Attach the forensic volume to the forensic analysis workstation EC2
aws ec2 attach-volume \
  --volume-id vol-0987654321fedcba0 \
  --instance-id i-0forensicworkstation \
  --device /dev/xvdf

# Step 6: Compute raw cryptographic baseline hash on forensic workstation
sha256sum /dev/xvdf > /evidence/ebs_volume_sha256.txt

# Step 7: Mount the volume in read-only mode without replaying the filesystem journal
mount -o ro,noload /dev/xvdf1 /mnt/evidence_disk/

[!WARNING] Always specify the noload mount option (or ro,noload for ext4 / ro,norecovery for XFS) when mounting forensic volumes on Linux. Mounting standard journaling file systems without these flags causes the kernel to automatically replay pending journal transactions, writing metadata back to the evidence volume and destroying the cryptographic baseline hash!

---

Microsoft Azure & Google Cloud Forensics

1. Microsoft Azure Forensic Architecture

• Azure Activity Logs: Subscription-level logs recording Azure Resource Manager (ARM) events. Tracks who created, updated, or deleted resources (virtual networks, storage accounts, NSGs), service health incidents, and security alerts.
• Microsoft Entra ID (formerly Azure Active Directory) Logs:
  • Sign-In Logs: Critical for tracing identity-based attacks. Logs user principal names, IP addresses, client applications, conditional access evaluations, and Multi-Factor Authentication (MFA) outcomes.
  • Audit Logs: Tracks directory-level modifications: privileged role assignments (Global Administrator elevation), user account provisioning, application consent grants, and password resets.
• Azure Diagnostic & Monitor Logs: Captures resource-specific internal activity (e.g., Azure Key Vault secret access operations, Network Security Group [NSG] Flow Logs).
• Azure Blob Storage Forensics: Uses AzCopy or Azure CLI to export blobs for offline inspection. Blob versioning and immutable blob storage (WORM) preserve evidence against intentional overwrites.

2. Google Cloud Platform (GCP) Forensics

• Cloud Audit Logs:
  • Admin Activity Logs: Records operations that modify GCP resource configurations or metadata (e.g., creating a GKE cluster or modifying IAM policies). Immutable, enabled by default, and retained for 400 days at no cost.
  • Data Access Logs: Records API calls that read metadata or read/write user-provided resource data (e.g., querying a BigQuery dataset, reading a Cloud Storage object). Retained for 30 days by default.
  • System Event Logs: Records automated configuration events generated by GCP systems.
• VPC Flow Logs: Records network flow samples between Compute Engine instances and external IP addresses.

---

Cloud Evidence Preservation & Legal Holds

To ensure evidence survives court scrutiny under Federal Rule of Evidence 902(14) (Certified Records Generated by an Electronic Process):

1. IAM Credential Invalidation: Immediately revoke active sessions for compromised identities. In AWS, attach an inline DenyAll policy, execute aws iam update-access-key --status Inactive, and revoke temporary Security Token Service (STS) credentials by setting an explicit session revocation timestamp via PutUserPolicy.
2. Immutable WORM Storage (Write Once, Read Many):
   • AWS S3 Object Lock:
     • Compliance Mode: Guarantees that objects cannot be deleted or overwritten by any user, including the AWS account root user, for the duration of the retention period.
     • Governance Mode: Prevents deletion by standard users, but permits specific users with s3:BypassGovernanceRetention permissions to alter retention.
   • Legal Hold: Places an indefinite hold on specific S3 objects or Microsoft Purview eDiscovery records until explicitly lifted by corporate legal counsel.

---

Practical Forensic Case: Investigating Cloud Compromise via AWS CloudTrail

The Incident

An alert triggered when a financial enterprise's AWS monthly billing spiked by $45,000 overnight. An unknown actor had launched forty GPU-intensive p3.16xlarge EC2 instances across European and Asian regions.

Investigation & Log Analysis

1. CloudTrail Investigation: Examiners extracted CloudTrail logs via Amazon Athena, querying for RunInstances API calls across all regions.
2. Attribution & Credential Abuse:
   • eventName: RunInstances
   • userIdentity.arn: arn:aws:iam::555544443333:user/developer_sarah
   • sourceIPAddress: 185.220.101.5 (Tor Exit Node)
   • userAgent: Boto3/1.26.115 Python/3.10.8
3. Root Cause Discovery: Correlating previous events for developer_sarah revealed that three weeks earlier, an access key (AKIA...) was generated. A search on public code repositories uncovered that a contractor had accidentally committed this hardcoded AWS access key into a public GitHub repository.
4. Containment & Remediation: The incident response team terminated the unauthorized EC2 instances, deactivated the compromised access key, rotated all repository credentials, and enforced mandatory MFA across all IAM principals.