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 processwhich 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.
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.
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.
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.
<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 az
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 Normal.dot 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.
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.
PingBack from http://stephanie.freetimesmedia.com/howtofightanoncompete.html