Finding an Attacker in a Snapshot of Memory: RAM Forensics with Redline and Volatility
This lab worked through exactly that kind of analysis, examining a RAM dump with two different tools, Redline and Volatility, to trace a compromise from a single suspicious network connection all the way back to the process that spawned it.
Every disk-based forensic technique I'd worked through earlier in this series shared one limitation: a disk image only shows what was written to storage. A sophisticated attack often doesn't look like that. Malicious code that lives entirely in memory, processes spawned and manipulated in ways that never touch the disk in an obviously suspicious way, can be completely invisible to a disk analysis while being very visible in a snapshot of what was actually running at the moment the system was captured. This lab worked through exactly that kind of analysis, examining a RAM dump with two different tools, Redline and Volatility, to trace a compromise from a single suspicious network connection all the way back to the process that spawned it.
Why RAM Analysis Is a Different Kind of Investigation
The scenario was specific: a firm suspected a data breach and needed to determine whether malicious processes were actually running on its systems. That phrasing matters, running, present tense, at the moment the memory was captured. A RAM dump is a snapshot of exactly what a system was doing when it was captured: every running process, every open network connection, every loaded file handle and registry key a process had touched, all frozen in place. Disk forensics tells you what's stored. Memory forensics tells you what was actually happening.
Starting With Redline: A Guided Entry Point
I began with Redline, a tool with a more structured, guided interface compared to the command-line approach I'd use later. After pointing it at the evidence file,
Windows_RAM.mem , and setting up a named analysis session, Redline took roughly an hour to process the full image, a reasonable amount of time given it's indexing every process, connection, and artifact present in the entire memory capture.Starting broad: the process list
The first thing I examined was the full Processes list, every process Redline had identified as running at the time of capture. On its own, a raw process list is a reasonable starting point but not usually conclusive, modern systems run dozens of legitimate processes simultaneously, and nothing in a bare list immediately screams "malicious" without additional context.
Finding the actual anomaly: network connections
The lab's own guidance was the key insight here: when a process list alone doesn't surface anything obviously wrong, the next move is to examine network connections instead. I opened the Ports section, which lists every network connection recorded in memory alongside the specific process each one belongs to.
Scanning through, I found something worth flagging immediately:
rundll32.exe , a legitimate Windows system utility normally used to run functions stored in DLL files, connected to a remote IP address on port 4444. On its own, one closed connection might not mean much. But scrolling further, I found the same process name again, a different PID this time (1896), connected to the exact same remote address and port, except this connection's state was ESTABLISHED, active, live at the moment the memory was captured.That detail matters specifically because of what port 4444 commonly represents in security contexts: it's a well-known default port associated with Metasploit's Meterpreter payload, a popular penetration testing and exploitation framework. A legitimate system utility like
rundll32.exe holding an active connection to that specific port is a strong, specific indicator of compromise, not a vague "this looks weird" hunch, but a recognizable pattern tied to a known attack tool.Tracing the relationship: hierarchical processes
To understand how that suspicious
rundll32.exe instance actually came to exist, I checked Hierarchical Processes, which displays parent-child relationships between running processes rather than a flat list. This revealed the actual chain: rundll32.exe 's parent process was spoolsv.exe (Windows' print spooler service), and rundll32.exe itself had spawned a child process, cmd.exe (Command Prompt), which had in turn launched two further processes: notepad.exe and calc.exe .That chain tells a coherent story on its own.
spoolsv.exe is a legitimate, normally quiet background service, it has no ordinary reason to spawn rundll32.exe , which then spawns a command shell, which then launches a calculator and a text editor. Each individual link might be explainable in isolation, but the full chain, a print service spawning a DLL-execution utility spawning a command shell spawning unrelated user applications, is exactly the kind of process ancestry that indicates a compromised service being used as an entry point for arbitrary code execution.Redline's Timeline view let me place all of this in chronological order, confirming the sequence these events actually occurred in, rather than just their logical hierarchy.
Confirming Independently With Volatility
With a clear hypothesis from Redline, I moved to Volatility, a command-line memory forensics framework, specifically to verify the same findings through an entirely separate tool and methodology, rather than relying on a single tool's conclusions alone.
Identifying the memory image's profile
Before running any real analysis, Volatility needs to know what kind of system the memory image came from, since Windows memory structures vary meaningfully by version. I used the
imageinfo plugin to get Volatility's best-guess suggestions, and kdbgscan as a more thorough alternative scan of the kernel debugger structures, to confirm a suitable profile. Based on the results, I selected Win2008R2SP0x64 as the matching profile for the rest of the analysis, a required step before any other plugin's output can be trusted to be interpreted correctly.Re-confirming the network finding
Using the
netscan plugin with the confirmed profile, I pulled network connection data directly from the memory image via the command line. This independently reproduced exactly what Redline had shown graphically: rundll32.exe with two different PIDs (1972 and 1896), connected to the same suspect remote address, one connection closed, the other (1896) still active.Cross-referencing the process list
Running
pslist returned Volatility's own full process listing, and scrolling to find rundll32.exe confirmed it was present and running exactly as Redline had indicated, a second, independent confirmation of the same process's existence in memory.Digging deeper: files and registry keys
This is where Volatility's command-line, plugin-based approach offered something Redline's more guided interface hadn't surfaced as directly. Using the
handles plugin targeted specifically at PID 1896 ( -p 1896 -t file ), I listed every file handle that specific process instance had open, concrete evidence of what files the suspicious process was actually interacting with while running. Running the same command with -t key instead listed the registry keys the process had touched.That level of granularity, down to specific open file handles and registry key access for one exact process instance, is a genuinely different depth of evidence than a process name and a network connection alone. It starts answering not just "is this process suspicious" but "what, specifically, was this process actually doing."
Confirming the full process tree
Finally,
pstree displayed the complete process ancestry in Volatility's own format, and it matched Redline's hierarchical view precisely: spoolsv.exe → rundll32.exe → rundll32.exe → cmd.exe → calc.exe , with the first rundll32.exe instance (PID 1972) already closed and the second (PID 1896) representing the live, ongoing compromise, the one that had spawned the command shell and, from there, the calculator and notepad processes.Why Confirming With a Second Tool Actually Matters
A few things stood out about the value of running this investigation through two separate tools rather than stopping once Redline had surfaced a clear finding.
Independent confirmation protects against a single tool's blind spots or misinterpretation. Redline's guided interface made the initial discovery fast and visually clear. Volatility's command-line plugins, run independently against the same raw evidence, reproduced every key finding, the suspicious connection, the specific PIDs, the process hierarchy, confirming the conclusion wasn't an artifact of how one specific tool happened to present or interpret the data.
A known port number is a real, specific indicator, not a vague suspicion. Recognizing port 4444 as commonly associated with a known exploitation framework's default payload configuration turned "this connection looks unusual" into "this specific pattern matches a well-documented attack tool," a meaningfully stronger and more actionable finding.
Process ancestry tells a story that a flat list never could. Nothing about
rundll32.exe running, or cmd.exe running, or calc.exe running, is individually alarming, each is an entirely ordinary Windows process under normal conditions. What made this suspicious was the specific chain connecting them: a background service spawning a code-execution utility spawning a shell spawning unrelated applications. Context, not any single process name, is what actually made this detectable.File and registry handle data provides depth beyond simply confirming a process exists. Knowing a process is suspicious is a starting point. Knowing exactly which files and registry keys that specific process instance had open while running is what starts to build a real picture of its actual behavior and intent, information a basic process or network listing alone can't provide.
Multiple PIDs for the same process name over time can represent an attacker relaunching their foothold. The first
rundll32.exe (PID 1972) with a closed connection and the second (PID 1896) with an active one suggests the compromise wasn't a single static event, the malicious process had been started more than once, which itself is a detail worth investigating further in a real incident.This lab traced a complete compromise using nothing but a snapshot of memory: a single suspicious network connection on a recognizable port led to a specific process, which led to its parent, which led to the full chain explaining how a legitimate background service had apparently been used as the entry point for a live, active compromise. Disk-based forensics, covered extensively earlier in this series, answers questions about what was stored. This lab was a direct demonstration of why memory forensics is necessary alongside it: some of the most important evidence of an active compromise exists only in what a system was actually doing in the moment, not in anything that was ever written to disk at all.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article