Unhackme

Right now, I am taking a look at Unhackme http://www.greatis.com/unhackme/index.html

I guess over time, through expirementation and reviews from others, I will find out just how effective this is in finding rootkits.

HMMM...Just looking over the features quickly, it seems to only detect Hacker Defender which is only the most popular rootkit out there. There are other rootkits that are equally dangerous such as FU. I am not sure if it detects other rootkits beside Hacdef,




Starrob

 

I just installed UnHackMe for grins and giggles. It said I was clean (now there's a surprise). I suppose private builds of rootkits are another issue altogether.
-

 

No trojans found

Jimbob

 

Not surprising, since the product doesn't scan for trojans. Can't quite imagine spending $20 on a product whose scan takes all of 2 seconds.
-

 

I too was wondering where the rest of the package was

Jimbob

 

It seems to be a gimmick to me. More likely than not, it can only detect the public version of Hacdef. It probably could not detect private builds and it does not say anything on the website about detecting other rootkits such as Fu or Aphex.

I have talked to a few AT companies in the past about rootkits and it seems that it is extremely difficult to design a rootkit detector that can detect all of the different ways for rootkits to disguise themselves. There are a myriad of ways to make things extremely difficult to detect.


Starrob

 

I would hope that they build some of this functionality into RegRun.. Interesting program, though, I wonder how many rootkits it can actually detect, and if it uses some of the same methods used in the free programs like VICE and RKDetector.

 

Hi All,

I need explain that UnHackMe is not the standard Trojan scanner.
It's used to detect Invisible Trojans (rootkits) only!
I mean the really invisible programs.
It's not the same when the Trojan masks as the legitimate program or uses runs as DLL or something else.
Use RegRun and you can see all that you need.

HackerDefender really hides its files, registry keys, ports, etc.
But HackerDefender needs to be restarted automatically at Windows startup.
It creates Windows service and driver.
If you know service and driver name, you can break the startup of Trojan.
Of course, Trojan hides these registry keys.
UnHackMe uses this fact. If Trojan hides the registry keys, UnHackMe searches for hidden registry keys.
You can't get it using Microsoft registry editor or similar programs because Trojan intercepts these functions.
UnHackMe uses another method.
It analyses the binary registry file on the hard drive.
It compares the list of keys received using standard functions and the list received from registry file.
It displays the results on the Results tab.
Now you can stop Trojan's service and remove hidden registry keys from registry.
After restarting of the computer you will see all Trojan's files and other hidden information.
More details:
http://greatis.com/unhackme/hackerdefenerremoval.htm

UnHackMe is valid not only for HackerDefender but for all other invisible Trojans.

Best regards,
Dmitry

 

Warm Welcome Dmitry

Thanks for coming here !!!


Best regards, Jan.

 

So, Rootkit Detector can also detect FU, Russian Rootkit HE4HOOK, NT Rootkit, Vanquish, WinlogonHijack, and all of the other Rootkits that are available for download over the internet??

Description of FU:

The FU rootkit can hide processes, elevate process privileges, fake out the Windows Event Viewer so that forensics is impossible, and even hide device drivers (NEW!). (Look, Mom, no hands!) It does all this by Direct Kernel Object Manipulation (TM); no hooking! This project has been evolving other time. It was originally conceived as a proof-of-concept. FU is a play on words from the UNIX program "su" used to elevate privilege.

It can really detect that? Also, can it detect private versions of these programs that are meant to be even more stealthy?

How come more than few security professionals have said rootkits are nearly possible to detect while running or that the different methods used to detect them could all be evaded once the method used to detect them is known. Is that statement true or not?

You don't have to explain the exact method but it your method of detection different from programs like Klister, Patchfinder, etc...that are already available on the internet?

If it is able to do as claimed then congradulations on putting out a tool that others deemed "impossible". I mean that sincerely and would keep such a tool if it could do as advertised.



Starrob

 

Not a problem.
Tomorrow I will reply the full investigation for FU and for other rootkits.

Best regards,
Dmitry

 

Its kind of a tool which needs to be packaged with others.

Jimbob

 

Welcome to the forum Dmitry, excellent work on your program there.

Starrob:

They are very difficult to detect when running, yes. "Impossible" to detect - well, in theory - only if it masks _every_ part of its existance ... and that is extremely difficult and has never been demonstrated before, it would require an intimate knowledge of undocumented areas of the kernel, and a heck of a lot of time. Like i said this has never been done before - there has always been some proof-of-concept detection program that has popped up which demonstrates a way to detect a particular rootkit, but those rootkits can then be modified to evade those detection methods - the anti-rootkit vs rootkit game is no different to anti-virus vs virus, it's pure cat and mouse, but in the case of rootkits, because they can alter the behaviour of critical kernel functions, they will always have the upper hand. If a scanner develops a new way to detect the rootkit, the rootkit can be updated to avoid that detection method. Even if the scanner has its own kernel-level code the rootkit could still intercept the execution of the scanner and modify it to prevent detection or prevent it from starting. This is why it's so important to stop rootkits from infecting your system in the first place, which was why we secured driver installation with ProcessGuard. It is now theoretically impossible for a rootkit to infect your system while ProcessGuard is running. Unhackme and ProcessGuard compliment each other well in this sense - one will check for existing rootkits, one will prevent you from getting infected by rootkits.

 

Nice program for these rootkits. This plus a few scanners is a good way to be more reassured for now that a system is clean of a lot of current rootkits using current hooking technology. Once it is clean you can be sure ProcessGuard will keep it that way. Knowing you are clean at ANY point is a great advantage

Disadvantages of any "scanner" no matter how it works, is that it can be worked around. Right NOW, its a good way to check for hidden services, which is where a lot of stealth malware does start from and hide itself with standard hooking or patching. The problem being, this is only useful for a specific type of malware which already exists and a useful comparison can be made between registry FILE and reported registry information via the Win32 API

A rootkit could simply lock read access to the registry files, at the filesystem. Would this be suspicious ? yes, in a way. Would it be a guarantee of a rootkit ? not really. Make sure it's clean then STOP any possible intrusion to be sure.

 

Thinking the same thing it seems..

Great topic for discussion. Other good detection methods exist, such as booting from a bootcd and comparing actual file existence with what the DOS prompt reports. This is probably the best method, but still requires on a list of files being taken in the hacked OS while it is running. Once malware is alive in memory, attackers who are experienced enough to avoid being detected will do so. There are avenues of attack to hide from even this in the future

http://research.microsoft.com/research/pubs/view.aspx?tr_id=775

 

Except for that little bit in the help file about disabling ProcessGuard when installing new software. That, and the inescapable fact that some software has a legitimate need to install drivers and/or services. So, how is a user--especially a novice user--to know what is legitimate, and what is not? Or, if s/he assumes the latter, and blocks everything, how does s/he figure out why the software doesn't work?

Seems to me that the picture isn't so rosy, even with ProcessGuard. Or, what did I get wrong here? Am I misunderstanding something?
-

 

nameless, without ProcessGuard you have no idea when any drivers of any nature are being installed, and you must also consider that drivers have much more power than .exe's - they can essentially modify anything on the system, including kernel areas of memory (which allows rootkit drivers to modify kernel functions to alter their behaviour). With ProcessGuard you will be alerted, and the driver installation intercepted so if it's a rootkit no infection can occur. If it's a trusted application (for example, Sysinternals tools often install drivers to perform low-level functions) then you simple allow it. Otherwise ProcessGuard has blocked it for you, in which case you should leave it blocked unless you find that you really do need it, in which case you simply unblock it. It's all very easy in practice

Anyway no more talk about PG, I was just responding to starrob's "I have talked to a few AT companies in the past" and mentioning PG was inevitable as you could understand due to its mutual complimentary nature to the Unhackme program.

 

Actually, I keep a close eye on everything that gets installed, and I always know when legitimate software installs a driver or service. But that's me. Most users aren't aware when drivers/services get installed, I agree. But if such software is installed maliciously and surrepticiously, ProcessGuard wouldn't help a typical user anyway, since, by your own advice, it would be disabled during the software installation. That's what I was getting at.

And the other point remains--unless you run a bare-bones system, without running much of any third-party software, you either have to by psychic (to know what to allow), or you're at risk (by allowing the wrong thing). How do I know that Sysinternals isn't installing a rootkit when I allow it in PG? "They're reputable." Yeah, fantastic, but how do you know that? And what about companies ABC and DEF? Either you run almost no software, or you take a risk and allow what you do want to run.

Whatever. I'm dropping off because all the cheerleaders are going to come toppling down on me any minute now.
-

 

If I am allowed to add a little thing:

I would not even think about putting ProcessGuard and NISFileCheck in the same league (oops, I hope that that is the right English word and expression...).
But isn't this a little bit the same as Joseph and I described in the NISFileCheck guidelines some years ago:
It is the user who has to decide whether a change in a file (new added, changed, or deleted) is legitimate or not....
Same of course for file integrity checkers like ADInf32 Pro and Inspector in KAV Pers Pro (using their so-called BIOS-call).

Anyhow, back to the topic: Unhackme.

 

Can I ask how you know when drivers are being installed?

There are several different ways to install a driver, many undocumented, and all of which are intercepted by ProcessGuard, but without ProcessGuard I can't see how you would ever know when they're being installed unless you use a monitoring program, and I don't know of any that monitor all of the known driver installation points other than ProcessGuard.

Wrong, wrong, wrong. I know what youre saying but before a driver is allowed to execute it must get past two layers of ProcessGuard security - first the user must allow the .exe to run (ProcessGuard also intercepts and secures file execution), and second it must allow the exe to install a driver, so to get infected by a rootkit you have to 1) allow its dropper to execute and 2) allow the dropper to install a driver. In other words, kernel rootkits cannot infect a ProcessGuard-secured system without twice obtaining permission from the user. Compare that with your current protection against rootkit installation - nothing. Checksum-scanning after the fact can be used to detect some rootkits, but by then you're already infected and who knows what else has been done - other non-rootkit trojans could've been dropped, and so on. Prevention is better than cure, so it's a bit strange that you're having a go at ProcessGuard yet not offering any alternatives or any other ways to actually prevent rootkit infection. Hmmm ...

Without ProcessGuard on your system you still face that same question anyway ... , but then you wouldn't even know that it was installing a driver in the first place. With ProcessGuard you will not only be informed about the installing of a driver (ie. giving itself the ability to go into kernel mode), you'll also be able to prevent it from loading if you so desire - it's completely up to you.

nameless, you probably use an anti-virus scanner ... you'll probably find that when it detects a virus you'll still be able to ignore the warning and allow it to run (most AV programs have a "Do Nothing" or "Ignore" response button). That is basically the same as ignoring the driver installation warning in ProcessGuard -- the program itself has done its job by alerting the user, it was the user who decided to ignore that warning.

At the end of the day, rootkit trojans need to install kernel-mode drivers before they can do their tricks - this is their Achille's heel, so if you can prevent driver installation then you can prevent rootkit infection. ProcessGuard has accomplished that (on the back of ~4 years of research & development) and is the only program to have done so.

Jan:

Spot on. Just as a PG user has to decide whether a driver being installed is legit or not, or a program being executed is legit or not, so must a NISFileCheck user decide whether a changed file is legit. It's basically the same - an integrity-based warning, alerting the user to make a decision based on the fact that something _might_ be wrong. It's better than knowing nothing

 

I think I might be very interested in Unhackme as long as it is actively developed to counteract the eventual attempts to evade it.

I am not totally sure yet...just expirementing but a combination of PG, Regrun and Unhackme might be extremely difficult to break through.

If Unhackme can also take care of other rootkits besides Hacdef then it will indeed be valuable. I know nothing can be 100% but if it can detect a good majority of rootkits then it will be better than nothing.


Starrob

 

Yes indeed it would be due to so many layers of protection - the more the better.

 

Having downloaded and run the trial version of UnHackMe, no infections shown & I do like the simple interface.
As others have said I would also be very interested to know how many rootkit families / variants UnHackMe can detect.

Regarding ProcessGuard, the only time I disable it is for major patches from MS such as SP2, for all critical updates I leave ProcessGuard on, as I also do for loading other programs, I then adjust the blocks & allows as necessary.

Anyway congratulations Dimitry & DCS for trying to address very complicated issues where others have feared to tread.

As has been said many times before there is no such thing as 100% security and that user education is one of the prime aims of these forums, the biggest hole in most ppl's security sits upon their shoulders, all we can do here is to guide users in the most positive way to security awareness, using the tools that become available to us.

Cheers. Pilli

 

I would like to mention that Unhackme is not totally new. The useful "search for hidden regkey feature" is already available to users of Heinz Ulbrich's RegdatXP. (I asked him to implement it a couple of months ago.)

I seems that Unhackme will nicely compliment Process Guard because you cannot entirely rule out that you will allow the installation of a kernel-mode rootkit (despite the fact that Process Guard will show a "driver installation" alert). This is because certain software requires the installation of drivers (e.g., software which uses SVK Protect for copyright protection, low-level software like firewalls, av scanners, certain registry defraggers etc.). If such software is compromised (i.e., bundled with a rootkit) you will probably ignore PG's alert and install the driver because you _think_ that it belongs to a valid application. Obviously, the above situtation is unlikely to occur if you do not use software obtained from untrustworthy sources.