Classical HIPS and policy based HIPS discussion

All the following registry keys it uses should be protected by HIPS rules:

Table 2 – Possible Installation Paths

http://www.welivesecurity.com/wp-content/uploads/2014/02/corkowtable2.jpg

 

@Rasheed187, I want to return to this link: http://nagareshwar.securityxploded.com/2014/03/20/code-injection-and-api-hooking-techniques/

The following are prevented by a HIPS process modification rule:

CreateRemoteThread
Inline Hooking
​

The following is prevented by a like HIPS rule:

SetWindowsHookEx
​

The following are prevented on Win 7+ x64 OSes by PatchGuard:

SSDT Hooking
IDT Hooking
​

That leaves:

IRP Hooking - This is done by drivers. As discussed previously trying to monitor driver hooking is an "effort in futility." You prevent rouge drivers from being installed in the first place with proper HIPS rules or using a driver installation tool like Driver RadarPro.

Sysenter Hooking - The most easy bypass for Sysenter hooking would be to rewriting the register to its original value, however because KiFastCallEntry is not exported by ntoskrnl, getting the address could be tricky.
​

The bottom line is you're "spinning your gears" so to speak with API monitoring. Most HIPS's will prevent all but the nastiest of the nasty's from nailing you.

​

 

I never used it because I was happy with SSM. But AFAIK it let you inspect user and kernel mode hooks, but didn't block them. SSM could also spot hidden processes. Zemana and SS don't offer this stuff, but perhaps it's also harder to implement this on Win 64 bit. Speaking of HIDS, did you ever try PC Hunter? It's basically a rootkit detector but I never tried it because it's from China. NoVirusThanks also offers a couple of interesting tools, see links.

http://www.downloadcrew.com/article/29999-pc_hunter
http://www.downloadcrew.com/article/28033-ring3_api_hook_scanner
http://www.downloadcrew.com/article/27332-ssdt_view_64-bit

I don't believe they can block process hiding, but they can spot malicious behavior from the hidden processes, what should be good enough.

 

I'm not sure what you mean with this, but you have to be specific when you try to block user/kernel mode API hooking, you should only watch for API's that are not likely to be modified normally speaking. That's why Zemana, SS and Trusteer, are only blocking certain user-mode API's from modification, because they are often abused by banking trojans. They could try to watch for other API's but that would give too many false positives, unless you're white-list is quite good. BTW, Inline Hooking can not be prevented by a block/allow rule, it will be either allowed or not, based on the white-list.

 

So does Eset's HIPS but you have to create a specific HIPS rule to do so. And remember as I showed on our discussion of memory based .dll injection, Eset HIPS will catch that whereas Zemana did not. Not sure if SS or Trusteer caught that but I doubt it.

 

I don't understand the purpose of this. The only way SSDT can be manipulated is if PatchGuard was defeated. You would need a rootkit of Turla's capability and those thankfully are rare and targeted to state like organizations. Also, MS in short order will issue a patch for the PatchGuard bypass. Finally, note the software hasn't been updated since 2012.

As far as I am concerned, if your going to monitor API's, the ones most common used by malware are those I posted in reply #223. Also, SetWindowsHookEx which performs global hooking most often used by keyloggers but also for other functions. You don't need to hook to perform keylogging; there are javascript keyloggers for example.

And again, there are products such as McAfee's Endpoint which has a "open_with_directive" feature that will allow for API detection.

 

@Rasheed187 here's one for you that is totally undocumented: ScRegSetValueExW. If you can't figure it out, it will give you a tip on what software uses it.

 

I also was happy with SSM !

 

You still didn't tell me which behaviors the ESET HIPS is monitoring. And I doubt ESET can block API hooking, only Zemana, SpyShelter and Webroot can do this besides Trusteer which isn't a full HIPS/BB.

The purpose is to check if PatchGuard hasn't been bypassed, so it can't hurt. But of course, the most advanced rootkits can fool these kind of rootkit detectors.

I don't have a clue.

 

Now that I think of it, I wonder why they didn't make it open source, it's a shame. I used it as anti-exe + HIPS and combined it with Neoava Guard for some features that SSM lacked. I used this setup for 8 years on Win XP.

 

Those I posted in reply #223. Also, SetWindowsHookEx - as mentioned previously many times. Additonally it can monitor(user custom rules) direct disk access, debugging activity, event interception, start/terminate/suspend activity; the ability to monitor all startup activity - not just changes to the registry run keys; and finally all registry modification activities. Remember Eset passed all the reflective .dll injection tests I performed. I believe Zemana and SpyShelter funked those per your testing?

This will use the service control manager utility to update the registry. It can also create services on the fly. A favorite of malware but also used by Win Updates.

 

What are the odds of a PatchGuard bypass? One in many thousands of malware, I would say. Even far less odds using rootkits like Turla that succeeded in intercepting the OS abend. Most of these type of rootkits result in a give away blue screen. Zemana's hook's can easily be disabled by malware by deleting them from the AppInit_DLLS registry key. I am sure the malware will then load its own dll hook there.

 

SSM had 2-3 developers, but, as for all HIPSs, there was not buying market for it; at the end remained only Vitali and he tried to find a buyer to sell the code, but he couldn't find. He gave for free the license for a short time, then he closed the site and the forum. If SSM worked on 7, I'd use it.

 

Yes, it's a shame they let SSM die, you never know if they had made it open source, developers could have redesigned it to make it work on Win 7 and 8 64 bit. Same goes for Neoava Guard, but I believe the developer sold the code to an AV company in Iran.

The odds of my system getting infected is quite small, but I still scan the system and still monitor running processes and drivers. I do think that the decision of M$ to lock-down the OS with PatchGuard was the right one.

No I never did test this, can you give some more info about how you tested ESET? I wouldn't be surprised if Zemana and SS failed because this technique is not often used by malware, it's more likely to be used in a exploit attack where the payload needs to be in-memory without touching the disk.

 

We've covered all this in previous discussions on reflective dll injection - remember? Also our previous PM session on the same. I used a reflective .dll test tool to try memory inject into my browser. Eset stopped it in its tracks by a HIPS process modification rule.

 

If they had made it open source, why don't say it ? And if at the end Vitali sold the code at a software house, why the software house didn't announce it ? SSM was very know and appreciated, we all had followed it in his new life. For a bit I thought that OSSS had SSM code, but now I believe that it's really vanished: probably the great softwares house, like Kaspersky, that already had their own code, were not interested, and there weren't little developer that wanted to continue SSM.

 

OSSS sure looks like a Comodo Defense+ variant to me from the screen shots shown?

You should check out Ambush IPS as I posted previously: http://ambuships.com/details.html . It is pretty much bullet proof.

 

Actually, it is coming down to the fact that Defense+ is the only free user friendly HIPS left these days being actively supported.

 

As Im currently running xp home sp3 ,right now ,I managed to get SSM serial from regnow.com ,which Id purchased in 2008.Glad I printed off my regnow order id,as it gave me access to my serial which id long lost/hadent saved.Anyhow ive downloaded 2.3.0.612 and 2.1.9.582 ,and both versions seem to install ,except after reboot I keep getting ssm driver wasn't found.Ive installed in safe mode but still no luck.Any old time users here know what the problem may be?

 

I never had, with XP S3, any issue. It sounds like the SSM file is corrupt. Try to download it from some other site. There is a site with the old softwares versions, but now I can't find it in my bookmarks.

 

I found OSSS more granular than Defense+.

Thank you. But its development is going on ?

 

Thanks
Ive tried the two different versions from 2 different sites (though its is quite difficult to find many versions) and get the same error.I thought it may have been sygate firewall as I read there once an incompatibility,but even when that's not installed I get same error.
EDIT
Ive just looked at ssm install log ,and it seems to have installed the driver.In fact its in system32 drivers ....safemon.sys ,so Im not sure whats going on.

 

May be that there are again some Sygate files uninstalled. Now I remember - sorry ! - that when I began to use GesWall with SSM I had to install SSM before GesWall otherwise I had compatibility problems: if I installed GesWall before SSM and then uninstalled GesWAll the problems continued.

 

Just installed the free version and that works,so I guess you were right saying that the other 2 files must be corrupt.If anyone has any links to later versions ,would be much appreciated.
EDIT
looking for 2.4.0.621 and 2.4.0.622 versions if possible.Ive checked old mediafire links posted at wilders where they were hosted but they are now dead.Would appreciate any links to above files or possibly sent to me if any members have access to them?
tia

 

ellison64, you appear to have Sandboxie running. I don't know if it'll conflict. Maybe not. SSM hooks all but 4 kernel functions in the Boot phase, so it should have full control. But if Sandboxie tries to hook stuff, there maybe a conflict, or may not if it chains one hook to the next.
I'd be interested to hear how both work together because I've been toying with an idea of adding Sandboxie to my XP.