Guest Blogger: Aditya Srikar Konduri

When learning memory forensics, many guides show you how to snapshot RAM from desktops and extract volatile artifacts from familiar endpoints. But step into the world of modern cloud deployments, and “memory acquisition” takes on new, urgent complexity. The traditional processes we were taught walk up, image the device, analyze the dump rarely apply in environments run by APIs, ephemeral VMs, and containers spun up and destroyed in seconds. In my incident response experience and research, the single most decisive factor in cloud forensics is whether you can preserve live evidence before it vanishes. Here, I’ll walk through real-world cloud and container scenarios, with a pragmatic lens for the decisions that every modern DFIR analyst faces.

The Cloud VM Incident: Memory Acquisition in AWS

Several high-impact attacks hit AWS EC2 environments in the wild, often leveraging weak AWS credentials to deploy crypto-mining malware or exfiltrate sensitive data. In one such public case, incident responders first observed the classic signs: unexpected compute spikes, network traffic to mining pools, and compromised IAM roles. At this point, legacy workflows would have stopped at the EBS volume, taking a disk snapshot via the AWS console or CLI, then launching it in isolation for disk-level forensics.

Disk alone rarely tells the whole story, especially in memory-resident attacks. To catch credential dumping, fileless malware, or lateral movement beacons, responders have to capture process memory. Tools like MargaritaShotgun or Volatility-ready memory capture agents can be deployed into the running EC2 instance. First, responders elevate privileges, either by leveraging their own IR or forensic account, or in some cases working with the cloud provider to gain snapshot permissions. Then, using the MargaritaShotgun script, they invoke AWS APIs to remotely dump the memory of the instance, without ever logging in interactively.

This remote acquisition, with minimal system disturbance, captures volatile footprints: PowerShell commands containing plaintext credentials, injected code segments, and the in-memory configuration of the mining malware. Memory analysis using tools like Volatility or Rekall exposes not just the initial compromise but secondary attack tools staged in memory, tools designed to pivot into associated IAM roles and S3 buckets. Ultimately, it is the RAM evidence, not the disk alone, that maps the attacker’s persistence and the genuine breadth of the breach. Direct evidence changes the scope of the investigation and escalates the response from a single compromised server to a cross-account incident.

Real-World Container Forensics: Preserving the Ephemeral

Consider containers, a major blind spot for traditional forensics. In a Kubernetes security team’s documented investigation, the alert was subtle, a container exhibiting burst outbound connections and privilege escalation behavior. Since container filesystems are frequently overlays and could be ephemeral, classical acquisition techniques would have lost nearly all relevant evidence once the incident response playbook called for “kubectl delete pod.”

Responders leaned heavily on Kubernetes’ advanced checkpoint and restore support, paired with CRIU (Checkpoint/Restore In Userspace). Instead of terminating the suspicious container, they first checkpoint it, freezing the running state, memory pages, open file descriptors, and the process tree into a storable snapshot. Memory and process dumps are preserved before the orchestrator moves to evict or redeploy the pod.

Locally, investigators unmarshall these memory images with Volatility and manual inspection. They recover plaintext secrets, evidence of runtime abuse, and shellcode none of which exist on disk overlays. The process also captures system calls and vectorized activity trails not visible via logs alone. Afterwards, the affected node is isolated for exhaustive analysis. It is only thanks to prior memory checkpointing that the full attack sequence can be reconstructed. Cloud-native forensics hinges on decision speed: responding before ephemeral evidence is forever wiped.

Lessons for the DFIR Practitioner

Both cases, cloud VM and container, highlight a fundamental truth. In modern, distributed environments, volatile memory forensics is both technically possible and tactically essential, but only with the right orchestration, tool selection, and awareness of native platform APIs. AWS-specific tools like MargaritaShotgun, Azure’s Diagnostic Extensions, and GCP’s forensic snapshot scripts should be part of every cloud IR toolkit. For containers, mastery of Kubernetes checkpointing, CRIU, and memory introspection utilities closes the evidence gap and gives responders direct access to what runtime attackers hoped to hide.

Modern incident response is a race against time and automation, the first minutes of a cloud or container incident, before pods are recycled or VMs terminated, often decide whether investigators can work from direct evidence or must rely on fragments and inference. Integrating automated memory acquisition into SIEM and SOAR workflows, and routinely testing these playbooks, is the clearest way to ensure that in your next investigation, volatile evidence will not slip into digital oblivion. 

References and Further Reading:

• MargaritaShotgun (AWS):
  An open-source, cloud-native toolkit widely adopted for remote memory acquisition in AWS EC2. It leverages AWS APIs to quickly collect process memory while minimizing forensic disturbance. Useful link:

https://github.com/ThreatResponse/margaritashotgun

• Volatility and Rekall:
  Industry-standard frameworks for analyzing raw memory images and identifying malware, injected code, and credential theft. Both support Linux, Windows, and cloud-acquired memory dumps.
  https://www.volatilityfoundation.org/

Rekall Cheat Sheet | SANS Institute

• CRIU (Checkpoint/Restore In Userspace):
  Used in Linux environments (especially with containers), CRIU can freeze and restore running processes, including memory state. Kubernetes natively supports CRIU as part of Pod checkpointing—essential for ephemeral evidence preservation.

https://criu.org/Main_Page

• AWS Forensic Investigation Reference:
  AWS official blog, “Forensic investigation environment strategies in the AWS Cloud”—details best practices for disk and memory acquisition, incident playbooks, and chain of custody in cloud contexts.
  ​
• Kubernetes Forensic Container Analysis:
  Official documentation and recent security blogs (Sysdig, Kubernetes) present case studies for memory dumps, container introspection, and runtime checkpointing for forensic investigations.
  ​
• Azure, GCP Forensics:
  • Azure Diagnostics Extension can retrieve VM state and perform live debugging or memory collection with privileged access.
  • GCP Compute Engine supports forensic snapshotting of both disk and, with some scripting, volatile RAM states.

Tool Summaries

• AWS MargaritaShotgun
  • Automates memory acquisition for live EC2 instances using IAM roles and SSM (Systems Manager).
  • Can collect memory for any compatible Linux AMI (Amazon Machine Image), ideal for quick response on compromised hosts.
• Volatility/Volatility3
  • Parses memory images from cloud and on-prem systems.
  • Offers extensive plugins: dump passwords, enumerate processes, and flag indicators of compromise.
  • Integrates with cloud workflows by supporting raw, compressed, and converted memory dump formats.
• CRIU for Containers/Kubernetes
  • Used with Docker and Kubernetes to create checkpoints before container stop/recycle.
  • Preserves full process state, memory, and open file handles.
  • Essential in dynamic orchestration environments, with growing integration in enterprise security suites.
• Azure VM Extensions
  • Memory acquisition via the diagnostics extension or VM Access Extension, used for live debugging and forensic snapshotting.
• Google Cloud Forensics
  • Custom scripts and third-party tools can snapshot disk, collect running process lists, and extract in-memory artifacts.
  • Security teams are encouraged to automate evidence collection via Cloud Functions or Pub/Sub triggers.