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

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.

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]

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 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 (22)

Cancel reply

  1. Anonymous says:

    <p>&lt;ul&gt;&lt;li&gt;Akinek nem tลฑnt fel, &lt;a href=&quot;node/173&quot;&gt;szavazás&lt;/a&gt; folyik éppen&lt;/li&gt;&lt;li&gt;&lt;a href=&quot;; target=&quot;_blank&quot;&gt;MSN Messengerrel keresés az

  2. Larry Seltzer says:

    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?

  3. Robert Hensing says:

    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.

  4. 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.

  5. md5 hash = 11234567890abcdef (is it long enough to says:

    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

  6. Robert Hensing says:

    We lost some comments yesterday due to a 2-3 hour downtime as my blog got moved over to (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). ๐Ÿ™‚

  7. Spanner intheWorks says:

    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.



  8. zzz says:

    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 ๐Ÿ˜‰

  9. H. Carvey says:

    "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…

  10. Robert Hensing says:

    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. ๐Ÿ™‚

  11. H. Carvey says:


    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"

  12. Spanner intheWorks says:

    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.



  13. Han Solo says:

    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.

  14. Robert Hensing says:

    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.

  15. Spanner intheWorks says:

    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 ! –

  16. Requiem says:


    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.

  17. Spanner intheWorks says:

    Robert, Sure i understand what you’re saying, but you can see the way i was thinking, by trying to look at the problem the way i did.

    At some future point though i can envisage HD’s and other storage devises having some kind of Root etc. protection built. Possibly similar to what i proposed. It seems other precautions etc would also need to be built in to the Total System to accomplish Full ( ish ) security !

    Requiem, Yes it does appear that some people have adopted this approach with some success.

    Well here’s an additional idea to compliment my intial ones.

    How about if ALL computers from now on have at least two HD’s etc. One with the OS on and the other/s with programs/files etc. I don’t just mean how it could be done today, but with mine and other peoples ideas incorporated into this new Split System Architecture – SSA.

    Again ways of combatting interaction between the two or more storage devices would have to be overcome. But i Really do think it’s worth considering and researching even further.

    Kind Regards,


  18. edward says:

    The difficulty in discovering rootkits comes because they are hidden from the standard APIs. The issues here is the rootkit is deliberately not hiding itself from a specific process.

    Instead of worrying how to disguise the process so that the rootkit does hide from it, why not just use standard detection routines to detect the non-hidden files and registry keys? If anything its a benifit that it is no longer hidden.

    Just combine the properties of a rootkit detector and a standard malware scanner into one process, then it doesn’t matter if the rootkit is hidden or not, it will get spotted either way.

    You are back to looking for specific files, keys and processes in order to identify malicious code, no just the presence of hidden files, but the rootkit itself is using similar techniques to decide to hide/not hide from the process.

  19. Robert Hensing says:

    So what you seem to be proposing is adding <insert virus scanner here> to the ‘root process’ list for the given rootkit so that the virus scanner doesn’t get its API’s hooked, thus it can see the rootkit and the files / folders its hiding and clean / remove them?

    This would be a great idea if the virus scanners were able to compete in this space – but they are, sadly, not.

    Virus scanners work best when confronting just that – viruses. Viruses are known threats, that can be studied and signatures can be updated for.

    Even viruses that mutate through some algorithm can have signatures developed becuase the researchers can study that algorithm and build signatures that defeat it.

    Custom rootkits that are mutated by a *person* (not an algorithm) to avoid antivirus detection are a whole different ball of wax.

    Holy Father on his web site sells ‘undetectable’ versions of hxdef for a fee. What do you think that means? It means he takes the hxdef binary and he manually tweaks it by hand or with tools he’s created until it is different enough that it can evade the signature based detection used by all of the AV vendors.

    Check out this URL:

    It looks like he’s even added anti-detection for ‘rootkit detector’ – an anti-rootkit tool.

    I’m sure if someone is willing to pay him to defeat Rootkit Revealer and other tools – he will apply some sustained thinking here and come up with a solution.

  20. Karl Levinson says:

    Spanner: making the files on the hard drive read only does very little to prevent malware, neither now or in the future. As an example, people in the mid 1990s made the MS Word read-only to try to prevent Word macro viruses. We found that word macro viruses still spread just as fast. Word would be virus-free when it was shut down, but when re-opened, the user would open an infected document and immediately be re-infected, spreading viruses to other files and users. Technically speaking, the virus was not able to load persistently; and yet MS Word was still persistently infected 95% of the time it was running.

    Robert – I see no reason why anti-virus programs or *suites* are not able to compete in the anti-rootkit field. AV programs have had non-signature-based heuristics and sandboxes for a long time, as well as detection for Trojans that are more similar to rootkits than to viruses. And now more generic features are being added that have nothing to do with signatures, such as AV that monitors outgoing requests on TCP 25 and alerting on x number of requests in Y period of time. Even if you argue that such functionality can’t be added to the on-access scanner without causing too much latency, the AV companies are now making security suites that will include or could include on-demand rootkit scanners.

    It is ideal to have a product that combines signature-based, heuristics and anomaly detection a la sysinternals rootkit revealer… because if Hacker Defender tries to trick a product like rootkit revealer by not hiding, then the signature-based scanner that is running in the same "context" would then easily pick it up. This further raises the bar for rootkits.

  21. Spanner intheWorks says:

    Karl, i wasn’t though suggesting making all the Files read only, but rather as i said the Boot area and Any copy/s of this on the HD. Also that these would be encrypted too. If this could be accomplished by some means, maybe as yet untried, then this would enable the Boot area to be protected from RootKits etc. I do still think it’s worth considering, and exploring by someone more skilled in the art than i am.

    Also if Files/Programs etc can’t be made read only in some way/s, then if Every App/File etc on a computer had a Md5 or PGP etc signature as already mentioned in this thread, then that might help too, as you yourself go some way to suggest.

    There is an App i listed recently over in my Wilders thread, where i have replied further to your input, – NOTIFY 1.00 – that looks Really useful in alerting users to unusual changes etc.



Skip to main content