Windows Forensics Analysis PT III — Memory

Why this matters

Profiling the system is the very first step because it tells Volatility exactly how to interpret the memory image. Memory layouts, kernel structures, and offsets can vary between Windows versions and builds. Without the correct profile, all subsequent analysis could be inaccurate or even completely misleading.

Additionally, taking note of the system timestamp and other environment details helps us begin building a timeline of activity. This context is crucial when correlating suspicious processes, network connections, or artifacts to specific points in time during an investigation.

I always start here so Volatility knows exactly which symbols and offsets to use.

# Step 1: Check the memory image info
vol -f solarmarker.img windows.info

# Step 2: Based on output, set profile (Volatility 2 example)
vol -f solarmarker.img --profile=Win10x64_19041 pslist

We get: Windows 10 x64, build details, Kernel Base address, DTB, system time (2022-06-01 09:39:50 UTC), etc.

Why this matters

Identifying rogue processes is a critical first step in memory analysis because processes represent the active execution layer of an attack. By analyzing what is running (and what may have recently run), we can begin to uncover how an attacker gained execution, escalated privileges, and moved within the system.

Many attack techniques—such as fileless malware, living-off-the-land binaries (LOLBins), and process injection—rely on abusing legitimate processes to blend in with normal system activity.

windows.pslist (running processes) + windows.psscan (scans for terminated/hidden processes) + Volatility 2 pstree for the tree view.

When reviewing the results, look for anomalies such as:

• Unusual or unexpected process names
• Processes running from suspicious locations
• Duplicate or misspelled system process names
• Processes with abnormal parent-child relationships
• Recently terminated processes that appear suspicious

IOCs noted:

• services.exe → svchost.exe → msiexec.exe (PID 5340, SYSTEM)
• msiexec (5340) → msiexec.exe (PID 6872, now domain user)
• msiexec (6872) → powershell.exe (PID 5352) + conhost.exe (PID 6388)

Classic red flag: msiexec spawning PowerShell + privilege context switch.

In this step, we aim to build context around previously identified Indicators of Compromise (IOCs) while also looking for potential signs of additional IOCs.

To do this, we will examine several key details:

• Associated DLLs: Identify dynamic link libraries loaded by the process, as these can reveal malicious behavior or relationships with other compromised components.
• Command Line Arguments: Review the command-line arguments used by the process to uncover potentially suspicious flags, payloads, or obfuscation techniques.
• Security Content: Assess what security content the process is interacting with, which could provide insights into the attack's evasion tactics.
• Handles/Objects Accessed: Look into the handles or objects the process is interacting with (files, registry keys, network connections, etc.).

The first thing we'll examine is windows.cmdline, as this is relevant to the IOC we're investigating.

Unfortunately, there were no command-line arguments observed for the PowerShell or conhost processes, nor did we see any relevant output from the dlllist plugin.

Next, we need to examine the security context in which the PowerShell and conhost processes were running. Both processes are running as a domain user, which, depending on the user, may not be out of the ordinary. However, what stands out is the parent process—it appears that powershell and conhost were both spawned by msiexec.exe and subsequently by services.exe.

IOCs Noted: We see the suspicious process chain (6872,5340,5352,6388) running under security context of a domain user S-1-5-21-2601604243-3364590713-1171799579-1001

Here, we have two main plugins for examining network connections. Netstat displays all currently allocated and active connections that are still present. Netscan, on the other hand, scans memory to identify remnants of ended or unallocated connections.

By using both tools together, we can build a clearer picture of whether processes were communicating with external systems.

When reviewing the results, look for anomalies such as:

• Unusual or unexpected external IP addresses (especially rare, foreign, or known malicious ranges)
• Connections to suspicious or uncommon ports
• Processes that should not normally communicate over the network (e.g., lsass.exe, winlogon.exe)
• Multiple outbound connections from a single process to different IPs (possible C2 beaconing)
• Repeated connections to the same external IP (potential command-and-control communication)
• Short-lived or rapidly opening/closing connections (beaconing, failed callbacks, or scanning activity)
• Network activity from previously identified suspicious processes or IOCs
• Listening ports opened by suspicious or unknown processes

Here, we see the output from Netscan. There are no connections tied to our previous IOC chain. However, we do observe three external closed connections, all using IPv6. None have enough evidence to be labeled as having a bad reputation.

What is Code Injection? At its core code injection aims to execute malicious code in a target "victim" process.

Common Code Injection Types:

• Simple DLL Injection — Write a DLL path into remote process → force it to call LoadLibrary(path) via remote thread. Leaves obvious artifacts (disk file + loaded module list).
• Reflective DLL Injection — Write entire DLL binary into remote process → remote thread jumps to custom ReflectiveLoader export → DLL manually maps/fixes/loads itself (no LoadLibrary needed). Popular because it's fileless.
• Process Hollowing — Create legit process suspended → gut/hollow its original code → write full malicious EXE → fix headers/PEB/context → resume thread. Makes malicious code appear as the legitimate program.

Aspect	Simple DLL Injection	Reflective DLL Injection	Process Hollowing
Writes to disk?	Yes	No — fileless	No — fileless
Evasion strength	Low	Good	Good
MITRE ATT&CK	T1055.001	T1055.001	T1055.012

Here, we focus on two powerful Volatility plugins: windows.ldrmodules and windows.malfind.

windows.ldrmodules compares the three PEB loader lists (InLoad, InMemory, InInit) to detect unlinked/hidden DLLs.

windows.malfind scans process memory for suspicious regions that are marked executable (RWX), not backed by a file on disk, and often containing MZ/PE headers or shellcode patterns.

Unfortunately for us Volatility did not show any results for either module. It happens and the reason why we use multiple tools and techniques.

The next step is to focus on the drivers loaded into the system. Drivers are critical system components that run in kernel mode and can be exploited by attackers to maintain persistence, escalate privileges, or execute arbitrary code.

Key Artifacts to Review:

• Driver Names and File Paths: Suspicious or unusual driver names can indicate the presence of malware.
• Driver Memory Locations: A driver loaded into unexpected memory ranges could be indicative of manipulation.
• Driver Signed Status: Drivers that are unsigned or have invalid signatures may be malicious.
• Process Creation from Drivers: Investigating any processes that were created by drivers can uncover covert attacks.

Sample Commands (Volatility 3)

# Check SSDT for hooks (kernel system call redirection)
vol -f solarmarker.img windows.ssdt

# Identify IRP hooks in drivers
vol -f solarmarker.img windows.driverirp

# Cross-view hidden processes
vol -f solarmarker.img windows.psxview

# List loaded kernel modules/drivers
vol -f solarmarker.img windows.modules

# Scan for hidden/unlinked drivers via pool tags
vol -f solarmarker.img windows.modscan

# Detect drivers specifically hidden by rootkit techniques
vol -f solarmarker.img windows.drivermodule

Here we see output of ssdt plugin ran on memory. In Windows there are two options commonly seen in this table: ntoskrnl.exe and win32k.sys. If any others are found they are sure a sign of investigation.

Next up was the modules plugin. The vast majority of drivers are loaded from \systemroot\system32\drivers\* which allows us to filter out this location to identify anomalies.

Once we've identified suspicious artifacts, the next step is to extract them from the larger memory sample and perform in-depth analysis. This can include techniques such as static code analysis.

There are four main types of artifacts we can extract:

• Process Memory Sections: Useful for examining the raw data in memory, including hex and ASCII representations.
• Image-Mapped Files (DLL/EXE/SYS): Critical for determining code intent and identifying malicious IOCs within binaries.
• Cached File Objects: These may include files or objects accessed by a malicious process.
• Specialized Objects (MFT, Registry Hives): Useful for correlating file activity through MFT entries or extracting registry data.