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

[shmu26]

Thanks for explanation. Like @Lockdown said, SMB1 is not how the latest version of Windows will be delivered to you.

You have the option of downloading the ISO for the latest Windows version, and using that for your upgrade. I see you are on Windows 10. So you can mount the ISO, run the installer file in it, and by default it will upgrade you to the newest version of Windows, saving your apps and files. After it finishes the initial stage of checking out your system and downloading latest updates, and it actually starts to do the real upgrade process, you could pull the plug on your internet connection, until it's all finished. You don't have to, but if you are concerned about an open internet connection, you could do it.

By the way, the tweaks you made to Windows will not be there anymore after the upgrade. You will have to tweak again.

 

[Deleted member 178]

Hi @shmu26, I'll take note of asking a question more clearly. I was meant to ask would the tweak of disabling SMB1 be a sufficient security measure to prevent being infected by wannacry so I can update to the latest version of windows.

Yes,but must be redone with every clean install/upgrades.

 

[My name Jeff]

@Umbra I also connected to the internet via standard user account to update to the current windows version.

 

[Andy Ful]

Why is everyone so worried about exploits that Microsoft has already patched ? It's pointless to worry about them - unless you continue to use an unpatched version of Windows, have SMBv1 enabled and are using it for SMB client-server file sharing and such.
...

The problem is not with the concrete exploit, but with the nasty idea of remote kernel exploit.
I think, that most MalwareTips members would agree with you (and me), that it is Microsoft concern to quickly patch those exploits, like in the case of EternalBlue. There is another problem for enterprises - to update or not to update. Sometimes the updates can be worse than malware, so many enterprises defer updates, and rely on security solutions. The fact that security program can stop some DLL payloads is another thing.

 

[Andy Ful]

I think this article has been revised. When I read it a week ago, I recall that the original version of this article stated that *.dlls were written to disk in the first or second paragraph, Analyzing the DOUBLEPULSAR Kernel DLL Injection Technique | Countercept, but I could be having a memory lapse.

Writing the EternalBlue and DoublePulsar DLLs to the disk was mentioned in some other articles, and it is coded in EternalBlue. From what I understand, those DLLs are next executed without using the standard method. So, I think that EternalBlue & DoublePulsar exploit cannot be stopped by blocking/monitoring rundll32.exe. It is an open question if DoublePulsar uses rundll32.exe to inject the payload or the payload itself uses rundll32.exe to execute additional Dll.

 

[ZeroDay]

Why is everyone so worried about exploits that Microsoft has already patched ? It's pointless to worry about them - unless you continue to use an unpatched version of Windows, have SMBv1 enabled and are using it for SMB client-server file sharing and such.



AppGuard is not an anti-exploit. We recommend that other means be employed to protect against application, kernel and network exploits.

I think this article has been revised. When I read it a week ago, I recall that the original version of this article stated that *.dlls were written to disk in the first or second paragraph, Analyzing the DOUBLEPULSAR Kernel DLL Injection Technique | Countercept, but I could be having a memory lapse.

I'm not worried at all I was just curious if there was a Comodo bypass. I don't even use Comodo I use KIS. But like I say I'm not worried in the least.

 

[shmu26]

I'm not worried at all I was just curious if there was a Comodo bypass. I don't even use Comodo I use KIS. But like I say I'm not worried in the least.

You are not the only curious one.
Most of the Comodo videos that I see here on MT involve plunking a few malware samples down on the ole desktop, and watching them get autosandboxed, when they are manually executed.
That system of testing is a forgone conclusion, and doesn't even begin to address these exploit issues.

I think that people are rightly curious about this stuff, because we assume that there will be more and more advanced exploits coming along, of various types, and they will ravage many computers, until they are finally identified and eventually patched by Microsoft.

 

[Deleted member 178]

check the video:




so basically if you are behind a NAT router , you shouldn't get attacked because the attacker can't see what is behind it.

 

[S3cur1ty 3nthu5145t]

You are not the only curious one.
All the Comodo videos that I see here on MT involve plunking a few malware samples down on the ole desktop, and watching them get autosandboxed, when they are manually executed.
That system of testing is a forgone conclusion, and doesn't even begin to address these exploit issues.

I think that people are rightly curious about this stuff, because we assume that there will be more and more advanced exploits coming along, of various types, and they will ravage many computers, until they are finally identified and eventually patched by Microsoft.

It has been well known for a very long time that as a free security suite CIS provides very good security with one exception, windows exploits.

To reiterate a comment seen on a post here in this forum, if the NSA can be hacked, what makes users here believe any amount of security they deploy on a home system will be bullet proof.

 

[shmu26]

It has been well known for a very long time that as a free security suite CIS provides very good security with one exception, windows exploits.

To reiterate a comment seen on a post here in this forum, if the NSA can be hacked, what makes users here believe any amount of security they deploy on a home system will be bullet proof.

CFW does have some exploit protection, and CFW10 actually has a very interesting new anti-exploit feature called embedded code detection (which is only half enabled at default settings, and the same is true for CS settings). The problem is that these features are poorly documented and rarely tested. So we don't know what they do, and how well they do it.

 

[509322]

Writing the EternalBlue and DoublePulsar DLLs to the disk was mentioned in some other articles, and it is coded in EternalBlue. From what I understand, those DLLs are next executed without using the standard method. So, I think that EternalBlue & DoublePulsar exploit cannot be stopped by blocking/monitoring rundll32.exe. It is an open question if DoublePulsar uses rundll32.exe to inject the payload or the payload itself uses rundll32.exe to execute additional Dll.

Eventually someone will publish the run sequence along with other details. However, disabling rundll32 shell and running the exploit should provide some preliminary answers; if the exploit succeeds with rundll32 disabled, then that suggests that the exploit itself is not dependent upon rundll32.

the nasty idea of remote kernel exploit.

The kernel is Microsoft's domain.

 

[Andy Ful]

...
However, disabling rundll32 shell and running the exploit should provide some preliminary answers; if the exploit succeeds with rundll32 disabled, then that suggests that the exploit itself is not dependent upon rundll32.
...

It can be also done, by extending the test performed by Dan. After blocking the payload by VoodooShield, one should run the DoublePulsar detection script.

 

[Andy Ful]

Eventually someone will publish the run sequence along with other details. However, disabling rundll32 shell and running the exploit should provide some preliminary answers; if the exploit succeeds with rundll32 disabled, then that suggests that the exploit itself is not dependent upon rundll32.

The kernel is Microsoft's domain.

I found one test with EternalBlue & DoublePulsar when not using meterpreter payload. Autors used the calc.exe as a payload. Here is the interesting fragment:

Step 3: INSTALLATION – Using DoublePulsar to launch an additional Backdoor
The DoublePulsar backdoor allows to inject and run any DLL (Dynamic Link Library), that way compromising the computer and using it for whatever purpose. I was able to load a DLL into LSASS.EXE spawning calc.exe as a POC. But this off course could just as well have been something malicious. (Meterpreter, Empire, Beacon).

https://www.dearbytes.com/blog/playing-around-with-nsa-hacking-tools/

If we look at the second image from this article, we can see the Task Manager on the target machine after successfully exploited system. The important thing is that there is no sign of rundll.exe!
So indeed, it is possible to install EternalBlue & DoublePulsar on the target machine without using rundll.exe !

 

[Andy Ful]

It is time to finalize this thread with some conclusions.

1. After reading some other threads it is clear to me, that generally, SRP and Anti-exe solutions cannot stop remote kernel exploits (like EternalBlue & DoublePulsar).
2. This is not a big surprise, because they are not supposed to be antiexploit programs.
3. There were some suspicions, that SRP / Anti-exe with memory protection or system processes monitoring could stop EternalBlue & DoublePulsar exploit. The truth is that they cannot (so far).
4. It is true, that SRP / Anti-exe can stop many post-exploitation payloads after successful EternalBlue & DoublePulsar infection.
5. It is also probable that SRP / Anti-exe cannot stop more advanced attacks when remote kernel exploit will not use the payload in the form of executable.
6. I did not see the conclusive tests about sandboxing / HIPS solutions (like Comodo), so until someone will prove the opposite, it is wise to assume that generally, they cannot stop remote kernel exploits (like EternalBlue & DoublePulsar). Of course, in many cases (like SRP / Anti-exe), they can stop post-exploitation payloads.

Home users should not be afraid of remote kernel exploits, because:

1. Microsoft is truly afraid of such exploits, and the patches are quickly available with security updates.
2. The home networks have a good protection against internet remote attacks (router).
3. There are many, more dangerous ways to infect the computer (spam, phishing, happy clicking, etc.).

 

[Deleted member 178]

i will comment in Red

It is time to finalize this thread with some conclusions.

1. After reading some other threads it is clear to me, that generally, SRP and Anti-exe solutions cannot stop remote kernel exploits (like EternalBlue & DoublePulsar). Exact
2. This is not a big surprise, because they are not supposed to be antiexploit programs.Exact
3. There were some suspicions, that SRP / Anti-exe with memory protection or system processes monitoring could stop EternalBlue & DoublePulsar exploit. The truth is that they cannot (so far). All depend what the memory protection is suppose to do, AG Consumer's one is to protect against reading/copying/modification of the memory of a process from another, not kernel exploit.
4. It is true, that SRP / Anti-exe can stop many post-exploitation payloads after successful EternalBlue & DoublePulsar infection. i agree
5. It is also probable that SRP / Anti-exe cannot stop more advanced attacks when remote kernel exploit will not use the payload in the form of executable. seems highly probable
6. I did not see the conclusive tests about sandboxing / HIPS solutions (like COMODO), so until someone will prove the opposite, it is wise to assume that generally, they cannot stop remote kernel exploits (like EternalBlue & DoublePulsar). Of course, in many cases (like SRP / Anti-exe), they can stop post-exploitation payloads. i believe so too

Home users should not be afraid of remote kernel exploits, because:

1. Microsoft is truly afraid of such exploits, and the patches are quickly available with security updates. yes
2. The home networks have a good protection against remote attacks (router). indeed
3. There are many, more dangerous ways to infect the computer (spam, phishing, happy clicking, etc.). obviously

obviously we agree on everything, because when it comes to SRP/Antiexe (and other deny-default solutions) , we know what we are talking about (because we used them for LONG period of time )

 

[Visa]

I was able to load a DLL into LSASS.EXE spawning calc.exe as a POC.

Even better. Within the DLL just do something like load a device driver, handle hijacking to shut down AVs even if they are protected, ... Game over. If you can use any DLL then it is even easier for someone to adapt, no need to spawn another process. = anti-exe cannot do nothing.

If you want you if not already done you can even conceal evidence of the DLL being loaded within DLL by unliking it from the PEB (ModulesList) or manual map inject it from the start, then if someone investigates they cannot just find the DLL through common methods by enumerating through modules, so apps like PH won't even find it within the process.

As far as evading any hooks in case an AV starts hooking in processes like lsass.exe to identify strange behavior, just copy ntdll.dll -> rename it to something else -> manual map the copy into lsass.exe and then call NTAPI functions within the copy of ntdll.dll = system call like ntdll does but evades hooks

So yeah this exploit is pretty damn powerful IMO

 

[danb]

It is time to finalize this thread with some conclusions.

1. After reading some other threads it is clear to me, that generally, SRP and Anti-exe solutions cannot stop remote kernel exploits (like EternalBlue & DoublePulsar).
2. This is not a big surprise, because they are not supposed to be antiexploit programs.
3. There were some suspicions, that SRP / Anti-exe with memory protection or system processes monitoring could stop EternalBlue & DoublePulsar exploit. The truth is that they cannot (so far).
4. It is true, that SRP / Anti-exe can stop many post-exploitation payloads after successful EternalBlue & DoublePulsar infection.
5. It is also probable that SRP / Anti-exe cannot stop more advanced attacks when remote kernel exploit will not use the payload in the form of executable.
6. I did not see the conclusive tests about sandboxing / HIPS solutions (like COMODO), so until someone will prove the opposite, it is wise to assume that generally, they cannot stop remote kernel exploits (like EternalBlue & DoublePulsar). Of course, in many cases (like SRP / Anti-exe), they can stop post-exploitation payloads.

Home users should not be afraid of remote kernel exploits, because:

1. Microsoft is truly afraid of such exploits, and the patches are quickly available with security updates.
2. The home networks have a good protection against internet remote attacks (router).
3. There are many, more dangerous ways to infect the computer (spam, phishing, happy clicking, etc.).

We finally agree... that sums it up nicely. In this attack, the difference between SRP and AE is whether or not DP is fully installed and is able to utilize its malicious tools or not.

BTW, I performed the Comodo tests with default settings and with CS's settings. But since I am unable to comment on other vendors, I unfortunately cannot release the results of the test.

Have a great weekend!!!

 

[Deleted member 178]

We finally agree... that sums it up nicely. In this attack, the difference between SRP and AE is whether or not DP is fully installed and is able to utilize its malicious tools or not.

As i said, depend the product and what it is supposed to do, you can't generalize.
And as i said , i don't care about the tools being usable or not, because the breach is already there.
I care only to protect against the breach itself. The rest doesn't matter.

i dont care about my car hit the wall and the airbag protect me, i care not to hit the wall in the first place...
People don't care about AV's removal abilities, they care not being infected in the first place...

Simple logic...

 

[Visa]

I've been thinking about virtual patching methods for this exploit for awhile now, but I am unable to test it out myself and do the reversing on the internals because I am not experienced with things relating to Metasploit (never even used Metasploit in my life nor am I ashamed of having lack of knowledge on that).

However for the lsass.exe target one idea I've thought of would be to detect thread creation from kernel-mode via kernel-mode callbacks (for x64 support); you can use this to identify thread creation within the lsass.exe process... Then apply some potential filtering and block this if deemed the thread should not have been created - since the newly created remote thread would be responsible for executing the injected code which could manual map another malicious DLL and the such (e.g. like in this case with the DLL being injected, it should work by using the injected code on the new thread be responsible for loading the DLL).

Only problem with the above is that you cannot do it for all the processes since it would cause issues, you never know when a program will create a new thread to execute code simultaneously... (e.g. threading to run code at same time within a process to speed things up, like AV scanners use multiple threads).. And you never know what process will be targeted by the exploit (assuming it doesn't have to be lsass.exe) so it is quite tricky.

I guess another idea would be verification for all DLLs loaded within system processes (e.g. require code signing authenticity) but an attacker can buy one or steal them/use an exploited one they bought online so that one is tricky too since it would be far from full proof.

I guess the only real solution would be on MS part with patching (did they already patch the SMB issue?).

Maybe my ideas were just useless though, I really am not sure on this one.

 

[danb]

I've been thinking about virtual patching methods for this exploit for awhile now, but I am unable to test it out myself and do the reversing on the internals because I am not experienced with things relating to Metasploit (never even used Metasploit in my life nor am I ashamed of having lack of knowledge on that).

However for the lsass.exe target one idea I've thought of would be to detect thread creation from kernel-mode via kernel-mode callbacks (for x64 support); you can use this to identify thread creation within the lsass.exe process... Then apply some potential filtering and block this if deemed the thread should not have been created - since the newly created remote thread would be responsible for executing the injected code which could manual map another malicious DLL and the such (e.g. like in this case with the DLL being injected, it should work by using the injected code on the new thread be responsible for loading the DLL).

Only problem with the above is that you cannot do it for all the processes since it would cause issues, you never know when a program will create a new thread to execute code simultaneously... (e.g. threading to run code at same time within a process to speed things up, like AV scanners use multiple threads).. And you never know what process will be targeted by the exploit (assuming it doesn't have to be lsass.exe) so it is quite tricky.

I guess another idea would be verification for all DLLs loaded within system processes (e.g. require code signing authenticity) but an attacker can buy one or steal them/use an exploited one they bought online so that one is tricky too since it would be far from full proof.

I guess the only real solution would be on MS part with patching (did they already patch the SMB issue?).

Maybe my ideas were just useless though, I really am not sure on this one.

You should try it and see. I suspect that a command line is going to have to be thrown at some point, and that is a great place for an AE to block the attack.