Cloud Memory Forensics: Acquiring and Analysing Volatile Evidence from AWS EC2 Instances

When responding to a security incident involving a compromised cloud instance, disk images and log data tell part of the story. Memory tells the rest. Running processes, active network connections, injected code, encryption keys, and credential material exist only in volatile memory and are lost the moment an instance is stopped or terminated. In cloud environments where instances are routinely scaled, terminated, and replaced, the window to capture this evidence is narrow.

This article covers practical approaches to acquiring and analysing memory from AWS EC2 instances during incident response. The techniques discussed apply broadly to Linux-based cloud workloads, with specific focus on tooling that works within AWS infrastructure constraints.

Why Memory Forensics Matters in Cloud Incidents

Traditional forensics relies heavily on disk artefacts: filesystem timestamps, log files, persistence mechanisms, and deleted file recovery. In cloud environments, these artefacts are often incomplete. Ephemeral storage is lost on termination, EBS volumes may be encrypted with keys you need to recover, and attackers operating primarily in memory can leave minimal disk footprint.

Memory fills the gaps disk and logs can’t reach: running processes and their full command lines, including ones that have deleted their on-disk binaries; active and recent network connections, resolved DNS entries, and established C2 channels; loaded kernel modules, including rootkits hiding from userspace tools like lsmod or ps; injected code and hooked functions inside legitimate processes; and credential material, encryption keys, and secrets held in process memory or environment variables that exist nowhere on disk at all.

Its volatility means acquisition has to be prioritised early in the response timeline, ideally before any containment action that involves stopping or isolating the instance at the hypervisor level.

Memory Acquisition Techniques

Acquiring memory from a cloud instance requires getting an acquisition tool onto the target, executing it, and extracting the resulting dump, all while maintaining forensic integrity and minimising changes to the system under investigation. There are several approaches, each with trade-offs.

AWS Systems Manager (SSM)

AWS Systems Manager provides agentless-style remote command execution to EC2 instances that have the SSM Agent installed (included by default on Amazon Linux, Ubuntu, and most AWS-provided AMIs). For incident response, SSM is valuable because it does not require SSH access, does not depend on security groups allowing inbound connections, and all command execution is logged in CloudTrail.

SSM can be used to deploy a memory acquisition tool, execute it, and upload the resulting dump to S3 without opening any additional network paths to the instance.

# Step 1: Deploy AVML to the target instance via SSM
aws ssm send-command \
  --instance-ids "i-0abc123def456789" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=[
    "curl -L -o /tmp/avml https://github.com/microsoft/avml/releases/latest/download/avml",
    "chmod +x /tmp/avml"
  ]' \
  --comment "Deploy AVML for memory acquisition"

# Step 2: Execute memory capture and upload to S3
aws ssm send-command \
  --instance-ids "i-0abc123def456789" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=[
    "/tmp/avml --compress /tmp/memory.lime",
    "aws s3 cp /tmp/memory.lime s3://forensics-bucket/case-2026-001/memory.lime"
  ]' \
  --comment "Acquire memory and upload to S3"

Push to S3 with presigned URLs or temporary scoped-down keys rather than long-lived credentials baked into the SSM document.

The obvious dependency: the SSM Agent must actually be running on the target. If an attacker has killed it, or the instance has no outbound connectivity to the SSM endpoint, this approach is dead on arrival and you fall back to LiME, AVML over an existing shell, or EDR-based acquisition.

LiME (Linux Memory Extractor)

LiME is a loadable kernel module (LKM) that acquires memory by reading directly from /dev/mem or through the kernel’s page mapping interface. It has been the standard Linux memory acquisition tool for over a decade and produces output in its own LiME format or raw/padded formats compatible with most analysis tools.

# LiME must be compiled against the running kernel's headers
sudo apt-get install linux-headers-$(uname -r) build-essential
git clone https://github.com/504ensicsLabs/LiME.git
cd LiME/src
make

# Load the module to acquire memory
sudo insmod lime-$(uname -r).ko "path=/tmp/memory.lime format=lime"

LiME writes the dump directly to the specified path. The format=lime option includes memory range metadata that Volatility and other tools parse natively; format=raw produces a flat binary some workflows prefer. It’s well-understood, forensically sound, and supports output over TCP for remote collection without writing to local disk — advantages earned over a decade of being the default Linux acquisition tool.

The problem is cloud-specific: LiME needs kernel headers matching the running kernel version exactly, and on instances that auto-update or run custom AMIs, those headers often aren’t available. Compiling a kernel module also modifies the target system by loading packages and writing to disk, which cuts against forensic integrity. If you’re maintaining a pre-built response toolkit, that means compiling and storing a LiME module for every kernel version in your fleet — a maintenance burden that’s largely why AVML has taken over for cloud IR.

AVML (Acquire Volatile Memory for Linux)

AVML, developed by Microsoft, addresses many of LiME’s cloud-specific limitations. It is a statically compiled, standalone binary that does not require kernel headers or module compilation. It acquires memory by reading /proc/kcore (the kernel’s virtual memory exposed as an ELF core file) or falling back to /dev/crash and /dev/mem.

# Download the pre-built binary
curl -L -o avml https://github.com/microsoft/avml/releases/latest/download/avml
chmod +x avml

# Acquire memory with compression
sudo ./avml --compress output.lime

# Acquire and upload directly to Azure Blob or write locally
sudo ./avml output.lime

AVML produces LiME-format output by default and supports optional Snappy compression, which significantly reduces the size of the memory dump for transfer. A 16GB memory dump typically compresses to 2-4GB depending on memory utilisation.

As a single static binary with no dependencies and no kernel module to load, it works across kernel versions without recompilation — drop it on the instance and run it. This is generally the recommended tool for cloud incident response precisely because of that simplicity and portability, and it’s well suited to automated runbooks where you can’t guarantee kernel header availability across a fleet.

EDR-Based Acquisition

If the compromised instance is running an EDR agent, some platforms support remote memory acquisition or already collect memory-relevant telemetry. CrowdStrike Falcon supports full memory dump collection via Real Time Response, where the memdump command initiates acquisition straight from the Falcon console with no additional tooling. SentinelOne offers similar remote shell and collection capability through Deep Visibility, and Velociraptor, the open-source DFIR tool, has built-in memory acquisition artefacts and can orchestrate AVML or LiME deployment across a fleet.

Using existing EDR for acquisition is attractive because the agent is already deployed and authenticated. But if the instance is compromised at a level where the attacker has kernel access or has tampered with the EDR agent, that acquisition may not be trustworthy — in high-severity incidents, an independent acquisition method is preferable.

Memory Analysis

Once you have a memory dump, analysis tools parse the raw binary data into structured information: process trees, network connections, loaded modules, and extracted artefacts. The three primary tools for this work are Volatility 3, MemProcFS, and Volexity Volcano.

Volatility 3

Volatility is the industry standard open-source memory forensics framework. Version 3 is a complete rewrite from Volatility 2, with a plugin-based architecture and native support for Linux, Windows, and macOS memory analysis. It uses symbol tables (ISF files) generated from kernel debug symbols to parse memory structures.

Setting up for Linux analysis:

# Install Volatility 3
git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3
pip3 install -r requirements.txt

# For Linux analysis, you need the correct symbol table (ISF)
# Generate from the target's System.map and kernel debug symbols
# or use dwarf2json to create one
python3 vol.py -f /path/to/memory.lime \
  linux.bash.Bash

Generating the correct ISF (Intermediate Symbol Format) file for your target kernel is a common stumbling block. The dwarf2json tool converts kernel DWARF debug information into Volatility 3’s symbol format:

# On a system matching the target kernel
# (or using the kernel debug package)
dwarf2json linux \
  --elf /usr/lib/debug/boot/vmlinux-$(uname -r) \
  --system-map /boot/System.map-$(uname -r) \
  > linux-symbol-table.json

# Place in volatility3/symbols/linux/

Key plugins for incident response:

# List running processes with parent relationships
python3 vol.py -f memory.lime linux.pslist.PsList
python3 vol.py -f memory.lime linux.pstree.PsTree

# Identify hidden processes (compares multiple sources)
python3 vol.py -f memory.lime linux.psaux.PsAux

# Active and recent network connections
python3 vol.py -f memory.lime linux.sockstat.Sockstat

# Loaded kernel modules (detect rootkits)
python3 vol.py -f memory.lime linux.lsmod.Lsmod

# Check for modifications to the syscall table
python3 vol.py -f memory.lime linux.check_syscall.Check_syscall

# Bash command history from memory
python3 vol.py -f memory.lime linux.bash.Bash

# Extract environment variables (may contain secrets)
python3 vol.py -f memory.lime linux.envars.Envars

# Recover files mapped in memory
python3 vol.py -f memory.lime linux.proc.Maps

It’s mature, extensible through its plugin architecture, and accepted in legal and regulatory contexts, backed by more training material and community knowledge than any other tool in this space. The real friction is Linux symbol table generation — matching debug symbols can be genuinely hard to obtain for some distributions or custom kernels — and the fact that analysis is offline and batch-oriented, with each plugin running as a separate pass over the dump.

MemProcFS

MemProcFS, developed by Ulf Frisk, takes a fundamentally different approach to memory analysis. Rather than running individual plugins, it mounts a memory dump as a virtual filesystem. Processes appear as directories, network connections as files, and registry hives (on Windows) as browsable structures. This makes memory analysis accessible to investigators who may not be deeply familiar with Volatility’s command-line interface.

# Mount a memory dump as a virtual filesystem
./memprocfs -device /path/to/memory.lime -mount /mnt/memfs

# Browse processes like a filesystem
ls /mnt/memfs/pid/
# 1/  2/  357/  1042/  4521/ ...

# View process details
cat /mnt/memfs/pid/4521/cmdline
cat /mnt/memfs/pid/4521/environ

# View network connections
cat /mnt/memfs/sys/net/netstat.txt

# View loaded modules
cat /mnt/memfs/sys/modules/modules.txt

# Timeline of forensic artefacts
cat /mnt/memfs/forensic/timeline/timeline.txt

# When done
umount /mnt/memfs

MemProcFS also includes a built-in web interface and supports both live analysis and dump file analysis. Its LeechCore library handles the underlying memory access and supports a wide range of input formats including LiME, raw, and crash dumps.

The filesystem interface lowers the barrier to entry considerably, it’s fast, supports parallel analysis, and integrates naturally with standard Unix tools like grep, find, and cat — which makes it excellent for rapid triage when you need answers quickly during an active incident, rather than a full plugin-by-plugin pass. The trade-off is that Linux support is newer and less mature than its Windows support, and some of Volatility’s more advanced analysis capabilities don’t have a direct equivalent here yet.

Volexity Volcano

Volexity Volcano is a commercial memory analysis platform developed by Volexity, the team known for their threat intelligence and incident response work. Volcano focuses specifically on detecting malicious activity in memory rather than general-purpose memory forensics.

Volcano combines signature-based detection, heuristic analysis, and YARA rule scanning against memory dumps, running automated malware detection across process memory, kernel space, and memory-mapped files, with context-aware YARA results showing exactly which process and memory region matched. It also handles rootkit and hooking detection (syscall table modifications, inline hooks, hidden kernel modules), credential extraction from memory for common services, and produces structured reports suitable for incident reports and legal proceedings. Its edge over Volatility is the curated database of indicators drawn from Volexity’s own IR casework, which covers advanced threat actor techniques that public rule sets typically lag behind on.

Where it earns its licence fee is fileless malware, in-memory implants, and kernel-level rootkits, cases where a manual Volatility pass could take a day and Volcano gets you to the same answer in an hour. If you’re running IR often enough that a day matters, buy it. If you’re doing this a few times a year, Volatility 3 with public YARA rule sets will get most organisations to a defensible answer without the licence.

Putting It Together: A Cloud IR Memory Workflow

Preserve first, ask questions later. As soon as a compromised EC2 instance is identified, acquire memory before any containment action. Isolating the instance via security group changes is fine — it preserves the running state — but stopping or terminating the instance destroys volatile evidence permanently.

From there, acquire using AVML via SSM: deploy it with SSM Run Command, run the capture with compression enabled, and upload directly to a secured S3 bucket designated for forensic evidence, documenting the acquisition time, instance ID, and the hash of the resulting dump as you go.

# One-liner via SSM for rapid acquisition
aws ssm send-command \
  --instance-ids "i-0abc123def456789" \
  --document-name "AWS-RunShellScript" \
  --parameters 'commands=[
    "curl -sL -o /tmp/avml https://github.com/microsoft/avml/releases/latest/download/avml && chmod +x /tmp/avml && sudo /tmp/avml --compress /tmp/mem.lime && sha256sum /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-evidence/case-001/i-0abc123def456789-mem.lime"
  ]'

With the dump in hand, triage with MemProcFS first — mount it, check running processes and network connections, and look for obvious anomalies. That gets you initial findings within minutes. Follow up with targeted Volatility 3 plugins based on what triage surfaced: if MemProcFS flagged a suspicious process, use Volatility to dump its memory regions, inspect its loaded libraries, and trace its network activity. Then scan with YARA, whether through Volcano or Volatility’s own yarascan plugin, against known malware signatures and any custom rules relevant to the threat you’re chasing.

Preparation Is Everything

The most common failure in cloud memory forensics is not having the capability ready when it is needed. During an active incident is not the time to figure out how to acquire memory from your instances.

Organisations should prepare by maintaining a forensic readiness toolkit: pre-staged AVML binaries in a secured S3 bucket, SSM documents configured for memory acquisition, IAM roles with the necessary permissions ready to attach, and an S3 bucket with appropriate retention policies and access controls for evidence storage. Regularly test the acquisition process against representative instances in your fleet to confirm that AVML works with your current kernel versions and that the SSM workflow completes reliably.

For analysis, maintain a forensic workstation (an EC2 instance or local machine) with Volatility 3, MemProcFS, and pre-generated symbol tables for the kernel versions running in your environment. Generating symbol tables during an incident adds delays and complexity that can be avoided with preparation.

Related Services: