home >> userland >> Hidden Process Detection

Hiding the Rootkit Process

TOP

Rootkits use variety of methods to hide their processes from detection as well as termination. One of the best methods the userland rootkit can employ to evade its detection is to hook the NtOpenProcess function and return negative result for its processes. This can not only protect rootkit processes from most of the detection methods, but also prevent its termination.

However, anti-rootkit software's typically use NtQuerySystemInformation to enumerate all the process ids, various handles related to process to uncover any hidden processes. To prevent against such detection, rootkits hook the NtQuerySystemInformation and temper with the results to cover all its tracks.

Detecting the Hidden Rootkit Process

TOP

Detection of hidden process is equally challenging as rootkit can employ one or more methods to cover its presence. Here are some of the very effective methods to detect any such rootkit processes.

All these detection methods work on common approach. First the list of running processes is obtained through standard API functions such as EnumProcesses or Process32First. Then any of the below methods is used to enumerate the processes and then that list is compared with previously obtained list through standard functions to find out hidden rootkit process.

HPD using Direct NT System Call Implemenation

TOP

This is very effective method to detect any hidden userland rootkit processes. One of the lesser-known methods of enumerating the processes is to use NtQuerySystemInformation function by passing first parameter as SystemProcessesAndThreadsInformation. The drawback of this method is that it can be easily circumvented by hooking the NtQuerySystemInformation function and then by tampering with the results.

The NtQuerySystemInformation is basically stub having few lines of code to transition from user to kernel land. It finally calls the NtQuerySystemInformation function within the kernel. So the trick here is to implement the NtQuerySystemInformation without directly calling the function.

Here is the sample code that shows how one can directly implement NtQuerySystemInformation on various platforms. On Windows2000, INT 2E and from XP onwards 'sysenter' instruction is used to transition from user to kernel.


  __declspec(naked)
  NTSTATUS __stdcall DirectNTQuerySystemInformation
          (ULONG SystemInformationClass,
		  PVOID SystemInformation,
		  ULONG SystemInformationLength,
		  PULONG ReturnLength)	
  {
										
										
	  //For Windows 2000
	  if( OSMajorVersion == 5 && OSMinorVersion == 0 )
	  {
		__asm
		{
			mov eax, 0x97
			lea edx, DWORD PTR ss:[esp+4]
			INT 0x2E
			ret 0x10
		}	
	
	}	
	
	//For Windows XP
	if( OSMajorVersion == 5 && OSMinorVersion == 1 )
	{
		__asm
		{
				mov eax, 0xAD     
				call SystemCall_XP
				ret 0x10
				
			SystemCall_XP:
			
				mov edx, esp
				sysenter
		}	
	
	}									
										
	//For Windows Vista & Longhorn
	if( OSMajorVersion == 6 && OSMinorVersion == 0 )
	{
		__asm
		{
				mov eax, 0xF8    
				call SystemCall_VISTA
				ret 0x10
				
			SystemCall_VISTA:
			
				mov edx, esp
				sysenter
		}	
	}
	
	//For Windows 7
	if( OSMajorVersion == 6 && OSMinorVersion == 1 )
	{
		__asm
		{
				mov eax, 0x105    
				call SystemCall_WIN7
				ret 0x10
			SystemCall_WIN7:
				mov edx, esp
				sysenter
		}	
	}					
										
										
     }								
  }
		

This technique can discover any userland rootkit process and only way for rootkit process to defeat against this technique is to move into kernel. However, due to low-level implementation, there is slight risk in using this method in production code.

HPD using PIDB (Process ID Bruteforce) method

TOP

This method was first used by BlackLight and it turned out to be very effective yet simple. Here, it enumerates through process id from 0 to 0x41DC and then check if that process exist by calling OpenProcess function. Then this list of discovered processes are compared with normal process list got using standard enumeration functions (such as Process32First, EnumProcesses functions).

During the testing, it is found that some process id on server machines were more than magic number 0x41DC. So in order to be effective the magic number is doubled to take care of all possible running processes on latest operating systems.

Here is the sample code that implements PIDB method:


 for(int i=0; i < 0x83B8; i+=4)
 {
   //These are system idle and system processes
   if( i == 0 || i==4 )
   {
   	 continue;
   }

   hprocess = OpenProcess
  	 (PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, i);

   if( hprocess == NULL  )
   {
	
	if( GetLastError() != ERROR_INVALID_PARAMETER)
	{
	// If the error code is other than 
	// ERROR_INVALID_PARAMETER that means this
	// process exists but we are not able to open.
		
	//check if this process is already discovered
	//using standard API functions.

	if( IsHiddenProcess(i) )
	{
		printf("\n Hidden process found %d", i);
	}
	}

	continue;
	}

	dwExitCode = 0;
	GetExitCodeProcess(hprocess, &dwExitCode);

	// check if this is active process...
	// only active process will return error 
	// code as ERROR_NO_MORE_ITEMS

	if( dwExitCode == ERROR_NO_MORE_ITEMS )  
	{
	  //check if this process is already discovered
	  if( IsHiddenProcess(i) )
	  {
		printf("\n Hidden process found %d", i);
	  }
	}
	CloseHandle(hprocess);
 }
		

Though this is very effective method, rootkit can easily defeat this technique by hooking OpenProcess or its native version NTOpenProcess function and then returning NULL with error code as ERROR_INVALID_PARAMETER. To defend against such tricks anti-rootkit softwares can call NtOpenProcess using direct system call method as shown in "Detection of Hidden Process using Direct NT System Call Implemenation".

HPD with CSRSS Process Handle Enumeration

TOP

Any windows process when run will have lot of open handles realted to process, thread, named objects, file, port, registry, etc. that can be used to detect hidden process. One can use the native API function. The effective way to enumerate handles is to use NtQuerySystemInformation with first parameter as SystemHandleInformation. It lists the handles from all running processes in the system. For each enumerated handle, it provides information such as handle, handle type and process id of the owning process. Hence, by enumerating through all the handles and then using the associated process id, one can detect all possible hidden processes that are not revealed through standard API functions.

There is one interesting system process called CSRSS.EXE, which holds the handles to all running processes. So instead of going through all the different handles, one can just scroll through the process handles of CSRSS.EXE process. Interestingly this method can, not only detect userland hidden processes but also some of the rootkit processes which have used kernel land techniques without taking care of hiding process handles within CSRSS.EXE process.

Here is the code snippet, which can demonstrate this method:


 PVOID bufHandleTable = malloc(dwSize);
 status = NtQuerySystemInformation
     (SystemHandleInformation, bufHandleTable, dwSize, 0);

 SYSTEM_HANDLE_INFORMATION *HandleInfo = 
     (SYSTEM_HANDLE_INFORMATION *) bufHandleTable;

// Process handles within CSRSS will not have handle 
// to following processes system idle process, system
// process, smss.exe, csrss.exe.

for(int i=0; i< HandleInfo->NumberOfHandles; i++)
{
  int pid = HandleInfo->Handles[i].UniqueProcessId;
	
  // For XP & 2K3 : HANDLE_TYPE_PROCESS = 0x5
  // For Vista & Longhorn : HANDLE_TYPE_PROCESS = 0x6
	
  if( HandleInfo->Handles[i].ObjectTypeIndex == 
                                  HANDLE_TYPE_PROCESS) 
  {
   //check if this process id is that of CSRSS.EXE process.

   if( IsCSRSSProcess(pid) ) 
   {
 	 hprocess = OpenProcess(PROCESS_DUP_HANDLE, false, pid);
	 
   if( hprocess )
   {
       if( DuplicateHandle(hprocess, 
	   (HANDLE)HandleInfo->Handles[i].Handle, 
	   GetCurrentProcess(), 
	   &tprocess, 
	   PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, 0))

	   {
		
		targetPid = GetProcessId(tprocess);

		 //check if this is hidden process

		 if( IsHiddenProcess(targetPid) )
		 {
		   printf("\n Found hidden process %d", targetPid);
		 }

	   }

	 }// End of if( hprocess )
		
   } // End of if( IsCSRSSProcess(pid) )

  } // End of if

 } // End of for-loop
		

Since the CSRSS.EXE is not first process started when Windows boots, it does not contains handles to already started processes such as system idle process(pid=0), system process (pid=4), smss.exe and its process itself.

On Windows Vista system it is possible to more than one CSRSS.EXE process in case of multiple users logged in. Same situation arises on XP system, when more than one user is operating through 'Switch User' mechanism. In such case, one has to check if the enumerated process belongs to any of these CSRSS process ids. The function IsCSRSSProcess() above does exactly the same by comparing the discovered process id with list of all running CSRSS.EXE processes.

One more way is to enumerate all thread handles within CSRSS process instead of process handles, as most rootkits are aware of this technique. The CSRSS process not only has process handles but also thread handles for every running processes. Once the thread handle is known, one can use GetProcessIdOfThread function to get process id associated with that thread after duplicating it.

Though any rootkit process can defeat this technique by hooking NtQuerySystemInformation or NtOpenProcess function, it can easily be circumvented by using direct implementation of these native API functions as described in the "Detection of Hidden Process using Direct NT System Call Implemenation".

Other Methods of Detecting Hidden Processes

TOP

There exists several other userland methods to detect hidden rootkit processes, but they are not as effective as the ones described above. However they can be used on need basis and often to target specific rootkit.

One such method is to enumerate through all the open Windows created by the processes within the system using EnumWindows API function and then calling the GetWindowThreadProcessId function to get the process id associated with that Window.

Here is the sample code that does the same...


 //Setup the callback function to enumerate through windows
 EnumWindows(EnumWindowsProc, NULL);

 //This is callback function to enumerate windows
 BOOL CALLBACK EnumWindowsProc(HWND hwnd, PARAM lParam)
 {
	DWORD procId;
	
	GetWindowThreadProcessId(hwnd, &procId);
	
	if( IsHiddenProcess(procId) )
	{
		printf("Found hidden process %d", procId);
	}

 }
 		

There exist several other ways to detect the hidden processes in user land and new ways are being discovered everyday. Though these detection techniques can be easily defeated from kernel land, they present simple and less risky mechanism to uncover the userland rootkits.

EvilFingers Arsenal




Socialize with RootkitAnalytics

Twitter Feed Blogspot

Links

Rootkits & Enterprise: Enterprise is a major victim to rootkits. What could rootkits do to them?[read more]

Rootkits & Home-users: Do home-users know the seriousness of rootkits? What should a home-user know about rootkits?[read more]

Rootkits & Information Warfare: What does the silent war of intelligence and national security, got to do with rootkit analysis?[read more]

Userland Rootkits: What should one know about userland rootkits?[read more]

Kernelland Rootkits: What should one know about kernelland rootkits?[read more]

ElfStat: ElfStat is a tool designed for detecting any kernel malware that modifies the text segment of the kernel in memory...[read more]

Syscall/Kernel function interception: This is a more stealth method of syscall hijacking without having to directly modify the syscall table; instead the first several bytes of the syscall are overwritten with a jump to the new code...[read more]

Syscall Interception: What should you know about Syscall interception by directly modifying the Syscall table?[read more]

KsiD [Kernel Symbol Interception Detection]: This tool is designed to detect kernel rootkits and kernel malware which hijack syscalls and kernel functions ...[read more]

IDT /dev/kmem rootkit method: This can be done using several methods including overwriting the first several bytes of the syscall with a jump to other code, or modifying the function pointers.[read more]

Hidden Process Detection: Hidden Process Detection [HPD] using Direct NT System Call Implemenation, PIDB (Process ID Bruteforce) method, CSRSS Process Handle Enumeration and other methods...[read more]

Hidden Registry Detection: Reason for Hiding the Registry Entries, Rootkit techniques to hide, and Detecting Hidden Registry Entries Using Direct NT System Call Method and Directly Reading Hives Method...[read more]

Hidden Service Detection: Hidden Rootkit Services Detection Methods...Enumerating Processes with 'NtControlPipe', Hook Bypass Method through Mapped Image, Services Enumerating Child Processes of Services.exe, Enumerating Services Registry Key...[read more]

Syscall Handler Checker [SHC]: This tool simply verifies whether or not the system call handler system_call() has been patched to call a phony sys_call_table. If a phony sys_call_table appears to be in use, a tool like elfstat can be used for further analysis...[read more]

Firmware Rootkits: Firmware is a small static code that runs on devices ranging from consumer electronics to anything that controls heavy machinery...[read more]

Hypervisor Rootkits: This comes under both firmware and hardware rootkits. The reason being, hypervisor is a virtual environment that runs on the hardware, but basically it is a firmware. Hence, we have drawn the line and dropped this rootkit in the firmware category of rootkits...[read more]

Publications: In this section, we are planning to list all the papers that we have published so far that are rootkit related.

Backdoor Ultimate Defender: In this paper (Backdoor.Win32.UltimateDefender.gtz - Reversing) we analyze install.exe that presents the typical structure of an Medium Evoluted Malware, with basical Obfuscated-Dummy Code...[read more]

Socialize: You could socialize with us by many ways...[read more]

About: Learn about rootkit analytics here...[read more]

Contact us: How can you reach us...[read more]

Our Team: Read more about the rootkit analytics team...[read more]

dwtf v1.0: dwtf is a DLL copying engine ... [read more]

Exploring ADS: Alternate Data Stream (ADS) is the lesser known feature of Windows NTFS file system which...[read more]

Installations [from RootkitAnalytics.com]

ToolsCount
~~~~~~~~~~~~~~~~~~~
Elfstat5846
dwtf4925
KsiD4376
SHC3443

NOTE: Our tools are listed in many sites and torrents, which makes it hard for us to track all downloads. Hence, we are listing only the total installations from our website.

Socialize with EvilFingers

Twitter Feed Blogspot LinkedIn Delicious Google

Tweets