Video EternalBlue and DoublePulsar application whitelisting test

Status
Not open for further replies.

danb

From VoodooShield
Verified
Top poster
Developer
Well-known
May 31, 2017
1,284
YES

you know exactly that in computing installing and connecting are separate actions.

i install a browser, it is present on the system, if i shut down internet , it cant connect but it is still installed. You can't argue with that...
Hehehe, but "installed" assumes that the browser at least has the ability to connect, right?

If you install a web browser on a machine (for the purpose of browsing the web), what good is the web browser if it never has the potential to connect to the internet?

This truly is semantics, so it is probably better that we not go down that road ;).
 
  • Like
Reactions: erreale
D

Deleted member 178

Hehehe, but "installed" assumes that the browser at least has the ability to connect, right?

If you install a web browser on a machine (for the purpose of browsing the web), what good is the web browser if it never has the potential to connect to the internet?

This truly is semantics, so it is probably better that we not go down that road ;).

yes, and a out-of-the-box system aren't supposed to have any software on it made to monitor execution of rundll32.exe.
if it was, the attacker will change the way the attack performs.
we can go forever like that. :)
 

danb

From VoodooShield
Verified
Top poster
Developer
Well-known
May 31, 2017
1,284
yes, and a out-of-the-box system aren't supposed to have any software on it made to monitor execution of rundll32.exe.
if it was, the attacker will change the way the attack performs.
we can go forever like that. :)
I totally agree ;).
 

Andy Ful

From Hard_Configurator Tools
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,077
And Umbra, for the last time, DoublePulsar is not an exploit ;).
That is right. If one takes EternalBlue separately from DoublePulsar, then the first is an exploit and the second is a backdoor payload. EternalBlue does not require DoublePulsar - it can run other payloads as well. In WannaCry attack the EternalBlue code was adjusted to run only DoublePulsar, so one can say informally that it was 'EternalBlue & DoublePulsar' exploit.
 
  • Like
Reactions: simmerskool

Andy Ful

From Hard_Configurator Tools
Verified
Helper
Top poster
Developer
Well-known
Dec 23, 2014
7,077
Let's ask an expert about DoublePulsar:
***
Conclusion

There you have it, a highly sophisticated, multi-architecture SMB backdoor. The world probably did not need a remote Windows kernel payload this advanced being spammed across the Internet. It's an unique payload, because you can infect a system, lay low for a little bit, and come back later when you want to do something more intrusive. It also finds a nice place in the system to hide out and not alert built-in defenses like PatchGuard. It is unclear if newer versions of PatchGuard, such as those in Windows 10, already detect this hook. We can expect them to be added if not.

Usually we only get to see kernel shellcode in local exploits, as it swaps process tokens in order to privilege escalate. However, Microsoft does many networking things in the kernel, such as Srv.sys and HTTP.sys. The techniques demonstrated are in many ways completely analagous to how usermode shellcode operates during remote exploits.
***

zerosum0x0: DoublePulsar Initial SMB Backdoor Ring 0 Shellcode Analysis

In fact, 'kernel Control Flow Guard' in Windows 10 can stop DoublePulsar, so one can say (not Microsoft) that DoublePulsar uses some kernel vulnerability, in prior Windows versions, when hiding in the system. Furthermore DoublePulsar uses techniques analogous to usermode exploits.
It is a kind of semantics - officially, DoublePulsar (in WannaCry attack) does not exploit Windows vulnerabilities, so technically it is not a Windows exploit.
 
Last edited:

Visa

Level 1
May 31, 2017
42
because no one else was testing, they were simply speculating
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.

so don't say "VS block DP to be installed", it can't , however VS can prevent DP to do further malicious tasks. which is a good thing.
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:
VS blocked the installation of the kernel level backdoor ;).
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. :p:cool:
 
5

509322

Other products also failed like AppGuard

AppGuard did not fail. AppGuard is not an anti-exploit, it is SRP. If a person does not understand how SRP works, then they can make idiotic comments based upon ignorance - as has been shown time-and-time again on these forums.

In the case of the SMB network exploit that results in WannaCry executing on the system, AppGuard blocks the WannaCry executable - which is its intended behavior.

Also, just because a security software blocks something doesn't mean the underlying issue is resolved. In the case of EB\DB the exploit is not patched until the Microsoft security updates are applied. If the vulnerability is not resolved, then it will remain - no matter what security soft is installed. And if you disable that security soft even temporarily, then it could very well result in complete and persistent system compromise. We look at security problems in their entirety in advising users how to protect and remediate systems.

Anti-executables and SRP are post-exploit protections.
 
Last edited by a moderator:

Visa

Level 1
May 31, 2017
42
AppGuard did not fail. AppGuard is not an anti-exploit, it is SRP. If a person does not understand how SRP works, then they can make idiotic comments based upon ignorance - as has been shown time-and-time again on these forums.
When I said that AppGuard failed I did not mean it failed to do its job, I apologize for my wording. What I meant was that it neither blocked lsass.exe from becoming compromised (even if it was supposed to), since apparently Dan has a big problem with people preferring SRP like AppGuard compared to his anti-exe called VoodooShield.

I only mentioned it so Dan doesn't have a mental break down and think I was just ganging up on him, which isn't the case. I just have a big problem with the entire discussion based on what he has said from the start and decided to make a post explaining the lsass.exe situation, 100th time lucky.

Anyway, you're right about that, my mistake there.
 
5

509322

What I meant was that it neither blocked lsass.exe from becoming compromised (even if it was supposed to), since apparently Dan has a big problem with people preferring SRP like AppGuard compared to his anti-exe called VoodooShield.

The product tested is not designed to block code injection in that particular case. The product does not monitor command lines. SRP, at its most basic level alone, is not designed to do it. AppGuard's memory protections are designed and implemented using best practices so as not to cause issues. The product provides the user flexibility in applying further protections if they so wish. Like any specialized security product, one cannot rely on it alone to protect every part of a system that is vulnerable to attack. This is why AppGuard users have combined it with a HIPS or an anti-executable for years. An SRP combined with one of those type programs is very high protection.

AppGuard works extremely well according to its design and intended purpose. The product provides very high defense against a wide range of malware types.

Saying or even suggesting that a tool - such as a screwdriver - is a failure because you think it should also be a saw is utter nonsense.

AppGuard LLC could care less what Dan thinks or says pertaining to this whole matter.
 
Last edited by a moderator:

danb

From VoodooShield
Verified
Top poster
Developer
Well-known
May 31, 2017
1,284
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. :p:cool:
In the Metasploit port test, VS blocked the malicious DoublePulsar backdoor tools, and when it did so, the DP tools were completely unavailable to perform any malicious DP tasks, such as data exfiltration, along with many others.

I have not ran the Fuzzbench port test myself, but from what I understand, VS blocked the malicious DP backdoor tools in this test as well.

VS is not the security vendor that falsely claimed that it has a "Patented Exploit Prevention for Endpoints". VS's feature is clearly defined in the VS owners manual as blocking the payloads of exploits.

This is exactly what I have been saying from the very beginning, and I have not lied about one thing, and I do not owe anyone an apology. If anything, people owe me an apology for incorrectly speculating in the following thread (and others).

Is that true, that default deny security solutions can stop the EternalBlue & DoublePulsar attacks?

I do not need a red carpet, but since everyone was incorrectly speculating and not testing, I decided to run the test.

The end result of the test is that VS blocked the malicious DP tools in the EB/DP attack... and without these tools, DP is rendered useless. If these tools are not blocked by the security solution, then DP is free to conduct a host of malicious activities, such as data exfiltration.

BTW, do not confuse a strong, valid argument with a mental breakdown.
 
  • Like
Reactions: erreale

Visa

Level 1
May 31, 2017
42
In the Metasploit port test, VS blocked the malicious DoublePulsar backdoor tools, and when it did so, the DP tools were completely unavailable to perform any malicious DP tasks, such as data exfiltration, along with many others.

I have not ran the Fuzzbench port test myself, but from what I understand, VS blocked the malicious DP backdoor tools in this test as well.

VS is not the security vendor that falsely claimed that it has a "Patented Exploit Prevention for Endpoints". VS's feature is clearly defined in the VS owners manual as blocking the payloads of exploits.

This is exactly what I have been saying from the very beginning, and I have not lied about one thing, and I do not owe anyone an apology. If anything, people owe me an apology for incorrectly speculating in the following thread (and others).

Is that true, that default deny security solutions can stop the EternalBlue & DoublePulsar attacks?

I do not need a red carpet, but since everyone was incorrectly speculating and not testing, I decided to run the test.

The end result of the test is that VS blocked the malicious DP tools in the EB/DP attack... and without these tools, DP is rendered useless. If these tools are not blocked by the security solution, then DP is free to conduct a host of malicious activities, such as data exfiltration.

BTW, do not confuse a strong, valid argument with a mental breakdown.
You're right, VoodoooShield did block the malicious DoublePulsar backdoor tools, but what did it fail to block? The EternalBlue exploit - I neither would expect VoodooShield to prevent it since it is a file-less remote attack which works in-memory and thus no new process is spawned to execute the loader code for the injection to occur into lsass.exe. The only reason VoodooShield intervened is because lsass.exe spawned another process to setup the installation of DoublePulsar, but this doesn't change the fact that the EternalBlue exploit was still successfully deployed since lsass.exe became compromised due to remote code injection. You can see it on your original video.

VoodooShield is not a security vendor that claims it has "Patented Exploit Prevention for Endpoints", instead it is a "security vendor" which is being ran by someone so blind to his own words who is too ignorant to admit where he was wrong and give apologies where it is due, to people like Umbra for example who have already been proven to be correct by MRG themselves - you were the one who even wanted the test to be done by them. Although, when a developer of an anti-executable product is throwing words around like "VS blocked the installation of the kernel level backdoor" to try and make his product seem better than it really is, then you know you are using a product from a shady developer with lack of experience.

The thing that you are not really getting the grasp of is how code injection works, and how the code injection attack within the EternalBlue exploit could be adapted to be a completely file-less attack occurring within lsass.exe. Honestly, since you are the developer of just an "anti-executable" product, I simply do not expect you to be knowledgeable on such a topic because it is clearly too advanced for your standards for you to be able to understand it correctly, hell, even partially... As proven throughout all your posts in the discussion relating to the lsass.exe process being compromised. To elaborate further, if someone has knowledge on code injection and can successfully deploy this attack for a genuine malicious purpose as opposed to testing, they should know how to have the code executed within the process being spawned by lsass.exe completely within lsass.exe.

Good idea, let's let the big boys focus on the big topics and you can go back to your GUI development and social marketing management. No problem. :)

BTW, do not confuse a strong, valid argument with a mental breakdown. You haven't really acknowledged and responded to my post properly anyway, you've just tried to change the conversation.
 
  • Like
Reactions: Deleted member 178

danb

From VoodooShield
Verified
Top poster
Developer
Well-known
May 31, 2017
1,284
VS is not an anti-exploit. We describe very clearly in our owners manual that we block the payloads of exploits. Which is exactly what happened in the test. What part of that do you not understand?

MRG agreed with me on the attack vector, and disagreed with Umbra, which was one of Pete's and Umbra biggest arguments from the beginning. But you do not see me doing any back slapping over that, do you?

MRG agreed with one post from Umbra, and I agreed with most of that particular post as well. MRG knows I have a very strong argument... let's wait and see what they say in the end before anyone jumps to conclusions. My only point is this entire thing is that VS blocked the malicious DP tools... and MRG will confirm this. Other people wanted to change the argument... first they talked about the attack vector, then it was something else, then something else. Just because I do not want to get into a detailed conversation about the attack with people who are too lazy to run the tests for themselves, that does not mean that I do not understand the attack, code injection, etc.

Again, my only point from the beginning is that VS blocked the malicious DP tools... that was the point of the test, and that has been my argument all along. It was the other people who wanted to change the conversation... simply because they were looking for ANYTHING to justify why VS blocked the attack, while other products did not.

Hehehe, who are the big boys? I am assuming that the big boys have security products that blocked the EB/DP attack... so I am confused as to who you are referring to when you say big boys? My software speaks for itself. It did exactly what we claimed and what it was designed to do.

Yeah, I am mainly a GUI dev... but guess what? That is the most important part... simply because application control utilities will never reach the mass market unless they are made to be user-friendly... and this applies to consumer, SMB and enterprise.

Locking the computer is the easy part. Making the lock user-friendly is the magical part.

Everyone needs to quit thinking they are so damn smart, and run the tests so they can see for themselves.


One last thing…

Are you actually implying that people are free to guess and speculate wildly on how various security products would perform in a test, but I do not have the right to take the time to run the test so that everyone can observe the empirical evidence for themselves? Are you kidding me?

You would think that people would appreciate the fact that I took the time to test, and not gang up on me 10 to 1 when they did not like the outcome of the test. Not only that, but they insisted on dragging me into an extended argument that I wanted no part of… when all they had to do was study the videos closely, or better yet, run the tests for themselves.

That is what I love about the VS supporters, they know the truth, and know that I am more than capable of defending myself, especially when the test results speak for themselves. The VS supporters also know that I would be highly disappointed if they were to gang up on one dev 10 to 1, if they would have been unhappy with the outcome of the tests.

You can actually make lsass.exe (Local Security Authority Subsystem Service) a protected process by changing a value in the registry: The things that are better left unspoken | Security Thoughts: LSASS Protection in Windows 8.1 and Windows Server 2012 R2

I am curious as to whether having lsass.exe ran as a protected process through this modification would protect the system against the attack. I would assume it would mitigate the attack but sadly I am unable to test it out so if anyone is capable of testing it or already knows the answer I would be very grateful!
BTW... I could have been a total know-it-all jerk and made fun of you for your HUGE misunderstanding of the attack in this post, like some arrogant people do. Instead, I was nice and responded in a way so that you would not look like a fool. And this is the thanks I get. Here was my response: Video Review - EternalBlue and DoublePulsar application whitelisting test

What you are missing is that if lsass.exe is injected, but yet, it cannot even properly spawn DP, how is it going to spawn a different payload? In other words, if VS blocked DP, why would it not block a different payload? And do not use the words "In-memory"... I am tired of hearing that.

Sure, there might be an attack that get through... but that was not the test that I ran. I ran the freaking test to end the speculation on the question "Is that true, that default deny security solutions can stop the EternalBlue & DoublePulsar attacks?".

If you guys are going to speculate wildly, then do not be upset when I test.

AppGuard did not fail. AppGuard is not an anti-exploit, it is SRP. If a person does not understand how SRP works, then they can make idiotic comments based upon ignorance - as has been shown time-and-time again on these forums.
Yeah, apparently there is a lot of confusion on AG’s scope... what it blocks and what it does not ;).

Is that true, that default deny security solutions can stop the EternalBlue & DoublePulsar attacks?
 
Last edited by a moderator:
  • Like
Reactions: erreale
D

Deleted member 178

VS is not the security vendor that falsely claimed that it has a "Patented Exploit Prevention for Endpoints".
You don't even understand the meaning of that and you quoted Appguard Enterprise... LOL
You clearly have a grudge against AG , so stop mentioning it because you obviously don't have a single clue about how AG works, you used it what ? 10mn to make a botched test, awesome ...

Last warning, you are a dev , if you keep attacking any other developers for improper reasons (like the one of Deterrent) you will suffer consequences, got it?


Yeah, apparently there is a lot of confusion on AG’s scope... what it blocks and what it does not ;).
yes, you are the one confused about it.

MRG agreed with me on the attack vector, and disagreed with Umbra,
where? i never see him quoting me and say he disagreed.

MRG agreed with one post from Umbra, and I agreed with most of that particular post as well. MRG knows I have a very strong argument...
because this post resumed the whole attack and shown your misunderstanding , i was correct, you were wrong to say im wrong, period .

Again, my only point from the beginning is that VS blocked the malicious DP tools..
no your point was saying "VS blocked DP and kernel exploits" , plenty of posts to prove that , you change your wording AFTER the guy of MRG acknowledge my post...hilarious to see you backpedalling...

That is what I love about the VS supporters, they know the truth, and know that I am more than capable of defending myself, especially when the test results speak for themselves.
Your fans didn't have a clue of what we talked, they didn't even participate in the technical discussion , except to cheers you and gang on me...pathethic...

The VS supporters also know that I would be highly disappointed if they were to gang up on one dev 10 to 1, if they would have been unhappy with the outcome of the tests.
but i didn't see you complain when they ganged on me...right?

What you are missing is that if lsass.exe is injected, but yet, it cannot even properly spawn DP, how is it going to spawn a different payload? In other words, if VS blocked DP, why would it not block a different payload? And do not use the words "In-memory"... I am tired of hearing that.
LOOOOOOOOOL you still don't understand hahahahahahahahaha
EB spawn DP > DP inject in lsass.exe which spawn a reverse-TCP connection (rundll32.exe) to connect to the attacker... so if DP is programmed to inject another process out of the scope of VS , it will succeed. GET IT?
you just show your ignorance again...
 
Last edited by a moderator:
  • Like
Reactions: Visa
Status
Not open for further replies.