This action might not be possible to undo. Are you sure you want to continue?
FINAL REPORT DARPA: Rootkit Detection Contract: N66001-06-C-2052 Draft: v2.10 April 26, 2007
Abstract Rootkits are software tools and techniques which allow an attacker to maintain a computer system in a compromised state, creating a risk to systems and data. This document presents the results of a research effort to establish the current state of rootkits and detection techniques, to document the anticipated future state of rootkits and detection techniques, and to identify effective solutions to the challenge of rootkit detection. We found that current tools and methods cannot detect modern rootkits, and future rootkit developments will exacerbate this situation. Current and emerging detection approaches rely on knowledge of rootkit implementations, and so will remain in a reactive position. We identified a solution for more proactive, generic detection. In this solution, we collect evidence related to the indirect effects of a rootkit, rather than the direct effects of specific rootkit implementations. Some of this evidence is induced and some is passively collected. We then reason over this evidence to determine the likelihood that a rootkit is present. Such an approach has the potential to detect current and future rootkits without the need for updates or knowledge of new rootkit techniques or implementations.
Not for use or distribution outside of DARPA Contract N66001-06-C-2052
DRAFT Table of Contents
1. INTRODUCTION............................................................................................................4 1.1. STUDY DESCRIPTION............................................................................................4 1.2. THE THREAT.......................................................................................................4 1.3. BACKGROUND INFORMATION....................................................................................7 2. CURRENT STATE.........................................................................................................8 2.1. CURRENT STATE OF ROOTKITS...............................................................................8 2.1.1. Rootkit Classification......................................................................8 2.1.2. Current Rootkit Capabilities..........................................................12 2.1.3. Rootkit Evolution and Operating Systems....................................17 2.2. CURRENT PREVENTION METHODS..........................................................................18 2.3. CURRENT DETECTION METHODS............................................................................19 2.3.1. Malware Detection........................................................................19 2.3.2. Rootkit Detection Challenges.......................................................19 2.3.3. Tailored Detection........................................................................20 2.3.4. Challenges Detecting Hypervisor.................................................20 2.3.5. Cross-View Differences Detection................................................21 2.3.6. Other Detection Methods..............................................................21 2.4. CURRENT MITIGATION METHODS...........................................................................22 2.5. CURRENT RECOVERY METHODS............................................................................22 2.6. COMPREHENSIVE DETECTION TESTING....................................................................22 2.6.1. Testing Methodology....................................................................22 2.6.2. Test Results.................................................................................23 2.7. EXAMPLE ROOTKIT DETECTED BY ZERO TOOLS........................................................27 3. FUTURE STATE..........................................................................................................29 3.1. FUTURE STATE OF ROOTKITS...............................................................................30 3.1.1. Rule #1: Rootkits Follow the Data...............................................30 3.1.2. Rule #2: Rootkits Respond in Kind..............................................30 3.1.3. Rule #3: Rootkits are Here to Stay..............................................34 3.2. FUTURE STATE OF PREVENTION............................................................................34 3.3. FUTURE STATE OF DETECTION..............................................................................35 3.4. FUTURE STATE OF MITIGATION.............................................................................35 3.5. FUTURE STATE OF RECOVERY..............................................................................35 3.6. LANDSCAPE-CHANGING EVENTS............................................................................36 4. SOLUTION ROADMAP...............................................................................................37 4.1. SOLUTION SCOPE..............................................................................................38 4.2. SOLUTION REQUIREMENTS...................................................................................38 4.3. SOLUTION IMPLEMENTATION .................................................................................39 4.3.1. Indirect Effects..............................................................................39 4.3.2. Multiple Perspectives....................................................................40 4.3.3. Reasoning over Observables.......................................................42 4.4. SOLUTION ARCHITECTURE....................................................................................42 4.4.1. Host Agents..................................................................................44 4.4.2. Reasoning....................................................................................46 4.4.3. Concept of Operations..................................................................47 4.5. EVALUATION.....................................................................................................48 4.6. DEVELOPMENT OUTLINE......................................................................................50 4.6.1. Development Phases...................................................................50 184.108.40.206. Phase 0: Tailored Detection Tool..............................................50 220.127.116.11. Phase 1: Proof of Concept........................................................51
Not for use or distribution outside of DARPA Contract N66001-06-C-2052
18.104.22.168. Phase 2: Functional Implementation.........................................51 22.214.171.124. Phase 3: Extensions and Enhancements..................................52 4.6.2. Task Schedules............................................................................53 4.6.3. Anticipated Costs..........................................................................54 5. CONCLUSIONS AND RECOMMENDATIONS............................................................54
Not for use or distribution outside of DARPA Contract N66001-06-C-2052
1.1. Study Description
This research has three primary goals: establish the current state of rootkit technology, establish the likely future state of rootkit technology, and identify promising solutions. Project Goals: • Establish current state of rootkits and detection • Project future state of rootkits and detection • Identify promising solutions
We established the current state of rootkit technology by collecting rootkit samples and detection tools, then executing a set of experiments. We collected over 200 unique rootkit samples, and we refined this down to 25 representative rootkit implementations. We attempted detection of these rootkits using 31 unique tools representing a range of approaches and methods. We also studied the rootkit samples and detection tools to establish a rough classification of each, identifying common methods and techniques. We present this work in Section 3. We established the likely future state of rootkits via our own research and discussions with outside experts. This future state takes the form of a list of likely rootkit developments and our assessment of the likelihood and impact of each. We also established the likely future state of defensive measures in a similar manner. We present this work in Section 4. We identified promising solutions by first considering current and emerging techniques. We established that current known and emerging techniques are ineffective against many current rootkits, and are likely to remain so in the face of future rootkit development. We next reviewed other ideas and research in related fields (e.g., medicine). From this effort, we developed what we believe to be a novel yet effective approach to the problem of generic rootkit detection. We present this solution in Section 5, and we present implementation details in Section 6. The Threat: Rootkits are rapidly • Remote access and control becoming the tool of choice for • Difficult to detect cyber-crime and espionage • Sensitive processing on compromised systems involving computing machinery and data. This is because rootkits offer stealth operation and the ability to exfiltrate data undetected from the network. Critical information is being stored in computers, and faulty software and a lack of security controls expose valuable information to attack. As the global economy develops, so does the demand for competitive intelligence. Today, malicious backdoors, trojans, botnets, and stealth rootkits (collectively known as malware) have unlimited access to our networks and employees are “recruited” based upon their access to information to steal for money or a cause. It has become easier than ever to get access to classified, controlled or proprietary information. Intellectual property such as product designs, marketing plans, customer lists, and gov’t intelligence is being stolen daily. It is estimated that 70 percent of the average
Not for use or distribution outside of DARPA Contract N66001-06-C-2052
1.2. The Threat
enterprises value is held in its information. The current FBI estimate is that over $100 billion dollars is being lost annually due to theft of intellectual property. Espionage is the dirty secret of the global economy, acquiring sensitive restricted information assets from an entity. Many corporations have departments or divisions in place to practice corporate espionage, thinly disguised as “competitive intelligence”. Governments routinely sponsor and engage directly in espionage, sometimes in the form of legitimate agencies. Even U.S. allied governments conduct espionage against the U.S. Robert Bryant, former head of FBI’s National Security Division, has found over 23 countries that conduct espionage against the U.S., half of them allied nations. Some reports indicate that nearly 140 countries and some 35 known and suspected terrorist groups target the United States through espionage . Allied nations that spy on the U.S. and U.S. companies: France India Pakistan Japan South Korea Taiwan Philippines For example, a statement by a former head of an allied Western European intelligence service illustrates the attitude of some friendly and allied countries toward economic and industrial espionage against the United States. When interviewed on the NBC television program "Expose," this former high government official was unapologetic about his country's espionage against the United States. He claimed credit for starting his country's program of economic and industrial espionage against the U.S. as a means of improving economic competitiveness. He said his country "... would not normally spy on the States in political matters or in military matters where we are really allied. But in the economic competition, and in the technological competition, we are competitors. We are not allied." Government sponsored espionage is a big problem. To illustrate an example, FBI counterintelligence chief David Szady has stated “The Russians are up to Cold War levels in both intelligence presence and activity.” According to FBI officials, Moscow is running more than one hundred spies who operate under official cover out of the Russian embassy in Washington and consulates in other major U.S. cities. These spies are supplemented by an unknown number of deep-cover agents dispatched throughout the U.S. posing as businessmen, academics, students, and other visitors . U.S. based corporations are also conducting espionage (see list below). Organized crime, terrorist groups, multinational corporations, and drug syndicates all threaten to steal sensitive, classified, and proprietary data. The economic impact to the U.S. economy is staggering, as is the threat to national security. The following corporations have been cited for corporate espionage1:
Source: Spyops Training Brief, March 2006
Not for use or distribution outside of DARPA Contract N66001-06-C-2052
Recent history has proven that software vendors use poor coding practices and lack security testing. 2 CSI/FBI Computer Crime. Today. Rootkits generally have full administrative privileges on the computer on which they are installed.DRAFT Avery Dennison/Four Pillars Lucent Technologies The Cleveland Clinic Foundation Kodak Mastercard Bristol Meyers Squibb/Taxol Gillette Deloitte and Touche Intel The espionage epidemic is being under-addressed. While computer viruses are easily detected with signature-based scanning. and the fact is that many incidents go undetected in the first place. When incidents are detected. a daunting task to keep up with even in a small enterprise. which means data and networks are exposed to external attacks. most rootkits have remote communication capabilities. Therefore. Desktop firewalls and endpoint security is not used in 49% of organizations. Rootkits are at the core of the data-theft problem because of their capabilities and their stealth. modern rootkits are very difficult to detect. the threat of rootkits is that compromised systems may be unknowingly used to process sensitive data for extended periods of time. and these techniques are under active development. modify. especially espionage-related cyber crime. permitting access and control for a remote user. data-theft now accounts for 80% of all cyber crime according to a study conducted by Symantec from July 2005 through Dec 2005. Internally. they go unreported for the following reasons2: • • • Fear of negative publicity and impact on stock value: 48% Fear that competitors can use the incident to their advantage: 38% Because of the lack of laws and awareness of options: 22% How can this be happening with all the supposed advances in computer security? According to Commercial Crime International [published 8/2006] a fifth of all organizations do not have any form of endpoint security. Vendors routinely require customers to upgrade or patch existing software. Many cases of espionage go unreported. Modern rootkits implement a wide range of techniques specifically aimed at evading detection. This would not represent a new level of threat were it not for the stealthy aspects of rootkits. 46% of companies fail to keep current on application patches and 37% do not keep their operating systems up to date. Additionally. thus resulting in security vulnerabilities in both applications and the operating system. and exfiltrate data. There are currently no government regulations which require the reporting of such incidents. destroy. Rootkit capabilities include the ability to access. Survey 2006 Not for use or distribution outside of DARPA Contract N66001-06-C-2052 6 . putting at risk all data on that system as well as other connected systems. All of these failings enable cyber crime.
the Lion worm affects Linux machines by exploiting a BIND vulnerability. over 250 specimens have been collected during the course of this study. because they do not self-propagate. Figure 1 provides a flowchart that can be used to help identify and discriminate between types of malware. relying on the abundance and dynamic nature of files and processes on a normal computer system to impede detection. and their use is on the rise. however unlike most Trojans. and covert communications. The Common Language for Computer Security Incidents published by Sandia National Laboratories classifies rootkits as a type of toolkit (Howard and Longstaff 1998). In addition to these basic features. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 7 . Background Information A rootkit is a type Rootkits: of malicious software • Are installed after a compromise has occurred (also known as • Help an attacker maintain a system in a compromised state malware) that is • May be stealthy or hide in plain sight installed by an attacker after the target system has been compromised at the root or administrator level. data exfiltration. and various flavors of Unix. Rootkits are available for every major operating system such as: Microsoft Windows. we note that one emerging trend in rootkits is to "hide in plain sight". rootkits may also provide functionality such as: keystroke loggers. backdoors. Figure 1: Malware Flowchart There are hundreds of rootkit variants readily available for download on the Internet. This is not a new practice. 3 For example. The purpose of a rootkit is to provide continued access to the compromised system and to hide information about the compromise and its ongoing activities from legitimate system administrators. and searches for more vulnerable machines to infect. packet sniffers. remote attack tools. 4 Although the malware flowchart of Figure 1 is currently accepted. Lion then installs the t0rn rootkit. Toolkits originated from attackers who wished to continue to exploit a compromised system by creating a hidden cache of tools. Although the exact number of rootkits is unknown. That is.DRAFT 1. Rootkits are distinct from worms or viruses. Once exploited. however multiple forms of malware are sometimes combined3. the concept has been around as long as hacking has. Mac OS X. Some sources consider a rootkit to be a type of Trojan horse. the rootkit elements do not implement stealth but rather attempt to look like innocuous system or application files and processes.3. rootkits provide stealth functionality4 that is used to hide itself and its activities.
The current state of rootkit mitigation and recovery are generally poor. detection. Along these lines. and recovery. That is. apropos. kernel-mode. • • • • • Current State Current rootkits are kernel mode drivers Current prevention is via patch maintenance and good security practice Current detection is via tailored methods. we are able to develop tailored detections mechanisms. we can effectively prevent most compromises through the use of existing tools and good security practice. However. we describe the current state of the rootkit prevention. These mechanisms are quite effective at detecting even advanced rootkit techniques. the stealth methods employed. suckit Not for use or distribution outside of DARPA Contract N66001-06-C-2052 8 . Following this. such as: user-mode. Sony rootkit. rootkit features or capabilities. This puts us at a defensive disadvantage. The current state of the art for defending against rootkits is tailored detection. however none have resulted in a broadly accepted rootkit taxonomy. if we have prior knowledge of the implementation. Then we present a summary of current rootkit capabilities. some progress with cross-view diffs Current mitigation is to quarantine the whole system Current recovery is to restore a known good image The current balance of the rootkit battle is in favor of the rootkit authors. and rootkit code control flow. mitigation.1. and virtualized.1. The state of the art for rootkits is kernel mode drivers which provide rootkit functionality and stealth. Joanna Rutkowska proposed a taxonomy based on three types of rootkits as shown in Table 1. Rootkit Classification There have been multiple attempts to categorize rootkits. 2. This is primarily due to the fact that when we are able to detect an advanced rootkit infection. Various approaches have used the level at which subversion occurs. we rarely understand the rootkit mechanisms completely enough to effect a surgical recovery.1. toolkits. we describe different approaches for classifying rootkits. Subverts operating system or applications by manipulating Examples Most viruses. Classification Type 0: No Subversion (not a rootkit) I: Infect Code Description Does not subvert the operating system or applications. 2. adore.DRAFT 2. trojans. Current State of Rootkits In the sections that follow. rootkit lineage and similarity. Several approaches refer to rootkits using an informal categorization based upon the level at which subversion techniques are employed. able only to react after a particular rootkit implementation has come to our attention. In general. we quarantine the system and rebuild it from scratch. When we have knowledge of specific kernel mode drivers. The current state of rootkit prevention parallels system security in general. but targeted attacks are still likely to get through. we are not able to detect such kernel drivers unless we have prior knowledge of them. which we characterize as solid but incomplete. worms Hacker defender.
” including elements of some kernel data structures.DRAFT II: Infect Data III: Hypervisor static resources. a rootkit that runs like a normal software application would be called a “Userland” rootkit and would use the “Ring 3”5 privilege level. even including rootkits that can get into the “hypervisor” hardware of the VM architecture. The most salient feature in a rootkit is how it hides. library. PHIDE2 Blue pill. Finally. hypervisor. As the name implies. Type III rootkits target newer hypervisor systems and are. Roughly speaking. “those which cannot be detected by any form of integrity scanning”. include device drivers (for Windows) and loadable kernel modules (for Linux). thus intercepting all hardware calls. These are known as “Kernel-mode” rootkits. loads ahead of the OS. which run at the same privilege as the kernel – Ring 0. More recently. SubVirt [Microsoft] demonstrates this capability. and thus be able to access any part of the system. FU. using virtualization. the application rootkit definition includes modifying (or replacing) applications like internet browsers. 5 Ring-3 and Ring-0 are privilege levels offered by the Intel CPU Not for use or distribution outside of DARPA Contract N66001-06-C-2052 9 . Canonically. & application. or low level chipset control Table 1: Stealth Malware Taxonomy Deepdoor. firewalk. a more desirable rootkit will operate within the kernel itself. Arguably. there are also rootkits which can run below the kernel. It installs itself in the boot sequence. kernel-level rootkits. like data sections. kernel. these four types are virtualized. the lowest level (and most insidious) is the virtualized rootkit. Subvert Type I rootkits target “those resources which were designed to be constant. they are restricted only by the ability of the programmer. A finer taxonomy can be developed by looking at different features. An additional type is called a library rootkit and associated methods include hooking system calls. because they live completely outside the native OS. Subverts operating system prior to boot. Vitriol. which does not have the same privileges as the operating system kernel. by definition. rootkits can be split into three broad categories depending on the highest privilege with which they run. via Virtual Machine (VM) technology. Subverts operating system kernel by manipulating dynamic resources. Type II rootkits target "dynamic resources. Other sources [Wikipedia] propose four classifications which are different from the Rutkowska types. and loads the OS as a virtual machine.” such as kernel code sections. these rootkits have full kernel-level access. FUTo. used by rootkits. or feature sets. The next type. Of these. prrf.
handles. and is shown in Figure 2. pagefault handler. overwrites syscall jump. by filling in values for a large set of possible features. IDT. Mode. DKOM (Direct Kernel Object Manipulation). Layered drivers. A real effort would consolidate and extend the feature set. But it offers one outstanding advantage: the ability to classify an unknown rootkit. it may not. we might find more useful clusters or patterns.. polymorphic. DKOM Object hiding: files. Registers. a quick way to look up • precisely what threats a known rootkit posed. but it should be straightforward. such as: General features: Target OS. /proc. They describe six broad ways that rootkits hide: Hooks. Weaponized. Virtual Machine • VMware etc. VM (Virtual Machines). and addition. First. API.g. adds internet protocol. and now. A completed table would give us two advantages. One could also create a feature vector for each rootkit. modules. VMM. layered filter drivers. in-memory executable. automated methods open up possibilities for fast recognition and classification on-the-fly. Like other inventions. drivers. either by manual Figure 2: Stealth Method Taxonomy inspection or via automated clustering. denial of service • • Hooks User Mode • Inline (userland) • IAT (userland) • Kernel Mode • Syscall (NT Rootkit) • IDT (ShadowWalker) • IRP Callbacks • Windows Message Hooks • File System Callbacks • Object Manager • NDIS protocols Special Registers • Debug registers • Model Specific Registers (MSRs) (similar to IDT hook) Layered Device Drivers (intercept all I/O) • Keyboard • File system • Network DKOM • Unlink process lists (FU) • Alter handle tables (FUTo) • . with the exception of userland hooks. IAT. A hierarchical clustering constructed from features would be a kind of taxonomy. Most of these techniques are kernel-mode. Although it may share some of the high-level features as the canonical taxonomy. Callbacks. That done. terminates foes. key logging. DLL injection. modifies kernel text. ports. packet sniffer. registry keys Behavior: elevate process privileges. Persistent. services. EAT.. evasive (e.. adds new system call jump. It may or may not be more understandable by humans. Second. processes. alteration. A Not for use or distribution outside of DARPA Contract N66001-06-C-2052 10 . the state of the art progresses. building on past examples by combination. Injection method. or Rutkowska's taxonomy.DRAFT A more refined taxonomy of stealth methods employed by rootkits was presented by Butler. Arbaugh & Petroni. inline. As we shall see. IRP. EEPROM/Flash Hooking methods: SST/SSDT. suspends to avoid detection). (SubVirt) • HyperVisor (BluePill) • • • This set of features is merely illustrative. filling in the vectors would take some • work. Maturity. and thus anticipate its behavior. Most rootkits do not appear out of thin air.
exe file of _root_040 is placed on the same branch. has developed tools to extract control flow diagrams and related semantic structures. and thereby the appropriate countermeasures. Inc. HBGary. not the source code. as did Carrerra & Erdelyi (2004) for other malware. An even better classification would result if we could first create the control flow diagram. and is placed on the same branch. Classification allows us to identify the threat. Cilibrasi & Vitanyi 2005). Figure 3 shows a similarity tree for 27 Windows rootkit executables in a sample we collected from repositories. The clustering suggests that they shared code. FU was written by Hoglund's co-author. automated methods like normalized compression distance (NCD) allow for rapid classification of new executables captured in the wild.DRAFT careful rootkit historian would be able to tell you which rootkits descended from which other rootkits. For example. using the same method as (Wehner 2005) did for Internet worms: we generated the normalized cross-compression scores for each executable against all 26 others. Note that the tree correctly groups the Hacker Defender family together (in the NorthEast branch). and these lines of descent can be recognized. Combined with a good database of rootkit features. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 11 . and built a tree from that using the Complearn toolkit (Complearn 2003+. and used only the executables. Also note the South branch: FuTo (also written FUTo) descends directly from FU. Furthermore the deploy. Since those offer a much deeper insight into the structure of the rootkit. But these lines of descent are written into their code and their features. This learning was completely unsupervised. and how they combined and added features. before we have their source code or time to reverse engineer them. Jamie Butler. would yield far better measures of similarity. trees constructed from graph similarity searches. or even NCD on efficient representations of the control flow. This is the original Windows NT rootkit by Greg Hoglund.
Not for use or distribution outside of DARPA Contract N66001-06-C-2052 12 .2. or use different and varied capabilities depending on needs. Figure 4 provides an overview of rootkit capabilities.DRAFT Figure 3: Similarity tree for 27 Windows rootkits 2. Current Rootkit Capabilities In this section. It would be uncommon for a rootkit to utilize only a single capability. and each capability is described in the text that follows. we provide an enumeration of existing rootkit capabilities. It is important to realize that a given rootkit can draw upon many diverse capabilities all at once.1.
DRAFT CACHE 2 1 BUS ADDRESS TRANSLATION 3 TABLEBASE REGISTER Function pointer hook 6 5 BREAKPOINT 8 4 TRANSLATION LOOKASIDE BUFFERS EXCEPTION PAGE TABLES Cache Pollution Detour patch 7 9 10 11 12 Thread transition into kernel m ode Device driver Cavern infection Freestanding code 14 DLL 15 Thread Process Service function 18 Data structures Allocated memory 17 Data state modifications 16 13 Kernel -only thread Internally induced buffer overflow activation Figure 4: Capability Diagram Not for use or distribution outside of DARPA Contract N66001-06-C-2052 13 .
For example. 3. 5. These can be directly placed into code bytes as breakpoint or interrupt Not for use or distribution outside of DARPA Contract N66001-06-C-2052 14 . causing a divide-by-zero exception. and is instead induced only by making a data state change. Thus. 2. a rootkit can instead modify data in a way that will induce an exception. Exception based control flow modification To avoid changing code bytes directly. Breakpoints Breakpoints are a way for a rootkit to cause an exception to occur on a memory or code address. such as the interrupt descriptor table. Some rootkits will poison the TLB in a way that allows memory to be subverted but remain undetected. Table base registers The location of tables. These page-tables are cached for performance reasons into the translation lookaside buffer. Such rootkits can make direct modifications to code. Bus Address Translation The various busses on the computer are subject to layers of address translation before they can directly access physical memory. Translation Lookaside buffers (TLB) Virtual memory is translated into physical memory addresses by page-tables. Processor Cache The processor maintains a copy. rootkit detection solutions that are based on DMA access can potentially be subverted. but these modifications are not detected using normal memory reads. This control is obtained without having to patch the original code. a rootkit might be able to move the entire table without the original table being modified. If the processor register is modified. If this base address is not integrity checked. 4. the rootkit would be able to modify the new table without detection. 6.DRAFT Key to the diagram: 1. or cache. of data and code for performance reasons. integrity checks fail to detect the modification. These cache’s can sometimes be poisoned to contain invalid data. Thus. This exception is caught by the rootkit and allows it to intercept control flow at the point of the divide instruction. are maintained as an address in a processor register. the entire table can be moved elsewhere in memory. Such poisoning can be used to hide code or data in a way that cannot be detected by normal memory access methods. a rootkit might zero out a number that is used in a divide operation. Thus.
Subverting usermode programs Usermode programs – typical application running on a computer. Rootkit detection systems that rely on enumeration of threads may not take into account these special kernel threads. This does not require patching any tables in memory. This allows the rootkit to control the function in a way that is more obscure that patching a table. Kernel mode threads Threads can be created in the kernel directly. Device Drivers Device drivers are typically used with rootkits as a simple way to load into the kernel. which is often detected.DRAFT instructions. the jump or call instruction is placed into the actual code thus modifying the logic. Instead. depend on kernel level operation to query data in the system. 13. Detour patching A rootkit can place a branching instruction directly into code. Page table modifications are fairly advanced. but instead will copy code directly into memory with no associated device driver. Freestanding code Some rootkits will not use device drivers. This allows the rootkit to intercept control flow at the point of the breakpoint address. Page tables manipulation The page tables control how memory is translated into physical RAM. and thus hook a system function. and they are not associated with any process. 11. and the fact it does not have a device driver does not prevent it from working. Cavern infection Not for use or distribution outside of DARPA Contract N66001-06-C-2052 15 . 12. Modifications can be made to the page tables to hide code or data. Device drivers give rootkits all the access they need to implement all their tricks. Many rootkits are going to be using an associated device driver. Rootkits often make use of kernel threads in their designs. Rootkits that intercept activities of the application in kernel mode can easily circumvent any type of integrity check or utility tool. and rootkits that use them are difficult to detect. Page table medications can be used hide entire sections of code so that they cannot be read using normal data access. or they can be induced via debug registers in the CPU. 9. This is a superior design for stealth because there is no device driver that can be detected. 10. The code operates normally. 8. This code can be executed like any code. 7.
Injected DLL’s Simple rootkits may just inject DLL’s into other processes. 18. Service Function Hooking Tables in memory keep track of which functions should be called for system calls or imported services. Such an attack does not require an injected DLL and may provide more stealth.DRAFT Instead of allocating new memory. The injected DLL implements the rootkit. Internally induced buffer overflows A specially crafted mutation in the data state can be used to induce a buffer overflow – this buffer overflow then causes embedded data to become code. These tables can easily be modified to call a rootkit-specific function as opposed to the original function. The code then performs rootkit processing. The area at the end of each page is typically not used and there might be a few hundred bytes of available space. For example. 17. The code does not need to remain resident as code. This allows a freestanding code rootkit to appear to be part of an existing module. The process will register as having a new thread and the new thread will perform all the rootkit processing. Data state modifications Rootkits can modify data instead of code. There is no new process that can be detected. and thus increases stealth. a rootkit can remove items from a linked list. The item in question is then hidden (such as a process or file). a rootkit may copy it’s code to the end of a preexisting page. Injected thread Another simple trick is for a rootkit to inject a new thread into another process. and the rootkit operates like a parasite within the existing legitimate process. whereas data modifications are much more difficult to integrity check. 16. Code modifications can sometimes be detected. thus eliminating the ability of system calls to enumerate those items any longer. 15. 14. Rootkits that hook functions like that can circumvent any applications that depend on these service calls operating properly. The data mutation may induce the overflow on a periodic basis. or in response to a specific event – the activation of the code is cleverly disguised behind a software bug. This type of attack would be very difficult to detect with integrity analysis. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 16 .
1. Key features of Windows rootkits have been stealth capability for files. heroin. Rootkit Evolution and Operating Systems Present-day rootkits evolved from toolkits that began to incorporate features designed to hide their presence. In summary. but in fact contained malicious enhancements. such as through the use of the functionality provided by Loadable Kernel Modules (LKM)6. then emerged as distinct entities as development continued. saving copies of system and user information such as configuration settings and password hashes. OSXRX contains utilities often associated with rootkits. itf. rootkits that targeted early Sun systems running SunOS 4. however it lacks any stealth technology. shuts off the firewall. Files Commonly Replaced By Early Unix Rootkits FILE FUNCTIONALITY /usr/ucb/netstat Hides network services and connections /usr/kvm/ps Hides processes /bin/ls Hides files /bin/du Hides files / adjusts disk usage report /usr/bin/login Logs keystrokes /usr/etc/ifconfig Hides network configuration settings /usr/sbin/du Hides files / adjusts disk usage report /usr/sbin/ls Hides files Kernel exploits have long been used by attackers. which is loaded through /dev/kmem. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 17 . For example. It then creates a new user. such as the SucKIT rootkit. processes. Early Windows rootkits initially emulated the functionality of Unix rootkits. Windows rootkits emerged after Unix rootkits. Some kernel rootkits are installed as kernel or device drivers. the OSXRK installation script does some initial data collection. It is up to the attacker to find a suitable home for OSXRK on the file system. (Zovi 2001) LKM rootkits began appearing in 1997. and kis. Hence.DRAFT 2. adore. knark. synapsis. as illustrated in Table 2. OSXRK does not provide any advanced hiding features.3. and there are now many examples of LKM rootkits. with notable examples dating back as far as 1974 (Arce 2004). turns on SSH.x typically replaced operating system commands with files that appeared to be functionally equivalent. Table 3. The installation script attempts to notify the attacker (installer) if it detects system logging. Recently reported by the media as the first rootkit for MacOS. This delay is generally attributed to the availability of source code for Unix operating systems and not for Windows systems. OSXRK Tools DESCRIPTION An xinetd backdoor (Trojan) TOOL Backd 6 LKMs are a feature of Unix operating systems. not Windows. and installs the tools illustrated in Table 3. Loadable Kernel Module (LKM) rootkits take advantage of LKM functionality that allows dynamic kernel manipulation that does not require kernel recompilation. and registry entries. the most notable include: afhrm. Kernel rootkits modify or manipulate the operating system kernel. rial. we would classify OSXRX as a toolkit and not a true rootkit. Table 2.
In the case of rootkits. The third generation represents a fundamental change. policy-based risk mitigation such as driver signing is notably poor at actually preventing vulnerabilities from being introduced into the kernel in the form of 3rd party device drivers. However this approach may be useful against Rutkowska Type III rootkits. each of these approaches has been defeated over time. where rootkits alter the OS kernel rather than replace system binaries. and other generic strategies have done a lot to make system penetration more difficult. where each generation represents a significant advancement from the previous generation. this approach would be very difficult to implement because the deception must be very convincing. hardening the attack surface area. However. Auguston et al. Furthermore. Given the sheer number of possibilities. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 18 . but this doesn’t solve the problem with desktop exploitation and application-layer infections that are not easy to control by the OS vendor. where the second generation used the same basic approach but implemented significantly more features. heap overflow protection. and the exploited attack vectors are difficult to spoof. The most promising approach to OS integrity is trusted computing. but they are correspondingly harder to detect. by having a properly equipped hypervisor installed on the system prior to attack. non executable stacks. Similar to the evolution from first generation to second. The first generation of rootkits might be considered those that implemented OS binary replacement. Fifth generation rootkits are those which are fully implemented as kernel drivers. this is admittedly a very complicated approach to defense (Row. Current Prevention Methods Prevention requires general software security. A network sniffer capable of gathering local user information and passwords A unix password cracking tool capable of dictionary and brute force attacks A formal consideration of rootkit history may specify different generations of rootkits. or the automated exploit tool. patch guard. but the fourth generation rootkits implement significantly more features. Some simple examples included providing inaccurate banner responses to service requests such as reporting a false operating system or application server version. Most current advanced rootkits are fourth generation. Modern Operating Systems are intended to run on general purpose computers and to run arbitrary software from third parties. third party applications provide both a vulnerable attack surface area and poor process compartmentalization. fourth generation rootkits use the same mechanism (kernel modifications) as third generation rootkits. and implementing better process compartmentalization to confine infections before a full installation can occur.2. 2004). 2. Creation of a fifth generation rootkit requires more skill than any of the previous generations. Fifth generation rootkits are under current development. A study was conducted to thwart exploit attempts by faking out the attacker. Hence.DRAFT Netcat Die Putze Opener Dsniff John the Ripper A TCP/IP debugging tool that has many useful functions for an attacker such as enabling reverse shells A unix log cleaning (manipulation) tool A tool to startup services and collect OS X system information. Secure boot. Another approach being explored is to deceive the rootkit with a ploy that prevents it from being installed. while the Windows OS itself (for example) has a relatively small attack surface area.
This is often not done for practical reasons. 8 New specimens which re-use code or techniques of known specimens may be detected based on prior signature matches to the re-used code or techniques. and worms) is a signature based approach. as they are the processes by which the detected lack of integrity is confined (mitigation) and then removed (recovery). With such privileges. as now. Rootkit Detection Challenges Rootkits pose several significant challenges that make detection more difficult than other forms of malware. The types of signatures vary. First. is that a snapshot of the critical system elements may be taken at a time when the system is known to be in a good state. attackers installing rootkits have typically gained superuser or administrator access to the system.2.DRAFT The nature of prevention mechanisms leads us to distinguish prevention7 from detection. viruses. while detection is concerned with the lack of integrity of one aspect of the system. 2.g. accuracy and performance. integrity.3. These tools have proven generally effective against traditional forms of malware.3. or replace detection tools. the attacker can disable. While these four elements are all part of the rootkit defensive process.. e.. tailored.1. as detection capabilities. The current state of the art is tailored detection. such an approach does not extend to previously unknown rootkits. stored in a file.. prior to stealth). alter. where customized detection methods are developed based on known rootkit techniques and implementations. the approaches to prevention and detection are different. This 7 We classify integrity monitors. Additionally. prevention is fundamentally different from the others. the detection may trigger prevention mechanisms. As such. although no comprehensive effective implementation of this technique has yet been produced. e. Tripwire). behavioral. or transmitted across a network. 2. and recovery. hardware and software kernel integrity monitors.g. This method involves gathering specimens of malicious code and generating unique signatures which can be used for identification. with the exception of previously unknown specimens. 2.. modify audit logs. The idea then.. Such specimens will almost8 always defeat signature-based detection tools. some detection tools attempt to identify behaviors associated with malicious code. While effective against known rootkits. Current Detection Methods Current rootkit detection approaches may be loosely classified as signature. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 19 . Signature based detection tools may be effective against some rootkits prior to full installation (e. but these are limited and insignificant cases. Prevention is concerned with the integrity of the entire system. The most promising emerging detection technique is cross-view differences. Rootkit detection via integrity verification has its roots in file integrity checkers of the 1990s (e. rendering the malicious code invisible to any signature-based scanner. Mitigation and recovery are directly related to detection.g. rootkits often implement stealth mechanisms.3.g. and otherwise tamper with the system. mitigation. trojans. and cross-view differences. As with most detection mechanisms. Second. since they are detecting the presence of actions associated with a rootkit. or code patterns that indicate malicious behavior.g. Malware Detection The most widely used method to detect traditional malware (e. but often include byte sequences that can be scanned in memory during runtime.
However. DKOM and other kernel data structure modifications) are much harder to detect. This does not address new and unknown techniques.4. Since data is in constant flux. In fact. any discrepancy indicates a potential compromise. Second. we can be quite effective at detecting known rootkit techniques and implementations.g.3. Critical files and processes often change for legitimate reasons (from patch application to simple run state changes). and rootkit functionality may be implemented in many of the files and processes which do change regularly and therefore cannot be integrity checked. At any later time. 2. even if all tailored rootkit detection techniques were collected in a single tool. we are quite ineffective until we are aware of a technique or implementation. Although in theory the problem is very difficult. and these effects Not for use or distribution outside of DARPA Contract N66001-06-C-2052 20 . they will affect the operation of the system to some degree. 2. a trusted external system may compare the current snapshot to the known good state snapshot. See Appendix A for a sampling of tailored detection methods.3. it can be even more difficult to integrity check than processes or files. be integrity checked. changing. As with current antivirus applications. real world specimen rootkits are only attacking a few well known structures and these can. computer systems and critical files are often dynamic. Until such an OS is available. The list of files and processes which do not change is small. and (b) would have almost no coverage of new techniques and implementations. and is an example of tailored detection (see next paragraph). and complex systems. Such a requirement may be difficult in an operational environment. In principle. as with the flu. With rootkits. Tailored Detection A tailored detection method is specific to a rootkit technique or implementation. hypervisor and related rootkits (Rutkowska's Type III) are difficult to detect. Rutkowska inadvertently makes a strong case for a multiple cross-view difference based approach. the trusted monitor must receive accurate information from the system in question. then we develop a vaccine specific to this year's strain. Tailored detection is analogous to the way we currently fight the flu virus in medicine: we wait for this year's flu virus to emerge. current systems are being infected and need some means to verify data structures. However. While integrity checkers have some usefulness to detect rootkits. rendering integrity checking impractical. however.DRAFT snapshot typically takes the form of cryptographically strong mathematical hashes of the critical system elements. they suffer from several limitations. Rootkits that modify data state (e. in fact. Further. even the most advanced ones. The number of possible data structure states is infinite for all practical purposes. First. A recent trend in rootkit detection is to collect multiple tailored detection techniques into a single tool. this can be effective against a wide range of rootkits. tailored detection often fails in the face of even minor changes to existing rootkit implementations. Rutkowska recently showed how such accuracy can be compromised.3. In the case of CoPilot. the initial snapshot must be taken when the system is in a known good state. Challenges Detecting Hypervisor In theory. we still (a) would not have 100% coverage of all current rootkits. Third. CoPilot is an example of a kernel integrity checker implemented as separate hardware within the system. The correct solution would be a secure OS that offers no avenue to corrupt data in the first place.
But more subtle methods to notice a scan may again circumvent the scan.5. but rather uses a statistics based approach that groups hosts into clusters and executes comparisons of key system files. and will not detect rootkits that are resident only in memory (Wang. The system hard-drive is then mounted and another detailed directory listing is generated and saved to the floppy disk as “Clean_Scan. Other Detection Methods Additional rootkit detection methods have been proposed. any differences will be reported. 2. which of course isn't hiding its signature anymore). Microsoft’s Strider Ghostbuster is a rootkit detection tool that uses the stealth features of a rootkit against itself. which has been defeated by giving the detector a random name before running it. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 21 . as it does not report on files contained in alternate data-streams.DRAFT may be detected. and a hypervisor can be protected fairly easily by security software or configuration changes. Rootkits may suspend their activities during a scan. 2004). For this reason. hypervisor based rootkits are not common. so as not to be noticed [Wikipedia]. The accuracy of this technique appears to be promising in large environments with a small population of infected hosts (Carrier and Matheny 2004). these methods rely on detecting known process names (like "chkrootkit" and "rkhunter"). Cross-View Differences Detection Since more sophisticated rootkits subvert the operating system. 2004). which is used for testing the effectiveness of intrusion detection systems. and are indicative of hidden files. For example. One such technique proposed by Carrier identifies hosts that have been compromised by a rootkit or trojan. In practice. Strider Ghostbuster accomplishes this by providing a simple interface that allows administrators to generate a detailed file and directory listing using the system that is suspected to be infected with a rootkit. timing side-effects might be observable by comparing internal and external measurements. This approach is unique in that it does not rely on signature-based identification. The authors of “Intrusion Detection in Virtual Machine Environments” tested their methods using six common rootkits to establish a performance baseline for their solution (Laureano. Currently.6. Maziero et al. Another interesting approach involves the use of simulation. Rutkowska's Type I and Type II rootkits are the primary problem. this approach will likely continue iterating between attacker and defender with no foreseeable end. Once the directory listing is complete it is saved to a floppy disk as “Infected_Scan.txt”. Microsoft Research recently began dedicating resources to the study of rootkits and developing detection and eradication tools. This program does have some limitations.txt”. detection tools that rely on information reported by the operating system are subject to false information. The two file/directory listings are then compared by Strider Ghostbuster.3. where information gathered from two or more vantage points is compared. rootkit detection techniques have evolved to include a cross-view diff approach. The system is then rebooted using a WinPE (Windows Pre-Installation Environment) CD. While interesting. For example. In the current space.3. Vo et al. 2. One proposed solution to this is to simultaneously scan with a difference-based rootkit detector (which will see discrepancies due to incomplete stealth) and a virus checker (that will notice the signature of an inactive rootkit.
Testing Methodology We began with a library of over 200 rootkits to test against. or be able to obtain. we selected 25 rootkits which best represented the range of techniques and implementations of current rootkits. Special cases may arise where we have. and restoration of associated data files. any surgical cleaning must be complete to ensure that all rootkits (and other malware) have been removed. as well as any vulnerabilities the attacker may have created.1.DRAFT 2. this means a re-installation of the operating system from original media. Comprehensive Detection Testing During this study we conducted extensive testing to determine the accuracy of current rootkit detection tools. If a system is suspected of. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 22 . if we are reasonably certain of the specific tools used in the infection. In most cases. or can obtain. Current Mitigation Methods Current mitigation methods are generally limited to full system containment. 2. 2. exceptions do exist. Further. Each rootkit was tested against a set of 31 different detection tools. This generally ensures a clean system.6. Such an approach may be useful if the system in question is mission critical. where operational concerns may override the risk of leaving the system on-line Rootkit infected systems may also be left on-line if system owners wish to monitor and/or trace the attacker's activities. then we may have. mitigation consists of taking the system off of the network or using network hardware and software to isolate the system.5. extensive knowledge of the specific tools used in the rootkit infection. For example. mitigation may be limited to restricting network traffic to the system and careful monitoring of allowed traffic and system activity. or known to have. i. Current Recovery Methods Current recovery methods are generally limited to restoration of a known good image. As with mitigation. it may be possible to surgically remove the rootkit and restore the system to a clean state. we do not know enough about a particular infection to be able to perform a "surgical" mitigation. 2. it is generally not possible to surgically remove the rootkit while leaving the system intact. although infected installation media or data files could re-infect the system9. In such cases. systems may be infected with more than one rootkit. it is generally not possible to contain potential exposure while leaving the system on-line. It should be noted that the vulnerability which was exploited to install the rootkit must also be corrected. enough knowledge to disable rootkit functionality while leaving the remaining system intact.6. to disable rootkit functionality while leaving the system on-line and functional. Gaining such assurances can be difficult. In certain cases.. a rootkit infection. The test results clearly show that existing detection tools do a poor job of detecting existing known rootkits. or the risk of subsequent re-infection is high.4. In most cases.e. reinstallation of any applications from original media/sources. The 9 Such cases are rare but do happen. After analyzing this library. In general. which is why the current state of the art and best practices are to restore from known clean media and sources. In such cases.
" = 0 Scores are tallied for each rootkit and each detector. "Y" indicates yes. The most effective detectors have positive values and are at the right of the chart. freely available such as Rootkit Unhooker. and mature commercial tools like those from McAfee. A "Y" does not necessarily mean that the tool gave direct notification that a rootkit was present or of which type it was. Test Results Test results are summarized in Table 4. all aspects of the rootkit were detected. it is apparent that most rootkits can be detected by at least one tool. "P" indicates partial detection.DRAFT set of detection tools chosen includes well known and commonly used tools. All tests were run on Windows XP with Service Pack 2 updated to include the latest security patches as of 2007-02-18. and Norton.. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 23 . A cell entry of "N" indicates that no aspects of the rootkit were detected. This environment was kept stable by turning off further automatic updates and by taking a snapshot (Ghost) image of the system state. Table 4 presents the test results. Each detection tool was subsequently installed and executed in an attempt to find evidence of the rootkit. but no tools effectively detect a wide range of rootkits.e. 5. i. detecting only certain types of system modifications. Between each test. then the columns and rows are sorted.6. On balance. Some tools are rather specific in their functionality.e. Our test scenario was one where a machine is suspected of already being infected by a rootkit and some form of discovery/verification and mitigation is required. and 6. i. and "X" indicates a problem prohibited the detection tool from being run. some aspects of the rootkit were detected. The most elusive rootkits have high negative values at the top of the chart. the rootkit was installed and verified to be functioning. It should be noted that these tests lean towards the side of someone having internal knowledge of the system.5 Blanks and " . Others are self-described as detecting a vast array of intrusions. but rather that information was provided which would lead a knowledgeable analyst to identify the rootkit.. the machine was brought back to a clean state with the rootkit installed and functioning.2. For each test. scored and sorted according to the following scheme: Y (a positive detection) = +1 N (a negative detection) = -1 P (a partial detection) = +0. 2. and DarkSpy .
DRAFT Table 4: Rootkit Detection Testing Results Not for use or distribution outside of DARPA Contract N66001-06-C-2052 24 .
Scored and Sorted Not for use or distribution outside of DARPA Contract N66001-06-C-2052 25 .DRAFT Table 5: Rootkit Detection Testing Results .
Alternate View Not for use or distribution outside of DARPA Contract N66001-06-C-2052 26 .DRAFT Table 6: Rootkit Detection Testing Results .
We consider this a partial detection. the set of detection tools run against the infected system. The main features of XRK are: • • • • • • 100% kernel mode Logs keyboard events Logged data is compressed/encrypted No stealth tricks employed Sends data via HTTP (port is open on most systems) Not detected by current anti-rootkit tools Not for use or distribution outside of DARPA Contract N66001-06-C-2052 27 . The rootkit’s file is displayed alongside a list of expected and safe system files. the driver may be visible to the user through the use of the detection tool. many more tests would have a status of ‘No detection’. we included in our testing a custom rootkit developed independently by HBGary. permanent. If the results were to list only those cases where an actual threat detection alert was announced. a rootkit may install a system level driver. This rootkit. the tools normally display all drivers. provided on a separate CD. In such a case. it would still be very difficult to determine if such a rootkit existed at all let alone if it posed any level of threat to the system. The detection tool may not have determined that driver to be a threat. Example Rootkit Detected by Zero Tools To demonstrate the ease with which current detection tools may be thwarted. what methods does this tool use to detect the rootkit. In regards to the tool’s ability to display the existence of these types of rootkits. It is important to note that this would be true even if the rootkit makes no further attempt at hiding itself from the operating system other than by its name. Additional personal firewall tools were included in the test for this rootkit to see if any could block its communication. Further detailed results of each test of rootkit and. Each document outlines the basic functionality of the rootkit and special installation steps if necessary. Each document contains data for a single rootkit installed vs. yet the user may be still be able to notice some anomaly and make some determination to the validity of such a file being present. XRK is a 100% kernel mode key logger that will send logged data to a collection server via HTTP.DRAFT In many cases. 2. Since it is visible along with all other system files. several aspects of the test results are outlined: • • • • • • Was the rootkit detected? Was the detection process automatic or did it require manual intervention? How was it detected? When possible to determine. To what extent was the rootkit discovered? Was the tool perhaps fooled so that some detection methods were thwarted? Did the tool offer any method of mitigation? Was disabling of the rootkit successful. Regardless of attempts to hide the file. the driver could be renamed to better match real system files generally thought of as being safe. or complete? Additional comments. was not detected by any of the tools used in this study. designated XRK. For each detection tool. detection tool are kept within individual documents.7.
tracing traffic to the end user may be quite difficult.DRAFT • Not detected or blocked by most personal firewalls Except for the installing executable.. Zone Alarm Pro has features to block outbound HTTP communications. reduces chances of detection by tools. system supported code. This is produced by the build utility. XRK communicates its data through HTTP POST requests to a PHP script hosted on a remote web server. Many of the stealth techniques used by other rootkits can be detected by some of today’s anti-rootkit tools and trigger an alert. No undocumented hooking or stealth techniques are used. Almost all personal firewalls will. the current XRK implementation includes custom code to bypass Kaspersky detections. The rootkit comes with a build utility.. advanced stealth techniques lead to incompatibilities between systems and can cause problems that allow the user to become suspicious. however. but they demonstrate that the strongest defense mechanisms can be bypassed The customized bypass code may of course fail with future versions of the detection tools. Changing the name of the rootkit requires a change to a single . Creating a system thread inside the browser does not cause any alarm by the firewalls therefore XRK is allowed to send its data using methods resembling a browser. The rootkit delivery package is a single executable file. but XRK has custom code allowing its communications to bypass Zone Alarm. Investigation is already under way to develop methods that will bypass these tools using more acceptable.e. The installation of the rootkit in this manner requires one reboot of the system before it becomes live.h header file. XRK is a kernel mode driver with no user mode components. The rootkit driver should be given a name that will not stand out – something that appears as a normal system driver (i. Certain tools such as Trend Micro and Kaspersky watch system driver installation. hide in plain sight). Being easily obtained and disposable. This lack of stealth maintains the highest level of stability and compatibility between operating systems. The rootkit uses a Transport Data Interface (TDI) filter to detect browser usage. HTTP was chosen because it is commonly allowed to traverse most firewalls. and eliminates suspicion and therefore reduces the cause for any further exhaustive investigations. Fully documented Windows APIs are used to access and log the keyboard events. an analyst would need to reverse engineer it in order to determine that it is a backdoor program. by default. XRK exploits this by the TDI filter catching when the default browser successfully completes outgoing connections. If the rootkit driver is suspected. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 28 . This allows the rootkit to send data over the network only when the browser is in use. Furthermore. even if the detection tools do not recognize the intrusion. The delivery package can install the rootkit driver and bypass windows file protection on XP SP2. authorize the default browser to gain access to outgoing requests on port 80. This action indicates the request has been authorized. and the driver is not required to be signed. The remote web server may be set up by an individual using a free service such as 100webspace.com. The user is not alerted that a driver is being installed. The methods XRK employs to bypass these systems are not perfect. further hiding its actions from possible network analysis.
. and will use virtual machines Future rootkits will use alternate memory and CPUs. and (3) virtual machines. Also. we expect that extensions and variations of the cross-view differences approach will prove effective at detecting generic rootkits.e. attackers will likely move up the trust chain in order to insert rootkit code in trusted modules before they are loaded. despite the limitations of this approach. Direct code injection at a low level (e. As detection capabilities become more advanced. By operating at a lower level. recovery capabilities of the future will likely take advantage of virtual machines and other methods for quickly restoring a system to a known good state. The future state of mitigation and recovery will closely follow detection capabilities. (2) hiding in plain sight. such techniques will likely not prove 100% effective. The future state of detection is likely to continue along current paths. Current rootkits use native OS functionality to run rootkit applications. The future state of prevention is likely to parallel software protection initiatives. Similarly. thus enabling the execution of rootkit code. We expect development along these lines to continue. The second future development is hiding rootkits in plain sight. Detection tools exploit remaining evidence to detect the rootkit. then the rootkit attempts to undo or hide the evidence created by the OS. These two trends are not independent. but such development may cease if the platform proves impractical.DRAFT 3.g. and will expand to other platforms Future rootkits will be distributed and will cooperate Future prevention will rely on signed code Future detection will use multiple tailored methods and variations of cross view differences Future mitigation may include the ability to mitigate selectively Future recovery will use virtual machines and may include surgical recovery The future state of rootkits is expected to take three paths: (1) direct injection of code into running processes. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 29 . i. so some future rootkits may attempt to look like legitimate processes and avoid stealthy behavior. Specifically. and we expect both to develop concurrently and occasionally within the same rootkit implementation.. While this technique has been demonstrated. We propose some of these extensions and variations in Section 4. Longer term. will hide in plain sight. The idea is that stealth creates system behaviors that may be detected. its practical usefulness and effectiveness as a rootkit platform has yet to be proven. validating code before it runs on a system and ensuring code integrity during execution. For example. detection of a rootkit (stealthy or not) will be much harder. • • • • • • • Future State Future rootkits will use direct injection. A third trend is the development of virtual machines rootkits. While promising. direct editing of memory) provides a minimal "paper trail" for a detection tool to find and follow. it does represent a significant operational advance. useful information will be passed to and exploited by mitigation and recovery capabilities. attackers may compromise the information provided to an integrity checker. independent of native OS tools. While this is not a significant advance technically. we expect near term detection to focus on collections of tailored detection methods.
More complex and low-level techniques for hiding rootkits are an investment of money. Rootkits applied to embedded platforms do not need all the fancy low-level stealth techniques characterized in section XX. We have seen certain responses to security software already. Emerging trend: Go lower To go lower means to hide in more hardware specific layers of the system that are not addressed by current security technology. This may also mean utilizing non-CPU hardware. What that data is and why is irrelevant. Rule #2: Rootkits Respond in Kind The second rule of rootkits is that they will evolve when they have to. rootkits will take the easiest and most inexpensive forms of development – simple Trojans and backdoor programs.1. Emerging trend: Rootkits for embedded platforms Embedded computing technology now outclasses traditional PC machinery.DRAFT 3.1. And. These intentions are centered on the covert acquisition of data. Although many rootkits modify the OS. all you need to examine is where the data will be processed in the future. 3. rootkits need to fulfill one of the intentions lists in section XX. Remember that rootkits are really about stealing data covertly. Rootkits are already starting to emerge for these platforms.1. They are protected only by their obscurity. Future State of Rootkits This section outlines upcoming trends in rootkit evolution. Emerging trend: Hide in plain sight The hide in plain sight approach is also valid. This is not so difficult. Many security technologies rely on the detection of abnormal OS modifications. The platforms themselves are not very secure and are in fact easier to develop rootkits for than traditional windows.2. This means CPU specific features will be exploited for stealth purposes. • • • Rootkits follow the data Rootkits respond in kind Rootkits are here to stay 3. and (3) virtual machines. Only when security software or designs prevent current rootkit technology from working will new rootkits techniques be developed. Rule #1: Rootkits Follow the Data To be useful. (2) hiding in plain sight. Until security software evolves to address the rootkit problem on embedded platforms. such as devices on the bus or IO chipsets. These trends are documented as three fundamental rules which drive specific trends. they will be developed. If Not for use or distribution outside of DARPA Contract N66001-06-C-2052 30 . Most of these trends support the three expected evolutionary paths of rootkits:: (1) direct injection of code into running processes.1. they don’t have to. and so we can assume these trends will simply continue. To know what kinds of technology rootkits will be used on in the future.
or multiple copies of data. this problem is very difficult. The countermeasure to this form of rootkit is to simply detect the malicious code – it’s not hiding after all so this should be easy. flashcard. Emerging trend: Rootkits in system hardware Rootkits that ‘live’ in the system hardware and firmware. These caches can be modified and desynchronized to hide data and code within the system. It will continue to be applied to Microsoft and Unix systems and will only emerge on embedded systems once security software starts to scan memory. The hardware maintains caches. These might live in attached device memory and BIOS.DRAFT this can occur without using stealth. and if stealth is detected. The boot vector will be on disk. then the obvious solution is to not hide at all. until new architectures are developed to force this code to be secure. it involves copies of memory that are maintained within the chip itself. May be defeated by trusted boot process. or solid state disk. Because computing platforms have such extensibility. but this is not implemented in most situations. So. In this case. as opposed to on-disk with the OS. Rootkits are starting to take advantage of these layers of functionality to mask memory and hide data. Emerging trend: Exploitation of hardware specific cache mechanisms This is an extension of the memory exploitation already described. Emerging trend: Exploitation of hardware specific translations of memory This is already in common use. hiding in plain sight will always be a trend. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 31 . Hardware has complicated methods to translate memory access. Emerging trend: Boot vector rootkits Modification made to startup software used to start the operating system and kernel. BIOS or firmware. The problem with detection is knowing what to look for. The systems are designed to accept new code into the desktop and allow this code to become an extension of features.
step 1. Once installed. In Figure 5. such methods maintain control while being unobservable. but standard memory analysis is rendered useless.DRAFT Decryptor Code Cache Code and data are desynchronized Data Cache Main Memory Main memory never has a decrypted version of the data Cache exploitation Decryptor Code Cache Data Cache Step 1 Figure 5: Cache exploitation This trend is especially dangerous because cache information cannot be observed external to the hardware. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 32 . the decrypt or portion of a code stream decrypts the second part of the stream completely within the cache without causing the decrypted data to persist to main memory. Execution behavior analysis can still detect these types of rootkits.
DRAFT Code Cache Re-encrypts . the exploit is used as a non-obvious means to load code into the kernel or as a way to intercept a control flow without using a patch. If the patch is detected. These can be leveraged by rootkits to intercept code. This is an obvious trend if rootkits are to be placed on embedded devices since most of the persistent memory on such a device is flash based. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 33 . In general. such as video BIOS and drive controller memory. Almost all devices. step 2 In Figure 6 (step 2). Emerging trend: Firmkits Rootkits that store their primary code payloads and potentially data in firmware that is addressable on the bus. but the code that the patch jumps to is not. patches are easy to detect. including PC’s. Security evaluation can remove many bugs. the next portion of code re-encrypts the data in the cache. or deletes previous data Data Cache Figure 6: Cache exploitation. Emerging trend: Exploitation of hardware specific event interception There are non-obvious way to induce an interception event for code execution. have some amount of addressable flash memory which can be modified. This is plain old buffer overflow exploitation. so that data reads will not be able to recover the unencrypted portions. but instead of exposing the system to a remote attacker. Rootkits merely have to access the bus using fully documented and established means of reading and writing firmware. or deletes it entirely. Emerging trend: Internal buffer overflow activation Data changes can easily induce program errors in most code. The basic theory is “patchless interception”. but if the patch cannot be located in the first place. Internal bugs can be exploited as a means of moving a data-modification into code execution. then it can be followed to the subversive code payload. The data modifications themselves would be very difficult to integrity check. The reason is that the subversive payload will look just like dynamic data on the system. but internal code that is not exposed to potential attackers does not receive the same amount of auditing. then the subversive code payload will be very difficult to find on its own.
Each processor likely has a set of programs somewhere in memory that are designed for it. Rebooting all the systems at once is not a viable option because in reality. allowing the malcode to be run as trusted code (this false trust could be more dangerous than the current untrusted environment). never touching the main CPU at all.3. Rootkits do not need to run on the main CPU. 3. allowing for the execution of Not for use or distribution outside of DARPA Contract N66001-06-C-2052 34 . no system is foolproof. Like all complex systems. Fourth. but they exist. First. and rootkits will always have a place in the world of information. In practice. A mechanism will be developed to use the emergent behavior to create a specific and known result. since any data traversing the bus is fair game for the rootkit. If Finn is rebooted. Large scale network infections will be extremely effective using this method. As long as there are human beings in the universe. Emergent behaviors are behaviors that were not intended as part of the design. Rule #3: Rootkits are Here to Stay Information systems will only get more complex. there will be tens or even hundreds of systems with infection. 3.DRAFT Emerging trend: Peripheral rootkits Rootkits that live entirely within a perihelia device. The only way to stop this infection is to close the remote vulnerability. the signing process itself may be corrupted or spoofed. it is possible for a rootkit to put it’s main processing code into a paraxial CPU and access the bus directly. Remember that every computer has multiple processors. malicious code may be incorporated in an application before the signing process occurs. These behaviors can sometimes be amplified to make a complex system do something unexpected. and thus lost from memory. if Huck is rebooted and lost. Any processor that is connected to the bus can become a processing center for a rootkit. there will be someone who will exploit emergent behaviors with a willful hand. The converse is also true. Information systems of the future will not be perfect.2. and other times main system drivers will configure these sub-CPU’s at runtime.1. so malicious code could not be executed. Emerging trend: Huck Finn rootkits Rootkits that are able to exploit a system from remote and place an active payload can be combined w/ botnets such that one rootkit (call him Huck) can protect another rootkit (call him Finn). In any case. Many times these programs will be in flash memory. In short. Finn will replace Huck. it may be difficult or impossible to sign every piece of code that a system needs to execute. Third. this is a more general property of nature that can easily be applied to rootkits. computing machinery will continue give rise to emergent behaviors. In theory. and attackers will likely find flaws in the implementations of the trusted computing mechanisms. this is much harder than it sounds for several reasons. such platforms would only execute code signed by a trusted third party or otherwise verified. they will continue to be exploited in new ways. Future State of Prevention The most promising emerging technology to prevent rootkits is the emergence of consumer-class trusted computing environments. Such advanced features as keystroke sniffing may be able to be implemented without going into main memory at all. Huck will reinfect Finn w/ the remote exploit. This is similar to many network worms that have already been seen in the wild and will continue to be a problem. Second.
DRAFT unsigned code. 3. The second phase addresses the key limitation of the first phase. and both technologies support the rapid restoration of a system to a known good state.4. but will extend this idea to detect other indirect effects of rootkits as well. thereby allowing us (possibly) to undo these actions. While we may be able to generally detect a new rootkit. Prevention is likely to remain a partial solution which relies on detection to help ensure a reasonably clean computing environment. Current mitigation consists of infected system quarantine. Given that information obtained from a potentially compromised system is inherently unreliable.5. The first phase consists of aggregating current tailored detection methods. Such a record would theoretically allow us to go back and determine actions since a compromise began. methods to reason over uncertain and partial information will be a component of future detection as well. some changes maybe irreversible. As with mitigation. Based on current and emerging research. Validating all of this code (so that it may be signed and trusted) is not practical. will represent this second phase. without specific tool or implementation knowledge. Methods which detect rootkits generally. namely that new or variant rootkits would not be detected. attackers may choose to attack or compromise the logging system itself. and aggregating multiple tailored detection techniques is likely to provide good detection accuracy against known rootkits. disabling rootkit functionality while leaving the rest of the system intact) requires significant knowledge of the rootkit implementation. Future State of Recovery System recovery will likely evolve in two phases. today or moving forward. The continued development of rootkits means that obtaining this Not for use or distribution outside of DARPA Contract N66001-06-C-2052 35 . having the knowledge to surgically mitigate it will require new knowledge for every instance. rendering the log unreliable or unavailable. 3. One possible advancement which would support surgical mitigation is to track all of the activities on a system in a trusted log file. 3. Future State of Mitigation While the future state of detection is promising. Both technologies are rapidly maturing and have entered production markets. As rootkits are under active and increasing development. Such methods are effective against specific rootkits. Our forecast for the future state of detection is captured in our proposed solution in Section 4. one of the drivers of our modern computing environment is the availability of software and a flexible platform to run it on. Such capabilities allow for the frequent (even arbitrary or preventative) restoration of systems.. such surgical recovery requires detailed knowledge of specific rootkit implementations. The near term certainty relies on the increasing deployment of virtual machines and blade or similar hardware. Practically speaking. Finally.e. Finally. one a near term certainty and the other longer term and less certain. these methods will rely in part on a cross view differences approach. minimizing rootkit infection impact. the future state of mitigation is unlikely to change in the near or mid term (2-5 years). Future State of Detection The future state of detection is likely to evolve in two phases. and the complexity of a modern operating system may make deconstruction of the actions and log file intractable.3. obtaining such knowledge will remain an ongoing effort. The second and less certain development will be the ability to surgically recover a rootkit infected system. Any surgical mitigation (i.
End of assembly language Operating systems will evolve to the point where native code is no longer developed or allowed. offered by most cellular phones and many PDA’s. Many new rootkits will be attacking handheld computing. and only strongly typed languages can be used to build device drivers and other extensions to the system. The whole idea of a monolithic software program controlling access to the computer will cease to make sense. a detailed system tracking mechanism may allow for surgical recovery as well. When this becomes enforced as opposed to optional. 3. Encapsulated functions can be represented in strongly typed languages and programmers can be forced to use strict access models. As with future mitigation. This potentially would exceed billions of dollars in damages. and benefits the operating system security overall. but. Data will be stored insecurely on cellular phones and PDA’s for many years until the new technology catches up to security standards. if they occur. Instead. Rootkits could be installed that are not easily removed. access to hardware specific. Large scale worm infection through critical vulnerability Microsoft’s operating system could be found vulnerable to a reliable buffer overflow or other exploit and a massive worm infection could sweep the internet.6. may significantly change the landscape for rootkits. so will develop a staggering volume of potential new exploits. we present possible landscape changing events. and in-place infections could remain for decades. encapsulated components will manage access to parts of the machine Not for use or distribution outside of DARPA Contract N66001-06-C-2052 36 . Explosion of handheld computing As embedded devices proliferate the worldwide data space. and CPU features can be tightly access controlled by policies set forth in the operating system. This allows components to place much tighter controls on how they can be used. low-level features of memory translation. interrupt handling. bus access.DRAFT knowledge will be an ongoing effort. Remote Telecom Firmware Worm Remote firmware update features. could potentially be exploited to create a massive rootkit infection across wireless handheld devices. Landscape-Changing Events In this section. Disappearance of the OS Eventually computers will not have operating systems. operating system components will be encapsulated into small well understood components that can easily be protected. Such events are not certainties. offensively and defensively. Partial OS Encapsulation Instead of the continued direction of building operating systems that “do too much”.
assuming they can crack into the application in the first place. the entire computer is thrown away.DRAFT and make their services available to other software. This will drastically increase the security of the enterprise will also drastically reduce the cost of software maintenance in the enterprise. Terminals for the computing will likely be the same device providing cellular phone access or equivalent. which will be unlikely given time to market momentum and the use of throw-away SSOC technology. and most certainly will be forced into applications with little to no access to unauthorized components. Personal information will be held encrypted on small smartcard-like chips and applications will be purchased for one-time use. Emergence of new VM CPU’s New CPU’s could be released that implement hardware virtual machines (not to be confused with hypervisor) – but more like a java virtual machine implemented in hardware. These components may be cryptographically signed and authorized to operate with a system. Disposable computing Computers will become so cheap that it costs less to throw them away than to keep them around for continued use. and endpoint computers will be dumb terminals. and will provide a strongly typed. Based Not for use or distribution outside of DARPA Contract N66001-06-C-2052 37 . Solution Roadmap We propose a solution based on probabilistic reasoning over passive and induced indirect effects collected from multiple perspectives: • A suite of "tests" to collect evidence (induced and passive) • A host agent to execute evidence collection at five different levels • A Multi-Entity Bayesian Network to reason over evidence The primary limitation of current approaches is that they do not detect new or modified rootkit tools or techniques. So-called ‘trusted computing’ will be realized by these tamper-proof containers. These types of chips already exist for Java. will be secured using hardware tamper-proofing technology. Rootkits will be rare. commodity SSOC technology. Applications will be integrated directly into a microchip with prepaid minutes of use. and new chips could be developed that have the required performance for Microsoft or desktop applications. When the application minutes are consumed. Centralized computing Large enterprises will stop installing software on endpoint computers and instead will host applications from a central location. 4. Secure System on a Chip (SSOC) Single-chips will contain the entire computer. well controlled language to access features of the computing hardware. Rootkits will be thrown into the trash with everything else. Endpoint terminals may operate on inexpensive. A new chip could be designed with strongly typed language and access and would be extremely secure.
virtual machine. current detection techniques are successful against known rootkits and techniques.2. mitigation and recovery cannot occur until detection has occurred (one cannot mitigate or recover from something one is unaware of). we established that current detection methods are ineffective against current rootkits. Indirect effects are common to all rootkits. 4. Further. and (c) advanced evidence marshalling and reasoning. Solution Requirements In the previous sections of this report. all aspects of rootkit defense (prevention. future rootkit development will likely reduce the amount of direct evidence available for collection and analysis. detection. The proposed solution addresses the limitations of current approaches and accommodates anticipated future rootkit development. effective detection will provide pointers and information of use in the mitigation and recovery stages. and future rootkits. resulting in an endless reactive cycle of techniques and countermeasures. For example. and recovery in terms of techniques and information flow. mitigation. First. However. and (c) advanced evidence marshalling and reasoning. By keying on direct effects. and current detection methods will certainly remain ineffective against future rootkits. where some of these observables are deliberately induced. This approach is based on (a) the acquisition of direct and indirect observables from multiple perspectives (host OS. Current approaches are poor at detecting new or modified rootkit tools or techniques.1.DRAFT on our research and analysis for this project and other work. we propose just such an approach which will detect current known. We propose that the limitations of current approaches can be remedied by an approach which has the following characteristics: (a) detection of indirect rootkit effects. This approach may be summarized as "probabilistic reasoning over passive and induced indirect effects collected from multiple perspectives". Therefore. regardless of technique or implementation. The proposed solution includes collection of indirect evidence of features common to all rootkits. we conclude that any approach to solve this problem must have the following three features: (a) detection of indirect rootkit effects. (b) evidence collection from multiple perspectives. rootkit prevention is part of a larger effort to prevent system compromise in general. Effective rootkit detection supports mitigation and recovery in two ways. mitigation. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 38 . resulting in an ability to detect new rootkits and techniques without relying on direct evidence. Detection of indirect effects is necessary because the direct effects of rootkits are specific to the rootkit techniques and implementations. and recovery) are equally important. First. and remote). 4. (b) evidence collection from multiple perspectives. rootkit elements must reside in memory and must use processor time in order to perform any actions. Solution Scope The focus of this research has been on rootkit detection. We consider rootkit prevention to be a separate effort from the other phases of rootkit defense for two reasons. and (b) reasoning over these observables using a probabilistic and dynamic knowledge model. compromise prevention in general has little in common with detection. and second. current novel. but perform poorly against new or modified rootkits or techniques. In the sections that follow. Second.
no single piece of evidence is expected to be conclusive. created under abnormal usage conditions. As another example. Given that we are collecting indirect and potentially unreliable evidence. We create abnormal usage conditions by creating many processes in rapid succession [QMDNS 2007]. we found that the PID of the hidden process is not assigned to one of the new processes that we create. we observe a general trend in rootkit development which is rendering less direct evidence available for analysis. and may produce different observables under abnormal usage conditions. we create abnormal usage conditions on the systems in question. again consider a hidden process. we can establish that a PID was skipped for no apparent reason (the real reason being that the hidden process had claimed the PID already and the operating system prevented duplicate PIDs from being created). evidence should be collected from as many different perspectives as possible. we can calculate the amount of memory that should be free. drawing quality conclusions from that evidence becomes a challenge. evidence may be collected from within the suspect host itself as well as from remote points. All evidence collection is dependent on the host system to greater and lesser degrees. We devised a simple program [QMDNS 2007] to empirically establish the amount of free memory by Not for use or distribution outside of DARPA Contract N66001-06-C-2052 39 . Consider two computer systems which are identical except that one is infected with a rootkit and one is not. Additionally. In many cases. Since one of the rootkit operator's main goals is to evade detection. produce identical observables). uncertain. Under normal usage conditions. Indirect Effects Identifying indirect rootkit effects requires an innovative approach.e.. Since we also know the total system memory. We can enumerate all visible process and establish their memory footprints. To generate observables related to indirect rootkit effects. most rootkits incorporate multiple methods to modify information provided to a potential analyst. constitutes indirect evidence of a rootkit. In our previous experiments. and potentially contradictory evidence. To mitigate this problem.DRAFT detection of indirect effects means detecting evidence that memory space and processor cycles are being used by rootkit elements. As the PID selection algorithm is deterministic. For example. Such an observable. Solution Implementation 4. A successful solution will have the ability to reason over partial. Given that a system under consideration might be compromised. these two systems may behave identically (i. However. although neither the process nor the PID are visible to a system user or administrator. consider a rootkit which hides a process.3. 4. For example.3. such a hidden process is assigned a process ID (PID) number. Further. and our observables consist of a list of assigned PIDs.1. we consider all available evidence to be potentially unreliable. the two systems are in fact different.
if a compromise of the web server process is present. if that fails. Evidence from multiple perspectives provides two key benefits. virtual machine. The development of evidence collection routines is an ongoing process.g. However. If no compromise is present. covert communications. For example. which provides a wealth of information about a system and the processes running on it.3). As a result. we have additional subchoices. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 40 . the network stack) . and keep halving until we get another successful allocation. data capture.0 GB. If we identify a discrepancy.5 GB.DRAFT allocating memory until an out of memory error is reached10. This injected code will listen for a specific byte sequence. at the highest level. Also. Many current rootkits operate at the kernel level. However. For example. then we have indirect evidence of a hidden process. then we try to allocate 0. Second. some evidence may not be available from all perspectives. For example. we may provide a specific byte sequence to a listening web server. and is relatively easy to collect since we do not require any special 10 We allocate memory in a halving scheme. 11 This is analogous to injecting a person with dye in order to trace blood flow. We augment the collection of abnormal usage observables with additional evidence. then our byte sequence will appear in unexpected places.2. and so on. some information available at the user level may be modified by the rootkit.3. it is difficult for any rootkit mechanism (current or anticipated) to uniformly corrupt evidence from all possible perspectives. We are continuing to develop these schemes and code for indirect and direct evidence under normal and abnormal usage conditions. For example. and so on until we get a successful allocation. and take appropriate action when such a sequence is detected. Such a detection would constitute indirect evidence of a rootkit infection. not all information at the user level will be corrupt (consider the previous process creation and PID example). we try to allocate 1. Evidence collected from different perspectives will be available to the reasoning component (Section 6. user level data provides a useful perspective for comparison.. Multiple Perspectives We propose to collect evidence from three different perspectives: host. We have developed a scheme to detect such injected code by inputting known data to running processes then analyzing physical memory to detect that known data in unexpected memory locations11. then the byte string should only appear within the memory space of the web server and associated operating system code (e. This additional evidence is captured through means such as physical memory analysis.3.). We total the successful allocations to get a measure of the true free memory. While rootkit mechanisms may corrupt evidence from one or more perspectives. First. Within the perspective of host evidence collection. a known covert communication technique is to inject code into an already running process. we can compare evidence from different perspectives to identify discrepancies (this is an extension of the cross-view differences concept). hidden files. We record the successful allocations as we go. and remote. 4. and we cease when the smallest memory unit is not able to be allocated. etc. a trend which we expect to continue. we can collect evidence from a user level perspective. Utilizing different perspectives allows us to capture evidence that would otherwise be unavailable. and for a range of rootkit behaviors (hidden processes. We then start with 1/2 of the last successful allocation.
For example. While information at this level is still suspect. The advantage of detection resistant evidence collection mechanisms is that the rootkit processes will not be able to take detection countermeasures. In any case. For example.. The advantage of this remote view is that we can compare the evidence gathered remotely to evidence gathered on the host. It is significant to note that we do not anticipate agents requiring any special privileges in order to conduct this remote evidence collection. We can also collect data at the kernel level. Evidence from this virtual machine perspective is joined with evidence from the other perspectives by the reasoner.collecting evidence externally to the guest OS allows us to observe the environment in which the rootkit is operating. Remote evidence collection consists of evidence generated by the actions of one agent against another remote agent.DRAFT privileges. Considerable attention has been given recently to rootkits operating as virtual machines to evade detection . Alternatively.e. discussed in Section 6..3. or at a lower level. but rather are executing normal actions over the network in order to provide evidence from a different perspective. We also note that we still collect evidence from within the guest OS using the mechanisms outlined above for the host perspective. then we have evidence of a potential rootkit12. so our external to guest OS view may actually involve evidence collection at several levels and in several virtual machines and/or host operating systems. including kernel level rootkit processes. the agent on host X may listen on the network for all traffic to or from host Y. We will also use this remote agent capability to support tests such as the web server dye packs. operating on a comparable level to advanced rootkits. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 41 . This may be implemented within the virtual machine. We note that virtual machines within virtual machines are possible. We can further divide kernel level data into two categories: overt and detection resistant. In fact. we have a greater chance of collecting accurate information. but the local agent on host Y indicates that port P is not listening. Besides providing additional evidence for comparison. an agent on host X may attempt to connect to port P on host Y. We are not conducting remote penetration testing. Detection resistant kernel level evidence collection mechanisms will not be visible to other users or processes. Overt kernel level evidence collection mechanisms (e. i. but to hide the listening port from the system's authorized users. 12 A common rootkit technique is to listen for remote control traffic on a given port. such mechanisms will only be visible to authorized administrators in the same fashion that a rootkit is typically only visible to the rootkit operator. As with user level data. collecting evidence outside of the guest OS avoids any rootkit counter detection mechanisms implemented within the guest OS (as they would be normally implemented under a non-VM rootkit infection). yet the rootkit would never be aware that it was operating in a virtual machine (hence external to the guest OS detection might fail).g. somewhere between the guest OS and the hardware. kernel driver) will be visible to any user with appropriate privileges. kernel level data provides another perspective for comparison. All collection will occur in accordance with existing host and network security policies. the host OS. if a remote test indicates that port P is listening on host Y. it is entirely conceivable that a rootkit could infect a guest OS on a virtual machine. The virtual machine perspective consists of collecting evidence at a point external to the guest operating system.
2006.g. methods at level 1 (hardware) enter at the hardware level. we require a means to reason over all of the observables in a structured way such that we can reliably determine whether a system is compromised or not.. Solution Architecture A conceptual representation of the solution architecture is provided in Figure 7. MEBN provides a flexibility and representational power suitable for the nature of our observables and our reasoning challenge. then joined into a larger network. George Mason University C4I Center Technical Report C4I06-01. these Bayesian Network fragments may be thought of as objects or templates. In a fashion similar to object oriented programming. the commands executed may then traverse the other levels to collect evidence (indicated by the vertical gray background double arrow behind the blue boxes. uncertain. and Multi-Entity Bayesian Networks (MEBN) are an extension of Bayesian Networks. methods at level 3 (visible kernel driver) enter at the kernel level. and we are running an "Agent" (orange box) on that host. and potentially contradictory14 information about the system in question. so we may deploy only methods at levels 4 and 5.3. etc. The agent can collect evidence at 5 levels (5 perspectives). we can't get any evidence without using OS and kernel commands at some point). an organization may not want kernel drivers or hardware. K. methods at level 4 (user level tools) access at the user level.. For example. can definitively establish that a system is compromised. “MEBN: A Logic for Open-World Probabilistic Reasoning”. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 42 . Therefore. The multiple sets of observables created by our various actions and evidence collection represent partial. No single observable. The agent's primary function is to collect evidence and supply it to a local or remote reasoner. and a means for us to reason over new observables to assess system state. The green lines with dots for ends indicate the entry point for evidence collection methods at that level. but will likely make use of OS and kernel level calls (indirectly) to collect evidence (i. methods at level 5 (remote collection) enter at the user level. Probabilistic reasoning provides a means for us to represent our prior knowledge about the relationships between the observables and possible system compromise. for example. as indicated by the green numbers 1-5. Reasoning over Observables We reason over the observables using Multi-Entity Bayesian Networks13. which are then instantiated and joined as observables become available. Note that these are just the entry points for data collection. This is important because we may collect the same evidence. so we'll get a discrepancy (a cross-view difference).e. but then contact the remote system at the "hardware" level (NIC). MEBN allows us to capture prior knowledge as separate Bayesian Network fragments. our evidence is inherently uncertain and may in fact be contradictory. the host being analyzed is represented as the "Local Host" (grey box). In the figure. 4.. Bayesian Networks are one probabilistic reasoning framework. of which multiple copies may be created with varying arguments.3. one access point may be compromised. 14 Recall that we are executing code on a potentially compromised computer system. e. Agents are also running on other remote hosts. but we are doing it from different access points. Therefore.4. The systems of the local host are represented in blue. 13 Laskey. or set of observables from a single test. Each of the levels is optional.DRAFT 4.
For B. Not shown in the figure. That reasoner is also collecting evidence from other agents. methods at the other levels (1-4) are collecting evidence on and about the local host. the reasoner (as a central reasoner or via the local agent) will alert the user. Optionally. For A. indicated by the orange arrows labeled A and B.DRAFT Methods at level 5 (remote collection) are unique in that they are collecting evidence about a remote host. including other agents which have collected level 5 evidence against the local system. etc. in which case we would pass local level 5 evidence to the local reasoner. Figure 7: Solution Architecture Not for use or distribution outside of DARPA Contract N66001-06-C-2052 43 . that belief in rootkit presence has exceeded some threshold. analyst. The alert will include the evidence that supports that conclusion. The reasoner (using Bayesian Network models) takes in evidence and produces a likelihood of rootkit presence. We have two (not mutually exclusive) reasoning options. the local reasoner could really be a distributed computing agent. evidence from all 5 levels (or a subset of those levels implemented on a particular agent) is passed to a central reasoner. evidence from methods at levels 1-4 is passed to a local reasoner (it doesn't make sense to pass information about a remote system to the local reasoner). such evidence will be useful for the mitigation and recovery phases. administrator. and the local reasoner would also receive level 1-5 evidence from other agents and about other agents (similar to the way that peer-to-peer networks operate).
whether local or remote. Passive evidence will be collected by simply observing objects or behaviors within the host system and the surrounding network. processes.g. evidence may be revealed as to the intent of the software or the software user... less likelihood of detection by malicious Not for use or distribution outside of DARPA Contract N66001-06-C-2052 44 .4). It might be a snapshot of the entire host memory.) as well as mitigation actions (e. Passive interaction might include. This should not be confused with a requirement for regular signature updates (ala antivirus applications). memory snapshots. This central system will have responsibility for pushing out new agent software with collection. obviating the need for the central system.. loaded software codes and dynamic data. and the monitoring of insider threats. A shortage of subject matter experts increases the value of having these advanced incident response capabilities via remote access. We anticipate that most agents will be maintained by a centralized system and common authority. The host agents will have the ability to collect evidence using methods at 5 difference levels (see Section 5. Such local reasoning will be less complete than reasoning over multiple agents. Furthermore. taking memory snapshots to further investigate a possible rootkit. disk content captures. Host Agents The host agents are the means by which evidence is passively and actively collected from each host and transmitted to the reasoner. and analysis modules. By dynamically interacting with running programs. but may be effective and suitable for certain environments. this approach has better access to system information (i. registry modification. the agents will have a capability to retain evidence locally and perform local reasoning. the analyst can verify actual program behavior and sequence of execution. This interaction may be initiated locally or remotely. The agent will be dynamically extensible and maintainable to accommodate new evidence collection methods and other capabilities as they are developed.). we recognize the occasional need to update the agent's capabilities. incident response. randomly. Evidence will also be collected by observing system response to deliberately induced abnormal conditions. which is applicable to digital forensics.e. Computer memory contains.DRAFT 4. evidence). or just specific regions of memory such as a snapshot of the kernel or a given application. As an alternative. However. and show encrypted data in clear text. etc. The agent itself will be implemented as a virtual machine and corresponding instruction set. This “live” memory contains crucial evidence to the behavior of running programs.g. Such actions might include additional evidence collection (e. Advanced forensics tools are needed for subject matter experts to “drill down” to assess if a problem truly exists. Compared to a user application or kernel driver.4. driver unloading.1. The agents also will have the ability to take actions on the local host. and the central system will serve as the repository for evidence recovered from the hosts. by design. or on a scheduled basis. track how data propagates through software. for example. and live memory. detection. process termination. The agent will not require regular updates in order to detect rootkits (even novel rootkits). Memory snapshots may be taken on-demand. etc. and may be either passive or active. suspected malware.
Not for use or distribution outside of DARPA Contract N66001-06-C-2052 45 . Figure 8 shows the agent implemented as an Integrity Machine Kernel. less system impact. better cross-platform portability.  A set of test programs (evidence generators and collectors) will be developed that check memory for malicious codes. is easily testable for reliability. read operating system structures such as process and thread lists. and can be designed for minimal impact and footprint on the host computer.DRAFT code. programs can be tested in a testharness prior to deployment. Such processing might include additional evidence collection or mitigation actions. a network management tool) for further processing. Because tests are built from a set of basic opcodes. driven by the reasoner results and human interpretation. a smaller footprint. and better integrity verification.  When a predetermined threshold of rootkit likelihood has been exceeded. The reasoner will consider the results from many separate tests in order to determine a likelihood of infection or malicious code. This gives the agent access to evidence at multiple levels to support more accurate rootkit detection.  Tests produce results (evidence) which are delivered to the reasoner. The integrity kernel can be developed for multiple platforms. The integrity program can contain all the logic required to run a specific test on the host. nearly any test conceivable can be built without having to add any code to the implant portion of the agent. alerts can be delivered to an external system (e.  The integrity test program is a small program designed to be executed by the integrity kernel. The numbers in the figure correspond to the explanations that follow. and memory within EEPROM and devices.g. The results of the test can be returned to a central system that is managing a set of deployed agents. Most malicious software on a computer system will be visible in one or more of these areas of the computer system.. This allows many factors to be tested in relation to one another. This program will consist of special bytecodes designed to be executed by the integrity kernel. and making use of the agent's remote evidence collection and mitigation capabilities. Furthermore. including the main CPU registers. or it can be provided to the local reasoner.  The integrity kernel is a virtual machine that understands a special bytecode-based instruction set. This instruction set includes instructions specifically designed to read physical memory and registers. and read the filesystem.
4.DRAFT Figure 8: Agent Implementation 4. We also propose a second alternative where the reasoning itself is also distributed. where these alternatives are not mutually exclusive. instances of these fragments are instantiated and connected according to pre-coded logic15. In both alternatives. the connected networks that result from a unique set of evidence are themselves unique. we construct knowledge models as Bayesian network fragments. When evidence is presented to the models. and could involve redundant computation at multiple points. The first alternative is the traditional idea of transmitting all evidence to some central location where the reasoning occurs.2. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 46 . Reasoning We propose two alternatives for the reasoning component of this solution. This alternative is only conceptual at this point. This is how reasoning over evidence from distributed sources has been accomplished in the past. The reasoning models are assumed to have access to all evidence from the multiple perspectives.e.. In fact. In this alternative. one of the 15 Despite the pre-coded logic. the evidence itself drives the network creation. i. We do note that complete evidence is not required in order for reasoning to occur. or could emphasize a parallel distributed computation approach. reasoning does not occur at a single central location but instead is distributed across all of the agents in a distributed computing model.
If we consider the full lifecycle of rootkit defense to include prevention. but directly supporting the mitigation and recovery elements as well. Additional tests may be those recommended by the reasoner. Optionally. Concept of Operations We envision the solution proposed here as part of a larger rootkit defensive capability. the tests are uploaded to the local agent (or a remote agent if it is a remote test) and scheduled for Not for use or distribution outside of DARPA Contract N66001-06-C-2052 47 . the reasoner (local or remote) will detect this as a supra-threshold value for the hypothesis "rootkit present". After considering the information presented in the alert. Tests may be stored in a local library.or post-rootkit infection. which may be updated at any time via remote communication with the central server or via local host updates. the only advantage to early installation is earlier detection. The alert will include the likelihood of rootkit presence. Installation may be performed remotely using existing tools such as Microsoft SMS. Agent installation may be performed pre.DRAFT benefits of probabilistic reasoning and Bayesian Networks in particular is their ability to reason under partial and uncertain information. network traffic. but otherwise we consider prevention to be distinct from detection. In any case.3. then we see this proposed solution primarily serving as a detection capability. the agent runs in detection mode. mitigation. Hosts with agents at multiple perspectives will provide the most complete evidence and will likely result in the most accurate detection. The frequency of detection test execution. The alert triggers human interaction and additional activities. and recovery. one or more tests may be pre-loaded and a local reasoner may be installed. 4. The analyst may also choose to create new tests. In any case. mitigation. and additional evidence which could be collected to strengthen the confidence in the assessment. or a combination. The quality of the reasoning will vary by host. the installation consists of loading the virtual machine (the integrity kernel) and associated bytecodes on the host. even hosts which have no agents installed will have some detection capability via reasoning over remotely collected information (open ports. which tests to run. Since our solution operates in a detection and not a prevention capacity. the reasoner will generate an alert via a pre-configured channel to a third party system. evidence is collected by the agent and passed to the reasoner at some interval. the reasoner will generate an alert via the local agent interface. and communication with the central server (if used) are configurable parameters. If local. The alert notifies a human analyst that a rootkit may be present and passes supporting information to the human analyst. etc. the supporting evidence and reasoning chain for that assessment. In any case. and recovery. If a rootkit is present. may be other tests chosen by the analyst. the analyst may choose to execute additional tests and/or evidence collection. or installation may be performed locally using Installation Wizards or similar tools. Once installed. The local reasoner consists of a compiled version of the Bayesian Network model for rootkit detection. detection.4.). etc. Our detection also supports prevention in a feedback capacity (providing information which can be used to improve prevention).. However. If remote. The models which are constructed can then be queried for likelihoods of rootkit infection for one or more hosts.
such as memory snapshots. like changes to firewall rules. In any case. we will attempt detection of rootkits on actual systems under investigation. In these cases. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 48 . Partial success will be defined as significantly better detection by our proposed solution compared to existing methods. we will develop rootkits designed specifically to evade detection (by our and other detection methods). etc. We propose to modify existing rootkits as well as to develop new rootkits from scratch. The reasoner updates the likelihood of rootkit presence. we will also deploy the solution in test environments. etc. editing registry entries. the analyst may choose to execute mitigation actions. unloading drivers. etc. we will need to perform empirical testing against currently unknown rootkits.5. truly unknown rootkits may be detected. Via the agent. the test results (evidence) are passed to the reasoner (local or remote). In these environments. At any point in the process. In particular. We propose to leverage our team's existing rootkit development capabilities to create novel rootkits for testing. Evaluation We claim that the proposed solution will be able to detect current and future rootkits without tailored modification. the analyst will be able to execute such actions as terminating processes. the information provided during the detection phase supports the analyst’s decisions and action during mitigation. To truly test the effectiveness of this solution. The recovery process follows mitigation and will also generally benefit from information gained during the detection and mitigation phases. and relevant information is made available to the analyst. and (b) an inability to evade detection by our proposed solution. isolating the suspect host. 4. To verify this claim.DRAFT execution. The analyst may also choose to execute non-agent mitigation actions. In addition to running tests. the analyst may choose to collect specific evidentiary information. Successful detection of a previously unknown rootkit "in the wild" will be the ultimate measure of success. This information may be stored locally or passed to the central server for storage and later analysis. Successful testing will demonstrate (a) an ability to evade detection by current methods. After execution. Empirical testing will evaluate detection capabilities of our proposed solution and other available solutions against existing and new rootkits. disk images.
DRAFT Not for use or distribution outside of DARPA Contract N66001-06-C-2052 49 .
as proposed in Section 4. Such an effort would provide a near-term but temporary solution to the rootkit detection problem. described below. With Not for use or distribution outside of DARPA Contract N66001-06-C-2052 50 . This tool would not implement a reasoning component. and (3) extensions/enhancements. Development Outline • • • • Four phases: 0-3 Phase 0 extends current tailored detection approaches Phases 1-3 implement the innovative approach outlined in this document Total cost: $4.6. 4. assuming execution of Phase 0. consisting of: (1) proof of concept. The total cost for Phases 1.6. similar to the manner in which antivirus scans are run. The tool would implement a collection of tailored detection mechanisms meant to detect the full spectrum of known rootkits.. The tool would be an integration of different tests in a single tool. and 3 would be approximately $4M. nor would it implement generic rootkit detection mechanisms (e. This effort would produce a host-based tool to detect rootkits. The tool would be implemented as a virtual machine byte code interpreter. and 3).65M over 36 months The solution described in this document could be developed in three phases.g. This provides the best platform from which to run the various tests at different levels. Development Phases Phase 0: Tailored Detection Tool Phase 0 implements the leading current trend in rootkit detection.1. the tool might send alerts to a local or remote event correlator or network management station. cross-view differences) to any great degree.1. over a period of 6 months for an approximate cost of $600k. With moderate resource allocation.DRAFT 4. (2) functional implementation. where phase 1 would last six months. We also suggest an optional phase 0 effort which would build a tool to combine multiple tailored detection methods. For example. 4. The tool might be run on demand or at specific intervals.1.4. and provides the basis for the ensuing agent development for the primary development (Phases 1.1. The user (or supporting analyst) would be required to interpret the results based on tool documentation and other knowledge. 2. 2. This approach consists of tailored detection methods based on our knowledge of currently implemented and proposed rootkit techniques. and phase 3 would last 12 months.6. this could be accomplished in a total of three years. This Phase 0 effort could be accomplished in parallel with the other efforts. phase 2 would last 18 months. The tool could easily be extended to interface with third party tools. and results would consist of results for each of the tests run.
4. 4. If the Phase 0 effort is executed. On balance. development of this Phase 0 tool has advantages and disadvantages. The working implementation will consist of an agent application. the benefit of such a tool is that it would improve rootkit detection in the near term while a better and longer term solution is developed. generic rootkit detection via probabilistic reasoning over induced observables and other evidence of indirect rootkit effects. this tool would require updates over time in order to remain effective as new rootkits and techniques are developed. for a moderate cost and in a relatively short time frame. While elements of this approach have been demonstrated. With proper resource allocation. we propose to formally demonstrate the effectiveness of the approach prior to commencing full development. Within the context of rootkit detection and mitigation. and 3. At present.e. as described in Section 4. On the positive side. The proof of concept will consist of prototype implementations of the solution components and empirical testing.6. This will provide a comprehensive set of test rootkits approximating the real world environment of known and unknown rootkits. Phase 1: Proof of Concept This proof of concept would validate our solution approach. the tool might be integrated with local components like antivirus applications. The agent application will be implemented as a virtual machine byte code interpreter. such an effort could be accomplished in parallel with. the execution of Phases 1.3. Phase 2: Functional Implementation A working implementation of the solution will be built in Phase 2. We will then conduct tests to verify that (a) current methods do not detect the previously unknown rootkits. i. We will also implement advanced rootkits (modifications to existing rootkits and novel implementations) to augment our existing rootkit library. and without any adverse effect on. this effort would produce a near term significant improvement to rootkit detection capabilities. this Phase 0 application does not solve the rootkit detection problem completely nor long term.DRAFT additional effort. and (b) our approach does detect the previously unknown rootkits. reasoner. 2. using some or all of the tests available to it.6. there would still be undetectable rootkits (especially ones we are not aware of).1.1. Also. The agent also has the ability to collect direct Not for use or distribution outside of DARPA Contract N66001-06-C-2052 51 . The agent's primary role will be to induce and collect evidence from one or more of the five levels.1.4. This working implementation will be developed in accordance with commercial software development and testing standards and will be suitable for operational deployment. and optional central server. then this Phase 1 agent development will leverage that earlier work. The components consist of the agent elements to induce and collect evidence and the reasoner.2. On the negative side. We will implement the components separately with minimal integration..
memory snapshots. MEBNs are implemented as various knowledge (network) fragments and corresponding logic to combine the fragments based on specific evidence received. the reasoner will consist of Bayesian Network models for rootkit detection.) and to take actions on the host (kill processes. which includes the initiation of tests and collection of results. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 52 . which is called by the agent (if local) or by the communication utility on the central server (if remote). write to memory. Porting the central server to an alternate platform will be possible. Analysts will also have the ability to craft their own tests.6. The agent development effort will include the agent configuration and communication utility. Communication with deployed agents supports configuration and operation of the agents. The reasoner will be implemented in both local and remote configurations. The optional central server implements communication with deployed agents and centralized reasoning. The models are accessible via an API. while the communication utility is only relevant if a remote central server is used. 4. testing. Phase 3: Extensions and Enhancements Phase 3 is designed to extend and enhance the functional implementation produced in Phase 2. Additionally. The models themselves will be implemented as MultiEntity Bayesian Networks (MEBNs).).DRAFT evidence from the host (files.4. we are only planning to develop the agent and associated tests for Windows platforms at this time. The configuration utility may be local or remote. In either case. While the concepts of this proposed solution will apply to non-Windows platforms as well. Possible extensions and enhancements include additional evidence tests. etc. The functional implementation will be developed for Windows platforms. Design decisions will be addressed early in the development process to establish the likely requirement for cross-platform portability for the central server. Ongoing research and experience with the developed solution may produce additional evidence tests which we will encode for the agent. This reasoner will ingest evidence from multiple agents and output likelihood of rootkit presence on any of the agent systems .g. We expect that user feedback. We may also identify additional functionality for the agent (e..). and additional agent functionality. etc. We propose this Phase 3 as a means to incorporate these ideas into the solution. additional evidence. we may identify modifications to the reasoner models to improve their performance (accuracy). etc. The central server will also house the centralized reasoner. additional forensic capabilities). reasoner model enhancements.1. and continuing research in the field will provide ideas for inclusion into the solution. then load and execute them on a remote agent. The models will return the likelihood of rootkit presence and supporting information from the reasoner (supporting evidence.
Figure 9: Phase 0 Schedule Figure 10: Phase 1 Schedule Figure 11: Phase 2 Schedule Not for use or distribution outside of DARPA Contract N66001-06-C-2052 53 . 4. The extensions and enhancements are opportunities to improve the implementation. Note that Phase 0 and Phase 1 begin at the same time and run concurrently.DRAFT The extensions and enhancements of Phase 3 should not be confused with regular signature updates as required by antivirus tools. 1.2. The key benefit of our proposed solution is that it is a generic rootkit detection capability and does not require regular updates. 2. but are not required for detection over time. and 3. Task Schedules The tables that follow provide high level schedules for Phases 0.6.
Costs also presume the use of pre-existing code and designs currently owned by various team members. • • • • Conclusions and Recommendations Best current approach is tailored detection Best current approach only detects known rootkits and techniques No current detection of unknown or new rootkits and techniques Solution: o Collect evidence related to induced and passive indirect effects o Collect evidence from multiple perspectives o Probabilistic reasoning over evidence Not for use or distribution outside of DARPA Contract N66001-06-C-2052 54 .6. and FTEs 5. Table 7: Estimated Costs. Durations. Costs were estimated based on past experience performing similar work using a mix of labor categories.DRAFT Figure 12: Phase 3 Schedule 4. Costs do not include escalation.3. Anticipated Costs Table 7 provides estimated costs for each phase.
We identified cross view differences and related techniques as the most promising approach to generic detection of known and unknown rootkits. we proposed to adopt probabilistic reasoning techniques being applied in other disciplines to reason over the collected information and establish the likelihood of rootkit presence. ranging from a low-level hardware view to a remote system view. some currently known and some novel. Cross view differences is an example of an approach which relies on indirect (and often unintended) effects of a rootkit infection. although this method was not 100% effective. Stage 1 would produce a near term detection capability based upon the aggregation of multiple tailored detection techniques. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 55 .DRAFT The goal of this project was to establish the current state of the art in rootkits and rootkit detection. We experimentally demonstrated that the most effective rootkit detection technique is tailored detection. Tailored and other detection methods require detailed knowledge of the rootkits to be detected. to forecast the future of the same. to include future rootkit techniques. and to include induced observables caused by deliberately establishing abnormal usage conditions. We forecast that detection of future rootkits will become increasingly difficult given expected rootkit developments and current detection approaches. We refined the cross view differences idea to incorporate five different data views. and to identify promising solutions to the problem of rootkit detection. Stage 2 would take 2-3 years to complete. The current state of the art in rootkits is direct manipulation of running processes and kernel data structures. We extended this idea to include other indirect effects (besides those visible through cross view differences). Finally. so no new (unknown) rootkits will be detectable by any existing methods (until the rootkit in question is known and studied). and would produce a more generic rootkit detection capability based on probabilistic reasoning over passive and induced indirect effects collected from multiple perspectives. We proposed a plan to build a rootkit detection capability in two stages.
or a driver that has been hidden. Kernel-protected software will often attempt to hide the presence of their driver or module using an imaginative variety of techniques. Drivers loaded this way are still present in the PsLoadedModuleList. Avoiding Inclusion into the Service Control Manager Some rootkits hide by loading the driver using SystemLoadAndCallImage with NtSetSystemInformation so that the driver is not added into the SCM (Service Control Manager). if there is a size mismatch then this type of infection can be detected.DRAFT Appendix A: Tailored Detection Methods Kernel Mode Data Analysis Detecting kernel structures will facilitate the process finding malware hidden in the kernel space. and can be detected by iterating this list. They can also be detected by scanning the thread list and looking for kernel threads whose starting address does not fall within any known driver. the system was never aware that it was loaded. The following four subsections describe some of these techniques. If the module was mapped into memory manually however. Avoiding the List of Loaded Modules Rootkits can be hidden by unlinking a module or DLL from the list of loaded modules in a user-mode process. or mapping it into memory manually so that it is never put on the list to begin with. a mirror-image kernel-mode list should still be present that reflects the presence of this module. Kernel Driver Module Detection The enumeration of loaded drivers and modules on a system is a key starting point to kernel level systemic analysis. it can be detected using methods described in the previous paragraph. If a module has merely been unlinked from the user-mode process. Unlinking the Driver Unlinking the driver from the PsLoadedModuleList in the kernel can be detected in several ways. Using off-axis scanning. the entry in the PsLoadedModuleList can be located in memory even though it is not in the list. otherwise referred to as rootkits. or scanning through the contents of memory looking for unlisted PE header signatures. If the driver has been removed from this list. Or the driver itself can be located by scanning for PE/MZ signatures that are not connected to an existing entry in the list. Those two cases can be separated by analyzing the memory footprint at the start address. The following eleven subsections discuss various ways that rootkits can be detected by understanding how they hide themselves and their behaviors. the module can be detected by comparing each of the listed modules with their image on disk. This can be detected by scanning the memory map for large blocks of space that are not connected with a listed module. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 56 . If the module has destroyed its own PE header and altered its memory footprint to combine itself with another module in the process. This is indicative of either a driver that has been unloaded.
Any deviation from this standard is the result of a hook being placed on it. Ntdll contains the “native API” which consists of super-thin. The debug registers can also be used to hook these functions. NDIS Scanning The NDIS stack is a frequent target of malware because it provides very low level network access. the address of that interrupt’s handler. If it isn’t. wrappers around the system call interrupt. The lower-most layer is very device-specific. ntdll. SSDT Table Pointer Analysis The SSDT (aka KiSystemService table) is essentially the glue that connects user-mode APIs to kernel-mode APIs. Most APIs have a standard function prolog/epilog. When a user-mode API call is made an interrupt is generated. The IDT can easily be modified by software. so we will monitor them as well. There is a way to map each user-mode API to the API in kernel-mode that it is supposed to correspond to though. and a driver with any other suspicious characteristics(such as those described in the other sections here) that is also hooked into this stack would be a good indicator of malicious activity. IDT Pointer Analysis and Integrity Check Intel processors use “interrupts” to process and signal events.dll. By manipulating the SSDT. we will parse the user-mode portion of this system. in the IDT. There should only be a limited set of drivers that appear in the NDIS stack. or other code entirely. in almost all cases. user-mode APIs can be re-mapped to either other kernel-mode APIs. then we know something is hooking it. and most importantly standard-format. The other problem with detecting SSDT hooks is that syscall numbers change constantly between versions of Windows.DRAFT Hooking APIs Hooking APIs that are used to enumerate modules or drivers and sanitizing their results are used to hide themselves. To do this. This allows malware to both see all of the traffic going through the given computer (which often times includes all of the traffic on the entire network) and generate its own traffic. By parsing each of these wrappers we can map APIs to syscall numbers and make sure that the SSDT is performing the translation correctly. To verify the integrity of the stack. When an interrupt fires the processor looks up. but before that call is made a “syscall number” is placed in a register to be used by the interrupt handler to lookup which API in the kernel is being requested. This is a form of hooking that is more difficult to detect than a normal function hook. NDIS was designed as a layered system so that applications could interface with network devices in a generic way. as Not for use or distribution outside of DARPA Contract N66001-06-C-2052 57 . and this makes it practically impossible to perform a simple checksum on the table as a whole. malicious code will insert itself so that it can monitor the traffic that passes between the layers and/or inject its own. An interrupt is one of the most basic components of any operating system and control over interrupts is the effective equivalent of total system control. and the higher layers get less and less so as you move up. we will traverse each of the layers and look for unauthorized or suspicious code. Somewhere in this ‘stack’. because this type of hook does not modify the function itself.
or both. and the size it claims to have on disk. and the kernel is secure then all of the IDT entries must be legitimate. or drivers for thousands of different pieces of hardware from equally many different vendors. However. inject their own. To verify the integrity of IDT entries we are not left with many options. System Call Function Integrity Checks So far we have focused on verifying the integrity of various tables and pointers that are important to the Operating System and have only passingly referenced the actual problem of automated code verification. or worse yet. we know the code section of the driver has been expanded to allow code injection. It isn’t difficult for us to determine what is in the IRP chain. Again. The simplest method of detecting patches to system functions is to compare the image on disk with the image in memory. Determining what is legitimate. IRP Chain Verification IRPs (I/O Request Packets) are what drivers use to communicate with each other and with user-mode processes. In this case. it is almost certainly illegitimate. it is possible that there would be large enough empty “code cave” spaces within a legitimate driver that a function or stub could be injected without modifying the size of the code section. IRP chains handle all manner of sensitive information such as keystrokes. even when done manually. but there is also no profile for a ‘legitimate’ driver in most of the main IRP stacks that we can use to heuristically verify their integrity. and it has no layer below it that can be used for purposes of cross-referencing. if they do point outside of it then we know they’re being hooked. What we do know about IDT entries is that they should never point outside of the Windows kernel. If an entry in the chain is not hidden. or what is authentic and what is not is very difficult. or a piece of raw code injected into the kernel. someone has tampered with something. because if all of the IDT entries point into the kernel. If there is a mismatch. inside of the kernel to make this simple sort of detection impossible. if there is a mismatch here. Rootkits and protection mechanisms will often insert themselves into these chains so that they can either monitor this traffic. But what if someone patches the image on disk the same way they have patched the image in memory. To resolve this we need to verify the integrity of the kernel. network data. and call code that is just floating out in memory by itself. then it will be visible in our enumeration of the loaded driver list. injection has taken place. But anyone who realizes this can insert their code. In either case. It is a non-trivial problem when dealing with software that changes versions frequently. or who is able to see which I/O packets. To detect this sort of code we will look for discrepancies between the drivers stated size in the memory-resident driver list. If they don’t match. The only remaining option then is for a piece of code to be injected into the address space of another driver. This is particularly dangerous because the IDT is so powerful. The IDT is not part of the Operating System. and files. even though it is not. we can compare the code image on disk with the code image in memory.DRAFT it resides in regular memory that can be modified from kernel-mode just like any other. or a redirection to their code. Some things that we can look for are IRP chain entries that are not associated with a particular driver. This is indicative of either a hidden driver. patched the image on disk permanently? Not for use or distribution outside of DARPA Contract N66001-06-C-2052 58 . so that it appears legitimate.
There are some instances in which this behavior is normal. however they are limited and can be white-listed in our analysis scriptlet. So whenever the target is called. so that whenever it tries to call that function. A hook usually consists of a patch over the first few bytes of the target function with a jump into your hook function. and not to external areas of code. it calls something else. Not for use or distribution outside of DARPA Contract N66001-06-C-2052 59 .DRAFT To deal with this problem is impossible in the general case. The simplest method of re-directing code flow is to place a “hook” in a function. your function gets control first. A more generic approach to this would be to use branch-tracing to scan for sudden cross-overs from a function in the kernel to a function in a totally different area of memory. We can detect this by ensuring that all static system function pointers point inside of the kernel. These can be easily detected by scanning the first 5 bytes of every system function for jump opcodes (which will generally never appear within the first 5 bytes of any function unless it has been hooked). but it can be dealt with in most cases because code injectors/modifiers tend to follow well known and similar patterns. Another situation is a static function pointer has been modified somewhere in the images memory.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.