Memory Forensics for Compromised Agent Systems with Volatility3

Why agent processes are high-value forensic targets

An agent process at the moment of compromise holds more forensically relevant data than almost any other process type:

• API keys in environment variables — the agent's full .env context is resident in memory as long as the process runs. A memory dump captures every key, even ones never written to disk.
• The current conversation context — the full context window, including injected instructions from AML.T0054 (Prompt Injection), is in memory. This is the exact artifact that proves what the attacker instructed the agent to do.
• Loaded model weights / cached model artifacts — for self-hosted LLMs, the quantized model is loaded into GPU/CPU memory. Injected code or tampered weight regions leave forensic signatures in the memory map.
• Network connections — the current socket table shows every active connection the agent has open, including any command-and-control connections established post-compromise.

The Volatility3 workflow for agent processes

Step 1: Capture the memory dump

On Linux (most agent deployments run on GCP/AWS Linux instances), capture the process memory with gcore before killing the suspect process:

# Identify the suspect PID
ps aux | grep "python3.*agent" | grep -v grep

# Capture memory without killing the process
gcore -o /forensics/agent_$(date +%Y%m%d_%H%M%S).dump <PID>

# For a full system dump (captures all processes):
sudo dd if=/proc/kcore of=/forensics/mem_$(date +%Y%m%d_%H%M%S).raw bs=1M

# Verify dump integrity
sha256sum /forensics/agent_*.dump > /forensics/dump_hashes.txt

Hash the dump immediately — this is your evidence integrity record, aligned with NIST AI RMF MEASURE-2.6 (evidence-based evaluation).

Step 2: Extract running processes and network connections

# List all processes at time of dump
python3 vol.py -f /forensics/agent_dump.raw linux.pslist
python3 vol.py -f /forensics/agent_dump.raw linux.pstree

# Check network connections — look for unexpected external IPs
python3 vol.py -f /forensics/agent_dump.raw linux.netstat

# Cross-reference with known-good agent IPs
# Any connection to an IP not in the agent's allow list is an IOC

The linux.netstat output is your direct window into AML.T0047 post-exploitation: a compromised agent establishing a connection to an attacker-controlled IP appears here even if the connection was opened and closed before any disk artifact was written.

Step 3: Scan for injected code regions (malfind equivalent)

# Detect memory regions with RWX permissions (classic code injection indicator)
python3 vol.py -f /forensics/agent_dump.raw linux.malfind

# For each flagged region, dump the bytes for further analysis
python3 vol.py -f /forensics/agent_dump.raw linux.malfind --dump \
  --output-dir /forensics/malfind_output/

# Scan dumped regions against YARA rules for known malware signatures
yara -r /opt/yara_rules/ai_agent_compromise.yar /forensics/malfind_output/

This addresses D3FEND D3-PSMD (Process Segment Metadata Detection) directly — the memory segment metadata (permissions, backing file, anonymous vs. file-backed) distinguishes legitimate agent code from injected shellcode.

Step 4: Recover API keys and conversation context from memory strings

# Extract all strings from the dump (filter for API key patterns)
python3 vol.py -f /forensics/agent_dump.raw linux.strings | \
  grep -E "(sk-ant|sk_live_|bo_live_|ANTHROPIC|OPENAI)" \
  > /forensics/extracted_keys.txt

# Extract the conversation context window
# Look for JSON structures containing "messages" or "content" keys
python3 vol.py -f /forensics/agent_dump.raw linux.strings | \
  grep -E '"role":|"content":|"messages":' | \
  head -200 > /forensics/conversation_fragment.txt

The conversation fragment is the forensic proof of what injected instructions (AML.T0054) the attacker delivered. If the agent was instructed to exfiltrate data via a prompt injection, that instruction is in the conversation context in memory — verbatim.

Step 5: Map findings to ATLAS techniques and NIST CSF response

For each finding, tag it with the relevant ATLAS technique before closing the incident:

Integrating memory forensics into the agent incident response runbook

Memory forensics should be a standard step in any agent incident response playbook. The trigger for escalation is a Wazuh rule alert (see Part 4) with severity ≥ 10 and an agent process in scope. The response sequence:

1. Isolate: block the agent's outbound network via host firewall rule (preserves process state)
2. Capture: gcore dump + sha256sum for chain of custody
3. Analyze: Volatility3 pslist + netstat + malfind + strings
4. Rotate: all keys found in /forensics/extracted_keys.txt
5. Document: ATLAS technique tags + timeline → verifiable audit record
6. Harden: add injection patterns found to content-trap scanner (Part 2); add network IOCs to Wazuh rules (Part 4)

Framework mapping