WannaCry Exploit Could Infect Windows 10

I am confused. Can this still happen if Windows file sharing service is disabled? That is how my Win 10 machine was by default.

 

EB needs SMB only to propagate, doesn't mean it can't exploit the system once inside if dropped via other methods.

 

How is file and printer sharing between PC's on a home network supposed to work if you disable port 445/SMB?
Not everybody has just one computer.

 

Next discussion point.

Let's ask if a user mode process was able to memory inject a .dll into the unprotected kenerl mode lsass.exe, would that code run? Assumed is that that attacker is using the .dll to access and run one of the three services lsass.exe controls; VaultSvc, KeyIso, and SamSs. Also, assumed is the user mode process has gained system privledges since that would be required for the .dll injection.

Below is an excerpt from a discussion of someone attempting just this on a Win 7 x86 device. Note that the PatchGuard bypass element is N/A here since that only protects x64 keneral mode processes:

https://forum.quequero.org/discussion/39/code-injection-inside-process-running-in-session0-from-outsider-process-win-vista-and-higher

Appears not is the case with the wannabee hacker resulting in his "throwing in the towel" for the effort.

Bottom line - the DoublePusar payload must be running in kernel mode to execute any of the injected .dll code.

For me, the x64 PatchGuard bypass by DoublePulsar far outweights any of the resultant SMBv1 worm activity employed by WannaCry. Also, the only way I can see of stopping an equivalent 0-day kernel mode malware would be during the user mode memory .dll injection phase.

 

Download Wireshark and do a capture while printing. If it is using SMBv1 then you will see SMB and what port it is using in the capture log.

 

I can't believe you guys are still obsessing over this one! Note that EB is really a poor man's way to get on to a system when the normal High and Noble methods of doing so (Bribery and/or Blackmail) are ineffective. Even so, it was rightly mocked in certain circles as being not specific, only targeting improperly maintained systems.

Nonetheless, the payload still has to be somehow placed on to the system to be ru, triggered either internally or extrinsically (spoiler- the payload dumping, activation, and mechanism of action is not Magic. Harry potter has nothing to do with this) . In the case of the "worst thing ever" Wanna, it still is just a code injection with Services created. Wowie, Zowie! like this is new. If the Security Pro's at the target have any idea of what they are doing this attack will fail; but again as they didn't even have the brains to prevent the EB exploit in the first place they are probably screwed.

Rule of thumb- if your security solution already prevents the malicious cascade from the payload you are golden; if it does not, then you ain't.

 

A TechNet write-up that does not even explicitly state that the key must be created - so that users understand. Typical no-answer or technically incomplete infos.

 

Don't look at me. As far as I am concerned this issue was solved back in March by Microsoft.

 

True enough however guest is quite EXACT as far as this statement relates IMO.

And they well know that but appear to making a better effort toward things yet with these machines that's never going to be quite enough to prevent constant security maintenance.

 

Pondering a bit more, the x64 PatchGuard bypass references are more figurative rather than literal. Or more likely, a "smokescreen."

The likely scenario is that that NSA found an unknown remote code execution kernel mode driver vulnerability in each OS they were targeting. The employed exploits set the backdoor and then entered the kernel though the vulnerability. All this would have elapsed undetectable bypassing all conventional security detection.

 

"Rule of thumb- if your security solution already prevents the malicious cascade from the payload you are golden; if it does not, then you ain't."


Precise, succinct and factual.

 

I believe the reasoning here or better yet, the focus, is on the unknown or potentional yet to come.

User's want to get ahead in anyway that they can through whatever means and even the best of security solutions can and do slip/miss, and usually at the most worse times.

The Wannacry massive spread to unpatched systems served as a wake up call even as Windows 10 progresses on ahead with each new release until done, whenever that might be.

 

I think the creators of these attacks are always one step ahead..If they view posts here I don't doubt they read them with a wry and knowing smile...And you guys will look at other peoples research and post them here adding a few comments to accompany them while security software developers will be busy thwarting them

 

And I'm out, there's no solutions here aside from some by the developers so there's nothing of use otherwise.

 

As far as enabling lsass.exe as protected mode in Win 10, not advisable based on this: http://blog.wisefaq.com/2015/11/19/passing-the-hash-protection-runasppl-and-breaking-windows-10/

 

I created the key and enabled it on Win 10 1607 and 1703. I did not see any issues, but most everybody knows how it could go.

 

The problem dll description posted below:

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

 

https://blogs.windows.com/windowsexperience/2017/06/21/announcing-windows-10-insider-preview-build-16226-pc/

 

I also see an issue with many security products not running in protected mode on Win 10. This was discussed previously in another thread in regards to protecting them from being disabled by malware. If malware can install itself as protected and the security solution is running as unprotected, there is no way it can monitor a protected process as noted in the below excerpt from the previously posted wisefaq.com article:

 

Another warning about setting lsass.exe to protected mode. I assume this also applies to Win 10?

https://www.petri.com/enable-lsa-protection-windows-8-1-server-2012-r2

 

It should be possible to remove the LSA Protection:

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

Process Opt-out tool:

 

Believe a bit more is involved:

 

LSA Protection is not needed unless one is using their system in a client-server scenario.

There is no use in creating and enabling the LSA protection key otherwise; it is a waste of time.

 

LSA Protection is to be enabled when one is using their system in a client-server scenario.

There is little to no use in creating and enabling the LSA protection key otherwise.