How can you validate the efficacy claims of endpoint security vendors? Here’s a free tool to help you out.

Given the large number of vendors in the endpoint security space, it’s not surprising that they are fighting tooth and nail to win deals. In many cases this involves genuine innovation and the understanding of customer needs. Unfortunately, too often the competitors invest sales and marketing funds in convincing potential clients they will be 100% protected after installing a given product. We frequently encounter such unrealistic promises when speaking with prospects and find ourselves explaining that anyone making such claims either lacks suitable knowledge or isn’t telling the truth. To help fight such snake oil sales tactics, we released a free tool that professionals can use to validate at least some aspects of efficacy claims themselves.

A Day in the Life of Selling a Security Product

When discussing endpoint security architecture with prospects, we sometimes encounter claims that the prospective customer’s endpoint is highly secure because their AV vendor supplied a third-party testing report stating that the product prevented 100% of the threats. In such conversations, it’s not enough for us to simply state that 100% efficacy claims are unrealistic. We need to prove it.

For example, a couple of months ago a prospective customer told us their organization  was about to switch to a pricy high-maintenance next-gen antivirus product (which is just another AV), citing vendor claims that the tool blocks 100% of endpoint attacks.

Any approach to detection-based malware protection is inherently limited, though antivirus products differ in their strengths and weaknesses. The particular product this customer was considering was powerful at identifying malicious executables but was weak against other contemporary threats such as “fileless” attacks involving PowerShell. When we shared this perspective with the prospect, he didn’t hesitate for a second, citing the vendor’s statements that they also block 100% of fileless attacks.

Bypassing “100%” Protection by Reading Documentation

Minerva’s malware research team is very familiar with the aforementioned product. It was clear to us that if the first 100% detection claim was inaccurate, the latter claim about blocking 100% of fileless attacks was truly misleading.

The clever, “next-gen” solution simply blocked the creation of the powershell.exe processes, which is in charge of executing PowerShell scripts on Windows by default. To demonstrate to the prospect that the claims upon which he was basing his endpoint security architecture were incorrect, we showed that the product failed to block an alternative host for PowerShell – PowerShell ISE. This built-in utility for debugging PowerShell scripts, while incapable of directly running scripts, can load and execute them in an indirect way documented by Microsoft. If the attacker places a malicious script under the path %USERPROFILE%\profile.ps1 and start PowerShell ISE, the script will be executed without powershell.exe being involved.

PowerShell ISE Console, running a basic “hello world” script

This trick succeeded at bypassing the “100% blocking PowerShell” restriction of the overconfident security product. However adversaries  still need to consider a scenario where the PowerShell execution policy restricts the deployment of malicious PowerShell payload. Unfortunately, like many other Windows features, the execution policy can be set in the registry, for example – from an Office macro script. Moreover, if an attacker without administrator privileges wishes to change it only for the current user, they can simply open the following key:

HKEY_CURRENT_USER\Software\MicrosoftPowerShell\1\ShellIds\Microsoft.PowerShell

And set the registry value ExecutionPolicy to Unrestricted.

Using this second trick which was publicly released in September 2014, we now proved how adversaries can guarantee the execution of any PowerShell script on the so-called 100% protected endpoint. For a more effective bypass, an attacker can wrap this logic in a malicious macro-enabled document, which often gets past antivirus-like solutions and provides a consistent way of demonstrating the gap in the “100%” claims above.

This story ended there. The prospect became a client, deploying Minerva’s solution to cover the gap between his current AV and real-world evasion tactics. This wasn’t the first time Minerva needed to confront exaggerated claims about prevention capabilities of security products and it’s not the last. Following this case, we had many conversations where prospects asked us for a similar “proof” about products’ weak spots. We found ourselves slightly tweaking the original proof-of-concept document just like real attackers do–changing the time at which it launches the payload, “downgrading” it to use plain old powershell.exe and changing the way it overrode the execution policy. Eventually, we decided to automate key elements of the task with this free tool.

Invoke-NoShell

As the result of the experiences described earlier, we created a free tool called Invoke-NoShell, which is designed to help organizations assess the potential weaknesses in their endpoint security products’ protection against malicious PowerShell scripts. Invoke-NoShell automates the “marriage” of a proof-of-concept malicious payload and a document, automatically generating 12 different evasive document permutations which vary in the following ways:

  • The script host – either PowerShell or PowerShell ISE
  • Optionally adding execution policy bypass tricks
  • When the payload is launched – on open, close or click

Creating all of the permutations at once allows the tester to quickly check how and whether their endpoint security product can be bypassed using these methods.

To verify that the tool is actually useful, we decided to perform the following test in our lab:

  • Set up an endpoint with the latest versions of half-dozen vendors
  • Generate 12 permutations of a Microsoft Office document that carried malware based upon publicly available frameworks such as PowerSploit
  • Try and execute it

We tested “traditional” and “next-gen” endpoint security products and Invoke-NoShell’s output overcame all of them. In 60% of the cases, the tool succeeded at generating at least one file that the product failed at preventing. The remaining 40% did not prevent any of the 12 versions created by Invoke-NoShell, so we didn’t even need it to demonstrate the tools’ gaps.

Invoke-NoShell is publicly available for experimentation, in case you’d like to use it to understand the potential weaknesses in your endpoint security architecture and tools:

https://github.com/G4lB1t/Invoke-NoShell

Invoke-NoShell is just one example of how you can validate the unrealistic vendor claims of 100% prevention. If you are interested in further details about methodologies for testing endpoint security products, this on-demand webinar, which our VP Research Omri Moyal conducted on this topic.

 

{{cta(‘9521ded0-c53b-4ebf-b511-e722908156d7’)}}

 

Our interest in understanding evasion tactics is driven by the focus of Minerva’s Anti-Evasion Platform, which augments any antivirus technology to stop threats designed to get around other security measures. By that, we significantly strengthen endpoint security architecture without competing with AV products or overlapping with other security measures.

 

{{cta(‘5dccbbce-7090-4ba3-be0b-1c775d019368’)}}