[ News ] [ Paper Feed ] [ Issues ] [ Authors ] [ Archives ] [ Contact ]

..[ Phrack Magazine ]..
.:: Win32 Portable Userland Rootkit ::.

Issues: [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ] [ 51 ] [ 52 ] [ 53 ] [ 54 ] [ 55 ] [ 56 ] [ 57 ] [ 58 ] [ 59 ] [ 60 ] [ 61 ] [ 62 ] [ 63 ] [ 64 ] [ 65 ] [ 66 ] [ 67 ] [ 68 ] [ 69 ]
Current issue : #62 | Release date : 2004-07-13 | Editor : Phrack Staff
IntroductionPhrack Staff
LoopbackPhrack Staff
LinenoisePhrack Staff
Phrack Prophile on scutPhrack Staff
Bypassing Win BO Protectionjamie butler & anonymous author
Kernel Mode Backdoor for NTfirew0rker
Advances in Windows Shellcodesk
Remote Execgrugq
UTF8 Shellcodegreuff
Attacking Apache Modulesandi
Radio Hackingshaun2k2
Win32 Portable Userland Rootkitkdm
Bypassing Windows Personal FW'srattle
A Dynamic Polyalphabetic Substitution Cipherveins
Playing Cards for Smart Profitender
Phrack World NewsPhrack Staff
Title : Win32 Portable Userland Rootkit
Author : kdm
                           ==Phrack Inc.==

              Volume 0x0b, Issue 0x3e, Phile #0x0c of 0x10

|=---------=[  NTIllusion: A portable Win32 userland rootkit  ]=--------=|
|=------------------=[  Kdm <Kodmaker@syshell.org>  ]=------------------=|

This paper describes how to build a windows user land rootkit. The first
part deal with the basis and describe a few methods to show how code
injection and code interception are possible, while the rest of the paper
covers the strategy that makes stealth possible in userland. A bigger
version of the paper is also available at [1] so that novice peoples can
refer to a preliminary article about injection and interception basics.

Table of contents

1. Introduction
2. Code Injection and interception
	2.1. System Hooks
	2.2. CreateRemoteThread
	2.3. Manipulating thread's context
	2.4. Redirecting the Import Address Table
	2.5. Inserting an unconditional jump (jmp)
3. User land take over
	3.1. User land vs Kernel land rootkits
	3.2. Restrictions...
	3.3. ...and constraints
	3.4. Setting a global hook to take over userland
	3.5. Local application take over
4. Replacement functions
	4.1. Process hiding
	4.2. File hiding
	4.3. Registry
	4.4. Netstat like tools.
	     4.4.1. The case of windows 2000
	 Hooking GetTcpTable
	 Defeating netstat
	 Defeating Fport
	     4.4.2. The case of windows XP
	4.5. Global TCP backdoor / password grabber
	4.6. Privilege escalation
	4.7. Module stealth
5. Ending
	5.1. Conclusion
	5.2. Greets
6. References

-------[ 1. Introduction
  A rootkit is a program designed to control the behavior of a given 
machine. This is often used to hide the illegitimate presence of a 
backdoor and others such tools. It acts by denying the listing of certain 
elements when requested by the user, affecting thereby the confidence that
the machine has not been compromised. 

There are different kinds of rootkits. Some act at the very bases of the 
operating system by sitting in kernel land, under the privileged ring 0 
mode. Some others run under lower privileges in ring 3 and are called user 
land rootkits, as they target directly the user's applications instead of 
the system itself. These ring 3 rootkits have encountered a recrudescence 
the last years since it is somewhat more portable and polyvalent than ring 
0 ones.
As there are multiple ways to stay unseen under windows, this article
performs a windows rootkitting tutorial based on a strong implementation
called the [NTillusion rootkit] which fits maximum constraints.

This rootkit has been designed to be able to run under the lowest 
privileges for a given account under windows. Indeed, it doesn't use any 
administrative privilege to be able to perform its stealth as it resides 
directly inside processes that are owned by the current user. In a word, 
all the ring 3 programs that a user might use to enumerate files, 
processes, registry keys, and used ports are closely controlled so they 
won't reveal unwanted things. Meanwhile, the rootkit silently waits for 
passwords, allowing the load of any device driver as soon as an 
administrator password is caught.

How does this works?
All this stuff is done in two steps. First, by injecting the rootkit's 
code inside each application owned by the current user and finally, by 
replacing strategic functions by provided ones. Theses tricks are 
performed at run time against a running process rather than on hard disk 
on binaries since it allows to work around the windows file protection, 
antiviral and checksum tools as well. The rootkit has been tested 
successfully under windows 2000/XP, but may also run on older NTs. It's
architecture allows it to be ported to windows 9x/Me but some functions
are missing (VirtualAllocEx) or behave abnormally (CreateRemoteThread) on
this version of the OS.

This introduction would not have been achieved without comments about the 
different sections of the paper that present each special characteristics.
Section 3 deals about user land take over. This mechanism has already been
presented by Holy_Father in [HIDINGEN]. However it is here done in a 
different way. In fact, the rootkit acts globally a level higher so things
are changed and it results in a somewhat simpler but efficient spreading
method. And contrary to Hacker Defender ([HKDEF_RTK]), NTillusion does not
need the administrative privilege. So the approach I propose is different.
This approach is also different when speaking about the way functions are
chosen and replaced.
This is the case with section 4 which introduces an uncommon way to 
replace original functions. On one hand, the functions are most of the time
replaced at kernel level. So, I hope this paper shows that performing a
good stealth is possible also in userland. On the other hand when thinking
about API replacement, people try to dig as much as possible in order to
hook at the lowest level. This is sometimes a good thing, sometimes not.
This is especially true with portability, which suffers from this run to
low level. NTillusion replaces top level APIs as often as possible.
As windows designers want programs that rely on the documented API to be
portable from one windows version to another, and as the rootkit hijacks
critical functions among this documented API, portability is accrued.
Thereby there's no need to perform OS version check and it results in a
more universal rootkit. Added to that, this section offers a new way for
privilege escalation by showing how hooking the POP3/FTP traffic is
possible in order to get login and passwords. 

This is not the only new thing: section 4.7 offers a new way to hide a DLL
loaded inside a given process. Usually, this would have been done by
hooking modules enumeration APIs inside the memory space of each process
able to reveal the rootkit. However I show how this is possible to do this
by dealing directly with undocumented structures pointed by the Process
Environment Block. Once this has been done, there's not need to worry
about subsequent detection. To test this method I downloaded a rootkit
detector, [VICE], and scaned my system. With no rootkit loaded, VICE
produced most of the time some false positive for standart DLLs (kernel32/
ntdll/...). Once the rootkit was loaded and using this technique, there
was no noticable change and VICE was still accusing some system DLLs to be
rootkits as before but there was no record about kNTIllusion.dll that was
however doing the job efficiently. 

-------[ 2. Code Injection and interception
The goal of this section is to allow a process to replace the functions
of another. This involves getting control of the target process, then
to replace parts of it's memory carefully. Let's begin with code injection.
So altering the behavior of a process requires to break into it's memory 
space in order to execute some code to do the job. Fortunately, windows 
perfors checks to prevent an application to read or write memory of an 
other application without its permission. Nevertheless the windows 
programmers included several ways to bypass the native inter-process 
protection so patching other processes' memory at runtime is a true 
possibility. The first step in accessing a running process is done trough 
the OpenProcess API. If the application possesses the correct security 
permissions, the function returns a handle to deal with the process, in 
the other case, it denies access. By triggering a proper privilege, a user 
may get access to a privilegded process as we'll see later. In Windows NT, 
a privilege is some sort of flag granted to a user that allows the user to
override what would normally be a restriction to some part of the
operating system. This is the bright side. But unfortunately there is
also a seamy side. In fact there's multiple ways to break into the memory
space of a running process and running hostile code in it, by using 
documented functions of the windows API. The following methods have
already been covered in the past so I will only give an overview.

-------[ 2.1. System Hooks
The most known technique uses the SetWindowsHookEx function which sets a 
hook in the message event handler of a given application. When used as a 
system hook, i.e. when the hook is set for the whole userland, by relying 
on a code located in a dll, the operating system injects the dll into each 
running process matching the hook type. For example, if a WH_KEYBOARD hook 
is used and a key is pressed under notepad, the system will map the hook's 
dll inside notepad.exe memory space. Easy as ABC... For more information
on the topic, see [HOOKS] and [MSDN_HOOKS]. Hooks are most of the time
used for develop