WannaCry Exploit Could Infect Windows 10

You said "Most security solutions can detect the "misbehaving" rundll32.exe activity done in the Metasploit version." This is simply not true... most of the security products that I tested did not detect the misbehaving rundll32.exe. If you ran the test for yourself, you would understand this.

I never said that "VoodooShield would not detect Peddle Cheap". I said that I needed to test it to find out for sure... but from what I have researched so far, I think there is a great chance that VS will block it as well.

Sophos used the metasploit port that I used in their test...

https://www.youtube.com/watch?v=agFgibQydzg&t=92s

Are you saying that you know something that Sophos does not? And that it is a no-no for them to be posting a POC?

In the end, it really does not matter, because the attack is either within the scope of application control, or it is not. If it is within the scope of application control, then VS should block it. If it is not within the scope of application control, then no application control utility will not block it... the only things that might block it would be an anti-exploit product or a Windows patch.

You are guessing and speculating wildly and making many, many incorrect statements.

Quit guessing and speculating, and start testing.

 

Let's "cut to the chaise" and apply some deductive logic.

Voodooshield states that it can detect the version of DoublePulsar from Metasploit. The DoublePulsar version at Metasploit uses disk based .dll execution from user mode via rundll32.exe.

The real version of DoublePulsar uses the reflective .dll injection method running in kernel mode to inject a non-reflective .dll user mode child process memory . It then uses APC calls running from kernel mode to load the .dll from the child process memory into its user mode parent process memory and execute it.

Therefore we can conclude that Voodooshield, based on its claims, can detect the Metasploit version of DoublePusar. We can draw no conclusion whatsoever on its effectiveness against the "real" version of DoublePulsar.

 

As far as blocking the stand alone Metasploit version of DoublePulsar, any anti-exec or HIPS can do so by simply creating a rule to monitor the start-up of rundll32.exe by lsass.exe. I know of no reason why lsass.exe would be starting rundll32.exe.

 

I thought I posted this link once but will post it again: https://www.exploit-db.com/docs/41896.pdf.. This will perform the exact kernel exploiting, reflective .dll injection, and APC loading done by DoublePulsar.

You need three PCs, one the target unpatched Win 7 x64. The other two are the attacker source machines. One is using XP with Fuzzbunch plus Python 2.6 and PyWin32 v2.12 library installed. The other attack PC needs to be running GNU/Linux or alternatively Kali Linux with Empire and Metasploit installed.

 

If we "We can draw no conclusion whatsoever on its effectiveness against the "real" version of DoublePulsar.", then why are we even discussing this?

You are free to test on your own, so you can experience the same result I did. But if you would rather speculate wildly without testing, I am unable to help you.

 

Sure, and that rule will stop this attack... but what about the next zero day? There needs to me an effective mechanism in place that protects all of the Windows processes.

 

You did post that! But that is not the PeddleCheap port that was recommended by MRG.

PLEASE perform the test from exploit-db.com and prove me wrong.

 

Huh, you mean to say there might be new zero days at some point in time?....I thought given that a few members have been bleating on about this DP fo weeks it was the 'holy grail' of attack vectors and once we have it crushed we would all never need to worry again

 

Let's get on topic ........... Please!

I started my discussion in this thread to determine if a user mode process employing the unique loading of a .dll via APC calls employed by DoublePulsar would work on Win 10 x64 1607+.
At this point barring feedback from the test tool developer which I expect in approx. a week, it appears it does not. Therefore, whether any security solution can detect that method or not is a moot point.

Any discussion of whether Voodooshield can block DoublePulsar in any form on any OS belongs in the Voodooshield thread.

Personally, I am fed up with Voodoshield hijacking threads to promote its product.

 

If people are going to speculate without testing, then I have every right to join the conversation.

 

I think it should be remembered that Dan is a member of Wilders as well as a developer, so its a subject he is allowed to discuss as much as you or moderators (who are also members)

 

Wrong! Voodooshield protection or lack of it was never mentioned or inferred. You just decided into interject yourself into the discussion in that regard.

 

The argument is pointless. You cannot mitigate security failures in systems that have the resources of global corporations devoted to designing those systems with deliberate security weaknesses to facilitate surveillance and intrusion.

 

Post 142!!!!!!

Ya know as I have mentioned a millions times before, I been on this forum longer that only a few other members. I have seen this kind of banter a million times before. Member bashings everybody that can't even write their own security software or code for that matter. The script kiddes that were here when I started are old adults now lol.
All Dan asked was for you all to test yourself. He also said he was going to make some changes for the better after making that test. I am surprised peter started arguing since he has actually tested Voodoo against many malware and it stopped them all. If this BS doesn't stop and be more constructive I will leave for a few years again and see what it is like in 2020.
Dan has been pretty genious to give two free years to all the Wilders members.
I sure hope you don't try bring his moral down and leave this forum.

 

I keep saying this!..

 

Based on the following, it appears it Win 10 x64 CFG that is stopping the test tool from running. Eagerly await the developers feedback.

http://lucasg.github.io/2017/02/05/Control-Flow-Guard/

 

Success with the test tool! Sort of that is.

I first retested the test tool using the CreateRemoteThread option it has. I assumed that option required a test reflective .dll. I happened to have saved one of those from previous reflective .dll testing I had done. So, I used that .dll. The test tool worked. Not a peep from Win 10 x64 1607. I retested this. Test tool did not work - no message box displayed. Nor did notepad.exe abend. Appears CFG detected the activity from the test tool and terminated it.

So for the heck of it, I ran a second test using the same reflective .dll. This time I used the APC call option for the test tool. Whalla! It worked. So I will be e-mailing the test tool developer about this since he stated the test tool using the APC call option should work with any .dll. Note: the message box states "Reflective DLL injection" because its coded that way.

Now what I am posting below is downright scary. There are actually two notepad instances running; one the normal one and one running the reflective .dll which displays a DLLMain message box. I know two instances of notepad.exe are running since my desktop lower toolbar shows that. However, Process Explorer only shows the original targeted notepad.exe instance running. Now that is very scary indeed. Additionally, I observed all activity in Process Explorer and I never saw a suspended notepad.exe process created or the like. Finally, the injected .dll does not show in Process Explorer .dll display indicating no PEB and associated like activity occurred to make it executable.

So folks, you have a test tool to run against your security software and "it's a duzy."

-EDIT- To simulate a DoublePulsar "like" attack w/o the backdoor and kernel aspects, you need to run the test tool remotely from another PC on your network. A few ways to do that are given in this article: https://www.raymond.cc/blog/remote-process-explorer-normally-cost-75-now-free-for-personal-use/ . The LizardSystems remote process explorer link is here: https://lizardsystems.com/remote-process-explorer/ . Of course, you can also use PowerShell and PsExec.

 

Now that I can run the test tool with a reflective .dll, went back and retested against calculator.exe which is running in AppContainer. No dice. It abended with a stack hash error.

So at this point, appears AppContainer will prevent any of this type of user mode memory injection. All bets are off if the injection is being performed from kernel mode.

Now the $64,000 question. Why can't Microsoft develop a like "AppContainer" protection for its system processes instead of relying on privileges alone? Let's call it "SysContainer."

 

Perhaps because that would prevent malware?

 

because Appcontainer is about Integrity Levels and Permissions (called Capabilities).

so from my understanding, you can't run system processes with lower IL than System.

 

Indeed. While AppContainer protects user-mode processes, it's enforcement (AC capabilities, permissions, etc.) is done kernel side.

Low Integrity AppContainer (LI-AC) is next as far as AppContainer dev goes. But as far as protecting more system processes with AC, I don't have anymore info there. I do believe that we will see more shift in that direction though as we've seen recently with font parsing being brought from kernel mode to user mode and protected within AC now. So I expect more AppContainer going forward.

 

I agree 100% with what guest mentioned here.
Another easy test is to ignore Peddlecheap completely, use Fuzzbunch + Eternalblue + Doublepulsar only against a machine protected with Voodooshield. You can even use Doublepulsar to check if Doublepulsar is present on the machine. It is amazing to see how much effort is done here to talk, but noone puts effort into test it. It is super easy to test this, tens of Youtube tutorials are available. I tested this weeks ago, so I know the result, but I would like to see how this plays out.

Please use correct terms. Peddlecheap is not an exploit, it is a malware payload in DLL format. Doublepulsar is not an exploit. It is an in-memory backdoor.

 

So please do everyone a favor and add VS results to your blog post here: https://www.mrg-effitas.com/eternalblue-vs-internet-security-suites-and-nextgen-protections/ .You already tested HMP-A. Also what needs to be specified is at what level the DoublePulsar activity is detected and blocked. Also VS should be run in install default configuration.

Then the results can be debated in never ending fashion in the current thread open on that testing.

-EDIT- I couldn't find a thread for the MRG blog post, so I open one in the AV forum.

 

My thinking was along the lines of the normal running mode would be AppContainer like mode. The OS kernel would escalate on demand to permission level required when process is performing system activity; basically remove from AppContainer status. Then return to protected AppContainer like status when process activity is completed.