|Hidden Driver Detection Test|
Hidden Driver Detection Test is another part of Hidden Data Detection Software test series. If you like to acquaint with other tests please visit these pages:
- Hidden Dynamic-Link Library Detection Test
- Hidden Process Detection Test
Kernel modules are cores of kernel mode rootkits. All malware rootkits use them to load their code into the kernel. Rootkits use them even if they need them only once - for example - to infect other module or to inject their user mode payloads. Rootkit's code injection based on loading of kernel modules is very ineffective. To load kernel module rootkit loader need to choose one of module loading methods. Mostly loaders use NtLoadDriver service. This method isn't the best choice, since loader need to access registry to create a new service key and few entries (not always). Loader also needed to create module file on the hard drive. Finally this method can be intercepted by notify routines, which are registered by some of security software's drivers. Of course, rootkit can hide its registry modifications, module file and bypass notify routines using services like NtSystemDebugControl, but all these actions are useless since rootkits don't need kernel modules. There are some undocumented services like NtSystemDebugControl or NtUserConsoleControl, which allow to overwrite kernel memory directly from user mode. In other words rootkit's code can be executed in kernel mode without touching registry or file system, all what is needed, is relocable kernel payload. Disadvantage of mentioned method is a fact that loaders need Administrator privileges to use these methods, but what if rootkit code could be loaded even from restricted account? It is possible with help of kernel components vulnerabilities if they haven't patched or 3rd party kernel modules which usually contain some vulnerabilities. So, why rootkits don't care about this possibility? The answer is simple - they don't need. Most users use an Administrator account as default account, so rootkits have all what they need to work.
The idea of hiding kernel modules probably has arisen with the FU rootkit. FU was a PoC rootkit using new method called DKOM (Direct Kernel Object Manipulation). This method allows to hide not only processes but also kernel modules and manipulation of tokens. In case of FU, the rootkit modified a doubly-linked list - PsLoadedModuleList (processed by NtQuerySystemInformation indirectly) directly excluding hidden modules from it. Next versions of FU and FUTo used additional methods of device/driver hiding. One of them is method based on excluding device and driver objects from object directories . In reply to this method Joanna Rutkowska wrote PoC detector which analyses kernel address space looking for valid driver objects and kernel modules . There's no doubt that pool scanning method is interesting and may help to detect even rootkits like Invisible Driver 1.0, but it must be properly written to avoid system crashes and false positives. Joanna's PoC detector was easy to defeat , but bugcheck developed this topic. He wrote great article  about grepping executive objects from pool memory. The only one thing which differ Invisible Driver 1.0 from other demo rootkits like: BadRKDemo by cardmagic, newRootkit11 by cardmagic, RKDemo1.2 by MP_ART, Unreal.A by MP_ART & EP_X0FF  is the latest hiding method based on bugcheck's theory.
Invisible Driver 1.0 hides its device and driver objects using following methods:
- [-01-] - PsLoadedModuleList - DKOM
- [-02-] - OBJECT_DIRECTORY - DKOM
- [-03-] - ObjectTypeList - DKOM
- [-04-] - DEVICE/DRIVER_OBJECT - ERASING
- [-05-] - DEVICE/DRIVER OBJECT_HEADER - ERASING
- [-06-] - OBJECT_TYPE - POINTER MANIPULATION
GUI interface of Invisible Driver 1.0
I decided to implement common method based on NtSystemDebugControl service to defeat detectors based on notify routines. Invisible Driver 1.0 also overwrites PE header (MZ signature only) to avoid detection of kernel module by DiamondCS Deep System Explorer. The driver creates system thread which invokes own implementation of HalMakeBeep. Thread modifies its start address, so software which use this field for malicious code detection will simply fail. The stealth code (and module) can be detected by kernel stack analysis - exactly like Radix does. That's why Invisible Driver 1.0 changes TID of system thread which causes that Radix doesn't classify this thread as malicious. The kernel module uses its own payload to obtain needed functions (this is remains related with other project). It also imports few functions (IoCreateDevice, DbgPrint, IofCompleteRequest) in usual way, so detection based on memory scanning is still possible.
|Information presented by tested software|
|Software||ModuleBase ||DriverObject ||DeviceObject |
|Avast! Antirootkit 0.9.6||?||?/?||?/?|
|AVG Anti Rootkit 126.96.36.199||?||?/?||?/?|
|DiamondCS Deep System Explorer 1.0.406||+||-/-||-/-|
|Dr.Web DwShark 188.8.131.5240||+||-/-||-/-|
|ESET SysInspector 1.2.021.0||+||-/-||-/-|
|Panda Anti-Rootkit 1.08.00||?||?/?||?/?|
|RootKit Hook Analyzer 3.02||+||-/-||-/-|
|Rootkit.Win32.TDSS remover 1.6.3||?||?/?||?/?|
|Safe'n'Sec Rootkit Detector 184.108.40.206||+||-/-||-/-|
|System Eyes & Ears Monitor 4.5||+||-/-||-/-|
|Trend Micro RootkitBuster 220.127.116.113||+||-/-||-/-|
|Vba32 AntiRootKit 18.104.22.168||+||-/-||-/-|
|Yas Anti RootKit 1.223||+||-/-||-/-|
The foregoing table shows what information are presented by individual anti rootkits. During the test some of anti rootkits couldn't show all information they provided, or presented information were incorrect. Some anti rootkits show only driver and device objects related to detected kernel module (+/-), few other can show independently driver and device objects (-/+) or both (+/+). These information can help to choose right tool to detect TDL3 rootkit presence.
|Avast! Antirootkit 22.214.171.124||-||-||-||-||-||-|
|AVG Anti-Rootkit 126.96.36.199||-||-||-||-||-||-|
|CMC CodeWalker 0.2.4.500||+||+||+||+||+ ||-|
|DarkSpy Anti-Rootkit 1.0.5||+||+||-||-||-||-|
|DiamondCS Deep System Explorer 1.0.406||-||-||-||-||-||-|
|Dr.Web DwShark 188.8.131.5240||+||+||+||-||-||-|
|ESET SysInspector 1.2.021.0||-||-||-||-||-||-|
|Hidden Finder 184.108.40.206||-||-||-||-||-||-|
|Kernel Detective 1.3.1||+||+||+||-||-||-|
|Malware Defender 2.6.0||+||-||-||-||-||-|
|NIAP Rootkit Detect Tools 1.02|
|Panda Anti-Rootkit 1.08.00||-||-||-||-||-||-|
|RootKit Hook Analyzer 3.02||-||-||-||-||-||-|
|Rootkit.Win32.TDSS remover 1.6.3||-||-||-||-||-||-|
|Rootkit Unhooker LE 3.8.386.589||+||+||-||-||-||-|
|Safe'n'Sec Rootkit Detector 220.127.116.11||-||-||-||-||-||-|
|SysProt AntiRootkit 18.104.22.168||+||-||-||-||-||-|
|System Eyes & Ears Monitor 4.5||-||-||-||-||-||-|
|Trend Micro RootkitBuster 2.80.1077 Beta||+||-||-||-||-||-|
|USEC Radix 22.214.171.124||+||+||+||-||-||-|
|Vba32 AntiRootkit 126.96.36.199||+||+||+||-||-||-|
|Yas Anti RootKit 1.223||+||-||-||-||-||-|
The test was carry out on real machine with Windows XP SP2 and virtual machine with Windows XP SP3. Some of tested software couldn't even detect driver hidden by simplest hiding method based on DKOM, but I decide to place them all in a comparison with other software for better contrast. As usual I've classified detection level into three classes. To the first (red) class belongs to software which couldn't detect driver hidden by two first hiding methods. In the second class (blue) there are software which uses additional methods of driver detection. The third class (green) belongs to anti rootkits which use driver detection based on analysis of kernel address space for known patterns.
Like in past test (Hidden Process Detection Test) also this time I've had some troubles with some software. I tried to run Helios on XP SP2/3 but always final result was the same - it couldn't properly recognize version of the operating system. NIAP Rootkit Detect Tools was another tool which had trouble with driver loading. Next DarkSpy was very unstable while testing on virtual machine and Yas Anti RootKit on real ones. I also had problems with USEC Radix it always hangs while scanning for IRP hooks.
There is only one detector which have driver detection strong enough to detect aggressive driver hiders. Undoubtedly CodeWalker uses most advanced detection techniques, but while hardcore scanning it hangs whole system, and obviously produces many false positives results.
Rustock series malware rootkits  initiated a new line of rootkits which abandon static pattern of typical rootkit. First variants of Rustock had typical kernel module which used to most of tested hiding methods, but finally Rustock.C abandon kernel module and started to infects other modules . Also latest waves of TDL 3 rootkit  shows that kernel module is only needed as transport of code which is injecting into the kernel and target driver. TDL 3 doesn't have device and driver objects related to its kernel module simply just because it doesn't use own kernel module (only first time), but its payload creates additional device and driver objects especially for IRP packed hooking. In this case detectors which have ability to show not only kernel modules but also driver and device objects can show these object as suspicious. It's strange because first version of TDL 3 used to typical IRP hooking with additional trick which initially defeated all public detectors. Now TDL's hooking mechanism is very clearly for everyone.
If any software isn't situated in this comparison and you think it should be - please let me know, I will test it and add to this comparison. Also if you don't agree with results of this comparison (some software should detects hidden driver on concrete level) - please let me know, I will test it again and correct results.
If you have any questions or suggestions regarding this test (lexical or grammatical mistakes, because English isn't my native language), please feel free to contact me. But please keep in mind that the Invisible Driver 1.0 is a private software, which was made for test purpose only!
Please let me know if you like to retest one of this software. In the future I'll not retest all newly published software without notification about its Driver Detection improvements.
- Hidden_Driver_Detection_Test.rar (external mirror)
- 23.02.2010 - retested - Vba32 AntiRootkit 188.8.131.52
- 21.05.2010 - retested - USEC Radix 184.108.40.206
 - How to properly hide a driver from the Object Directory with *NO HOOKS*
 - modGREPER - hidden kernel modules detector
 - Please don't greap me!
 - GREPEXEC: Grepping Executive Objects from Pool Memory
 - Unreal.A, bypassing modern Antirootkits
 - What makes the Rustocks tick!
 - TDL3 - Why so serious? Let's put a smile on that face ...
 - BackDoor Tdss 565 (aka TDL3)
- BadRKDemo by cardmagic
- newRootkit11 by cardmagic
RKDemo1.2 by MP_ART (unavailable)
Unreal.A by MP_ART & EP_X0FF (unavailable)
Avast! Antirootkit 220.127.116.11
AVG Anti-Rootkit 18.104.22.168
Avira AntiRootkit Tool 22.214.171.124
CMC CodeWalker 0.2.4.500
DarkSpy Anti-Rootkit 1.0.5
DiamondCS Deep System Explorer 1.0.406
Dr.Web DwShark 126.96.36.19940
ESET SysInspector 1.2.021.0
Hidden Finder 188.8.131.52
Kernel Detective 1.3.0
Malware Defender 2.6.0
NIAP Rootkit Detect Tools 1.02
Panda Anti-Rootkit 1.08.00
RootKit Hook Analyzer 3.02
Rootkit.Win32.TDSS remover 1.6.3
Rootkit Unhooker LE 3.8.386.589
Safe'n'Sec Rootkit Detector 184.108.40.206
SysProt AntiRootkit 220.127.116.11
System Eyes & Ears Monitor 4.5
Trend Micro RootkitBuster 2.80.1077 Beta
USEC Radix 18.104.22.168
Vba32 AntiRootkit 22.214.171.124
Yas Anti RootKit 1.223
- this icon means that this software is still "alive"
- this icon means that this software is currently "dead"
- this icon means you can download this software from trusted source (author's site)