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

[danb]

it is why i keep saying testing some apps needing tailored setup with default setting is totally useless.

I see what you are saying, but exploits and attacks do not discriminate... security software, in my opinion, should sufficiently protect the computer out of the box. What if you tailor everything perfectly, except you miss one thing, and there is a bypass?

 

[danb]

There is a check box column called ASR that did get cut off. I played hell getting anything to work with it on. I have a few Office apps that worked with it. I finally quit testing it, as I seem to recall it was breaking Windows. APC isn't in the list. Looks like that's a very bad omen for the test, but maybe another one will get it...

Yeah, that is not good then... I highly doubt it will block it then, but we will see. I am not an exploit expert, but I think there is very little, if any overlap in coverage. For example, DEP protection will do nothing for a heap stray attack. But we will see, we might be surprised .

 

[Deleted member 178]

I see what you are saying, but exploits and attacks do not discriminate... security software, in my opinion, should sufficiently protect the computer out of the box. What if you tailor everything perfectly, except you miss one thing, and there is a bypass?

Then that is my fault to misconfigured my apps. there is no rules saying apps must be used as default.
Default is to ease the installation of the soft and avoid it to break the system at first run, beginners will let it at default, advanced users will tweak it.

security softs are tools, they give you mechanisms to use , the devs hardcoded or set some rules by default to protect against what they believe is basic attacks,the soft should prevent, now if the user want more deep and tight security , it is to him to tweak the soft based on its mechanism; and no security tools can be used against all attacks .

 

[AtlBo]

I have already tested VS about 10 times, but I suppose I can test again .

JK Dan. I thought you would never miss an opportunity to market your product . You gotta be a salesman sometime you know lol.

 

[Orion]

Lot of AV vendors are coming up with new ways to combat these Exploits or atleast avast is:
- Tiny Firewall for blocking EternalBlue exploit - (internal) It is a part of StreamFilter, turned ON/OFF by Webshield
https://forum.avast.com/index.php?topic=203375.0

 

[danb]

Lot of AV vendors are coming up with new ways to combat these Exploits or atleast Avast is:
- Tiny Firewall for blocking EternalBlue exploit - (internal) It is a part of StreamFilter, turned ON/OFF by Webshield
Avast Beta 17.5.2298

Interesting... very cool to know!

 

[Andy Ful]

@AtlBo yep, all at "always on" if possible.

Anyway all this debate about what may block EB-DP or not is useless now, MS released a patch fixing this issue.

I am not sure. SMB protocol is like a Swiss cheese. We can see soon EB-bis.

 

[danb]

I ran the EMET lsass test and EMET blocked the exploit… however, as you can see in the video, the system crashed (not that it matters… at least the system was protected).

On in interesting side note, I completely forgot that EMET has Recommended Settings… which do not provide lsass protections. And like most security software, users will most likely run EMET with the Recommended Settings.

http://www.voodooshield.com/artwork/EMETWizard.PNG

Here is the video:

BTW, if anyone believes that they completely understand every aspect of this attack, they are either godlike or delusional:



(and this does not even demonstrate every aspect of the attack).

For me, it is simple… either the attack is within AE’s scope, or it is not. If a security product can prevent malicious activities or a data breach, that is really what matters.

 

[Andy Ful]

I ran the EMET lsass test and EMET blocked the exploit… however, as you can see in the video, the system crashed (not that it matters… at least the system was protected).
....

Maybe the system crashed because of EAF setting? In @AtlBo post EAF is unticked.

 

[Visa]

I ran the EMET lsass test and EMET blocked the exploit… however, as you can see in the video, the system crashed (not that it matters… at least the system was protected).

In the video we can see that the lsass.exe process was terminated (so it would have crashed which caused the termination for sure). Lsass.exe is a critical process therefore I would have assumed it would have triggered a BSoD with the error code CRITICAL_PROCESS_DIED but seems it notified you instead of enforcing a sudden BSoD. Either way, that must have been the cause of the critical error message demanding a restart.

The crash in lsass.exe most likely occurred due to the code injection from the exploit being blocked by EMET. Something in memory was messed up and caused lsass.exe to crash. God knows what messed up

 

[danb]

@mWave , Yeah... exactly, something like that.

I just retested with EAF and ASR disabled, and EMET did NOT block anything at all... all of DP's tools were completely available. I did not test to see which ones worked, but it kinda looked like all of them would. But I really am tired of testing... I have a video if someone really wants to see it.

 

[AtlBo]

I ran the EMET lsass test and EMET blocked the exploit… however, as you can see in the video, the system crashed (not that it matters… at least the system was protected).

Dan just enabled EAF for lsass.exe on the system here, and no crash. It and ASR were the only two I had disabled. Usually, when I disabled one, it followed a crash, so maybe the system will crash later. Hopefully not. Rebooted and ran some applications and it seems fine.

ASR has a special setting that you may have noticed, but I doubt it. Here is a screenshot. To see this information->from the window opened by the apps button top left of main GUI, you double click on lsass.exe once it's set up to see the mitigation switches and there is some information about some of the mitigations:

I may have done research on ASR mitigation, but I can't remember. I think it requires modules and Internet Zones Exceptions to serve a function, although I'm just not sure. For example, Office Word and Excel are pre-configured to block Flash*.ocr. I suppose that is the flash module, so that Flash content is blocked. Actually, I don't know how you got ASR to activate. Did you add a module? I was required to enter a module into the modules area (bottom of the pic above) for the mitigation to enable.

On in interesting side note, I completely forgot that EMET has Recommended Settings… which do not provide lsass protections. And like most security software, users will most likely run EMET with the Recommended Settings.

Valid point. There hasn't ever been energy in deploying EMET in a configured setup. They're 90%+ probably running it stock on the networks where it's being used.

Thanks again for the test.

 

[Andy Ful]

I must also note, that all tests with Dan's setup are inconclusive to me in the aspect of blocking DoublePulsar installation. Simply, the Metasploit console gives too little information about it.
There is a clear info that EternalBlue succeded, but there is no information at all about DoublePulsar, either when the attack was successful or not. Moreover, in the end of attack, we can always can see the info: Remote code executed. But, what could be executed if DoublePulsar was not installed?
So, from such video test no one can be sure if (1) DoublePulsar installation was blocked or (2) DoublePulsar failed to install a payload or (3) the payload was run by DoublePulsar but failed to compromise the system.
The last scenario follows from Zoltan video test:
Video Review - Voodooshield Free vs EternalBlue/DoublePulsar/Peddlecheap

Edit
A couple of weeks ago, I posted the simple method to make such test conclusive by running the DoublePulsar check script (available on GitHub), after blocking the Meterpreter session.

 

[danb]

Dan just enabled EAF for lsass.exe on the system here, and no crash. It and ASR were the only two I had disabled. Usually, when I disabled one, it followed a crash, so maybe the system will crash later. Hopefully not. Rebooted and ran some applications and it seems fine.

ASR has a special setting that you may have noticed, but I doubt it. Here is a screenshot. To see this information->from the window opened by the apps button top left of main GUI, you double click on lsass.exe once it's set up to see the mitigation switches and there is some information about some of the mitigations:

View attachment 157758

I may have done research on ASR mitigation, but I can't remember. I think it requires modules and Internet Zones Exceptions to serve a function, although I'm just not sure. For example, Office Word and Excel are pre-configured to block Flash*.ocr. I suppose that is the flash module, so that Flash content is blocked. Actually, I don't know how you got ASR to activate. Did you add a module? I was required to enter a module into the modules area (bottom of the pic above) for the mitigation to enable.



Valid point. There hasn't ever been energy in deploying EMET in a configured setup. They're 90%+ probably running it stock on the networks where it's being used.

Thanks again for the test.

Very cool! I did not play around too much with ASR... as you were saying, it requires further tweaking.

 

[AtlBo]

So, from such video test no one can be sure if (1) DoublePulsar installation was blocked or (2) DoublePulsar failed to install a payload or (3) the payload was run by DoublePulsar but failed to compromise the system.
The last scenario follows from Zoltan video test:

Good point. I would guess that the episode was blocked over something to do with the injection of lsass.exe. This would suggest that something else happens first but it's only speculation.

 

[danb]

I must also note, that all tests with Dan's setup are inconclusive to me in the aspect of blocking DoublePulsar installation. Simply, the Metasploit console gives too little information about it.
There is a clear info that EternalBlue succeded, but there is no information at all about DoublePulsar, either when the attack was successful or not. Moreover, in the end of attack, we can always can see the info: Remote code executed. But, what could be executed if DoublePulsar was not installed?
So, from such video test no one can be sure if (1) DoublePulsar installation was blocked or (2) DoublePulsar failed to install a payload or (3) the payload was run by DoublePulsar but failed to compromise the system.
The last scenario follows from Zoltan video test:
Video Review - Voodooshield Free vs EternalBlue/DoublePulsar/Peddlecheap

Edit
A couple of weeks ago, I posted the simple method to make such test conclusive by running the DoublePulsar check script (available on GitHub), after blocking the Metrpreter session.

The easiest way to tell is if the DP tools are available or not .

I really wish other people would test too, then everyone would understand what I have been saying all along.

This is actually why I avoided in depth conversations about the attack for the most part. I mean, if someone is not going to bother running the tests for themselves, why even get into a discussion with them about specifics of the attack?

BTW, I am not picking on you or anyone specifically, I just would have strongly preferred that other people perform the test as well, so we can all be on the same page.

 

[Andy Ful]

Dan, please run the DoublePulsar check. The result will not harm VoodooShield. No one expects that Anti-exe can stop Ring0 -> Ring0 installation. Furthermore, even with the negative result, VoodooShield will still block some DP tools (like Meterpreter).

 

[danb]

Dan, please run the DoublePulsar check. The result will not harm VoodooShield. No one expects that Anti-exe can stop Ring0 -> Ring0 installation. Furthermore, even with the negative result, VoodooShield will still block DP tools.

I actually started to run the DP check, but then I got sidetracked.

Here is some example usage of the test from github...

root@kali:~# python detect_doublepulsar_rdp.py --file ips.list --verbose --threads 1
[*] [192.168.175.141] Sending negotiation request
[*] [192.168.175.141] Server explicitly refused SSL, reconnecting
[*] [192.168.175.141] Sending non-ssl negotiation request
[*] [192.168.175.141] Sending ping packet
[-] [192.168.175.141] No presence of DOUBLEPULSAR RDP implant
[*] [192.168.175.143] Sending negotiation request
[*] [192.168.175.143] Server chose to use SSL - negotiating SSL connection
[*] [192.168.175.143] Sending SSL client data
[*] [192.168.175.143] Sending ping packet
[-] [192.168.175.143] No presence of DOUBLEPULSAR RDP implant
[*] [192.168.175.142] Sending negotiation request
[*] [192.168.175.142] Sending client data
[*] [192.168.175.142] Sending ping packet
[+] [192.168.175.142] DOUBLEPULSAR RDP IMPLANT DETECTED!!!

Let me ask you this... if the session was blocked from being created in the EB / DP attack, do you really think the above would succeed? I could be completely wrong about this, but I HIGHLY doubt the test would pass.

And even if the test did pass (which I do not see how it could), that does not change the fact that the malicious DP tools are not available.

That is what is sooooo frustrating to me... if you guys would just run the test, you would see what I mean.

 

[danb]

Let's make a deal... if you run the Metasploit test, I will run the DP check test, and we will post the results. Deal?

 

[AtlBo]

Dan, please run the DoublePulsar check. The result will not harm VoodooShield. No one expects that Anti-exe can stop Ring0 -> Ring0 installation. Furthermore, even with the negative result, VoodooShield will still block some DP tools (like Meterpreter).

Honestly, I think VoodooShield is coming out a huge winner in the light of the testing Dan is doing in spite of the apparently at least partial exploitability of Windows out of the box.

This testing you do Dan puts a really solid perspective on what can be counted on. I know I can say I for one appreciate seeing the results. Good information