Page 1 of 2 12 LastLast
Results 1 to 15 of 19

Thread: The Perfect Rootkit

  1. #1

    The Perfect Rootkit

    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?
    Last edited by Snatch; May 7th, 2009 at 23:58.

  2. #2
    do you mean windows?

  3. #3
    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.

  4. #4
    Musician member evaluator's Avatar
    Join Date
    Sep 2001
    Posts
    1,479
    Blog Entries
    1
    >>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!?

  5. #5
    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.

  6. #6
    Musician member evaluator's Avatar
    Join Date
    Sep 2001
    Posts
    1,479
    Blog Entries
    1
    ???
    >>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!

  7. #7
    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.
    Last edited by Snatch; May 10th, 2009 at 06:53.

  8. #8
    Musician member evaluator's Avatar
    Join Date
    Sep 2001
    Posts
    1,479
    Blog Entries
    1
    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.

  9. #9
    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?
    Last edited by Snatch; May 9th, 2009 at 02:18.

  10. #10
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,114
    Blog Entries
    5
    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/index.php/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.

  11. #11
    Musician member evaluator's Avatar
    Join Date
    Sep 2001
    Posts
    1,479
    Blog Entries
    1
    IDT/GDT modified? > then extract address & dump.

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

  12. #12
    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?
    Last edited by Snatch; May 9th, 2009 at 07:18.

  13. #13
    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).

  14. #14
    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.

  15. #15
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,114
    Blog Entries
    5
    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

Similar Threads

  1. Amr Thabet: Reversing Stuxnet's Rootkit (MRxNet) Into C++
    By Silkut in forum Malware Analysis and Unpacking Forum
    Replies: 4
    Last Post: February 6th, 2011, 08:19
  2. Rootkit Analytics
    By Kayaker in forum Advanced Reversing and Programming
    Replies: 0
    Last Post: March 19th, 2009, 12:02
  3. Rootkit.Win32.TDSS.eyj Another custom packer/cryptor
    By Cthulhu in forum Malware Analysis and Unpacking Forum
    Replies: 3
    Last Post: February 6th, 2009, 17:25
  4. Question about Rootkit Unhooker
    By WaxfordSqueers in forum Malware Analysis and Unpacking Forum
    Replies: 15
    Last Post: February 1st, 2009, 23:06
  5. Rootkit Revealer
    By Silver in forum Tools of Our Trade (TOT) Messageboard
    Replies: 6
    Last Post: March 23rd, 2005, 18:55

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •