A cunning rootkit

Ok, I see what they're doing now.

First some background ... Most rootkits _hide_ themselves from Windows api, and the anti-rootkits _find_ them by looking first with the normal Windows api, and then making another pass of the disk making calls directly to the kernel, and then comparing the lists. If they find a file in the second list that's not in the first, they report it as a hidden and there's a good chance it's a rootkit. This method is far from foolproof, because, for example, files might be legitimately created, say by a Browser, in between passes, and it will look like a hidden file, but it's good enough to provide a clue anyway.

What's happening with this one is that it is _not_ hidden. It sits in plain sight, and when the cross-viewing anti rootkits compare their lists, they get no differences, and therefore no hidden files, and most declare there to be no rootkit on the system.

Why is it a rootkit then? Instead of hooking the file list functions, they're hooking the _file open_ functions. If you try to view, or scan, or copy the contents of the rootkit, you get a "file does not exist" error!!! What this means is that even if your scanner has a signature for that rootkit, it probably won't be able to open the file anyway.

I dunno about you but I think that's pretty cunning!

Cheers

Roger