Why rootkits mean you must nuke your machine

At Microsoft's IT Forum 2005 event in Barcelona this week, Windows programme manager Mike Danseglio explained the only reliable method of dealing with rootkits
Written by Matt Loney, Contributor

Rootkits hit the news earlier this month when Mark Russinovich of Sysinternals noticed odd behaviour following installation of some digital rights management (DRM) software that shipped with a Sony music CD. What he found sparked a furore that saw Sony threatened with everything from boycotts to class action lawsuits, and system administrators totally reassigning their approach to users playing what had previously been widely seen as harmless music CDs on work computers.

Rootkits may have been around for many years on Unix systems, but the Sony DRM debacle has propelled them into the consciousness of many IT managers responsible for Windows computers.

At Microsoft's IT Forum 2005 event in Barcelona this week, Windows programme manager Mike Danseglio delved into the technical aspects of rootkits. ZDNet UK was there to report what he had to say, to find out what University of Michigan students get up to with rootkits, why the only way to recover an affected machine with any level of assurance is to nuke it, and what the future holds.

What is a rootkit?
A rootkit is not an attack vector on its own. It is not a virus, and it is not a worm. It is a cloak or a disguise — something to hide something else. For instance an attacker might want to use a rootkit to put a virus on your system but doesn't want you to be able see that virus.

Is a rootkit malware?
Most people think it is, but it is not always. A sys admin might want to use a rootkit to hide something from the user, to monitor the system in some way. I treat rootkits neutrally — I don't want to class them as good or bad. You have to make your decision in each case.

The rootkit is not a virus, a worm, or a Trojan horse. It is just the code that hides something. Can it hide worms and spyware etc? Absolutely it can. The issue in the Sony DRM case is whether Sony properly disclosed that it is installing a rootkit on your system. And what Sony uses is a rootkit: it hides other things.

How do rootkits work?
In Windows, the easiest way for a rootkit to run is in user mode. The easiest way for it to do this is to grab hold of the ntldll.dll file, and if it can control this then it can hide anything it wants from any other program running in user mode. Software may askntldll.dll if there is a rootkit present, and if there is, it will say "No".

Other rootkits run in kernel mode, and these can fool not only user-mode scanning, but also kernel-mode scanning. That can be a big concern.

Once installed, a rootkit can do anything it wants to. It can hide files, directories, ports, registry entries, pretty much anything you might use in user mode to examine the system.

Most virus scanners cannot detect a rootkit when that rootkit is active — the scanner says "show me all the files on the operating system, and the rootkits say "ok, I'll show you all the files on the operating system (except mine)." So all the files are scanned except those belonging to, or hidden by, the rootkit.

User mode rootkits are relatively stable. If they crash then they only affect themselves. They are much more common that kernel-level rootkits. However, a lot of people try to write kernel mode rootkits, and these are inherently dangerous as they operate in a space where the operating system works. They can destabilise the entire system. They frequently bluescreen machines; in product support that is often the first sign we see that a rootkit exists on a system.

Kernel mode rootkits are more powerful but far more dangerous, as they tend to be more unstable. Why?
Because the application programmers writing them are not so advanced. Yet. We have to see any great programmers writing kernel mode rootkits, but this is in its infancy, so that may well change.

What does the lifecycle of a rootkit look like?
The first thing that happens is that a rootkit is created by a programmer. The next stage is that the system is compromised, usually not by the person who wrote the rootkit, but by another means. Rootkits do not themselves infect computers. They do not identify and exploit compromises, or scan systems. They need some other exploit to get on the system; this can be an unpatched system, a system with a weak password and so on.

Once a system is compromised, an attacker has access to the system, and can put files on it; they may put a rootkit on there to further compromise the system or to hide the compromise. They can then put other tools there to conduct the attack. Often we then see some time lag between the compromise and the attack. Attackers do not just crash system, they tend to be subtle — they may wait a week, a month or six months, before doing anything.

Finally, the attack is invoked — the attacker may use the compromised machine as a zombie, or as a mail forwarder. The problem is that they can repeat the attack until the rootkit is removed, and of course your problem is that because this is a rootkit, you don't know there is a rootkit on the system. We found on machine in a university in the US where a rootkit had been installed two years ago. What it did during those two years we don't know.

Where do rootkits come from?
We find they can be written by anyone from script kiddies to master programmers. It doesn't require great knowledge of Windows. Why? Because there are source code examples out there. You can grab downloadable source code for free, and take a look at how they work.

Hacker Defender is the most common rootkit. It is written by a guy who calls himself the Holy Father, in the Czech Republic. He has a free one, but also a version for sale, and will even create custom versions for you, which means each one is unique, and so we cannot detect it using a signature file.

How do rootkits get onto a system?
In two main ways: manual and automatically. Manual is the more common method, and this is where an attacker identifies the system, uses footprinting techniques to identify systems of interest, then loads the rootkit and executes it. This is very hard to detect because it tends to be a one-off attack, not broadcasting tons of traffic, not attacking every system in IP address order.

The automatic method is les common: it tends to rely on very noisy, undirected attacks that tend to get picked up in log files by intrusion detection systems.

Then there is the hybrid attack, which we see often in government espionage, where the attacker might identify all interesting systems in a particular environment and attack those specifically, and quietly. Recently we had one government customer whose ports were being port scanned very slowly, at the rate of one port probed every three weeks. This was a very slow and very deliberate and it was very hard to detect. But it was an attack.

How can we detect rootkits?
There are a number of tools, including: VICE, Patchfinder2, Rootkit Revealer, Klister/Flister, F-Secure Blacklight, Microsoft File Checksum Integrity Verifier, Windows Preinstallation Environment (WinPE), Bootable Antivirus and Recovery Tools (Bart PE), Knoppix Security Tools Distribution (STD).

The ones at the top of this list examine the operating system from the inside, which means they often cannot detect the rootkit code. A lot depends on the quality of that code. Rootkit Revealer sometimes detects Hacker Defender, sometimes it doesn't. It totally depends on the attacker.

WinPE and Bart PE and Knoppix STD all rely on external operating systems loaded on CDs or thumbdrives, and they do not activate the local operating system that you're attempting to scan. They let you examine it from the outside.

There is no way to hide from an external scanner, but if the rootkit is customised then again it can be very difficult to detect. One solution is to look at the entire file system and dump it to a text file externally, then boot the suspect operating system, examine everything from within it and dump that to a text file. If I then see eight extra files on the first version that don't appear on the second version I might find that one is a rootkit, one is a virus or even a movie. That is a very reliable technique.

Of course the concern is that this is not practical when you have 80,000 PCs and 700 servers. How do you detect rootkits on those? There can be tell-tale signs. At the University of Washington they find at least two rootkits a week. The students are doing nothing [with the rootkits] but hiding movies. The university identifies systems that have rootkits because in that case they have enormous amounts of network traffic. If you have 50 people pulling a 4GB DVD off a server that normally has just 1Mbit throughput, then you should be concerned. So one way to scan for rootkits is to look for footprints and ask yourself what is it doing to my system?

How do we remove rootkits?
There is only one guaranteed way to remove a rootkit: you destroy the system and then rebuild it. There is no other way to reliable remove a rootkit — no other way whatsoever.

You can't delete the file or even reinstall the operating system over the top of the existing OS — which is a horrible practice anyway. It is super important to nuke the system because a rootkit's primary function is stealth — what is it hiding? Do you know? Usually not. How can you reliably know what it was hiding, what it was compromising or what it was removing?

Are there any defences?
You should use malware scanners, firewalls, intrusion detection and prevention, strong passwords, regular patches and audits. They are easy to prevent, but extraordinarily difficult to remove.

What does the future hold?
We found one example of a rootkit recently that hides itself in video memory, and every time the system boots it loads up. This means that it doesn't exist on the hard drive, and so the only time you can detect it is when the system is running, which is when it is able to hide itself. That's where we see things going: harder to detect, better cloaking. And of course finding its way into DRM technology, and increasingly into spyware too.

Editorial standards