Learning from Rustock rootkit

Today I'm going to talk again about Neprodoor trojan, adding some thoughts and technical informations to my previous post.

People who work in the antivirus industry know that they must learn from every malware attack. It is the only useful way to be able to develop better technologies and to be even able to prevent and block future infections. This is the same old known story, where human race should learn from history and avoid making same mistakes.

While investigating on the Neprodoor rootkit, I saw some similarities with another old famous rootkit. They are not related, nor written by the same hands, but they looked so conceptually similar that it captured my attention.

The rootkit I'm talking about is Rustock.C, the mysterious piece of malware which lot of people have talked about but only few of them really saw. This was the situation until last May, when a security company officially discovered and documented what can be defined as one of the most advanced kernel mode rootkits out there.

Those who analyze rootkits and write antirootkit engines know what the "Rustock" name means: it means innovation, breakthrough, new proof of concepts always able to bypass most existing security products. A piece of malicious software from which every antirootkit developer should learn.

While Rustock.C is still a mistery for most of the antirootkit engines out there, the curious thing is that some of these antirootkit products are not yet even able to detect some variants of the .B family. This can mean both that the rootkit is technically well written and that someone is not learning from known attacks. It also means there are many cases where people think their PC is clean when it is harboring one of the most powerful rootkits ever devised.

This is bad, because Rustock.B has been widely used to build up huge botnets with the goal to send massive spam waves or launch other infections.

We can't say the same for Rustock.C, because it has not been seen in the wild, just some isolated detections. Anyway, the big mistake would have been underevaluating the threat, because it looks like Rustock.C has inspired someone who has then written Neprodoor. This last one has unfortunately now been detected in the wild.

Rustock.C is very complicated, starting from the encryption it used to defend itself against analysts and code reversers. In fact, every PC infected with Rustock.C has its own exclusive or unique version/variant of the rootkit, encrypted with a specific key generated from the user's PC configuration. This means that anyone but the user of that PC is able to get it working. Impressive stuff.

Then, after the rootkit is run, it is able to infect one of Windows system drivers. By doing so it doesn't need a service registry key to be executed at Windows startup, it doesn't have or need its own body, it's just a piece of code attached to a legitimate driver. When loaded in memory, it just becomes a piece of untraceable executable code.

To stay invisible even on the disk, it places inline hooks on some ntfs.sys's IRP handlers. Every attempt to read the infected file will be useless because the original clean copy will be presented to the caller. Then, it injects a spambot user mode component inside winlogon.exe process.

This is only a small summary of what Rustock.C does, but the important thing is that it has been able, and remains able to evade detection by most specialized anti-rootkit products and probably all maintstream antivirus products.

Neprodoor is incredibly similar to Rustock.C, conceptually speaking.

Rootkit body is crypted, yet it is not as complex as Rustock's polymorphic encryption code. But it is enough to hide its code from unwanted eyes. In fact the encryption code is mostly trivial, but we'll see it more in detail later.

From my previous blog post we have seen how complicated and well constructed is the whole concept behind the Neprodoor trojan infection. We have found that Neprodoor is infecting ndis.sys driver.

Even Neprodoor's author, as Rustock's writer, has used the idea to infect a Windows system driver. This way he has all the advantages listed above, staring from the concealment capabilities in memory to the fact that the rootkit doesn't need any registry keys to launch.

This infection is quite different from the Rustock model. The rootkit dropper has embedded its rootkit code in an encrypted form. The dropper is able to read ndis.sys driver, encrypt it and build up a new ndis.sys driver which will contain the rootkit code and the old original encrypted body of ndis.sys. Then, the rootkit code will act as a stub to decrypt the real rootkit payload in memory followed by the decryption of the original ndis.sys.

The encryption itself is almost trivial and it's based on xoring every byte with the previous one, starting from the end of the encrypted driver body until the first byte. The first byte is then xored with a fixed byte.

Now that the driver is infected, the rootkit must use some technique to hide the infected file on the disk. Rustock was hooking ntfs IRP handlers placing some smart and unconventional inline hooks. Neprodoor is using a more classical but really effective way: hooking the IofCallDriver Windows kernel function, by changing the address pointer and redirecting it to its own function.

By doing so, the rootkit is now able to filter all driver communications and intercept any attempt to get access to the ndis.sys driver on the disk. In fact the rootkit is filtering the ndis.sys file name, so every attempt to get access to every file called ndis.sys for copying, renaming or overwriting will be denied. The rootkit is preventing every attempt to be cleaned or overwritten. A classic read will show the original ndis.sys file.

Neprodoor is now totally hidden on the disk and in memory: it has allocated a small memory region where it has decrypted and executed its real payload.

Rustock was now able to inject a spambot module inside winlogon.exe process. Neprodoor is setting up a process creation notify routine used to intercept services.exe process. This is the process where the rootkit will inject the user mode component of the infection which is able to communicate with a number of central servers and get other infection files from them through an encrypted protocol. Even Neprodoor downloads and execute a spambot component.

It's evident that Rustock and Neprodoor are not developed by the same author. However, looking at Neprodoor's code and behavior, it looks like the author could have used Rustock.C's as inspiration for his creation, after a process of simplification and optimization.

Rustock.C was over complicated, a nice development exercise but definitely not necessary. Neprodoor used the same concept, simpler and effective, able to hide from antirootkit engines. This is why we're seeing a growing number of infections caused by this rootkit.

If the rootkit is active, most antivirus engines are not able to detect the infection, and only a few of them detect it but they are not able to clean it, the available options might appear to be just delete or ignore the file. Be careful with this, the infected file is merged with your ndis.sys driver, a really important Windows network driver.

Rootkit developers have learned well from the underground and from the Rustock family. They have learned how easy it is to hide a malicious code inside Windows components thereby bypassing many security solutions abilities to detect or remediate.

Most security vendors don't appear to have learned much from Rustock rootkits, because if they had, then rootkits like Neprodoor could have been easily detected. Prevention is as important as detection and cleanup abilities. If every aspect is well balanced, then it will become much more difficult for an attacker to defeat security software.

This is one of the reasons why before thinking about hypervisor and SMM rootkits, we should take care of current threats, much more than what the security industry have done until now.

As said in the previous post, Prevx CSI and Prevx Edge are both able to clean the infection.