Rootkit

A rootkit is software that enables continued privileged access to a computer, while actively hiding its presence from administrators by subverting standard operating system functionality or other applications. Typically, a hacker installs a rootkit on a computer after first obtaining user-level access, either by exploiting a known vulnerability or cracking a password. Once a rootkit is installed, it allows an attacker to mask his intrusion while gaining root or privileged access to the computer. Although rootkits can serve a variety of ends, they have gained notority primarily as malware, appropriating computing resources or stealing passwords without the knowledge of the administrators or users of affected systems. Rootkits can target firmware, a hypervisor, the kernel or most commonly, user-mode applications.

The term rootkit is a concatenation of the "root" user account in Unix operating systems and the word "kit", which refers to the software components that implement the tool. The term has negative connotations through its association with malware.[1]

Contents

History

Screenshot of RootkitRevealer, showing the files hidden by the Extended Copy Protection rootkit

The very first computer virus to target the PC platform in 1986 used cloaking techniques to hide itself; the Brain virus intercepted attempts to read the boot sector, and redirected these to elsewhere on the disk where a copy of the original boot sector was kept.[2] Over time, DOS cloaking methods became more sophisticated, with advanced techniques including the hooking of interrupt 13 API calls in order to hide modifications to files.[2]

The term rootkit or root kit originally referred to a maliciously modified set of administrative tools for a Unix-like operating system, which granted "root" access.[3] If an intruder could replace the standard administrative tools on a system with a rootkit, the intruder could obtain root access over the system while concealing these activities from the legitimate system administrator. These early rootkits were trivial to detect by using uncompromised tools to access the same information.[4] Lane Davis and Steven Dake appear to have written the earliest known rootkit in 1990 for SunOS 4.1.1.[5] An earlier exploit equivalent to a rootkit was perpetrated by Ken Thompson of Bell Labs against a naval laboratory in California to settle a wager; Thompson subverted the C compiler in a Unix distribution and discussed the exploit in the lecture he gave upon receiving the Turing award in 1983.[6]

The first malicious rootkit for the Windows NT operating system appeared in 2001 with a trojan called NTRootkit, followed by HackerDefender in 2003.[2]

In 2005, Sony BMG included a rootkit program called Extended Copy Protection (XCP) – created by First 4 Internet[7] – on many of its music CDs[8] in an attempt to enforce DRM.[9] Sony silently installed the rootkit software on any Microsoft Windows computer that played certain Sony music CDs, without asking users' permission. Noted Windows expert Mark Russinovich created a tool called RootkitRevealer, with which he was able to discover Sony's rootkit.[2] He published the information in his blog, resulting in a highly-publicised scandal that raised the public's awareness of rootkits.[10] In addition to the intentional unauthorised modifications made to the target computer, the rootkit would automatically hide any file whose name started with "$sys$"—malware soon appeared that started to take advantage of the free cloaking provided by the rootkit, in order to hide from antivirus software.[2] The public relations fallout for Sony was compared by one analyst to the Tylenol Scare.[11] In light of adverse publicity, Sony BMG released patches to repair the breaches, but initial attempts failed to remove the security vulnerability. Subsequently, the company lost a related class action lawsuit in the United States.[12]

Uses

Modern rootkits for the Windows platform do not elevate access,[3] but rather are used to make some other software payload undetectable by adding stealth capabilities.[13] Most rootkits are classified as malware because the payloads they are bundled with are malicious, for example to covertly steal user passwords, credit card information, computing resources or to conduct other authorized activities. A small number are legimate utility applications—an example of the latter is a rootkit that provides CD-ROM emulation capability allowing video game users to defeat anti-piracy features that require the original installation media.

Rootkits and their payloads have many uses, mostly nefarious:

Types

There are at least five types of rootkit, ranging from those at the lowest level in firmware (with the highest privileges), through to the least privileged user-based variants that operate in Ring 3.

User-mode

Computer security rings (Note that Ring ‑1 is not shown)

User-mode rootkits run in Ring 3 as user rather than low-level system processes.[18] They have a number of possible installation vectors in order to intercept and modify the standard behaviour of APIs. Some inject a library (DLL) in other processes, and are thereby able execute inside any target process in order to spoof it; others with sufficient privileges simply overwrite the memory of a target application. Injection mechanisms include:[18]

"...since user mode applications all run in their own memory space, the rootkit needs to perform this patching in the memory space of every running application. In addition, the rootkit needs to monitor the system for any new applications that execute and patch those programs’ memory space before they fully execute."[3]

Kernel-mode

Kernel-mode rootkits run with the highest operating system privileges (Ring 0) by adding additional code or replacing portions of the core operating system, including both the kernel and associated device drivers. Most operating systems support kernel-mode device drivers which execute with the same privileges as the operating system itself.[19] As such, many kernel mode rootkits are developed as device drivers or loadable modules, such as loadable kernel modules in Linux or device drivers in Microsoft Windows. This class of rootkit has unrestricted security access, but is more difficult to write.[20] The complexity makes bugs common, and any bugs in code operating at the kernel level may seriously impact system stability, leading to discovery of a rootkit.[20] One of the first widely known kernel rootkits was developed for Windows NT 4.0 and released in Phrack[21] in the mid-1990s by Greg Hoglund.[22]

Kernel rootkits can be especially difficult to detect and remove, because they operate at the same security level as the operating system itself, and are thus able to intercept or subvert operating system operations. Any software, such as antivirus software, running on the compromised system is equally subvertible. In this situation no part of the system can be trusted.

A rootkit can modify data structures in the kernel (direct kernel object modification), it can hook kernel functions in the System Service Descriptor Table (SSDT) or modify the gates between user mode and kernel mode in order to implement its cloaking.[3]

Boot loader level (Bootkit)

A kernel-mode rootkit variant called a bootkit is used predominantly to attack full disk encryption systems, for example as in the "Evil Maid Attack".[23] The bootkit replaces the legitimate boot loader with one controlled by an attacker; typically the malware loader persists through the transition to protected mode when the kernel has loaded. For example, the "Stoned Bootkit"[24] subverts the system by using a compromised boot loader to intercept encryption keys and passwords. Apart from preventing unauthorized physical access to machines (a particular problem for portable machines), a Trusted Platform Module, configured to protect the boot path, is the only known defense against this attack.

Hypervisor level

Hypervisor rootkits have been created in academia only as proofs of concept. By exploiting hardware features such as Intel VT or AMD-V, this type of rootkit runs in Ring -1 and hosts the target operating system as a virtual machine, thereby enabling the rootkit to intercept all hardware calls made by the original operating system.[4] Unlike normal hypervisors, they do not have to load before the operating system, but can load into an operating system before promoting it into a virtual machine.[4] Unlike a kernel-mode rootkit, a hypervisor rootkit does not have to make any modifications to the kernel of the target in order to subvert it—however that does not mean to say that it cannot be detected by the guest operating system, as timing differences may for example be detectable in CPU instructions.[4] The "SubVirt" laboratory rootkit, developed jointly by Microsoft and University of Michigan researchers, is an academic example of a virtual machine based rootkit (VMBR),[25] while Blue Pill is another.

In 2009, researchers from Microsoft and North Carolina State University demonstrated a hypervisor-layer anti-rootkit called Hooksafe that provides generic protection against kernel-mode rootkits.[26]

Hardware/Firmware

A firmware rootkit uses device or platform firmware to create a persistent malware image in hardware such a network card, hard drive or the system BIOS.[18] The rootkit hides in firmware, because it is not usually inspected for code integrity. John Heasman demonstrated the viability of firmware rootkits in both ACPI firmware routines[27] and in a PCI expansion card ROM.[28]

In October 2008, criminals tampered with European credit card reading machines before they were installed. The devices intercepted and transmitted credit card details via a mobile phone network.[29] In March 2009, researchers Alfredo Ortega and Anibal Sacco[30] published details of a BIOS-level WIndows rootkit that was able to survive disk replacement and OS re-installation.[31] Full details are available.[32]

A few months later they found that most laptop BIOSes come with a "legal" preinstalled rootkit known as Computrace LoJack. This is an anti–theft technology system that, as the researchers showed[33] can be turned to malicious purposes.[34]

Installation and cloaking

Rootkits employ a variety of techniques to gain control of a system; the type of rootkit will also influence the attack vector that is chosen. The most common is to leverage security vulnerabilities. Another approach is to become a Trojan horse, deceiving a computer user into trusting the rootkit's installer as benign—in this case, social engineering convinces a user that the rootkit is beneficial.[20] The installation task is made easier if the principle of least privilege is not applied, since the rootkit then does not have to explicitly request elevated (administrator-level) privileges. Other classes of rootkits can be installed only by someone with physical access to the target system.

The installation of rootkits is commercially driven, with a Pay-Per-Install (PPI) compensation method for distributors.[35]

Once installed, a rootkit takes active measures to obscure its presence within the host system through subversion or evasion of standard operating system security tools and API's used for diagnosis, scanning and monitoring. Rootkits achieve this by modifying the behavior of core parts of an operating system by loading code into other processes, the installation or modification of drivers or kernel modules. Obfuscation techniques include concealing running processes from system monitoring mechanisms and hiding system files and other configuration data.[36] It is not uncommon for a rootkit to disable the event logging capacity of an operating system in an attempt to hide evidence of an attack. Rootkits can in theory subvert any operating system activities except CPU scheduling.[37] The "perfect rootkit" can be thought of as similar to a "perfect crime", one that nobody realizes has taken place.

In addition to installing more commonly into Ring 0 (kernel-mode) where they have complete access to a system, rootkits also take a number of measures to ensure their survival against detection and cleaning by antivirus software. These include polymorphism, stealth techniques, regeneration and disabling anti-malware software.[38]

Detection

The fundamental problem with rootkit detection is that if the operating system has been subverted, particularly by a kernel-level rootkit, it cannot be trusted to find unauthorized modifications to itself or its components.[37] Actions such as requesting a list of running processes, or a list of files in a directory, cannot be trusted to behave as expected. In other words, rootkit detectors that work while running on infected systems are only effective against rootkits that have some defect in their camouflage, or that run with lower user-mode privileges than detection software in the kernel.[20] As with computer viruses, the detection and elimination of rootkits is an ongoing struggle between both sides of this conflict.[37]

Detection can take a number of different approaches, including signatures (e.g. antivirus software), integrity checking (e.g. digital signatures), difference-based detection (comparison of expected vs actual results) and behavioural detection (e.g. monitoring CPU usage or network traffic).

Several products detect some rootkits. Unix offerings include Zeppoo, chkrootkit, rkhunter and OSSEC. For Windows, free detection tools include Microsoft Sysinternals Rootkit Revealer, avast! antivirus, Sophos Anti-Rootkit, F-Secure Blacklight(The first rootkit detector), and Radix. Any rootkit detectors that prove effective ultimately contribute to their own ineffectiveness as malware authors adapt and test their code to escape detection by well-used tools.[Notes 1]

Alternative trusted medium

The best and most reliable method for operating system-level rootkit detection is to shut down the computer suspected of infection, and then to check its storage by booting from an alternative trusted medium (e.g. a rescue CD-ROM or USB flash drive).[39] A non-running rootkit cannot hide its presence, and most established antivirus programs can identify rootkits via standard OS calls (which are often tampered with by the rootkit) and lower level queries, which remain reliable. This also defeats the camouflage technique which suspends rootkit activity until scanning has finished; this is not possible if the rootkit is not running.

Behavioural-based

This approach attempts to infer the presence of a rootkit by looking for rootkit-like behaviour. For example by profiling a system, differences in the number, timing and frequency of API calls, or in overall CPU utilization, can be attributed to a rootkit. The method is complex and is hampered by a high incidence of false positives. Defective rootkits can sometimes introduce very obvious changes, such as crashing the system, that will attract the attention of system users and administrators.[40]

Signature-based

Antivirus products rarely catch all viruses in public tests, even though security software vendors incorporate rootkit detection into their products. Should a rootkit attempt to hide during an antivirus scan, an appropriate stealth detector notices; if it attempts to temporarily unload itself from the system, fingerprint (or signature) detection can still find it. This combined approach forces attackers to implement counter-attack mechanisms ("retro" routines) that kills the antivirus program. Signature-based detection methods are effective against well-published rootkits, but less so against specially crafted, custom root rootkits.[37]

Difference-based

Another method that can detect rootkits compares "trusted" raw data with "tainted" the content returned by an API. For example, binaries present on disk can be compared with their copies within operating memory, or the results returned from file system or Registry APIs can be checked against raw structures on the underlying physical disks[37][41]—however in the case of the former, some valid differences can be introduced by operating system mechanisms, e.g., memory relocation or shimming. This was the method used by Mark Russinovich's RootkitRevealer tool to find the Sony DRM rootkit.[2]

Integrity checking

The Rkhunter utility uses sha-1 hashes to verify the integrity of system files

A cryptographic hash function can be used to compute a "fingerprint" or digital signature that can help to detect subsequent unauthorized changes to on-disk code libraries.[42] However, unsophisticated schemes check only whether the code has been modified since release by the "publisher"; subversion prior to that time is not detectable. The fingerprint must be re-established each time changes are made to the system. The fingerprinting process creates a message digest dependent on every bit in each file being fingerprinted. By recalculating and comparing the message digest at regular intervals, changes in the system can be detected and monitored as long as the original baseline was not created when the malware was already present, and the malware is also unable to subvert the crytographic functions used to compute digital signatures. The technique is effective against the earlist forms of rootkit that simply replaced Unix commands like "ls" in order to mask the presence of a file.

Similarly, detection in firmware can be achieved by computing a cryptographic hash of firmware and comparing hash values to a whitelist of expected values, or by extending the hash value into TPM (Trusted Platform Module) configuration registers, which are later compared to a whitelist of expected values. Code that performs hash, compare, and/or extend operations must also be protected. The notion of an immutable root-of-trust, ensures that a rootkit (or more specifically a bootkit) does not compromise the system at its most fundamental level. A method of rootkit detection using a TPM is described by the Trusted Computing Group.[43]

Memory dumps

Forcing a kernel or complete memory dump will capture an active kernel-mode or user-mode rookit in the resulting dump file, allowing offline anaylsis to be performed with a debugger and without the rootkit being able to take any measures to cloak itself. This technique is highly specialised, and may require access to non-public source code or symbols. Memory dumps cannot be used to detect a hypevisor-based rootkit, which is able to intercept and subvert the lowest-level attempts to read memory.[4]

Removal

Most rootkits install hooks in user-mode processes;[18] those that operate at the lowest level of the OS (Ring 0), have system privileges, so booting into Safe Mode on a Windows machine will not usually allow removal. Given the stealth nature of rootkits, some experts believe that the only reliable way to remove them is to re-install the operating system from trusted media.[44]

Manual repair

Manual removal is often too difficult for a typical computer user.[45] Conversely, antivirus and malware removal tools running on an untrusted system may be ineffective against well-written kernel-mode rootkits. Booting an alternate operating system from trusted media can allow an infected system volume to be mounted and potentially safely cleaned. Lightweight operating systems such as Windows PE, Windows Recovery Console, Windows Recovery Environment, BartPE or Live Distros can be used for this purpose, allowing the system to be cleaned, or alternatively, critical data to be copied off before the system is rebuilt.

Re-installation

More often, manual repair is impractical. Even if its type and nature are known, re-installing the operating system and applications is simpler and quicker. Re-installation time can be greatly reduced by modern drive imaging software, especially when the source image includes necessary hardware drivers and software applications. This is true even if the rootkit is well-known and can be completely removed.[46]

Raw disk access

Some antivirus scanners can bypass file system APIs, which are controlled by the operating system and therefore vulnerable to manipulation by a rootkit. They accesses raw file system structures directly and use this information to validate the results from system APIs to indentify any differences that may be caused by a rootkit that has subverted the file system.[Notes 2][47][48][49][50][51]

Public availability

Like much malware used by attackers, many rootkit implementations are shared and are easily available on the Internet. It is not uncommon to see a compromised system in which a sophisticated publicly available rootkit hides the presence of unsophisticated worms or attack tools that appear to have been written by inexperienced programmers.

Most of the rootkits available on the Internet are constructed as an exploit or "proof of concept" to demonstrate varying methods of hiding things within a computer system and of taking unauthorized control. Since these are often not fully optimized for stealth, they sometimes leave unintended evidence of their presence. Even so, when such rootkits are used in an attack they are often effective.

See also

Notes

  1. ↑ The process name of Sysinternals Rootkit Revealer was targeted by malware; in an attempt to counter this countermeasure, the tool now uses a randomly-generated process name.
  2. ↑ In theory, a sophisticated enough kernel-level rootkit can subvert read operations against raw file system data structures too, so that they match the results returned by APIs

References

  1. ↑ "Glossary of malware terminology". Anti-Spyware Coalition. http://www.antispywarecoalition.org/documents/glossary.htm. 
  2. ↑ 2.0 2.1 2.2 2.3 2.4 2.5 "Rootkits, Part 1 of 3: The Growing Threat". McAfee. 2006-04-17. http://www.mcafee.com/us/local_content/white_papers/threat_center/wp_akapoor_rootkits1_en.pdf. Retrieved 2010-08-16. 
  3. ↑ 3.0 3.1 3.2 3.3 Windows Rootkit Overview. Symantec. 2006-03-26. http://www.symantec.com/avcenter/reference/windows.rootkit.overview.pdf. Retrieved 2010-08-17. 
  4. ↑ 4.0 4.1 4.2 4.3 4.4 Michael Myers & Stephen Youndt (2009-11-18). An Introduction to Hardware-Assisted Virtual Machine (HVM) Rootkits. Harris Corporation. http://download.harris.com/app/public_download.asp?fid=2237. Retrieved 2010-08-18. 
  5. ↑ Andrew Hay, Daniel Cid, Rory Bray (2008). OSSEC Host-Based Intrusion Detection Guide. Syngress. p. 276. ISBN 159749240X. http://books.google.com/books?id=h37q2q3wvcUC&pg=PA276. 
  6. ↑ Thompson, Ken (August 1984). "Reflections on Trusting Trust" (pdf). Communications of the ACM 27 (8). http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf. 
  7. ↑ "XCP.Sony.Rootkit". Computer Associates. 2005-11-05. http://www.ca.com/us/securityadvisor/pest/pest.aspx?id=453096362. Retrieved 2010-08-19. 
  8. ↑ "XCP Titles". Sony BMG. 2006. http://www.sonymusic.com/cp/xcp/english/titles.html. 
  9. ↑ Mark Russinovich (31 October 2005). "Sony, Rootkits and Digital Rights Management Gone Too Far". http://blogs.technet.com/markrussinovich/archive/2005/10/31/sony-rootkits-and-digital-rights-management-gone-too-far.aspx. Retrieved 2008-09-15. 
  10. ↑ Mark Russinovich (2005-10-31). "Sony, Rootkits and Digital Rights Management Gone Too Far". Microsoft. http://blogs.technet.com/b/markrussinovich/archive/2005/10/31/sony-rootkits-and-digital-rights-management-gone-too-far.aspx. Retrieved 2010-08-16. 
  11. ↑ "Sony's long-term rootkit CD woes". BBC News. 21 November 2005. http://news.bbc.co.uk/2/hi/technology/4456970.stm. Retrieved 2008-09-15. 
  12. ↑ Mark Lyon (06 Feb 2006). "Settlement Notice". Sonysuit.com. http://www.sonysuit.com/. 
  13. ↑ Greg Hoglund, James Butler (2006). Rootkits: Subverting the Windows kernel. Addison-Wesley. p. 4. ISBN 0321294319. http://books.google.com/books?id=fDxg1W3eT2gC. 
  14. ↑ Mark Russinovich (June 2005). "Unearthing Root Kits". Windows IT Pro. http://www.windowsitpro.com/Article/ArticleID/46266/46266.html. 
  15. ↑ "World of Warcraft Hackers Using Sony BMG Rootkit". The Register. 2005-11-04. http://www.theregister.co.uk/2005/11/04/secfocus_wow_bot/. Retrieved 2010-08-23. 
  16. ↑ Steve Hanna (September 2007). [http://www.vividmachines.com/download/icsicceid.pdf Using Rootkit Technology for Honeypot-Based Malware Detection]. CCEID Meeting. http://www.vividmachines.com/download/icsicceid.pdf. 
  17. ↑ Russinovich, Mark (6 February 2006). "Using Rootkits to Defeat Digital Rights Management". Winternals. SysInternals. Archived from the original on 31 August 2006. http://blogs.technet.com/markrussinovich/archive/2006/02/06/using-rootkits-to-defeat-digital-rights-management.aspx. Retrieved 2006-08-13. 
  18. ↑ 18.0 18.1 18.2 18.3 Aditya Kapoor and Ahmed Sallam (2007-04-03). "Rootkits Part 2: A Technical Primer". McAfee. http://www.mcafee.com/us/local_content/white_papers/wp_rootkits_0407.pdf. Retrieved 2010=08-14. 
  19. ↑ The 64-bit version of Windows XP and Server 2008 are a notable exception "Driver Signing Requirements for Windows". Microsoft. http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx. Retrieved 2008-07-06. 
  20. ↑ 20.0 20.1 20.2 20.3 "Understanding Anti-Malware Technologies". Microsoft. http://download.microsoft.com/download/a/b/e/abefdf1c-96bd-40d6-a138-e320b6b25bd3/understandingantimalwaretechnologies.pdf. Retrieved 2010-08-17. 
  21. ↑ issue 55
  22. ↑ Rootkit Evolution by Alisa Shevchenko (1 September 2008), An Overview of Unix Rootkits by Anton Chuvakin (February 2003)
  23. ↑ Bruce Schneider (23 October 2009). ""Evil Maid" Attacks on Encrypted Hard Drives". http://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html. Retrieved 2009-11-07. 
  24. ↑ Peter Kleissner (19 October 2009). "Stoned Bootkit". Insecurity Systems. http://www.stoned-vienna.com/. Retrieved 2009-11-07. 
  25. ↑ "SubVirt: Implementing malware with virtual machines" (PDF). University of Michigan, Microsoft. 3 April 2006. http://www.eecs.umich.edu/virtual/papers/king06.pdf. Retrieved 2008-09-15. 
  26. ↑ Zhi Wang, Xuxian Jiang, Weidong Cui & Peng Ning (11 August 2009) (pdf Protection). Countering Kernel Rootkits with Lightweight Hook. Microsoft/North Carolina State University. http://research.microsoft.com/en-us/um/people/wdcui/papers/hooksafe-ccs09.pdf. Retrieved 2009-11-11. 
  27. ↑ Implementing and Detecting an ACPI Rootkit by John Heasman, presented at BlackHat Federal, 2006.
  28. ↑ Implementing and Detecting a PCI Rootkit by John Heasman, November 15, 2006.
  29. ↑ Austin Modine (10 October 2008). "Organized crime tampers with European card swipe devices: Customer data beamed overseas". The Register. http://www.theregister.co.uk/2008/10/10/organized_crime_doctors_chip_and_pin_machines/. Retrieved 2008-10-13. 
  30. ↑ Sacco, Anibal; Ortéga, Alfredo. "Persistent BIOS infection". Core Security Technologies. http://www.coresecurity.com/content/Persistent-Bios-Infection. Retrieved 2009-10-06. 
  31. ↑ Dan Goodin (24 March 2009). "Newfangled rootkits survive hard disk wiping". The Register. http://www.theregister.co.uk/2009/03/24/persistent_bios_rootkits/. Retrieved 2009-03-25. 
  32. ↑ Phrack Magazine #66
  33. ↑ Sacco, Anibal; Ortéga, Alfredo. "Deactivate the Rootkit". Exploiting Stuff. http://exploiting.wordpress.com/2009/09/11/138/. 
  34. ↑ Sacco, Anibal; Ortéga, Alfredo. "Deactivate the Rootkit". Core Security Technologies. http://www.coresecurity.com/content/Deactivate-the-Rootkit. 
  35. ↑ Aleksandr Matrosov & Eugene Rodionov (2010-06-25). "TDL3: The Rootkit of All Evil?". ESET. http://www.eset.com/resources/white-papers/TDL3-Analysis.pdf. Retrieved 2010-08-17. 
  36. ↑ Brumley, David (16 November 1999). "invisible intruders: rootkits in practice". USENIX. http://www.usenix.org/publications/login/1999-9/features/rootkits.html. 
  37. ↑ 37.0 37.1 37.2 37.3 37.4 "Hacking Exposed Malware and Rootkits". Massachusetts Institute of Technology. http://www.mhprofessional.com/downloads/products/0071591184/0071591184_chap10.pdf. Retrieved 2010-08-14. 
  38. ↑ Defeating Rootkits and Keyloggers. Trlokom. 2006-07-05. http://www.trlokom.com/pdf/TrlokomRootkitDefenseWhitePaper.pdf. Retrieved 2010-08-17. 
  39. ↑ Josh Harriman (2007-10-19). [http://www.symantec.com/avcenter/reference/testing_methodology_for_rootkit_removal.pdf A Testing Methodology for Rootkit Removal Effectiveness]. Dublin, Ireland: Symantec Security Response. http://www.symantec.com/avcenter/reference/testing_methodology_for_rootkit_removal.pdf. Retrieved 2010-08-17. 
  40. ↑ Mircea Cuibotariu (2010-02-12). "Tidserv and MS10-015". Symantec. http://www.symantec.com/connect/blogs/tidserv-and-ms10-015. Retrieved 2010-0819. 
  41. ↑ "Strider GhostBuster Rootkit Detection". Microsoft Research. http://research.microsoft.com/en-us/um/redmond/projects/strider/rootkit/. Retrieved 2010-08-14. 
  42. ↑ "Signing and Checking Code with Authenticode". Microsoft. http://msdn.microsoft.com/en-us/library/ms537364(VS.85).aspx. Retrieved 2008-09-15. 
  43. ↑ "Stopping Rootkits at the Network Edge" (PDF). Trusted Computing Group. 4 January 2007. https://www.trustedcomputinggroup.org/news/Industry_Data/Whitepaper_Rootkit_Strom_v3.pdf. Retrieved 2008-07-11. 
  44. ↑ Ellen Messmer (2006-08-26). "Experts Divided Over Rootkit Detection and Removal". NetworkWorld.com. http://www.networkworld.com/news/2006/082806-rootkits.html. Retrieved 2010-08-15. 
  45. ↑ "Rootkits Part 2: A Technical Primer". McAfee. 2007-04-03. http://www.mcafee.com/us/local_content/white_papers/wp_rootkits_0407.pdf. Retrieved 2010-817. 
  46. ↑ "Rootkit Question". Spywareinfoforum.com. http://www.spywareinfoforum.com/lofiversion/index.php/t52360.html. Retrieved 2009-04-07. 
  47. ↑ Posted by Flashlight (30 April 2007). "Tech Loop: Rootkits: The next big enterprise threat?". Techloop.blogspot.com. http://techloop.blogspot.com/2007/04/rootkits-next-big-enterprise-threat.html. Retrieved 2009-04-07. 
  48. ↑ "Security Watch: Rootkits for fun and profit - CNET Reviews". Reviews.cnet.com. 19 January 2007. http://reviews.cnet.com/4520-3513_7-6686763-1.html. Retrieved 2009-04-07. 
  49. ↑ Sponsored by Dell. "Six ways to fight back against botnets - Business Center". PC World. http://www.pcworld.com/businesscenter/article/137821/six_ways_to_fight_back_against_botnets.html. Retrieved 2009-04-07. 
  50. ↑ 12:00 AM. "Handling Today's Tough Security Threats: Rootkits - Malicious Code - STN Peer-to-Peer Discussion Forums". Forums.symantec.com. https://forums.symantec.com/t5/Malicious-Code/Handling-Today-s-Tough-Security-Threats-Rootkits/ba-p/305215;jsessionid=7D537BC23D36E015CD11EA806B389E54#A68. Retrieved 2009-04-07. 
  51. ↑ Hultquist, Steve (30 April 2007). "Rootkits: The next big enterprise threat? | Security Central". InfoWorld. http://www.infoworld.com/d/security-central/rootkits-next-big-enterprise-threat-781. Retrieved 2009-04-07. 

Further reading

External links