Computer security has become a hot topic for the news industry. Hardly a week passes without some new threat or data breach making headlines.
Increased media coverage of these attacks reflects the growing need for everyone to be educated about secure computing, not just system administrators and security professionals.

As with news in general, the more sensational or frightening the security story, the more attention it will get.

A regular candidate for these stories are rootkits.

Writers and editors, aided by the security community, spook users with tales of malicious rootkits with cryptic names such as Duqu and Stuxnet that are capable of no end of damage.

Rootkits have been around for some time—longer than many other types of malware.

They still make the news, though, because they are scary.

And they really are scary…if you lack proper protection.

What are Rootkits?

Broadly defined, a rootkit is any software that acquires and maintains privileged access to the operating system (OS) while hiding its presence by subverting normal OS behavior.

A rootkit typically has three goals:

  1. Run: A rootkit wants to be able to run without restriction on a target computer. Most computer systems (including Windows) have mechanisms such as Access Control Lists (ACLs) in place to prevent an application from getting access to protected resources. Rootkits take advantage of vulnerabilities in these mechanisms or use socialengineering attacks to get installed so that they have no restrictions on what they are able to do.
  2. Hide: Specifically, the rootkit does not want an installed security product to detect that it is running and remove it.The best way to prevent this is to appear invisible to all other applications running on the machine.
  3. Act: A rootkit has specific actions it wants to take (often referred to as its payload). Running and being hidden are all well and good, but a rootkit author wants to get something from the compromised computer, such as stealing passwords or network bandwidth, or installing other malicious software.

So what does it mean that a rootkit “subverts” normal OS behavior? This subversion occurs when a rootkit hides by lying to other software on the computer. Most software relies on the OS to provide information about the environment in which it is running.

For example, an application may have files that it needs to run, or data files that it needs to write to, or registry keys that are used for configuring the application.

The application asks the OS about those files and registry keys using the application programming interface (API) provided by the operating system. (Examples include FindFirst-File to enumerate files, or RegOpenKeyEx to get access to the registry).

The OS then returns the appropriate information to the application.

These same APIs are often used by security software when scanning for malicious software. In order to hide, rootkits hijack these APIs and watch for any question an application may ask that might be incriminating. So imagine that an application asks, “Operating system, can you show me the contents of the file at c:foo.exe?” The rootkit intercepts the question before it gets to the operating system and quickly replies (as if it were the operating system), “That file does not exist.”

The same sort of conversation might take place when looking at registry settings, which are used to configure individual applications and the OS itself.

The best rootkits will not only prevent their files from being read (as in the “foo.exe” example), but will completely hide their existence from other software running on the machine.
There are a number of techniques a rootkit can use to subvert normal operating system behavior:

  1. Hooking operating system APIs: Some rootkits re-route OS APIs by changing the address of these APIs to point to their own code.This can be done both in user mode (where most applications run) and kernel mode (where device drivers run) and is often referred to as “hooking.” When an application calls a hooked API, the system looks up the address of the API in a table (such as the System Service Dispatch Table in kernel mode or the Import Address Table in user mode).

    The operating system then executes the code at that address.

    If a rootkit has hooked the API, it has changed the address in the table to point to its own code so that its code runs, rather than the expected system functionality.

    This allows the rootkit to intercept requests that might reveal its presence.

  2. Hiding in unused space on the machine’s hard disk: This unused space is invisible to normal OS APIs that are used to look for files on the hard disk.The rootkit will then modify a commonly used driver (such as atapi.sys) so that when that driver loads it will look in this unused space to find the rest of the rootkit’s code.
  3. Infecting the master boot record (MBR): The rootkit may also infect the MBR in order to get its code into memory.The MBR is used to bootstrap a system, helping make the transition from the hardware portion of a computer’s startup routine to loading the operating system itself.

    If a rootkit can control that process, then it can control what code gets loaded into memory before the OS even has a chance to protect itself.

Regardless of the technique used, a rootkit is trying to get its code running while hiding its presence from other applications running on the machine.

Please Download the whitepaper to view the full report

Leave a Reply