VoodooShield/Cyberlock

Emsisoft Internet Security is among the other vendors who use ObRegisterCallbacks (I believe) which another member has already suggested and provided details for. I believe they use it at least... AVG, Avira, Avast, ESET, and many other vendors rely on that method too. It would also allow him to obtain the process ID of the process attacking his process via PsGetCurrentProcessId.

 

I note that the Script used to demonstrate the vulnerability was launched as "part of" a permitted program--it does not matter if it was a child, a macro, or injected code. It matters that the application was considered "safe to run".

We also note that under at least one professionally run test--I'm sorry, it's too close to my bed time for me to search back to find the reference--VS was scoring 100% detection/stop, one of only 3 or 4 IIRC.

In my experience, the low-impact bits are simple to handle, but the bits with highest impact are inordinately difficult to deal with. And Dan is going for the one thing which can target VS, the bit with highest impact. Unfortunately, the approach to the threat must be draconian, since the risk assessment is #5, extreme. Not because it happens all the time--although it could--but because the damage would be so catastrophic. And BTW, I write risk assessments as part of my job.

Others with more knowledge than I have pointed out that almost every AV out there has a robust self-defense module. It would be foolish of Dan to ignore the hole in the fence. IMHO it would also be foolish to give users an OFF switch, simply because too many of them would use it simply to avoid the perceived inconvenience post-lockdown. And then complain bitterly that VS doesn't work.

However,

I have to disagree. The attack will be via a permitted "safe-to-run" application, and by that stage it will be too late do to anything other than lock down and reboot, simply because we do not know what else the attack is doing while attempting to kill VS: it is perfectly possible for a process to have more than one stream AFAIK.

Having said that, I fell Dan would be wise to generate a boot-time warning that the box has been penetrated, indicating the "parent" process and clearly stating the need for a remediation.

And after all that, I do wish Dan had released 3.54 before starting the self-defense module. I suppose I'll just have to bite the bullet and suck the bottle, probably on Friday evening when I'll have time to undo any oopses.

 

If I can optionally disable self-protection, then a targeted malware could do the same... eh?

 

I do admire and thank you for sharing knowledge, but if he implemented self-protection properly using the methods which I personally suggested in more extensive detail a few days ago, it would not matter if a process is trying to attack the VoodoShield processes or not because every attempt would fail. In other words, to put it the simplest: if ObRegisterCallbacks is used to it's full potential, NO user-mode code execution will bypass it without exploiting Windows.. Easier said than done.

Of course there is more to it, but the actual service process (VoodoShieldService.exe) won't be vulnerable to some other user-mode exclusive attacks, so protecting it from kernel-mode alone should be sufficient and strong.

 

The first time the system locks up on a "common" user, they are going to freak out and ask to uninstall it. Supposedly this product was to be targeted at average/common users, it has become too complicated to even think about placing it on a novices computer. The product will suspend a process and then ask the user for input on what to do with recommendation. Still, it is far from perfect and sometimes not enough information to make the choice "for an average user".

As mentioned before, and by Dan himself, this product is supposed to be a companion product, not a stand alone, it was designed to be a optional UAC replacement not a full fledged suite.

I can not advise users around my area to use this product in its current state "not just because its a Beta" but as i stated above, it is becoming novice user unfriendly. Sure it works ok for those with experience, if that's the audience Dan wishes to target, he will find sales to not be as wide spread.

This will be my last input on this product and in this thread. It is a shame to see what was a great product head down this road. Yesterday it was this problem, today its another, it will be never ending until those that started with this project no longer recognize it, all because of a POC "proof of concept" posts like the mentioned script above that is not even in the wild, leaving the developer to chase down possible theories instead of stabilizing the product.

@VoodooShield i wish you good luck with your mission.

 

Just do it properly or do not do it at all... The product doesn't need useless self protection, don't add it for now, no problem!

+1000000000000000000

Yeah I am done on this thread too, no more replies from me unless I am mentioned or quoted. No point tryna give advice when it's ignored.

I gave details on how self protection can be done properly for the process/process' thread protection, that's a start. @VoodooShield I suggest you go back and actually acknowledge it.

Gl with your mission

 

So far the last stable version on Voodoo's site is 3.53. I believe that version has no self protection.

 

Guys, this is simply an experimental feature... it might work, it might not. Sure, there are other self-protection mechanisms (which can be bypassed) that we can add as the initial layer of self-protection, but wouldn't it be nice to have a backup system in case they failed?

My point is, why even implement a self-protection mechanism at all, if you know it can be bypassed?

I have a lot of on-site work to do today, but I will be back a little later.

 

"The thing I really like about VoodooShield is its simplicity." See P40 - https://www.wilderssecurity.com/threads/voodooshield.313706/page-40

I hope that is the aim, protection through simplicity, even though the effort by the developer may have to deal with complexity to attain that outcome.

 

So... that's why called: beta! Not for all!
(latest stable version: 3.53)

Keep going Dan!

 

+1

 

Above all, DON'T PANIC ....Think of it as a concept, an experiment, it will all end well in one way or another.

 

Pete, I will pm you the macro, and you can test for yourself. Just change the process that is being killed, and the path of the payload. Also, make sure that a test payload exists in that path. We can add code to automatically download the payload to your drive, but this is just as easy.

Besides, what really matters is if the payload is blocked or not... which VS scans and blocks it.

I really have to get going... I am running late, talk to you guys soon!

 

Can you tell me if my version of Appguard is the Enterprise version? AppGuardSetup-4-4-6-1.exe

It must be because I terminated the Appguard agent service not Appguard gui application with task manager and could not open any other apps. I had to do a hard start a simple reboot didn't work for me.
I know there is a lot of people still using this version and I don't know if Appguard 5.0 has this same protection or not.

 

Well, common user here finds the comments of mWave, gorblimey and Achelous very interesting, if poorly understood. And from a common user's perspective, a self protect mechanism is great, b/c all it takes is just one documented in-the-wild bypass and if you thought life was obnoxious before..... Is one making VS a little too cerebral? Actually, why wouldn't one want to bypass VS--if a user is savvy enough to use it in the first place, maybe there's some juicy stuff on the machine worth trying to get to.

Anti-executable with self protection, elimination of little used features, optimization of scanning.

 

What, you mean Dridex? File-less malware? Yes, and also read the replies to those queries. Why not try to cover all bases now, and there's always the stable 3.53 to fall back on. You all are making this so much more difficult than it should be.

 

Try and stop the service holding the VSScanner.sys driver, it'll work without a problem; then you can delete the service.

Spoiler: Info

The "bypass" briefly mentioned by @Achelous was written by me, feel free to ask him yourself. I didn't want to post anything initially because I knew it would be denied as being valid or I would have got a random ban, but oh well.

@Peter2150 If you'd like, I can send you a test sample today which you can run on a Virtual Machine (most preferably, however it won't damage anything except prevent VoodoShield from working) with the beta version of VoodoShield which contains the self-protection (or use the stable release); the lock-down will not be triggered however the protection provided by VoodoShield will be eliminated. The actual processes don't even need to be touched.

Now if you could deploy this through a macro then it'd be perfect. I'm not spending time doing this, I wrote the code in C++, therefore you will initially have to allow it to run. Although since this is a self-protection bypass, meaning it has to be running to work in the first place, this should not be a problem.

"Patiently waiting for the mWave bypass… coming before 3/26/2017!" - VoodoShield signature. Yes, well it did come before 3/26/2017, it came on the 3/21/2017. Happy now...

 

No, yours is same as mine, AG "home". You won't have access to AG Enterprise and enterprise version doesn't have Guarded Apps.

About v5 i have no ideas, only @Lockdown can answer you. So from your test, and you are the second to confirm this, seems to be that the locking self-protection of AG is for all versions, which make it even greater

 

Peter
The first time I tried to end the service , it recreated itself too. I had to click end a few times , then it finally took. Or try Process explorer or another. All I know is it works for me and maybe guest also.