Has anyone come across any rootkits that hook down to the process API, registry API, memory API and file API level and render themselves totally undetectable even by the most sophisticated reverse engineer? In otherwords the only effective rootkit detection software would have to perform an offline scan of the operating system disk. This of course leads to the question: how do you detect such an insidious infection while booted in the infected OS?

do you mean windows?

OS does not really matter - any OS that abstract data storage through shared libraries would theoretically be vulnerable. This is a theoretical question: can software perfectly hide itself at the OS level? If so then as you point out how can we be sure our Windows boxes have not already fallen victim. The problem is that offline there is no way to detect the rootkit either without finding the load entry and rootkit file as there is nothing to compare or hooked so the standard rootkit detection methods are useless (running Autoruns under a clean WinPE boot is the best I can come up with for Windows).

For any advanced computer user, this is the biggest theoretical threat in my opinion to the security of a local machine (and network). You will be completely unaware and may even be unable to remove the threat and have no option except to format and hope it does not get reinfected.

>>how do you detect..

my mind gives only 1 method inside detecting, if it is API-hooker rootkit.

Load our program with driver & dump kernel memory, also dump any info SIDT,GDT.. then sit & analyze..

hint: If we have privilege, but can't load driver.. ~: guess, infected

PS. guess2: seems my mind does your mind job!?

evaluator: I considered this technique but would argue there are problems as the kernel mode dump could trigger the driver to unload and further there is the sit & analyze. A kernel mode driver could do any number of things to make itself so obscured that you would need an automated driver image verifier tool to make things close to practical.

Granted it requires a lot of highly advanced hooking code among other things to actually work and not interfere with all of the varieties of complicated software out there. I was thinking an "Unrootkitme" may be the next real change as that is quite an advanced reversing challenge.

???
>>further there is the sit & analyze
do you want with out this??

hooks are done in memory(ya?). so you need analyze that memory.

>>trigger the driver to unload
our driver or rootkit?

If our driver unloaded > than infection detected!
If rootkit unloaded > that system unhooked! be happy & analyze HDD!

You raise good points - basically a rootkit cannot completely hide itself through a kernel mode dump. Wouldnt it be nice to have an automated way to verify every byte of kernel mode code sitting in memory on a live system?

Edit: Seems there is no such "perfect" rootkit.

actually, analyze is need for memory: IDT,GDT, NTOSKRNL.EXE HAL.DLL
image dumps need to be Back-Relocated to Base, than compare to files.

So I fired up Kernel Detective (fabulous tool btw) and found 4 ntkrnlpa.exe "Kernel Modifications" - is this normal? The IDT also shows modifications but it is hard to tell whether or not they are suspicious. Also if the tool is not able to load - what is the recommended debugging strategy?

The kernel modifications might be normal. Kernel Detective warns of some of the same "code hooks" as Rootkit Unhooker, and which I've found with Softice to be fairly innocuous.

http://www.woodmann.com/collaborative/tools/Rootkit_Unhooker


See here for example, both KD and RKU pick up a file-to-image modification which maps to KeFlushCurrentTb and which occurs normally during ntoskrnl initialization by Ki386EnableGlobalPage.

http://woodmann.com/forum/showthread.php?p=79078#post79078


Not to say that every unidentified kernel modification detected by these tools is "normal", they should definitely be checked, but unless reasonably suspicious they could be due to Windows itself.


Of course if you have a virus scanner/firewall you'll probably see several SSDT/SSDT Shadow/IDT/inline hooks, but most should be identified as such by these tools.

IDT/GDT modified? > then extract address & dump.

the tool is not able to load? > now you should need terrorize system as malware did!

Kayaker: that thread is excellent and explains one of the occurences. The other ones only listed by PD are probably "normal" in that they would appear on a standard up to date fresh Windows XP install. One was a ret (C3) -> nop (90) and another I think a ret (C3) -> partial instruction (00) making them look by OS design. It would be interesting to come up with a way to easily identify which ones are modified by the OS.

evaluator: RKU loads and works fine. PD does not load on one particular XP setup but I highly doubt there is malware. One thing I noticed on that machine is RKU shows a driver with no name that appears to be atapi.sys upon dumping it (does seem quite strange that it would be nameless). My systems also have 10-15 unknown interupt handlers on them - yes I could painstakingly dump and analyze each one but what the seperate problem of identifying the files that contain them (there must be a way to automate this)? From what you imply, unless the rootkit infects the BIOS, the "perfect" rootkit would have no choice but to hide in an administrative usermode most of the time.

What are the typical scenarios where unknown_irp_handler would be present for a given number of entries (at least some seem to have to do with file storage systems such as NTFS and CDFS)? Seperately, what causes shimeng.dll (Microsoft's hooking library) to hook GetProcAddress in explorer.exe? Is there a general guide to unwraping shimeng.dll hooks to find the real hook?

Any sorts of hooks will always be detectable, without some additional code to mask memory reads. I think I can say with pretty good authority and certainty that it is not physically possible to create a rootkit that does anything truly useful that cannot be detected. And i'm not even talking about offline analysis or using special hardware to do the detection. It may be possible to create a trivial rootkit that has no features other than stealth that is undetectable, but as soon as you start trying to do things like log keystrokes or communicate with other machines over the internet or local network you are going to have to do something that will give away your presence. However, it is certainly possible to develop novel routes of maintaining stealth and thereby evade all existing rootkit detectors, but ultimately it will always come down to a cat and mouse game.

The only possible pseudo-exception to the above is to create a rootkit that cannot be detected without de-stabilizing the system. If you could do that, then you might just be able to, in practice, evade detection on certain types of machines (e.g. dedicated web-servers or other machines that either cannot be shut down or would cost the owners of said machine a lot of money to do so and hence would make them unwilling to take the risk of running a detection scan that might crash their server).

Thanks for that darawk - I tend to agree with you. This applies to all OS too as I have read some interesting information about Linux kernel mode rootkits as well. So for Windows the best way to go undetected is to have Microsoft develop, sanction or at least sign a seemingly innocuous "trojan" DLL/SYS/EXE that would have the greatest chance of being undetectable. A DLL could even allocate memory in the process, copy itself into that memory, set the appropriate interfaces, unload itself and effectively remain hidden without comparing the entire install to one clean from the infection. This may seem obvious but the implications are not necessarily so easy to see.

That was my thought as well, BIOS/SMM/Hypervisor "rootkits" are pretty much POC of a certain level of stealth, but not much more, and/or are hardware dependant. To interact with the API they are likely to give away their presence at some point by some method.

The ShadowWalker concept can cloak the contents of memory, but is itself not fully hidden. Hypervisors have the potential to covertly control API's, but there is still the whole BluePill - "Yes they are detectable", "No they aren't" debate.

For the short term at least, botnets for the masses are likely to remain detectable

There is one other possible way to go about solving this problem, and that is to create no rootkit at all. I mean, what is a rootkit in essence? Something that allows you to maintain control over a machine once you have obtained access to it in some way(either by tricking the user, exploiting a vulnerability, or whatever). So, going on that, all we really need to do is inject a vulnerability into a permanently running and internet-accessible service. One way would be to patch the code in say, DCOM, to re-open one of the many now patched vulnerabilities that had been discovered a while back. Then, instead of having the command and control apparatus on each infected client, you maintain that apparatus on the controller's system, and it exists in the form of shellcode or shellcode that downloads, runs, and deletes some more complex application. Now, obviously simple code patching is very easy to detect, and it is just a simple PoC example of how this might be accomplished. But there are other things that can be manipulated at a very low level in the kernel, like say, manipulating some static NDIS buffers that are used in handling some extremely rare ICMP packet type to cause an overflow when they are accessed and used in the kernel.

Obviously the above methods have the limitation that when the machine is shut down, the 'rootkit' dies. But there are other possible, even more subtle reboot-resistant methods, such as changing configuration files, or maybe even editing the raw NTFS disk structure to, when requesting access to some specific file (like say on a web server), actually redirect the reads/writes to some important system file that can be used to take over the system. The possibilities here are really as expansive as is your imagination, and there are definitely some methods I have thought of that are resilient enough to work practically in a lot of real world challenges. If done correctly, it would be impossible to detect such a rootkit in a generic way. Obviously it will still be detectable if a rootkit detector specifically discovers and analyzes your specific system, but in this case, since the possibilities are so endless, and the primary coding work is done on the controller side, it is extremely easy to change the type of exploit that you use to maintain access, and this makes your rootkit much more potentially dynamic and versatile.

I disagree that maintaining control is a necessity of a rootkit - simply a hidden program. Would you want a program that does nothing loading and hiding itself? You can think of this in terms of our own health - there are viruses and infections people can get that have no realizable detrimental effects (like a tapeworm for a long while at least). Not surprisingly though, all my rootkit activity analysis always turn leads to bugs in software like AVG Free, random drivers for USB devices, etc. Conclusion about rootkits: without being able to fake memory reads, rootkits are just an insidious game that could potentially require a lot of tools to detect every generalized possibility though a BIOS/SMM/Hypervisor method is much harder to detect as black box methods have to be used.

Anyone agree that there is probably an official sanctioned Microsoft spyware out there that is tightly kept secret and would not set off any Antivirus alarms while seeming innocuous ? See KB666666 .

I think there's nothing perfect in the nature of things we create; there will be always a workaround, eventually someone will find out a solution. Nevertheless, a very stealth rootkit should perform two actions: what's inherent to its nature (obtain illegal access to private information and login credentials, etc.) covering itself in a layer consisting in a legitime OS/application function as a disguise to perform the malicious actions. I.E: some rootkit could consist in a tampered HTML render DLL from Mozilla Firefox, or an altered version alterada of the SSL/TLS v3 dynamic load library (ssl3.dll) to passively send login credentials to the attacker and gain access.

This could be a starting point to try achieving an advanced level in hiding rootkit's activity and presence.

Ideologies and pseudo wisdom are nice and all, but pertaining to the subject I think it'd be rustock.c, I've never seen anything more complex than it. It's only short coming was that it was partnered with a email based dropper; which is still effective, but AV vendors pick up on it quicker.

Kernel mode rootkits are pretty much dieing on NT though, because of signing. It's all going to userland. You don't even have to hook the native API calls or manipulate tables to avoid the best AV solution out their considering the best heuristics are cryptographic functions based on signatures with trivial detection of common native API calls; that's all 2009 AVs in a nutshell, and their supposed rootkit protection isn't much better compared to something like GMER.

My Rootkit(lazy version):

Propagation: Remote Code Execution and Social engineering via email
Remote Vector: MSRPC(with offset scanning and native process trampoline to avoid DEP and others) & SMTP Engine
Format: PE with TheMida 2.0.8.0(high complexity VM, anti dump, code replacement, IAT mutation, etc..)or VMprotect. Plus a DLL with the same(avoids static signatures plus unpacking plus the hassle of being a single entity writing a mutation engine and VM in a short time span)
Init: DLL puts a loader in a native PE then pretends to be a thread
Payload: collects emails and sends and scans for new vulnerable hosts. You can side channel SSL traffic or try to get into a low level keyboard interface if you want assets.

That's really lazy though. A cloak and dagger job would be a firmware based bootkit that exploits hardware virtualization architecture and spreads through a overflow in the tcpip.sys lookup table functions(any port=vulnerable even if it drops packets(it's on the local network stack with SYSTEM privileges, and infamous memory allocation functions are used in a lot in drivers, nobody dangerous is dumping key level code and analyzing it though))

Even if found by some researcher what are people going to do mail in motherboards? Also the best possible way to use networking from a rootkit is through DNS abstraction like botnets are using to hide control nodes, and I read about using native NT shell network calls to bypass IDS systems once like ones used by NET STAT etc...

The BIOS is the foundation for the ultimate malware on a IBM clone system. The MBR and H.A.L. on all operating systems have been tried and tested for decades, and can only make the process be a little harder to stop with packing algorithms, PE/ELF infection, and kernel hijacking, and maybe a RNG to do it all with.

Personally I can stop pretty much anything software based on a NT system with group policies, DEP, and driver signing. Which are post SP2 and default already on vista. Before that it was group policies and packet filters, and I didn't bother with stack defender or anything. My servers have always been openbsd and apache based with heavy use of gcc allocator security.