Alright, let’s dive into a straightforward guide to memory analysis using Volatility. Memory forensics is a vast field, but I’ll take you through an overview of some core techniques to get valuable insights. Let’s go
Notes: "This is not a complete analysis; it’s an overview of key steps. In memory forensics, findings can be hit or miss—sometimes we uncover valuable data, sometimes we don’t, so it’s essential to work carefully."
Step 1: Basic System Information with windows.info
Let’s start by getting a basic overview of the memory image using the windows.info plugin. This gives us essential details like the operating system version, kernel debugging info, and more, which helps us ensure the plugins we’ll use are compatible.
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.info
Step 2: Listing Active Processes with windows.pslist
Now, I’ll list all active processes using windows.pslist and save the output. This helps identify running processes, their parent-child relationships, and a general look at what’s happening in memory.
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.pslist > ./testing/pslist.txt
I’m storing the output so we can refer back to it easily. With pslist, we can identify processes and their parent-child links, which can help detect suspicious activity if any processes don’t align with expected behavior. (I am using the SANS Material to make sure processes aligned with parent child)
Step 3: Finding Hidden Processes with windows.psscan
Next, we move to windows.psscan, which scans for processes, even hidden ones that pslist might miss. This is especially useful for finding malware or processes that don’t show up in regular listings.
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.psscan > ./testing/psscan.txt
After running psscan, I’ll sort and compare the results with pslist to see if anything stands out. A quick diff can reveal processes that may be hiding:
sort ./testing/psscan.txt > ./testing/a.txt
sort ./testing/pslist.txt > ./testing/b.txt
diff ./testing/a.txt ./testing/b.txtIn my analysis, I found some suspicious processes like whoami.exe and duplicate mscorsvw.exe entries, which I’ll dig into further to verify their legitimacy. (Later analysis mscorsvw is legit)
Step 4: Examining Process Trees with windows.pstree
To get a clearer view of how processes are linked, I’ll use windows.pstree. This shows the process hierarchy, making it easier to spot unusual or suspicious chains, like a random process launching powershell.exe under a legitimate parent.
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.pstree > ./testing/pstree.txt
During my analysis, I noticed a powershell.exe instance that used encoded commands to connect to a suspicious IP (http[:]//192.168.200.128[:]3000/launcher.ps1). This could be an indicator of compromise, possibly indicating a malicious script being downloaded and executed.
Step 5: Checking Command-Line Arguments with windows.cmdline
Now, I’ll use the windows.cmdline plugin to check command-line arguments for processes. This is helpful because attackers often use command-line parameters to hide activity.
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.cmdline > ./testing/
cmdline.txtHere, I’m filtering out standard system paths(System 32) to make it easier to focus on anything that might look unusual. If there’s any suspicious execution path, this command can help spot it quickly. (Make sure it doesn't means attacker run processes from comandline)
cat ./testing/cmdline.txt | grep -i -v 'system32'Step 6: Reviewing Security Identifiers with windows.getsids
To understand the permissions and user context of the processes we’ve identified as suspicious, I’ll check their Security Identifiers (SIDs) using windows.getsids. This can tell us who ran a specific process, helping narrow down potential attacker accounts.
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.getsids > ./testing/getsids.txt
I’m searching for the user that initiated each suspicious process to see if it’s linked to an unauthorized or unusual account. (For example if you see above screenshot we have identifed powershell and cmd execution)
So i have searched through text file:
cat ./testing/getsids.txt | grep -i cmd.exe
Step 7: Checking Network Connections with windows.netscan
Next, I’ll scan for open network connections with windows.netscan to see if any suspicious processes are making unauthorized connections. This is crucial for detecting any malware reaching out to a command-and-control (C2) server.
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.netscan > ./testing/netscan.txt
In this case, I found some closed connections to a suspicious IP (192.168.200.128:8443), initiated by powershell.exe. This further confirms the likelihood of malicious activity
Step 8: Module Analysis with windows.ldrmodules
To see if there are unusual DLLs or modules loaded into suspicious processes, I’ll use windows.ldrmodules. This can help catch injected modules or rogue DLLs.
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.ldrmodules > ./testing/ldrmodule.txtcat ./testing/ldrmodule.txt | egrep -i 'cmd|powershell'
In very simple language: If you see even single one false you have to analyse it manually whether its legit or not (Mostly you will got lot of false positive. This is where DFIR examiner is there to identify if this is legit)
Step 9: Detecting Malicious Code with windows.malfind
Finally, I’ll scan for potential malicious code within processes using windows.malfind. This command helps by detecting suspicious memory sections marked as PAGE_EXECUTE_READWRITE, which attackers often use.
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.malfind > ./testing/malfind.txt
Next step I have looked into PID for power shells/cmd. So i can dump those and run antivirus scan or use strings or bstrings.
cat ./testing/malfind.txt | grep -i 'PAGE_EXECUTE_READWRITE'
I have identified powershell PID and noted down dump an the powershell related malfind processes: (One by One) for PID 5908,6164,8308,1876(as per screemshot)
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.malfind --dump --pid 5908
Once done now u can run string or bstring to identify character in them or run full disk scan again dump or give it to reverse engineer(Thats on you)
(There are commnds avaible you can use those, Again this is an overview you can dig deeper. More commmands you can find in my previous article)
--------------------------------------------------------------------------------------------------------
Digging into Registry Hives
Step 1
Moving on to the registry, I’ll first check which hives are available using windows.registry.hivelist. Important hives like NTUSER.DAT can hold valuable info, including recently accessed files.
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.registry.hivelist
If you see above screenshot we have most important hives usrclass.dat and Ntuser.dat
Fist get a offset of usrclass.dat - 0x9f0c25e75000 and ntuser.dat - 0x9f0c25be8000 in our case
Than to check which data is avaible under these two hives:
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.registry.printkey --offset 0x9f0c25be8000 
As you can see screenshot little data is intact:
After this you can do two things First dump these hives and use tool like registry explorer to analyse further like normal windows registry analysis
or
You can do is dump all the output in txt file and analyse it here your choice:
Lets do with txt file:
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.registry.printkey --offset 0x9f0c25be8000 --recurse > ./testing/ntuser.txt
Step 2
Checking User Activity with UserAssist Plugin
The userassist plugin helps verify if specific applications or files were executed by the user—like PowerShell commands. Results may vary, and in this case, it might not yield any findings.
Lets suppose this does not work out for me: than use the above ntuser.dat method dumping all userassist into .txt using --recurse and analyse manually (Just change the offset)
example:
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.registry.printkey --offset 0x9f0c25e75000 --recurse > ./testing/usrclss.txt
Step 3
Scanning for Key Files with Filescan
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.filescan > ./testing/filescan.txtSee this is not necessary but why its important .(you can simply use above first and second steps to extract and dump for analysis using registry explorer or examining manually its on you
Lets suppose you ran filescan and saved output and you want to check which if you hives like SAM hives or security hives:
cat ./testing/filescan.txt | grep -i 'usrclass.dat' | grep 'analyst'This above command will grep usrclass,dat and then grep user analyst, because the powershell executed under user account analyst.
Now after going through i have identified multiple hives there that might be useful.
I have noted all the offset and what i am going to do is dump all the hives and analyse using registry explorer.
Step 4
Dumping Specific Files (Like NTuser.dat, usrclass.dat)
python3 vol.py -f /mnt/d/practice_powershell_empire/practice_powershell_empire.vmem windows.dumpfiles --virtaddr <offset>Use this for additional files or executable of interest. If data is retrieved, analyze it with tools like RegRipper.
Step 5
Similar to above you can search for keyword "history" in filescan.txt if you find history files related to browser or psreadline.txt dump it out analyse it.
If u dumping browser history us can browserhistory viewer from nirsoft
Step 6
Logs Analysis
you can search for logs in our case
cat ./testing/filescan.txt | grep -i '.evtx'
you can dump the logs and use evtxcmd to parse the logs and analyse it.
-------------------------------------------------------------------------------------------------------------
Once done with volatility what i always do. run the strings or bstrings.exe against my Memory images using the IOC i have identified to look for if i can get extra hit and i missed out something
example: (If you look above i have found launches.ps1 in IOCs) running strings and bstring again the memory image
bstring <dumped file> | grep -i 'launcher.ps1'
Below screenshot i looked for IP we have identified as IOC
This is what i do after running volatility you do not have do it but its on you!
How to run strings/bstrings.exe there is article created link below do check it out
-------------------------------------------------------------------------------------------------------------
Next I have run MemProc5 Analyzer:
Dirty Logs in MemProcFS
Examining logs, such as those found in MPLogs\Dirty\, reveals possible threats, like PowerShell Grampus or Mimikatz:
There are legit files as well u have to defined its legit or not
How to run MemProc5 there is article created link below do check it out
-------------------------------------------------------------------------------------------------------------
Conclusion
Alright, so we’ve walked through a high-level approach to memory forensics here. Each tool and plugin we used, like Volatility and MemProcFS, gave us a way to dig into different artifacts, whether it was registry entries, logs, or user files. Some methods hit, some miss—memory analysis can be like that, but the key is to stay thorough.
Remember, you may or may not find everything you’re looking for. But whatever you do uncover, like IOCs or specific user actions, adds to your investigation. Just keep at it, keep testing, and let each artifact guide your next step. This is all part of the process—memory forensics is about making the most out of what you have, one artifact at a time.
Akash Patel
Comments