Rich Tinberg
9/10/2009
Independent Study 3991:
Computer Forensics Project
Rootkits
Submitted for completion of Independent study 3991
For the summer quarter of 2009 at the University of Denver
Computer Forensics Project
Professor Ramakrishna Thurimella
Objective:
The objective of this independent study was to create a rootkit that could be used
as a tool for teaching students of future computer forensics classes about rootkit software
detection and prevention. The software package I developed is designed to be an easily
installable package that can be used to infect machines running Windows XP.
What is a rootkit?
The purpose of a rootkit is to conceal, hide, or disguise its own existence by any
means necessary. Rootkits come in many different packages that can contain different
types of files and employ different methods to accomplish their purpose. Often, these
software packages are designed not to only conceal their own existence but the existence
of other malicious softwares that an attacker may wish to infect a compromised machine
with. When a computer is compromised with a rootkit it can become very difficult for the
user of the machine to realize their machine has been infected. Some rootkits methods of
stealth are so effective it is impossible to detect the rootkits presence without the use of
other third-party software.
“a rootkit is a set of programs and code that allows a permanent or
consistent, undetectable presence on a computer”1
It is important to realize that rootkits are not malicious software. They are a tool
commonly used for concealing malicious software or infecting a system with malicious
software but the rootkit itself is not malicious. It is also important to know that rootkits
are not always designed with devious intentions, as they can have some legitimate
purposes. Today, rootkits have become common practice for hackers because of their
ability of stealth. Hackers use them to launch DOS attacks from thousands of
compromised machines, steal credit card information, steal password and mine for other
information. If the user of a compromised computer does not know their machine is
infected, the attacker has free reign to do as they please with the compromised machine.
Accomplished rootkit coders can design rootkits with endless functionality that can
guarantee full access to all of the machines resources and memory. Needless to say
rootkits are extremely powerful and effective means of gaining full control of any
infected machine.
Why this was a good project for me:
This was a particularly interesting project for me because I previously had no
experience with windows programming or with rootkit programming. I enjoy being
challenged and having to learn new subjects. Going into this independent study I wanted
to come out with a new understanding of computers in a totally new area. I can honestly
say that I have learned a great deal from this project and I am also quite pleased with the
final result.
Sources and Readings:
As the project first started my primary concern was to learn about rootkits,
specifically how they work. The book “Rootkits, Subverting the Windows Kernel” by
Greg Hoglund and James Butler was extremely useful for this project. Much of the
material written on rootkits can be highly technical and difficult to understand but this
1
“Rootkits, Subverting the Windows Kernel” Greg Hoglund, James Butler, Addison-Wesley Publishing.
2
book was informative and easy-to-understand. It deals with many aspects of rootkit
design and is completed with code examples. The book is accompanied by the website
www.rootkit.com. It was also necessary for me to learn C++ coding in windows. It was
suggested that I try Microsoft Visual C++ Express version as my IDE for coding. Visual
C++ express comes with a help utility that is basically a refined internet searching utility.
This was a useful source for me during the project as I was trying to learn the windows
API, which required many hours of searching and reading through API documentation. I
previously only had experience coding using the Java Virtual Machine or on UNIX and
Linux machines. As a by-product of learning how to code a rootkit I learned how to code
windows device drivers. Windows has a software package named Windows Driver
Development Kit or Windows DDK. This package came with a help manual which was
also very helpful when learning how to build device drivers.
Rootkit Basics:
Creating a device driver is often the pre-cursor to creating the rootkit. Drivers
have “ring 0” access which sets them on an equal level with the windows kernel. Having
this access allows for the driver software to edit and change points in memory that
normal user-land programs would not be able to. In ring 0 a program can access and
modify any other process's memory space, which includes memory for the Windows
operating system itself. To load a Windows driver a user-land program is required, after
loading the driver it has free reign in ring 0. There are many driver loaders which are
publicly available. However, I wrote my own for the purposes of this project. Below is
an example of the Driver Loader I wrote for this project(which was eventually scrapped
for a non GUI version I wrote).
3
DrvLdr.exe
Once a driver is loaded into the windows driver list it executes its mandatory
DriverEntry() function. This is where the bulk of rootkit cloaking and stealth code is
implemented. This is where most rootkits will employ a method called hooking to cloak.
Hooking and the Windows Kernel
Hooking is the most commonly employed rootkit technique. To understand
hooking we must understand how the kernel handles system interrupts. When a system
interrupt or system call(sometimes referred to as SYSENTER) takes place, the kernel
must make a decision: what to do with the interrupt? The kernel keeps different tables for
different types of interrupts. When the interrupt is made the kernel checks system tables
for which type of interrupt it is, the table will return a memory address of the function to
be executed for that specific interrupt. The System Service Descriptor Table(SSDT) is the
table we're mostly interested in for this project. This is the table which contains the
memory address's for functions which are relevant to revealing operating system state
information(i.e. File Structure, Process Information, Registry Information etc...). The
idea of hooking is that you replace the original function address for certain system calls
in the SSDT with the address to a function which you have written yourself. Effectively,
we are overwriting sections of the SSDT that contain memory addresses of system
functions with our own function addresses. Replacing these addresses with the addresses
of functions we have written allows the rootkit to disguise itself. For instance the
addresses to the functions ZwQuerySystemInformation() and
ZwQueryDirectoryFile() are housed in the SSDT. The functions return information on
processes active in the system and files held on the hard-drive respectively. By reverse
engineering the functions in our rootkit, we can then replace their addresses in the SSDT
with the address of the function we have reverse engineered in the rootkit. Thus we have
effectively created a "System Hook".
Driver Hiding
Not all methods of cloaking require hooks. When a driver is loaded into windows
its information is stored in a circularly linked list(which you have a handle to when you
code the driver). This list is in un-protected and writable memory so the driver you
create, which functions in ring 0, can easily modify the list without having to hook a
function in the SSDT. Any user can find out which drivers are currently loaded on their
machine by using a number of different tools. Thankfully by using the handle to our
driver we can simply access the circularly linked list and re-assign the pointers from our
driver to the entries before and after it. Now the driver will be invisible when the system
makes a call to list the currently loaded drivers.
How this rootkit works
The rootkit package I designed is comprised of 4 different files:
AutoLoad.exe
Infect.exe
FakeVirusProc.exe
rootkit.sys
4
The package is desgined to be easy to use. Each file has a specific purpose within
the rootkit. To install the rootkit, unzip the files into a folder name "rootkit" anywhere on
the system. Once this is done, execute the Infect.exe file. Infect.exe will make the
necessary registry entries so the rootkit will survive reboot. The two registry entries will
be to auto-launch FakeVirusProc.exe and AutoLoad.exe on windows startup. After
Infect.exe makes the registry changes it will execute AutoLoad.exe which will load the
rootkit.sys driver into the system. Infect.exe will also execute FakeVirusProc.exe which
is just a busy-wait process designed to demonstrate rootkit process hiding capabilities.
Once the driver is loaded the rootkit will cloak all peices of the package. The only visible
aspect of the rootkit is going to be the registry entries made by Infect.exe. These entries
are necessary to de-activate the rootkit and clean the system. By deleting these entries the
rootkit will no longer survive reboot, thus the cloaking will not be active. The registry
entries are made in
HKEY_LOCAL_MACHINE->SOFTWARE->Microsoft->Windows->
CurrentVersion->Run
How do I know if my system is compromised?
This is a very difficult question to answer for two main reasons. First, rootkit
technology is constantly changing. As rootkit detection software becomes more
advanced, so does rootkit code. There will always be holes for rootkit designers to get
through. With rootkit methods changing so quickly it is hard for anyone to really stay a
couple steps ahead. Secondly, as noted, the primary purpose of a rootkit is to employ
stealth, it's always going to be hard to find something that has a sole purpose of not being
found. However, there are some tell-tale signs of a rootkits existance on a system: high
network traffic when not using the network, slower than usual performance, unverified or
unsigned drivers, and questionable processes. The problem with these symptoms is that in
most cases they are either un-reliable or take tedious attention to details(i.e. figuring out
what every process is/searching through loaded drivers). Also in most cases a well
designed rootkit will conceal all the information listed above.
Detection of Rootkits
Poorly designed rootkits will be visible without the use of third party detection
software. One way to find out if your machine is infected is to go into the device manager
and see which device drivers are loaded. If a ring 0 rootkit has not hid its own driver you
will be able to see that there is an unsigned and unverified driver that is running on your
machine. Using Start->Run->msinfo32 you’ll have all the system info you need.
5
msinfo32
This method is probematic though, because having to sort through the entire list of
drivers can take a very long time and since you probably wont recognize 50% of the
driver names to begin with this method is not going to be very effective. Another bruteforce method of detection is to search through the whole file system and look for things
that appear to be out of place, however once again this is extremely tedious and most
rootkits will have hidden thier files from view anyways. You can try to use the task
manager to look for suspicious processes or strange network usage, but again this is unreliable. The best option for detection of rootkit existence is to use third party detection
software. Microsofts Systems Internals division offers several useful tools, one of which
is name Rootkit Revealer. Rootkit Revealer reveales hidden files, hidden drivers, and
strange registry entries. Another usefule diagnostic too is Radix. Radix functions
somewhat differently than Rootkit Revealer. Radix will not only show hidden files and
hidden processes, but will also search the kernel for Hooks that are currently
implemented on the system. However, Radix and rootkit revealer can produce many
false-positives so it is important to exercise care when determining whether or not the
system is actually compromised. The tool in these software packages that produces the
least amount of false-positives is most likely going to be the detection of hidden files.
Normally there is no good reason for any files to be completely hidden from the users
view unless they are intended for malicious reasons.
6
Rootkit Revealer
Radix
Final Comments:
This project has been one of the most interesting learning experiences for me so
far in college. It started as a simple project on rootkits but was much more educational
than can be said. I learned aspects of GUI’s, the windows API, Driver Development,
Kernel fucntionality, Malware, Malware removal, Visual Express, QEMU, and of course
the increasingly relevant aspects of the modern Rootkit.
7