WannaCry Exploit Could Infect Windows 10

http://www.darkreading.com/endpoint/wannacry-exploit-could-infect-windows-10/d/d-id/1329049?

 

Windows 7 was probably targeted because of it's market share. I guess that attackers didn't think that targeting other OSs is ATM worth the trouble.

EDIT: wrong Windows version

 

Have you read the whole white paper?

This bit makes me pleased I'm using the latest version of Windows 10...

https://www.risksense.com/download/datasets/4353/EternalBlue_RiskSense Exploit Analysis and Port to Microsoft Windows 10_v1_2.pdf

 

Yes. Win 10 AU and CE have "upped the ante" as far as exploitation goes.

-EDIT- However, I wouldn't get overly confident with Win 10's exploit protection or lack of it as shown in this study which included AU as far as I can determine: https://insights.sei.cmu.edu/cert/2...tect-insecure-applications-like-emet-can.html

 

I'm running AU as the stable version.

People who run an older, unpatched version of Windows 10 could be vulnerable.

Considering Windows 10 receives mandatory updates - it shouldn't be an issue.

 

Agreed. That's why I have Hit man Pro.Alert and VoodooShield.
However the CU also added more mitigations to the mix, which the white paper said would stop the modified ETERNALBLUE exploit.

 

No reason to not update to the CU. It just runs WAY better than the previous builds of Windows 10.

 

Agreed. Just upgraded a new laptop to CU last night after being on AU. Way better with performance.

 

Perhaps I'm misunderstanding what you mean with "Patient Zero", but from what I've read you don't need any browser exploit or email attachment to exploit systems via EB because it will automatically exploit systems that are not protected correctly with firewall or AV/HIPS. It does this by sending "specially crafted packets", which causes remote code execution, see first link.

In other words, EB will directly exploit the SMB service, and will run DP which runs WannaCry with the worm component (or other malware) that spreads to other PC's in the network. So if you can't block the exploited system process like lsass.exe from running malware (via rundll32 and cmd.exe) the system and network is owned. That's why I said that AG wouldn't protect the system, since it doesn't monitor lsass.exe and other system services from spawning other processes. At least, if I understood correctly.

https://en.wikipedia.org/wiki/EternalBlue
https://blog.avast.com/avast-blocks-wannacry-ransomware-1-million-times-150-countries

 

Yikes! Now you're cross-thread posting quotes.

Let's take it from the top:

1. The NSA use a product called "Fuzzbunch" which is the functional equivalent of Metasploit which I assume was used in the WanaCry attacks although not the only means to do so.
2. The attacker then searched for vulnerable devices that had an inbound port open. I assume some recon. was done at this point to determine the vulnerability of the network such as many Win 7 PCs that are vulnerable.
3. Once the attacker had an IP address, it could deploy the EternalBlue exploit.
4. EnternalBlue created a backdoor using tunneled access via port 445. At this point the attacker has unrestricted remote access to the targeted PC.
5. The next phase using the created backdoor was to deploy the DoublePulsar exploit. This allowed the attacker to remotely run rundll32 to inject a .dll into lsass.exe which in running in kernel space.
6. Once in the network the worm could spread to all devices within and to external networks.

Any talk about blocking rundll32, cmd, or anything else locally is crap since none of the processes are running locally and cannot be monitored by anything locally.

Again, you need to read this article in detail: https://www.exploit-db.com/docs/41896.pdf

 

I wasn't allowed to post in the other thread but at least I'm on topic now.

But anyway, you basically said the exact same as me. Except for the fact that you mention rundll32.exe being run remotely? You do realize you need to somehow be able to execute a payload on the system, and this can be done by using system tools like rundl32.exe and cmd.exe, but it's also possible to drop files to disk and then directly execute them via lsass.exe or other exploited process. So I'm not sure what is your point exactly.

 

No, you do not. That is why a backdoor is so dangerous. Think about RDP for example.

RPC over SMB allows for numerous remote communication activities:

Security Account Manager service
Local Security Authority service i.e. lsass.exe
Remote Registry service
Service Control Manger service
Server service
and various other services​

 

Yes but how is this relevant in this particular attack? You say "Any talk about blocking rundll32, cmd, or anything else locally is crap", but I don't see what you're trying to say with this statement. Fact of the matter is that these system processes were used in this attack, and security tools should monitor them.

 

I am not going to join this discussion, but if you guys do not want to test for yourselves, you can at least see the attack in action, and see why blocking rundll32.exe is vital.

https://www.youtube.com/watch?v=W-LfzQyYsFg

5:28 – Shows the hacker tools that are available when lsass.exe is able to spawn rundll32.exe

9:44 – Shows the hacker tools that are available when lsass.exe is blocked from spawning rundll32.exe

Application control mechanisms (SRP / AE) are designed to block unwanted applications / payloads, and their mechanism either blocks the kernel level malicious payload, or it does not.

 

One more reason why windows10 blows.

 

Cool, thanks for the new video.

 

I see EMET 5.5 was running at defaults, not that it would have mattered apparently.

Add: this software, or much of it, is supposedly going to be incorporated into Windows Security system in the fall. Even though this was run on a Windows 7 virtual machine, I'm not optimistic or enthusiastic given that zero days seem to be a bit more out there nowadays. Sticking with HMPA and no one needs to convince me about VoodooShield's capabilities, for sure.

 

DoublePulsar didn't use rundll32 to inject the .dll. It used APC.

Here's a detailed analysis of the actual .dll injection performed by DoublePulsar: https://www.countercept.com/our-thinking/analyzing-the-doublepulsar-kernel-dll-injection-technique/

Here's a detailed analysis of an improved reflective .dll injection performed by DoublePulsar: https://www.countercept.com/our-thi...rmode-analysis-generic-reflective-dll-loader/

 

https://www.wilderssecurity.com/thr...-could-infect-windows-10.394550/#post-2682779

"Again, you need to read this article in detail: https://www.exploit-db.com/docs/41896.pdf"

Pages 9 and 10 of the above 41896.pdf... "We must select the architecture of the Windows 7/2008 target machine that we are going to impact (in my case it is x64). Then, we’ll do the most important part of this step, we are going to indicate that we want to perform a DLL injection (Option 2 – “RunDLL”)."

But these are just details, what really matters is if the payload succeeded or not:

https://www.youtube.com/watch?v=W-LfzQyYsFg

EMET: Payload succeeded / Session created / Backdoor tools available
VS: Payload did not succeed / Session was not created / Backdoor tools are unavailable

Please run the test and you will see what I mean.

 

@VoodooShield you just can't stop...

point 5 is what i understood and wanted to confirm, thx.

about point 2 , if the machine's IP you mentioned (point 3 ) is behind a NAT router so only the router IP is public , how the attacker would access a machine port?

 

I wasn't talking about the DP injection, I was talking about when lsass.exe is already hijacked by DP, it can spawn any child process that it needs in order to get malware running and to perform other stuff. From what I've read it will spawn system processes like rundll32.exe and cmd.exe, and not to forget the processes that were associated with the WannaCry ransonware.

 

The way I visualize it in a simplified way, is that there are 3 stages:

1 EternalBlue
2 DoublePulsar
3 WannaCry

So basically, security tools get 3 chances to stop this particular attack. Any "top quality" tool should at least be able to stop it in stage 3. The only problem is, if you can't stop stage 1 and 2, and attackers will use in-memory malware, then you might be in trouble, as described over here:

http://blog.secdo.com/multiple-groups-exploiting-eternalblue-weeks-before-wannacry

 

Maybe.

EternalBlue was a kernel exploit that was able to bypass x64 PatchGuard on all version of Windows other than Win 10 AU and CE. Once that happens, it is game over for all practical purposes. From the kernel, it can do pretty much anything it wants to do.

Although there are numerous detailed analyses on the internal operational details of EternalBlue and DoublePulsar, I have yet to see anything concrete on how EternalBlue entered a network. Another infamous NSA worm, Stuxnet, required loading from an external device. At this point, I have to assume that a perimeter network vulnerable existed that let EternalBlue in and it was able to bypass some heavy duty Enterprise front-end security mechanisms.

What is most illuminating about this incident is what is not publically being said.

 

That is also how i see it, also we have to consider "does the top quality tool mechanism is made to prevent those types of attacks?"
- If yes but they failed to stop the attack, it is a bypass;
- if not designed to prevent it and they (obviously) failed , it isn't.

some people believes that every softwares should block everything...this a too simplistic understanding based on fantasy.

indeed , no denial possible on that.

Yes this is what i wanted to know too.

That is what i kept asking : "what is the initial vector and was it a conventional dropper?". Once we know that we can know what measures (tweaks, tools, etc...) would properly stop the attack from even starting.

exact.

EB need an IP inside the network to propagate, if he only sees the IP offered by a router/hardware firewall or else, it won't be able to propagate, for that it needs to be dropped inside the network via another vector (mail, usb, browser, etc..) . this is my understanding.

 

Much of it is irrelevant to home users who haven't the foggiest notion of what SMB is they never touch, disabled or not.

Some of those vulnerabilities effect corporate networks more because computer resources are run in a way they wouldn't be at home.