Is the new era of Rootkits upon us?

Today we have to deal with thousands of new threats on a daily basis and the use of rootkits have become very common. Most of the time, however, these threats are quite easy to detect, but once in awhile we see something interesting.

Sometimes we have to deal with interesting new proof of concepts, often used to reveal vulnerabilities in rootkit scanners or simply to illustrate a new idea of how to hide files on a user's machine, these are more advanced, but rarely become mainstream as they are too complex to write and hard to deploy.

The most common technique used today is SSDT (System Service Deor Table) hooking, changing pointers from kernel functions to custom written functions used to alter results and pass them back. It's easy to code, powerful and there are lot of C and C++ samples on how to code it on the web.

Yet there are a number of techniques to hide a rootkit on a system, but often only proof of concepts are released because they need a complexity of coding and a knowledge of the operating system that is not trivial.

That's why when Rustock rootkit was released, most antivirus companies weren't ready to fight against it. A rootkit that used different techniques to hide itself, very different from the normal ITW (In The Wild) samples that were detected at the time. Hooking INT 2E and SYSENTER handler functions, even if it was a documented technique, wasn't commonly used and lot of rootkit scanners couldn't detect the infection.

Excluding Rustock, that used a number of techniques to be stealth and it's still the most complex rootkit ITW, and excluding proof of concept malware that are developed just to show the world new ways to be stealth, the biggest percentage of ITW kernel mode rootkits use the SSDT hooking method examples: Haxdoor, Peacomm, Oddysse, Beagle Rootkit Component.

In the past few months, we have seen two rootkits using well known techniques but not so commonly used and, again, some rootkit scanners don’t detect them.

Almanahe and Srizbi used two interesting techniques, different to each other but at the same time similar. Let's see what do they do in the system.

Srizbi, as written in one of our previous articles in the blog, installs on the system and places inline hooks on some exported kernel functions. What does this mean? Simply that the SSDT pointers aren't changed in any way, because the hook is inside the function. This is a common technique for user mode rootkits, it's not quite widespread in kernel mode rootkits, so some rootkit scanners check only for addresses that point outside the kernel memory range, the wrong approach here because a code analysis could have helped in detecting the rootkit.

Almanahe, after being installed on the system does something interesting. It looks for unused space in the kernel memory space and uses detour patching with a classic PUSH/RET function. Then redirects some SSDT function pointers into the newly created section.

This time three situations could happen with rootkit scanners:

• SCANNERS THAT CHECK ONLY IF SSDT POINTS TO ADDRESSES OUTSIDE KERNEL MEMORY RANGE (commonly used technique): in both cases they are bypassed because pointers lie in the kernel range;
• SCANNERS THAT, CHECK & COMPARE IF SSDT POINT TO REAL KERNEL EXPORTED FUNCTIONS: in the case of Srizbi they are bypassed because the hook is done inside the first bytes of the function. In the case of Almanahe a cool situation appears: some SSDT function don't point to real exported functions, so the rootkit scanner tries to detect which module the SSDT is pointing to, and surprise! ntoskrnl is hooking the function. The inexperienced eye might think that the rootkit scanner is detecting a false positive, it's impossible that ntoskrnl is hooking its functions, an embarassing situation is created. Indeed, it's not really ntoskrnl that's hooking the function, it's SSDT which is pointing to a kernel memory address space where the rootkit has added inline hooks to its rootkit driver.;
• SCANNERS THAT DO CODE ANALYSIS TO FIND OUT WHERE POSSIBLE MODIFICATIONS RESIDE: in this case, depending on which deep level analysis is done by the rootkit scanner, it's possible to detect both rootkit hooks. If the Srizbi case is detectable with a simple code analysis, the Almanahe case isn't so trivial. In fact, if at the second check it's detected that a function is pointing to another kernel section instead of the one it should point to, a question could arise: why should ntoskrnl hook its own functions, pointing to its own memory space but not to the functions it should point to? Then, if pointers aren't pointing to addresses outside the kernel memory range, they are pointing inside the kernel but not to the right address inside it, something strange is happening and simply showing that ntoskrnl is hooking its own functions could be dangerous to the untrained eye.

Sure, even if some anti rootkits show that ntoskrnl is hooking functions, they can still restore SSDT fixing pointers and a lot of rootkit scanners give the users other tools to detect possible infection so that they simply don't rely only on this kind of detection.

Only the fact that already two rootkits in-the-wild are using a different approach to hide itself could be a warning that malware writers are ready to change techniques to evade antirootkits, and not only with proof of concepts but ready to release malware. SSDT hooking is old nowadays: Rustock, Almamahe and Srizbi are the clear examples. Are we ready to fight?

I would conclude with a simple video (available on our YouTube Channel) that would reply to all people that asked if a rootkit could work on new Windows Vista operating system.

Sure, with UAC (Are you sure you want to close that window?... Really, are you sure !!?!?!... Seriously, are you?!) turned ON its actually difficult to load a driver without user interaction (I don't want to focus here on social engineering tricks), but are Vista users really safe from rootkits?

A Rootkits goal is to hide itself and the components its there to protect from easily being noticed by the user, they can do it with some "trivial" techniques or compromise kernel objects: at the end, the result is the same.

In most cases, most users don’t know what a rootkit is, neither how to find out if they have one. This article is to raise a basic awareness of the issues surrounding rootkits.

Could a User Mode rootkit infect Vista? Let's see how a well known User mode rootkit named Vanquish is run on Windows Vista.