VoodooShield/Cyberlock

just to mention, Appguard Business block lsass.exe by default via its MemProtect module, which isn't available in the Home Version.

Not saying , that to use this exploit in Dan's video , the attacker has to know how is your network , if you are behind a NAT router , no way he can know...

Conclusion, this attack is valid only if:

- the target system is attacked via another compromised system in the same network...or the attacker know your IP adress , which isn't very easy task because you are behind a NAT router.
- the target system is ran under Win7 with SMB1.0 enabled.

Since now mostly all system are supposed to be patched , this attack is obsolete.

 

Hehehe, how funny. If this is true, then kindly explain to everyone how VS blocked the installation of the kernel level backdoor .

True, VS does not monitor for the 24 or so known exploitation methods... I found a better method that works great with VS. And it covers all Windows and other processes, so that they do not have to be added manually every 2-3 months when a new one is discovered and abused. In all fairness, I have mentioned that a time or ten on here... and it went largely ignored.

It is not my fault that other people complicate things with less effective methods.

You are free to test all you want... but do not speculate.

 

Correct... THIS attack is obsolete .

 

Are you saying that if a user encounters this exploit in the wild on an unpatched system that it would not be able to run without having your IP in advance, or it would have to originate on the same network? That makes no sense to me.

Edit below: 5/29/17 @ 10:46
How did so many people get infected using this exploit? Did they send out mass request to known IP addresses similar to what a targeted attack would do, but targeting as many users as possible? Is it possible to run the exploit from a webpage?

 

Speculation is the same as Assumption, and we are all familiar with the old adage applied to "Ass/u/me" right

 

IMA... In general, no one seems to get bent out of shape when people incorrectly speculate or assume, but somehow they do get bent out of shape when a test is performed and the truth is revealed.

 

It's good to see that VS was able to block lsass.exe from spawning rundll32.exe. That effectively mitigated the exploit from being able to do any damage.

 

I cannot explain to everyone how VS blocked the installation of a kernel-mode backdoor because it simply didn't happen. All VS did was block the process responsible for installing the kernel-mode backdoor, although it didn't actually intercept and prevent the activity itself... Which takes me back to what I said in my previous post (which you seem to be disagreeing with me on):

If you are claiming that process whitelisting (and then blocking non-trusted programs) counts as exploit mitigation then people could argue that an AV has dedicated "anti-ransomware" protection because it can block a ransomware sample based on its SHA-256 checksum hash... As I would have assumed, this wouldn't work right in peoples minds.

Here is a video which I have just taken:
https://vid.me/B8cc
(or alternatively hosted here for 24hrs: https://a.uguu.se/QZRUwLgVhK8p_voodooshield.mp4 )

In the video above you can see my host OS desktop with two folders... kit and video. The kit folder contains a program called OSRLOADER which is used to load device drivers as services (e.g. for testing purposes), and the other folder contains a device driver called vs64.sys which I also wrote myself. When the vs64.sys driver is loaded it will terminate the VoodooShield processes (this isn't about self-defense however I wanted to add something to verify that the driver did indeed load, or for the sake of the video).

As we can see in the video, VoodooShield did absolutely nothing to stop the kernel-mode driver being loaded. However if I had not allowed OSRLOADER.exe to be allowed when I tested it out before recording then VoodooShield would have popped up asking if I was intentionally allowing the program to run (along with the VoodooAi score). This all verifies the points I have made... VoodooShield is pretty much reliant on process white listing, and this also means that my response at the start of this post about the kernel-mode backdoor is also correct (since VoodooShield doesn't block the installation of device drivers - even if they are unsigned like the one in this video - it can just block the process from starting up and that is pretty much it).

The video you made yourself suggests that VoodooShield already failed the test along with many other products; lsass.exe was successfully attacked. Code was injected into lsass.exe and then this code was successfully executed within the context of the process... The remote code execution exploit was successful. From what you decide to do on from there is your own decision, although obviously trying to spawn another process would flag VoodooShield if it wasn't trusted and the child setting wasn't enabled... Therefore, the test was already failed since an attacker could just execute his malicious code instead of spawning another process to execute the malicious code. If you cannot understand something so simple as this then maybe you should not even be a developer. So much for your "Anti-Exploit" capabilities lol

So sure VoodooShield blocked a malicious process being spawned by lsass.exe and sure it blocked the installation of a backdoor however let's get some things straight:
- Lsass.exe was still successfully attacked and could execute any code it wanted which would not trigger VS unless it spawned another process.
- VoodooShield does not block the installation of kernel-mode components however it can block a process from being executed if it is not trusted which we all already know.

Therefore if we apply a kernel-mode backdoor installation in the previous discussion, so lsass.exe would be attacked from your Metasploit and then the injected code would load a device driver instead of spawning another process to run whatever code, then VoodooShield would obviously not block it. Whereas if you ran a program which was not trusted which would load a device driver, VS would block the execution until allowed... Although, if that process had been previously allowed or was then allowed by the user, then the program can do whatever it wants and VS will not intercept the driver loading.

Absolute joke man. I don't think there is anything more to say. Even in your own video it showed VoodooShield actually failing since lsass.exe was attacked successfully

 

Thank you CET! Yeah, it would have preferred that VS would have blocked the attack even earlier, but this is an acceptable result... especially considering this was a particularly nasty zero day kernel attack.

 

There's a big difference between being a fan of a product and then literally putting your tongue up the backside of a developer.

 

ok the exploit is kinda simple , and it is amazing how crafty are those CIA guys:

1- the attack have to connect to a real system with its true IP adress, obviously being behind a NAT router will greatly reduce the effectiveness.

2- once located, the attack check the target system hoping it has the required "vulnerability" (windows7 + smb1.0), if it doesn't, the exploit is ineffective.
3- once detected, the exploit connect to the machine, drop a dll and break the OS defense via a kernel exploit creating a permanent backdoor.

At this point the target is wide open for stage 2 :

4- the attacker has now a direct path to the target system, any payload can be delivered (and eventually be blocked based on the security software)

This is a network exploit + malware drop , seems it was originally started via a weaponized file or email, then due to its nature spread through networks.

 

Hehehe, in the video you had to allow OSR Driver Loader when VS blocked it, correct? And you are calling that a bypass? Are you kidding me?

I am STILL waiting for the mWave VS bypass. You can talk the talk... let's see if you can walk the walk.

 

i dont see any VS alerts on the video? it was Process Hacker notification, or do i misunderstood what you meant?

 

He did not show when VS blocked OSR Driver Loader... for affect.

Yeah, if VS does not block OSR Driver Loader... then we have a real problem .

 

you didnt understood his point.
He want to prove that VS doesn't have real exploit mitigation (the driver VS64.sys was loaded without any opposition), however it blocked OSRLOADER.exe as a normal anti-exe should do.

If the exploit is loaded via an executable any anti-exe will block it.

 

It's not a bypass and I never claimed it was a bypass. I've literally explained myself as best as I can, you are just either drugged up or have a problem with your brain mechanics.

Let me re-elaborate one final time and hope you have a high enough IQ to understand:
- You claim that VoodooShield surpassed the test in the video you made except it didn't. Lsass.exe was still affected by remote code execution therefore you FAILED the test. It doesn't matter if VoodooShield blocked lsass.exe from running another program or not, the point is that the injected code which was being executed on a new thread from within lsass.exe could have been malicious and since lsass.exe is running under SYSTEM it means a ton of damage can be performed by executing code from within the context of the process (e.g. encryption of a lot of documents, patching of other installed applications placed in protected directories, disabling of UAC, handle hijacking to actually shut down existing installed security products regardless of kernel-mode drivers for self-defense, and so on).
- You claim that VooodooShield "blocked the installation of the kernel level backdoor" however you worded it like VoodooShield actually intercepts and blocks specific activity... Spoiler alert: it doesn't. Blocking a program from running doesn't count as blocking something like that. Sure you are right it did block the sample but at the end of the day if that was a normal scenario then you wouldn't know what the program is going to do and if it was allowed to run then VoodooShield isn't gonna do anything about the behavior it is performing.
- Process blocking is not the same as "exploit mitigation".

In other words, doing things the way you are pointing the direction in would be allowing a program to run and still keeping the system protected. In this case you either allow the program to run or it doesn't and that is all there is too it.

Just go to a hospital

 

No, I completely understand his point. But that is exactly like suggesting that an anti-exploit product should block the payload, even if it was not spawned by an exploit.

That is not how VS works... EVERYONE knows that.

The ONLY thing that matters is that VS blocked the kernel level backdoor from being installed... and this is one of the nastiest zero days that the world has seen. If VS can block this attack, then there is a high probability that it will handle other similar attacks properly as well.

Enough talk... bypass VS.

 

All you have to do is bypass VS, then you will have impressed everyone! Just do it!

 

Agreed!

 

This is EXACTLY what I mean by pure speculation... Why speculate when you can test and know for sure?

 

My understanding of mWave:

Lets put it like this.
Car>OS
Driver>VS
Passenger>Exploit

Passenger is entering the car, pull out a gun, then driver react and stop the passenger - right?

So, to VS block Exploit it should be like this:
Passenger is coming to the car but driver is going out and stop the passenger to go into his car - right?

 

Sorry, I am unable to follow this analogy.

Here is the funny thing... earlier I said this, but obviously mWave and guest missed my point:

"True, VS does not monitor for the 24 or so known exploitation methods... I found a better method that works great with VS. And it covers all Windows and other processes, so that they do not have to be added manually every 2-3 months when a new one is discovered and abused. In all fairness, I have mentioned that a time or ten on here... and it went largely ignored.

It is not my fault that other people complicate things with less effective methods."

Anyway, since a lot of people are speculating, I have the right to do it at least once... wouldn't it be funny and painfully ironic if VS's method blocks the installation of DoublePulsar, but specialty anti-exploit products that utilize the 24 or so exploit mitigation techniques did not? Now THAT would be funny.

 

Huh?

 

My thought exactly.

 

VS does not actually block exploits, it mitigates them by blocking payloads at a later stage. It seems to me VS done a good job for it's intended purpose.

Was EternalBlue able to install a permanent back door?