Tutorial Volatility 2.4 and memory analysis to detect a kernel rootkit

Storm Shadow

Administrator
Staff member
Developer
Ida Pro Expert
Elite Cracker
This demo shows how to use Volatility 2.4 and memory analysis to detect a kernel rootkit, extract it from memory, reverse engineer it, write a custom pool scanner, and then use what you've learned to develop new indicators.





http://volatilityfoundation.org
https://github.com/volatilityfoundation
http://www.memoryanalysis.net
http://volatility-labs.blogspot.com


Text to speech narration:


This video demonstrates how you can leverage Volatility and memory forensics to detect kernel rootkits, assist with reverse engineering, and use the results for developing additional indicators.

We begin by installing two malware samples. You can see them start running in Process Explorer, but they quickly disappear from view, including the files on disk.

We then simulate capturing memory by suspending the virtual machine.
Now we configure volatility’s location parameter and begin to list the processes. You can see lanmanwrk.exe and kerneldrv.exe running, although they’re hidden from process explorer.

Let’s run the SSDT plugin to check for hooks in the system call table. We filter for any functions that aren’t owned by the NT module or win32k.sys. You see 4 hooks pointing at lanmandrv.sys. These APIs are frequently hooked to hide resources from the running system.

The next command dumps the malicious driver and fixes the PE header image base to match where we found it in memory. Then we generate a list of imported API functions and format them as labels for IDA pro.

This gives IDA the extra context it needs to properly identify functions.

We copy this output to our clipboard and then open the dumped driver. Without the extra context, IDA is initially unable to tell you which API’s are being called. However, if you go to File, IDC Command, and paste in the impscan output, you’ll begin to see the reconstructed API names.

The ExAllocatePoolWithTag API is used to allocate kernel memory. Let’s investigate the parameters to this function. You see the driver uses a special tag 'ppc0' and requests non paged memory.

With this information, we can build a custom pool scanner with Volatility. We add the tag and memory type to a template and then run it to find all allocations made by this specific kernel driver.

The output shows unicode strings found in the kernel pools. You should recognize them to be the processes and files that the root kit is currently hiding from process explorer and basic file system directory listings.

However, if you didn’t previously know the names, you could find them using the procedure we showed here. Trace the SSDT hooks to the owning driver, extract it, and use reverse engineering to determine what resources it hides.

The last command shows how Volatility can dump the hidden processes, since we don’t rely on the live system APIs.

source youtube :)
 
Last edited:
Top