Discussion in 'other anti-malware software' started by Windows_Security, Oct 21, 2014.
No problem...and thank you for your signature where I saw this great program
What to say about this analyze?
Here is one similar program like this, it's made be the same guys who did Shadow Defender:
Easy File Locker
Have you tried this? how do you like it?
Nice finding thanks!
Although this is a showstopper for me, from FAQs:
I use SecureFolders precisely to lock a whole drive. Namely a USB drive. Imagine if I had 50 folders in the root of it...
Similarly, I need to lock my USB drive.
Also the ability to set trusted applications ... this doesn't appear to have that feature.
Secure Folders implementation of this needed improvement e.g. trusted application per folder, but alas that will never happen now.
What about this analyze of Secure Folders? Legit or false?
Here is and Anubis report of Secure Folders:
I just tested it and it seems to do what it says it does very well.
From Deepviz analysis:
But I've never seen any connection attempts in WFC connections log.
I analyzed that IP - CLICK
It try to connect because cheeking Update.
Ah yes I do remember now. I unchecked that "Update" case and SF stopped calling to updates server.
This what the web page looks in the past (23.8.2015)
Just see one great thing!!!
You can protect files but just adding extensions like: *.mp3, *.txt, *.docx...
This sounds a bit weird, so basically you're saying that the ransomware could encrypt files except for the protected data? So you didn't get to see any alert about code injection into explorer.exe and svchost.exe? The weird part is that if explorer and svchost.exe were modified (process hollowing) then in theory SS should have failed to protect private data, because encrypton was done by a trusted process. If I don't trust explorer.exe then I can't even access protected data myself.
Nice video, but what happens if you trust explorer.exe? A question to the people that use SF: Is it necessary to make explorer.exe a trusted process in order to get access to protected folders?
Deepviz looks interesting. When I look at the behaviors that were monitored, I noticed that SF injects code. So does SF load a DLL file into running processes?
On 64 bit system SpS cannot alert to code injection: Action Types 29 & 36.
In response to what you said here - I retested using different samples.
It is weird result.
It depends upon sample.
The one sample there was no encryption.
Other samples there is encryption - because of explorer.exe and svchost.exe (process hollowing) have SpSFW file modification allow rules.
And I did verify that all samples were, indeed, ransomware; for whatever reason(s) that one sample doesn't encrypt protected folders.
@Online_Sword had best suggestion when launching files ("from User Space") that are unknown - don't allow them to execute system files - like explorer.exe or svchost.exe.
Against ransomware, I think that is best one can do with SpSFW.
Anyhow, in its current version, SpSFW implementation of protected folders is problematic because of "trusted" processes with generic allow rules for file\folder access\modification.
For protection against ransomware, Secure Folders is better solution - as long as you don't designate Trusted Application.
I made a test with extension protection and Explorer added to Trust.
I run Locky, it drop some files but nothing got encrypted.
Thanks a lot for these useful tests!
Are you serious about Action Types 29 & 36? So it can't protect against all types of code injection? And yes, I already expected that SS doesn't protect against process hollowing. This is something that the developers should fix, because it allow to bypass data protection. A dedicated anti-ransomware feature like in HMPA would also be nice.
Very weird, I really wonder how SF manages to do this.
On 64 bit system, no detection by SpS of Action Types 29 & 36.
@Online_Sword tested - and his tests appear to confirm.
You can verify specific details regarding these Action Types with support.
I have no further technical infos - and curious about all of this as well.
This statement is not precise enough. More precisely, what I found was that, on 64-bit systems, when a parent process takes Action 29 & 36 to its child process, then this operation would not be alerted.
That is why I think we need to prevent unknown processes in user space from launching vulnerable system processes, such as svchost.exe and explorer.exe. In such case, we can prevent the system process from becoming the child process
Parent process A => executes => Child process B; no detection Action Types 29 & 36
Process A => modifying process memory (29) or injecting dll (36) => Process B; detection Action Types 29 & 36 - correct @Online_Sword
Good Stuff to know. Quite useful.
Beautiful YT Vid too. Great overview in action!
All this is encouraged another look for me even deeper into SF and not just reply for it On Demand as been the case.
I'm not sure if you mean on .exe file or others?
On Win 10_x64 I could run .exe if that folder is Read Only.
Interestingly, the download link in this archive (click the download tab) still seems to be active!!
Yep, I noticed that also.