Rootkits

What is a rootkit? A rootkit is a special variant of a Trojan, a.k.a. a RAT (Remote Administration Tool). What separates a rootkit from a regular Trojan is that a rootkit, by definition, occupies Ring , also kno!n as root or kernel level, the highest run privilege available, !hich is !here the "# ("perating #ystem) itself runs. $on%rootkit trojans typically run in Ring &, or user level, !hich is !here ordinary applications run, though some sources refer to userland trojans as 'rootkits( also. )sually, but not al!ays, a rootkit !ill actively obfuscate and attempt to hide its presence from the user and any security soft!are present.knjk Rootkits subvert the "# through the kernel (core operating system) or privileged drivers. This enables a rootkit to operate as a part of the "# itself rather than a program being run by the "#. This high level of sophistication makes rootkits e*tremely difficult to detect and remove. "ften anti%virus products !ill be unable to detect or remove a rootkit once it has taken over the "# and more speciali+ed detection and removal procedures are re,uired. What kinds of rootkits are there? Rootkits may use a variety of techni,ues to gain control of the operating system and hide from both the user and security soft!are. -ifferent techni,ues may be used in combination to increase overall effectiveness. There are many variations and not every techni,ue !ill be discussed. "nly those most relevant and common !ill be discussed here. 1 #ome common techni,ues include. MBR infection The /0R or /aster 0oot Record is the portion of the hard drive that tells the 01"# (0asic 1nput "utput #ystem) !here to find the "# ("perating #ystem). This is a critical handoff of responsibility bet!een the 01"# !hich does the initial boot se,uence !hen the computer is started and the "# !hich takes over. 0y subverting this process the rootkit (sometimes called bootkit) is able to inject itself bet!een the computer2s hard!are and "#, subtly altering data sent back and forth to mask its presence and take over the system. 3very time the "# tries to read files from the hard drive the rootkit intercepts the attempt and substitutes either fake data to hide itself or modified data to trick the "# into loading and e*ecuting infected files. 0y selectively intercepting attempts to read and e*ecute kernel drivers the rootkit loads itself into memory and takes over the "#. 1f the user attempts to vie! the rootkit files, the rootkit can give a false report of there being no trace of its files. #ince the rootkit often never actually modifies the "# files on the hard drive itself, but only gives modified data !hen the file is being loaded into memory, it becomes even harder to detect. 1t can also detect and intercept any attempt to delete the rootkit itself or any portion thereof. 3ven if the rootkit is deleted, since it is loaded in the /0R, the system can be reinfected !hen it is rebooted.
4. "# subversion techni,ues used by ordinary trojans, such as 1AT and 3AT hooks, malicious App51nit -66s, etc are out of scope for this document. "nly kernel level attacks are presented, so additional information regarding these and other user mode attacks are left to the reader.

$e!er versions of Windo!s incorporate protections to prevent the /0R from being !ritten to. 7o!ever, rootkits have evolved to overcome this by !riting directly to the disk using #R0 (#8#1 Re,uest 0locks). $ot all computers use the /0R method of booting the "#. $e!er 98s may use 3:1 (3*tensible :irm!are 1nterface) or )3:1 ()nified 3*tensible :irm!are 1nterface) !hich !ill be discussed later in the document. Hypervisor A hypervisor is a virtual machine manager, !hich !hen used for legitimate purposes allo!s a single physical computer to host and run more than one "# simultaneously by creating multiple virtual machines, each of !hich appear to the "# to be a physical computer. 1t simulates hard!are and intercepts attempts by the "# to access the hard!are, then translates the re,uest, and passes it to the actual hard!are. 7ypervisors have many legitimate uses in computing, ho!ever a rootkit can create a malicious hypervisor to hide its e*istence from the "# and the user. There are several types of hypervisor rootkits. #ome modify the bootloader to create the malicious hypervisor during the bootup process in a !ay very similar to an /0R rootkit. "thers can subvert the "# and migrate it into a virtual machine !hile it is still running, !ithout any indication to the user and !ithout re,uiring a reboot. This is possible due to hard!are support for virtuali+ation built into most modern 89)s. 1ntel2s virtuali+ation architecture is called ;T%* and A/-<s is called 9acifica. A hypervisor rootkit !ould subvert a running "# by first checking to see !hether the hard!are supports virtuali+ation using a function such as vmx_init. 1t !ould then reallocate system memory and split system resources using a function such as vmx_fork !hich !ill put the rootkit into a privileged #upervisor mode beyond Ring . 1t !ill then put the running "# and all active processes into a non%privileged non%root mode !here they cannot see or interact !ith the actual hard!are or the processes of the rootkit. The hypervisor rootkit emulates virtual hard!are for the "#, !hich the "# cannot detect to be any different from the actual hard!are. 1n such a situation the rootkit becomes almost impossible to detect from !ithin the compromised "#, because it controls !hat the "# =sees=. The only certain !ay is to do a forensic e*am of the hard drive to look for backdoors or modifications to the bootloader !hich !ould allo! the rootkit to reload after a reboot.2 The rootkit can also suspend its operation and even temporarily e*it out of virtuali+ation mode if it detects the "# is attempting an operation !hich may uncover its e*istence, such as by checking to see if virtuali+ation e*tensions are active or attempting to detect timing irregularities in certain system calls such as 89)1-. 0ecause a hypervisor introduces a certain amount of latency in addition to !hat !ould normally be e*pected !ithout a hypervisor it may be possible to detect some less sophisticated hypervisor rootkits. This is not reliable ho!ever for advanced rootkits !hich can suspend or e*it the virtual mode temporarily.

>. 7ypervisor rootkits !hich are injected into memory and do not modify the file structure on the hard drive !ill not be able to be detected by an e*amination of the hard disk, but !ill also not survive reboot.

Alternate Data Streams Alternate -ata #treams or A-# are a little kno!n function of $T:#, a popular file system used by /icrosoft Windo!s products. A-# allo!s the "# to store metadata about a file !ithout changing the file itself. A-# are not vie!able by Windo!s 3*plorer or other common file vie!ers. They make a very good hiding place for rootkits because there is no limit to the number or si+e of files that can be stored invisibly in A-#. An e*ecutable may be stored in A-# and e*ecuted !ithout ever sho!ing up on a file or directory listing. /ore and more A; (anti%virus) products are no! scanning A-#, so this is no longer !idely used for modern trojans, but is still common in rootkits a fe! years old. 7o!ever, if you e*amine an infected hard drive on a non%infected computer, you may be unable to detect the rootkit files using standard file e*plorers and !ill need speciali+ed tools !hich can scan A-#. 1t is possible to manually create and read A-# streams, but only if you kno! the e*act stream identifier e*pressed in the form drive letter:\path\filename:stream. :or e*ample c:\temp\tmpfile.tmp:hidden.exe Slack space 3very file on a hard drive is allocated a certain amount of space. 0ecause space is allocated in fi*ed si+e =chunks= or disk clusters, most often the file that has been allocated the space doesn2t use all of its allocated space and there is a little bit left over. This is kno!n as slack space. Rootkits have long been kno!n to hide in such areas of the disk, spread out over the slack space allocated to several normal files. "rdinary attempts to read the portions of the disk !here rootkit resides !ill simply sho! the file to !hich those disk clusters have been allocated. 1t takes speciali+ed tools to read these sections of the disk, and even then it is difficult to tell a rootkit in slack space from the random junk data that !ould normally be there any!ay. A rootkit taking advantage of this method !ill most likely store itself in the slack space of protected system files that !ill not change much or ever, because of the risk of having itself over!ritten !hen the file to !hich the space is allocated gro!s in si+e. /ost A; tools and even AR (anti%rootkit) tools are not able to scan slack space, !hich makes this an e*cellent hiding place for mal!are !hich !ill enable it to remain undetected even !hen the hard drive is e*amined on a non% compromised system. Bad Sectors "ver time a hard drive may develop sectors (storage units) !hich can no longer be reliably read from or !ritten to, these are called bad sectors or bad blocks. The "# keeps a record of these bad sectors in the /:T in Windo!s and the bad blocks inode in 6inu* so it !ill not try to !rite to them in the future. #ectors marked as bad are generally not readable because in most modern drives they are transparently mapped to a pool of spare sectors either by the drive controller hard!are or in some cases the "#.

0ecause of this bad sectors make a favored hiding place for rootkits, preferred over slack space because there is no danger of data in bad sectors being over!ritten. The rootkit simply marks the locations on disk !here its files are stored as bad, making those sectors inaccessible !ithout direct disk access. /ost soft!are uses A91s (Application 9rogramming 1nterface) to access hard!are, !hich re,uires the hard!are access re,uest to go through the "#. This data hiding techni,ue makes the rootkit invisible to both regular A; and even speciali+ed AR tools !hich use standard A91s for scans. :orensic soft!are capable of direct disk access and reading ra! sector data !ould be re,uired to locate data stored in bad sectors, and often rootkits using this method of hiding !ill intercept direct disk access re,uests re,uiring the disk to be e*amined on a non%compromised system. Hidden Partition A partition is a logical division of the physical hard drive used for data access. #ome rootkits create a hidden partition !ithin an e*isting disk partition. 1n order to do this the rootkit has to create a disk object and a disk driver to access the ne! hidden disk. 1n a Windo!s system this !ould either involve copying the e*isting disk.sys driver object and modifying the dispatch function and device object to point to the hidden partition or creating a !hole ne! device object and driver set from scratch. )sually the 1R9 table !ill also be hooked to monitor and control access to the hidden disk object and prevent the "# from accidentally over!riting the hidden data since it overlaps the ordinary disk partition the "# already kno!s about. The rootkit may also create a fake file and allocate the portion of the disk used by the hidden partition to the fake file to prevent the "# from trying to allocate that space for another purpose. 8ommonly the hidden partition !ill be allocated a section of the hard drive at the very end as this is the least likely to already have data. Any e*isting data !ill be moved and the rootkit !ill intercept access attempts and transparently redirect them to !herever it has moved the data. /odern rootkits !ill also encrypt the hidden partition making it impossible to read !ithout the correct encryption key and encryption algorithm. Interrupt Hooks The "# uses a set of basic commands to interface !ith the computer hard!are as mediated by the 01"#. These commands are kno!n as interrupt calls and given numbers in he*adecimal. A rootkit !hich is able to intercept and modify these calls is said to have hooked that call. -epending on ho! the interrupt is hooked it may be kno!n as an 1$T hook or 1-T hook. #ince interrupt calls are the most basic, a rootkit !hich is able to hook them has control over the hard!are at a very lo! level. This techni,ue is most commonly seen in /0R rootkits because 1$T calls are used in the boot process. #pecifically INT !h, !hich enables direct access to the hard drive, is commonly hooked by /0R rootkits. This enables a rootkit to modify the disk directly, subverting any access control on the part of the "#. 1t also enables the rootkit to intercept any attempt by the "# to read or modify data on the disk and prevent or alter attempted data reads or modifications.

Message Hooks 9rograms running in memory use messages to communicate changes and user input to other programs and the "#. A message hook is used to either monitor or intercept messages before they reach the intended system process. :or Windo!s "# they are created by calling the "etWindo#s$ook function !ith appropriate parameters. Rootkits !ill often set message hooks because all user input, keystrokes and mouse movements, creates messages. A rootkit !hich has hooked these messages !ill be able to read and record all user activity on the 98. #ince there are many different messaging subroutines, it allo!s very fine grained control over !hich functions !ill be monitored. #ome common message hooks used by rootkits are W$_%&'()*+,, W$_%&'()*+,_--, W$_."/0I-T&+, and W$_.)1"&. SSD Hooks

The #ystem #ervice -escriptor Table or ##-T is used by Windo!s "# to locate system services !hich are crucial to the functioning of the "#. 1n 6inu* "# this function is held by the #ystem 8all Table. A rootkit !hich hooks this table can alter it so that important system calls are routed to the rootkit. Any program !hich attempts to use the ##-T !ill instead be funneled to the rootkit, and since the ##-T is fundamental to the "#, every program must use it. ##-T hooks are very po!erful and commonly used by rootkits for stealth. :or e*ample, if the Nt23ery,irectory0ile function is hooked, the rootkit can return false information to re,uesting programs, such as A;, about files and directories on the hard drive, making itself invisible. 1n the same !ay, a rootkit may hide its running processes, net!ork activity, or Registry entries, such as !ith Nt&n3merate%ey and Nt&n3merate4al3e%ey or for 6inu* sys_5etdents and sys_#rite. 0ecause of the fre,uent use of ##-T hooks, many anti%rootkit programs scan the ##-T for modifications, ho!ever rootkits are able to hide changes to the ##-T in a variety of !ays, such as by modifying the %T$+&*, structure or modifying the ##-T =on the fly= !ithout leaving permanent traceable changes. $e!er /icrosoft "# and ?@bit "# have made hooking the ##-T much more difficult, ho!ever this is still very common on Windo!s A9 rootkits. IRP Hooks Any time a program needs to send or receive data from the computer hard!are an 1B" Re,uest 9acket (1R9) is used as an intermediary bet!een hard!are and soft!are. This includes reading and !riting data from the hard drive, RA/, video, audio, and net!ork. 7ooking 1R9 generally involves modifying or replacing hard!are drivers. Rootkits use this method as another !ay of gaining privileged access to hard!are, !hile intercepting other access attempts. A rootkit !hich has modified disk driver disk.sys or the lo! level disk driver atapi.sys can control !hat other programs see on the hard drive, !hile tcpip.sys allo!s a rootkit to hide net!ork traffic. 1nitially fe! rootkits used these techni,ues, but as other techni,ues came under more scrutiny, more and more rootkits began using 1R9 hooks and coming up !ith novel !ays to hook the 1R9 subsystem !ithout leaving obvious hooks in place.

:or e*ample by modifying the lo!est level device driver for the hard drive \,evice\$arddisk6\,+6 to no longer point to the default 1R9 handling subsystem via I+7_.8_INT&+N*-_,&4I9&_9)NT+)- routine but a parallel system controlled by the mal!are, or adding a malicious device into a target device2s 1R9 chain via Io*ttach,evice. These are both sneaky !ays to redirect 1R9s !ithout having to modify the 1R9 dispatch table itself. #ince there are many different drivers for hard!are, this makes detecting hooks that much harder for anti%rootkit soft!are, especially since, unlike ##-T, pointers in the 1R9 table are not all e*pected to point back to the kernel, since there are many &rd party drivers in use. "ther commonly hooked procedures include. I+7_.8_+&*,, I+7_.8_W+IT&, I+7_.8_"9"I, and ,river"tartIo. #ince some AR products began using passthrough 1"8T6s to directly access the disk and bypass the rootkit hooks, ne!er rootkits are additionally hooking I+7_.8_,&4I9&_9)NT+)- subcontrols such as I)9T-_*T*_7*""_T$+)1/$ and I)9T-_*T*_7*""_T$+)1/$_,I+&9T or "9"I)7_+&*, and "9"I)7_W+IT&. D!"M A kernel object is a virtual placeholder for a resource that contains information about it. 3verything on a computer !ill have an associated kernel object, every file, every process, every port, etc. When a kernel object is created, it is given an inde* number called a handle, through !hich it is accessed. When a program !ants to make a change (e.g. create or destroy a process), it makes a re,uest to change the kernel object, and the kernel itself ("bject 7andler) decides !hether to grant or deny the re,uest. $ormally the kernel itself is the only one able to directly change kernel objects, ho!ever, in the last fe! years, rootkits have appeared !hich are able to access kernel objects directly in !hat is called -irect Cernel "bject /anipulation (-C"/). 1t is another tool in the toolbo* of the mal!are !riter to be able to hide thier o!n processes and drivers !hile interfering !ith other processes and files. 0ut it is much more stealthy than other methods such as replacing device drivers and hooking tables for > reasons. 4. 0ecause changes occur in memory only, there is no record of them, and >. 0ecause no other program, not even A;, can access the kernel objects, !hat happens in this reserved memory region is some!hat =behind the curtain=. 1n 6inu* -C"/ can be accomplished by !riting to :dev:mem or :dev:kmem. A -C"/ rootkit in Windo!s A9 !ill use the undocumented A91 Nt"ystem,e;359ontrol a hidden A91 used to directly access kernel memory. 7o!ever, it must open a handle to the memory at \\,evice\7hysical.emory, !hich is one method of detecting it. 0y modifying the &7+)9&"" structure, a -C"/ rootkit can hide running processes. "ther often modified kernel objects are &T$+&*,, T)%&N, and ,+I4&+. These attacks allo! the rootkit to hide processes and device drivers and change process access tokens. A rootkit that modifies the kernel object of the page fault handler can hide the contents of RA/ from any other program. This means such a rootkit can hide its o!n e*istence even from a scan of objects in memory or running processes.

7o!ever, rules for manipulating kernel objects !ill change from one version of the "# to another, making manipulation of those objects challenging, also because of the delicacy of the operations involved any mistake !ill result in a system crash, !hich can be a givea!ay. -espite the difficulties in -C"/, it is e*pected more and more rootkits !ill be using them in the future, since advances in "# security are rendering hooks more difficult and because all "# must use kernel objects. The latest versions of some rootkits are using -C"/ to great effect by blending it !ith 1R9 hooking, using -C"/ to create phony devices and setting 1R9 hooks on the phony device !hile using -C"/ to link the phony and real device by modifying the )(8&9T_$&*,&+ structure. 1n this !ay, the actual device is not sho!n as being hooked, so it can evade anti%rootkit techni,ues. There is a great deal of innovation occurring !ith -C"/ rootkits and more creative methods of using them to manipulate and hide data is to be e*pected.

Rootkit

rends # 2$11

Rootkits are increasingly developed by professional mal!are developers !orking in teams and accordingly are becoming highly sophisticated and comple*, comparable in many !ays to the A; and AR products devoted to catching them. /odern rootkits are highly obfuscated to confuse forensics and frustrate reverse engineering, incorporate encrypted files, encrypted communications, and a modular design that allo!s different types of mal!are from different designers to !ork together by e*porting malicious A91s and syscalls. This modular design allo!s mal!are developers to speciali+e in one particular area. initial infection, hiding mal!are files and activity, payload functionality, ie botnet, search engine results modification, sending spam emails, capturing sensitive user data, etc, and speciali+ed plugin functions, ie keylogging, 7TT9#, etc. These trends are making rootkits more fle*ible and po!erful as !ell as harder to detect and remove.

Rootkit detection
#ince rootkits go to great pains to hide, they can be ,uite difficult to detect. Additionally, since kernel rootkits run in Ring , they can subvert any other soft!are running, including tools trying to find them. :or this reason, it is a good idea to take the hard drive out of the suspected infected machine and attach it to a kno!n clean machine for e*amination. "ne of the first indicators of a rootkit infection is system instability. #ince rootkits often replace core system drivers, any malfunction !ill crash the system. #ince rootkit drivers are not subject to the same ,uality standards of an "# vendor bugs and system crashes are common, though this is becoming less true over time as professional level rootkits become more common. Additionally, often rootkits are designed to !ork !ith a very specific patch level for an "#. #o if the "# is patched and some dll is replaced that the rootkit has modified, it can cause serious system problems, such as lockups and crashes. 0ut then there are a fe! rootkits that don2t even try to be stealthy and pop up advertisements for pornography as !ell. All of these can be potential indicators that a deeper e*amination is needed. 9rior to making any changes to a potentially rootkit compromised system, it is a good idea to learn as much through passive observation as possible. /any rootkits monitor system activity very closely and are programmed to look for anti%rootkit programs running in memory and attempts to read or change sensitive areas of the "# and hard drive !hich may represent attempts to detect or remove the rootkit. Rootkits !ith an observer process !ill usually have some self defense code !hich !ill activate if it detects any attempt to remove the rootkit. This can be anything from terminating the process, to unhooking hooked tables and drivers, to moving its code around in memory or on disk in an attempt to th!art investigation. :or this reason, it is a good idea to make a clone of the hard disk of the potentially infected machine to e*amine !ithout running the risk of alerting the rootkit on the running machine that it is being investigated. With a clone you can safely kill processes, modify files, and generally poke into the suspected rootkit and observe if there is unusual behavior in response to this. !ernel Mode Signing "ne of the major security fla!s of past Windo!s "# is that device drivers !ere loaded in Ring . This is a major problem because device drivers often come from &rd parties and are unverified, meaning they could be buggy or include malicious code. This !as a common !ay for rootkits to load themselves into kernel memory in the past. ?@ bit versions of ne!er Windo!s, ;ista and later, incorporate a security measure called kernel mode signing. This re,uires all kernel mode drivers to be cryptographically signed, certifying their origin and trusted status.

/odern rootkits have found !ays to overcome this security control. Rootkits !hich subvert the /0R may use functions normally used for debugging purposes, (cd-i;rary(oolean_,isa;leInte5rity9heck and (cd-i;rary(oolean_*llo#7rerelease"i5nat3res. #ince an /0R rootkit controls the boot process it is able to set either of these options at boot time to disable code signing re,uirements and load malicious, unsigned kernel drivers. !ernel Mode Patc% Protection Another security feature found in ?@ bit versions of Windo!s, A9 and ne!er, is kernel mode patch protection (C99) also kno!n as 9atchDuard. 1t prevents modifications to the ##-T, 1-T, D-T, and /#Rs, creation of kernel stacks, and inline patching of the kernel or kernel libraries. 7o!ever, 9atchDuard has several !ell kno!n bypass techni,ues, including hooking andBor modifying the 9atchDuard code itself or supporting system functions like the e*ception handler. 0ecause the code 9atchDuard is attempting to regulate runs in Ring , it has full access to the kernel and there is an ongoing cycle of attacks to disable or evade 9atchDuard<s protections and updates to 9atchDuard to counter those attacks. &nified '(tensi)le *irm+are Interface The security design fla! e*ploited by /0R rootkits is that if they can get direct access to the hard!are at boot time all future soft!are checks become meaningless. )3:1 includes a security control to eliminate this threat in the hard!are itself called secure boot. #ecure boot re,uires cryptographic signatures on all code loaded at boot time. The signatures create a chain of trust from the soft!are developer up to the certifying authority !hich certifies the soft!are as trusted. Any unauthori+ed modifications to a signed bootloader !ill cause the integrity check to fail and prevent the system from booting. While this is not fool proof it does provide a high degree of protection against rootkits and other mal!are !hich may attempt to modify the bootloader or key boot components, i.e. NT-,+< ;ootm5r< #inload.exe< #inres3me.exe< or kdcom.dll. )3:1 is becoming more commonplace and is !idely supported by hard!are manufacturers and most modern "#. As of this !riting, there have been no verified instances of mal!are able to bypass )3:1 protections.& Hard+are Assisted Security A major stumbling block to anti%rootkit efforts is the fact that all soft!are running in privileged e*ecution mode (ring ) on the 89) and !ith direct access to hard!are is effectively on e,ual terms !ith the "#, meaning a rootkit can alter or disable the AR soft!are hunting for it. #everal attempts have been made to incorporate AR technology directly into the hard!are to give more of an advantage. "ne of these !as a 981 card called copilot !hich contained rootkit hunting code burned into the firm!are, able to monitor the host<s memory and filesystem at the hard!are level. This technology never caught on in the private sector but !as popular in the government sector.

&. #ecure boot depends on the chain of trust established by certificate authorities, !hich has been successfully broken in rare instances. 9C1 and chain of trust attacks are outside the scope of this paper.

Another hard!are assisted security technology is called -eep#A:3. This relies on virtuali+ation, creating a hypervisor that runs at a higher level of privilege than the "# and kernel level code !ithin the "#, including rootkits. This means that the scans running from !ithin the hypervisor based security code cannot be easily bypassed because it is not vulnerable to hooking from the "# layer. 1t can also free+e the running system and e*amine the contents of RA/ directly !ithout having to rely on the "#, !hich may have been subverted. ,ompare Integrity Assurance Snaps%ot 1f you have a snapshot of the hard drive from a kno!n clean state using one of the many intergrity assurance soft!are products, such as Trip!ire, #amhain, "##38, A:18C, or A1-3, you can use it to track changes to the hard drive. This !ill sho! you files and registry settings added, removed and altered, !hich is a good first step to trying to track do!n changes made by a rootkit. 0e a!are that the registry changes fre,uently as a matter of course and temp files are regularly created and deleted in the appropriate folders. Rootkit authors are a!are of this and may try to mimic these normal patterns by hiding a rootkit in Btmp or a .tmp file for e*ample. 6ook for changes in any critical "# directories and cross reference !ith the logs to determine if those !ere authori+ed changes. Registry entries !hich could be used to load a rootkit into memory should also be given special attention, some e*amples !ould be. $%-.\"'"T&.\93rrent9ontrol"et\"ervices< $%-.\"oft#are\.icrosoft\Windo#s\93rrent4ersion\= $%91\"oft#are\.icrosoft\Windo#s\93rrent4ersion\= $%-.\"oft#are\.icrosoft\Internet &xplorer\= $%91\"oft#are\.icrosoft\Internet &xplorer\= $%9+\exefile\shell\open\command $%-.\"oft#are\9lasses\exefile\shell\open\command $%-.\"oft#are\.icrosoft\*ctive"et3p\Installed9omponents Anti#Rootkit Products There are a number of speciali+ed anti%rootkit (AR) soft!are products available, some free and some commercial products. #ome Windo!s AR include. Rootkit Revealer, 0lacklight, Rootkit )nhooker, D/3R, 1ces!ord, RA1-3, and 7elios. #ome 6inu* AR include. chkrootkit, Rkdetector, rkhunter, Eeppoo, kstat, elfstat, and Cs1-. While none of them are capable of detecting every rootkit, they can provide some very useful information about the state of the "#. /any older rootkits use direct ##-T and 1AT hooks. 1n other !ords they modify the tables to point directly to the rootkit code. These types of changes are trivially easy for a scanner to detect. The AR scanner simply scans the 1AT and ##-T tables for pointers !hich don2t point to the kernel itself. 1t then presents a list of these hooks to the user for e*amination.

7o!ever, just because a hook is present, doesn2t mean there is a rootkit. There are other legitimate soft!are applications !hich may also install hooks. #ystem security soft!are such as A; and fire!all !ill often hook ##-T tables. 9oorly programmed soft!are !hich should use hooks limited to its o!n process, may instead install global keyboard or mouse hooks !hich an AR scanner !ill flag as suspicious. A; and fire!alls !ill often hook the net!ork stack or device drivers (ie chained or filtered device drivers) to protect the system. A-# is used by jpeg image files and saved !ebpages. #oft!are debuggers !ill often hook e*ception handling A91s. 1n 6inu* systems, #356inu* !ill often hook the sys call table. 1n theory, there should be fe! enough hooks in an "# to carefully e*amine each one to determine !hether it is malicious or part of a kno!n process. 7o!ever, in order to counter rootkits !hich become ever deeply buried in the "#, modern A; and AR products often embed themselves just as deeply into the "#, in some cases using live kernel patching techni,ues. 1n effect becoming benign rootkits themselves. The documentation of system modifications for many of these products is !oefully incomplete or non%e*istent and because of this in some cases it may not be possible to determine !hether a given hook or kernel patch is a sign of a rootkit or an undocumented A; or fire!all function !ithout removing the soft!are. #everal e*amples of both benign and malicious hooks and kernel patches !ill be sho!n to provide reference for your o!n investigations. This screenshot sho!s 1ces!ord reporting a global keyboard hook.

$e!er rootkits do not directly hook tables, but instead modify the code of the legitimate A91 handler or dll to insert a 8.7 instruction !ithin the file header that points to the rootkit. This leaves the table intact and unmodified, but any process !hich attempts to call that A91 !ill get redirected to the rootkit. 1n some cases the file on disk may be left intact as !ell and only running code modified.

This screenshot sho!s 1ces!ord reporting a number of kernel hooks. "f particular note is that malicious code has been injected into ntoskrnl.exe the "# kernel for Windo!s, !hich has hooked the ##-T A91s for Nt)pen7rocess, NtTerminateThread, Nt9reateThread, Nt9reate7rocess&x, NtTerminate7rocess, and Nt)penThread. This particular rootkit is able to monitor and control any attempt to start a ne! process or kill an e*isting one.

This screenshot sho!s D/3R reporting inline or =hidden= hooks in the ntdll.dll process !hich is used to handle translating user mode applications (Ring &) A91 re,uests to the kernel. 1n addition to hooking the virtual memory handler, this rootkit has also hooked i>6?@prt.sys and s3nkfilt.sys a keyboard and mouse driver respectively.

This screenshot sho!s D/3R reporting a keyboard hook and an 1R9 hook in atapi.sys, a lo! level hard disk driver. This is not a sure sign in itself as some change rollback or shado! copy soft!are may use 1R9 hooks in the disk driver, but it should be e*amined very carefully.

Another common techni,ue among AR products is to e*amine ra! disk data and compare it to data reported by A91s, or comparing the processes listed in 9sActive9rocess7ead !ith the processes listed by Task /anager. -iscrepancies are reported as hidden processes and files.
This screenshot belo! sho!s Rootkit Revealer reporting a number of hidden files. 7o!ever, these all appear to be false positives. Any file !hich changes bet!een the time the first (ra!) scan is done and the comparative (A91) scan is done !ill sho! up as discrepancies

This screenshot sho!s a D/3R scan reporting a huge list of system modifications entirely caused by either the A;A#T anti%virus package installed or D/3R itself. The D/3R e*ecutable in this case is named yoh6#rli.exe.

A;A#T has not only hooked 1AT and ##-T, but also has created filtered device drivers for the net!ork card, hard drive, and 8-R"/.

This screenshot sho!s 1ces!ord reporting an apparently alarming finding that )nkno!n e*ecutable has hooked several important ##-T entries including Nt,elete%ey and Nt,elete4al3e%ey. These hooks !ere created by the Avira anti% virus soft!are !hich then obfuscated the hook, probably to prevent mal!are from interfering but making it all the more suspicious looking.

This scan log sho!s a live T-6@ infection. $ote the characteristic hidden file system. Another givea!ay is that firefox.exe has hooked ntdll.dll. There is no reason for :irefo* to have any hooks at all, so this is an indication hostile code has been injected into the :irefo* process space. There are also a number of benign #ymantec soft!are hooks in place.

'liminating false positives After having e*amined all the hooks present in the "#, the investigator should try to eliminate any false positives by e*amining all the soft!are loaded on the system to determine !hether any legitimate applications may have placed the hooks. 1n some cases it may be possible to simply disable the soft!are being tested temporarily and run another scan. 1n other cases it !ill be re,uired to completely uninstall the soft!are to remove all of its hooks. This process should be completed methodically and the system rescanned after each change to see !hich hooks, if any, disappear. 1deally, a scan of the system in a kno!n clean state !ould have been done to allo! a comparison to be made. "nce all legitimate soft!are !hich may have hooked the "# has been disabled or removed, the remaining hooks can be assumed to either be part of the "# itself or a rootkit. Research into the "# design !ill tell !hether it has placed its o!n hooks or not. These /icrosoft dlls are kno!n to hook other dlls as part of their normal function. set3papi.dll< ms#sock.dll< sfc_os.dll< adsldpc.dll< advapi!@.dll< sec3r!@.dll< #s@_!@.dll< iphlpapi.dll< ntdll.dll< kernel!@.dll< 3ser!@.dll< 5di!@.dll . 1nline code modifications of kernel files are generally e*tremely suspicious, ho!ever, /icrosoft has released a set of A91s called =detours= for inline code modifications for use in hot patching live systems !ithout needing to reboot. The changes made by applications using these A91s !ould sho! up as hooks in a rootkit scanner. 9roperly implemented these types of hooks should be temporary and rare, ho!ever there is no !ay to be completely certain !hether any given inline kernel modification is malicious or not !ithout e*amining the memory location referenced by the hook. 1f you have a tool to enumerate dlls called by processes, such as 9rocess 3*plorer, you can check to see if deto3red.dll is listed. 1f so, this is generally a sign that the -etours A91 is in use and has hooked the process. 6inu* and /ac"# also use !hat<s called runtime patching or runtime memory barrier patching !hich replaces instructions in the .te*t section of the kernel. Denerally this is done to optimi+e the kernel for the specific instruction set of the 89) !ithout having to compile and release a binary for every type of 89), though sometimes it is done to apply kernel patches to a system that cannot be rebooted. All runtime changes should be documented in the .altinstructions or .altstr5replace section of the kernel. Any changes not documented there should be considered malicious, but even documented changes may sho! up on a running kernel modification scan from a tool like elfstat. And ultimately there is nothing stopping rootkit authors from properly documenting modifications to make the rootkit appear legitimate. '(amine automatic program e(ecution entries Rootkits, like any other comple* soft!are are generally composed of several interrelated files, !hich may include device drivers, e*ecutables, and dependent dlls. "ften there !ill be do+ens of such files, each of !hich has a speciali+ed function, stored in different folders all over the hard drive. The rootkit needs to get all of them into memory to function properly. This job falls to loader files, !hich only serve to load the other rootkit components into memory. There may be a half do+en or more distinct loaders, each capable of kickstarting the rootkit in case the others are deleted.

Rootkit authors tend to favor the =belt and suspenders= approach to making sure their rootkit is loaded on boot. "ften, despite having loaders specified in. $%-.\"oft#are\.icrosoft\Windo#sNT\93rrent4ersion\Windo#s\*ppInit_,--s $%1\.,&0*1-T\"oft#are\.icrosoft\Windo#s\93rrent4ersion\&xplorer\"hell 0olders $%-.\"'"T&.\93rrent9ontrol"et\9ontrol\"afe(oot\.inimal\ all of !hich are stealthy places to hide, the rootkit !ill still have loaders in all the obvious places you !ould think of to look for mal!are, like. $%-.\"oft#are\.icrosoft\Windo#s\93rrent4ersion\+3n and user #tartup folders, found at 9:\,oc3ments and "ettin5s\A3sernameA\"tart .en3\7ro5rams\"tart3p for A9 or 9:\1sers\A3sernameA\"tart .en3\7ro5rams\"tart3p for ;ista and later. 8hecking common locations for automatic program e*ecution is a good step to take in any investigation, even !here something as stealthy as a rootkit is concerned. Remember to check #ystem #ervices, Task #cheduler, and for 6inu*, init.d, rcA.d, .bash5profile, .bashrc, BetcBprofile, cron and at jobs also. The presence of a file !ith a name consisting of a series of random letters and numbers in any of these places is a dead givea!ay. 8hecking obvious locations for a loader is often a ,uick and easy !ay to unmask the presence of a rootkit !hich may have other more stealthy components else!here. Another ,uick check !hich surprisingly often yields results is to check the system directories for hidden files, ie 8:\Windo#s\system!@ 7idden files generally sho! up as =grayed out=. -espite being buried in a huge pile of legitimate files !hich !ould other!ise make finding any file !hich didn2t belong difficult, rootkits ,uite often mark their files as hidden as =e*tra protection=, !hich only serves to make them stand out to an investigator. ;ery fe! real "# files are marked hidden in the filesystem, so it is fairly easy to check online !hether any hidden files that turn up are legitimate or not. 1n 6inu* "# check lsmod and :proc:mod3les for unkno!n or suspicious kernel modules.

Memory Scan 3ven though there are methods for a rootkit to hide its code in memory, not all rootkits use these techni,ues, so a good A; or AR program !hich includes memory scanning is a good step to take, as is using Task /anager or ps to look at running processes for anything that looks suspicious. 3*amples of suspicious processes !ould include unusual filenames or applications !hich should not be running or !hich should have a visible !indo! but do not. /any rootkits hook the default bro!ser and run it in a hidden conte*t, so if the !eb bro!ser is sho!n as running !hen it is not visible as such, that can be a sign of infection. /ost linu* distributions using kernel >.? or ne!er enable 8"$:1D5#TR18T5-3;/3/ !hich disables the ability to read physical RA/, !hich may be re,uired for some rootkit scanning tools.

"pen Ports 1t is also a good idea to check all the open T89 and )-9 ports, using a tool like T89;ie! or netstat. 3ven though some rootkits hide net!ork connections, not all do, so it is !orth!hile to check. The computer being tested !ill need to have internet access for any attempts by the rootkit to =phone home= to sho! up. 8lose all other programs !hich may have an active internet connection to more easily spot unauthori+ed connections. Then do a reverse -$# lookup on any 19s !hich sho! up to determine if there is a legitimate reason for that connection. :or rootkits !hich use hidden connections, having another computer sniffing net!ork traffic using Wireshark and a hub or net!ork shunt can be a useful !ay to e*pose a rootkit2s communications to its remote command and control server. :ire!all and pro*y logs are another good place to look. Rootkits may connect back on any port or protocol. What2s more important is the connection end point. A lack of communication should not be construed as no infection, since some rootkits only phone home very infre,uently, but une*pected connections are a good indicator of infection. aking -otes Ceep meticulous notes of all information uncovered during an investigation. Rootkits are kno!n to behave erratically. A registry entry !hich points to one of the rootkit files may disappear the ne*t time the registry is e*amined. "pen net!ork connections may be brief and infre,uent. Take screenshots !here possible and in every case make note of file names and locations, memory offsets, registry entries, 19 addresses, and disk sector addresses.

Making A Diagnosis After all the above steps have been done, make copies of any files !hich are suspicious and upload them to a multi%A; site such as vir3stotal.com or novir3sthanks.or5. /ost rootkits use encryption or other obfuscation techni,ues and are only likely to have been previously identified by a handful of A; vendors. Running a scan using a large number of A; signature databases is more likely to result in a positive match should any of the files actually belong to a rootkit. 1n the absence of a direct match in one of the A; databases, a mal!are sandbo* such as an3;is.isecla;.or5 or camas.comodo.com may be useful for automated heuristic behavior analysis and comparison to kno!n rootkit profiles. This !ill often catch variants of popular rootkits that have simply had minor modifications to evade A;. 7o!ever, many rootkits monitor the e*ecution environment and !ill refuse to run in a virtuali+ed or sandbo*ed environment. 1n this case the investigator is forced to make an independent evaluation of the heuristic behavior of the computer as to !hether it is consistent !ith an infection. There is no sure standard, but most rootkit infections !ill e*hibit multiple signs, such as hooks, hidden processes, files, and net!ork connections. "t%er races "f Malicious Activity

A rootkit compromised machine may function as a staging area for the rootkit user to launch additional attacks on other machines on the net!ork. 1f this is the case, evidence of this activity may be found on the computer hard drive !hich can point to the underlying rootkit. Tools for malicious activity can be considered a sign of an infection. 7ackers often code attacks in 9erl, Ruby, and 9ython scripts, so support libraries for these programming languages may be an indicator of malicious activity. $et!ork scanners such as $map, sniffers such as Wireshark, pass!ord crackers such as Fohn the Ripper, and e*ploit frame!orks such as /etaplsoit may also be indicators of malicious activity. Whether they have a legitimate reason to be on the machine !ill depend on its regular use and role in the net!ork. 6ogs of other machines on the net!ork, including 1-#, !hich indicate a pattern of malicious activity originating from the suspect machine may also be a sign of infection. Advanced Rootkit Detection 3ven though hypervisor rootkits, memory only rootkits, and 01"# based firm!are rootkits have not been found in the !ild so far, they cannot be ruled out, particularly as nation%state actors become involved in the development of targeted mal!are. The e*istence of these kinds of advanced rootkits adds a greater element of uncertainty to rootkit detection. While it is possible to use commands like dmes5 to tell if virtuali+ation components are loaded in the "#, along !ith other techni,ues such as e*amining the 1-T (1nterrupt -escriptor Table), if the machine is already kno!n to be running a virtual environment as part of its normal function this gives no information !hether there is any additional hypervisor other than the e*pected one.

:orensic analysis of the hard drive on a kno!n clean system may sho! signs of a hypervisor rootkit !hich resides on the hard disk but not one !hich is only memory resident or any rootkit in hard!are flash memory. 7ard!are based rootkit scanners, may be able to unmask these advanced types of rootkits, but even that may not be able to catch all of them or may itself be vulnerable to compromise. -ue to the highly sophisticated nature of the threats, 4 G certainty that a rootkit is not present on a system is not possible. 3ven a brand ne! computer never before used can be compromised as there have been instances of mal!are infected soft!are provided direct from the manufacturer.

Rootkit Removal
The most reliable and efficient method of removing a rootkit is to lo! level format the infected hard drive using manufacturer2s soft!are or firm!are for that purpose and reload the "# from kno!n good backups. 1n cases !here computer firm!are is suspected of compromise, the additional step of re%flashing all 01"# firm!are using firm!are cryptographically signed by the manufacturer may be necessary. :or real certainty, every !ritable space, including all drives and firm!are, !ould need to be flushed. 1f this is impractical, steps may be taken to attempt to manually remove the rootkit piecemeal, ho!ever success cannot be guaranteed. The key to a manual rootkit removal is to have accurately and thoroughly mapped out all its functions, hooks, and files. "ften a rootkit !ill be programmed to check !hether its hooks and files are intact and replace them if they are modified or deleted. 1n order to fully remove a rootkit, all its files, hooks, and registry entries must be removed !hile the computer is offline to prevent the rootkit from detecting the changes and undoing them. Additionally, any device drivers and kernel files !hich have been modified by the rootkit !ill need to be restored from backup as they are critical for the operation of the "# and cannot be simply deleted. 1t !ill be crucial !hen restoring damaged drivers and kernel files to ensure they are the same version as the original. 1f kno!n good backups are not available, "# files may be restored from the original installation source. 0efore attempting a removal, it is advisable to observe the rootkit in operation on a clone drive using advanced debugging tools, such as #oft183 and "llydbg, !hich monitors heap and stack, traces registers, recogni+es procedures, loops, A91 calls, s!itches, tables, constants and strings. This is to make sure that all hidden components are uncovered to the fullest e*tent possible. 7o!ever, many rootkits !atch memory space for kno!n debuggers and !ill attempt to confuse the process by shutting do!n, falsifying data, or terminating the debugger. 1t is important to gather as much information as possible before attempting removal because if even one component is missed, the rootkit may still be operable and either recreate deleted components or do!nload them fresh from its control server. 1t may be necessary to fully reverse engineer the rootkit to determine ho! to completely remove it.

1n cases of an /0R infection, the /0R !ill need to be over!ritten !ith a clean copy using the fdisk utility, fixm; or for 6inu* 5r3;Binstall. 1n cases of slack space infection, the slack space can be over!ritten !ithout damaging the files on disk. This is done !ith a speciali+ed utility like 3raser or bmap. 1n fact, if the !hole hard drive is not going to be !iped, it is probably a good idea to at least !ipe slack space and free space, even if there is no concrete indication the rootkit is storing files there, simply because it doesn2t harm the filesystem and there just might be some backup copy of the rootkit there !aiting to spring back into action. :or cases of A-# infection, a different set of speciali+ed tools !ill be re,uired to clean them. #ome of these tools include. A-##py, #treams, and #treamArmor. 1f the rootkit has been positively identified by an A; vendor, it may be possible to use that vendor2s A; soft!are to remove some or all of the rootkit files automatically. :or this reason multi%A; scan sites !ill be valuable in identifying !hich A; vendor has detection signatures for the rootkit. 1n addition, there may be information online or available directly from the A; vendor !hich more fully describes the operation of the rootkit and e*act removal instructions. 3ven if no A; vendor has signatures for the rootkit, it may still be useful to run an A; scan !hich includes good heuristic detection, to complement other efforts and make sure nothing is missed.