WannaCry Exploit Could Infect Windows 10

MS states that the exploits employed by WanaCry would not have worked against Win 10 1607+ versions. So lets test this out.

For this testing, I am using this test tool: https://github.com/countercept/doublepulsar-usermode-injector . The details of this test tool is explained here: https://www.countercept.com/our-thi...rmode-analysis-generic-reflective-dll-loader/ .

The author states the test tool contains all the original code of the DoublePulsar exploit which has been enhanced to perform memory based reflective .dll injection using any .dll. This in itself is of note since past reflective .dll injection required a special crafted reflective .dll.

-EDIT- Helps if one thoroughly reads the author's write-up. He is using the original DoublePulsar payload which does an enhanced memory-to-memory reflective .dll injection. This is what I thought from day one. So whatever is currently loaded into Metasploit is bogus since that vers. is using rundll32.exe to load the .dll.
​

Not only does the test tool support DoublePulsar's original APC use but the test tool can be run using the CreateRemoteThread method. For my testing, I used the original APC method. The author additional states that although this test exploit runs in user mode versus kernel mode, it shouldn't affect any of it functionality. Let's get on to the testing details.

All testing was performed on a fully patched Win 10 x64 Home ver. 1607.

The first test I did was against calculator.exe which runs as an AppContainer process in Win10. The test tool was not successful in performing any process modification activity as best as I can determine with calculator.exe abnormally terminating. Glad to see that AppContainer works as designed.

Next test was against a non-AppContainer process, notepad.exe. The test tool creates a suspended child process of it and successfully injected RUExt.dll into it as shown in the below dump of the suspended notepad.exe process screen shot. RUExt.dll BTW is a Revo UninstallerPro x64 .dll I randomly selected. At this point, notepad.exe also abnormally terminated. I have e-mailed the developer about the abends but appears he is on vacation for two weeks. So I don't expect a response till then. My hunch is the abending is by design to prevent the test tool from being abused. In normal malicious reflective .dll injection, the parent process would be suspended, the suspended injected child process started as a stand alone process, and the original parent process terminated.

So at this point barring further details from the test tool developer, I would say all versions of Windows are possibly vulnerable to a DoublePulsar exploit using reflective .dll injection. Also I didn't receive "a peep" from Eset Smart Security ver. 10 on the execution of the test tool or any of its activities.



-UPDATE- I created an ESET HIPS rule to determine if it would detect the reflective .dll injection via APC. It did. I knew from previous testing it would detect via CreateRemoteThread mode.

Somewhat academic at this point since one is not going to create a like HIPS rule for every running process. Actually that would be possible if I switched to training mode for a period of time and then to interactive mode.

-UPDATE- 6/13/2017

I have ran enough tests with a consistent crash due to:

BEX64 - Fault Module = StackHash_86eb
​

that DEP on Win 10 x64 ver. 1607 is being triggered for the parent notepad.exe process when the DoublePulsar exploit is trying to modify its memory. I do have DEP set on for all system and app processes except those specifically excluded. It could also be due to CFG which is enabled for notepad.exe and almost all Microsoft processes except for .NET and a few others.

Whether DEP/CFG would trigger if the exploit was running from kernel mode is unlikely I believe.

​

 

I did some more testing yesterday and I must say this DoublePulsar expoit .dll execution is one of the most ingenious ones seen.

For starters, I changed the .dll I was using to something more appropriate. I used one that displays a message box that states you've been pwnd. Next, I did what I described previously. After the parent notepad.exe abended, I suspended it. I then resumed execution of the .dll injected child process and terminated the parent process. No message box displayed? Now I have the full picture of what this exploit is doing.

DoublePulsar hijacks a thread in the parent process and patches its memory to allow it via APC to execute the malicious .dll in the suspended child process. So short of detection of a memory violation which appears to be the case for Win 10 ver. 1607+, the only way to detect this exploit is when the reflective .dll injection is done to the suspended child process. As stated previously, Eset HIPS has this capability but only if a specific rule has been created for the process to prevent process modification. Previous reflective .dll injection discussions in Wilders yielded that most HIPS's and behavior blockers do not have the capability to monitor suspended process modification activity.

 

@itman I definitely appreciate all of the great details that you've shared on this topic as well as many others, so your insight and opinions are greatly appreciated. Anyway, so in your testing scenario here with the example that you are sharing in this post, you were pointing DoublePulsar toward notepad.exe as the initial point of exploitation? Is notepad.exe the default target generally or is that something that you had done specifically for your testing? I am curious about testing MemProtect against this but many of the details are scattered across the web and quite honestly some of the details are above my knowledge when it comes to memory exploitation. Thank you for your time.

 

Everything published to date indicates DoublePulsar exploited lsass.exe to gain the credentials and privileges it needed for further malicious activity. And indeed MemProtect would probably protect against a like user mode memory exploit. Doubtful it or Eset for that matter would prevent like activity if it originated from the kernel.

-EDIT-

What makes DoublePulsar unique is it used memory based reflective .dll injection to inject a non-reflective .dll into a suspended child process. In other words, that .dll is not executable by the child process. To be so, it would have to be a reflective .dll and the child process PEB and other memory control areas modified for the .dll to execute. It is this later activity that most security software monitors; not just the injection of a .dll into the child process since it is non-executable code at that point by the child process.

 

Also I am doubtful that Win 10 CFG caused the abend in the parent notepad.exe process. Below are two articles detailing CFG bypasses on Win 10:

https://improsec.com/blog//bypassing-control-flow-guard-in-windows-10
https://improsec.com/blog//bypassing-control-flow-guard-on-windows-10-part-ii

The second link is of most interest in that it notes that not all Win 10 system .dlls are compiled with CFG. The ones that aren't, can be used be used for exploitation activity. The message box .dll I am using although validly signed I strongly suspect was not compiled with CFG. Will have to check this out more.

 

lsass.exe was chosen surely because most security softs won't interfere with it since it is a critical process.

 

Good news for anyone "losing sleep over" if a like user mode exploit using DoublePulsar techniques would work against lsass.exe or for that matter, any process running with system privileges. As I suspected, any access to those processes will be blocked. For the user mode exploit to succeed, it would first have to acquire like system privileges. Whereas gaining admin privileges in Win is somewhat trivial, gaining system or trusted installer privileges are not. Of course, a like user mode exploit could be embedded in something you install.

Again if an exploit can run from the kernel and bypass PatchGuard, it is game over.

-EDIT- Below will give you system privileges among a number of other ways noted in the article:

https://hackmag.com/security/elevating-privileges-to-administrative-and-further/

Must be run with admin privileges. Setting UAC to max. level would detect any initial hidden elevation to admin level activity.

 

Although this test seems interesting and has important information, but there is one issue with the statement I quoted. Doublepulsar is not an exploit! Doublepulsar is a backdoor, which can be installed by the exploits in the Shadowbrokers leak, like Eternalblue ... And once Doublepulsar backdoor is installed, it can be used to drop more malicious code in DLL format to the victim system. DLL injection (reflective, APC based) is not an exploit technique, it is code injection. Totally different things.

 

Thank you... I have a quick question. If a security product is able to block the Doublepulsar backdoor, is it relatively safe to assume that the exploit Eternalblue will have a difficult time executing a different malicious payload, without the security product blocking it?

 

FYI - except from my previously posted link:

Additional stated here:

https://zerosum0x0.blogspot.com/2017/04/doublepulsar-initial-smb-backdoor-ring.html

And here:

https://www.nopsec.com/blog/shadow-broker-leaked-equation-groups-hacking-tools-lab-demo-analysis/

If I spawn a suspended child process, inject code into it, then execute that code from the parent process all the previous being done from memory it has all the characteristics of an exploit whether it is formally classified as one of not. Except in this case, it doesn't need a vulnerability.

 

Lets take the activity from the top:

1. Spawn a child process from the parent process. Nothing malicious about that since numerous process do like activity; browsers, Abode Reader, etc..
2. Malware payload injects code into the suspended processes. There are numerous examples showing security solutions ineffectiveness against this. First, many don't by default monitor suspended processes. If they do, they are monitoring for modification activity in regards to making that code executable within the suspended process as I explained previously.
3. Execution of the injected code in the suspended process by the parent process. Well, the parent process created the suspended process. As such, it has complete control over it and its activities are not monitored by security software.

No. 2(pun intended) is the issue as it has been for some time.

Finally, DoublePulsar created the backdoor to run the payload to allow it to perform the above activity unimpeded from kernel mode. The point of this testing is to show that like activity from user mode can be likewise effective regardless if a backdoor is employ or not.

-EDIT- Also if a backdoor can be set, user mode payload can be run remotely bypassing all local detection methods of it.

 

Malware that gains admin privilege basically gets control over the system, by-passing all security measures to block it.

Once that happens, game over.

 

What you describe is still not an exploit. Because in this attacker model, as an attacker, you can already execute malicious code on the machine. In a real exploit, the attacker first does not have any code execution ability, but due to the exploit, attacker can start some malicious shellcode.
On a very high level, an exploit (buffer overflow, format string, use after free, null pointer dereference, integer overflow, ...) is something where the attacker sends some DATA to a service (e.g. SMB, FTP, HTTP) or to a client (browser, FTP client, Office Word, etc), and due to vulnerability in the service/client part of the data will turn into code (this is the shellcode payload), and this malicious code gets executed. I wrote 10 exploit in the past 1 year, trust me on this.

The only exploit where the attacker already has code execution ability is a local privilege escalation exploit, when a user is blocked from running code with admin/system/root level privileges, but the attacker can elevate privileges due to a vulnerability. But I don't even believe Doublepulsar can be considered a privilege escalation exploit.

If you don't believe me, ask the authors of the referred blogposts, and ask them the following:
"Eternalblue and Doublepulsar: Which one is a backdoor and which one is an exploit?"

 

If a security product is able to block loading the Doublepulsar backdoor installation, attackers have to come up with different ways to install another backdoor. This is far from trivial, but possible.

I guess you refer to this video:

https://www.youtube.com/watch?v=lLChVsNt1fY

I recommend you to test Voodooshield against Fuzzbunch+Eternalblue+Doublepulsar+Peddlecheap, and not just against the Metasploit port of the Eternalblue exploit. Peddlecheap DLL loads in a different way than Meterpreter DLL, and Peddlecheap might not be blocked by Voodooshield ...

 

BTW - I found what I believe is a Win 10 vulnerability in regards to lsass.exe. It does indeed have a .dll not compiled with CFG making it vulnerable to a ROP bypass as noted in reply #55 posted links. This is in contrast to notepad.exe whose .dlls are all compiled with CFG

 

"However, one particularly interesting feature is the GANGSTERTHIEF module that shows the authors were very aware of these detection techniques themselves. In fact, GANGSTERTHIEF can actually be used to detect PEDDLECHEAP itself:"

https://www.countercept.com/our-thinking/analyzing-and-detecting-the-in-memory-peddlecheap-implant/

 

Agreed.

 

@Zoltan_MRG do you have some infos how the EternalBlue/DoublePulsar can be delivered in the target network by a remote attacker from outside the network?

All articles/videos start their demonstration when the EB-DP exploit is already on a compromised machine in the same network, then they obviously easily abuse SMB to propagate to other machines.

Seems no one cares about how it was dropped in the first place...

 

exact , once it get NT AUTHORITY\SYSTEM who cares what happens later...the machine is owned.

 

I was thinking more along the lines of skipping the backdoor installation completely and replacing it with a different malicious payload, but yeah, I appreciate your point about having to find a different way to install the backdoor.

Yes, that video is a brief demonstration, but as you are probably aware, there has been a massive discussion on this subject, so I am certain that everyone appreciates your insight and clarity. On a side note, there are a couple of things that VS could have done better in the Metaploit port, and I am fixing them, but overall our mechanism worked as expected for this test.

That is really interesting about the Fuzzbunch / Peddlecheap port, it sounds like there might be an issue I need to address ... thank you for mentioning that, I will test asap. Thanks again!

 

Unless we know how the exploit is dropped on the network/machine, there is no point in blocking what it does once executed, what is important is stopping it to be executed in the first place.
It is what all those articles and demonstrations "forgot" to mention...

using an analogy :

"i have no interest on how hampering a fever once i get sick , but only how to prevent being sick."

 

All that is need is an open/vulnerable inbound port. RDP which is frequently used in corp. environments is a favorite target. Past history has shown that RDP is not properly secured in many corp. environments.

 

i saw only one article mentioning the source, and guess what ? it was an classic exe... any decent security tool would block it...

Indeed. it is why this is a enterprise-oriented attack using enterprise-oriented vulnerable features.
99% home users are behind NAT routers so there is no way the attacker can access the machine behind it unless he compromised it by the usual way (classic dropper, drive-by Download, etc..etc...), so any decent security apps would prevent it (unless the user is an happy clicker).

 

Hey stop alluding to me!!!