Discussion in 'other anti-malware software' started by Mops21, Jul 30, 2015.
Im using Eset Smart Security with Spyshelter Premium. I know, Eset Hips(in smart mode) and Spyshelter Hips "clash" together. That is why i tested them together. And the results are interesting. With SS8+Spyshelter Premium CLT result is 320/340. Interesting thing is that, for example when chrome is updating, or steam update(an .exe file is changed), Spyshelter notices that modification instantly, and prevents it running before i click yes or no. However, SS8 noticed that an .exe modification is made(accept or no). But the steam still starts.
So is kinda interesting how deep on the kernel ring side of these hips are programmed for. That is why i configured Eset Hips basically disabled, and using Spyshelter's one for that purpose.
There is 35% off all Spyshelter licenses including the firewall lifetime license for this weekend only.
No thanks, im using SS8 firewall component to specify my outbound connections. Deny all raw socket connections.
I assume you are running the Eset firewall with outbound connection monitoring enabled? If so, the alert you received actually was generated by the firewall. When an outbound connection is made, it does a check by hash to determine an .exe change was made to the process initiating the connection. As far as Eset's HIPS goes, it will only monitor an app .exe change when a specific user rule is created to do so.
itman, yes im using SS8 firewall for outbound connections. SS8 firewall is quite capable doing so, if you compare it to windows 7 based firewalls
There is a lot way to connect to internet via windows 7 basic firewall. It does not give an option to preven raw socket connection...
Maybe a ridiculous question, but when set Auto Allow to Medium (or High).
When starting ProcessExplorer, Spyshelter allows auto-allows some actions, but it blocks the loading of a driver. When you click details it says "signer is on the auto-allow list"
@ichito what am I understanding / doing wrong?
Might have to do with the way Process Explorer loads its driver. It dynamically creates a driver entry in C:\Windows\System32\Drivers directory upon execution and deletes the entry upon termination of PE. That type of activity would definitely be construed as suspicious if done by most processes. You might have to create a manual rule to allow the driver to load.
Okay, ran SpyShelter on my PC for a day (I have it on XP systems of older relatives in auto block suspicious actions mode). Might have accidentally put it on Auto Allow high (when I replaced Chrome by Firefox due to ending Chrome XP support). In Medium level it does create an Auto allow rule (auto allow rules have a different icon). Thanks for the explanation @itman (40=opening process/thread for modification, 41=creating the driver (modifying protected files), 27=loading the driver). Note I have only Hips module enabled in free version.
SpyShelter version 10.7.4 has been released:
I'm still waiting for:
- Protection against process hollowing (child process modification)
- Protection against rapidly deleting or overwriting files (anti-ransom)
- Protection against modification of EXE files
- Protection against termination of processes
- Protection against loading of network enabled process (to bypass firewalls)
- Ability to allow or block actions via log window
- Ability to see which actions are allowed or blocked in log window (separate column)
- Ability to auto-block certain actions (let user choose)
- Ability to manage protected registry keys
- Ability to hide actions from certain (system) processes in log window (too cluttered)
- Ability to exclude certain rules from being cleaned
- Ability to manage Trusted Signers (SS internal list)
This is what I mean, in NG it was easy to see this. But for some reason the SS developers refuse to add this basic function, I don't get it:
Another thing that should be improved is the way rules are managed. There should be separate rules for Trusted, System and Restricted apps. This should be independent of the sandbox. All apps inside C:\Windows should be trusted except if they marked as "restricted system process" and they can only be trusted if they are protected by Windows Resource Protection.
Here is how parent-child process creation should be managed:
System Space = C:\Windows
User Space = All folders outside C:\Windows
Trusted process ---> Child process ---> Trust system space ---> Restricted process is not trusted ---> Restricted system process is trusted
Restricted process ---> Child process ---> Restrict system + user space ---> Trusted process is not trusted
Non marked process ---> Child process ---> Trust system space ---> Restricted process is not trusted ---> Restricted system process is not trusted
Have you sent all this details to the developer?
He is usually quite collaborative.
You can always develop your own software if you are not happy with 2000 other things that soyshelter actually offers.
I am pretty sure that protected files list was added to protect from file modification (writing).
Process termination 'could' be useful but personally never in my life I have had to protect anything from being terminated...Would be a pointless alert IMO
Not sure what you mean about trusted signers internal list but I am pretty sure we have the ability to customize our own trusted and untrusted signers because I have been using it like since 2013
Ctrl+A on rules list, shift+click on entries you wish to keep, and hit the delete button? Not sure if this is what you suggested, but this is a pretty basic UI functionality, and it is there, like in 99% of applications.
Listing allowed actions in Log would be nice, although with the amount of monitored actions by sps they would have to come up with some really slick design. There is like 60 different actions monitored, now imagine listing 43 of them
I don't really mean to imply that you are wrong, I just think that most of these features you listed are not really required. Process hollowing might be a thing but I have not personally tested it so I can't say if it protects against it or doesn't.
Afterall, spyshelter is currently the best antikeylogger and hips on the market, at least as far as my requirements go.
But yeah, like @guest said, you should send it to devs if you haven't. Posting such suggestion lists on unofficial forum seems pointless.
Yes I did, the only problem is it was 6 months ago.
Yes, but without protection against process hollowing, it can't stop ransomware, this has already been tested. Also, if you can block apps from rapidly modifying files in a short amount of time, this could also stop (most of) the damage done by ransomware.
It would indicate malicious intent, most apps don't try to terminate or suspend other processes.
SS has an internal list of trusted software publishers. We should be able to edit this.
There are certain rules that you don't want to remove, now you have to untick them every time when cleaning up rules.
I think you misunderstood, I meant there should be an option to block/unblock actions straight from the log window. Now you will have to look for the rule (in Rules tab) to do this.
No they are not required, but it would most certainly make SS stronger and handier to use.
SpyShelter version 10.7.5 has been released:
Fixed Keystroke encryption driver load on Windows 10 32 bit
Added compatibility support for custom build of VirtualBox
French language update
With best Regards
BTW, for the people who didn't understand the scheme: It's basically about how child processes should be handled. To avoid breaking the OS, you need to trust most system applications, except for "vulnerable processes" that can be used in attacks. But even they should sometimes be trusted if they are launched by other system or trusted applications. The problem is that SS doesn't let you label apps, and it's also not clear how "vulnerable processes" are handled. Examples of system processes that should be running as restricted:
It loads very slowly, can you give some more info? It fails to protect against what exactly?
ESET passed the test! I just want to figure it out that ESET can detcect injection to C:\Windows\explorer.exe, but others can't, then explorer.exe could do something bad...
is triying to modify other program's status.
Clicking on services on that website, nothing happens
It's dead right now!
Have you seen the pictures below.
Separate names with a comma.