PsXview in Vol3 not showing a hidden process

[aleksost]

Describe the bug
I ran through some old CTF memory images, and stumbled upon a potential bug in psxview. The memory image contains a hidden process discoverable with psxview. Running Volatility 3 with vol -f banking-malware.vmem windows.malware.psxview.PsXView did not return the hidden process, but running volatility 2.6.1 with vol.py -f banking-malware.vmem --profile=Win7SP1x64 psxview did. Hidden process name vds_ps.exe, PID 2448.

Context
Volatility Version: Volatility 3 Framework 2.27.0
Operating System: Ubuntu 24.04 (docker container, mirror.gcr.io/library/ubuntu:24.04), run on a MacBook pro M2
Python Version: 3.12.3
Command: vol -f banking-malware.vmem windows.malware.psxview.PsXView

To Reproduce
Steps to reproduce the behavior:

1. Download the memory image (https://cyberdefenders.org/blueteam-ctf-challenges/deepdive/)
2. Run the Volatility commands above

Expected behavior
Both versions of volatility psxview should display the hidden process, vds_ps.exe.

Example output
Example output from vol2 vol.py -f banking-malware.vmem --profile=Win7SP1x64 psxview | grep vds_ps
0x000000007d336950 vds_ps.exe 2448 False False False True True True True

Example output from vol3 vol -f banking-malware.vmem windows.malware.psxview.PsXView | grep vds_ps
<blank>

[ikelos]

The original author mentioned some of the checks that they didn't code into the vol3 version of psxview when they ported it over. It appears in your output the csrss should have found the process and in vol3 we're supposed to have that check and it hasn't found it.

Here's the original PR. @dgmcdona, you've tinkered with psxview in the past, any chance you could give this a look over please? I'll try and take a look myself, but it might be a while before I can find some time...

[dgmcdona]

Taking a look today since I have a long layover

[dgmcdona]

I downloaded the archive from the provided link and got this:

$ unzip -l ~/Downloads/78-DeepDive.zip 
Archive:  ~/Downloads/78-DeepDive.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
2147483648  10-19-2021 16:29   temp_extract_dir/banking-malware.vmem
---------                     -------
2147483648                     1 file

VMWare analysis with volatility3 always requires an additional metadata file, either a .vmss or .vmsn. Short of getting the challenge authors to provide the metadata file, I don't think there's an easy shortcut to analyze this sample, which is too bad because it looks like an interesting one.

[dgmcdona]

It looks like you actually can perform some analysis on this if you rename the file to banking-malware.raw, don't know how reliable those results will be though. The hidden process still doesn't appear so I'll see if there's something else going on with psxview.

[dgmcdona]

That analysis only worked because I unintentionally reused the config from an XP sample... 🥴

[ikelos]

Yep, some vmware images are just raw files, but because of the file format being split across files, we can't know which. It also turns out that a recent patch seems to detect the DTB as invalid because there's so few pointers in it (which is also annoying) so you need to dummy out the 0xFA0 chewck in automagic/windows.py.

So after all that, pslist works, but as the original poster mentioned, vds_ps.exe doesn't turn up. The question now is... why? 5:S

[dgmcdona]

The config had the file location in it, so it was just analyzing the other memory sample.

[dgmcdona]

Or were you able to analyze this one after making the changes?

[dgmcdona]

Nvm, made the change you suggested and am looking at valid-looking pslist results. I'll keep digging.

[dgmcdona]

The root of the issue is here, since .is_valid() always evaluates to false on the process in question due to this check:

volatility3/volatility3/framework/symbols/windows/extensions/__init__.py

Lines 732 to 736 in 98e2f7a

	# Quick smear test on thread Flink and Blink
	kernel = 0x80000000 # Yes, it's a quick test
	list_head = self.ThreadListHead
	if list_head.Flink < kernel or list_head.Blink < kernel:
	return False

[ikelos]

Hmmm, that's pretty deep in the windows code. 5:S We could add an (optional) parameter that tells it not to do such stringent checking, but actually, if malware is using it, then it suggests that the process can be valid even in that situation, so it might be a bad check?

[ikelos]

Good work on narrowing down the problem, by the way @dgmcdona, thanks!!! 5:D

[dgmcdona]

No problem! Second part of the problem, arguably more serious, is here:

volatility3/volatility3/framework/plugins/windows/malware/psxview.py

Lines 34 to 36 in 98e2f7a

	valid_proc_name_chars = set(
	string.ascii_lowercase + string.ascii_uppercase + "." + " "
	)

It filters out this process from all sources even after tweaking is_valid() because it contains an underscore. It would probably be best if filtering processes based on characters was optional instead of the default.

[ikelos]

I think the filtering is still reasonable, but underscore feels like it should be a legitimate character included in the valid_proc_name_chars, surely? We'd probably need to do tests to see which characters are actually invalid, but yeah that second test seems weak/overly protective.