MALWARE

Although the term is still gaining traction in mainstream circles, malware is generally accepted among more technical folk as a term that encompasses all forms of malicious software, including:

• Viruses Infectious programs that can reproduce themselves but require interaction to propagate.

• Worms Infectious programs that can self-propagate via a network.

• Rootkits and back doors Programs designed to infiltrate a system, hide their own presence, and provide administrative control and monitoring functionality to an unauthorized user or attacker.

• Bots and zombies Very similar to rootkits and back doors, but focused additionally on usurping the victim system's resources to perform a specific task or tasks (for example, distributed denial of service against an unrelated target or send spam).

• Trojan horses Software that does something other than, or in addition to, its purported functionality. Usually, this means installing a rootkit or back door.

In contrast to spyware, adware, and spam, malware has obvious and indefensibly malicious intent .

Although the classes of malware we just described have historically infected systems of all makes and models, our discussion in this section will focus primarily on Microsoft Windows variants, again due to the overwhelming preponderance of malware targeted at the widely deployed Windows platform today.

Our discussion will first focus on the most popular variants of malware circulating today, attempt to derive some common attack themes in parallel, and, finally, provide some concrete and abstract countermeasures that you can implement to prevent, detect, and/or respond to malware attacks.

Malware Variants and Common Techniques

Our discussion is aligned around the classes of malware we described previously: viruses, worms, rootkits and back doors, and bots and zombies.

Viruses and Worms

Viruses and worms remain the most popular forms of malware in circulation today. Entire books have been written on these infectious critters, and we're not going to spend a lot of time discussing them here. Instead, we point the reader to the abundant information available on the Internet describing recent and long- dormant viruses and worms. Some of our favorite sites include:

• http://vil.nai.com/vil/default.asp

• http://securityresponse. symantec .com

• http://www3.ca.com/securityadvisor/virusinfo/default.aspx

• http:// sophos .com/virusinfo

Although the sites listed here are more authoritative , our own personal perspective on common virus/worm trends and techniques was covered fairly well in the earlier section of this chapter titled "A Brief History of Internet Client Hacking." Here are the most important qualities to consider for viruses and worms:

• Propagation mechanism

• Payload

• Insertion points

• Detection avoidance

From our perspective, the dominant virus/worm propagation mechanisms of the last several years have been e-mail attachments and software vulnerabilities such as buffer overflows (for example, the MyDoom virus propagated via e-mail attachment, and the Slammer worm propagated by exploiting a remote buffer overflow in Microsoft's SQL server). As long as humans remain the dominant interactive and creative agents for software, these trends are not likely to change anytime soon.

Payloads and post-infection activities have focused primarily on self-propagation and remote control of the victim system (via rootkits, back doors, bots, or zombies, which we will discuss in more detail momentarily). Slammer in particular was illustrative of the capability of well-designed software to scan for and infect vulnerable hosts on a large network. According to several researchers, Slammer was the fastest computer worm in history: The initial infection population doubled in size approximately every 8.5 seconds, and the worm achieved a full scanning rate of over 55 million scans per second, which was potentially limited because significant portions of the network did not have enough bandwidth to allow it to operate unhindered (see http://www.cs.berkeley.edu/~nweaver/sapphire). More recently, malware is reaching out to remote sites on the Internet to download additional payload items, upload sensitive data from the victim's system, send anonymous (laundered) spam, or search Internet search engines for more e-mail addresses to attempt to propagate to.

Insertion points refer to the locations where the files and data in the payload that actually execute the virus/worm functionality are installed or hidden. There is a wide diversity of executables, DLLs, and the like used by virus/worm writers to do their bidding, but one of our longtime observations of this space is that almost all of them attempt to write values to the "Run" keys in the Windows Registry in order to ensure the code will restart at the next logon. The main Windows "Run" keys are at HKLM\Software\Microsoft\Windows\CurrentVersion\Run and HKCU\Software\Microsoft\Windows\CurrentVersion\Run.

If you see anything suspicious here, your system may be infected, and you should read the upcoming section titled "Detecting and Cleaning Malware."

Besides the Registry, it is also becoming more commonplace for malware to overwrite other key configuration data on compromised machines. For example, variants of the MyDoom worm rewrote victim %systemroot%\system32\drivers\etc\hosts files to prevent them from accessing common antivirus and software patch update sites.

Caution 

A number of other autostart extensibility points (ASEPs) are used by malware to hide within Windows. See http://www. pestpatrol .com/PestInfo/AutoStartingPests.asp. You can run the msconfig utility on Windows XP to view some of these other startup mechanisms.

Finally, more and more viruses and worms are being written to perform detection avoidance, primarily by monitoring for key components of popular antivirus programs and deleting or disabling them. Typically, this is done by terminating processes of common detection tools (for example, navapw32.exe for Symantec's Norton Antivirus program, and vsmon.exe for ZoneAlarm personal firewall) and/or deleting Registry entries related to starting such programs at logon (obviously, if the malware writers use the Run keys to restart their own programs, they are also well positioned to prevent detection tools from restarting).

These are very rudimentary detection avoidance techniques, and, of course, detection avoidance is an escalating arms race that is never truly won or lost. Due to its complexity, there are probably limitless ways to hide programs within Windows, as you will see in the next section on rootkits and back doors.

Rootkits and Back Doors

Although the term was originally coined on the UNIX platform ("root" being the superuser account there), the world of Windows rootkits has undergone a renaissance period in the last few years. Interest in Windows rootkits was originally driven primarily by Greg Hoglund, who produced one of the first utilities officially described as an "NT rootkit" circa 1999 (although many others had been " rooting " and pilfering Windows systems long before then using custom tools and assemblies of public programs, of course). Hoglund's original NT Rootkit was essentially a proof-of-concept platform for illustrating the concept of altering protected system programs in memory ("patching the kernel" in geek-speak) to completely eradicate the trustworthiness of the operating system.

More recently, Greg's site, http://www.rootkit.com, has blossomed into a dynamic forum for sharing ideas on subverting operating systems, and an entire crop of prepackaged rootkits have gained widespread popularity (and deployment) across the world. In-depth examination of all the stealth techniques for hiding presence on a Windows system would require us to write another book entirely, so we're going to focus our discussion on the most popular tools and techniques being used today so that you can focus your efforts to defeat these miscreants where they'll achieve the most reward.

This being said, the concept of rootkits itself illustrates the folly of trying to rescue a Windows system that has been compromised at so fundamental a level. Our first advice if you find yourself in this state would be to back up known-good data and then flatten and rebuild your system. Again, the techniques discussed next are only the most popular as of this writing, and the boundaries are being pushed all the timedon't assume that simply by examining the receptacles we outline here that you are safe from infection.

One of the best overviews of rootkit techniques we've read is Jamie Butler's 2003 presentation at http://www.immunitysec.com/downloads/shindig-2- butler -jamie.ppt. In this presentation, Jamie outlines the basic premise exploited by modern rootkits: Microsoft and many other operating system vendors only use two out of the four privilege levels (called rings) provided by standard Intel hardware. This sets up a single barrier between nonprivileged user mode activity in Ring 3, and highly privileged kernel mode functions in Ring 0 (again, Rings 1 and 2 are not used). Thus, any mechanism that can penetrate the veil between user mode and kernel mode can attain unlimited access to the system.

Early rootkits crossed this boundary by hooking application programming interface (API) calls used to communicate between user and kernel mode. By hijacking the interfaces exposed by the kernel (via the operating system files kernel32.dll and ntdll.dll), an attacker can provide false information to the user of the local system. The API calls traditionally hooked in this manner manipulate the System Call Table and Interrupt Descriptor Table (IDT). Typically, rootkits use this to mask their activities by hiding files, processes, or ports with special names (for example, the AFX Rootkit hides all processes, files, and Registry keys matching the string "~~*"). API hooking is a very powerful technique that can even evade low-level analysis techniques such as debugging, which uses APIs to examine memory (more details on API hooking can be found in "How to become unseen on Windows NT" by Holy_Father at http://hxdef.czweb.org/knowhow/hidingen.txt).

Jamie's presentation goes on to describe a more direct mechanism for attaining control of kernel memory, via kernel-mode device drivers (or loadable kernel modules, LKMs, on non-Windows systems). This is how most modern rootkits work today.

Note 

By compromising operating system functions at such a low level, rootkits can avoid detection by antivirus and intrusion detection programs that rely on these same low-level functions to query the system.

Note 

User-mode rootkits are not as popular, but possibly more portable. See http://www.phrack.org/show.php?p=62&a=12 on NTIllusion for a detailed description of how to create a user-mode rootkit.

Thus, rootkits are composed of two basic pieces: a dropper and a payload. The dropper is anything that can get the target system to execute code, be it a security vulnerability or tricking a user into opening an e-mail attachment. The payload is typically a kernel-hooking routine or a kernel-mode device driver that performs one or more of the following techniques to hide its presence and perform its nefarious activities:

• Kernel modification As we noted earlier, this is traditionally done either by usurping kernel access calls or more recently by loading a malicious device driver (.sys), which is itself then hidden. Once the kernel is compromised, standard API calls that could be used to identify hidden files, ports, processes, and so on can be usurped to give false information. Good luck trying to find a rootkit when you can't even trust the dir or netstat commands! The subsequent techniques mostly rely on this important first step.

• File/directory hiding Many popular rootkits chain or detour the Windows API call ZwQuerySystemInformation to achieve this (for example, Hoglund's NT Rootkit would hide any file on the file system prefixed with "_root_"). Some also use Alternate Data Streams (ADS), a feature of the Windows NT Family operating system originally used to support Macintosh file system compatibility, but now also used by XP SP2 to hold information about the security zone from which a file has been downloaded (previous editions of Hacking Exposed illustrated the use of ADS to hide files, and such techniques are widely published on the Internet now). Flagging files so that Windows identifies them as bad blocks is also popular. Rootkits commonly also employ encryption or compression ("packers") on their payloads to avoid antivirus scans. More recently, rootkit researchers are speculating about storing information in writeable computer chips like the graphic processors used by most PCsthis would provide the ultimate hiding place for malicious code outside of the hard drive where most detection tools currently look.

• Process hiding Because processes are necessary to do work on Windows, a good rootkit must find a way to hide them. Most commonly, rootkits hide a process by delinking it from the active process list, which prevents common APIs from seeing it. Many rootkits also create threads, which are subcomponents of a process. By creating threads "hidden" within processes, it becomes more difficult for users to identify running programs.

• Port hiding To hide the backdoor component that allows remote control via a network, rootkits commonly attempt to hide the network ports on which they listen, whether they be TCP or UDP. The popular rootkit "kit" Hacker Defender hooks every process on the system and thus can avoid easy identification using investigative techniques such as netstat. Hacker Defender uses a 256-bit key to authenticate commands to these ports. Other rootkits, including cd00r and SAdoor, adopt techniques such as port knocking (http://www.portknocking.org) to achieve a similar capability.

• Registry key/value hiding This is generally not too hard, because the size and complexity of the Registry makes hiding things quite easy simply by naming them something that looks at once harmless and critical to the stability of the system (for example, HKLM\Software\Microsoft\Windows\CurrentVersion\ Run\firewall-service.exe). And of course, once the kernel is hooked, keys and values can simply be hidden from prying eyes altogether.

• User/ group hiding Typically, this is achieved by setting permissions on the user or group object so that most other system users cannot read them. Again, with kernel residence, operating system access tokens can simply be changed to reflect whatever the attacker wantsand only the SYSTEM user is implicated in the logs.

• Service hiding Rootkits commonly load components as Windows services, which makes them less accessible to novice users.

• Keystroke loggers Typically these are custom programs that capture submitted form data as a Browser Helper Object (BHO) in Internet Explorer, Win32-based keystroke loggers that are injected into the Windows logon process, or software shims placed directly at the keyboard hardware level (socalled "trapping an interrupt").

Multiple techniques may be employed to provide redundant reinfection vectors if one or more are discovered . Next, we will examine some of the most popular rootkits to see how they implement some of these techniques.

Hacker Defender

One of the most widely utilized rootkits is Hacker Defender, based on personal communications from colleagues who perform forensic analyses following computer security incidents at organizations large and small. Hacker Defender is frequently referred to by its slang name , hxdef, and can be downloaded from http://rootkit.host.sk or its mirror site http://hxdef.czweb.org.

The primary technique utilized by Hacker Defender is to use the Windows API functions WriteProcessMemory and CreateRemoteThread to create a new thread within all running processes. The function of this thread is to alter the Windows kernel (kernel32.dll) by patching it in memory to rewrite information returned by API calls to hide hxdef's presence. hxdef also installs hidden back doors, registers as a hidden system service, and installs a hidden system driver, probably to provide redundant reinfection vectors if one or more are discovered. hxdef's popularity probably relates to its ease of use combined with powerful functionality (ironically similar to its host system, Windows). Its INI file is easy to understand, and it binds to every listening port to listen for incoming commands, as we noted earlier in our discussion of port hiding. You have to use the hxdef backdoor client to connect to the backdoored port, as shown next:

 C:\test>  bdcli100.exe  Host: localhost Port: 80 Pass:  hxdef-rules  connecting server ... receiving banner ... opening backdoor .. backdoor found checking backdoor ...... backdoor ready authorization sent, waiting for reply authorization - SUCCESSFUL backdoor activated! close shell and all progz to end session Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\WINNT\system32> 

Note that we've used the default password to connect to the backdoor thread on port 80, which is commonly used to host a web server (and thus passes through standard firewall configurations).

We'll talk about finding and cleaning hxdef in the upcoming section titled "Detecting and Cleaning Malware." If you want to get a head start, hxdef's own readme file gives plenty of good pointers on how to detect and delete it.

Other Common Rootkits

Besides Hacker Defender, other rootkits are frequently found on compromised systems. These include the fuzen_op, or FU Rootkit, Vanquish, and AFX.

Like hxdef, FU consists of two components: a user-mode dropper (fu.exe) and a kernel-mode driver (msdirectx.sys). The dropper is a console application that allows certain parameters of the rootkit to be modified by the attacker. The driver performs the standard unlinking of the attacker-defined process from the standard process list to hide it from users. Again, once installed in the kernel, it's curtains for the victim system.

Vanquish is a DLL injection-based Romanian rootkit that hides files, folders, Registry entries, and logs passwords. It is composed of the files vanquish.exe and vanquish.dll. DLL injection is a technique we discussed in Chapter 4 on Windows hacking. It first gained notoriety circa NT4 with the getadmin exploit. DLL injection is similar to hooking kernel-mode API calls, except that it injects malicious code into a privileged kernel-mode process to achieve the same ends. Microsoft has sought to limit its exposure to DLL injection, for example by causing the operating system to shut down when the integrity of privileged processes is violated by DLL injection attempts.

The AFX Rootkit by Aphex (see http://www.iamaphex.net) attempts to simplify rootkit deployment. AFX is composed of two files, iexplore.dll and explorer.dll, which it names "iexplore.exe" and "explorer.exe" and copies to the system folder. Anything executed from its root folder will be hidden in several dynamic ways. Shifting the techniques used to hide components makes AFX more difficult to detect by tools that detect only one or two hiding techniques. AFX is also interesting for its easy-to-use graphical user interface for generating customized rootkits.

Bots and Zombies

Now that you've seen how easy it is to hide things from unsophisticated users, let's take a look at what sorts of nefarious activities malicious software engages in. If your machine becomes infected via one of the common mechanisms we've outlined so far (for example, a software vulnerability, IE misconfiguration, or opening an e-mail attachment), your system may wind up hosting a bot, which will turn it into a zombie in a larger army of mindless computers under the control of a remote attacker.

Although we prefer the term "drone" or "agent," bot is derived from "robot" and has traditionally referred to a program that performs predefined actions in an automated fashion on unmonitored Internet Relay Chat (IRC) channels. The connection with IRC is important, because the primary mechanism for controlling most malicious bots today is IRC. Zombie simply refers to a machine that has been infected with a bot.

What would anyone want to do with an army of PCs hooked up to the Internet? To leverage the potentially massive power of thousands of computers harnessed together, of course. Typically, abuse falls into the following categories:

• Distributed denial of service (DDoS) attacks As you saw in Chapter 11, DDoS is challenging to mitigate, and it's therefore an effective tool for extortion or brand assassination.

• Spam Ongoing efforts have closed down most of the unsecured e-mail relays on the Internet today, but this seems not to have dented the massive volume of spam flowing into inboxes worldwide. Ever wonder why? Spammers are buying access to zombies who run e-mail gateways. Even better, this sort of distributed spamming is more difficult to block by mail servers that key on high volumes of mail from a single sourcewith zombies, you dribble out a low volume of mail from thousands of sources.

• Laundered connections and hosting This reduces the need to assiduously cover ones tracks on the Internet when you simply masquerade as someone else's PC.

• Harvest valuable information This includes online banking credentials, software activation license keys, and so on.

• Secondary infection Scanning and enlisting more zombies, of course, increases the aggregate strength of the army.

If there is any greater indication of the value inherent in these bot networks/zombie armies, it is that they have now achieved economic value. Yes, these networks (some numbering in the tens of thousands) are now bought and sold by the CPU cycle to anyone willing to pay for their use in DDoS, spamming, and the like.

Microsoft has started to address some of the secondary effects of bot infection, such as DDoS flooding. Windows XP SP2 introduced a limit on the number of concurrent TCP connection attempts, to reduce the ease of scanning for new systems to infect and to block DDoS attacks such as connection flooding. Of course, this fix was quickly identified and modified by individuals who were not happy with this newfound restriction on their system's behavior (see http://www.lvllord.de/?url=tools#4226patch). Many new bots now incorporate similar code to simply bypass this restriction, illustrating the ongoing cat-and-mouse game between software vendors and the hacking community.

Some of the most popular bots in use today include Agobot, AttackBot, SubSeven, EvilBot, SlackBot, GT (Global Threat) Bot, Litmus Bot, and Socket Clone Bots such as Judgment Day. We're not going to spend any time describing these in more detail because we've already covered the most significant features of such programs (if you want, search for their names using any Internet search engine and you'll get plenty of data). Most of these bugs aren't very innovative, and they reuse common techniques from other malware like viruses and worms to perform their evil bidding. Let's instead move on, at last, to a discussion of finding and cleaning malware of all types.

Detecting and Cleaning Malware

As with the many other security threats we've discussed in this book, there are preventive, detective, and reactive controls you can implement to protect yourself from the threat of malware.

Before we begin this section, let's make it clear that we are not going to talk much about prevention here, because we already covered that heavily in our previous discussion of general countermeasures. This discussion will assume for the most part that a compromise has already occurred and that preventative measures have failed for one reason or another (which is, after all, what most malware relies upon quite heavily).

Caution 

For 99.99 percent of users, who lack a sophisticated understanding of the issues we are about to discuss, we recommend you either follow the recommendations provided by your installed security software, adhere to your organizational security policies, or seek professional assistance in dealing with a computer security incident, intrusion, or compromise.

Tip 

Microsoft provides common security software vendor contact information at http://www.microsoft.com/athome/security/protect/support.mspx and also offers no-charge support for virus and other securityrelated issues, 24 hours a day, for the U.S. and Canada at 1-866-PCSAFETY, or 1-866-727-2338. For other regions , see http://support.microsoft.com/common/international.aspx.

Immediate Actions

If you think your system has been victimized by malware, one of the first things to do is unplug the network cable(s). This prevents further communication with remote controlling entities that may react to attempts to investigate or clean the system, and it also prevents the infected host from spreading the infection to other systems on the network ( assuming it hasn't already) or performing other nefarious tasks such as DDoS.

With the network cable unplugged, you now have time to investigate and identify the root cause of the observed issues, whether they are infection-related or not. Of course, this also makes it difficult to utilize the great resources on the Internet or internal networks for examining and cleaning the system; use good judgment about when and how to reconnect .

Back Up, Flatten, and Rebuild

If you confirm a malware infection on your system, you have two choices:

• Assume that the malware you found was the only malware installed on your system, clean it with the appropriate tools and/or techniques, and move on with life.

• Assume that the malware you found was only one of potentially many infections on your system that took advantage of whatever vulnerable state it was in, back up your critical data, erase the system, and rebuild from trusted sources.

Obviously, if you select the first option, you take additional risks. Of course, if you select the second option, you potentially incur significant work. Again, use good judgment.

Administrators of large numbers of systems might also consider documenting a policy on exactly what situations justify each option, to head off nasty disagreements during the heat of a response to a real computer security incident, intrusion, or compromise. We've found that such a policy usually looks something like the following:

"Systems identified as compromised shall be investigated by the [authorized computer forensic team]. The team shall make a judgment within 24 hours as to the nature of the compromise and make a recommendation as to whether specific cleansing, or a complete flatten and rebuild, is warranted. In all cases, compromises resulting in unauthorized, nonautomated remote control of a system shall require flattening and rebuilding. The forensic team's recommendation shall be implemented across all systems and lines of business, except in those specific instances where an exception is granted by the Security Group."

Detecting and Cleaning

For 99 percent of the infections you are likely to encounter, standard antivirus software is sufficient to detect and clean malware on your system (and if you have it installed before you get infected, chances are that the malware was detected and blocked before it even had a chance to infect you!).

We've also covered antispyware programs, which have become popular lately (see the previous section in this chapter covering deceptive software such as spyware, adware, and spam). Although antivirus and antispyware programs tend to overlap somewhat, we think they are mostly complimentary today, and we recommend maintaining both for the time being.

Intrusion detection/prevention (IDS/IPS) tools such as McAfee Entercept, although typically deployed and managed within corporate environments, can also detect and deflect many forms of malware activity, although we again recommend combining it with a good antivirus product because fundamental IDS/IPS approaches are still maturing.

When it comes to rootkits, back doors, and bots, the situation becomes more complex. Most antivirus software will detect the default installations of such tools, but with only the barest of customizations, they become undetectable using the standard antivirus signature databases. And although antivirus programs also use heuristics ( rules-based examination designed to identify polymorphic or metamorphic malware), we've yet to see the big antivirus vendors start looking for techniques such as kernel hooking and modification. Remember also that many antivirus programs use the very same hooking techniques to identify malware, so if the rootkit gets there first, the antivirus software won't see it.

Enter the world of computer security forensics, typically only entered by practiced professionals, and definitely not recommended for the uninitiated when serious issues such as monetary damages are at stake or when legal standards for evidence preservation must be maintained . A number of professional firms specialize in computer forensic examinations, including New Technologies International (NTI; see http://www.forensics-intl.com). Also, commercial tools are available, such as Encase from Guidance Software (see http://www.guidancesoftware.com), although such highly specialized tools tend to be quite expensive.

And of course, there are numerous free tools and published techniques that tend to keep pace more closely with the ever-evolving landscape of stealth software techniques. Some of these tools include VICE, RKDetect, Patchfinder, Klister, and SDTRestore (these can be found at http://www.rootkit.com, http://www.forensics.nl/tools, or http://www.cybersnitch.net/tucofs). We'll examine some of these tools next. As for published information, one of our favorite Windows intrusion detection checklists can be found at http://www.auscert.org.au/render.html?it=4323#A1.

In general, one technique shared across all rootkit detection tools is the concept of comparing disparate sources of information about the same system to identify inconsistencies (this concept is sometimes referred to as "diff-ing" two information sources, after the UNIX utility for parsing out the diff erences between two files).

RKDetect, from http://www.security.nnov.ru/soft, is a utility for finding services hidden by generic Windows rootkits such as Hacker Defender. Using the diff technique, it enumerates services on a remote computer using Windows Management Instrumentation interface (WMI, user level) and the Services Control Manager (SCM, kernel level) and then compares the results and displays inconsistencies. The same approach can be used to enumerate processes, files, Registry keys, and so on that rootkits might attempt to hide. The following example shows RKDetect "detecting" Hacker Defender on a remote machine:

 C:\>  cscript rkdetect.vbs 192.168.234.3  Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. Query services by WMI... Detected 0 services Query services by SC... Detected 84 services Finding hidden services... Possible rootkit found: Alerter - Alerter [SC] QueryServiceConfig SUCCESS SERVICE_NAME: Alerter    TYPE          : 20  WIN32_SHARE_PROCESS    START_TYPE    : 3   DEMAND_START    ERROR_CONTROL      : 1   NORMAL    BINARY_PATH_NAME   : C:\WINNT\System32\svchost.exe -k LocalService    LOAD_ORDER_GROUP   :    TAG      : 0    DISPLAY_NAME       : Alerter    DEPENDENCIES       : LanmanWorkstation    SERVICE_START_NAME : NT AUTHORITY\LocalService [output edited for brevity] Possible rootkit found: HXD Service 100 - HackerDefender100 [SC] QueryServiceConfig SUCCESS SERVICE_NAME: HackerDefender100    TYPE          : 10  WIN32_OWN_PROCESS    START_TYPE    : 2   AUTO_START    ERROR_CONTROL      : 0 IGNORE    BINARY_PATH_NAME   : C:\windows\system32\hxdef100.exe          C:\windows\system32\hxdef100.ini    LOAD_ORDER_GROUP   :    TAG      : 0    DISPLAY_NAME       : HXD Service 100    DEPENDENCIES       :    SERVICE_START_NAME : LocalSystem 

Notice in this output that the WMI-based query returned no data, so RKDetect lists every service found by SCM as a possible rootkit. Be aware of this issue if you try the tool. Also recall that RKDetect must be run remotely; if it's run locally on an infected system, calls to SCM may be hooked and return erroneous data. In any event, because of the default naming convention used in this particular instance, the Hacker Defender infection stands out rather conspicuously in the output.

SDTRestore is proof-of-concept code from Tan Chew Keong that essentially reverses kernel call hooking techniques used by early rootkits (see http://www.security.org.sg/code/sdtrestore.html). As opposed to diff-ing, it restores the real values modified by rootkits when they return from native kernel API calls. One limitation of SDTRestore is that it only identifies and fixes rootkits that hook the Service Descriptor Table kernel structure, and those that hook the Interrupt Descriptor Table (IDT) are not visible. Tan Chew Keong has also produced other tools designed to ferret out rootkits, including ApiHookCheck and Win2K Kernel Hidden Process-Module Checker, both available at http://www.security.org.sg.

Although not specifically targeted at rootkits, the Microsoft Windows Preinstallation Environment ( WinPE ) is indispensable when it comes to offline analysis that must be performed to truly detect rootkits (after all, you can't trust any data returned by the compromised system). WinPE is essentially a command-line Windows XP environment that can be booted from a CD-ROM. For more information on WinPE, search http://Microsoft.com for "winpe." Also check out BartPE from http://www.nu2.nu/pebuilder.

For an idea of how WinPE might aid in the detection of rootkits, check out the paper by Yi-Min Wang, et al., available at http://research.microsoft.com/sm/ strider /default.aspx#GhostBuster. The authors point out a simple three-step process for diff-ing a file system dump (using dir /s /a) run locally on the infected system and then from the WinPE environment. Because the rootkit cannot filter the output of the WinPE-based listing (because it is not running in the WinPE environment), any hidden files should stand out quite conspicuously in the diff. This methodology would seem to be pretty effective, because at some point, malware must write data to a nonvolatile portion of the system (that is, the hard disk) if it wants to persist beyond reboot or other memory-cleansing events. Of course, this is a proof-of-concept implementation; a practical tool based on this concept would have to consider alternate data streams and other techniques by which data can be hidden in the Windows file system.

If you have doubts about whether a file is legitimate or not, several Internet repositories are available to compare cryptographic hashes of known-good files. For example, the national Software Reference Library provides libraries of known hashes at http://www.nsrl.nist.gov.

One last toolkit should be referenced before we move on. The Microsoft OEM Support Tools, available at http://support.microsoft.com/?kbid=253066, contain several tools that can be helpful during forensic examination, including Kernel Debugger Extensions (kdext), Kernel Memory Space Analyzer (kanalyze), User Mode Process Dump (userdump), Kernel Mode to User Mode Process Dump Extraction Utility (genedump), NTFS File Sector Information Utility (nfi), and a Driver Verifier and System Information API Wrapper (syswrap).

Last, but not least, we recommend keeping an eye on developing architectural mitigations to the challenges posed by rootkits. For example, on September 10, 2004, Microsoft announced some key changes in company policy related to patching the kernel on Windows Server 2003 Service Pack 1. In essence, W2K3 SP1 and later on 64-bit platforms will not allow the kernel to be patched except through authorized Microsoft-originated hot patches. The policy intimates that the following activities will no longer be supported:

• Modifying system service tables (for example, by hooking KeServiceDescriptor Table)

• Modifying the Interrupt Descriptor Table (IDT)

• Modifying the Global Descriptor Table (GDT)

• Using kernel stacks that are not allocated by the kernel

• Patching any part of the kernel (detected on AMD64-based systems only)

As we've noted, these are the primary techniques upon which modern Windows rootkits are based. By blocking these extensibility points, Microsoft is essentially shutting down the most popular Windows rootkit methodologies. We're sure the security research community will find alternatives (perhaps focusing more on user-mode rootkits, or even circumventing some of these controls), but this certainly raises the bar significantly for those willing to invest in x64-based platforms. For the full article on this policy change, see http://www.microsoft.com/whdc/driver/kernel/64bitpatching.mspx.