Blog

PowerShell has recently become one of Cybercriminals’ favorite assets to exploit, and security experts are predicting an increase in such exploits.

In this article we’ll try to understand PowerShell exploits, and why attackers like using them. Finally we’ll consider our options for defending against them.

Understanding PowerShell Exploits

PowerShell exploits are an example of fileless malware, which we’ve written about more generally elsewhere. In general, fileless malware doesn’t include any of its own malicious files, executable or otherwise, to be saved on infected endpoints. Instead, it exists primarily as code running in computer memory (RAM). The malicious code is injected into and run by various combinations of legitimate processes – such as Windows PowerShell. For this reason, fileless malware is also known as malware that ‘lives off the land’ – since it utilizes existing operating system processes without needing to create its own executables.

Before we go any further, let’s understand what PowerShell itself is.

PowerShell is a command-line shell and associated scripting language, which is part of Windows. Think of it as a command-line interface like the conventional cmd.exe (and its associated batch scripting), on steroids. PowerShell is to a large extent replacing cmd and batching, since it enables significantly more functionality, and also enables more types of applications to use it.

This means that PowerShell has complete control of the Windows operating system. Basically, it can do anything that the user under which it is running can do – whether on the local endpoint, or remotely to other computers to which the user has access.

So what makes PowerShell so attractive to cybercriminals? It’s the combination of several factors:

• It’s always there. Since Windows 7, PowerShell is included by default. It’s even included in a service pack to Windows XP. So, unless PowerShell has been intentionally disabled – no trivial task, and one that is likely to block legitimate systems and activities – the hackers can rely on its presence, without needing to download it. This is the ‘living off the land’ phenomenon we mentioned above.
• No native security: With such extensive and powerful functionality, one might expect PowerShell to have significant built-in security features. One would be wrong. PowerShell does have a feature called Execution Policies, but users – including any malware that may have gained a foothold – can change or bypass these policies at will. To quote Microsoft:
  “The execution policy is not a security system that restricts user actions. For example, users can easily circumvent a policy by typing the script contents at the command line when they cannot run a script. Instead, the execution policy helps users to set basic rules and prevents them from violating them unintentionally”.
  For fun, try Googling “How to bypass PowerShell execution policy”.
• PowerShell can execute commands directly from memory, without needing any files or data saved to disk. Since security software’s most basic and reliable functionality is disk scanning, such PowerShell exploits don’t leave any traces to be found.
• More advanced security solutions don’t just scan disk data, but monitor endpoint running processes. However, since PowerShell is, in general, a legitimate tool used for many legitimate purposes, there’s nothing about it to raise any red flags. Endpoint security monitoring software registers the PowerShell process as legitimate.

For these reasons, PowerShell has been used, and will most likely continue to be used, for all kinds of attacks, including ransomware, data theft, keystroke logging, cryptomining, and targeted attacks.

Defense Considerations

From the above description it should already be clear that traditional, signature-based data scanning antivirus is pretty much useless when it comes to PowerShell exploits and other fileless malware. Unless the malware also includes characteristic files that it needs to save to disk – something current cybercriminals are smart enough to avoid – the antivirus won’t have anything to find. And, as we mentioned, process monitoring won’t fare any better, since PowerShell is a legitimate and often even necessary process.

Perhaps the most comprehensive available analysis of PowerShell exploitation is a report produced by Symantec. A follow-up Symantec blog post, last updated as recently as February 2018, states:

“Running a full system scan with SEP will not identify any malware. PowerShell is a legitimate tool: SEP’s AntiVirus component will not stop it… Even if a SEP full system scan turns up no malware, malicious code might be running in memory via PowerShell”.

The latest trend in the mainstream security establishment for such hard-to-identify malware and targeted attacks is behavior-based analytics. Leading security companies are attempting to apply behavioral and statistical analysis to identify malicious behavior rather than the malicious code itself.

However, while this approach has had some successes, it is not yet clear to what extent in fact attack behavior can be reliably differentiated from legitimate behavior. In addition, this approach is by definition limited in its ability to anticipate new attack types and patterns, which may significantly differ from such known behaviors.

The above-mentioned Symantec report and blog post suggest a variety of defense measures. However, it is clear that they do not consider any of them reliable for prevention, and their primary recommendation is to concentrate on improving PowerShell logging and on monitoring and forensic analysis of the produced logs. This is the report’s final word, and the only recommendations to appear in its concluding chapter:

“With the evidence we have shown of a rising tide of threats leveraging PowerShell, we recommend bolstering defenses by upgrading to the latest version of PowerShell and enabling extended logging features. Additionally, make sure that PowerShell is considered in your attack scenarios and that the corresponding log files are monitored”.

Logging and monitoring are certainly to be desired, but it should be clear that such measures will always be too little, too late. Logging only starts once an attack is taking place, and by the time logs can be analyzed it’s likely too late for someone.

Microsoft, on the other hand, unsurprisingly believes PowerShell to be securable. A long and detailed Microsoft article lists the measures that need to be taken to secure PowerShell in an enterprise. Here’s its summary of all the various aspects that need to be secured:

Honestly, we didn’t investigate the level of security that the combination of all these measures would provide. However, it seems safe to say that this level of complexity is unlikely to provide infallible security, probably requires significant expertise and labor to maintain, and is likely prone to human configuration error.

However, the situation is not hopeless.

The Solution: Prevention by Containment

Gradually, the security establishment is coming to recognize that the only reliable solution for endpoint security from unidentified, evolving, and fileless attacks is proactive containment and isolation. Any and all potential threats must be isolated from valuable organizational resources and kept where they can’t do any damage.

BUFFERZONE provides exactly such a solution. BUFFERZONE doesn’t attempt to detect and identify threats. Instead, it creates a virtual container on endpoints, where all downloads and email attachments from untrusted sources such as the internet are kept. BUFFERZONE keeps browsing sessions and other applications that access external, untrusted content such as unknown internet sites in a virtual container, along with processes started by those sessions and anything they save or download, including registry settings. At the same time, trusted organizational resources and confidential data can be accessed only by uncontained processes. So, for example, a browser session to a malicious site would stay in contained memory, and a malicious email attachment would be opened in contained memory. Even if some malicious code manages to run in the container, it can only affect and access contained, virtualized resources (memory, disk space, networking, and registry). The container is periodically wiped clean, including contained processes, data, and any registry settings saved to the container’s virtual copy of the registry. Contained processes can also be kept on separate networks, enforced by organizational proxy, eliminating the possibility of propagation through the organization.

The advantage of this approach is clear: When malware strikes, no matter how new it is, what evasion techniques it implements, and what native resources it utilizes – it cannot cause any damage to native endpoint or organizational resources. And, the container is periodically emptied, so even there malware can’t last.

Sources

The Increased Use of PowerShell in Attacks, Symantec.com, retrieved 16/7/18
About Execution Policies, Microsoft.com, 6/9/17
What You Can Do About Powershell Threats, Symantec.com, last updated 2/18
PowerShell Security at Enterprise Customers, Microsoft.com, 25/5/17