A comparative : 10 HIPS against 'brutal unhooking' malwares

I'm actually quite disappointed that they need NicM's test of in-the-wild malware to realize they were vulnerable.

None of the techniques are really that new, and if you believe their feature list, most of them should have handled it 100% without problems. This merely points out to the fact that while feature lists are nice, you also need to look at the quality of implementation, clearly a lot of them have bugs in the implementation.

I'm surprised that people like Easter who claim to give HIPS brute tests have not come across any weaknesses at all according to them. One suspects that there are a lot more problems in HIPS just that no one is really borthering to test it properly. Instead people ask for more and more features and the code just gets more and more bloated and more bugs creep in.

 

I did not mean to imply you were bashing anything. I was trying to say that some tests seem concerned with bashing more than testing. And NicM's test was only about testing.

 

That's because i normally been content to replacing SSDT Table displacements given back over to SSM. To be frank, i had no idea unhooking hooks could be repeated infinite times over again, and since i'm no specialist in super coding i never gave any thought that a malware unhooker could repeat their stripping of those HIPS repeatedly but then we all live and learn when it comes to someting as intricate as microsoft "undocumented" risks.

 

Vey well said.

 

Thanks NicM for the test as it has opened some eyes. I'm also glad that the one I'm using, OA2 did well . What Lusher stated is true. Why did a test like this have to spawn action among the developers. I'm totally ignorant to malware so I trust that my anti-whatevers and HIPS know more than I do, or at least implement their protection correctly. This is why I run a layered setup as I don't want to depend on 1 app to cover my A$$. Thanks again NicM and I hope to see more tests like this (not necessarily from you) as it appears to stimulate improvement, growth and interest.

Cheers, innerpeace

 

Touché. There are some applications that are worldchampions in running behind the facts (I'm not referring to HIPS proggies in particular). and seem to only become aware of flaws in their proggie by a test on this (or another) forum.

As far as I can remember this is the first time SSM is "caught in the act".

 

Fully agree. It is really a shame for SSM & others. All the more if you realize that the protection against this kind of attack, which allows ProSecurity to perform so well (as nicM pointed out in post #40 in this thread), was added in PS version 1.20, released 12-Oct-2006.
It is not just this 10 months period which makes the whole issue so disturbing. It is also the fact that without nicM's test nobody knows how many more months would have passed. Months with a gaping hole in the protection that would allow malware to completely and silently turn off the whole HIPS.
As far as I know the mentioned debugging technique which is used in these attacks was discussed ~1 year ago in malware forums. So I would consider this as public knowledge since then.

 

And even though I favour PS over SSM, I wouldn't just single out SSM, just cos PS did okay in this test doesn't mean it is 100% secure, chances are if someone runs another tests PS might fail that too but maybe SSM might pass.

In fact ,in every serious formal test on HIPS (and there are precious few), pretty much few or no HIPS score 100% and most fail at least partly or totally.

The fact is nobody does enough tests really, we just take it on faith they work as advertised, or listen to hype from people who blow hot air about how they conduct "intensive technical research analysis" (with no evidence) and how they are sure HIPs makes them unbeatable. Thank God for people like NicM who don't feel the need to blow hot air, or put silly titles in their signatures, but just quietly produce all the work. It's not so much that you have to be a super guru to do the tests but it is very very detailed work and takes a lot of time and effort to do it methodically.

Yes, I'm getting sick of those people who only ability is to talk on paper, about kernel hooking , layers or in analogies about motion detectors and whatnot. All nice on paper, and very impressive to a newbie but the reality is they can't tell us if the HIPS is really working as promised.

Indeed. And this is public knowledge stuff, what about the really nasty stuff that is kept secret? Sure chances are you won't get hit by them, but I really don't like people making BS about HIPS.

I support HIPS. But I'm opposed to overly hyping it. And yes i believe in layers, but I don't accept that failure in this test is okay cos you have layers. That's just a lame excuse.

 

I have no idea what you said. No doubt it takes someone to be a "INTENSIVE TECHNICAL RESEARCH ANALYSIS AND STEALTH EXAMINER" to decipher what you just said.

 

Yes me too, I think that if you´re building a HIPS you just have to know and keep on learning about most malware techniques which are used today, and which may be used in the future, you have to be on top of things! Btw, @ NicM, don´t forget to test the new Neoava Guard, the version that´s out now will probably not pass most of the tests, but a newer version with more protection options is out soon.

 

It makes perfectly good sense to me -- all except the explanation, of course.

 

I could not either, but GesWall also could block the nag screen lanched by avnotify. The problem solved itsef, because antivir's update did not come through anymore (Holland is in the same time zone as the developers). Now we are using Avast one one PC and AOL's KAV on the other.

Regards Kees

 

Nicm,

Just see what you did, two aps had better defense in their next release, others are promising to improve soon.

So you single handed made this a safer digital world. THANKS

This behavior of security aps, increases my belief that in general it is a good approach to have the most tested programs on board. Due to the image damage on ot passing tests, those (much tested) programs are often a good choice, despite the stories of program x failing test y.


Regards Kees

 

The results are not clickable. None of the links are.

 

I have no problem at all clicking on the results links.

Did you check your browser settings?

 

Hello,

These are interesting tests, but one point is unclear to me.

To unhook kernel-mode hooks, you should allow the rogue driver to
install and load. So in your tests, did you enable in the various HIPS the
driver installation protection ? If yes, did you willingly allowed the rogue drivers to install when the HIPS asked you or did the trojans used undocumented driver loading methods, bypassing the HIPS hooks ?

If you "allowed" the driver install, then you should really clearly write it in bold, that the user must allow the initial rogue driver installation, for his HIPS to be disabled.

Thank you.
Regards,
gkweb.

 

Wrong. There are some ring3-based methods to unhook SSDT.

 

And ? Was it only that kind of unhooking used in these tests ??
I'm sorry but it is still very unclear, you only answer a general statement, and, thought useful, does not address my primary question.
Also, if you could explain a bit how a user mode action can modify kernel mode hooks, without loading anything in kernel mode,
it would be quite interesting for anyone (including myself).

The author should write clearly if the unhooking methods used drivers or not.
If yes, if on one hand driver protection was enabled, and on the other hand if he allowed them or if the trojans used undocumented methods to load a driver.

My questions still stand

Regards,
gkweb.

 

There are ring3 and ring0 unhoking methods. Ring0 is requires driver loaded, ring3 is using some advanced techniques (like PhysicalMemory object access, for instance).

 

Hmm yea, I know the \Device\PhysicalMemory object, I was just thinking until know that you could only access it through a driver (I'm not a kernel coder, so could never checked). However you are right, it can be accessed from user mode, with the condition of the current user account being part of the Administrator group ( I am under a restricted account, that does not scare me ). Thanks for correcting that point.

Now, only last my first questions.

Regards,
gkweb.

EDIT : PhysicalMemory object cannot be accessed under Windows XP 64bits, Windows 2003 Server SP1, and Windows Vista. So it applies only to Windows 2000 and XP 32bits (provided the OS are up to date).

 

What question?

 

@Ilya Rabinovich

Regards.
gkweb (using another account from work).

EDIT : from the original link (Emphasis is mine) :

 

Hi everyone,

And Thanks for the feedback.

Just replying quickly to a few comments,

Yes, page is not written yet, but it is in the next update .

Hmm, I know, happened to me too (probably due to some Lycos stuff). Just try to refresh the page, links will be back.

gkweb, your question is interesting, and this is an occasion for me to make few points more clear : I've noticed that there was some misunderstanding about the tests methods used. When making a test with a HIPS, one shouldn't expect the impossible : For this reason, a prevention test where a driver loading is allowed is useless, since a driver can potentially bypass the whole protection offered by the HIPS. It doesn't always do, but can do.

What was tested for several of the trojans here was the effective ability of the HIPS to prevent the driver loading : Just because as you have seen, sometimes a program can detect a driver loading...but is unable to prevent it in fact. Nuance.

However the main subject of these tests are unhookers. Among samples used, there were 2 kinds : Most of these sample perform the hooks restore without to need driver. There was just the rootkit Agent.ey 1st sample, which performs the unhook only once its driver is loaded (less interesting, provided that the subject of this test is merely to check the program's ability to prevent this driver install; once driver is loaded, it is "too late" - though some programs revealed interesting features in this regards, like DSA, thanks to a clever use of user-mode hooks.

So, to reply to your main question, no, driver install were - of course - not allowed. What happened is that, for programs which prevented unhooking, the driver install attempt was visible, and could be blocked (program still active). Whereas for programs which failed tests, driver install was "stealth", impossible to block : There was no way to prevent, allow or deny it, since the program tested was dead, after successful unhooking.

Thus, driver install were not allowed - when it was possible. Most of the samples are not running in kernel at the time they perform the unhooking : Quite, they unhook before to undertake driver loading. That's what make them 'bypassers' : Not that they are using undocumented methods to load their drivers, but they just try to disable the driver loading protection first (by unhooking, HIPS killing, etc ), in order to 'make sure', or at least to increase their chance that driver will load.

I hope it does adress your question. Your quote can sum it up, used on the affirmative mode : "user mode action can modify kernel mode hooks, without loading anything in kernel mode". (though physical memory access is eventually another way to access kernel).

Cheers,

nicM

 

Hello Nic,

That is absolutly my point, that's why I thought so much important to make it clear if driver loading were allowed or not

That perfectly answers to my questions. Your tests are therefore very relevant and done in a logical way. While reading your tests, I was looking at this information but couldn't find it.

As a reader, we are all looking at different kind of information, and it's difficult to make an article to fit everyone's expectations. Nevertheless, I think it would be great to add somewhere that HIPS's driver loading protection was enabled, and that driver loading requests (if any) were denied.

Also, I find that your tests are giving usefull information as a side effect of your methodology : number of hooks per HIPS. I would have liked to see a table, sorting the HIPS per number of hooks. It's not relevant for your tests and your conclusion, as the number of hooks does not indicate the effectiveness of an HIPS, but still is a valuable information. Of course that is just my opinion, that would just be a bonus.

In conclusion, great work Nic on these very interesting and unique tests

Regards,
gkweb.

 

Any news on this? Have HIPS like Sandboxie, DefenseWall, SafeSpace and Neoava Guard (to name a few), already been tested?