WannaCry Exploit Could Infect Windows 10

Post # 64 Fuzzbunch+Eternalblue+Doublepulsar+Peddlecheap
was about two others. Are you suggesting a new thread about this?

 

I am confused... the title of this thread is "WannaCry Exploit Could Infect Windows 10", which I am assuming refers to Eternalblue (since WannaCry is not an exploit), and subsequently refers to any payload involved in the attack as well, since they are important components of the attack.

Besides, MRG recommended that I test VS with PeddleCheap on this thread, so instead of starting a new thread, I found it more efficient to create a quick post to update everyone as to the status of the test.

 

Just look and think, do you see at this forum people being attacked, versus business?
Don't rely on "news".

 

At this point, I have no confirmation from the DoublePulsar test tool developer that it is indeed PeddleCheap. I will send him an e-mail in that regard.

 

See my reply #104

 

As far as I have read Fuzzbunch was the worst of the tools released by shadowbrokers.

 

Ref: https://hackernoon.com/a-quick-look-at-the-nsa-exploits-dander-spiritz-trojan-1b5428b0ee65

Unless I am missing something, PeddleCheap which is the AKA for Dander Spiritz was running remotely. Prior to that it was used to create the .dll payload. It then created a backdoor; memory injected the .dll payload; then downloaded and memory injected the shellcode; and finally executed the shellcode to run the .dll payload. Also based on the below, it has the capability to run with system privileges. Whether that function involved modifying lsass.exe to do so, remains to be determined. I doubt it.

 

This confirms it. PeddleCheap and DoublePulsar are two different exploits. And as noted previously, PeddleCheap is "noisier" leading to higher likelihood of detection:

https://www.dearbytes.com/blog/playing-around-with-nsa-hacking-tools/

Also I believe but have not 100% confirmed that PeddleCheap is using relective .dll injection since it has an option to create a .dll payload. What I believe that is doing is creating the special code required for a reflective .dll.

BTW - the author's screen shots show the "real version" of DoublePusar injected the memory of lsass.exe which resulted in it spawning a child process of calc.exe, the malicious payload his test, and running it. So the lsass.exe "mystery" is solved. I believe the only way this could have been done is via a kernel exploit, which DoublePulsar is, since lsass.exe runs with system privileges.

Appears to me the problem with the test tool is in the startup of the child process. Again, might be something with Win 10 x64 1607+ CFG protection.

 

i posted this link somewhere and told what DP does ages ago, and some people still believe that their "uber-anti-exe" would stop DP... made me laugh... once DP inject lsass.exe , game over, whatever the security apps does after.

with all we know now about EB-DP , tell me how any anti-exe/SRP can stop a kernel exploit, i will buy it right away LOL ...

 

From post #64 of this thread "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."

https://www.wilderssecurity.com/thr...-infect-windows-10.394550/page-3#post-2685255

In other words... if the application control utility prevents the exploit EB from installing the payload DP, then the exploit has failed in doing its job.

In addition, if the application control utility fails to prevent the exploit EB from installing the payload DP, then the application control utility has failed.

 

So Dan , do you still say VS block DP? yes or no?

because if it does, VS would block a kernel exploit.

 

Yes, in the metasploit test, VS absolutely blocks the installation of the payload DP... this is easily proven because the session is not created and the DP hacker tools are unavailable.

Yes, in effect, VS blocked the exploit, simply because it blocked the job it was designed to do.

It would be even better to block the exploit EB at an earlier stage, but VS is not an anti-exploit product... it is an application control product, and it performed its job properly by blocking the payload.

 

DP payload is in the kernel. If lsass.exe is injected, the kernel has been exploited. Blocking rundll32 is not blocking DP (it is blocking DP to connect to the attacker and be used as a vector to download more malicious payloads) the backdoor has already happened and the kernel has been modified.

VS didn't block DP , it stopped DP to connect to the attacker, which is different thing. VS prevented further stages of the attack, not the backdoor DP to be installed , because it was done by EB exploit at kernel level. and that no anti-exe/SRP can stop it to happen.

This is what i kept saying since the beginning...

on @itman article link, the guy just ran calc.exe instead of Rundll32.exe. so in this case VS would block calc.exe as well.

Blocking what want DP to do is good , but don't say VS block DP to be installed because it is just not true.

Do you understand what i try to say?

 

I see exactly what you are saying, but you are incorrect. How can you say that VS did not block DP, when the session was not created and the DP hacker tools were not available? That honestly makes absolutely no sense at all.

If you performed the test for yourself to see how the attack worked, and if you understood how VS worked, you would understand that VS would have blocked calc.exe as well. Well, by design VS should block calc.exe in this scenario, but it would not hurt to test to be sure.

Kindly explain to me how DP was not blocked, when the session was not created and its hacker tools were not available. That is exactly like saying calc.exe was not blocked, but yet the Windows form for calc.exe does not appear on the screen for you to add two numbers together.

 

lsass.exe being able to create rundll32.exe or calc.exe, mean DP was installed?
if VS blocked DP to be installed, then rundll32.exe or calc.exe wont be able to be ran.

isn't that clear enough?

 

Hehehe, that is where VS blocked the attack!!! EB was not "able to create rundll32.exe or calc.exe" since VS blocked it... which is the one job of an application control utility.

So we can at least agree that the application control utility should have the appropriate mechanism to block the attack at this stage (the payload), correct?

I really am finished talking about this. If you have any other questions, please ask Zoltan_MRG, and hopefully he will take the time to clarify this even more.

 

- EB is a kernel exploit, EB just implement DP (the backdoor).
- EB doesn't run rundll32 or calc, you are confused about all of it, that is DP job by exploiting lsass.exe.
- if lsass.exe is able to spawn rundll, calc, or any other process , means DP is running.
- however VS and ERP prevented DP to fully run any additional payloads.
- those rundll32, calc, etc... would be in suspended mode because of VS/ERP, means they were created but cant fully execute.

so don't say "VS block DP to be installed", it can't , however VS can prevent DP to do further malicious tasks. which is a good thing.
It is all i say, but you seems not to (or refuse to) understand what i mean.

depend of the principle and mechanism used by the said applications. you can't generalize.

 

You said "so don't say "VS block DP to be installed", it can't , however VS can prevent DP to do further malicious tasks." This is completely and totally incorrect, simply because once VS blocks DP, THERE ARE NO "FURTHER MALICIOUS TASKS" to be blocked. DP's tools were not available, so DP was never loaded into memory. What part of that do you not understand?

You are the one who is confused on what is what. You have not even ran the test, and you are arguing with someone who ran it around 40 times, after spending several hours researching the attack, and understanding each component of the attack to get the test to work properly.

It's fine though... it all comes down to these questions.

1. Did VS allow any malicious payloads that it should have blocked? If so, what did it allow?
2. If VS did not block DP, then why was the session not created, and why were DP's hacking tools unavailable?
3. If VS did not block DP, what specifically did VS block in this attack?
4. What specifically do SRP mechanisms miss in this attack?

 

1- since the beginning, I said VS can't prevent DP to be installed (you keep saying the opposite).

2- because DP can't reach the attacker platform where the additional payload are launched from.

Your understanding and claims that VS blocked DP are false. DP is an exploit - and not the full attack - which you do not seem to understand.
The DP exploit modified the kernel before code injection into lsass.exe. : https://zerosum0x0.blogspot.com/2017/04/doublepulsar-initial-smb-backdoor-ring.html
That means once VS suspends rundll32, the DP exploit has already modified the kernel and the exploit itself has succeeded.
Turn off VS and the exploit is still there and will proceed to fully compromise the system. It is published everywhere online by researchers more qualified than you.
https://threatpost.com/nsas-doublepulsar-kernel-exploit-in-use-internet-wide/125165/

VS doesn't have memory protection, how can it block an in-memory attack... be logic !

3- the attempt to create a reverse connection in your video (connection to kali) or calc.

Spoiler: DP primary task

The DoublePulsar backdoor allows to inject and run any DLL (Dynamic Link Library), that way compromising the computer and using it for whatever purpose. I was able to load a DLL into LSASS.EXE spawning calc.exe as a POC. But this off course could just as well have been something malicious. (Meterpreter, Empire, Beacon).

https://www.dearbytes.com/blog/playing-around-with-nsa-hacking-tools/

https://threatpost.com/nsas-doublepulsar-kernel-exploit-in-use-internet-wide/125165/

So on you videos, rundll32.exe was spawned but suspended, so DP was successfully installed but its additional tasks were suspended; got it ?

4- depend the SRP used. SRP arent AVs , however they have one common mechanism, they block stuff based on policy.

I dont say VS is crap (seems it is what you believe), i even say it is very good for its purpose as an anti-exe, but just VS wasn't made and isn't able to block EB-DP exploit. Blocking one aspect of an attack (because it falls into the scope of a product) isn't blocking the full attack. And this is an important point to consider.

 

First of all, DP is not an exploit, it is the malicious backdoor payload that EB tries to install... But VS blocks the installation.

https://www.wilderssecurity.com/thr...-infect-windows-10.394550/page-3#post-2684981

DP IS THE "ATTACKER PLATFORM" that contains all of the hacker tools!!!! And it was blocked by VS, and that is the reason the hacker tools were not available.

Sure, the process is suspended at 88kb while VS decides whether to allow or block the execution, but once it decides to block the execution, the payload is completely blocked. Besides, we all witnessed how effective memory protection was in this attack .

You are misreading this quote: "The DoublePulsar backdoor allows to inject and run any DLL (Dynamic Link Library), that way compromising the computer and using it for whatever purpose. I was able to load a DLL into LSASS.EXE spawning calc.exe as a POC. But this off course could just as well have been something malicious. (Meterpreter, Empire, Beacon)."

He is talking about after the malicious backdoor payload DP is installed... but VS blocks DP from being installed.

I really am done with this conversation, if you have any questions, you know who to ask.

 

it is an exploit :
https://threatpost.com/nsas-doublepulsar-kernel-exploit-in-use-internet-wide/125165/

the attacker platform is the metasploit framework , aka Kali in your video.

you don't even understand your own test lol

do you thnk an in-memory attack will have an exe embedded with it LOL, are you kidding me ?

which one?

 

Directly from the link you just provided... "DoublePulsar is a sophisticated memory-based kernel payload that hooks onto x86 and 64-bit systems and allows an attacker to execute any raw shellcode payload they wish."

I give up... someone else is going to have to explain this to you.

 

I wonder what it will take for the world to realize this and most all of the malware chaos we see on a regular basis is not random criminals and teenage hackers. This is business and there are no software solutions that will protect you from it.

 

exact ! so tell me how VS would prevent it to be installed, thank you to validate what i was saying and contradicting yourself...

 

No one seems to have noticed, wannacry has no way for the perpetrators to identify an individual machine and unlock it and no one has collected the money that some victims paid. A very sophisticated malware attack for no apparent gain yet no one comments on that.