Is that true, that default deny security solutions can stop the EternalBlue & DoublePulsar attacks?

[Andy Ful]

The real problem with EternalBlue & DoublePulsar exploits (used by WannaCry ransomware) is the ability to remotely patch the kernel memory of the victim machine. The code is next extracted from the memory, dropped on the disk in the form of DLLs, and injected to the system processes. All of this is done on the Kernel-level. I found an interesting article about the injection details of DoublePulsar, and it seems that the injection is a very unusual one:
Analyzing the DOUBLEPULSAR Kernel DLL Injection Technique | Countercept

From the above it follows, that some default deny security solutions, like Windows Software Restriction Policies and Anti-exe, cannot stop EternalBlue & DoublePulsar worm. Yet, the home users are still well protected, because the home networks are typically under the NAT, and the worm uses port 445 that is closed by default. Running the malware by the user is blocked/alerted by default deny security.
The problem arises when the machine is connected to the big local network like in enterprises.

Running the shellcode on the Kernel-level is not so easy. For example the EternalBlue can run from the memory only itself and DoublePulsar, and it seems that it works well only on Windows 7.
There is an open question, if the other default deny solutions (including autosandboxing) can stop the EternalBlue & DoublePulsar worm, especially: Applocker, No Virus Thanks SOB, Comodo Firewall (autosandbox), AppGuard, etc.

 

[AtlBo]

Thanks for addressing this issue. Isn't this a little bit of a ridiculously ingeniously designed mechanism for a ransomware?

Got a question about this. Maybe this sounds stupidly simple and a stupid consideration, but the question is, could a malware writer be thinking the following way? Create a PC within the PC of the target where your OS is in every way the target OS. In other words, create a fake OS, which is also in every way recognized as the standard clean installation of Windows by security software, and which the user in every way believes he/she has the control that has been set for them by the administrator in the safe and clean OS, and which the administrator believes is the safe clean PC also. This is the absolute definition of full control is it not? I'd be willing to bet that some hacker out there somewhere is thinking in this exact way with these exact words to create malware. Instead of "I have become your installation of Windows", something like, "I am the actual PC you are using and which you believe is the one you are authorized to use." In the same way but in reverse, a security writer can think too. Find a parasite version PC attached to the safe and clean one and which uses its hardware and find a way to block its activities, so that the hardware and software remain the PC everyone believes it is with its intended safe/clean version of Windows.

I feel like we have to get inside the minds of malware writers better to know their angle on full control. They are at the end of the day a basic sit in front of the PC hackers, and obviously they are dedicated to tearing apart Windows. It helps to remove the mystery of the hacker to know what they consider the challenge. This is why I speculate about this.

 

[Deleted member 178]

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.

 

[shmu26]

Appguard and Comodo protect the memory

Will the memory protection of Comodo help in this case, if you have HIPS on safe mode? Or do you need paranoid mode?

 

[Deleted member 178]

From what i recall the memory protection shouldn't be influenced by the mode level.

 

[shmu26]

From what i recall the memory protection shouldn't be influenced by the mode level.

So the memory protection you are referring to is what Comodo calls "shellcode injection"?

 

[Deleted member 178]

So the memory protection you are referring to is what Comodo calls "shellcode injection"?

more or less

• Detect shellcode injections (i.e. Buffer overflow protection) - Enabling this setting turns-on the Buffer over flow protection.

Background: A buffer overflow is an anomalous condition where a process/executable attempts to store data beyond the boundaries of a fixed-length buffer. The result is that the extra data overwrites adjacent memory locations. The overwritten data may include other buffers, variables and program flow data and may cause a process to crash or produce incorrect results. They can be triggered by inputs specifically designed to execute malicious code or to make the program operate in an unintended way. As such, buffer overflows cause many software vulnerabilities and form the basis of many exploits.

Turning-on buffer overflow protection instructs the Comodo Internet Security to raise pop-up alerts in every event of a possible buffer overflow attack. You can allow or deny the requested activity raised by the process under execution depending on the reliability of the software and its vendor. Click here for more details on the alerts.

For example , i couldn't use Sandboxie if it was not whitelisted in the Detect Shellcode Injection tab.

 

[shmu26]

more or less



For example , i couldn't use Sandboxie if it was not whitelisted in the Detect Shellcode Injection tab.

True, Comodo has a module for protecting memory. But we cannot assume that it protects from all kinds of memory exploits, just as we cannot assume that an AV with a detection module will detect all malicious samples.

 

[509322]

The code is next extracted from the memory, dropped on the disk in the form of DLLs, and injected to the system processes.

@Andy Ful

I don't have time to research this in-depth. It looks like the DoublePulsar uses a kernel-mode exploit to gain EoP to manipulate the system - one of which is to write *.dlls to disk. I very quickly combined infos from various webpages covering DoublePulsar since no one ever bothers to give complete details in their articles - a pet-peeve of mine.

Anyhow...

AppGuard is not designed to block exploits per se; AppGuard is designed to block post-exploit system manipulation at various policy points.

AppGuard blocks the loading of *.dlls according to policy.

Without testing I cannot provide a definitive guarantee, but based upon a quick grab of online DoublePulsar infos, AppGuard should prevent the *.dlls from being loaded.

However, I am certain that AppGuard will block the ransomware executable itself - for example, WannaCry.exe.

And I just want to point out to everyone that just can't seem to grasp this fundamental truth - put every single security soft that currently exists or will exist on the table and let pen-testers, malc0ders, and hackers have at them. I can guarantee that eventually every single one of those security softs will be bypassed at some point.

Get it ?

 

[Winter Soldier]

And I just want to point out to everyone that just can't seem to grasp this fundamental truth - put every single security soft that currently exists or will exist on the table and let pen-testers, malc0ders, and hackers have at them. I can guarantee that eventually every single one of those security softs will be bypassed at some point.

Has anyone any doubt about this?
They already do this, they take every security software looking for weaknesses to exploit, malcoders and criminals have very, very free time to do that.

 

[shmu26]

And I just want to point out to everyone that just can't seem to grasp this fundamental truth - put every single security soft that currently exists or will exist on the table and let pen-testers, malc0ders, and hackers have at them. I can guarantee that eventually every single one of those security softs will be bypassed at some point.

Get it ?

I doubt that the malcoders and hackers are spending much time on the more exotic security softs, because why bother? I suppose AppGuard is a juicy target, since government is using it. But who would bother to hack HMPA, ReHIPS, or VoodooShield?

 

[Winter Soldier]

But who would bother to hack HMPA, ReHIPS, or VoodooShield?

Uhm...but if they regularly visit MT, then they may change their mind

 

[military]

Default deny probably the most effective way, but not the most convenient for the ordinary user. There is a wish what and other principles of protection, in the majority of antiviruses, could cope with such threats.

 

[Andy Ful]

@Andy Ful

...
Without testing I cannot provide a definitive guarantee, but based upon a quick grab of online DoublePulsar infos, AppGuard should prevent the *.dlls from being loaded.
...

Thanks for the answer.
I think, that it would be not fair to demand from 'non anti-exploit software' protecting Windows OS against kernel exploits. The primary responsibility is on the Microsoft side. I have opened this thread to discuss how nasty this worm can be for default deny security solutions. It looks very nasty to me.

EDIT
I am glad, that in Windows 10, the kernel protection disables that kind of nasty worms.

 

[509322]

Thanks for the answer.
I think, that it would be not fair to demand from 'non anti-exploit software' protecting Windows OS against kernel exploits. The primary responsibility is on the Microsoft side. I have opened this thread to discuss how nasty this worm can be for default deny security solutions. It looks very nasty to me.

EDIT
I am glad, that in Windows 10, the kernel protection disables that kind of nasty worms.

If you look at the nastiest malware, it seems most of them are delivered via exploit.

So a sound protection strategy is to combine a good anti-exploit with a default deny solution - whether that be an anti-executable, auto-sandboxing, or software restriction policy.

However, if some new, unknown exploit method comes along then you should expect an anti-exploit soft to not protect against that exploit.

Pay attention to what I am saying... a new exploit method, and not a new exploit. There is a difference.

Go ask the Loman (Hitman Pro) brothers about exploits. They will explain the above.

 

[Andy Ful]

...
However, if some new, unknown exploit method comes along then you should expect an anti-exploit soft to not protect against that exploit.
...

I would say that EternalBlue & DoublePulsar worm is a mix of the old method (exploiting SMB, heap spray) and the new method (remotely patching the kernel and nonstandard DLL injection). It is not completely new because it cannot patch the Windows 10 kernel.

 

[509322]

I would say that EternalBlue & DoublePulsar worm is a mix of the old method (exploiting SMB) and the new method (remotely patching the kernel and nonstandard DLL injection). It is not completely new because it cannot patch the Windows 10 kernel.

What I meant is that if a anti-exploit does not have a mitigation - like SEHOP, Heapspray, EAF, etc - then it probably isn't going to prevent a new exploit method.

 

[Andy Ful]

While you were making your post I was editing mine . I read somewhere that the worm uses the heapspray method. But, I think that remote heapspray may be a challenge for some anti-exploits.

 

[509322]

SMBv1 has long been established as bad ju-ju.

I tested WannaCry on two unpatched and connected Win 7 (2011 with no applied updates) VMs, created file and network shares and still the SMBv1 exploit isn't working = I can't get one VM to infect the other. I see in the Wireshark captures on both VMs the SMB2 - but I want to see only SMB. So I enabled only SMB1 and still can't get the damn thing to work... LOL. just how it goes sometimes.

 

[509322]

While you were making your post I was editing mine . I read somewhere that the worm uses the heapspray method. But, I think that remote heapspray may be a challenge for some anti-exploits.

I generally don't take the time to research stuff like that in-depth. Researching for complete, accurate answers just takes way too much of my time.