VoodooShield/Cyberlock

VT "Access Denied" = non-privileged key or privileged key has been restricted by VT

Don't you just love having to chase this stuff ?

 

Hehehe, do you guys remember what happened the last time someone claimed that they could bypass VS? . I spent a few hours trying to reproduce his test, and in the end, his bypass was unable to spawn an executable payload, so his bypass failed... I still have the video if anyone would like to see it. I posted my video on his blog, but obviously he removed it.

Since nothing is bulletproof, I am certain that something can bypass VS, and I will be curious what it is. If someone has a bypass, please feel free to post it so we all can try it, just be sure it is a real bypass that actually works… you do not want to be known as the boy who cried wolf. But I am not going to waste my time trying to piece together his testing methodologies... but odds are, something is flawed in them.

It is hard to see what is going on in the post, but all I see is VS blocking a .tmp file and some standard windows files. If someone sees something that I am not seeing, please let me know! Thank you!

 

It is difficult from post.

I tried my best to get sample...

 

It's in Korean:

 

Even if we found the .tmp sample, I doubt that would help... I think we need the original file that spawned the .tmp file. Otherwise, it would probably not work, and for sure would not be a valid test.

 

Thank you TH! BTW, I will try to catch up on any posts that I missed soon, if there are any specifically for me that Vlad did not answer. Thank you!

 

You're right...

 

https://translate.google.com/transl....kafan.cn/thread-1936040-1-1.html&prev=search

 

@VladimirM
I can reproduce at will the blank pop-up on my machine (Win 7 Pro 64, VS in 'Scan and Allow' mode) when running FoolishIT dMaintenance Home Edition maintenance app, which runs cleanmgr.exe and other routines. Blank pop-up appears twice, once when cleaning updatususer temp files and again when running cleanmgr.exe.
Have PM'd you developer log. Hope you can see something there.
Not sure but it may be when this program is running dismhost that these blank pop-ups appear?
Edit: Tried taking snapshots but having difficulty capturing screen with active blank pop-up (presumably VS because of the shape of the box) - just seems to capture the screen and loses focus of the blank pop-up.

 

hjlbx found the .tmp payloads and sent all 3 payloads to me, they were all ransomware, and one specifically was teslacrypt.

The whole point of VS, specifically the "anti-exploit" feature, is to block the payload, in which it did... otherwise the person would have posted screenshots of the ransom demand note and the encrypted files, hehehe, not the VS prompts that shows it blocking the payloads.

I realize that VS's "anti-exploit" feature is not as "sophisticated" as the products that specialize in blocking the 24 or so exploitation techniques, but then again, if ultimately their goal is to block the payload, which I understand is the case, then why not just block the payload? That is... I would think that the chances of something going wrong is a lot higher when trying to cover 24 exploit techniques, instead of just blocking the payload. We can always add features and new techniques to our lock if we need to, but so far we have not seen a need to do so.

 

Yeah, exactly, it certainly would not hurt to do so! Specifically Conhost.exe, Taskhost.exe, PresentationHost.exe and Dllhost.exe and especially if they are child processes of a web app. Who knows, maybe we can make it so that a web app cannot spawn ANY windows child process... although we would have to think this through, we do not want to break anything .

I will say that the person was close to bypassing VS... if they can just get the payload to run and show the ransom demand note and the encrypted files, then they successfully bypassed VS .

 

Hello
I got the log, however there are no something useful in the log. For the next VS release I added additional prints to the log, so hopefully it will help to catch the issue.
Meanwhile please send me the following information:
- The settings you use
- VS state (ON, OFF, Smart, Scan&Allow, etc.)
- Program you run
- OS
- If you can send me the whole content of C:\Program Data\voodooshield (all .dat file) maybe it will help to reproduce

Thanks in advance

 

This is one of the reasons why Emsisoft adopts the approach - just block the payload.

One cannot rely upon a dedicated anti-exploit soft alone; a solution such as VS is the foundation upon which other security solutions are added.

The primary purpose of adding an anti-exploit when VS is installed, is to mitigate shellcode exploits.

There is remote, funky risk that shellcode exploit could potentially mess with white-listing solution on Windows.

 

Vlad,

Anything in my log showing why VS and IE locked up?

Thanks,
Dave

 

So this is how the wildcard feature will be implemented.
When user adds new wildcard cmd rule:
1. Go over all entries:
1.1 If existing entry is not wildcard and it match the new rule (including action) - delete the entry
1.2 If existing entry is not wildcard and it match the new rule, but doesn't match the action - leave it
1.3 If existing entry is wildcard and it doesn't intersect the new rule (that mean there is no any cmd that can match both rules) - leave it
1.4 If existing entry is wildcard, it intersect the new rule and match the action - leave it.
1.5 If existing entry is wildcard, it intersect the new rule and doesn't match the action - warn user that the new wildcard cannot be added and consider to change the old entry or the new rule.

When there is a cmd executed that needs to be checked against rules:
2. Firstly check all entries without wildcard - if there is any match, then act by the action of that rule (either block or allow)
3. If there is no match in step 2 - go over wildcards. If there is any match, then act by action of the wildcard. Put attention the cmd cannot match 2 wildcards with different actions, because of 1.5. However it can match 2 or more wildcards with the same action, but there is no problem with it.


I hope that I explained it clearly. Please tell me if it seems to be good enough before I'm starting implement it?
Put attention that the only "priority" here is that firstly the matching is against precise rules (without wildcards) and then, if no match, against wildcard rules. And there is also a defense mechanism that doesn't allow user to add 2 wildcard entries that might get the same command with different action, i.e. this one will not be allowed:
ALLOW - ping 10.0.*.5
BLOCK - ping 10.0.0.*
command ping 10.0.0.5 -

Thanks

 

Hi
Nothing. In the log all programs, commands, etc. requests were proceed by VS and doesn't seems like it blocks anything.

 

It appears sound method and prioritization.

Refinement and finalization will be trial-and-error... LOL.

 

Have PM'd you the info.

 

Not sure I am up to validating the logic! But I know you have thought through this - let's go with it!
When you say 'When user adds new wildcard cmd rule', would that include right-click editing an existing rule?

 

Can anyone give some more info about this exploit? It appears to run certain system apps but for what purpose exactly? And it's not clear if VS, ERP and AG blocked the payload or not. But yes, it would be cool if you could control parent-child process creation, because browsers (and other appss) should not be able to launch processes without user control.

 

I just supplied the dropped files from the exploit.

The actual exploit is a webpage exploit - but I cannot get the URL from the OP.

 

VS, ERP and AG all blocked the payload... the payload blocks are clearly posted on the thread for all 3 products.

I think the point that the OP was trying to make was that there were certain windows processes that the exploit spawned as well... but he remarked that he did not seem to know why, or what was going on (from how I read the translation). Yeah, we might as block child processes of web apps... we can at least try it to see if it breaks something or not... I cannot think of a reason why we would not want to. Then again, the whole goal of VS is to safely allow as much good stuff as possible, without prompting the user... so maybe we can play around with it and figure out the best balance.

 

Yeah, I have always heard that shellcode exploits might be problematic for VS or the anti-executables, but I have tested against many, many shellcode exploits in the past, and they were all blocked. If you find one that slips through, please let us know, thank you!

 

Dan & Vlad,
Have you seen this?

https://www.wilderssecurity.com/thre...y-to-separate-malware-from-safe-files.383774/

 

OK thanks, so in fact none of the apps were bypassed? The way I understood it is that the spawned system processes were probably needed in order for the bypass technique to work. But if the payload was blocked, then the bypass clearly failed. And yes, browsers and other vulnerable apps should normally not be able to spawn other processes, unless it's needed like a Flash plug-in or PDF reader.