WannaCry Exploit Could Infect Windows 10

It could be argued that each time MS release a security patch they're tweaking the system!

 

Of note is Microsoft's own admission that anyone running unpatched Win 10 could have been hacked by EternalBlue if they were not running Creators Update Enterprise version with Device Guard enabled:

https://blogs.technet.microsoft.com...ith-windows-10-virtualization-based-security/

So putting in all together, EternalBlue exploited a remote code execution vulnerability in the SMBv1 kernel mode driver. This is the absolute worse type of vulnerability that can exist. Port 445 use was an incidental factor since that is the port that SMB uses.

 

In my opinion M$ by playing it loose once again with Windows 10 Home, Pro etc. and not fully implimenting all of the EXTRA security potential that those systems could and should have, they are digging themselves another hole to have to crawl out of down the road once again just like the WannaCry spread and various others being mentioned in this and other topics.

Yeah, they might have made better provisions for Enterprise, Education, and even more so for gov. military editions, but it leaves open plenty for the hackers to examine on the common series which they seem to holding back on so far.

That's another way the bad actors work their way up the chain to be able to poke through the higher end models. But this is just another opinion of mine coupled and driven by tons of discussions and facts from proof popping up all over the net these days.

Stop the teasing Microsoft and just put the extra security in there for ALL users period.

 

Agreed. However, there are hardware requirements to using Device Guard w/VBS enabled. The device CPU must support Hyper-V; the BIOS must be UEFI; etc.. The main issue is Secure Boot must be enabled which is not supported on the Home versions.

 

I forgot to mention… disabling VS's parent process feature is only required while testing when a parent test app is executing child malware. For example, the various leak tests and RanSim type apps require disabling the parent process feature, otherwise, all of the malware will be allowed as a child process of the parent test app.

For the EB / DP attack test, the parent process feature should remain enabled while performing the test, since no user interaction is required to steal documents from the machine, and since all software should be tested in default settings, unless otherwise specified by the vendor.

 

I didn't realize that. Thanks for updating me on that since I happen to be on Pro and been testing Enterprise of course like many others.

So for now it's safe to assume Home users will be somewhat at a disadvantage where this particular feature is concerned per the Windows series model and hardware support to be sure.

More on topic, where else does one turn to inside the O/S to better prevent a potential like is being being discussed in this thread. The basic security softs are always necessary of course but what extra preventions (internally) is available (if any) for the end user of say a Home model of Windows 10?

Where do they go, what do they look for to better help them avoid a potential breach of their good machine on the order of something this callous?

 

Yes, always ON.

please stop using words like DP tools. It makes no sense.

Probably yes, I don't know.

Proof, with password stealing demonstrated:
https://youtu.be/RdKrWL7dR1s

As mentioned, some attacks (especially those spawning new processes) will be blocked by VS, some like stealing passwords won't.

I already sent the same tutorial I used to setup my machine. If you can't replicate it via that tutorial, I am not sure how else could I help ... This is not rocket science

 

When I say “DP tools”, I am using the same terminology that everyone has used for the last month, so we can all be on the same page. It is much more important to me that the community understands what is going on here, rather than to try to impress you with my "limited" understanding of exploits.

When you say “Probably yes, I don't know”, are you confirming that “all of the tools were blocked from loading / installing in the first place”?

If so, that is all I need to know.

The password stealing does not surprise me. It appears that everything else was blocked, correct?

So then, the question is… your whole point is that if the payload is running at kernel level, then “things are not that great.” Which I completely agree, unless the code is effectively blocked. But if the malicious code is unable to perform any malicious function, because it is being blocked by the security product, then it does not matter if the code is running at the kernel level in the system space, or asInvoker in the user space, correct? The fact is, it cannot do its job because it is being blocked by the security product. Correct?

For example, if you have ordinary ransomware running on your system, but the security software blocks the malware from encrypting your files and copying ransom notes to every directory it writes to, (and whatever other malicious activities) then the security software effectively blocked the ransomware.

It is true that if the malicious code is injected into lsass, and runs at the kernel level, things could get really bad, really quick. But the ONLY time it matters if the malicious code is running at the kernel level, is when the malicious code is not blocked. If the malicious code is blocked, it does not matter how it runs... the code is blocked.

What you are not explaining to people is that when the attack is a true zero day, there is no Windows patch available, so that is not an option. Sure, there are anti-exploit products, but as everyone witnessed in the EB / DP attack, it is iffy whether these products will be effective or not for the next zero day.

So in the end, VS blocks the payload tools and the absolute vast majority of the damage. Isn’t this MUCH better than a full bypass, where all of the payload tools are available?

I honestly have not received the tutorial, where did you post it? Can you please either post it, or tell me where to find it? I simply want to reproduce the exact same test that you ran... you know out of respect for the scientific method .

Please do not talk down to people by saying things like "this is not rocket science", especially if you have not sent me the link. I am trying to keep this discussion profession and non-personal. We could discuss my area of focus (GUI Dev / AE / ML/Ai), and I promise, I would never belittle you.

Edit: BTW, I really do appreciate your help and insight, thank you!

 

Read through this: http://www.nosuchcon.org/talks/2014/D3_05_Alex_ionescu_Breaking_protected_processes.pdf

My take on what is shown in this article is that as long as the security solution's kernel is running in kernel mode as a protected process, it can indeed monitor malware payloads also running in kernel mode as protected. I believe the issue is anti-execs and security solution HIPS's don't by default monitor kernel mode protected processes since they consider them safe Windows system processes. Also many don't run as kernel mode protected processes. So I believe my Eset HIPS rules for lsass.exe I posted previously will work and detect the noted monitored activity from a malware kernel mode protected process.

"The rub" is that a malware kernel mode protected process could attack another like system process as long as it adhere's to this:

So the HIPS training mode then switching to interactive mode appears to be the safest since an alert would be generated when activity against any system process was performed that was not detected during the training period. Of course, you are going to get a lot of alerts when major system or application updating creates new processes or activities. This can be mitigated somewhat by switching to training mode prior to these activities; abet at some risk especially in regards to application updating.

 

Very VERY good explanation on that and big thanks for spelling it out so well in detail.

The good ole kernel as usual and once again takes top honors as the most important meeting room and so unless there is a security solution also in attendance, it looks like matters could quickly and easily get very dancey.

Many security programs are not fashioned to attend the dance in there so your mention of HIPS in no way is a surprise as well as others.

 

I really need to exit this discussion asap... it is getting old. But I just wanted to mention, I cannot speak for other security products, but this is simply not true with VS.

A quick and dirty test is to try to open one of the executables in the system32 directory with Internet Explorer... VS will block it. I have actually mentioned this feature probably 10-20 times in the last couple of years, and I bet a lot of people are tired of hearing me talk about this feature .

BTW, to test, just go to IE, then File, Open, Browse to System32, and change the file type to "All Files", then try to open on of the exe files in the system32 directory, VS will block it. This is just a simple demo... there are several other things that are done to restrict what needs to be restricted.

 

I think Lockdown is a vendor?

 

Pete, I understand why you are upset, but please do not be mad at me... I was simply testing guest's theory when he said the following.


"Only apps with memory protection would stop the payloads to being injected to the system and those others default-deny solutions who don't have it , would stop the payload to run. but none will stop the spreading in the network.

Appguard and Comodo protect the memory; VS, NVT (ERP, SOB), Applocker doesn't."


I was just encouraging testing and discouraging wild, incorrect speculation.

Don't worry... if the toxicity and uncalled for bias continues on these security forums, I will not be posting much longer anyway.

 

So what? i was right about VS, no?
Yes, I speculated not stated (note the use of "would") about AG based on the few infos i had at that moment, is it forbidden?
By the way, AG isn't your product, know your place, focus on your product, which is VS.

And you had to made a video to prove my theory (which was a theory) was wrong? and at the end the whole thing just blow up on your face. hilarious.
You should focus working on VS instead of wasting time debating and making irrelevant videos about theories concerning other products.

Yes AG does have memory protection, it prevent the memory of a process to be read/copied/modified by another process. so i'm wrong? no.
VS doesn't, i'm a right? if VS has memory protection feature, let us know, because it was never mentioned before.

 

Internally. Disable SMB1 and make lsass run as a protected process: HKEY_LOCAL MACHINE > SYSTEM > CurrentControlSet > Control > Lsa
In the right pane, right-click an area of empty space and select New > DWORD (32-bit) Value from the menu.
In the new value box, type RunAsPPL and press ENTER and change the value to 1

 

Grow up.

 

Say that to yourself, kid. i made one single post, you made from it a video and a month-long heated debate because you can't handle people saying a certain product is better than yours ( you clearly admitted it) and i should grow up? hilarious...

 

I can only repeat myself. "As mentioned, some attacks (especially those spawning new processes) will be blocked by VS, some like stealing passwords won't."

Working with Peddlecheap is not easy. It is a complex beast. I already spent days with it, but I still can do basic things with it. There are things in Peddlecheap one can do without VS blocking it, and there are other things which is blocked by VS.

VS is not blocking ALL malicious functions, just some.

And some ransomware steals your bitcoin wallet and stored passwords before encrypting the files. Surely, it is still better than when the files are also encrypted, but the protection could be improved.

When Eternalblue/Doublepulsar was only in the possession of the NSA, no tool was able to block it from installing Peddlecheap. NSA has huge teams for this purpuse, to bypass every endpoint protection which can be found on their targets. Let's imagine NSA targets a machine protected with VS, and their tool was not tested for VS before. While installing Peddlecheap the operator will immediately see that an unknown software protects the system. Check 2:21 here: https://youtu.be/RdKrWL7dR1s?t=141 - VoodooShield is highlighted because further action is needed from the operator. They will download VS, test it, and they will see that although it blocks some of the attacks, they can still disable VS. They already had an army of tools to disable endpoint protections - even ones with good self defense. So a developer at NSA will add a KillSuit module against VS, they will deploy it, kill VS, and they are good to go. In this sense, VS was not protecting against the NSA 0-days.
When Eternalblue/Doublepulsar was stolen by the Shadowbrokers, they probably didn't have the time/resources to create a new KillSuit module against VS. If they ever tried to use Eternalblue/Doublepulsa and imagine they attacked a computer protected with VS, VS would probably block the attack chain.
When WannaCry started, and Eternalblue was ported to Metasploit, VS was probably blocking these attacks from the beginning. Which is great.
But you can't say VS protects against NSA 0-days.

Sorry, you are right, it was someone else I posted this: https://www.youtube.com/watch?v=2cNwkqDB0DI

 

Thank you... we are in total and complete agreement, and I appreciate your help and insight. Yeah, I am not pretending that VS will block all NSA 0-days... I was simply investigating guest's claim that:


"Only apps with memory protection would stop the payloads to being injected to the system and those others default-deny solutions who don't have it , would stop the payload to run. but none will stop the spreading in the network.

Appguard and Comodo protect the memory; VS, NVT (ERP, SOB), Applocker doesn't."


I only expect VS to block attacks that are within the scope of application control utilities, which is exactly what I claim VS does, and exactly how it performed for this attack.

Thank you for the tutorial... I will play around with it when I get a chance.

Pete, guest, and other doubters, should we start a new thread on Wilders or MT called "VoodooShield Apologies", so you can post your apologies?

 

So to sum things up a bit, the lsass.exe process itself is pawned regardless. Anything spawning from that would seem to be blocked, whereas lsass.exe itself which contains all of the meat & potatoes as far as Enterprise level passwords would still be ripe for harvesting passwords/secrets.

 

Dan, I like it when you stick up for yourself and VS.