People were indeed speculating however there is one thing when people are discussing theories on whether a products feature will be bypassed or not, and there is another when people are discussing about how a product can be bypassed due to their not being an existent feature to block such a discussed attack in the first place.
Please let me elaborate this point further.
Let's take Kaspersky for example. They have a feature called Application Control. Now a bad speculation would be for someone to come forward and say something along the lines of "Bypassing the Application Control feature is really easy if you do <this> and <this>" without them having actually tested it themselves, or even researched the monitoring/protection scope of the feature. Especially if they are claiming that they've found a way to manipulate a protected registry key when the process was being restricted from doing such an action... In this case,
they are claiming that they can bypass a feature which actually EXISTS in the product without providing any evidence -> Bad!
Now let's take VoodooShield in this example and apply it to the speculation which was going on about the blocking capabilities towards the Eternal Blue exploit; VoodooShield does not have a real anti-exploit mitigation feature, it is pretty much nothing more than an anti-executable and this is even proved in the video you posted yourself when you attempted to bash other vendors like AppGuard when you got fed up with people not laying down a red carpet to your product because they preferred another. In this case, the speculation was that the system was already attacked and VoodooShield had failed because the Eternal Blue exploit was successfully deployed since it had managed to create a thread within the address space of lsass.exe (remotely) to execute the attackers code -
does VoodooShield have any capabilities to detect thread creation within lsass.exe, and filter to decide whether a thread should be blocked from being created within lsass.exe after check-ups to decide whether that thread should exist to execute the code it was created to execute, or not? The answer is
No.
If someone comes forward and says that
they can have a process spawned without it being blocked by VoodooShield if it should have alerted the user to ask whether that program should have been allowed to run or not without providing any evidence ->
Bad! Why? Because the process blocking feature actually exists within the product, therefore real evidence is needed, not just speculation of HOW they would do it.
The only thing VoodooShield can do is prevent a process from being spawned. Period. It really is that simple. There's no point in you trying to pretend that VoodooShield has more capabilities than it really does just because people have speculated as opposed to testing in-existent features.
There is absolutely no point in people testing VoodooShield against a modified use of External Blue because unless a new process is being spawned to execute the malicious code, obviously we know that VoodooShield will block the process from spawning unless they have found a way to exploit the Windows kernel-mode callbacks from user-mode (easier said than done by a long shot, probably worth a lot of money and we are talking in the thousands due to how extensive such an exploit would really be).
At the end of the day... If someone can use the exploit to gain code execution within lsass.exe they can execute the code that the blocked process would have executed instead of trying to spawn another process to do it; in this scenario, your product would be able to absolutely nothing because if it COULD it would have prevented lsass.exe from executing the malicious code which was injected by the exploit (and then was being ran on the newly created thread which was made remotely, also by the exploit) in the first place. The very first video where we see the additional process attempting to be spawned by lsass.exe (which gets blocked by VoodooShield) backs all of this up, that is evidence right there! There is no need for people to put on their Windows Internals hats and spend time trying to test it when the evidence has already been shown in the very same video you created to bash other products and try to prove that Voodoo"Shield" is the best. Ohhhh how the tables turn...
Clearly you do not know about code injection and how it works otherwise you would be more educated on this subject and this entire argument on both Wilders Security and this forum wouldn't have happened how it did, the same way you know more than me about Metasploit. I would love to test this out just to prove you wrong although I am not experienced with Metasploit and quite frankly I neither care about it, I stick to Windows myself. But the facts are already laid out from when you first uploaded your video of VoodooShield blocking the backdoor installation (which was only possible since it required an additional process to be spawned, and obviously VoodooShield was able to control this since it is an Anti-Executable product).
The funniest part about all of this must have been when you claimed on Wilders Security that VoodooShield could prevent the installation of a kernel-mode backdoor, which is partially true to an extent although due to the wording used it is also partially a lie. Here is the original quote for anyone interested:
The correct wording would be that VoodooShield blocked a process which was not allowed by the user from running; VoodooShield does not decide which programs should run based on what behavior it will execute, you do not have dynamic methods of identifying and intercepting a program's behavior. The only control your product has is showing a score based on your Ai engine when a question is displayed to the user on whether they should run it or not, which is their decision. If they allow the program to run, the code can execute fine without any interruptions and can execute any malicious code the process wants without a problem as long as the process running has the correct privileges to do what it needs to do. Therefore, in the case of this scenario, if the injected code into lsass.exe performs the rest of the malicious activity WITHOUT spawning another process on the remote thread, VoodooShield will have nothing to report to the user and will be able to do absolutely nothing to protect the user from further attack. It all comes down to new process execution at the end of the day.
It really doesn't take a genius to understand the entire situation nor admit where he is wrong and apologize to numerous people for trying to make them look like a fool and cover-up the truth to save reputation and product sales.
Now there are two things you can do right now:
1. Quote me in this post and quote other members like Umbra explaining how they are wrong and how you are right regardless of you not knowing the slightest thing about code injection (it seems) because you seem to believe that a new process HAS to be spawned by lsass.exe, and keep defending yourself with the excuse of people speculating instead of testing an anti-exploit feature which is in-existent (where your advantage is that not many people here or on WS have XP with Metasploit it seems, me included).
2. Grow a pair and be a man and admit that this entire thing evolves around process execution as opposed to making dumb statements about how VoodooShield can block kernel-mode backdoors (wrong, it can block a process, not the behavior). At the same time as doing this, you can apologize to members like Umbra and have this entire discussion ended on good terms.
It isn't always about being the "better" person, no one is going to dump your product just because it cannot block the real exploit from being deployed. The backdoor installation being blocked from within VoodooShield is a PARTIAL BLOCK, if anything a partial "virtual patch", because if an attacker adapts it to how I mentioned in this thread (and anyone with the experience to deploy the attack as it already had been should know how on code injection to do it without needing another process spawned) then whatever protection you claim you have is gone and in-existent as far as the infection see's it.
Without that being said, I think VoodooShield is a good product at what it does and I do not intent to bash the product, nor am I. Other products also failed like AppGuard, it isn't the end of the world. The problem is when an argument like this occurs for weeks and weeks on edge and many things are misunderstood, fake features are mentioned and just total bollocks is polluted in the air because someone wants to be seem "right" and cannot take being "wrong".
Good day sir.
