- May 31, 2017
- 42
Is that true, that default deny security solutions can stop the EternalBlue & DoublePulsar attacks?
- Thread starter Andy Ful
- Start date
- Status
- May 31, 2017
- 1,719
I have to choose my words carefully so there is no misunderstanding, and so we do not start another argument
.The safest answer is... "because that is what they do".
I would love to see a kernel level attack similar to the EB/DP attack where the attack is not blocked at all, all inside of lsass.exe, and where a command line is not used at all. This type of attack would be outside the scope of application control utilities, and only an anti-exploit or windows patch could mitigate an attack like this.
But keep in mind, for true zero days, a windows patch simply does not exist, and as we all witnessed in the EB/DP attack, there is no guaranty that an anti-exploit can mitigate this attack either.
I am not an exploit expert, but I have not seen such an attack. If someone knows of one, I would be happy to check it out.
But as they say... be careful what you wish for
.
Andy Ful
From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
- Dec 23, 2014
- 8,497
I have to choose my words carefully so there is no misunderstanding, and so we do not start another argument
The safest answer is... "because that is what they do".
I would love to see a kernel level attack similar to the EB/DP attack where the attack is not blocked at all, all inside of lsass.exe, and where a command line is not used at all. This type of attack would be outside the scope of application control utilities, and only an anti-exploit or Windows patch could mitigate an attack like this.
But keep in mind, for true zero days, a Windows patch simply does not exist, and as we all witnessed in the EB/DP attack, there is no guaranty that an anti-exploit can mitigate this attack either.
I am not an exploit expert, but I have not seen such an attack. If someone knows of one, I would be happy to check it out.
But as they say... be careful what you wish for
That is true. Criminals do not want to spend time and money to create a sophisticated 0-day malware. That is why SRP/Anti-exe are still useful in post-exploitation stage. The nasty things like Stuxnet, EternalBlue, DoublePulsar, etc., were created by government agences.
- May 31, 2017
- 42
Not sure why you believe that a command line is essential. I recommend against using a command line, because it'll be on a vulnerable process list and trigger a process spawn by anti-exe (VPL like I just mentioned).
@Andy Ful has already posted details/quotes about the DLL injection via the exploit. Make a custom DLL which does something malicious and apply it with the exploit; don't spawn any additional processes - if you do decide to spawn another process for whatever reason, make sure it uses dynamic forking (also known as "process hollowing" or "RunPE") and if the process architecture is 32-bit running on a 64-bit OS you can use Heavens Gate to confuse AV solutions should they inject even if the target for the dynamic forking is considered "trusted" (dynamic forking will trick security solutions, including anti-executable, into believing that the program running in memory is the one you targeted when in actual fact you start it and then suspend it, then you replace it in memory with the malicious PE).
Make a Win32 C++ application in Visual C++ with the DLL template, disable things like optimization and make it on multi-threaded settings - make sure the run-time is statically linked and not dynamic. Then within the DLL Main function for the DLL_PROCESS_ATTACH you call a function you setup which will execute malicious code.
Here are some ideas you can do within your DLL which are malicious for your file-less attack test:
- Install a device driver -> make the device driver "driverless"/mix it with a Driver Signature Enforcement bypass (e.g. DSEFix if you're on a version of Windows where it isn't patched).
- Inject code into another process like a web browser to steal information.
- Patch files on the system belonging to other software.
- Modify the Windows Hosts file.
- You can even terminate the VoodooShield processes and unload the VSScanner.sys driver if you want.
If you decide to use a kernel-mode driver to be installed, lsass.exe is running under SYSTEM so you can get SeLoadDriverPrivilege via RtlAdjustPrivilege. You might even be able to spawn another program which would already be installed and trusted by anti-executable solutions by stealing the access token from lsass.exe itself/another Windows process like winlogon.exe and then using CreateProcessAsUser using those token -> do it with dynamic forking if you want so anti-executable solutions think that a trusted process like chrome.exe is being spawned when in reality it is your precious rundll32 program LOL.
Do whatever you want in the DLL. Then use the exploit which you are so used to testing to have that DLL injected into lsass.exe and test it all out.
Like I already said in previous posts, I am not experienced with Metasploit otherwise I would test it out myself. Go make a malicious DLL and test the exploit with that if you care so much. You'll find if you do it right it'll work flawlessly without anti-exe intervening, because it doesn't take a genius to figure out that if another process which is not known and trusted is not spawned, then anti-exe won't intervene.
Have fun with that. Gl
Last edited:
- May 31, 2017
- 1,719
Hehehe, instead of speculating, will someone please run the above test? I ran the last one, so it is someone else's turn
. heheheYou sure sound like mWave / Wave BTW.
Everyone have a great weekend!
- May 31, 2017
- 42
Maybe I have tested the circumstances without deploying a file-less exploit attack such as EB (since I am not a Metasploit expert). Alternatively, it could just be a bunch of rubbish I pulled out of thin air. Who knows?Hehehe, instead of speculating, will someone please run the above test? I ran the last one, so it is someone else's turn
You're not wrong. For once. Interestingly. Nice catch... I was definitely concealing myself?
Hmm.. I certainly did not expect the chuckle brothers to reunite tonight. If only I was as good at being a "cyber ghost" as you are... pls teach me (*face palm*?)trust me no one here is mWave, thank god
Andy Ful
From Hard_Configurator Tools
Thread author
Verified
Honorary Member
Top Poster
Developer
Well-known
- Dec 23, 2014
- 8,497
There would be no problem with doing that. Such scenario is probable, when Enterprises are the targets, like in WannaCry attack.
But among home users, SRP/Anti-exe are uncommon solutions, so criminals do not bother to fight them. For more profit, they should rather add to their malware, anti SRP/Anti-exe check to avoid more experienced users.
- May 31, 2017
- 1,719
How funny! Initially you had me fooled because of your *face palm* here...
Video Review - EternalBlue and DoublePulsar application whitelisting test
But the last few post sure sounded like you, and now that you used the term *face palm*... yeah, it is mWave
.I thought of another very simple way of explaining the command lines. I say simple because it really does not explain everything completely. But think of it this way... when you see youtubers performing Metasploit (and other) tests, a lot of times the command lines they are entering into the command prompt to perform the attack... well, those are (or result in) windows command lines that AE's will block. Not all of them, but a lot of them.
Is there a way to bypass an AE without command lines? Probably... anything is possible, but I am just not aware of such an attack, because exploits are not my main focus. Having said that, I think it would be quite difficult to fully own a machine without an AE blocking something.
Keep in mind, VS's only job is to block executables, scripts and command lines. I know a little about exploits (all I really care or need to), but not enough to try to impress everyone on here with my "vast knowledge of exploits"... that is not what holds my interest. What I am interested in is creating a user-friendly computer lock (GUI development), and I am also highly interested in ML/Ai.
Metasploit is actually pretty easy to use and understand... you should try it sometime, I think you would like it a lot. It really gives you a lot of insight on how these types of attack occur. And it is fun
.
- Aug 30, 2012
- 6,598
Private stuff and history aside, please stay on topic
- Aug 30, 2012
- 6,598
We should always be as nice as possible towards each other. That's the primary thing of MalwareTips Security, privacy, antiviruses, antiexes, exploits and vulnerabilities are secondary
Security, privacy, antiviruses, antiexes, exploits and vulnerabilities are secondary
- May 31, 2017
- 42
I'm not trying to impress anyone, I don't have anyone to impress. I merely intervened after watching the on-going debate you were having with @Umbra because I disagreed with some things, and agreed with @Umbra.
Ever since I intervened over on Wilders Security I have been trying to explain that lsass.exe was compromised which means that the game is already over (technically). I agreed that VoodooShield blocked the DoublePulsar tools in the test, but have tried to explain that if the attack is deployed without the additional process (therefore the post payload becomes executed from within lsass.exe) then it means the product would fail; there would be no additional process to block from running, whereas the post payload would still continue.
@Andy Ful posted the following on this thread recently:
This is already evidence to back up what I have stated previously... Move the malicious code into a DLL which is then injected into lsass.exe via the exploit & then watch the magic happen.
If I try to make an informative post then I am automatically trying to prove that I have a "vast knowledge" on specific topics. If I try to prove a point then I get smacked in the face without re-creating the video to prove what was said even though it is perfectly logical and reasonable and it gets labelled as an invalid "speculation", and if I test a specific feature (e.g self-defense) then I am required to bypass the entire product's process monitoring for it to be valid.
It doesn't even matter to me anymore, I give up with this debate entirely. To avoid future issues, you won't see me mentioning VoodooShield/VS products publicly anywhere further-on.
Have a good weekend everyone.
- May 31, 2017
- 1,719
Sorry, I need to clarify... when I said "but not enough to try to impress everyone on here with my "vast knowledge of exploits", I was certainly not referring to anyone specifically... I was just saying that I am not an exploit expert, and I was not trying to impress anyone with my limited knowledge of exploits.I'm not trying to impress anyone, I don't have anyone to impress. I merely intervened after watching the on-going debate you were having with @Umbra because I disagreed with some things, and agreed with @Umbra.
Ever since I intervened over on Wilders Security I have been trying to explain that lsass.exe was compromised which means that the game is already over (technically). I agreed that VoodooShield blocked the DoublePulsar tools in the test, but have tried to explain that if the attack is deployed without the additional process (therefore the post payload becomes executed from within lsass.exe) then it means the product would fail; there would be no additional process to block from running, whereas the post payload would still continue.
@Andy Ful posted the following on this thread recently:
This is already evidence to back up what I have stated previously... Move the malicious code into a DLL which is then injected into lsass.exe via the exploit & then watch the magic happen.
If I try to make an informative post then I am automatically trying to prove that I have a "vast knowledge" on specific topics. If I try to prove a point then I get smacked in the face without re-creating the video to prove what was said even though it is perfectly logical and reasonable and it gets labelled as an invalid "speculation", and if I test a specific feature (e.g self-defense) then I am required to bypass the entire product's process monitoring for it to be valid.
It doesn't even matter to me anymore, I give up with this debate entirely. To avoid future issues, you won't see me mentioning VoodooShield/VS products publicly anywhere further-on.
Have a good weekend everyone.
I think everyone understands what happened in the EB/DP attack and test... people are aware that if the attack is outside the scope of an AE (blocking an executable, script or command line), then it will prove ineffective at blocking the attack. But as I mentioned, for a true zero day, there will not be a Windows patch available, and it is certainly iffy whether an anti-exploit product will block the attack either. Basically, everything would have a difficult time blocking the attack, if it is outside the scope of an AE.
Off-topic/non-technical post removed. if people has nothing to say about the discussion itself , please refrain to post .
This is not a soccer game with supporter cheering/boohooing the other side.
Thanks.
This is not a soccer game with supporter cheering/boohooing the other side.
Thanks.
indeed
and to all members , remind that :
1- An in-memory (kernel or not) exploit or any "direct" exploits, are always outside the scope of classic SRP/anti-exe unless those have a dedicated anti-exploit mechanism in place, which is rare.
2- if they have the said protection, we have to know how this protection is acting, "memory protection" is a general term , that may imply several different mechanism, which in our EB-DP attack , some of them may not suffice to stop it.
3- SRP/Antiexe, may block some stage of the attacks, no one here is denying this, we saw it on vids and many articles; but blocking some stage isn't blocking the full attack, which in our case start with Eternalblue , DP just being a "method" for EB to allow the attacker to use more malicious tools on the targeted system.
4- if you wan't to protect against potential exploits, use an anti-exploit or something with similar feature, they were made for it, don't involve other products like anti-exe/SRPs , they have nothing to do at all with exploits...however as said in point 2 , they have some mechanism in place to prevent some kind exploits (like those using powershell, cmd, etc...)
5- no security soft can protect against an innovative attack , we all know that, the users/vendors can only react afterwards. so no point of discussing about future yet-to-happen stuff we don't know.
6- kernel exploit can't be blocked , they run in a level (aka Ring 0, kernel level, etc..) under the one security software are usually placed; it is like asking a surveillance plane with just a radar to detect a submarine deep in the ocean...
Eternalblue is a kernel exploit, running Doublepulsar at kernel level , now you see why it is a very effective exploit.
Detecting and Analyzing Malware in the Kernel
So the only way to block kernel attacks is by protecting (to some extent) the kernel, like Win8/10's patchguard or its secureboot (drivers verification) are trying to do , or deploying kernel virtualization via hardware .
Don't ask any classic security softwares to protect against kernel exploits, they can't anymore, it is now the job of Win10 various protection mechanism, next build will introduce EMET directly in Win10.
Last edited by a moderator:
note that EB-DP is targeting enterprise first , home user were caught with it because Win7 enabled SMB by default on all Windows' versions.
EB is a network kernel exploit made to be spread across the compromised network. This is the main "module" of the attack , it runs "in-memory" (hehe i know u dislike this term , but it's its method) at kernel level.
Once EB is in a network , you can't stop it unless disabling SMB/port 445.
Because it is a kernel exploit, its payload run also at kernel level, the payload can't be prevented to be installed/deployed by classic home users security solutions.
The payload in our case is DP , not that it can be anything else if the attacker want to. Important point here.
In the case of DP it is an kernel level Backdoor that will inject code in its default targeted process which is lsass.exe; again the attacker can change the targeted process as he see fit. important point to consider again.
DP only inject code in lsass.exe, then lsass.exe use rundll32.exe to create a reverse-TCP connection to the attacker framework (metasploit on Kali usually).
Once the connection is successful, the attacker has a direct entrance to the targeted system/network and can deploy various malicious tools at disposal.
Note that even if the connection attempt is blocked by a security product , the DP backdoor is still here on the machine and others machine in the network, if the attacker manage to disable any security software, the connection can successfully complete.
Remember EB spread across a compromised network, so obviously if it is in the network, the attacker already had a way to get EB in , and so can deployed other attacks to disable security softs.
The real deal is EB, DP is EB's tool to deploy other tools or execute specific malicious tasks. DP can be replaced by something else even more nasty.
So to answer your question:
originally EB-DP is a in-memory kernel exploit used to spread across a penetrated network (penetration can be made by various methods), then create a backdoor so the attacker can access the machines in the network to deploy malicious tools.
This attack was created by the CIA to spy on the victims so the use of a backdoor was needed, but now let say i'm not CIA but a cybercriminal, i dont need the DP backdoor , i just need EB coupled with a something more nasty inflicting direct damages.
The EB exploit is ineffective now since MS patched Windows, so debating about it or speculating of a similar attack is pointless unless it appears, and since kernel exploits can't normally be blocked by security softs once executed, there is no need theorizing about which security softs would stop the full attack. If EB is in, the system is owned. period.
look at ghostHook attack : GhostHook Attack Bypasses Windows 10 PatchGuard
We are able to execute code in the kernel and go unnoticed by any security feature Microsoft produces,” said Kobi Ben Naim, senior director of cyber research. “Many other security vendors rely on PatchGuard and on DeviceGuard in order to receive reliable information and analyze whether it’s benign or an attack. This bypass enables us to go unnoticed versus the security vendors we checked (this includes antimalware, firewalls, host-based intrusion detection and more) that rely on those security layers to provide reliable information.”
Conclusion: If you can't stop EB , there is no point debating about blocking the tools deployed afterwards.
Last edited by a moderator:
- May 31, 2017
- 1,719
Absolutely!!! The one objective of the EB / DP attack is to load / install DP's malicious tools.
So if DP's tools are blocked, the system obviously is not fully compromised.
From the article you posted above...
“This technique requires that an attacker has already fully compromised the targeted system.” a Microsoft representative said in a statement provided to Threatpost.
Does anyone have an attack walk through or test video for GhostHook? I will run the tests and see.
So if DP's tools are blocked, the system obviously is not fully compromised.
From the article you posted above...
“This technique requires that an attacker has already fully compromised the targeted system.” a Microsoft representative said in a statement provided to Threatpost.
Does anyone have an attack walk through or test video for GhostHook? I will run the tests and see.
no you don't understand, the system and entire network is already compromised by EB. DP is just a tool of EB. Blocking the reverse-TCP connection doesn't nullify EB or DP damages.
the attacker can deploy other methods, when he see his reverse connection was stopped.
- May 31, 2017
- 1,719
Sure, you can replace DP with a different payload, but there is a heck of a chance it will be blocked as well. DP is pretty nasty... it has just about every backdoor / hacker tool in the book, so it really is not necessary to replace it... just use DP (if its tools are not blocked).
- May 31, 2017
- 1,719
But if DP is blocked from performing its one objective, what makes you think for a second that a different payload would not have the same result?
- Status
Similar threads
