To list the kernel modules, you can use the modules plugin. This plugin relies on walking the doubly linked list of metadata structures (KLDR_DATA_TABLE_ENTRY) pointed to by PsLoadedModuleList (this technique is similar to walking the doubly linked list of _EPROCESS structures, as described in Chapter 10, Hunting Malware Using Memory Forensics, in the Understanding ActiveProcessLinks section). Listing kernel modules may not always help you identify the malicious kernel driver out of the hundreds of loaded kernel modules, but it can be useful for spotting a suspicious indicator such as a kernel driver having a weird name, or kernel modules loading from non-standard paths or the temporary paths. The modules plugin lists the kernel modules in the order in which they were loaded, which means that if a rootkit driver was recently installed, you are very likely to find that module at the end of the list, provided the module is not hidden and the system was not rebooted before the memory image was acquired.
In the following example of a memory image infected with the Laqma rootkit, the module listing shows the malicious driver of Laqma, lanmandrv.sys, at the end of the list running from the C:WindowsSystem32 directory, whereas most of the other kernel drivers are loaded from SystemRootSystem32DRIVERS. From the listing, you can also see that the core operating system components such as the NT kernel module (ntkrnlpa.exe or ntoskrnl.exe) and the hardware abstraction layer (hal.dll) are loaded first, followed by the boot drivers (such as kdcom.dll) which start automatically at the boot time and then followed by other drivers:
$ python vol.py -f laqma.vmem --profile=Win7SP1x86 modules
Volatility Foundation Volatility Framework 2.6
Offset(V) Name Base Size File
---------- ------------ ---------- -------- ---------------------------------
0x84f41c98 ntoskrnl.exe 0x8283d000 0x410000 SystemRootsystem32 tkrnlpa.exe
0x84f41c20 hal.dll 0x82806000 0x37000 SystemRootsystem32halmacpi.dll
0x84f41ba0 kdcom.dll 0x80bc5000 0x8000 SystemRootsystem32kdcom.dll
[REMOVED]
0x86e36388 srv2.sys 0xa46e1000 0x4f000 SystemRootSystem32DRIVERSsrv2.sys
0x86ed6d68 srv.sys 0xa4730000 0x51000 SystemRootSystem32DRIVERSsrv.sys
0x86fe8f90 spsys.sys 0xa4781000 0x6a000 SystemRootsystem32driversspsys.sys
0x861ca0d0 lanmandrv.sys 0xa47eb000 0x2000 ??C:WindowsSystem32lanmandrv.sys
Since walking the doubly linked list is susceptible to DKOM attacks (described in Chapter 10, Hunting Malware Using Memory Forensics, section 4.2.1 Direct Kernel Object Manipulation (DKOM)), it is possible to hide a kernel driver from the listing by unlinking it. To overcome this problem, you can use another plugin named modscan. The modscan plugin relies on the pool tag scanning approach (covered in Chapter 10, Hunting Malware Using Memory Forensics, section 4.2.2 Understanding Pool Tag Scanning). In other words, it scans the physical address space looking for the pool tag (MmLd) associated with the kernel module. As a result of pool tag scanning, it can detect unlinked modules and the previously loaded modules. The modscan plugin displays the kernel modules in the order in which they were found in the physical address space, and not based on the order in which they were loaded. In the following example of the Necurs rootkit, the modscan plugin displays the malicious kernel driver (2683608180e436a1.sys) whose name is composed entirely of hex characters:
$ python vol.py -f necurs.vmem --profile=Win7SP1x86 modscan
Volatility Foundation Volatility Framework 2.6
Offset(P) Name Base Size File
------------------ -------------------- ---------- ------ --------
0x0000000010145130 Beep.SYS 0x880f2000 0x7000 SystemRootSystem32DriversBeep.SYS
0x000000001061bad0 secdrv.SYS 0xa46a9000 0xa000 SystemRootSystem32Driverssecdrv.SYS
0x00000000108b9120 rdprefmp.sys 0x88150000 0x8000 SystemRootsystem32drivers dprefmp.sys
0x00000000108b9b10 USBPORT.SYS 0x9711e000 0x4b000 SystemRootsystem32DRIVERSUSBPORT.SYS
0x0000000010b3b4a0 rdbss.sys 0x96ef6000 0x41000 SystemRootsystem32DRIVERS dbss.sys
[REMOVED]
0x000000001e089170 2683608180e436a1.sys 0x851ab000 0xd000 SystemRootSystem32Drivers2683608180e436a1.sys
0x000000001e0da478 usbccgp.sys 0x9700b000 0x17000 SystemRootsystem32DRIVERSusbccgp.sys
When you run the modules plugin against the memory image infected with the Necurs rootkit, it does not display that malicious driver (2683608180e436a1.sys):
$ python vol.py -f necurs.vmem --profile=Win7SP1x86 modules | grep 2683608180e436a1
Since modscan uses the pool tag scanning approach, which can detect unloaded modules (provided that the memory has not been overwritten), it is possible that the malicious driver, 2683608180e436a1.sys was quickly loaded and unloaded, or that it is hidden. To confirm whether the driver was unloaded or hidden, you can use the unloadedmodules plugin, which will display the list of unloaded modules and the time when each one was unloaded. In the following output, absence of the malicious driver, 2683608180e436a1.sys, tells you that this driver was not unloaded and it is hidden. From the following output, you can see another malicious driver called 2b9fb.sys which was previously loaded and unloaded quickly (not present in the modules and modscan listing which is shown in the following code). The unloadedmodules plugin can prove to be useful during the investigation to detect the rootkit's attempt to quickly load and unload the driver so that it does not show up in the module listing:
$ python vol.py -f necurs.vmem --profile=Win7SP1x86 unloadedmodules
Volatility Foundation Volatility Framework 2.6
Name StartAddress EndAddress Time
----------------- ------------ ---------- -------------------
dump_dumpfve.sys 0x00880bb000 0x880cc000 2016-05-11 12:15:08
dump_LSI_SAS.sys 0x00880a3000 0x880bb000 2016-05-11 12:15:08
dump_storport.sys 0x0088099000 0x880a3000 2016-05-11 12:15:08
parport.sys 0x0094151000 0x94169000 2016-05-11 12:15:09
2b9fb.sys 0x00a47eb000 0xa47fe000 2018-05-21 10:57:52
$ python vol.py -f necurs.vmem --profile=Win7SP1x86 modules | grep -i 2b9fb.sys
$ python vol.py -f necurs.vmem --profile=Win7SP1x86 modscan | grep -i 2b9fb.sys