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.
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
Anonymous
January 01, 2003
<p><ul><li>Akinek nem tűnt fel, <a href="node/173">szavazás</a> folyik éppen</li><li><a href="http://secretgeek.net/insideC_part2.asp" target="_blank">MSN Messengerrel keresés azAnonymous
January 01, 2003
PingBack from http://stephanie.freetimesmedia.com/howtofightanoncompete.htmlAnonymous
March 10, 2005
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?Anonymous
March 10, 2005
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.Anonymous
March 11, 2005
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.Anonymous
March 12, 2005
The comment has been removedAnonymous
March 12, 2005
The comment has been removedAnonymous
March 13, 2005
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=69658Anonymous
March 13, 2005
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 ;)Anonymous
March 14, 2005
The comment has been removedAnonymous
March 14, 2005
The comment has been removedAnonymous
March 14, 2005
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.comAnonymous
March 16, 2005
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=69658Anonymous
March 17, 2005
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.Anonymous
March 18, 2005
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.Anonymous
March 18, 2005
The comment has been removedAnonymous
March 19, 2005
The comment has been removedAnonymous
March 19, 2005
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,
Spanner
http://www.wilderssecurity.com/showthread.php?t=69658Anonymous
March 21, 2005
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.Anonymous
March 21, 2005
The comment has been removedAnonymous
March 24, 2005
The comment has been removedAnonymous
March 25, 2005
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.
Regards,
Spanner