WannaCry Exploit Could Infect Windows 10

https://www.wilderssecurity.com/thr...-infect-windows-10.394550/page-7#post-2686330

THANK YOU !!!!
so i'm not so "ignorant" after all, like some said...

@VoodooShield you owe me more than one beer !

 

could be possible indeed, there is lot of room to improve Appcontainer functionalities

 

AFAIK processes can't change their permissions ad hoc and have to be rerun with new permissions. So services would have to be shut down and then started with new permissions. Similar with drivers.
At least that is procedure with elevating to admin mode.

 

https://github.com/countercept/doublepulsar-usermode-injector/blob/master/README.md

The DoublePulsar payload is running from kernel mode. In order to run from kernel mode, it would have had to bypass x64 PatchGuard. This activity is the very definition of an exploit.

In order to modify lsass.exe which is running with system privileges via user mode activity, the following would have had to occur. Lsass.exe system privileges were downgraded by the DoublePulsar payload running in kernel mode. Or, the .dll injection user mode actor was running with system privileges.

Perhaps you should post a rebuttal to the Countercept's author posting on GitHub.

 

In the metasploit port test... here are the results:

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

Please look closely at the hacker tools that are available after the attack completes in both the EMET test and the VS test. To me, it looks like in the EMET test, the DP hacker tools are available, and in the VS test, only the EB hacker tools are available. Basically... in the EMET test, you see a list of hacker tools... are they a result of EB or of DP? And in the VS test, you see a DIFFERENT list of hacker tools, are they a result of EB or of DP? Also, in the VS test, why was the session blocked?

Edit: In other words... why am I not able to use the Download command to exfiltrate data from the target machine in the VS test, but I am able to do so in the other tests?

I would be more than happy to run any test... but since everyone is referring to several different tests, please post a link to the exact test you would like for me to perform.

 

I agree... as soon as we run all of the tests, I would be happy if MRG posts the results of ALL of the tests!!!

 

Something along this line:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx

As the Microsoft article points out, PROCESS_DUP_HANDLE cannot be employed against protected processes. I see no reason however why the OS kernel could not do so.

 

Hum ........ This is an interesting find and something somewhat stupidly, I should have examined initially.

As the below screen shot shows, lsass.exe in Win 10 x64 1607 is not a protected process. However, it runs in kernel mode i.e. level 0. As such, it would be impossible for any user mode activity such as DoublePulsar's memory .dll injection to modify lsass.exe in any form. Ditto for any spawning of a rundll32.exe child process by a user mode actor. On the other hand, since the DoublePulsar payload is running in kernel mode, I assume it could access lsass.exe internals and perhaps change it to a user mode process?:

 

Not on-topic, but there is a registry key that purportedly enforces protected process for lsass.exe on W 8 onwards. It is disabled by default.

 

https://technet.microsoft.com/en-us/library/dn408187(v=ws.11).aspx

 

Apparently guest deleted his recent post… but since I spent the time to write my response, I am going to post it anyway…

guest, the point of the original test (https://www.youtube.com/watch?v=lLChVsNt1fY) was to investigate a couple of things:

1. https://malwaretips.com/threads/is-...lblue-doublepulsar-attacks.71722/#post-632722
2. When MRG stated "It is nice that all the AV vendors claim to protect against the ransomware payload, but in case there is a backdoor running on your machine in the kernel level, things are not that great."

And this test was based on the best test that was available at the time, and performed by Sophos: https://www.youtube.com/watch?v=agFgibQydzg

The result of the test is that DP was not installed during the test on the computer that was protected by VS, whereas DP was installed on other machines that were protected by other application control utilities. You are simply looking for a technicality to support your argument and to fit your agenda, now that we are aware of other ports of the test, and have more information about the attack.

Either way, I wouldn't be doing any "back slapping", when VS blocked something in the test that the other products clearly should have blocked.

And again, if we perform a test that is outside the scope of application control, then no application control utility will block the attack... only anti-exploit or windows patches will do so.

 

BTW, you cannot claim that something is successfully installed if you cannot communicate with it, if it is unusable, or the tools are not available.

 

@VoodooShield As Zoltan confirmed, Vs can't protect against the installation of DP , so your claim since the beginning that "VS block the installation of DP" is false.
Vs only block the backdoor to connect to the attacker, which is totally different. (and not a bad thing)
Just admit it, there is no shame to admit mistakes especially when VS wasn't supposed to block DP installation in the first place...

LOL are you serious? i can install a keylogger but the firewall block the outbound connection, so the keylogger isn't installed? come on, gimme a break...
My house was broken by a thief but he stole nothing but hide on the basement, so my house is still safe...? you have a weird logic...
You didn't understood ED-DP from the start, accused me of ignorance, but now you are the one who is wrong, and now you tried to save your face with loops and words play .

No point to keep debating with you, you shown your true colors to everybody , i was right , you were wrong, that is enough to me. Now you can say whatever you want, it will not change the result : VS can't block DP installation.

 

No, I clearly stated from the very beginning that the hacker tools were not available in the VS test, and you wanted to focus on the reverse TCP because it fit your agenda.

It does not matter where the attack is stopped... all that matters is that the attack is stopped. Some products blocked the attack, and some did not.

You can install the software / driver for a printer, but if it is not plugged in, it is not going to work, correct? The printer is not successfully installed if it is not plugged in.

Sure, there are now other tests that might yield different results... but this entire conversation should be based on the test that I performed, and what we knew at the time.

 

not what you claimed , see screenshot.

Nothing much to say. Just admit you were wrong? is it so hard? really?


the point is you mistaken one thing by saying you do another thing. You were just confused , i tried to correct you, you claimed i was an ignorant. Now who is the ignorant?

 

Thanks for the reference.

Now for the next question. Could a kernel mode process modify another protected kernel mode process? I suspect not.

Also appears this option is disabled for good reason:

 

OMG guest!!! You know what I mean. Doesn't installed mean "successfully installed"... as in functioning as expected? What good is it to install something if you do not have access to it?

Really? Your whole argument is based on this one technicality? Ok, from now on, I will use the words "installed, connected and functioning properly" instead of just the word "installed".

You knew exactly what I meant... but you knew that VS blocked the attack, while some others did not, so you spent 3-4 weeks trying to find a single technicality to try to prove me wrong.

 

Keep in mind "the hacker tools are available" is the EXACT same thing as "installed, connected and functioning properly".

 

YES you should have done this far earlier, instead of contradicting me , insinuating i'm a ignorant, by keep saying "DP wasn't installed". If you said "DP didn't connect" , i wont say a word, and all that "debate" won't even exist.

When you talk about something , you must be precise in your wordings, most people in security forums are not specialist or technicians like us. they will interpret your words at the letter,
In MT a guy after reading your words believes now that VS is also an anti-exploit !
You are not a basic member, you are a dev ! devs must be very careful on how they describe and demonstrate things, they aren't allowed to say wrong or vague things.

I always said since the very beginning VS blocked part of the attack (the reverse-TCP), not the previous stages of the attacks (lsass.exe exploitation) . You denied what i said, so yes i did what i have to make you realize you were wrong and that i was not a ignorant fool like you wanted makes me to appears. Sorry if you are bothered that i defend myself.
I succeeded to prove my point, so end of the story for me.

 

You guys are good. There is a lot to be pinpointed with this (outbreak) and it's raised the issue full tops to the surface. Thanks

No matter the driving home of different points-of-view, but because the rest of us probably see it a bit both ways so we'll leave the balance to whoever gives in first on that one to the back n forth at hand.

But both ends of that disagreement/discussion are well worth a ponder IMO.

Without swerving too far off as you mentioned, is the reason it's disabled by default, does it have anything to do with stability in your view?

 

See reply #191

 

Right under the nose and I skipped passed it that close?

Thanks itman.

 

Install
verb (used with object)
1. to place in position or connect for service or use: to install a heating system;

http://www.dictionary.com/browse/install?s=t


You said: "When you talk about something , you must be precise in your wordings, most people in security forums are not specialist or technicians like us. they will interpret your words at the letter,
In MT a guy after reading your words believes now that VS is also an anti-exploit !
You are not a basic member, you are a dev ! devs must be very careful on how they describe and demonstrate things, they aren't allowed to say wrong or vague things."

That being the case... please feel free to, as a Moderator of MT, correct your statement here: https://malwaretips.com/threads/is-...lblue-doublepulsar-attacks.71722/#post-632722

I was tired of people wildly speculating on the subject, so I took the time to run the test, and I ran the test from the demos that were known to us at the time (Sophos video).

Everyone can go back and read all of our posts, so do not pretend for a second that you, or anyone else (including me) understood the entirety of the attack from the very beginning... especially as it relates to reverse TCP.

Hindsight is 20/20, but at the end of the day, VS stopped the DP tools from being available in the metaspolit port test. If we would have said that DP was installed in the VS test... that would have given everyone the false impression that the DP tools were available. They were not. End of story.

 

I have said all I need to say, thank you.