Did some CLT tests with all SpyShelter products in the past. Not sure about the exact scores for Premium and Free, but in order of magnitude: SpyShelter Firewall gets a 340/340 score on CLT (perfect score). SpyShelter Premium about 300/340 (4 tests failed). SpyShelter Free about 260/340 (8 tests failed).
As best as I can determine, the two CLT hook tests are not valid for Win 7+ x64. CLT is a 32 bit process. The two source .dlls CLT uses for the hook tests are 32 bit by definition. You can't hook a target 64 bit .dll from 32 bit source .dll. This is definitely the case for the global hook test which is trying to hook kernel32.dll in every .exe. Another quirk with these hooks tests is that they don't set any actual hooks such as the one for keyboard monitoring. So failure in these tests means that only the API calls for SetWindowsHookEx or SetWinEventHook were not detected /blocked from CLT. Many HIPS's only monitor selected targeted processes for any detected hook like activity. So they will fail these tests since no actual hooking activity took place. CLT by default is treated as a "trusted process" in Defense+. You have to set it to "untrusted" to pass all the tests.
No, it means it is legitimate score. I do have to agree though that Matousec Test Suite is better - I wish he would perform new official tests but it seems he abanoned the project. That is a bold statement...What I learned while working with software myself (game dev, which imo is far less complicated than security), is that making even small changes from user's point of view can take hundreds of man-hours on the developer end, so when hundreds of users start to send suggestions on top of the development pipeline...well... you get the idea. Judging by the amount of updates they started to roll out recently, I am convinced that they are not bored.
I am confused. If CLT is 32 bit, and the 2 hook tests are 32 bit, then it can't hook the processes on 64 bit. So how should the 2 test results for hooks be interpreted ? Matousec is abandoned project - I would bet.
No. I believe SS works similar to Defense+ and monitors API calls from any untrusted process. Will comment on this more in another reply.
I looked at the CLT code again for the two hook tests. CLT is performing the hook tests against itself. Defense+ must monitor API calls from any "untrusted" process. If it detects a hook API being executed, it alerts on that activity alone. This is the only way these tests can be passed. As long as CLT is set up in Defense+ as "untrusted", it will detect the hook activity. As I commented previously, most HIPS are looking for hook activity against some predefined target process if so coded in a user rule. As such, they would ignore any hook activity from a source process directed at itself.
SpyShelter website: https://www.spyshelter.com/help/ * * * * * Can I completely trust system processes like explorer.exe? Not completely. Sophisticated malware can use injection techniques. It means that malware will inject code into system processes and try run dangerous actions, covering up its real name by using a system process name. SpyShelter protects your files from injections. Keep in mind that SpyShelter cannot undo injection once it happens. SpyShelter can stop malware from injecting or stop the dangerous actions of a file, which contains malicious code. However, thanks to our partnership with VirusTotal you can scan a suspicious file with over 40 different antiviruses online in matter of seconds, with just one click. You can do it by clicking on Check component for viruses on www.virustotal.com link on the top of alert window. You can also do it from the context menu, by clicking the right mouse button on a file itself and choose SpyShelter>Check file on VirusTotal.com * * * * * Code injection detection\process hollowing on 64 bit systems is a weakness. If a typical user reads the above, then they would reasonably expect SpS to provide these protections completely - unless noted otherwise. The exceptions are not covered...
There are two types of dll injection; disk based and memory based. I believe Rasheed187 tested SS and found it vulnerable to memory based injection. Process Hollowing is just a technique to facilitate the memory based injection. The malware spawns a valid process from itself in a suspended state, alters its memory, and injects the malware code. The malware then starts the suspended process. That way the malware injected into the memory of the suspended process will run with process's normal privileges. -EDIT- The reason many HIPS fail when Process Hollowing is involved is because they are not monitoring suspended processes for process modification activities. I tested Eset HIPS and Emsisioft and they both detect such activity in a suspended process.
Anyone know what the specific limitations of the sandbox are on 64 bit systems ? The SpS help file raises more questions -- and doesn't really give any infos except vague general answers.
I tried running portable apps in SpS Sandbox. If added to Sandboxed Application list, the app runs outside the sandbox...
"Sandbox" in SS is not the same feature like in Sandboxie...this module lowers privileges of chosen apps as much as possible. What do ypu mean "outside the sandbox"? Read this please or just help file. https://www.spyshelter.com/sandbox/
Just like I said. Add portable app to Restricted Application list (Sandbox). Execute. Portable app runs unrestricted; outside the sandbox. I can reproduce at will on my system.
OK...I understood...I'll check how works my portable pdf reader (STDUViewer) which is launched trough "Sandbox".
I have seen such behavior before with other policy sandboxes. For example, COMODO policy and virtual sandboxes (bypass). Portable apps have proven to be problematic for some security softs in various ways. There are reports on forums: COMODO, ESET, Kaspersky... etc. It is no big deal - since SpS HIPS module still generates alerts if application will not run in sandbox. So user is still protected in this case with SpS. If anyone else can reproduce I will submit report to Datpol. I can report it now, but I have no confidence that others can reproduce it on various systems - e.g. 32/64 W7\8\10. I am on W8.1 Home 64 bit.
"New version of SpyShelter brings support for Windows 10 Insider build 14271 and includes few small improvements. SpyShelter 10.7.1 (1/Mar/2016) – Added support for Windows 10 Insider build 14271 – Fixed issue with PID display in Alert Window – Small fixes" https://www.spyshelter.com/blog/spyshelter-10-7-1/#more-6451
No I never did test this, but I wouldn't be surprised if most HIPS would fail to block the reflective DLL injection method, since it's a relatively new technique. I also don't know if it's used by malware. Yes seems like they missed this, they could easily add this by making SS monitor child processes. Same goes for anti-ransom, they could add a "rapidly modify files" filter, so whenever some process gets a list of files and wants to modify them in a short amount of time, they could suspend the process. Neoava Guard and Online Armor had such features.
Yes I can understand this, I think they were mostly busy getting SS ready for Win 10. I know that Zemana failed to do this. But still, I think they have focused on the wrong things like the skin. The things that I mentioned are not that hard to implement I believe. I have no idea. But I think the sandbox is a missed opportunity. Instead of blocking write access to folders, they should have focused on anti-exe. All sandboxed (or restricted) apps should not be able to auto-execute child processes, and all high risk behaviors should be auto-blocked.
I'm not sure if it's difficult to add. Another member did post about HMPA stopping an attack which involved process hollowing. That's weird, on my system it just fails. Can you give some more info, do you use Win 8 64 bit? Yes support can be a bit better, seems like they don't have all technical info. But it's still the best standalone HIPS. It's a shame that none of those tests actually work.
OK...my test of portable apps that are listed in "Sandobx". Every apps launched normaly ("restricted") are restricted...if they are launched using command "Run as unrestricted" are just unrestricted. Properties on screenshots - list of portable apps - restricted - not restricted
SpS does not create Application Execution Control rules for MicrosoftEdge on W10? E.g explorer.exe > Microsoft Edge (Action Type 53) 10.7.1 does not do it on W10. Also, I am seeing that SpS is not "remembering" existing rules.
v 10.7.2 released Spoiler: change log New version of SpyShelter brings support for Windows 10 build 14279, and it also allows to specify 64 bit paths for manually added components. On 64 bit systems it is now possible to specify system32 paths by choosing “sysnative” shortcut when manually creating a rule. The sysnative folder is visible in the file selection window, just like below: sysnative Windows 8.x and 10 users should no longer experience issues while launching applications using the ‘Run as restricted’ option in context menu. SpyShelter 10.7.2 Changelog (9/Mar/2016): – It’s possible now to specify 64bit path while adding components – Added support for Windows 10 Insider build 14279 – Fixed problem with shell context menu and “Run as Restricted” feature on Windows 8.x/10 https://www.spyshelter.com/wp-content/uploads/2016/03/sysnative.png
You can set Spyshelter to allow all actions from a program and a folder. When you allow all actions you can choose to allow only this program version (hash) or also all future version (name, I always choose this option because it is less maintenance). After you have created the allow rule, you can change it to a deny rule. This will cause SpyShelter to silently block all actions of this program.
@Windows_Security So for potentially exploited app - create deny rules by changing the allow rules of its customary actions to deny... am I understanding this correctly ?
Can Microsoft Edge be run inside SpS sandbox ? Are there any required tweaks that need to be made beforehand ?
