In the U.S., scripting attacks are a fast growing vector for cybercriminals that’s already nearly as common as malware, according to the most recent Crowdstrike Global Threat Report. And it’s not just cybercriminals who are using them. Nation states such as China and Iran are also employing scripting attacks, most recently with Iran’s MechaFlounder Python backdoor attack against Turkey last year.

Why are scripting attacks growing in popularity? First, these attacks use assets that are already pervasive in enterprise environments. For example, on most *NIX systems, Python is installed by default, and PowerShell is a very common — and very powerful — administrative tool. Plus, malicious scripts are not at all hard to create. Less than 100 lines of Python code can achieve persistence in the environment, set up a back door and establish command and control, essentially giving a hacker the same access as an administrator. In fact, there are more than 200 Python backdoor scripts available for download on GitHub right now.

Let's take a closer look at one scripting attack vector: PowerShell, which is a ubiquitous admin tool used to manage IT environments. PowerShell comes with a fully developed scripting language and connects to remote systems, so it can be used to make unauthorized Internet connections and establish backchannels for command and control. This makes it a very attractive target.

PowerShell has already played a key role in many successful attacks:

• Operation PowerShell Olympics was developed specifically to disrupt the 2018 Winter Olympics in South Korea, and it’s still circulating today. If an infected Word document is opened and the user follows the instructions in the email to enable content, a hidden PowerShell script installs malware that creates an encrypted tunnel that gives hackers remote access.
• PowerShell is a favorite vector for delivering the Emotet trojan, which has worm-like capabilities that enable it to move laterally across the network to steal information.
• Deep Panda, a suspected Chinese group, has used PowerShell scripts that look like regularly scheduled tasks to deliver and execute malware to a wide range of government, healthcare and business targets.

PowerShell is difficult to secure. While measures such as code signing and white listing can limit the scripts PowerShell will execute, they’re very cumbersome to control and manage. Inevitably, a vulnerability will be overlooked that can be exploited. Additionally, endpoint protection and detection platforms struggle to identify malicious scripts because they look just like ordinary administrative traffic.

Any solution for securing PowerShell and other scripting attacks must prevent the tools from being used to spread malware throughout the environment and move across it to access critical data and assets. But it must do so without making it difficult for admins to conduct ordinary day-to-day IT operations. PowerShell, Python and other vectors targeted by scripting attacks are critical tools, and security measures cripple admins’ ability to use them, some will find ways to get around or disable security measures.

Identify-based Zero Trust and How it Prevents Scripting Attacks

The best way to prevent scripting attacks, such as those that implement Python back doors or compromise PowerShell, is to implement identity-based zero trust. In a zero trust environment, IT treats the internal network as if it were the public internet, a place where nothing can be trusted, and anything can be a threat. In this model, instead of working to identify threats  — of which there is a limitless supply — IT identifies safe applications, workloads, hosts, devices and processes so that only approved communications are permitted. Everything else is blocked by default.

It’s important to take an identity-based approach. Legacy approaches build zero trust policies on network addresses and cannot adequately secure an environment. That’s because network addresses are short-lived in modern networks, and in environments such as the cloud or containers, they can change multiple times per second. Not only does this require that policies must be constantly updated — which requires a ton of manual intervention and has a high risk of introducing vulnerabilities with errors —  but it also means that malware and scripts can piggyback over addresses that are considered “safe.”

In an identify-based approach, each application, device or workload has a unique fingerprint based on dozens of immutable properties of the device, software or script, such as a SHA-256 hash of the binary, the UUID of the bios or a cryptographic hash of a script. By using these identities, IT can create policies that explicitly state which devices, software and scripts are allowed to communicate with one another — all other traffic is blocked by default. As a result, malicious scripts would be automatically blocked from establishing backdoors, misusing PowerShell or communicating with sensitive assets, but without hindering admins from using these tools to do their jobs.

As a result, CIOs and CSOs will sleep a lot better, knowing that the threat posed by malicious scripts has been neutralized.