VoodooShield/Cyberlock

Does VoodooShield have a potential for conflicting with AV?
Right now I am using Bitdefender Total Security 2016, on Windows 10 pro x64 stable build.

Are there certain security tweaks I should avoid when using Voodoo?

 

Hmmm, we better get to the bottom of this so that we all agree .

Let's keep the default settings, because those are kind of like the most dangerous, worst case scenario, right?

Place VSExploitTest.exe anywhere in C:\Windows\ (either in that folder or any sub directory, it does not matter). Whether VSExploitTest.exe is placed in a sub directory that auto whitelists VSExploitTest.exe, or the user manually allows VSExploitTest.exe, VS will still block the VSExploitPayload.exe that is dropped.

BTW, this is the mechanism that stopped r41p41's exploit attempt.

Keep in mind... VSExploitTest.exe is really no different from the thousands of files that can possibly be exploited in one way or another, in the Windows directory, to spawn a payload. So assuming what I am saying is correct, isn't is infinitely better that we handle vulnerable processes this way... that way we do not have to worry about the next vulnerable process that is the latest "buzz". I mean, 4-5 years ago, we only talked about 6-10 vulnerable processes... now we talk about 60 or so? If this method works, then it applies to ALL Windows folders, along with others , so it is much more secure than handling each process individually.

 

Hi shmu26! The only incompatibilities that I am aware of is with cryptoprevent and sometimes AVG, since both of these mess up the VS installation. But as long as you disable both of these while installing VS, it will work fine afterwards. Thank you!

 

Yeah... exactly!!! From my original post...

1. First try running VSExploitTest.exe from your desktop... it should block the initial file VSExploitTest.exe. If you allow this file, it should spawn the VSExploitPayload.exe that was dropped to your desktop 3 seconds later (I made it sleep for 3 seconds to make sure the file finished downloading). Usually payloads are dropped to appdata or programdata, but I figured the desktop would be easier for this test, and the results would be the same.

In the user space, you have to allow VSExploitTest.exe in order for it to spawn VSExploitPayload.exe, right?

But whether VSExploitTest.exe is allowed or not in any of the Windows folders, the payload will be blocked.

See what I mean? I seriously want to get this right one way or another, so if I am missing something, please let me know! I appreciate your guys help on this!

 

Interesting. I have CryptoPrevent (before VS) but never noticed an issue.

 

Yeah, it works fine after VS is installed .

 

Yes, it is important. I hope @hjlbx and @Cutting_Edgetech also chime in on this.

 

Sorry, I did not explain this poc well enough... VSExploitTest.exe is basically emulating a potentially exploitable windows file (it is NOT the dropped payload), so feel free to put this in any folder you want (even if it is a windows protected folder that requires admin approval)... VSExploitTest.exe does drop the payload to the user space.

Well, any folder that has potentially exploitable files should not be able to spawn a dropped payload, even if the parent process is enabled. And keep in mind... if any file is in the user space, it has to be whitelisted first, right?

 

Yeah, and it would be good to hear what Vlad has to say about it as well... him and I have never discussed this from what I remember. I could be completely wrong about this, but either way, we just need to make sure it is done correctly .

 

VoodooShield,

Do you think would be good to have filters in whitelist, logs, command, etc... in the GUI?
Like show blocked files, show system files, show allowed files, etc...
And may be more like show session allowed/blocked/quarantined, etc...

 

I have notice that VS 3.09 keeps silently crashing. I see that the icon on the task bar is red, rt click on the item, menu pops up and it freezes. Have to use Task Bar to kill it off.

Win 8.1
Sandboxie
Avast
Private f/w

 

There are only a few ways that I know of to bypass white-listing. One is the use of crafty scripting that fully exploits vulnerabilities in NET assemblies and host processes - either the ones shipped with Windows or 3rd party. Due to various quirks, arguments can be created that cause NET assemblies and host processes to carry out actions that are ultimately malicious. It's an intrinsic vulnerability with NET assemblies and host processes.

There's quite a few processes shipped with Windows that are white-listed because they are Microsoft processes - and they have been utilized to infect the system without dropping a single file. For example, it can be accomplished by using a white-listed Windows process to manipulate the registry and create encrypted keys. Poweliks comes to mind.

The above can only be mitigated by adding all the abusable processes to the vulnerable process list - so as to ensure that VooDooShield alerts to their execution.

For example, if you browse to a website. All of a sudden, you get alerts from VooDooShield that vbs.exe, RegAsm.exe, PresentationHost.exe, wusc.exe, fondue.exe, etc are attempting to execute, then you just know that an exploit has occurred and an infection is in progress.

I added every single vulnerable process I could think of to NVT ERP's vulnerable process list. Over a few months, not a single vulnerable process I added was executed as a part of day-to-day operations on my W8.1 and W10 systems. csc.exe was needed for one item in Control Panel. These processes just are not needed on the typical system. NOTE: What I added was supplemental to the built-in list: rundll32.exe, wscript.exe, etc.

Another case will involve process hollowing a few steps along the run sequence - and there isn't much that can be done about it once that happens; if you allow it to execute, then all bets are off. An example is ransomware - which often hollows explorer.exe and svchost.exe - which are white-listed processes. Detecting process hollowing using HIPS-type file monitoring is difficult on 64 bit systems. Furthermore, fileless infections have been shown to create a process, suspend it, hollow it, then manipulate the registry, scheduled tasks, etc. Once again, Poweliks is an example (in that case powershell.exe - which is a vulnerable process in VooDooShield - hollows dllhost.exe; so in this case VS should definitely block Poweliks). Other fileless malware cases, that use non-blacklisted Windows processes = high probability of bypass.

A lot of HIPS-like programs have real trouble with memory only malware\process hollowing\*.dll injection. Mitigating against process hollowing and *.dll injection is not what VS was designed\intended to do - I am just pointing out that HIPS-like programs from all vendors have some weakness - especially on 64 bit systems.

Once you reach a certain point, there is only so much you can do... Patch Guard has a lot to do with creating limitations.

 

To me, there are many factors that determine whether a new item should be allowed or not... blacklist scan, user analysis of the file (file name, suggestions from the security software, etc), Ai and so on. Once the determination is made to block the file, then it should be completely blocked, and not a single line of malicious code should be executed. But once the determination is made to allow a file, then the file should be allowed to do what it needs to do in order to function properly... otherwise, restrictions can cause some programs to not work properly, and cause all types of problems on the computer.

So while the determination of allowing or blocking a file has a lot of grey areas, once the determination is made, it is then black and white (binary). Having said that, you can adjust VS however you like to fit your needs.

You said "Why not give the option to monitor more stuff if you want and know how. Just more freedom for experienced users to protect their system more." But adding this would not give the experienced user more freedom to protect their system more... it would actually make it more vulnerable, right?

 

We could add this... it would not be too difficult to do.

 

Yeah, that happens on my Windows 8.1 system every once in a while... we have been trying to track down this issue, I think we are getting close. Can you please send your .log files from the C:\ProgramData\VoodooShield folder to support@voodooshield.com?

 

Because currently they are all blocked, so the only option is to open them up to vulnerabilities. BTW, this is just a guess, but I do not think we could get away with handling vulnerable processes the way we do without VS's toggling.

 

Vulnerable processes - like powershell - can be abused to infect system - trivially. VS is designed in such a way, that when you need to use vulnerable processes legitimately - in a safe manner - it is easy for you to do so.

 

The .net assemblies are protected.

The .net assemblies are protected.

Poweliks (along with others) drops a payload which VS will block: "In the case of malware like Poweliks the dropper file does not download a payload file that needs to remain active on the computer. Before the dropper file deletes itself it is programmed to write all necessary code to the Windows registry of the local computer. Hence there is no secondary payload file to take a sample of as all computer instructions for the malware to persist on the computer are contained in the registry."
https://www.sophos.com/en-us/support/knowledgebase/121370.aspx

I really wish people would stop using Poweliks as the "fileless malware" example, and find a exploit that can actually do the things you are describing.

As far as hollowing a processes, I did a poc on this thread several pages back, and it is not an issue for VS: "The overall technique is very simple. A malicious process executes, creates a benign looking process (svchost.exe, lsass.exe, …) in a suspended state."

https://www.trustwave.com/Resources/SpiderLabs-Blog/Analyzing-Malware-Hollow-Processes/
http://www.codereversing.com/blog/archives/65

I thought we had an understanding that we should not use hypothetical scenarios . If someone can bypass VS, then great, let's do it, I will help!

 

Hehehe, try telling that to r41p41 .

http://voodooshield.com/artwork/bored.mp4

 

I am not sure if CET remembers this or not... but a while back when I implemented the Parent Process feature, he warned me that it is not possible to do so... and from what I remember, I believe he was consulting with another security developer from a different security product while we were discussing this, and they were helping me and giving me advice (I could be wrong about that... but from what I remember, that was the case).

Anyway, I was not sure if it was possible or not, but it was important to me from a user-friendliness standpoint to implement the Parent Process feature, if there was any possibility to do so, but only if I was able to do it safely. It took me 30 or so hours, but after a lot of trial and error, I finally created a mechanism that worked.

Now, there is a chance that I did not do everything correctly, and if there is a way to bypass VS, then we need to make some changes. Until that happens, there is no reason to specify 60 or so vulnerable processes, when you can just handle this globally... especially since handling this globally is more secure and applies to ALL of the thousands of files, including the 10-20 new vulnerable processes that will probably be "discovered" in the next year or two.

 

ROFLAO...

 

I am certain there is a way to bypass VS... there HAS to be, and believe me, I have tried.

The thing is... we have to take SOME calculated "risks" (although they are not actually risks if nothing can get through), otherwise the computer will be locked up way too tight and people will not want to use VS... Including me .

But seriously, let's find a way to bypass VS!!!

 

I think there is too much paranoia that VS will be bypassed. Such a thing would be quite improbable. If it does happen, then it happens - and it will get fixed.

 

See my signature.

 

Adam, the guy who I have mentioned on this thread several times has found 3 or so bypasses. And the only other one was on a rundll32.exe mistake I made in a beta version that a client of mine was running.

And in all fairness, I did not have to mention either of these publicly .