Detecting Memory-Only Malware Using Volatility And Memory Forensics

📅 October 30, 2026  |  🏷 Cyber Security  |  Cyber Security, Information Security, Threat Management

A compromised enterprise server sat clean on every antivirus scan for 217 days before incident responders discovered the breach — not through endpoint detection, but by dumping and analyzing raw memory. The attacker had never written a single file to disk. This is the reality of fileless, memory-resident malware: it operates entirely within the volatile address space of a running system, leaving almost no forensic footprint on storage media. Traditional disk-based forensics finds nothing. Log analysis finds anomalies, but nothing conclusive. Only memory forensics — specifically the disciplined use of tools like the Volatility Framework — reveals the truth buried inside RAM.

Memory-only malware has evolved from a niche attacker technique into a mainstream threat vector. According to the 2026 CrowdStrike Global Threat Report, fileless attack techniques now account for 71% of all detected intrusions, a sharp increase from 40% just three years prior. For security analysts, network defenders, and incident responders, understanding how to detect, analyze, and respond to these threats using memory forensics isn’t optional — it’s a foundational competency.

Understanding Memory-Only Malware: How Attackers Operate Without Touching Disk

Memory-resident malware, often called fileless malware, achieves persistence and execution entirely within RAM, leveraging legitimate operating system features to avoid detection. Attackers inject malicious code into trusted processes — svchost.exe, explorer.exe, lsass.exe — using techniques like Process Hollowing, Reflective DLL Injection, and living-off-the-land binaries (LOLBins). The OS itself becomes the delivery mechanism.

Common Execution Techniques and Why They Evade EDR

Several well-documented techniques enable memory-only execution. Process Hollowing spawns a legitimate process in a suspended state, unmaps its original executable memory, and replaces it with malicious shellcode. To any process listing tool, the parent process appears legitimate. Reflective DLL Injection loads a DLL directly from memory — rather than from disk — by implementing a custom loader within the DLL itself. This bypasses Windows’s normal DLL loading mechanisms and leaves no entry in the module load list.

PowerShell and WMI abuse represent the most pervasive LOLBin vectors. Attackers encode malicious payloads in Base64, execute them through PowerShell’s -EncodedCommand flag, and chain WMI subscriptions for persistence — all without dropping executables. The 2025 Verizon DBIR noted that PowerShell-based attacks accounted for 35% of all confirmed malware incidents in enterprise environments, with a significant portion achieving full persistence purely in-memory via WMI event subscriptions.

The Persistence Problem: Memory Is Volatile, But Attackers Compensate

A fundamental assumption is that memory-only malware dies on reboot. Sophisticated threat actors counter this through several methods: embedding WMI permanent event subscriptions that re-execute a remote payload on startup, abusing scheduled tasks that download and reflectively load code each time they trigger, and compromising firmware or UEFI — though the latter is far more resource-intensive. Understanding these re-infection chains is critical, because memory forensics must be paired with startup artifact analysis to fully remediate an infection.

Setting Up Your Memory Forensics Environment with Volatility 3

Volatility is the de facto open-source memory forensics framework, and its third major version — Volatility 3 — eliminates the need for separate OS profile creation by using symbol tables derived from debug symbols. This significantly reduces setup friction for analysts working across diverse Windows, Linux, and macOS environments. Deploying it correctly is a prerequisite for every investigation that follows.

Acquiring a Forensically Sound Memory Image

Memory acquisition must precede analysis. The cardinal rule: never analyze live memory directly from a production system without first creating a verified image. Tools purpose-built for acquisition include WinPmem (open-source, Windows), LiME (Loadable Kernel Module for Linux), and commercial options like Magnet RAM Capture. The acquisition process should be documented with hash verification (SHA-256) immediately after capture to establish forensic integrity.

On a Windows target, a WinPmem acquisition looks like this in practice: execute winpmem_mini_x64.exe memory.raw from an elevated command prompt. The resulting raw image file becomes the input for all subsequent Volatility analysis. For cloud or virtualized environments, hypervisor-level memory snapshots (VMware .vmem files, Hyper-V checkpoints) are equally valid inputs and often more accessible for enterprise IR teams.

Installing Volatility 3 and Preparing Symbol Tables

Volatility 3 requires Python 3.8+ and a set of symbol tables that correspond to the target OS. For Windows analysis, download the pre-built ISF (Intermediate Symbol Format) files from the Volatility Foundation’s symbol server or generate them using dwarf2json paired with the target kernel’s debug symbols. A working installation should pass the basic python3 vol.py -f memory.raw windows.info command, which outputs the OS version, architecture, and kernel base address — the foundation for all subsequent plugin execution.

Core Volatility Plugins for Detecting Fileless Malware

The real analytical power of Volatility lies in its plugin library. Each plugin interrogates a specific memory structure, and the skill of a memory forensics analyst lies in knowing which structures malware disturbs — and how to spot the disturbance. The following plugins form the core toolkit for fileless malware investigation.

Process Analysis: windows.pslist, windows.pstree, and windows.psscan

windows.pslist walks the doubly-linked list of active process objects (EPROCESS structures) maintained by the Windows kernel. Malware using DKOM (Direct Kernel Object Manipulation) can unlink itself from this list, making it invisible to pslist. windows.psscan compensates by scanning raw memory for EPROCESS pool tags, discovering processes regardless of whether they appear in the active list. A process visible to psscan but absent from pslist is a critical indicator of compromise.

windows.pstree visualizes parent-child process relationships. Anomalies are immediately apparent: a cmd.exe spawned by svchost.exe, a powershell.exe with no parent (orphaned processes), or lsass.exe with child processes — none of these should occur in a legitimate Windows environment. During the 2024 analysis of the BlackMatter ransomware campaign’s reconnaissance phase, IR teams identified compromised systems by spotting powershell.exe processes spawned directly by WMI worker processes, a relationship invisible to EDR tools that had been specifically bypassed by the attackers.

Injection Detection: windows.malfind and windows.cmdline

windows.malfind is arguably the most powerful single plugin for detecting code injection. It scans all process memory segments for regions that are executable, private (not backed by a file on disk), and contain content that resembles shellcode or PE headers. The plugin outputs the virtual address, memory protection flags, and a hex/disassembly dump of the suspicious region. A VAD (Virtual Address Descriptor) node tagged as PAGE_EXECUTE_READWRITE with no mapped file path is a textbook injection artifact.

Analysts should expect false positives — some legitimate Just-In-Time compilers (Java JIT, .NET CLR) generate executable private memory. The disambiguation step involves correlating the suspicious region’s parent process, comparing it against known-good baselines, and examining the disassembly dump for identifiable shellcode patterns (e.g., GetProcAddress resolution stubs, XOR decryption loops).

windows.cmdline retrieves the command-line arguments for every running process. For fileless attackers using PowerShell, this often captures the encoded payload directly — including Base64 strings that can be decoded offline to reveal the full attack chain. Cross-referencing cmdline output with process creation time (from windows.pstree) allows analysts to sequence the attack timeline.

Network Artifact Recovery and Lateral Movement Detection

Memory-resident implants maintain command-and-control (C2) connections. Unlike disk artifacts, active and recently closed network connections exist in memory long after they’ve been torn down — and Volatility can recover them.

Using windows.netstat and windows.netscan

windows.netstat enumerates active TCP and UDP connections from kernel network structures, including the local/remote addresses, port numbers, owning process, and connection state. windows.netscan extends this by scanning for connection objects in memory pool space, recovering recently terminated connections that no longer appear in the active table.

During a 2025 incident response engagement at a European financial services firm, analysts using netscan recovered connection records showing an internal workstation had established repeated HTTPS connections to an IP address registered in a bulletproof hosting range — connections that had long since terminated and left no trace in firewall logs (which had been selectively cleared). The owning process for those connections was rundll32.exe, which had no associated DLL on disk. This led directly to the discovery of a Cobalt Strike Beacon running reflectively in memory.

Identifying Injected Network-Capable Code

When netscan reveals suspicious connections owned by processes like svchost.exe or explorer.exe, the next step is memory carving. Using Volatility’s windows.dumpfiles or windows.memmap plugins, analysts can extract the memory pages associated with the suspicious process and subject them to static analysis in tools like YARA, CyberChef, or a disassembler. C2 configuration blocks — containing beacon intervals, jitter values, and C2 server addresses — are often recoverable directly from these carved memory regions, providing intelligence that feeds directly into threat hunting across the broader environment.

Advanced Analysis: Rootkit Detection and Registry Artifact Recovery

Sophisticated actors don’t stop at process injection. Kernel-level rootkits modify OS structures to hide processes, network connections, and registry keys — all within memory. Volatility provides several plugins specifically designed to surface these manipulations.

Detecting DKOM and Hook-Based Rootkits

windows.ssdt (System Service Descriptor Table) analysis checks the kernel’s function pointer table for unauthorized modifications. Rootkits hook SSDT entries to intercept and filter system calls — for example, intercepting NtQuerySystemInformation to exclude malicious processes from enumeration. Volatility compares SSDT entries against known-good kernel module addresses; any entry pointing outside expected kernel space is flagged as a hook.

windows.modules and windows.modscan — analogous to their process counterparts — enumerate loaded kernel modules from the active list and raw memory respectively, enabling detection of hidden kernel drivers used by rootkits. The TDL4 rootkit family, still actively repurposed by various threat actors in modified forms as recently as 2026, is consistently identifiable through modscan revealing driver modules absent from the active module list.

Registry Hive Analysis in Memory

Windows registry hives are partially or fully mapped into memory during system operation. Volatility’s windows.registry.hivelist and windows.registry.printkey plugins allow analysts to query registry key content directly from memory — including keys that may have been deleted from disk or modified in-memory by rootkit activity. Attackers frequently use the registry for staging encoded payloads in run keys or COM object hijacking entries; memory-based registry analysis can recover these even after deletion, because the in-memory hive hasn’t been flushed to disk.

Operationalizing Memory Forensics: From Incident Response to Continuous Hunting

Memory forensics is most powerful when it shifts from a purely reactive capability to a proactive threat hunting practice. Waiting for an incident to occur before acquiring memory images means losing the forensic window. Modern enterprise security programs integrate memory analysis into their continuous detection pipelines.

Building a Memory Forensics Playbook

An effective memory forensics playbook establishes standardized procedures for acquisition triggers (EDR alert thresholds, anomalous network behavior, privilege escalation events), image handling (chain-of-custody documentation, hash verification, encrypted storage), analysis sequencing (pslist → pstree → malfind → cmdline → netscan → ssdt), and escalation criteria (what constitutes confirmed compromise versus investigation-requiring anomaly).

Quantifying the operational benefit: organizations with documented memory forensics playbooks reduce mean-time-to-identify (MTTI) for fileless attacks by an average of 58% compared to those relying solely on log and EDR analysis, according to a 2026 SANS Institute survey of 412 enterprise incident response teams. The same survey found that memory forensics was the definitive detection method for 83% of confirmed fileless malware incidents where other tools had returned false negatives.

Integrating Volatility with SIEM and SOAR Pipelines

Volatility’s JSON output mode enables direct integration with SIEM platforms like Splunk, Microsoft Sentinel, and Elastic Security. Automating periodic memory acquisition on high-value targets — domain controllers, jump servers, privileged admin workstations — and feeding Volatility plugin output into a SIEM dashboard creates a continuous memory threat visibility layer. SOAR playbooks can trigger automated memory analysis workflows when EDR alerts cross defined severity thresholds, routing suspicious malfind or netscan output to analyst queues without manual intervention.

Key Takeaways

• Memory-only malware bypasses disk-based forensics entirely. Fileless techniques like Reflective DLL Injection and Process Hollowing leave no file artifacts, making traditional AV and disk forensics insufficient. Memory analysis is the definitive detection method for 83% of confirmed fileless incidents.
• Volatility 3 is the essential framework for memory forensics. Its plugin ecosystem — pslist, malfind, netscan, ssdt, and registry plugins — maps directly onto the behavioral signatures of memory-resident malware, providing structured, repeatable analysis capabilities.
• Forensically sound acquisition is non-negotiable. Memory images must be acquired with hash verification and documented chain of custody using purpose-built tools (WinPmem, LiME) before any analysis begins. Contaminated evidence undermines both investigation and legal proceedings.
• Cross-correlation between plugins reveals the full attack chain. No single plugin provides complete visibility. Effective analysis chains process enumeration, injection detection, network artifact recovery, and rootkit detection into a coherent investigative narrative.
• Proactive memory hunting reduces MTTI by 58%. Organizations that operationalize periodic memory acquisition and integrate Volatility output into SIEM/SOAR pipelines detect fileless attacks dramatically faster than those treating memory forensics as a purely reactive capability.

Conclusion: Build Your Memory Forensics Capability Before You Need It

Memory forensics is not an esoteric specialty reserved for elite threat intelligence teams. It is a practical, deployable capability that directly addresses the most evasive attack techniques currently deployed against enterprise environments. The 217-day dwell time described at the outset of this article isn’t an outlier — it’s representative of what happens when defense teams lack visibility into process memory.

The path forward is concrete. Download and deploy Volatility 3 in your lab environment this week. Practice acquisition using WinPmem against known-good baselines to understand what legitimate memory looks like before you encounter malicious artifacts. Build your first analysis playbook using the plugin sequence outlined in this article. Identify the five highest-value systems in your environment — your domain controllers, privileged access workstations,