Lesson 08 — Memory Forensics

Learning Objectives

By the end of this lesson, you will be able to:

Understand the purpose of memory forensics
Differentiate memory forensics from disk forensics
Explain volatile evidence and order of volatility
Identify situations requiring memory acquisition
Understand memory acquisition techniques for Kubernetes and Amazon EKS
Analyze processes, threads and loaded modules from memory
Detect fileless malware and in-memory attacks
Investigate credential theft from memory
Identify process injection techniques
Correlate memory evidence with Kubernetes Audit Logs, CloudTrail and runtime telemetry
Maintain forensic integrity and chain of custody
Build an enterprise memory forensics workflow

Why Memory Forensics Matters

Many modern attacks never write malware to disk.

Instead, attackers execute entirely in memory.

Examples include:

Fileless malware
Memory-resident backdoors
Reverse shells
Reflective DLL loading
Process injection
Stolen credentials
Encryption keys
Kubernetes tokens
Cloud credentials
Runtime malware

Once the Pod or worker node is restarted…

…that evidence disappears forever.

Application Exploit

↓

Memory-Resident Malware

↓

Credential Theft

↓

Data Exfiltration

↓

Container Restart

↓

Evidence Lost

Memory is often the most valuable source of evidence during an active incident.

What is Memory Forensics?

Memory forensics is the process of acquiring and analyzing the volatile memory (RAM) of a running system.

Unlike disk analysis, memory analysis focuses on information that exists only while the system is running.

Examples include:

Running processes
Network connections
Open files
Loaded libraries
Active threads
Credentials
Encryption keys
Shell history
Command execution
Malware
Injected code

Kubernetes Memory Forensics Scope

Memory Investigation

├── Running Processes
├── Process Trees
├── Memory Regions
├── Loaded Libraries
├── Network Connections
├── Credentials
├── Encryption Keys
├── Shell Sessions
├── Malware
├── Injected Code
├── Runtime Metadata
├── Container Runtime
└── Worker Node Memory

Why Memory is Important

Memory may contain:

Kubernetes Service Account tokens
AWS temporary credentials
JWT tokens
OAuth tokens
SSH keys
Encryption keys
Database passwords
API keys
Malware configuration
Runtime commands
Shell history
Process arguments

Many of these never appear on disk.

Memory vs Disk Forensics

Memory Forensics	Disk Forensics
Live system	Offline system
Volatile	Persistent
Running malware	Stored malware
Active credentials	Saved credentials
Current network connections	Historical logs
Running processes	Installed files
Encryption keys	Encrypted files
Lost after shutdown	Available after shutdown

Both investigations complement each other.

Order of Volatility

Always collect evidence based on volatility.

CPU Registers

↓

RAM

↓

Network Connections

↓

Processes

↓

Temporary Files

↓

Disk

↓

Cloud Logs

↓

Backups

Memory should always be collected before shutting down the system whenever practical.

When Should Memory Be Collected?

Memory acquisition should be considered when:

Active malware is suspected
Reverse shell detected
Cryptomining detected
Container escape suspected
Ransomware running
Credential theft suspected
In-memory malware detected
Process injection suspected
Fileless malware suspected
Rootkit suspected
Advanced persistent threat (APT) activity observed

Memory Acquisition Challenges

Unlike traditional servers…

Containers are ephemeral.

Pods may restart automatically.

Worker nodes may terminate.

Auto Scaling may replace nodes.

Memory evidence disappears quickly.

Enterprise Memory Collection Workflow

Runtime Alert

↓

Determine Need

↓

Contain System

↓

Acquire Memory

↓

Hash Evidence

↓

Preserve Original

↓

Analyze Copy

↓

Correlate Evidence

↓

Root Cause

↓

Incident Response

Memory Acquisition Targets

Possible acquisition targets include:

Worker Node

Entire RAM

Container

Running processes
Memory regions

Process

Specific suspicious process memory

Virtual Machine

Entire EC2 memory

Memory Acquisition Considerations

Before collecting memory:

Is production impact acceptable?
Is legal approval required?
Is enough storage available?
Is acquisition tooling approved?
Is the system stable?
Is encryption enabled?
Is there sufficient time?

Preserve Evidence First

Before memory acquisition record:

Cluster
Namespace
Pod
Node
Instance ID
Process IDs
Runtime alerts
Current time
Investigator

Worker Node Memory

Memory acquisition is generally performed on:

Amazon EC2 worker nodes.

The acquisition captures:

Kernel memory
User processes
Containers
Runtime metadata
Loaded drivers
Active network state

Container Memory

Containers do not have independent RAM.

They share the worker node kernel.

Container memory analysis focuses on:

Process memory
Namespaces
cgroups
Runtime metadata

Live Response Before Acquisition

Record:

date

hostname

uptime

who

w

ps aux

ss -plant

These commands preserve volatile context before acquisition.

Memory Image

The acquired memory dump should include:

Running Processes

+

Threads

+

Memory Pages

+

Open Files

+

Network State

+

Kernel Structures

Memory Acquisition Tools

Common enterprise tools include:

LiME (Linux Memory Extractor)
AVML
Volatility-compatible acquisition tools
Commercial EDR tools
Hypervisor snapshots (where supported)

Use only organization-approved tools.

Evidence Integrity

Immediately calculate:

sha256sum memory.raw

Record:

SHA256
File size
Collection time
Collector
Host

Preserve Original Memory Image

Original Memory Dump

↓

Read-only Storage

↓

Working Copy

↓

Analysis

Never analyze the original evidence.

Memory Analysis Workflow

Memory Dump

↓

Identify OS

↓

Enumerate Processes

↓

Review Network Connections

↓

Review Loaded Modules

↓

Search Credentials

↓

Identify Malware

↓

Timeline Reconstruction

Process Analysis

Memory allows investigators to recover:

Running processes
Hidden processes
Parent-child relationships
Threads
Command lines

Questions:

Which process started first?
Which process spawned malware?
Which process injected code?

Hidden Processes

Attackers may hide processes from normal operating-system utilities.

Memory analysis can reveal:

Hidden malware
DKOM manipulation
Rootkits
Process unlinking

Thread Analysis

Review:

Suspicious threads
Injected threads
Remote threads
Thread start addresses

Unexpected threads may indicate code injection.

Process Injection

Common techniques include:

DLL Injection
Reflective loading
Process hollowing
Memory patching
Shared memory injection

Memory analysis can reveal injected code.

Loaded Modules

Review:

Shared libraries
Kernel modules
Unexpected modules
Unsigned modules

Unexpected modules may indicate:

Rootkits
Malware
Persistence

Memory Regions

Review memory pages for:

Executable regions
Writable executable pages
Injected shellcode
Suspicious permissions

Shellcode Detection

Memory may reveal:

Reverse shells
Downloaders
Encoded payloads
Exploit shellcode

that never existed on disk.

Credential Discovery

Memory often contains:

Kubernetes Service Account tokens
AWS STS credentials
JWT tokens
OAuth tokens
Database passwords
API keys
Kerberos tickets
TLS session keys

Investigate carefully while protecting sensitive data.

Kubernetes Credentials

Look for:

Service Account tokens
kubeconfig data
Bearer tokens
Kubernetes API requests

AWS Credentials

Possible artifacts include:

Access Key IDs
Temporary STS credentials
IAM role sessions
Session tokens

Correlate with CloudTrail.

Environment Variables

Memory often stores:

Secrets
Tokens
Passwords
API keys

Do not expose these values in investigation reports.

Network Analysis

Memory reveals:

Active TCP sessions
UDP sockets
Listening ports
Reverse shells
C2 channels

Correlate with:

VPC Flow Logs
DNS Logs
GuardDuty

DNS Investigation

Recover:

Cached domains
DNS requests
Resolver information

Look for:

Command-and-control domains
Newly registered domains
DGA activity

Malware Discovery

Memory analysis may reveal:

Malware configuration
Injected code
Encryption keys
Process relationships
Network destinations
Persistence

Fileless Malware

Fileless attacks execute entirely in RAM.

Examples include:

Reflective loading
Shellcode
PowerShell-like in-memory execution
Memory-only payloads

Disk analysis alone cannot detect these.

Rootkit Detection

Memory may reveal:

Hidden processes
Hidden drivers
Hidden modules
Kernel patches
Hooked system calls

Runtime Correlation

Correlate memory findings with:

Falco alerts
GuardDuty Runtime Monitoring
Kubernetes Audit Logs
CloudTrail
CloudWatch Logs
VPC Flow Logs

Timeline Reconstruction

Example:

10:01 Exploit

↓

10:02 Reverse Shell

↓

10:03 Malware Loaded

↓

10:04 AWS Token Access

↓

10:05 Secrets Retrieved

↓

10:06 External Connection

Indicators of Compromise

Examples include:

Hidden processes
Injected code
Reverse shell
Unusual modules
Suspicious memory pages
Credential artifacts
Network sessions
Rootkits

Enterprise Investigation Workflow

Runtime Alert

↓

Acquire Memory

↓

Hash Evidence

↓

Analyze Processes

↓

Analyze Credentials

↓

Analyze Network

↓

Analyze Malware

↓

Correlate Logs

↓

Root Cause

↓

Recovery

Evidence Collection Checklist

Memory

Memory image
SHA256 hash
Acquisition tool
Collection time

Runtime

Process list
Threads
Open files
Network connections

Credentials

Service Account tokens
AWS credentials
Secrets
API keys

Correlation

Chain of Custody

Every memory image should include:

Evidence ID

Incident ID

Cluster

Node

Collector

Acquisition Tool

Collection Time

SHA256

Storage Location

Common Mistakes

Rebooting Before Collection

Evidence lost.

Analyzing Original Memory Image

May modify evidence.

Always analyze a copy.

Ignoring Runtime Alerts

Memory findings should always be correlated with runtime telemetry.

Forgetting Hashes

Evidence integrity cannot be proven.

Leaving Memory Dumps Unprotected

Memory images may contain:

Passwords
Tokens
Customer data

Always encrypt and restrict access.

Enterprise Best Practices

As a Cloud Security Engineer:

Acquire memory before shutdown whenever possible.
Preserve volatile evidence immediately.
Hash every memory image.
Store originals securely.
Analyze working copies only.
Correlate memory evidence with Kubernetes Audit Logs and CloudTrail.
Protect sensitive credential artifacts.
Document every acquisition step.
Practice memory acquisition before incidents occur.
Include memory forensics in enterprise incident response playbooks.

Real-World Scenario

A banking organization receives a Falco alert indicating shell execution inside a production Pod.

GuardDuty Runtime Monitoring reports suspicious credential access.

The incident response team:

Identifies the affected EKS worker node.
Preserves runtime metadata.
Acquires a full memory image from the worker node.
Calculates SHA-256 hashes.
Stores the original dump in encrypted evidence storage.
Analyzes a working copy.
Identifies a hidden malware process injected into a legitimate application.
Recovers AWS STS credentials from memory.
Correlates CloudTrail API activity using those credentials.
Discovers attempted access to Amazon S3.
Revokes credentials.
Rebuilds the worker node.
Rotates Kubernetes Service Account tokens.
Updates runtime detection rules.

The investigation confirms that the attacker used fileless malware that never touched the disk, making memory forensics the key source of evidence.

Key Takeaways

Memory forensics is essential for investigating advanced Kubernetes attacks.
RAM contains volatile evidence that disappears after shutdown.
Memory analysis can reveal hidden processes, injected code and fileless malware.
Kubernetes Service Account tokens and AWS credentials may exist only in memory.
Memory findings should always be correlated with Audit Logs, CloudTrail and runtime telemetry.
Memory images must be hashed, protected and analyzed using working copies.
Enterprise incident-response plans should include memory acquisition procedures.

Knowledge Check

1. Why is memory forensics important during a Kubernetes incident?

Answer: Memory contains volatile evidence such as running processes, credentials, injected code, network connections and fileless malware that may never exist on disk.

2. What is the difference between memory and disk forensics?

Answer: Memory forensics analyzes volatile RAM from a live system, while disk forensics examines persistent storage after acquisition.

3. Why should memory be acquired before rebooting a compromised worker node?

Answer: Rebooting destroys volatile evidence including active processes, encryption keys, tokens, shell history and in-memory malware.

4. Why should investigators calculate a SHA-256 hash of a memory image?

Answer: The hash verifies evidence integrity, proves the image has not been modified and supports chain-of-custody requirements.

5. What types of credentials may be recovered from memory?

Answer: Memory may contain Kubernetes Service Account tokens, AWS STS credentials, JWT tokens, OAuth tokens, API keys, database passwords and encryption keys.

What’s Next?

In the next lesson, we will explore Lesson 09 — Root Cause Analysis, where you’ll learn how to reconstruct Kubernetes incidents, identify the original attack vector, determine the blast radius and document enterprise incident findings.