LAPTOP i7

dlllist module

dlllist module list the mapped DLLs for each process. If no "-p" or "-o" parameter is given, the modules will list mapped DLLs for all processes. "dlllist" module show us the executable and any other DLLs loaded by the process.

Problems with dlllist module 

The problem with dlllist module is that most Windows executable maps lots of DLLs, so figuring out which ones are normal and which ones are malicious could be difficult and time-consuming.A bigger problem, however, is that more recently new ways,which are discussed below, of injecting DLLs into other processes have been developed that dont show when you run "dlllist" module.

Limitations of dlllist module

"dlllist" module will no longer see the DLLs which are unlinked from the LDR lists. The PEB points to many interesting data structures,such as three separate doubly-linked lists(LDR lists) of the DLLs that the process has loaded(provided it did so via the standard LoadLibrary call). But, as with the active processes linked list, a process is free to unlink a DLL from any or all of these DLL linked lists. The DLL,however will still reside in the virtual address space of the process, and there may be import address table pointers that will allow the functions in the DLL to be called by the process.

Detecting Unlinked DLLs With ldrmodules

"ldrmodules" compares the PEB list with data in the VAD. "ldrmodules" checks each allocated memory range in a process,using VAD, to see if it contains a mapped file and detects DLLs that are loaded in a process, even if theres no entry for the DLL in the processs PEB.
( When a process allocates memory with VirtualAlloc, the memory manager creates an entry in the VAD tree. Along with information such as the starting and ending addresses of the allocated memory block, the VAD contains some nested structures that, if present, can identify which file is mapped into the memory region.)

You can use the "ldrmodules" plug-in for volatility to inspect discrepancies between the PEB lists and the VAD. The plug-in shows the base addresses and full paths to all mapped executables in a process. It displays a column for each of the three PEB lists, which contain "True" or "False" based on whether a DLL with the same base address exists in the list.

Limitations of ldrmodules 

There are two main arguments about the method that ldr_modules uses for detection.

• First, a rootkit can use DKOM and overwrite members of the VAD after unlinking a DLL from the lists in the PEB. Then it will appear as if there is no memory-mapped file.
• The second argument is  about the method used by ldr_modules is that it is possible to load DLLs into a process without using LoadLIbrary("Reflective DLL Injection"), which does not create a mapped file in the VAD or any entries in the PEB.

malfind module

Limitations of "ldrmodules" module can be overcome by "malfind" plug-in.  It identifies suspicious memory ranges based on both the contents of memory and VAD characterstics, and optionally, a configurable list of signatures that is provided in YARA format.

• "malfind" dumps the memory ranges marked as executable and that had pool tag of "VadS" because all injected DLLs shows this property and hence it detects a majority of shellcode and DLLs injected into a process by a malicious process.

• "malfind" views hex dumps or disassemblies of suspicious area of memory for a quick preview of its contents.