WannaCry Exploit Could Infect Windows 10

Exact.

 

http://news.softpedia.com/news/micr...protected-users-against-wannacry-516348.shtml

http://news.softpedia.com/news/wind...inst-wannacry-ransomware-attacks-515679.shtml

 

Wasn't this already explained in the Wikipedia article? EternalBlue can directly exploit the SMB driver if systems are not protected by firewall. Or am I missing something?

guest, what I don't get, is you keep saying that there has to be a dropper. There is no dropper for EB and DP, because it's running in-memory. But there is a dropper for WannaCry, and I've read it will be dropped inside C:\Windows, so a tool like AG won't block this correct?

That's why I said that not all tools are designed to block stage 1 and 2, but if you can't block stage 3 either, even though you're supposed to mitigate/block malware launched via exploits, you should get back to the drawing board.

 

from what i read it need port 445 open.

1a- once in the network, yes i agree.
1b- but how you get in the network in the first place? EB needs an IP of a system with SMB enabled (that is available only inside the network).
Now what if i'm behind a NAT router/hardware firewall, from what i know, the attacker (from outside the network) can ping only my router/hardware FW, not my machine behind it (unless the router/HwFW is miconfigured) and normally my router/HwFW doesn't have SMB and port 445 open, right ?

http://www.thewindowsclub.com/smb-port-what-is-port-445-port-139-used-for

2- correct because point 1a , but how from point 1b ?

it is why i believe EB-DP is more a corporate threat than a home user threat.

You can't generalize like this, some security tools are designed to do one thing, they have one purpose only, this purpose will influence their mechanism/protection model and the way the user have to use its OS.
Don't ask an anti-logger to stop ransomwares, dont ask a virtualization soft like SD to block keyloggers from running.
The user has to know the pros & cons of the tools he use, then he can adapt his security layout based on those infos.
However if he uses a security suite , those are designed to protect all known angles.

 

That was never the debate, we all know this. But fact of the matter is, this attack was successful and disrupted a lot of computer networks. You keep asking certain questions that are not relevant, because the attack did happen right? My only question is, what security tools would have protected against stage 3, and when it comes to AG, you don't give a clear answer, just say yes or no. Based on what I've read, a lot of tools failed to protect against it.

It's very simple, if a security tool claims to protect against advanced exploit attacks, it should do the job. But I agree that it depends, for example a tool like Sandboxie wouldn't have helped since it designed to protect only the browser and other user-mode apps. But there is no excuse for companies that offer so called "next gen" AV's because they are supposed to protect against all kinds of threats.

 

Think I might of found a way to shut down ExternalBlue exploiting.

A new Wilders forum member posted a one liner response about ntoskrnl.exe in the main WannaCry thread. That got me thinking ...........

For starters, the EternalBlue exploit by itself does nothing more than exploit the kernel. This exploit sets the stage to employ the secondary exploit, DoublePulsar for WannaCry and Casey Smith's Applocker bypass via regsvr32.exe for EternalPot. Both these secondary exploits will memory inject a .dll payload from the kernel into lsass.exe so that credentials and privileges can be acquired to install and run the resultant malware.

It dawned on me that there really is no direct interaction between ntoskrnl.exe and lsass.exe that I was aware of. So I created an Eset HIPS rule to monitor any hook setting, event interception, or process modification from ntoskrnl.exe against lsass.exe. So far, this rule has not been triggered including after a reboot on Win 10 x64 1607 indicating no adverse impact. Whether same would apply on other Win vers. needs to be tested.

What I need is someone running in a VM or test rig with access to the Metasploit ver. of EternalBlue/DoublePulsar to create a like HIPS/anti-exec rule and see if it will block any process modification by DoublePulsar against lsass.exe. Note the security solution has to have the capability to detect memory injection.

 

Interesting stuff, you never know, it might actually work. At least you tried to think out of the box.

 

If your suggestion works, can you apply your hips rule to other processes as well as lsass.exe as it is just an arbitrary process for demo purposes?

 

I would proceed very, very slowly on any activity monitoring from ntoskrnl.exe. Again, security solutions assume the kernel is impenetrable and as such do not monitor it for adverse activities. And if they did, how can they differentiate legit versus malicious activity from it?

 

Agreed. I didn't even realise it was an option to watch the kernel.
I'm looking forward to someone testing your theory out and hearing the outcome.

 

I am also not 100% convinced there is a direct kernel to lsass.exe memory injection taking place although all the detailed analyses state so.

Makes more sense that the kernel exploit is modifying services.exe memory which lsass.exe is running under. Then services.exe is deploying the secondary exploit that in turn is modifying lsass.exe. If this is the case, it would be impossible to detect under conventional HIPS/anti-exec methods.

 

yes because all test were based assuming the attack is launched from a computer already compromised inside the same network; checking other machines in the same network and using SMB to propagate.
now how EB get into the network and compromise the 1st machine (that will be patient zero) , so if EB-DP can find his way by bypassing a NAT router/HwFW, you are right, it doesn't matter , if not....then this is an important point to consider.

network = House
machines = Rooms
SMB ports = room's door
router/Hardware FW = house's public entrance
attacker = thief
EB-DP = passkey

if the thief is in the house, he use the passkey to move from room to room, we agree on that; but how the thief get into the house in the first place?

Every malware needs an entry point in a network, now we have to know it to block the attack to even start.

Those are the basis of security:

1- protect the network from external/internal threats
2- protect the machines inside the network
3- protect the user using the machines

those 3 are keypoints in security. i'm sure you will agree.

AG Consumer is made to do 3 things :

1- block or Guard by policy any items from User-Space to execute and modify System-Space. AG's System Space = "Trusted Enclave" , this area is protected from exe/dll/installers originating from user-space.
AG by default won't react from anything originating from System-Space unless it is on its policy. because System Space is supposed to be clean.
Obviously, the user can add system processes to be blocked or guarded, but this may bork the OS. lsass.exe is critical system process.

2- prevent a Process to read/copy/modify the memory of another Process (hollow processing)
3- prevent programs to access user's folders configured as "private"

However :

a- AG does not apply a policy to the kernel.
b- AG wasn't made to block exploits but can block/guard some interpreters used to execute the exploit (powershell, cmd, etc...)
c- AG gives to the child the parent's privilege;
d- AG doesn't have a command line parser.

So if stage 3 managed to directly pop in System Space, AG (consumer) shouldn't react especially if it is defined by point a/b/c
note that AG Enterprise has additional protection mechanisms.

i agree on that.

 

No matter what security program blocks a post-exploit, it is possible on a system that is maintained indefinitely in its unpatched state, that the user can unknowingly turn the exploit into a system "forever-day."

Update Windows and apply all security updates; don't run unpatched Windows and recognize that there is no single-button, set-it-and-forget solution against anything and everything that can potentially compromise a system.

 

Chalk this up to "wishful thinking." Ntoskrnl.exe is a protected process on x64 Windows; and totally locked down. As such, security software cannot monitor API calls from it which is necessary to monitor any of the above noted activities.

Because the original DoublePulsar exploit employed shellcode, the process startup of rundll32.exe by lsaas.exe can be monitored. This will be short lived since a reflective .dll version of DoublePulsar has been posted on GitHub.

 

OK, so long story short, you don't really know if AG Home and Enterprise would have protected against this attack. I did wonder about AG, because it has the ability to block malware from running or to at least restrict them.

Like I said, don't ask me how they managed to infect 200 or more businesses, I'm not a firewall expert. Fact of the matter is, it did happen. So companies now have to rethink their whole security strategy. And they will need to assess what security tools can and can't do. A multi layered security is definitely needed, so perhaps we're not that crazy after all.

Well, that's the thing, you might still be able to interfere with malicious payloads that were run by hijacked system processes, so it's definitely not always game over when you're dealing with kernel exploits. For example, anti-executable and HIPS/BB don't care about what privilege level some process has. If the child process is not white-listed or shows signs of malicious behavior it should still be blocked. If malware runs completely in-memory, then it's get harder to block.

 

In reality, how many people would be monitoring a rundll32.exe startup by lsass.exe?

 

Well, it isn't the people who should be monitoring this. Anti-executable tools like VS and ERP do have this ability, and would have blocked this attack. It proves that AE and white-listing tools are essential in a layered strategy. Thanks again to Dan for taking the time to test this exploit.

 

Rethink ! There is no security program in-place to begin with to rethink. Most just needed to apply the Microsoft security updates that fix exploits or upgrade to latest Windows 10.

The ones that fell victim to WannaCry are also the ones that are very likely not security aware\conscious and never adhere to recommended best practices. That's what got them into trouble to begin with. The simple truth of the matter is that if security patches were applied, then the systems would not have been exploited. Remember that the attacks occurred months after Microsoft pushed emergency patches.

Companies typically do not go to extraordinary lengths to protect their systems. In fact, the exact opposite is true and most systems are misconfigured or neglected.

I can guarantee you that your personal system security is better than most systems in a commercial setting.

 

Almost no one. And because of a forever vuln that Microsoft has yet to completely fix in lsass.exe, it can be easily picked-off using mimiKatz for example. There is a proprietary protection for lsass.exe in our Enterprise product. It hasn't made it into the consumer version yet. No ETA on incorporating it.

 

In the samples we looked at, the ransomware executable was always written to a user profile directory so - yes - both AppGuard Consumer and Enterprise block it.

The ransomware is the last 3rd of the attack. There are two exploits that are still on the system if it made it all the way to WannaCry itself. Those will remain there until Microsoft security patches are applied or the system is remediated by other means. And the fact is, unless you block the attack at the very 1st phase, you have to remediate the system. Blocking the attack further down the run leaves the user with at least one active exploit on their system - a fact that is little discussed. Once injection of lsass.exe is attempted, the kernel has already been modified by the 2nd DP exploit.

Anyway, this continued focus and interest on exploits that were patched by Microsoft months ago is a curious phenomena.

 

Glad you mentioned this. The user I am now dealing with now can't seem to understand this. His whole network is infected and he will have to take the entire network off-line and clean every client and server on it.

 

Additionally, any Win system executable could have been targeted; not just lsass.exe. It is a fact that .dll injection can be performed many ways. One that can employed since this is a kernel exploit would be to modify the knowndlls and knowdlls32 areas in the registry or the kernel root table itself. This would ensure that the malicious .dll be inserted into every process.

 

Surely, lsass.exe was only the default. If we start applying our MemGuard protections to session 0 stuff, you basically blackhole Windows. So we recommend carefully measured configurations to cover the whole spectrum.

 

No idea for enterprise indeed, i don't and surely will never have access to it, as a beta tester.

About home version, since i don't have the malware/exploit, i can tell only from what i know from AG. I use "shouldn't" because what applies today, doesn't mean that it will in the future.
The sure thing i know, is: attack based on exe/dll launched from user-space = blocked; now in security, nothing is 100%...

maybe email attachment executed by a unaware user, web exploit, who knows... all i know is there is a exe that was uploaded to VT, is that exe is the dropper of the massive scale wannacry attack? we dont know.
What we sure know : unpatched Win7 + smb enabled = victim; a properly maintained network would have at least Win7 patched and up-to-date and then won't be victim to the Wannacry attack.
As @Lockdown said some enterprise networks/machines are so badly maintained/protected that i could run whatever i want on them...i see it from my own eyes....

 

As far as monitoring rundll32.exe, below are lists of its usage in:

Win 10 - https://www.tenforums.com/tutorials/77458-rundll32-commands-list-windows-10-a.html
Vista and Win7 - http://vlaurie.com/windows-7-tips/rundll32-vista-windows-7.html
​

Note that many of the rundll32.exe examples employ shells. At best, all a security product could do would be to examine the .dll or shell code being used for a malicious signature. This implies that the malware code would have had to been detected prior to its usage.