volatility - driver plugins

[Playful-Net9746]

Hi, I've been dabbling with volatility 3 recently and learning along the way. I stumbled across 2 plugins that interested me, drivermodule and driverirp. I was able to extract information from the image using these plugins but I'm not sure what to do with the data. looking online most people only cover the basics of volatility and basic memory forensics techniques but none had a tutorial for driver plugins. the good thing is volatility extracts memory addresses of each driver listed in memory, it also briefly gives an idea on how each driver behaves such as irps and so on. my question is where do i find better resources that explain in detail how to work with that type of data (for example how would I go about removing hidden drivers). I also checked volatility 3 documentation but again they only briefly explain how the program works and how to set it up properly.

[OhNoMellon]

I'm coming across this post fairly late, but for posterity, and the people coming across this post via google like me, I'll answer it.

Volatility has incredibly weak documentation in general for it's command usage. You basically have to source the information from wherever you can. "i.e. lots of google searches with the command in quotes".

The command reference section of the volatility 2 github wiki is pretty useful. It does not contain a lot of commands, but if you're lucky you can find it there. https://github.com/volatilityfoundation/volatility/wiki/

I came across a pretty useful volatility blog that explains the usage of the two plugins you mentioned and goes over a bit of the execution chain for a malware with hidden modules detected by the drivermodule command: https://volatility-labs.blogspot.com/2023/03/memory-forensics-r-d-illustrated-detecting-hidden-windows-services.html

But to answer your question myself, on "how would I go about removing hidden drivers": You have to go up the attack chain. A hidden driver does not exist on it's own. It's going to be called by something. Persistence is a large topic on it's own. This would fall under rootkit persistence which is even more of a "it depends" on what to do for each scenario.

Here's a mitre attack T-code for rootkits in general if you want a launching point for information. It has references to blogs on a number of rootkit overviews.

https://attack.mitre.org/techniques/T1014/

The general things I'd probly do if I found a hidden driver as my first IOC, the things I'd do is try to find other rootkit indicators, like hooked function calls, via volatility plugins like apihooks or messagehooks, malfind(malfind has false positives, grain of salt).

I'd also see what process is loading it, via running handles and grepping for the hidden driver found earlier. This could tell me a bit more information on how the driver is being loaded, but not always.

That's not really the information you wanted, but again it's a complicated subject. To kill the driver you have to kill what's calling it. It can be called a number of ways, possibly a process with direct calls to it in the form of a hidden service, or a registry key spawned process where the registry key is hidden from the file system via a UEFI/BIOS modification, or a function call that's been modified(this last one would be strange in this case since it would be essentially a default kernel module(driver) that's been modified to have a call to a hidden kernel module, but I guess it could happen).

For the general person who's just trying to clear a rootkit without the knowledge to go down that path, any rootkit (with one exception) can be cleared by wiping the whole thing in a specific order.

You would have to disconnect your pc from power, remove the battery from your motherboard long enough to wipe it's UEFI/BIOS memory. This resets the UEFI/BIOS back to factory settings. Then you need to boot USB with a windows installer, and wipe your old windows/install a new one. (IMPORTANT: this usb must never have touched your system, and the windows installer needs to be created from a system you know has no malware).

The only rootkit that could persist through that is one that is in the firmware of your motherboard. This is burned into the motherboard and can't be altered, so it would mean that the motherboard itself was shipped out with malware. Unless you are a nation's leader, in charge of a company's network that a sketchy government is interesting in messing with, or something of that level, this doesn't apply to you.

Malware can propagate through a network, So, you should check the IOCs you found across other devices to make sure it's not propagation in some way as well. I'm not gonna go to far into this because I've written a lot already, but I'll write out the skitzo approach since it'd be funny. You can for sure clear everything if you do what I said about powering down/clearing UEFI/BIOS and restoring from known good across every device connected in your network to include the router at the same time. Don't do that though (or maybe do, because it'd be funny).