PowerShell is a scripting language originally designed to automate Windows administrative tasks. In addition to running its native commands, it can call DLL functions, access any .NET framework type or class, and many other things. If a type or class does not exist, it can be created. In a nutshell, PowerShell is extremely powerful and very efficient at helping IT administrators automate and optimize their jobs.

Unfortunately, malicious threat actors have also noticed the power and flexibility of PowerShell, including the ability to perform the actions they want on an endpoint. It also eliminates the need for them to download and run malware once they’ve gained access to a system. This, in turn, allows them to bypass any type of protection that relies on the analysis of executable files.

The scenario outlined above is why an increasing number of organizations are now trying to control the use of PowerShell in order to prevent the execution of malicious PowerShell scripts and commands. Some try to mitigate the risk and ban its utilization entirely by blacklisting it. However, there are still other ways for attackers to bypass application controls. One such method consists of using InstallUtil.exe to invoke a recompiled shell. This is a well-documented method and details can be found on this GitHub page.

Other methods try to offer more flexibility by preventing most executions and only allowing PowerShell scripts to be run from predefined folders, or allowing access to only specified user accounts. These methods still leave gaps in the security because all it would take for attackers to run a script is for them to escalate their privileges sufficiently, or find the folders that have been excluded from preventive measures. The latter could be done easily by finding where all the .ps1 files are stored on an endpoint, then assume that their own .ps1 scripts can be run from that same folder.

Some defensive methods might try to analyze the content of the PowerShell script — since it’s a file (.ps1 extension) that is either in clear text and can be easily decoded, or it can be read and therefore analyzed. But this approach is not reliable. A script or command is not inherently good or bad. It’s the intention behind the execution of the script or command that makes it malicious.

To illustrate this point, let’s take a look at the following PowerShell script:

Wipe_Hard_Drive.ps1

Is it malicious? We can’t tell just by looking at it. If it’s run by a system administrator to reimage a system, then it’s absolutely legitimate. If it’s run by an attacker with the intention of destroying data to cover their tracks, then it is absolutely malicious. But it’s the same script. Just looking at it will not necessarily give you an indication of its intent.

Of course, there are some well-known malicious PowerShell scripts where utilization can be detected. That is the case with Mimikatz, the infamous credential-dumping PowerShell script. But the vast majority of PowerShell scripts won’t necessarily give much away. For instance, if the attacker is using a command line interface (CLI) to directly run the commands — one at a time on a machine that is owned — there will be no script to analyze.

This is why you need context to understand the intent behind a PowerShell script or a series of PowerShell commands. To make that determination, you need to know how the script or commands started, where they started from, what happened before they started and what happened after they ran. Furthermore, you need to know how all the commands relate to each other — in short, you need to look at the entire behavior. This is why a behavioral approach is the most efficient way to detect malicious activities that utilize PowerShell. And this is not only true of PowerShell, it is also the best method for assessing any legitimate tool that might be used to perform malicious actions.

Behavioral Analysis Is Key

CrowdStrike uses behavioral IOAs (Indicators of attack) to determine if the intention of a series of actions is malicious or legitimate, regardless of whether these actions are generated from PowerShell or other means. This approach provides a unique and proactive capability to defend against attacks that use PowerShell. IOAs look for signs that an attack may be underway, instead of being concerned about how the steps of the attack are being executed. In contrast with other protection approaches, such as signature-based methods or whitelisting, IOAs observe the sequences of PowerShell commands — and it doesn’t matter if a series of actions was started from a specific folder, a specific user, or via a CLI or a script. IOAs are concerned with the actions performed, their relation to each other, their sequence and their dependencies, recognizing them as indicators of the true intentions and goals behind a sequence of commands. IOAs are not focused on the specific tools that attackers use, making them a breakthrough defense against the malicious use of PowerShell or the use of any legitimate application for nefarious purposes.

Four hundred years ago, Shakespeare wrote, “There is nothing either good or bad, but thinking makes it so.” The same axiom applies to PowerShell. A good script that’s run with the wrong intentions becomes bad and vice versa, even if it’s the exact same script. Even Mimikatz, the password dumping PowerShell script, could be used legitimately to recover a lost password. This is why the ability to monitor the behavior of scripts, and the context within which they are run, are must-haves for protecting against the malicious utilization of otherwise legitimate tools.

Learn more:

Learn how a fileless PowerShell-based ransomware attack works in this infographic.
Learn more about defending against fileless attacks: “Understanding Fileless Attacks and How to Stop Them.”
Test CrowdStrike next-gen AV for yourself. Start your free trial of Falcon Prevent™ today.