Looks like you're on Windows 7 32-bit. I'm on Win 8.1.1 x64, so the issue is either 64-bit or Win 8.1.1.
I have SS Firewall & Comodo V5. This combo works very well together and blocks everything you throw at it
On my system it passed the test, and I already explained that PC-Flank will always try to start up IE, if it isn't already open. If you're interested in leak-testing, you might want to try these ones: http://www.testmypcsecurity.com/securitytests/all_tests.html#AllTests Yes, but it should give an alert.
Now that I think of it, it's indeed weird that this option is not available. Fiddler also triggers blocking of "network monitoring hooks". Like I said before, this protection is used to block banking trojans from hijacking SSL connections, but sometimes it's of course also used by legitimate apps. I did notice that SS has the ability to monitor/block this without injecting code into browsers, so all is done with the driver, interesting from a technical point of view. I don't believe SS Premium watches for execution of apps, it will of course automatically trust all MS signed apps.
Another thing that I noticed: SS does not protect against process termination (no separate rule), and changing of service/driver state. Seems like they missed this.
In XP time there were no Integrity Levels and UAC, so process termination was a layer of protection. All core processes run at System/Admin level, so Low and Medium processes can't touch them. Spyshelter should stop abnormal process/driver access with the protection listed.
They would run in a policy container which strength can be compared to somewhere between's IE's protected mode and Chrome's sandbox (in laymen's terms). You can only do that for a few selected medium level processes. See third picture in this post (#100) SpyShelter 9.2 released Only applying them to a few medium level processes, you would still get blocks (warnings) for ADS creation and Opening other process for update access. Chrome and IE should work normally when these two actions are silently blocked. The effect is that the Medium Level brokers of IE/Chrome can't touch other medium levels processes (side-by-side protection) and make it harder for exploits to illegally elevate. Same way Sandboxie will not protect against exploits, but still could prevent the next steps of a staged intrusion. Exploits/malware aware of these limitations could circumvent them (SBIE/SS) depending on the severity of the exploit, but I have not seen those in the wild. So when you use SS with EMET/MBAE/HPMA as explained in post #100 (as an inverted HIPS with keylogger protection when you like), one could only be infected through shoot in the foot user errors.
Did you test it? The first one: "modifying memory of other process" is normally not used to stop process termination. It's meant to stop code injection. And the second one is not listed in the "List of monitored actions". If you stop or change the state of a service/driver, SS should alert about it, but it didn't on my system. You can test it with these tools: http://p-nand-q.com/download/pserv_cpl/index.html http://www.nirsoft.net/utils/serviwin.html
First - no I didn't test it...it was only a slack note/proposition Second - rule #46 on "List of monitored actions" BTW...not all actions from such list are included in window with advanced rules for process...after all, you know
@Rasheed187 from spyshelter help desk If you meant this words: " If you stop or change the state of a service/driver, SS should alert about it" SpyShelter should not alert about it. There is no protection implemented for this because this thing is not treated as dangerous SpyShelter drivers are not being unloaded this way.
Thanks for checking, but I have to disagree with the developers, especially SS which is an advanced HIPS should monitor this. Malware (and other apps) should not have the possibility to silently enable or disable services and drivers. It's a potential security risk. Correct, perhaps an idea for the developers to streamline this a bit more.
Running spyshelter with only system protection module enabled as a HIPS sandbox for EMET protected applications. Default Allow rules for Windows & Program Files folder (I have UAC on full with ValidateAdminCodeSignatures enabled) Security: ASK USER with Auto block suspicious behaviour (so everything outside UAC folders will be denied without user interaction) Default Deny rules for all apps EMET protected abnormal behavior protection (Spyshelter monitors over these processes while EMET guards from within). Seamless and silent protection, with no function degradation and no user interaction The EMET-ed programs should function normally with this setup as long as you switch off Spyshelter protection before updating/installing software.
I just saw this, SS fails to stop the "CTB-Locker Ransomware" with behavioral monitoring. A bit disappointing, but in the past most HIPS also failed against this type of malware. In order to pass, HIPS need to add adequate protection against "process hollowing" and a dedicated "file modification monitor" like HMPA's CryptoGuard. http://malwaretips.com/threads/ctb-locker-ransomware-2015-02-01-update5.41633/
it seems in some auto allow mode level? video is in poland language? i think "ask user" level will for sure block it.
Yes...most o such tests are in Polish. Tests of SS was repeated by other users and we can say that on Win 7 and Win 8.1 SS sometime failed and sometime passed, but on XP passed...from discuss it seems that result depends on settings and chosen action (block or terminate) and when (in which moment) such actions are chosen. Unfortunately it's hard to find some rule in this mess. Many settings are changed and "ask user" level in some tests don't give good result.
Well it depends, if I'm correct ransomware often starts a legitimate instance of explorer.exe or svchost.exe and then uses the "process hollow" method, to take control of the process. This is different to the standard "dll injection" method, and might fool some HIPS. But like I said, even if HIPS are fooled, they should still be able to detect "file modification" like HMPA. Seems like SS and Zemana both have failed to implement protection against this stuff.
"SpyShelter version 9.6.5 has been released. It contains important security improvements, therefore we recommend that you install it as soon as possible. 9.6.5 (18/Feb/2015) – Self defense enhanced – Com protection improved – General protection improvements" https://www.spyshelter.com/blog/category/news/
So does Ghostery v4 install for IE11... runs outside of SBIE, but not inside. SS picks up a NetworkSpy trigger... ugh! SS will alert about service mods if the appropriate YES is swapped for NO in the List of Monitored actions... I wish I had a way to create a rule for #33.
Kees asked about this rule in post #86 I got answer from developer that rule #33 is common for all apps (on list of monitored actions) so due to possible freezes of system they don't want to offer it in rules template. Probably it will be