Volatility Plugins — Plugin window.psxview Let’s Talk About it
- 1 minute ago
- 3 min read
If SSDT hooking shows you how rootkits control behavior
psxview shows you how they hide existence.
This plugin is one of the most important tools for rootkit detection in memory.
What psxview Really Does
psxview is a compound plugin.
It doesn’t invent new data — it compares existing views of processes gathered using different kernel mechanisms.
Why this matters:
Windows tracks processes in multiple places:
linked lists
PID tables
thread structures
user-session data
desktop objects
A rootkit can hide from one of these.
Hiding from all of them is extremely difficult.
This is the core idea behind cross-view analysis.
Cross-View Analysis
Cross-view analysis means:
Ask Windows for process information the normal way (high-level)
Independently discover processes using low-level structures
Compare the results
If something exists in one view but not another: someone is lying
Rootkits usually lie to the high-level views.
What psxview Compares
psxview runs multiple plugins and builds a comparison table.
Here’s what each source represents:
High-Level View
pslist
Reads the active process doubly linked list
Easiest place for DKOM rootkits to hide
This is your baseline “normal” view
Low-Level & Alternate Views
psscan
Scans memory for raw EPROCESS structures
Finds terminated, hidden, and orphaned processes
thrdproc(scan)
Reconstructs processes via thread parent PIDs
Very hard to fully clean up
pspcid
Uses the kernel PspCid table (PID tracking)
Another place attackers forget to clean
csrss
csrss.exe holds handles to user processes
Only valid for processes started after csrss
session
Groups processes by logon session
deskthrd
Maps processes via desktop-attached threads
How to Read psxview Output
Each process gets a row.
Each detection method gets a column.
True → process found via that method
False → process not found via that method
What you’re looking for:
Inconsistencies
Especially:
False in pslist
True everywhere else
That’s rootkit territory.
Legitimate “False” Values
Not every False means malware.
Some examples that are expected behavior:
System, smss.exe, csrss.exe
Started before csrss tracking exists
Will show False under csrss, session, deskthrd
Terminated processes
psscan may find leftover EPROCESS structures
Other views show no references
Real-World Example: FU Rootkit
The FU rootkit uses Direct Kernel Object Manipulation (DKOM).
Instead of hooking functions, it:
removes its process from the active process list
leaves the process alive elsewhere in memory
psxview Findings
Plugin | Result |
pslist | ❌ False |
psscan | ✅ True |
thrdproc | ✅ True |
pspcid | ✅ True |
csrss | ✅ True |
This is textbook DKOM behavior.
pslist — the high-level view — has been manipulated. Low-level structures still know the process exists.
That discrepancy is the detection.
Why pslist Is the “Canary”
pslist is the easiest place to hide.
So your rule of thumb:
If a process does not appear in pslist but appears elsewhere, investigate immediately.
This is how most rootkit detections start.
False Positive Example
You’ll often see something like:
psscan → True
everything else → False
Example:
csrss.exe
This usually means:
process exited cleanly
EPROCESS still present in memory
no active references remain
This is not malware — just memory artifacts.
The Important Question
If psscan already finds hidden processes, why do we need psxview?
Because context matters.
Without cross-view comparison:
you might assume the process is legitimate
you might miss that it was hidden from pslist
you lose the evidence of DKOM manipulation
psxview doesn’t just find processes —it tells you which kernel view was tampered with.
That’s critical for attribution and reporting.
Key Takeaways
psxview is a rootkit detector, not a process lister
Inconsistencies matter more than presence
pslist = high-level truth
psscan = raw reality
---------------------------------------Dean--------------------------------------------