Robert Hensing's Blog

Software Security . . . and stuff.

Blogs

Rootkit Revealer vs. Hacker Defender - How the miscreants are defeating Rootkit Revealer and how to fight back

  • Comments 27
  • Likes

So over the last week we've started to get cases where Rootkit Revealer (having been downloaded by the customer) is not detecting any hidden files / folders / registry entries on the customers machine; yet our own rootkit tools we supply with our IR toolkit come back with hidden files / folders etc. and have no problem detecting evidence of a rootkit.  Why the discrepancy?  After all Mark's tool works very similairly to some of ours which have worked fine for years . . .

We decided to investigate and collected some specimens and it turns out that Rootkit Revealer is rather easy to defeat if you're using the Hacker Defender rootkit.

Background:
The Hacker Defender rootkit supports configuration through an INI file.  The INI file has numerous sections in it that govern the behavior and operation of the rootkit / backdoor (just like a normal INI file would) and one of the sections that the miscreant can configure is entitled [Root Processes].  Here's an explanation from the readme file that comes with the rootkit:


Root Processes is a list of programs which will be immune against
infection. You can see hidden files, directories and programs only with these
root programs. So, root processes are for rootkit admins. To be mentioned in
Root Processes doesn't mean you're hidden. It is possible to have root process
which is not hidden and vice versa.

Here's the default settings for this part of the .INI file:
[Root Processes]
hxdef*
rcmd.exe

Here's how Hacker Defender (hxdef) works.  When the main .EXE is run - a device driver is extracted and code is subsequently injected into all running processes on the machine and the various user mode Win32 API's listed in the readme file are then patched / hooked / detoured over to the rootkits code so that filtering can be performed etc.  Root processes are immune to this however; when they start, they do not get hooked in any way - so they can 'see' all that would normally be hidden by the rootkit.  The miscreants of course are all too familair with the operation of hxdef (I stand by my assertion that this is by far the most popular 'in the wild' rootkit with the biggest installed user base) and many seem to have added 'rootkitrevealer.exe' to the Root Processes section of the .INI file.  Since rootkitrevealer.exe is a root process; it can see all the files / folders / registry entries that hacker defender is hiding and thus it does not flag them as hidden.

This is just another great example of the arms race we are locked in with the miscreants (some call it a cat and mouse game - but that's far too innocent; I personally am at war with the miscreants and this is my arms race).

Advice:  If you're going to download and run Rootkit Revealer (and I encourage you to) - make sure you rename the .EXE to something unique, be creative.  If you need a random file name use the random number generate from www.random.org or something like that and make the file name long and random.  You'll have much better success - until the miscreants counter this move and fire back with something more technically advanced.

Comments
  • SysInternals could generate a random name as well I suppose, at the cost of convenience to the user. If they did so and generated a rootkitrevealer.lnk shortcut from which to launch it would that be traceable by hxdef?

  • Hey Larry - glad to see you're still keeping an eye on me. :)

    Sadly this will not work. So I think if I understand you correctly you're saying that the main exe (rootkitrevealer.exe) would actually become a 'stub' .EXE that extracted an embedded EXE and give it a random name and then launch THAT process to do the scan?

    If so this approach won't work becuase since the stub .EXE is still called 'rootkitrevealer.exe' and its on the 'root process' list for hxdef, it will never get 'infected' by the code hxdef injects into processes that it wants to hook; since it is not 'infected' it won't infect any child-processes that it spawns as a result - thus the randomly named main .EXE would be clean as well.

    I haven't given the solution much thought - but I don't think we're going to be able to start the process off using a well-known name.

  • I think what Larry is suggesting is that the SysInternals executable get installed as <random-file-name>.exe, but a shortcut be installed on the Start menu or Desktop called "Rootkit Revealer.lnk". The process starting up would never be RootkitRevealer.exe. This might get around the root process defense - for now.

  • hehe then some one could md5 the renamed crap and give it root access so it still wont detect any thing as hidden coz it doesnt rely on name now you make a lodaer and add random
    bytes at the end of section and change md5 and
    run it they willl start scanning the system for pattern

    good cat and mice game all depends on the ingenuinity

  • We lost some comments yesterday due to a 2-3 hour downtime as my blog got moved over to blogs.msdn.com (did anyone notice the redirect?). Sorry if your comment was lost and didn't make it here - nothing I could do about it and I didn't remove it.

    This last comment is accurate. If we start doing the random file name thing - the miscreants will inevitably start using MD5/SHA-1 hashes to spot processes to not hook / hide from. Then we can start changing the MD5/SHA-1 of the file dynamically at runtime before it runs using a variety of techcniques - this would be harder to counter as it would force the miscreants to look for a series of bytes that form a pattern that is unique to the anti-rootkit tool they want to evade.

    Definitely an arms race (not a cat and mouse gaem). :)

  • Hi,interesting article so i thought you might like to know that ive got a thread going over at Wilders called - RootKit Detection Treasure Trove - which you may like to take a look at and follow, and/or even better hopefully contribute to if you wish.

    Regards,

    Spanner

    http://www.wilderssecurity.com/showthread.php?s=42b535346d2a74d87aca95b5200d863f&t=69658

  • I did not even think of the MD5 step, good point.

    I did think that it could be possible to have a service on the rootkitrevealer web site, that would use a customized compiler to compile that rootkitrevealer, inserting for example a lot of random NOPs all over the machine code in the exe. This could maneuver could be perhaps circumvented by disregarding NOPs when looking for the rootkitrevealers signatures. But I am sure there's solutions to this too ;)

  • "If they did so and generated a rootkitrevealer.lnk shortcut from which to launch it would that be traceable by hxdef?"

    I found Larry's above comment to be very interesting, and in some ways, exemplify the status of Windows incident response. I say this not to be mean or to find fault, but to point something out.

    As responses to the quoted comment have indicated, the method of executing a process aren't included in the process information; take a look at the documentation for the Win32_Process WMI class, as an example. There's nothing that indicates that a process was launched from a link or shortcut.

    Methods of detecting RootkitRevealer running would include (as pointed out) checksumming the executable image, maybe searching the executable image for particular strings, etc.

    But about Larry's comment...I see this a lot of time in presentations and courses...rather than trying something for themselves, learning and discovering on their own and then sharing that info, lots of folks out there just throw questions out like "what if..." or "what happens if..." without really giving the question itself a great deal of thought.

    Again, this isn't a bad thing necessarily, but I do believe that it shows an underlying trend in the field of incident response as it applies to Windows systems.

    Am I an expert? Hardly. Am I being high-and-mighty? Not at all. I am not saying that I'm better or smarter than Larry or anyone else. In fact, I'm not even singling Larry out. All I'm saying is that his comment is indicative of the mindset one sees posting to public sites. I think we all...security weenies...need to keep this in mind when addressing complex security issues such as rootkits. After all, the "bad guys" know this, too...

  • To make this manageable and figure out what the next move in the war is going to be - we need to identify all of the ways that a rootkit (a process / driver running on the system) could be notified that a new process has started and then what the rootkit would do with this information.

    Running the anti-rootkit tool as a service, or from a shortcut / .LNK etc. isn't meaningful - you have to look at what happens under the covers and what's happening under the covers is you are making a call to CreateProcess() or CreateProcessAsUser(). These are doc'd on MSDN. And when I say 'you' I mean 'the shell' (Explorer.exe in the case of a shortcut) or CMD if you are running it from the command line.

    So how would a rootkit know that YOU via some other process are trying to start an anti-rootkit tool? Simple - hook these API's and whenever they are called in any process - do something interesting like check the file name the API was told to start or check the signature of the file the API was told to start, or scan the binary it was told to start for a sequence of 'interesting' op codes that would indicate it's an anti-rootkit tool.

    Maybe the rootkit will operate at a lower level and wait for the process to show up in the PsActiveProcess list in the kernel and then take action then without doing any API hooking up in usermode?

    maybe the rootkit will operate lower still and wait for the threads for this process to show up in a thread list?

    Maybe the anti-rootkit tool creates some global named object that the rootkit can watch for in the object manager namespace and when it sees it do something interesting?

    These are but just a few ideas I came up with that may be inevitable 'next steps' for the rootkit writers.

    What's needed is a threat model to identify all of the next moves in the game of chess and to plan the counter-moves accordingly. :)

  • Robert,

    Good ideas, all...most definitely.

    Along with that, I would throw out there that we also need to keep pushing intrusion prevention, not just detection. Setting up intrusion prevention is like the scene in "Mission Impossible" where Tom Cruise crushes the light bulb in his jacket, and spreads the shards out on the floor...anyone stepping on one of the shards is going to create noise...

    (Sound familiar? Yeah, I know...it's in my book...)

    Using many of the methods of intrusion prevention that have been documented, some for years, I think we can make a great deal of headway.

    Looking at detection measures is also important. How do we look for rootkits, so that we have hard facts to go one, rather than speculation (re: my previous comment about the state of Windows incident response)? What road might the rootkit authors follow next?

    H. Carvey
    "Windows Forensics and Incident Recovery"
    http://www.windows-ir.com
    http://windowsir.blogspot.com

  • I read the interesting articles about RK's etc. So i thought you might like to know that i've got a thread going over at Wilders called - RootKit Detection Treasure Trove - which you may like to take a look at and follow, and/or even better hopefully contribute to if you wish.

    Regards,

    Spanner

    http://www.wilderssecurity.com/showthread.php?s=95908884f62ac79cc539f5af10599a2a&t=69658

  • For Robert:
    " what's happening under the covers is you are making a call to CreateProcess() or CreateProcessAsUser()."

    Some Intrusion Prevention Systems also hook these and think that they can flag what's happening.

    "These are but just a few ideas I came up with that may be inevitable 'next steps' for the rootkit writers. "

    -Why do you think rootkit writers are the one tooking next steps and not you? On your list you just talk things which are years old.

  • Sorry - this doesn't solve the problem. You are trying to solve a software problem using other software. The prompt displayed to the administrator to allow writes? Why wouldn't the rootkit just hook that to allow its writes to occur?

    Unfortunately - once a rootkit is installed on a machine - the game is over, it owns the machine now - not you. If you want your machine back, with confidence - you should rebuild that machine.

    This is a challenging problem to solve effectively - we are working on some things with the Next Generation Secure Computing Base that will probably utilize a combination of hardware and software to try to address this problem.

  • Thanx for dropping by the other day Robert !


    I would like to suggest some possible ideas on how it may be feasable to prevent RootKits from EVER gaining access in the first place. I acknowledge i'm Not an expert in the field, just someone who takes an interest in the subject !

    Maybe you've heard the expression ( not being able to see the woods for the trees ) because some people are heavily involved in so many aspects of a particular project and concentrating Very deeply in a linear fashion. I DO fully appreciate and understand their dedication and hard work and take nothing away from them at All !

    Now Don't anybody take this the wrong way at All, but as i'm not engrossed in the minutie, i see things from a different perspective. More akin to standing back and seeing an overview of the problem. So on that basis i submit the following -

    A - The root section of a hard drive could be made to switch over to read only after the initial OS installation on a fresh HD. Some method could be devised whereby the user and/or admin would be required to authenticate an allow a Root write. Requests for Root write could be saved to a reserved scalable area RSCA of the HD and put in a queue. So these would not be lost, and also in case of a HD crash etc they could be retrieved on reboot. At the end of the session/day and/or intermittently at some selected interval, a prompt box could appear asking to valididate and give permission with an encrypted password for the Root write. How this would work in practice i leave to others, as i said i'm No expert, but i feel that something along these lines Could be achieved in some way. The RSCA would be similar in principle to the swap file area we already have.

    B - The RSCA and the Root area Should also be encrypted strongly. This would mean that NO unauthorised access could take place, EVER, and therefore the Root could NOT be tampered with in Any way. Any and All copys of the Root area would also be protected in a similar way. No more RootKits, problem solved ! - http://www.wilderssecurity.com/showthread.php?t=69658

  • Spanner-
    If you store the OS on a CDROM and boot from it, you have yourself a read-only partition implemented in hardware. (It's been done on occasion.)

    However, even with such a setup, the system could be 0wned. Most likely the rootkit would be wiped out by a reboot, but the original vulnerability could be exploited again until you patch the system and burn a fresh CD.