Bypassing Emsisoft (Video)

[Amelith Nargothrond]

He used a confirmed escalation of privilege exploit - more than likely one of the many that are passed-around the pen-tester community. He needed to bypass UAC and elevate the agent so he could run the Mimikatz module which itself needs admin privileges.

He used the Invoke-BypassUAC.ps1 that's in the privsec\bypassmodule. The command you see him type "bypassuac EmsiBypass" = bypassuac is an alias and EmsiBypass is the listener which must be specified. The elevated agent is denoted by the * symbol next to it. Next he runs Mimikatz.

Emsisoft itself was not exploited.

If Emsisoft was not the target, their security was circumvented. Still the loser of the test in the end, technically.
It's just like accidentally executing a malware, which happens all the time, malware which does stuff to your system, malware which should've been stopped by the AV that says it will protect you with a thousand layers. Again, Emsisoft is great, but has its weaknesses, like any other AV.

Let's call these malware 0-day, as they don't have signatures for them. As an example, many Metasploit exploits are blocked by AVs, but just because they are known as being used for illegal activities. It's a matter of perception really, Metasploit is not meant for illegal stuff, but rather to demonstrate that your product has its weaknesses in some versions, in some circumstances and environments.

 

[509322]

If Emsisoft was not the target, their security was circumvented. Still the loser of the test in the end, technically.
It's just like accidentally executing a malware, which happens all the time, malware which does stuff to your system, malware which should've been stopped by the AV that says it will protect you with a thousand layers. Again, Emsisoft is great, but has its weaknesses, like any other AV.

Let's call these malware 0-day, as they don't have signatures for them. As an example, many Metasploit exploits are blocked by AVs, but just because they are known as being used for illegal activities. It's a matter of perception really, Metasploit is not meant for illegal stuff, but rather to demonstrate that your product has its weaknesses in some versions, in some circumstances and environments.

The guy's whole point is that he doesn't have to go to, what he considers to be, any extraordinary lengths to "bypass" security software. All he needed to do was reach for openly available PowerShell Empire or Metasploit and use whatever techniques happen to be working at the moment within those frameworks.

I am simply saying that, based upon what I see in the video, Emsisoft itself was not exploited. Black Cipher Security's methods - in all the videos he posted on his YouTube channel - appear to me as being pretty much "off-the-shelf."

I don't know all the low-down nitty-gritty technical innards of PowerShell Empire. The entire code is open for all to see on GitHub if anyone wishes to read it line-for-line. From what I understand it manages to do what it does by wrapping PowerShell in Python. It could be launching PowerShell from a dll or other means like an executable. It does use *.ps1 scripts and there are various loadable modules - Mimikatz for example. You don't need powershell.exe (the powershell Shell) to run PowerShell on Windows.

My involvement here is not to defend Emsisoft. Fabian and Christian can do that for themselves if they think it necessary. I am just saying that there is a distinct technical difference between Emsisoft being exploited itself or it being bypassed.

As far as any security soft or even a multi-layered security configuration providing guaranteed protection against 100 % of all threats or guaranteed to be "unknowledgeable or negligent user-proof," for a lot of reasons that just isn't going to happen. And that is the greater message that Black Cipher Security is making with these videos - it goes something like this... "Don't be completely dependent upon security softs as they will fail you at some point. Users need to be educated and practice recommended IT security best practices. Such a user will be better protected. They will not be perfectly protected, but better protected."

Basically, the guy is saying stack your IT security deck with educated, disciplined users...

I have one answer to that based upon observation and experience - educate your workstation users, but still lock them out of the system so they can't modify it either with or without intent. A single user can bring the entire house down. Take away users' ability to be users "who want to use stuff." It works surprisingly well.

 

[Amelith Nargothrond]

Got it, thanks for the detailed feedback @Lockdown .
I prefer to lock them out in a different way, by virtualizing their environment (if this is a possibility for the company), giving them apparently some freedom (so they don't call me all day to allow them to do stuff), but that's it, nothing outside their container. But it's not something i can do in many places unfortunately.

 

[509322]

Got it, thanks for the detailed feedback @Lockdown .
I prefer to lock them out in a different way, by virtualizing their environment (if this is a possibility for the company), giving them apparently some freedom (so they don't call me all day to allow them to do stuff), but that's it, nothing outside their container. But it's not something i can do in many places unfortunately.

However you do it I don't think it much matters - whether with SRP or VDI or both or however. Those clients that specifically pursue those protection models tend to be reasonably good natured when stuff doesn't work as they expect. Fixes tend to be fairly mundane. The real problems happen when Admins are force-fed something that they did not want by management. At least that is what I have seen. And of course there is always the occasional IT nuclear meltdown - and it seems no matter what happened or why it happened - they want to blame everybody in sight for it.

 

[_CyberGhosT_]

Thanks Jeff, I mentioned this was not an Emsisoft bypass in the beginning.
You put it far in a far more eloquent manner though, Thanks for that

 

[Emsisoft]

We appreciate the testing and the demonstration! Our team will improve detection of attacks like that in the upcoming software release.

 

[509322]

Thanks Jeff, I mentioned this was not an Emsisoft bypass in the beginning.
You put it far in a far more eloquent manner though, Thanks for that

I said it was not an exploit of Emsisoft itself to gain escalation of privilege. And the technique used didn't disable any part of Emsisoft. It takes advantage of the default whitelisting of cmd and PowerShell.

 

[Emmanuellws]

Black Cipher Security bypass video .after a small friendly chatting with them, I managed to get the loophole in their test....it will always be successful bcoz it is running Windows 7, with powershell 1.0.....wait till you see how hard they need to bypass any product when running in Windows 10 Environment, and if your AV supports AMSI, and powershell 2.0 disabled...running only Powershell v5 and not on local....they will fail.

 

[Deleted member 178]

But Empire can be executed via a dll. So even his test works on old systems, the attack vector is still valid. it abuse the whitelisting of powershell by products.

 

[Emmanuellws]

But Empire can be executed via a dll. So even his test works on old systems, the attack vector is still valid. it abuse the whitelisting of powershell by products.

Agree, but on Windows 7 and Powershell 1.0 makes it easier..If an AV don't have whitelisting, might as well don't install any AV. Powershell v5, strips a lot of cmdlets and reduce attacking vector. The video simply didn't proves anything, as in the end you need proactive network monitoring tool to detect the attack like LogRhythm and to stop the attack. Basically, it is no longer a malware but rather a breach. It's no AV with whitelisting job

 

[enaph]

Maybe I have missed something but why there was no reaction from EAM's BB?

 

[_CyberGhosT_]

We appreciate the testing and the demonstration! Our team will improve detection of attacks like that in the upcoming software release.

Thanks for the kind words, and keep up the awesome work, your hard work is appreciated.
PS: and give Mr Ott a raise he deserves it

 

[Solarquest]

Oh, so it's ok that the user opened an attachment and sent his password, got his keys logged, sent his screen captures to third parties without his consent because he was stupid and had an AV installed he bought just to prevent these sorts of things. Got it.

Well, to all AV vendors: please add to your EULA that you do not protect "idiot users" that click and open email attachments. You protect just the smart ones that do not open email attachments. Thanks.

I agree.
I think that:
- AV and AM , as the name says, should protect users from malwares, all users.
- no AV-AM protect or can protect 100%
-If an AV-AM doesn't block a MW, it failed unless it warned the user that decided to allow the infection vector.
-User are most of the time the weak link but not always.
For example, user can open a legit and famous page and get infected, e.g because the page got hijacked/ injected with exploit or you can get an email from a friend with an attachment that is infected, e.g because he got infected and the malware used his contacts to spread.

 

[jamescv7]

It is totally different between the program being exploited and not.

The behavior of Emsisoft is still working and fully functional but the protection capabilities are already bypassed since the technique is came from Powershell which already been notified as legitimate program by Microsoft.

So Emsisoft like others should formulate proper mechanistic behavior when it comes on execution of scripts through the usage of Windows' tool.

 

[Deleted member 178]

So Emsisoft like others should formulate proper mechanistic behavior when it comes on execution of scripts through the usage of Windows' tool.

Emsi will do. Confirmed.

 

[Fabian Wosar]

The funny thing is, that the problem isn't even PowerShell but just the unusual way PowerShell is being invoked. We have been blocking PowerShell for a very long time, including detecting and attributing malicious behaviour to the scripts it runs, not PowerShell itself. In any case, using WMI to invoke processes via Office will be considered exploitative behaviour in the next version and blocked automatically.

 

[Emmanuellws]

to understand more about powershell....taken from ADSECURITY website, they have video of this too

PowerShell is more than PowerShell.exe
Blocking access to PowerShell.exe is an “easy” way to stop PowerShell capability, at least that’s how it seems. The reality is that PowerShell is more than a single executable. PowerShell is a core component of Windows (not removable) exists in the System.Management.Automation.dll dynamic linked library file (DLL) and can host different runspaces which are effectively PowerShell instances (think PowerShell.exe & PowerShell_ISE.exe). A custom PowerShell runspace can be instantiated via code, so PowerShell can be executed through a custom coded executable (such as MyPowershell.exe). In fact there are several current methods of running PowerShell code without Powershell.exe being executed. Justin Warner (@SixDub) blogged about bypassing PowerShell.exe on Red Team engagements in late 2014, aka PowerPick). Since PowerShell code can be executed without running PowerShell.exe, blocking this executable is not an ideal solution to block attacks (and by “not an ideal solution” I mean this doesn’t stop PowerShell from being executed, so no it doesn’t solve the problem).

There are two sides to every argument. On the “Block PowerShell” side, there is the positive result that initial attack code will not execute since PowerShell is not allowed to run, with potential issues later on due to Microsoft and/or 3rd party requirements for PowerShell. Often an organization will “block” access to PowerShell.exe to stop the initial attack. There are side-effects to this, including potentially reduced management capability.
On the “Don’t Block PowerShell” side, there are other ways to limit an attacker’s PowerShell capability without blocking PowerShell from running. Configuring PowerShell protection/limitation via AppLocker is worth investigating (and testing) as well as setting Powershell to constrained language mode. For more on this, review the later section on “Limiting PowerShell Capability.”

• PowerShell = System.Management.Automation.dll
• Applications can run PowerShell code
• “PowerShell ps = PowerShell.Create()”
• Ben Ten’s AwesomerShell
  GitHub - Ben0xA/AwesomerShell: The AwesomerShell Code Sample

Executing PowerShell commands without PowerShell.exe
Starting with PowerShell v2:

“Provides methods that are used to create a pipeline of commands and invoke those commands either synchronously or asynchronously within a runspace. This class also provides access to the output streams that contain data that is generated when the commands are invoked. This class is primarily intended for host applications that programmatically use Windows PowerShell to perform tasks. This class is introduced in Windows PowerShell 2.0″.

• Create C# application that references Powershell System.Automation.dll assembly.
• Leverage Automation assembly’s functions to execute PowerShell Code.
• Similar to how PowerShell.exe works.

That measn no matter how you block powershell.exe, attackers can still run their own powershell executable code...and run directly from memory. But this problem has been fixed in Windows 10 and server 2016 running Powershell v5....limiting cmdlets of remote powershell. check this out for full article PowerShell Security: PowerShell Attack Tools, Mitigation, & Detection » Active Directory Security

 

[Amelith Nargothrond]

The funny thing is, that the problem isn't even PowerShell but just the unusual way PowerShell is being invoked. We have been blocking PowerShell for a very long time, including detecting and attributing malicious behaviour to the scripts it runs, not PowerShell itself. In any case, using WMI to invoke processes via Office will be considered exploitative behaviour in the next version and blocked automatically.

So basically the interpreter invoking cascading parents (& methods) were the circumventing vectors, right? The engine was misled because the parents were legitimate processes?

 

[Fabian Wosar]

Yes and no. The problem with WMI is, that it interrupts the execution chain.

As mentioned many times before, for a behaviour blocker context matters a lot, which is why it is difficult to test them properly. In this particular case, we look at how a PowerShell instance comes to be. You can run PowerShell manually just fine because it is okay for explorer.exe to start PowerShell. However, if some very vulnerable processes attempt to start it, like Office or your browser or your PDF reader, then we assume that is not normal and prevent it. If you ever tried EAM against various macro malware, you have probably seen it suddenly killing Excel or Word. Kind of like this:

That is pretty much happening because we saw the macro malware instructing Office to run applications that are risky.

The malware in this particular video, technically also does that. It instructs Office to run PowerShell with a passed in command line. But unlike most macro malware, who just tell Office to run the file directly, it tells Office to run it through WMI. The problem with that is, that Office will not be the parent of the PowerShell process. Instead, the parent will be a WMI host process. There is also no documented way for us to trace back which process or user triggered the execution through WMI, to restore the chain of execution.

With the update, we restrict access by vulnerable processes to WMI interfaces and methods that we deem problematic because they will interfere with the contextual analysis done by the behaviour blocker. So any attempt to abuse WMI will result in immediate termination of the protected processes.

 

[Amelith Nargothrond]

Yes and no. The problem with WMI is, that it interrupts the execution chain.

As mentioned many times before, for a behaviour blocker context matters a lot, which is why it is difficult to test them properly. In this particular case, we look at how a PowerShell instance comes to be. You can run PowerShell manually just fine because it is okay for explorer.exe to start PowerShell. However, if some very vulnerable processes attempt to start it, like Office or your browser or your PDF reader, then we assume that is not normal and prevent it. If you ever tried EAM against various macro malware, you have probably seen it suddenly killing Excel or Word. Kind of like this:

View attachment 147030
That is pretty much happening because we saw the macro malware instructing Office to run applications that are risky.

The malware in this particular video, technically also does that. It instructs Office to run PowerShell with a passed in command line. But unlike most macro malware, who just tell Office to run the file directly, it tells Office to run it through WMI. The problem with that is, that Office will not be the parent of the PowerShell process. Instead, the parent will be a WMI host process. There is also no documented way for us to trace back which process or user triggered the execution through WMI, to restore the chain of execution.

With the update, we restrict access by vulnerable processes to WMI interfaces and methods that we deem problematic because they will interfere with the contextual analysis done by the behaviour blocker. So any attempt to abuse WMI will result in immediate termination of the protected processes.

This will be a very nice update WMI access is particularly protected (blocked) by many security products, some even have separate modules just for this, exactly because of the dangers it may bring upon the user, by malware.

Great job!