9.3 Cloud Incident Containment, Snapshot Forensics, and Container Security

Cloud Incident Containment, Snapshot Forensics, and Container Security

Containing security incidents in public cloud environments presents fundamentally different operational requirements compared to traditional on-premises forensics. In cloud environments, abruptly terminating a compromised virtual machine (AWS EC2, Azure VM, GCP Compute Engine) obliterates volatile memory (RAM), wipes ephemeral storage, and triggers auto-scaling groups to provision replacement instances, perpetuating the intrusion. Cloud containment and forensic investigation rely on software-defined network isolation, non-destructive snapshot acquisition, and specialized workflows for serverless and ephemeral container architectures.

Cloud Containment Playbooks: Virtual Machines and Identities

Incident responders execute coordinated containment playbooks across both virtual compute workloads and cloud identity services:

• Host Isolation via Layered Network Controls: Rather than powering down a compromised virtual machine, responders can attach a dedicated quarantine security group or Azure NSG that permits only approved forensic traffic. This blocks new flows while the machine remains running for volatile triage. AWS security groups are stateful, however, and changing a rule does not necessarily interrupt tracked connections immediately. If an active C2 channel must be cut at once, responders need a tested stateless control—such as an approved deny rule in the subnet network ACL—or another provider-supported isolation action, with scope and business impact assessed because a subnet ACL can affect other workloads.
• Detaching IAM Instance Profiles: Compromised virtual machines often execute with attached IAM roles (EC2 Instance Profiles or Azure Managed Identities) granting access to cloud resources. Threat actors exploit these roles to issue API calls against the cloud control plane. Handlers must immediately detach the instance profile or replace it with an empty IAM role containing an explicit Deny policy, preventing the host from accessing cloud storage or pivoting across accounts.
• Identity Revocation and Session Invalidation: Revoking compromised credentials requires addressing both static and temporary tokens:
  • Long-Lived Access Keys: For compromised IAM users, responders immediately change access key status to Inactive or delete the key, reset console passwords, and terminate active web sessions.
  • Temporary STS Credentials: Deleting an IAM access key does not invalidate temporary security tokens previously generated through sts:AssumeRole or federation. These tokens remain valid until their expiration timestamp. To revoke permissions from earlier role sessions, incident handlers can use the role's Revoke active sessions action or attach an equivalent inline policy containing an explicit Deny statement with an aws:TokenIssueTime condition (e.g., "Condition": {"DateLessThan": {"aws:TokenIssueTime": "2026-10-03T20:00:00Z"}}). After IAM policy propagation, this causes authorization to deny requests made with role sessions issued before the cutoff. Responders must verify the policy scope and effect rather than assume instantaneous global enforcement.

Forensically Sound Cloud Evidence Acquisition

Cloud infrastructure provides robust, API-driven evidence acquisition mechanisms that preserve chain of custody without physical media handling:

• Point-in-Time Disk Snapshotting: Cloud providers offer block-level snapshots (AWS EBS, Azure Managed Disk, and GCP Persistent Disk). A snapshot of a running volume is generally crash-consistent, not automatically application-consistent: cached writes and multi-volume transactions may be incomplete unless responders can safely quiesce the workload. Record the API request, account, region, volume identifiers, timestamps, and encryption context; copy the snapshot into an isolated account; and validate exported or mounted artifacts with cryptographic hashes. A snapshot preserves storage blocks, not volatile RAM.
• Cross-Account Isolation and Chain of Custody: If an adversary compromises the production cloud account, snapshots stored within that same account remain vulnerable to tampering or deletion. To ensure evidence integrity and establish a defensible chain of custody, incident handlers share the snapshot with a dedicated, isolated Forensic Investigation Account and copy it into that account. During the cross-account copy, the snapshot is re-encrypted using a new, isolated Customer Master Key (CMK) managed by AWS KMS accessible exclusively by forensic personnel.
• Forensic Workstation Analysis: In the isolated forensic account, responders create an EBS or managed disk volume from the secured snapshot and attach it as a secondary, non-boot data disk to an analysis instance (such as a SIFT Workstation). Crucially, attach the derived analysis volume as a secondary disk and prevent journal replay. For ext4, an example is mount -o ro,noload /dev/xvdf1 /mnt/evidence; XFS uses filesystem-specific options such as ro,norecovery. Work from a copied snapshot, document every transformation, and hash exported evidence. Read-only mounting reduces modification risk but does not by itself prove forensic integrity.

Serverless and Container Incident Response

Modern cloud-native workloads introduce distinct containment and forensic challenges:

• Serverless Architectures (AWS Lambda, Azure Functions): Serverless computing abstracts virtual infrastructure entirely. Functions execute within short-lived, stateless microVM containers terminating within seconds or minutes. Responders cannot dump physical memory or snapshot virtual disks. Incident response relies on centralized logging (CloudWatch Logs, Azure Monitor), tracking input payloads (API Gateway triggers), inspecting environment variables for leaked credentials, and examining temporary storage directories (such as /tmp in Lambda) where attackers stage payloads during execution.
• Container Threat Vectors and Escapes: Containerized environments (Docker and Kubernetes) introduce unique attack surfaces. Attackers exploit malicious public images, misconfigured Kubernetes RBAC roles, and vulnerable application dependencies. The most dangerous container threats involve Container Escapes, where an adversary breaks out of containerized isolation to gain host-level operating system control. Primary escape vectors include:
  • Exploiting shared Linux kernel vulnerabilities (e.g., Dirty COW, Dirty Pipe).
  • Exposed Docker Sockets: Containers configured with mounted host Docker sockets (-v /var/run/docker.sock:/var/run/docker.sock) enable an adversary inside the container to communicate directly with the host Docker daemon, creating privileged containers that compromise the entire host.
  • Excessive Linux Capabilities: Containers executed with the --privileged flag or granted dangerous capabilities like CAP_SYS_ADMIN or CAP_NET_ADMIN can manipulate cgroups, load malicious kernel modules, or bypass AppArmor and SELinux profiles.
• Ephemeral Container Forensic Triage: Because Kubernetes automatically terminates and replaces failing containers (CrashLoopBackOff), forensic evidence can vanish in seconds. When responding to container incidents, handlers must:
  1. Cordon the host node to prevent new pods from scheduling and, where the runtime and safety plan permit, pause the suspect container to stop execution while collection begins. Pausing does not create a memory image; responders still need a supported memory-acquisition method before the node or workload is destroyed.
  2. Capture live file modifications by running docker diff or copying the container upper read-write storage layer (OverlayFS) before termination.
  3. Extract process memory directly from the host operating system via /proc/<PID>/mem for the container isolated process, or use nsenter to execute forensic tools within the container namespaces.
  4. Audit Kubernetes API server logs to trace service account token abuse, unauthorized pod deployments, and cluster privilege escalation.