Windows Memory Forensics: Reconstructing User Activity with Volatility3

Case Background

In our previous analysis https://www.dfirhive.com/post/windows-memory-and-process-analysis-volatility3-walkthrough, we focused on uncovering suspicious processes and file activity using the memory image from MemLabs5. We previously uncovered a rogue Notepad.exe within the user’s Videos directory, a password-protected RAR archive, and several related memory artifacts that outlined the attacker’s workflow.

This time, we’re taking the same memory dump further — moving beyond process-level analysis to understand what the user actually did on the system.

"Process trees tell us what ran. User activity artifacts tell us who ran it and how."

---

Objective

In this article, we’ll reconstruct the interactive user behavior from the same memory image to answer critical DFIR questions:

• Which user was active during the suspicious timeframe?

• What files or programs did the user open?

• Were these actions performed manually, or triggered automatically?

• How do memory-resident artifacts confirm user interaction beyond simple process execution?

  
  

By examining sessions, registry hives, UserAssist data, Shimcache entries, and live command-line traces, we’ll correlate user actions with the process execution chain discovered earlier.

---

1. Reconstructing Logged-In Sessions

Before diving into file and registry artifacts, it’s crucial to answer one fundamental question — who was actually logged in when this memory image was captured?

Knowing which sessions were active helps us map suspicious processes back to real, interactive users. Was the system accessed locally by a desktop user, or remotely by an attacker? Were multiple sessions active at once?

Windows constantly maintains data about interactive logins, console sessions, and remote connections, all stored in specific kernel structures. With Volatility 3, we can extract this information directly from memory and see the system through the eyes of its users.

---

Why Session Enumeration Matters

Every interactive session tells a story. If multiple sessions exist, it can indicate RDP activity, fast user switching, or even session hijacking. Even on a single-user workstation, seeing multiple concurrent sessions can immediately point to unauthorized access or impersonation.

By mapping processes to sessions, we can distinguish:

• Legitimate background activity (Session 0, SYSTEM-level processes), and

• Real human interaction (Session 1, 2, etc.)

This distinction is key — because attackers prefer hijacking existing desktop sessions rather than spawning new ones, blending in with legitimate activity.

---

Extracting Sessions from Memory

For this, We are using windows.sessions plugin. This module walks through kernel memory structures related to session management and extracts details such as:

• Session IDs

• Associated usernames

• Logon timestamps

• Session types (Console, RDP, etc.)

Each entry represents an active or recently active user context at the time of memory capture.

Command:

python3 vol.py -f MemoryDump_Lab5.raw windows.sessions > sessions.txt

"This command saves all discovered session data for review"

The results revealed multiple sessions: a system-level Session 0 and two user-interactive sessions (Session 1 and Session 2).

Session ID	Username	Description
0	SYSTEM	Core OS processes and services
1	Alissa Simpson	Interactive logon
2	SmartNet	Secondary interactive session

The presence of multiple console sessions is unusual for a standard workstation. While Alissa’s session appears normal (possibly the main user), SmartNet’s session stands out — its start time aligns precisely with the suspicious process execution window.

Key Activity

A new interactive session (SmartNet, Session 2) appeared and, immediately followed by a rapid burst of process launches:

• explorer.exe, WinRAR.exe, and multiple NOTEPAD.EXE instances executed within seconds of each other.

  
  

The compressed execution window and presence of Console-type processes indicate direct desktop interaction rather than automated background tasks.

Session 0 (SYSTEM) remained stable, showing only expected service activity, while Session 2 stands out as the first clear sign of hands-on user engagement—the likely moment the compromise became active.

---

2. Loading Registry Hive

With active user sessions confirmed, the next step was to determine which registry hives were resident in memory during acquisition. The Windows registry is one of the richest sources of evidence in memory forensics — holding configuration data, user profiles, recently accessed files, and traces of interactive activity.

Each logged-in user has their own registry hive, primarily stored in two files:

• NTUSER.DAT — captures per-user configuration and execution data, including UserAssist entries (a record of recently executed applications).

• UsrClass.dat — holds GUI and shell-related information such as folder views, pinned items, and file interaction history.

---

Enumerating Hives

Using Volatility 3’s windows.registry.hivelist plugin, I listed all registry hives present in memory:

python3 vol.py -f MemoryDump_Lab5.raw windows.registry.hivelist > hivelist.txt

This command enumerates all loaded hives — both system-level (e.g., SYSTEM, SOFTWARE, SECURITY) and user-specific (NTUSER.DAT, UsrClass.dat).

---

Output and Hive Dumping

The output confirmed that multiple hives were mapped in kernel memory, including those belonging to Alissa Simpson and SmartNet.

\??\C:\Users\Alissa Simpson\NTUSER.DAT
\??\C:\Users\Alissa Simpson\AppData\Local\Microsoft\Windows\UsrClass.dat
\??\C:\Users\SmartNet\NTUSER.DAT
\??\C:\Users\SmartNet\AppData\Local\Microsoft\Windows\UsrClass.dat

Note: All hives were listed as “Disabled,” which simply indicates that the lazy writer process (responsible for flushing registry data to disk) was inactive — the hives themselves were still fully loaded and valid for analysis.

To extract the hives for offline examination, the same plugin can be used with the --dump flag:

python3 vol.py -f MemoryDump_Lab5.raw windows.registry.hivelist --dump

This creates .hive files that can be examined using Registry Explorer (Eric Zimmerman), a GUI-based forensic tool designed to explore and extract data from Windows registry hives.

It allows to review key user artifacts — including application execution traces (UserAssist), file and folder interaction data (ShellBags), MRU lists, and system configuration information.

Findings

The output revealed that registry hives for both Alissa Simpson and SmartNet were fully loaded into memory, including their corresponding NTUSER.DAT and UsrClass.dat files:

The presence of these hives confirms that both user profiles were active and interactive when the memory was captured — not merely cached or dormant.

---

3. Graphical Interface Activity (UserAssist)

   
   

While processes and registry hives confirm what was running,

UserAssist is a Windows registry feature that logs executables launched via the graphical interface (Start Menu, Run dialog, Explorer double-clicks, or desktop shortcuts).Each entry is ROT13-encoded and records:

• The executable path

• The number of times it was run

• The timestamp of the last execution

Note: The presence of these entries in memory confirms hands-on GUI activity rather than background or automated execution.

---

Extracting UserAssist Data

We can parse the UserAssist data using Volatility3 windows.registry.userassist plugin:

python3 vol.py -f MemoryDump_Lab5.raw windows.registry.userassist > userassist.txt

This plugin reads from the NTUSER.DAT hive of each loaded user, decoding the relevant keys under:

Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist

Key Observations

For SmartNet, multiple entries were present — the most significant being:

C:\Program Files\WinRAR\WinRAR.exe
C:\Users\SmartNet\Videos\NOTEPAD.EXE

This timestamp corresponds precisely with the process timeline validating that all executed within the same one-minute window (03:47:13 – 03:48:00 UTC), reinforcing the interactive pattern. (The UserAssist timeline strongly supports the evidence seen in session and process data:)

The fact that it appears in UserAssist means it was launched through direct user interaction (e.g., double-clicked from File Explorer).

Note: The presence of these entries in memory confirms hands-on GUI activity rather than background or automated execution.

This aligns with our earlier hypothesis: the SmartNet account was compromised and actively used during the malicious event sequence.

---

4. Execution Evidence

While UserAssist data confirms what the user interacted with through the GUI, the command-line arguments reveal exactly how those processes were executed in memory. To capture this, Let's use Volatility3 windows.cmdline plugin.

---

Inspecting Process Commands

The plugin extracts command-line strings directly from each process’s PEB (Process Environment Block) — Inside the PEB, there's a structure called Process Parameters, which contains a pointer to the Unicode string holding the command line used to launch the process.

Command:

python3 vol.py -f MemoryDump_Lab5.raw windows.cmdline 

This command enumerates all processes and their execution arguments.

---

Command-Line Findings

• WinRAR was used to open or manipulate the archive SW1wb3J0YW50.rar located in the SmartNet user’s Documents directory.

• A rogue binary masquerading as Notepad was launched from the user’s Videos folder — a clear deviation from the legitimate C:\Windows\System32\notepad.exe.

  
  

Note: UserAssist shows that WinRAR was launched interactively from the SmartNet desktop, and the cmdline output proves it was executed with the argument C:\Users\SmartNet\Documents\SW1wb3J0W50.rar. Together these artifacts demonstrate that a user in the SmartNet session opened or operated on that specific archive.

---

5. Handles / DLLList

Volatility’s windows.handles and windows.dlllist plugins reveal open file objects and loaded modules for a given process. In this case, WinRAR’s handle table did not show the SW1wb3J0YW50.rar file, which can occur if the file was closed before the memory capture or if the process had already terminated.

Even so, examining its loaded DLLs is valuable —

• Normal WinRAR modules (unrar.dll, RarExt.dll) confirm expected behavior.

• Any anomalous or unsigned DLLs would suggest code injection or tampering.

A clean DLL list here supports the theory of user-driven compression activity rather than malware injection.

Command:

python3 vol.py -f THM-WIN-001_071528_07052025.mem windows.handles 

---

6. Locating the File

In our Windows Memory and Process Analysis, we had observed WinRAR.exe accessing a suspicious archive named SW1wb3J0YW50.rar and but we needed to confirm whether the file itself still resided in memory and what it contained.

To achieve this, we turned to Volatility’s file-related plugins — windows.filescan and windows.dumpfiles — which are designed to locate and extract active or recently accessed file objects from memory.

---

File Discovery and Extraction

Using these plugins, we located a memory-resident instance of SW1wb3J0YW50.rar, confirming that the file still existed in the captured image. We then extracted it using the dumpfiles plugin for inspection:

python3 vol.py -f MemoryDump_Lab5.raw windows.dumpfiles --physaddr <address>

Password Recovery and Archive Analysis

Upon inspection, the recovered .rar archive was found to be password-protected, a common tactic used during concealment.

To validate its purpose, we analyzed the memory dumps of explorer.exe and WinRAR.exe, performing a focused string search for RAR-related references.

Within the process memory, we successfully retrieved the password in plain text, allowing full decryption of the archive.

---

7. Additional Collaborations:

Plugin Name	Description / What It Does	Usefulness in User Activity Analysis	Additional Correlation / Notes
windows.registry.amcache	Extracts execution metadata from the Amcache registry hive if present in memory. Provides details such as file paths, SHA1 hashes, timestamps, and version data for executed applications.	High value (if hive present-Introduced around Windows 8; backported to late Win7 updates.). Confirms that an application was executed on the system. Often includes both system-wide and per-user data.	• Cross-check with userassist, cmdline, or recovered executables to confirm execution. • Hashes can be validated against known-malware databases. • Correlate with process start times to build timeline consistency. (Ref: SANS DFIR Amcache Analysis Guide)
windows.registry.printkey	Displays registry key names, values, and data from a specific hive and key path. Useful for directly examining registry structures (UserAssist, RunMRU, etc.).	Highly targeted. Allows deep inspection of user or system registry keys inside memory. Best for verifying data extracted via automated plugins.	• Use after hivelist or hivescan to manually confirm findings. • Can validate decoded UserAssist data or identify manual command history entries.(Ref: Volatility3 Official Docs — Registry Plugins)
windows.registry.scheduled_tasks	Parses scheduled task definitions stored in registry memory structures. Lists task names, executable paths, triggers, and timestamps.	Medium relevance for user behavior. Indicates persistence or automation created by a user or attacker (e.g., auto-launch of WinRAR or malicious scripts).	• Combine with sessions or userassist to determine if task creation aligns with the same user context. • Look for abnormal task triggers or executables in user space. (Ref: Microsoft Task Scheduler Forensics – Mandiant Blog)
windows.shimcachemem	Reads in-memory AppCompatCache (Shimcache) entries from ahcache.sys AVL tree. Lists executables observed by the OS, with file paths and modification timestamps.	Strong supporting artifact. Confirms presence of executables (e.g., NOTEPAD.EXE, SW1wb3J0YW50.rar) that Windows loaded or interacted with.	• Correlate with cmdline, userassist, or dumped binaries to show that these files existed and were processed by the OS. • Note: timestamps reflect file metadata, not execution time.(Ref: Mandiant AppCompatCache Whitepaper, 2014)

This concludes our analysis of user activity reconstruction from memory. I hope you found it insightful — do let me know your thoughts, feedback, or questions in the comments below.