NT Internals


Hidden Process Detection Test

Hidden Process 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 Driver Detection Test

Attention:

Regarding to discussions and speculations about this test and tested software, I'd like to answer a few questions.

- Why I'm testing software which isn't anti rootkit software?
- Because I'd like to show that this non anti rootkit software may be useful (or not) for hidden process detection.

- Why I'm testing software which doesn't implement process detection?
- Once again, I'd like to show is tested software is useful for process detection or it isn't.

Introduction:

The main question we should answer at the beginning of this test is - should kernel mode rootkit hide user mode processes/threads or not? In my opinion, they shouldn't!
The idea of hiding processes probably has arisen with a first kernel mode rootkit - NTRootkit, written in 2001 by Greg Hoglund. Hiding of the processes was only one of many possibilities offered by replacing pointers of services stored in the SDT. About two years later after the NTRootkit publication, James Butler wrote another open source rootkit. FU was a PoC rootkit using new method called DKOM (Direct Kernel Object Manipulation) [01]. This method allowed to hide not only processes but also kernel modules and manipulation of tokens. In case of FU, the rootkit modified a doubly-linked list - PsActiveProcessLinks (processed by NtQuerySystemInformation indirectly) directly excluding hidden processes from it. Successor of FU rootkit - FUTo [02] was armed with few other methods of process hiding [02][03].
In 2003 Joanna Rutkowska released her PoC process detector - klister in version 0.3 [04]. Klister was based on very strong method - the analysis of thread scheduler lists - KiWait[In/Out]ListHead, KeDispatcherReadyListHead. Joanna wrote "while reading such internal list, we can be (almost;)) sure that we're getting list of all threads in the system (including those which belong to hidden process) and it also means that we can create complete list of ALL PROCESSESS in the system."[05]. First time, klister 0.3 was defeated by 90210 in 2004 [06]. At the same year, SoBeIt described his proposition of defeating thread scheduler list based detector [07]. Another answer on updated klister 0.4 was phide2 also written by 90210. In his article [08] 90210 wrote - "So, is Joanna now right when she says that "it is rather impossible to remove threads of the hidden process from the just mentioned dispatcher internal lists, because then, our hidden process, will not get any CPU time for execution"? The answer is no. It is possible to remove threads from those lists and to run our own thread scheduler that will schedule only our hidden threads.". The strongest method of process detection become defeated.
Instead of looking new and more efficient methods of process detection some software started uses the last resort - process detection based on interception [09]. One of the oldest and most efficient method is a SwapContext procedure interception [10]. Another popular and documented interception method uses system callbacks, called during process/thread creation and termination events. Callback routines registered by detection software allow to collect PIDs/TIDs and module names of created objects (processes). This kind of "detection" has of course many disadvantages. One of them is the fact that to "detect" rootkit process, detector's kernel module have to be loaded before rootkit's module to register callbacks which will intercept process/thread creation. If from any reasons rootkit's module will be loaded earlier then detector's one - anti rootkit based on this technique will show absolutely nothing! Second disadvantage of this method is the fact that even if process/thread creation event will be intercepted, there is a high possibility to remove the rootkit process record from the anti rootkit data base. Most of tested software naively belive that if the callback routine is called second time with Create flag set as false (which means that this process is exiting), it's time to remove this process from the data base without checking if it's true. Only Safe'n'Sec Rootkit Detector can't be fooled by this trick.
The story of process hiders doesn't end with FUTo or two other conceptual rootkits. There are few other PoCs focused on process hiding like: RKdemo by MP_ART (2006), newRootkit11 by card_magic (2006), famous phide_ex written by author of Rustock rootkit series - PE386 (2006) and Z0mBiE rootkit by EP_X0FF (2008) which manipulate on kernel objects from user mode.

Details:

Invisible Process 1.0 hides its process and thread objects using following methods:

- [-01-] - PspNotifyRoutine - RECALLING
- [-02-] - PsActiveProcessLinks - DKOM
- [-03-] - ObjectTable (HANDLE_TABLE) - DKOM
- [-04-] - CSRSS ObjectTable (HANDLE_TABLE) - ERASING
- [-05-] - PspCidTable (HANDLE_TABLE) - ERASING
- [-06-] - SessionProcessLinks - DKOM
- [-07-] - WorkingSetExpansionLinks - DKOM
- [-08-] - ObjectTypeList - DKOM
- [-09-] - CSR_PROCESS/CSR_THREAD - DKOM
- [-10-] - PID & IMAGE NAME - CHANGING
- [-11-] - OBJECT & OBJECT_TYPES - MANIPULATION
- [-12-] - THREAD OBJECT - MANIPULATION


GUI interface of Invisible Process 1.0


The PspNotifyRoutine method is especially invoked as the first one to prevent "process detection" by software which uses notify routines. Invisible Process 1.0 is "deactivating" notify routines from kernel mode. There is no tricks with re-spawned processes or kernel memory manipulation from user mode. Only after disarming callbacks and other interceptions (SwapContext) the test will show a real level of process detection. Invisible Process 1.0 has GUI interface, which of course shouldn't be used by real rootkits, because it drastically increases process detection possibility. The reason for GUI existence is to create easy in use testing tool. Such tools like Process Hunter, Process Master, and Safe'n'Sec Rootkit Detector have build-in "process detection" method based on user's windows enumeration, but in the higher hiding level they don't even show pid of hidden process. Invisible Process 1.0 has only one main thread (GUI thread). User mode module uses WM_TIMER notification to invoke some code at regular time intervals. The code is called every two seconds sending an updated (current time) string to the file output. Obviously when all methods will be called together (including PIDs modification) this will cause some trouble with GUI interface, since Invisible Process doesn't touch win32 subsystem. But it doesn't upset functionality of Invisible Process. The last method, which defeats all tested software, doesn't create own thread scheduler and doesn't touch thread scheduler lists, it is rather combination of thread and process objects manipulation.

Test Table
Software [-01-] [-02-] [-03-] [-04-] [-05-] [-06-] [-07-] [-08-] [-09-] [-10-] [-11-] [-12-]
ARK2007 1.0 - - - - - - - - - - -
ATool 1.0021 + - - - - - - - - - -
Avast! Antirootkit 1.0.0.1 + + + + + + + + + + -
AVG Anti-Rootkit 1.1.0.42 - - - - - - - - - - -
Avira AntiRootkit Tool 1.1.0.1 + + + - - - - - - - -
AVZ 4.32 + + + PID PID PID PID PID - - -
BitDefender Rootkit Uncover 1.0 + - - - - - - - - - -
CMC CodeWalker 0.2.4.500
CsrWalker 1.0.0.600 + + + + + + + - - - -
DarkSpy Anti-Rootkit 1.0.5 + + + + + + + + - - -
DeepMonitor 1.8 + + + + + + + + - - -
DiamondCS Deep System Explorer 1.0.406 + + + + + + + + - - -
Dr.Web DwShark 1.0.0.11140 + + + + + + + + + + -
ESET SysInspector 1.2.021.0 + - - - - - - - - - -
F-Secure BlackLight 2.2.1092.0 + + + + - - - - - - -
GMER 1.0.15.15227 + + + + + + + + + + -
Helios 1.1
Helios Lite 1.0 + + + + + + + + + + -
Hidden Finder 1.5.6.7 + + + - - - - - - - -
IceSword 1.2.2 + + + + + + + + + + -
Interactive Cleaner 1.0.0.135 + - - - - - - - - - -
Kernel Detective 1.3.0 + + + + + + + + + + -
KLISTER 0.4
KsBinSword 1.0.0.1 - - - - - - - - - - -
kX-Ray 1.0.0.98 + + + - - - - - - - -
Malware Defender 2.4.4 - - - - - - - - - - -
McAfee Rootkit Detective 1.1.0.1 + + + - - - - - - - -
NhsScan 0.9.4 + - - - - - - - - - -
NIAP Rootkit Detect Tools 1.02
Panda Anti-Rootkit 1.08.00 + + + + + + + + + - -
PScanner++ 1.8.3.0 - - - - - - - - - - -
Process Hunter 1.0 + + + + + + + + + - -
Process Master 1.1 + + + PID PID PID PID PID PID - -
Process Walker (EP_X0FF & MP_ART) 1.0.8 + + + + + + + + + + -
ProcessWalker Express 5.4.1000.10 - - - - - - - - - - -
RootKit Hook Analyzer 3.02 + - - - - - - - - - -
Rootkit Unhooker LE 3.8.LE.383.585.SR1 + + + + + + + + + + -
RootRepeal 1.3.5 + + + - - - - - - - -
Safe'n'Sec Rootkit Detector 1.0.0.2 + + + + + + + + + + -
SafetyCheck 1.7 + + + + + + + + + + -
SanityCheck 2.00 + + + + + + - - - - -
SnipeSword 1.0.2.2 + + - - - - - - - - -
Sophos Anti-Rootkit 1.5.0 + + - - - - - - - - -
SpyDLLRemover 2.5 + + + - - - - - - - -
Spyware Process Detector 3.20 + + + + + + + + + + -
SysProt AntiRootkit 1.0.1.0 + + + - - - - - - - -
SysReveal 1.0.0.7 + + + + + + + + + + -
System Eyes & Ears Monitor 4.5 + + + + + + + + - - -
Trend Micro RootkitBuster 2.80.1077 Beta + + + + + - - - - - -
USEC Radix 1.0.0.9 + + + + + + + + + + -
Vba32 AntiRootkit 3.12.5.1 + + + + + + + + + + -
Wsyscheck 1.68.33 + - - - - - - - - - -
XueTr 0.30 + + + + + + + + + - -
Yas Anti RootKit 1.223 + + + - - - - - - - -
Summary:

I've classified detection level into three classes. To the first (red) class belongs to software which couldn't detect process hidden by oldest process hiding methods including PspCidTable manipulation. In the second class (blue) there are software which uses additional methods of process detection. Same of these tools use strong methods, but they use them in a wrong way, so they can be easy defeated. The third class (green) belongs to anti rootkits which use process detection based on analysis of thread scheduler lists and scanning memory for known patterns. But as always, both process detection method can be defeated. For example, IceSword and SysReveal don't properly validate potential process's objects, so it is really easy to destroy their detection signatures. However, process detection based on analysis of thread scheduler lists has mistaken guidelines, that all listed threads must be valid objects. It's really interesting that an open source detector - Process Hunter is one of the best of tested detectors. Unfortunately, it has a few disadvantages which allow to defeat it, for example without MSR/IDT restoration. The same situation is with DeepMonitor which uses syscall interception. The biggest surprise during the test was Safe'n'Sec Rootkit Detector with its non-standard callback usage.

During the test I've had some troubles with some software. I tried to run Helios on XP SP2/3 but always the final result was this same - it couldn't properly recognize version of the operating system. Because klister is a PoC software prepared to be used with Windows 2000 systems only, I couldn't test it (but results of process detection by this tool are obvious). 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. CsrWalker, a PoC process detector is needing more explanations. It uses conceptual method based on analysis user mode structures stored by Csrss.exe (Client Server Runtime Process). Using this method CsrWalker can only obtain pid's/tid's of running processes/threads. But if Invisible Process will remove its process from these lists CsrWalker will be useless. Conclusion is that it can't be use as a real process detector. The same situation is with all detectors which use windows enumeration. If the rootkit will intercept appropriate services or will change pid's related to rootkit's windows, these tools wouldn't show suspicious pid. There are only twelve detectors which can detect processes hidden by potential modern malware - of course if we suppose there is no malware which use more sophisticated process hiding methods than used in FUTo and similar PoCs (phide, RKdemo, newRootkit11).

Should we be expecting new wave of malware process hiders? Rather not. Current malware rootkits doesn't worry about hiding something what really shouldn't be hidden. Latest variants of Rustock.C and TDL3 rootkits are proof of this theory. They hide injected DLLs instead of process hiding.

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 Process 1.0 is a private software, which was made for test purpose only!

Sample Video:

- Hidden_Process_Detection_Test.rar
- Hidden_Process_Detection_Test.rar (external mirror)

Updates:

- 07.12.2009 - added - Interactive Cleaner 1.0.0.135
- 30.12.2009 - retested - Spyware Process Detector 3.20
- 23.02.2010 - retested - Vba32 AntiRootkit 3.12.5.0
- 13.05.2010 - retested - Vba32 AntiRootkit 3.12.5.1

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 Process Detection improvements.

References:

[01] - Win2K Kernel Hidden Process/Module Checker 0.1 (Proof-Of-Concept)
[02] - Avoiding new methods of process detection
[03] - FUTo: Bypassing Blacklight and IceSword
[04] - Klister v0.3
[05] - Cheating klister?
[06] - Process Hide
[07] - Byepass Scheduler List Process Detection
[08] - Bypassing Klister 0.4 With No Hooks or Running a Controlled Thread Scheduler
[09] - Detection of the hidden processes
[10] - Detecting Hidden Processes by Hooking the SwapContext Function
[11] - CsrWalker - using csrss as rkdetector

Demo rootkits:

- NT ROOTKIT 0.44 (hoglund)
- FU Rootkit (fuzen_op)
- FUTo (petersilberman)
- phide (90210)
- phide2 (90210)
- newRootkit11 (cardmagic)
- RkU Test Rootkit aka Rkdemo (EP_X0FF & MP_ART)
- phide_ex (PE386)
- Z0mBiE (EP_X0FF)

Tested software:

ARK2007 1.0
ATool 1.0021
Avast! Antirootkit 1.0.0.1
AVG Anti-Rootkit 1.1.0.42
Avira AntiRootkit Tool 1.1.0.1
AVZ 4.32
BitDefender Rootkit Uncover 1.0
CMC CodeWalker 0.2.4.500
CsrWalker 1.0.0.600
DarkSpy Anti-Rootkit 1.0.5
DeepMonitor 1.8
DiamondCS Deep System Explorer 1.0.406
Dr.Web DwShark 1.0.0.11140
ESET SysInspector 1.2.021.0
F-Secure BlackLight 2.2.1092.0
GMER 1.0.15.15227
Helios 1.1
Helios Lite 1.0
Hidden Finder 1.5.6.7
HookShark 0.4
IceSword 1.2.2
Interactive Cleaner 1.0.0.135
Kernel Detective 1.3.0
KLISTER 0.4
KsBinSword 1.0.0.1
kX-Ray 1.0.0.98
Malware Defender 2.4.4
McAfee Rootkit Detective 1.1.0.1
NhsScan 0.9.4
NIAP Rootkit Detect Tools 1.02
Panda Anti-Rootkit 1.08.00
PScanner++ 1.8.3.0
Process Hunter 1.0
Process Master 1.1
Process Walker (EP_X0FF & MP_ART) 1.0.8
ProcessWalker Express 5.4.1000.10
RootKit Hook Analyzer 3.02
Rootkit Unhooker LE 3.8.LE.383.585.SR1
RootRepeal 1.3.5
Safe'n'Sec Rootkit Detector 1.0.0.2
SafetyCheck 1.7
SanityCheck 2.00
SnipeSword 1.0.2.2
Sophos Anti-Rootkit 1.5.0
SpyDLLRemover 2.5
Spyware Process Detector 3.20
SysProt AntiRootkit 1.0.1.0
SysReveal 1.0.0.7
System Eyes & Ears Monitor 4.5
Trend Micro RootkitBuster 2.80.1077 Beta
USEC Radix 1.0.0.9
Vba32 AntiRootkit 3.12.5.0
Wsyscheck 1.68.33
XueTr 0.30
Yas Anti RootKit 1.223

Legend:

- 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)
Copyright © 2oo8-2o1o NT Internals. All rights reserved.