WannaCry Exploit Could Infect Windows 10

There is another intriguing possibility of this whole HSA EternalBlue/DoublePulsar fiasco.

It is that the x64 PatchGuard bypass was not an exploit of a kernel mode vulnerability; at least in the conventional sense. But rather the NSA was clued into a closely guarded kernel mode backdoor by a "little bird" whose name begins with "M." And all the furious resultant activity that occurred had in reality little to do with patching of SMBv1 per se, but rather with closing that kernel mode backdoor.

 

I just want to know what Chrome theme you are running and what extensions?

 

Yep. If not, just feel free to delete my posts .

 

Why do say begins with M? You know who came to my mind when you said that?

 

Bingo! We have a Bingo, and the numbers are...........

X64 Patchguard. Therein is your key of entry into the zone of darkness or Ring0 as it's referred to in some circles.

"little bird" equals unsubstantiated speculation? Or? There are several lanes of choice here but you can bet if you build a door and install a lock, there are always spare keys to fit it.

It was only a matter of time clearly, before someone someplace fashioned together certain exploits like this but the pure numbers of them that we now know which were openly released is enough to cause all Windows users the jitters.

 

Yes.

It goes without saying that all involved parties in this fiasco are going to point fingers at each other. It is called "Plausible Deniability."

I also believe the real reasons for Win 10 not being targeted are:

1. The targets are nation state governments, subversives, terrorists, suspect misbehaving corps., etc..
2. Most of the above in all likelihood were not running Win 10 as noted in no. 3.
3. The exploits are "end of live" as previously publically noted with Win 10 being introduced publically after the exploits were "shelved."

 

Thanks, this makes things a bit clearer. Probably that's why a lot of tools fail to block DP.

Did you test if VS can block the in-memory PeddleCheap payload?

That's what I said, the only problem is that according to MRG, it might be a problem if in-memory malware is used when DP is installed, see link. If it's a disk based payload like WannaCry, then a tool like VS will block it. I see that MRG has updated their article, were they mention that Cylance also isn't able to block DP.

http://blog.secdo.com/multiple-groups-exploiting-eternalblue-weeks-before-wannacry

 

Eternalblue exploits the Windows File Sharing Service (a.k.a SMB) on TCP port 445. This Windows File Sharing Service runs with SYSTEM (a.k.a kernel) level privileges, under the SYSTEM process.

https://security.stackexchange.com/a/159774

Which means that after successful exploitation, Eternalblue can install Doublepulsar straight into kernel mode. Here is a thing with SMB exploits, like Eternalblue - they start code straight at kernel level. Once it can execute code in kernel mode, the code has to hide from Patchguard. Not exploit Patchguard.
From Wikipedia: "[Patchguard] works by periodically checking to make sure that protected system structures in the kernel have not been modified."

If you don't believe me, check Zerosum's blogpost:
"It's an unique payload, because you can infect a system, lay low for a little bit, and come back later when you want to do something more intrusive. It also finds a nice place in the system to hide out and not alert built-in defenses like PatchGuard. It is unclear if newer versions of PatchGuard, such as those in Windows 10, already detect this hook. We can expect them to be added if not."
If a code hides from OS defenses, and already runs in kernel mode from the beginning, it is a kernel backdoor. Not an exploit.

The Countercept article is totally fine, there is no issue with that.

 

We might be getting into semantics here. If a kernel backdoor exists, its a vulnerability. An exploit is employed against a vulnerability. The backdoor can previously exist or it can be created by malware. EternalBlue set the kernel mode backdoor, DoublePulsar exploited that backdoor.

 

This is my final post on this topic. I feel tired to do this, and I don't think it is my responsibility to teach basic things.
An exploit is used to get from one state (less or zero privileges) to another state (more privileges).
A backdoor is maintaining a state, so the attacker does not lose the gained privileges. In case Patchguard can't detect the backdoor, it is not a vulnerability, but a lack of security feature or similar issue. Antivirus is NOT exploited because it can't find a malware on the system, and it is definitely not a vulnerability in the antivirus that it lacks the signature to detect a malware.

The broad use of exploit is way too confusing. Please, don't do that.

 

"Let's agree to disagree" and leave it at that.

 

Getting back on topic, I have created the following two HIPS rules for lsass.exe in addition to the previously mentioned rundll32.exe child process startup rule. Actually, I am going to change that rule to any child process startup.

Although it's doubtful these new rules will prevent any kernel mode modification of the unprotected lsass.exe process, they will protect against any user mode reflective .dll modification activities. That is as long as your security solution can detect reflective mode .dll injection; regardless of it is via APC or CreateRemoteThread method or, if a reflective or normal .dll is used.

Rules:

1. Allow services.exe to intercept events, terminate or suspend, or perform process modification activities against lsass.exe.
2. Block(Ask mode) any other process from intercepting events, terminating or suspending, or performing process modification activities against lsass.exe.

Been running a couple of days with these rules w/o any HIPS alerts or other adverse activity.

Of course, services.exe itself could be hijacked at which time, it is pretty much "game over time."

 

guest and itman, after all this extensive and exhaustive internet searching you've done on other peoples research on this, do either on you have a solution or will you simply continue to argue the theories?...If not I will cease following this thread as it offers no help to end users.

 

The solution already exist, at least for the Current EB-DP attack : patch Windows, Disable SMB, block port 445, use a dedicated anti-exploit (HMPA for example).
My debate wasn't about theory, it was about to say correct things and i was correct, it is proven, that is it. So i have no need to continue, now if some people can't handle that fact...

 

Thanks, as I thought, stick to security software such as VS, HMPA, AG etc...All very well knowing what the problem is, but finding the solution is better.

 

Indeed, remember that attacks don't popup magically on your system. So a multi-layered security setup is highly recommended. Even AG recommend to use other solutions beside it.
On the current landscape , an application control soft + an anti-exploit , is a must have. This is the reason why MS is implementing EMET as built-in security in the next Build of Win10, because Average Joe don't know what is HMPA or MBAE.

 

I think the average Joe is starting to realise that there is more to Windows systems other than a built in firewall and Defender, and that's due to the worldwide attention that wannacry drew..It made the headlines on all major news channels and press..There was a lot of advice given to the average Joe on how to protect themselves from such attacks and links for further reading so in the end its done everyone a favour.

 

Exactly, now maybe some will start having safe habits, updating windows when possible, be careful of unknown executables/mails, etc..

 

So do you still believe patching vulnerabilities does not make users more secure, even when the vulnerability affects their software profile, and user configuration? That's the argument you was trying to make with me, and a few other users last year. Have a look at post 35 from the link below.
https://malwaretips.com/threads/microsoft-support-says-security-patches-will-not-make-your-pc-more-secure.63100/page-2

Edited: 6/21/17 @ 2:47 am
Retiring for the night. Will check back in tomorrow.

 

It is more about point of view :
- the patch make you less vulnerable, not more secure, the patch doesn't improve security, it remove a vulnerability, it is a band-aid.
Calling back cars to fix their faulty breaks doesn't makes the care safer than it was, just safe as it should have been.

SMB was a feature that shouldn't be enabled by default, (since years, i disabled it everytime Windows got an upgrade , even before the Wannacry attack), like admin account shouldn't me made default account.

If MS were more "thorough" on how they set up Windows out of the box, many users won't be infected:
- why port 445 and SMB being enabled on home users? why network discovery is on when the user only has one computer? etc..etc...
i could give you a long list of tweaks i have to implement to set Windows "safe as it should be", why MS didn't via their installation wizard? would not be hard to do.

if Wannacry wasn't revealed, you won't have the patches they issued , they even being funny of pushing a patch for WinXP...

Patching is applying a band-aid when getting hurt, why not avoiding getting hurt in the first place?

 

"If MS were more "thorough" on how they set up Windows out of the box, many users won't be infected:
- why port 445 and SMB being enabled on home users? why network discovery is on when the user only has one computer? etc..etc..."


Sound argument

 

To be perfectly honest, I am not sure as to Microsoft's rationale for keeping the protected process disabled for lsass.exe by default. I have created the key and enabled it in the past and have seen no issues with it on the system.

 

I wondered the same.

My take is this is typical Microsoft "logic." Create a security feature but disable by default. Then write a detailed technical write-up on all the adverse effects of enabling that feature as posted previously which I suspect only apply to corp. users. The logic here is the same employed by many security vendors. If I enable the security feature, then I will be "bombarded" with irate users complaining about what the security feature busted. Or at a minimum after the feature is enabled, the feature doesn't work as designed because of user misconfiguration and the like with the finger being pointed at Microsoft. Then there is the issue of third party security software that might be installing its own protection mechanisms in these processes and if protected, would bust those. So at least Microsoft's recent complaints in this area are partially justified.

This does bring up the issue of the "one version fits all" OS that Windows is. All desktop versions are essential the same with system utilities functional and the difference being features enabled. This is great from a Microsoft maintenance cost perspective. Also, Microsoft's continued support of superseded features for compatibility purposes. However, all these are bad from a security point of view since it is these elements that are currently being used by malware to bypass built-in OS containment features and third party security software.

One solution to this would be that Microsoft employ a "lockdown" feature for the Home OS versions that would be enabled by default. This feature would in effect configure the OS for maximum security but minimum usability in regards to system utility use and the like. Similar like less restrictive settings could be offered for the Endpoint OS versions. This feature would also in all likelihood have major impact on third party security software severely restricting its functionality. If one is "reading the tea leaves" in this regard, I believe the above are already in progress.

 

BTW- I did check services.exe mode and protection status in Win 10 x64 1607. It is running in kernel mode as a protected process. Very glad to see that since it was a primary malware target in past Win OS versions.