CH9: Windows Memory Forensics – Part 2

Chapter Overview

In Chapter 8, we established the foundations of memory forensics: the Order of Volatility, Windows memory architecture, acquisition tools, and six core Volatility 3 plugins for initial triage. By the end of that chapter, you could capture RAM, verify an image, list processes, and spot the telltale signs of process injection using malfind.

This chapter takes you from triage to deep-dive investigation. We will move beyond asking "What processes are running?" to asking "What is that process doing?" We will extract registry hives and cached files directly from volatile memory, hunt for threats using custom pattern-matching rules, recover credential hashes and encryption keys that exist nowhere on the hard drive, and build unified timelines that merge memory-resident events with the disk-based artifacts you studied in Chapters 4 through 7.

We will also introduce MemProcFS, a modern analysis framework that transforms a raw memory dump into a browsable virtual file system—giving you the power of Volatility's analysis engine with the accessibility of Windows Explorer.

Learning Objectives

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

• Conduct advanced process investigation using Volatility 3 plugins that enumerate handles, loaded DLLs, Windows services, and user sessions to determine exactly what a suspicious process is doing.
• Extract forensic artifacts—including registry hives, cached files, and network data—directly from a memory image, recovering evidence that may not exist on the physical hard drive.
• Detect known malware signatures and custom threat patterns by deploying YARA rules through the yarascan plugin.
• Recover password hashes and identify the presence of encryption keys in memory, understanding both the investigative value and the legal responsibilities of credential extraction.
• Construct a unified forensic timeline from memory-resident events using the timeliner plugin and correlate it with disk-based timelines from earlier chapters.
• Deploy the MemProcFS framework to mount a memory image as a virtual file system for rapid, GUI-accessible analysis.

---

9.1 From Triage to Investigation: A Structured Methodology

Chapter 8 taught you how to perform the forensic equivalent of taking a patient's pulse: Is the image valid? What processes are running? Are any of them hiding? That is triage. This chapter is the full diagnostic workup.

Before diving into new plugins, it is worth establishing a repeatable methodology for memory analysis. Having a structured sequence prevents you from chasing false leads and ensures you do not skip critical steps under the pressure of an active incident.

The Memory Analysis Workflow

The following five-phase workflow builds on the triage foundation from Chapter 8 and extends it into the deep-dive analysis covered in this chapter:

Phase	Objective	Key Plugins / Actions
1. Validate	Confirm the image is intact and identify the OS	windows.info
2. Enumerate	List all processes; detect hidden ones	windows.pslist, windows.psscan, windows.pstree
3. Investigate	Deep-dive into suspicious processes	windows.handles, windows.dlllist, windows.cmdline, windows.malfind, windows.svcscan
4. Extract	Pull artifacts from memory (files, registry, credentials, network)	windows.filescan, windows.dumpfiles, windows.registry.hivelist, windows.registry.printkey, windows.hashdump, windows.netscan
5. Correlate	Build a timeline and cross-reference with disk evidence	timeliner, YARA scans, comparison with MFT/Event Log/Registry timelines

Phases 1 and 2 were the focus of Chapter 8. This chapter covers Phases 3 through 5 in depth.

Analyst Perspective

In a real incident response engagement, you will rarely have the luxury of running every plugin sequentially. The workflow above is a training framework. In the field, you will often jump directly to Phase 4 (Extract) if you already know you need the registry hives, or to Phase 3 (Investigate) if your SIEM alert already identified a suspicious PID. The value of the methodology is that it gives you a checklist to return to when you feel lost or want to confirm you have not missed anything.

---

9.2 Advanced Process Investigation

In Chapter 8, we used pslist, psscan, and pstree to identify which processes were running. Now we ask the harder question: What is that process doing with system resources?

Handles: What Resources Does the Process Own?

Every running process in Windows holds handles to system objects—open files, registry keys, network sockets, mutexes (synchronization locks), and more. The windows.handles plugin enumerates these for a given process.

The Command:

python3 vol.py -f [Image.raw] windows.handles --pid [PID]

The --pid flag filters the output to a single process. Without it, the plugin returns handles for every process, which can produce tens of thousands of rows.

What to Look For:

• File Handles: If a process you suspect of data exfiltration holds open handles to C:\Users\CFO\Documents\Financial_Projections.xlsx, you have direct evidence linking the process to the sensitive file.
• Registry Key Handles: A process holding an open handle to HKLM\SAM or HKLM\SECURITY is likely attempting credential extraction.
• Mutexes (Mutant objects): Many malware families create a uniquely named mutex to ensure only one copy of themselves is running at a time. These mutex names are well-documented in threat intelligence databases. Finding a mutex named Global\HermeticWiper_Mtx inside an svchost.exe process is a definitive indicator of compromise.

Loaded DLLs: What Code Libraries Are in Use?

The windows.dlllist plugin lists every Dynamic Link Library loaded by a process.

The Command:

python3 vol.py -f [Image.raw] windows.dlllist --pid [PID]

What to Look For:

• Path Anomalies: Legitimate Windows DLLs load from C:\Windows\System32\. If a DLL is loaded from C:\Users\Public\Downloads\ or a Temp directory, it is highly suspicious.
• Name Anomalies: Attackers sometimes name their malicious DLLs to mimic legitimate ones with slight misspellings (e.g., kerne132.dll with a numeral "1" replacing the letter "l"). Compare the DLL list against a known-good baseline.
• Unsigned or Unknown DLLs: Cross-reference DLL names and paths against your forensic baseline or a threat intelligence feed to identify libraries that do not belong.

Windows Services from Memory

In Chapters 4 and 5, we examined Windows services through the registry (SYSTEM\CurrentControlSet\Services). The windows.svcscan plugin provides a complementary view by scanning memory for service record structures.

The Command:

python3 vol.py -f [Image.raw] windows.svcscan

Why This Matters: If an attacker installs a malicious service and then deletes the registry key to cover their tracks, the service may still be running in memory. The disk-based registry will show nothing, but svcscan will reveal the service name, its binary path, its current state (Running/Stopped), and its start type (Automatic/Manual). This is a direct example of where memory evidence contradicts—and corrects—disk evidence.

Warning

Do not assume that a service listed by svcscan still has a corresponding entry on disk. Memory and disk can tell different stories, especially after anti-forensic activity. Always cross-reference both sources.

User Sessions

The windows.sessions plugin maps processes to their originating logon sessions. This is particularly useful in multi-user environments (e.g., a server accessed by several administrators via RDP).

The Command:

python3 vol.py -f [Image.raw] windows.sessions

By correlating a suspicious process with a specific Session ID, you can determine which user account launched it. This directly supports attribution—the same goal we pursued through SID mapping in Chapter 4.

---

9.3 Extracting Forensic Artifacts from Memory

This is where memory forensics transforms from a specialized niche into a force multiplier for everything you have learned in this course. The artifacts you studied on disk in Chapters 4 through 7—registry hives, user files, network connections—also exist in RAM, sometimes in a more current or more complete state than their on-disk counterparts.

Registry Hives in Memory

Recall from Chapter 4 that registry hive files (NTUSER.DAT, SAM, SYSTEM, SOFTWARE) are locked by the operating system and require special tools to acquire from a live system. In a memory dump, these hives are fully loaded and accessible without any file locks.

Step 1: List the Hives

python3 vol.py -f [Image.raw] windows.registry.hivelist

This outputs the virtual memory offset and file path for every registry hive loaded into memory. You will see entries for \SystemRoot\System32\config\SAM, each user's \NTUSER.DAT, and other familiar paths.

Step 2: Read Specific Keys

python3 vol.py -f [Image.raw] windows.registry.printkey --key "Software\Microsoft\Windows\CurrentVersion\Run"

This prints the subkeys and values at the specified path, just as if you were browsing the registry in Registry Explorer—except you are reading it from volatile memory.

Forensic Value: If the machine crashed or was forcibly powered off, the most recent registry changes may still be sitting in the transaction logs (.log1, .log2) and have not yet been flushed to the main hive file on disk. The in-memory version of the registry reflects the actual runtime state, including those unflushed changes. This means the memory-resident registry can be more current than the on-disk hive, even after replaying transaction logs.

Files Cached in Memory

Windows aggressively caches file data in memory for performance. Documents the user had open, executables that recently ran, and even files that were downloaded and immediately deleted may still have their content resident in RAM.

Step 1: Locate Files

python3 vol.py -f [Image.raw] windows.filescan

This plugin scans memory for FILE_OBJECT structures. The output is a list of file paths and their memory offsets. You can filter this output (using grep on Linux/macOS or findstr on Windows) to search for specific filenames or extensions.

Step 2: Extract Files

python3 vol.py -f [Image.raw] windows.dumpfiles --pid [PID]

This extracts the cached file content from memory and writes it to your analysis directory. The --pid flag scopes the extraction to files associated with a specific process. You can also target a specific virtual address offset if filescan identified a file of interest.

Analyst Perspective

This technique is particularly powerful in ransomware investigations. If the ransomware was actively encrypting files when the memory was captured, you may be able to recover the unencrypted originals from the file cache in RAM. The ransomware encrypts the on-disk version, but the pre-encryption copy can linger in memory pages that have not yet been reclaimed.

Credential Extraction: Password Hashes from Memory

The Windows Security Accounts Manager (SAM) database stores the NTLM password hashes for local user accounts. On a running system, these hashes are loaded into memory by the Local Security Authority Subsystem Service (lsass.exe). Volatility can extract them.

The Command:

python3 vol.py -f [Image.raw] windows.hashdump

Output: The plugin produces output in the format:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:fc525c9683e8fe067095ba2ddc971889:::

This is structured as Username:RID:LM_Hash:NTLM_Hash. In modern Windows systems (Vista and later), the LM hash is disabled by default and will appear as the placeholder value aad3b435b51404ee.... The NTLM hash is the operative credential.

Investigative Applications:

• Confirming Credential Theft: If your investigation involves a suspected attacker who gained access to the system, running hashdump tells you exactly which password hashes were exposed. This determines the scope of the compromise: if the Administrator hash was in memory, the attacker had access to the highest-privilege local account.
• Identifying Pass-the-Hash Attacks: In lateral movement scenarios, attackers do not need to crack the password. They reuse the hash itself to authenticate to other machines on the network. Identifying which hashes were in memory helps you predict which other systems the attacker could have accessed.
• Offline Password Recovery: In authorized forensic investigations (e.g., decrypting a deceased person's laptop for an estate case), the extracted hashes can be tested against password dictionaries using tools like Hashcat or John the Ripper to recover the plaintext password.

Warning

Credential extraction is a sensitive capability. In a law enforcement context, your warrant or legal authorization must explicitly cover the recovery of authentication credentials. In a corporate context, your engagement scope and authorization letter must permit it. Extracting and storing password hashes outside of a documented, authorized investigation can expose you to legal liability. Always document why you performed the extraction and what you did with the results.

Encryption Key Recovery from Memory

In Chapter 1, we discussed the challenge of BitLocker full-disk encryption. When a BitLocker-protected volume is mounted and accessible on a running system, the Full Volume Encryption Key (FVEK) must reside in RAM for the operating system to read and write data to the encrypted disk. If you capture memory while the volume is unlocked, the key is in the dump.

How It Works: Volatility 3 does not have a dedicated built-in "BitLocker key finder" plugin at the time of this writing. However, the open-source community has produced plugins and standalone tools that scan a raw memory dump for the known data structures associated with BitLocker's FVEK and Volume Master Key (VMK).

The general workflow is:

1. Capture RAM while the encrypted volume is mounted and accessible (the system is running, and the user has authenticated or the TPM has released the key).
2. Scan the memory dump for the AES key schedule structures that BitLocker uses. Tools such as bitlocker-memory-extractor or community Volatility plugins search for the characteristic byte patterns of the expanded AES key.
3. Use the recovered key to decrypt the forensic image of the encrypted drive using a tool like dislocker (Linux) or by importing the key into a commercial forensic suite.

Beyond BitLocker: The same principle applies to other encryption tools. If a suspect had a VeraCrypt volume mounted at the time of capture, the AES (or Serpent, or Twofish) keys are in memory. Standalone tools like aeskeyfind scan a raw dump for any AES key schedule, regardless of which application created it. The tool does not know what the key encrypts; the examiner must determine that through context.

Analyst Perspective

This is the single strongest argument for live acquisition. If you encounter a running system with BitLocker or VeraCrypt in use and you pull the power cord, the encryption keys vanish permanently. Unless you can obtain the recovery key from Active Directory, the user's Microsoft account, or a physical printout, the data on the drive may be permanently inaccessible. Capturing RAM first is not optional in these scenarios—it is the investigation.

---

9.4 Threat Hunting with YARA Rules

The plugins covered so far help you find anomalies: hidden processes, suspicious DLLs, injected code. But what if you already know exactly what you are looking for? What if your threat intelligence team has provided you with specific byte patterns, strings, or signatures associated with a known malware family? This is where YARA enters the workflow.

What is YARA?

YARA is a pattern-matching language designed for malware researchers and incident responders. A YARA "rule" is essentially a search template that defines a combination of strings, hexadecimal patterns, and logical conditions. When you scan data against a YARA rule, the engine reports every location where the pattern matches.

A basic YARA rule has three parts:

rule Detect_Cobalt_Strike_Beacon {
    meta:
        description = "Detects common Cobalt Strike beacon strings"
        author = "Example"
    strings:
        $s1 = "beacon.dll" ascii
        $s2 = { 4D 5A 90 00 03 00 00 00 }
        $s3 = "ReflectiveLoader" ascii
    condition:
        2 of ($s1, $s2, $s3)
}

• meta: Descriptive information about the rule (not used for matching).
• strings: The patterns to search for. These can be plain text (ascii), wide-character Unicode (wide), or raw hexadecimal byte sequences enclosed in curly braces.
• condition: The logic that determines a match. In this example, the rule fires if any two of the three defined strings are found.

The yarascan Plugin

Volatility 3 integrates YARA directly through the windows.yarascan plugin. This allows you to scan the entire memory image—or a specific process—against one or more YARA rules.

Scanning with a Rule File:

python3 vol.py -f [Image.raw] windows.yarascan --yara-file /path/to/rules.yar

Scanning for a Single String (Quick Search):

python3 vol.py -f [Image.raw] windows.yarascan --yara-rules "rule quick { strings: $a = \"password\" ascii condition: $a }"

Scoping to a Single Process:

python3 vol.py -f [Image.raw] windows.yarascan --yara-file /path/to/rules.yar --pid [PID]

Output: For each match, yarascan reports the rule name that triggered, the process (PID and name) containing the match, the virtual address of the match within that process's memory space, and a hex dump of the surrounding bytes for context.

Practical Applications

• Known Malware Families: Organizations like YARA-Forge, Florian Roth's signature repository, and CISA regularly publish YARA rules for known threats (Cobalt Strike, Mimikatz, various ransomware strains). Running these against a memory dump is the fastest way to confirm or rule out a specific threat.
• Custom IOC Sweeps: If your incident response team has identified a unique string, mutex name, or C2 domain from a prior compromise, you can write a custom rule targeting that indicator and sweep all captured memory images across the enterprise.
• Credential Tool Detection: YARA rules targeting strings associated with credential dumping tools (e.g., the string "mimikatz" or specific function names from the Mimikatz source code) can identify whether an attacker used these tools, even if the executable was deleted from disk.

Warning

YARA is a pattern-matching engine, not an oracle. It can produce false positives (matching innocent data that happens to contain the same byte pattern) and false negatives (missing malware that has been obfuscated or packed). A YARA hit is a strong lead, not a conviction. Always validate matches by examining the surrounding context—the process, its parent, its network connections, and its command-line arguments.

---

9.5 Timeline Construction from Memory

Individual plugin outputs are snapshots. A timeline weaves those snapshots into a chronological narrative. Volatility 3 includes the timeliner plugin, which aggregates timestamped events from multiple sources within the memory image into a single, sortable output.

The Command:

python3 vol.py -f [Image.raw] timeliner --output-file timeline.csv

The timeliner plugin pulls timestamps from process creation times, loaded driver timestamps, network connection states, and other datable structures in memory. The resulting CSV can be opened in Timeline Explorer (Eric Zimmerman) or any spreadsheet application, sorted chronologically, and filtered by keyword.

Merging Memory and Disk Timelines

The real analytical power comes from merging this memory-derived timeline with disk-based timelines you have already learned to produce:

• MFTECmd output (Chapter 6): File creation, modification, and deletion timestamps from the Master File Table.
• EvtxECmd output (Chapter 6): Windows Event Log entries (logons, service installs, process creation).
• PECmd output (Chapter 6): Prefetch execution timestamps.

By importing all of these CSVs into Timeline Explorer (which supports loading multiple files simultaneously), you create a Super Timeline—a unified, chronological view of every forensically significant event across both volatile and non-volatile evidence sources.

Analyst Perspective

The Super Timeline is the deliverable that senior analysts and legal teams value most. It transforms hundreds of thousands of individual artifacts into a story: "At 10:02 PM, the user logged in (Event Log). At 10:03 PM, PowerShell executed an encoded command (Prefetch + Memory cmdline). At 10:04 PM, a new service was installed (svcscan + Event ID 7045). At 10:05 PM, an outbound connection was established to 185.x.x.x (netscan)." That narrative is what wins cases.

---

9.6 GUI-Based Analysis with MemProcFS

Up to this point, every memory analysis technique in this course has been command-line driven. Volatility 3 is powerful, but its plugin-by-plugin workflow can be slow for exploratory analysis, and its text-based output requires mental translation to visualize relationships. MemProcFS solves this problem by taking a fundamentally different approach to memory analysis.

What is MemProcFS?

MemProcFS (Memory Process File System), created by Ulf Frisk, is a framework that mounts a raw memory dump as a virtual file system. Instead of running a plugin and reading text output, you open Windows Explorer (or a Linux file manager) and browse the memory image as if it were a hard drive. Processes appear as folders. Registry hives appear as navigable directory trees. Network connections appear as readable text files inside process directories.

How It Works

MemProcFS uses the Dokany file system driver (on Windows) or FUSE (on Linux) to present the parsed memory data as a virtual drive letter. When you launch MemProcFS and point it at a raw memory dump, it performs the same kind of structural analysis that Volatility does—identifying the OS version, locating EPROCESS blocks, parsing registry hives—but instead of printing text to your terminal, it exposes the results as a directory tree that Windows treats as a real drive.

Installation and Setup

Unlike Volatility 3 (which is a Python framework you clone from GitHub), MemProcFS is distributed as a pre-compiled package. The installation process is straightforward, but there is one critical dependency you must install first.

Prerequisites:

• Dokany File System Driver: MemProcFS requires Dokany to create virtual drive letters on Windows. Dokany is a free, open-source user-mode file system driver.
  • Download the latest Dokany installer from https://github.com/dokan-dev/dokany/releases.
  • Run the installer and accept the defaults. A system reboot is typically required after installation.
  • You can verify the installation by checking that the "Dokan Library" service is running in services.msc.

Downloading MemProcFS:

1. Navigate to the official MemProcFS releases page: https://github.com/ufrisk/MemProcFS/releases.
2. Download the latest Windows release package (e.g., MemProcFS_files_and_binaries_vX.X.X-win_x64.zip).
3. Extract the ZIP archive to a folder on your forensic workstation (e.g., C:\Tools\MemProcFS\). There is no traditional installer—the tool is portable. You run it directly from the extracted folder.

Verifying the Installation:

Open a Command Prompt, navigate to the MemProcFS directory, and run:

memprocfs.exe -h

If you see the help output listing available command-line flags, the tool is ready. If you receive an error about a missing Dokany driver, revisit the Dokany installation step and confirm the service is running.

Warning

MemProcFS requires administrator privileges to create virtual drive mounts. Always run your Command Prompt (or PowerShell) as Administrator when launching MemProcFS. If you forget, the tool will fail with a permissions error when attempting to register the virtual drive letter.

Mounting a Memory Image

With Dokany installed and MemProcFS extracted, mounting a memory image requires a single command:

memprocfs.exe -device [Image.raw] -mount M:

• -device: The path to your raw memory dump (e.g., C:\Evidence\Case001\memory.raw). MemProcFS supports .raw, .dmp, .vmem (VMware snapshots), and several other formats.
• -mount: The drive letter to assign. Choose any unused letter. M: is a common convention (M for Memory), but any available letter works.

MemProcFS will spend a few seconds parsing the image. Once it finishes, drive M:\ appears in Windows Explorer just like a USB drive. You can also navigate to it via the command line with cd M:\.

To unmount the image when your analysis is complete, press Ctrl+C in the terminal window where MemProcFS is running, or close the terminal. The virtual drive letter will disappear.

Analyst Perspective

If your forensic workstation has Python 3 installed, you can also launch MemProcFS with the -forensic 1 flag to enable its built-in forensic analysis engine at mount time: memprocfs.exe -device [Image.raw] -mount M: -forensic 1. This pre-computes timelines, NTFS metadata, and other forensic outputs and places them in the M:\forensic\ directory automatically. Without this flag, the forensic directory may be empty or incomplete.

The Virtual File System Layout

After execution, drive M:\ appears in Windows Explorer. The top-level directory structure includes:

• M:\name\ — A folder for every process, named by its executable (e.g., M:\name\svchost.exe-1234\). Inside each folder, you find text files containing handles, loaded DLLs, memory maps, and more.
• M:\pid\ — The same process data, organized by Process ID rather than name.
• M:\registry\ — The full registry tree, browsable as a folder hierarchy. You can navigate to M:\registry\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\ and read the values as plain text files.
• M:\forensic\ — Pre-computed forensic outputs, including a timeline (CSV), NTFS MFT data (if recoverable), and file listings.
• M:\sys\net\ — Network connection data, presented as readable files.

Advantages Over Command-Line Workflows

• Speed of Exploration: Browsing folder structures is faster than running individual Volatility plugins and waiting for output. You can navigate to a suspicious process, check its DLLs, view its open handles, and read its command-line arguments within seconds—all by clicking through folders.
• Native Tool Integration: Because the memory is mounted as a drive letter, you can point any Windows tool at it. You can run your antivirus scanner against M:\ to check for malware signatures. You can open a suspect's cached .docx file directly in Microsoft Word from the virtual drive. You can load registry hives from M:\registry\ into Registry Explorer.
• Simultaneous Access: Unlike Volatility, where you run one plugin at a time, MemProcFS presents all parsed data simultaneously. You do not need to re-process the image for each question.
• Integrated Timeline: The M:\forensic\ directory often includes a pre-built timeline CSV that you can immediately load into Timeline Explorer without running a separate command.

Limitations

MemProcFS is not a replacement for Volatility 3; it is a complement. There are specific areas where Volatility remains the stronger tool:

• Custom Analysis and Scripting: Volatility's Python-based architecture makes it easier to write custom plugins or integrate with automated analysis pipelines.
• YARA Scanning: While MemProcFS supports some YARA integration, Volatility's yarascan plugin offers more granular control over scan scope and output formatting.
• Community Plugin Ecosystem: Volatility has a larger library of community-contributed plugins for niche analysis tasks (e.g., specific malware family decoders).
• Courtroom Familiarity: Volatility has a longer track record in legal proceedings. If you need to testify about your methodology, Volatility's widespread adoption and NIST-adjacent validation may carry more weight with a judge evaluating the Daubert factors (Chapter 2).

MemProcFS Analysis Workflow

Task	MemProcFS Path	Equivalent Volatility 3 Plugin
List processes	M:\name\ or M:\pid\	windows.pslist
View process DLLs	M:\pid\[PID]\modules\	windows.dlllist
View open handles	M:\pid\[PID]\handles\	windows.handles
Browse registry	M:\registry\HKLM\...	windows.registry.printkey
View network connections	M:\sys\net\	windows.netscan
Extract cached files	M:\pid\[PID]\files\	windows.dumpfiles
Pre-built timeline	M:\forensic\timeline\	timeliner

---

9.7 Putting It Together: A Phishing-to-Exfiltration Investigation

The following scenario walks through a realistic investigation that applies the techniques from both Chapter 8 and this chapter. The goal is to demonstrate how the plugins chain together to build a narrative.

Scenario: A financial services company detects an alert from their network monitoring system: a workstation in the Accounting department initiated a large outbound data transfer to an external IP address at 2:47 AM. The employee assigned to that workstation was not in the office. The incident response team captured a RAM dump from the running machine using DumpIt before isolating it from the network.

Phase 1 — Validate and Enumerate

The analyst runs windows.info to confirm the image is a Windows 11 22H2 build. Next, windows.pstree reveals the process hierarchy. Most processes look normal, but one branch stands out: OUTLOOK.EXE spawned WINWORD.EXE, which in turn spawned powershell.exe. A mail client launching Word is expected (the user opened an attachment), but Word spawning PowerShell is a classic indicator of a macro-based exploit.

Phase 2 — Investigate the Suspicious Chain

The analyst runs windows.cmdline filtered to the PowerShell PID. The output reveals an encoded command using the -EncodedCommand flag. Decoding the Base64 string with CyberChef shows a script that downloads a secondary payload from an external URL and executes it in memory.

Running windows.dlllist on the PowerShell process reveals a DLL loaded from C:\Users\Public\Libraries\—a non-standard path. Running windows.malfind confirms that PowerShell's memory contains executable code pages (PAGE_EXECUTE_READWRITE) with an embedded MZ header—injected malware.

Phase 3 — Extract Artifacts

The analyst uses windows.filescan to search for the .docx attachment that triggered the chain. It is found cached in memory, and windows.dumpfiles extracts it. The recovered document contains a malicious VBA macro.

Next, windows.netscan reveals two established connections from the PowerShell process: one to the external IP identified by the network alert (the data exfiltration channel) and one to a different IP on port 443 (the C2 server).

The analyst runs windows.hashdump and confirms that the local Administrator hash was loaded in memory. Combined with the C2 connection, this suggests the attacker harvested credentials for potential lateral movement.

Phase 4 — Threat Hunting Confirmation

To confirm the malware family, the analyst runs yarascan with a YARA rule set targeting known Remote Access Trojans (RATs). The scan hits on two rules associated with a known commodity RAT inside the PowerShell process memory space.

Phase 5 — Timeline and Reporting

The analyst runs timeliner and merges the output with disk-based Event Logs (captured separately from the forensic image). The merged timeline tells a clear story: the phishing email arrived at 2:31 AM, the macro executed at 2:33 AM, the C2 connection was established at 2:34 AM, credential harvesting occurred at 2:40 AM, and data exfiltration began at 2:47 AM—exactly when the network alert triggered.

---

Chapter Summary

This chapter advanced your memory forensics capability from initial triage to comprehensive investigation:

• Advanced Process Investigation using handles, dlllist, svcscan, and sessions allows you to determine not just what is running, but what resources it controls, what code it has loaded, and which user launched it.
• Artifact Extraction from memory—including registry hives via hivelist/printkey, cached files via filescan/dumpfiles, and credential hashes via hashdump—recovers evidence that may not exist on the hard drive, or that reflects a more current state than the on-disk version.
• Encryption Key Recovery from memory is the primary justification for live acquisition when BitLocker or VeraCrypt volumes are mounted. Without the key captured from RAM, full-disk encryption may render the drive permanently inaccessible.
• YARA Scanning with the yarascan plugin enables targeted threat hunting using known malware signatures and custom indicators of compromise, bridging the gap between threat intelligence and forensic analysis.
• Timeline Construction via the timeliner plugin, merged with disk-based timelines from MFTECmd and EvtxECmd, produces the Super Timeline—the single most valuable analytical product for both incident response reports and courtroom presentations.
• MemProcFS provides a modern, GUI-accessible alternative to command-line analysis by mounting memory images as virtual file systems. It accelerates exploratory analysis and enables integration with native Windows tools, complementing Volatility 3's strengths in scripting, YARA scanning, and courtroom-tested methodology.

In the next chapter, we shift from analyzing the operating system's internals to leveraging one of its most powerful built-in tools. Chapter 10: PowerShell Forensics will teach you how to use PowerShell both as an investigative instrument for live response and as a source of forensic artifacts that reveal attacker activity.