PowerShell is a highly customizable command-line tool that’s often enabled by default. With it, administrators can easily and quickly automate routine tasks necessary for managing day-to-day processes and operating systems. PowerShell provides easy access to data stores, such as the certificate and registry stores, and it comes with a fully developed scripting language. It connects to remote systems, and can also be used to make unauthorized internet connections and establish backchannels for command and control. As a result, PowerShell is often a tool of choice for “living off the land” cyber-attacks.
In fact, PowerShell has already played a key role in current threats and successful attacks:
- The Emotet trojan, for example, was designed to target financial institutions, but it can also affect consumer devices to steal sensitive information. With worm-like capabilities that enables it to move laterally across the network, it can determine when it’s operating in a sandbox environment and go quiet to avoid detection. PowerShell is a convenient vector for delivering this malware.
- Operation PowerShell Olympics was developed to disrupt the opening ceremony of the 2018 Winter Olympics in South Korea. It used a compromised Word document to execute a hidden PowerShell script. This attack installs malware that creates an encrypted tunnel to give hackers remote access to servers in the data center.
- Deep Panda, a suspected Chinese group also known as Shell_Crew, used PowerShell scripts that looked like regularly scheduled tasks to download and execute malicious software at government, defense, financial, telecommunications and healthcare organizations.
Challenges to controlling PowerShell
Unfortunately, PowerShell is difficult to control, i.e., allow legitimate use but prevent malicious exploitation. Code signing allows PowerShell to execute only signed scripts, and, while whitelisting operations can help, it can be tricky to manage in practice, because managers typically create either overly permissive access that can be exploited or overly restrictive policies that lead to complaints from IT admins. Endpoint protection and detection platforms have difficulty detecting “fileless malware,” and PowerShell’s flexible syntax can evade anti-virus protection. Limiting the ability to execute PowerShell scripts to administrators seems like a strong measure, but attackers are still usually able to bypass these restrictions.
Any solution for controlling PowerShell use has to meet the following requirement: It must prevent PowerShell from being used for lateral threat movement or command and control without hindering admins to conduct normal and approved IT operations. After all, PowerShell is a valuable tool. Security measures that cripple its functionality will hurt productivity, or worse, encourage administrators to find ways to avoid implementing security measures.
So, here’s what we need to accomplish if we are to effectively secure and control PowerShell:
- Block PowerShell from executing where it is not needed;
- Allow PowerShell to perform local administrative tasks but block it from accessing the network;
- Allow PowerShell to connect to specific remote hosts when run from administrative systems but block it from accessing the internet; and
- Allow select Powershell scripts to only access required network resources.
In this way, PowerShell will be secure, but not locked down so severely that it disrupts an administrator’s ability to use it. The way to accomplish this is through microsegmentation to enable a zero trust environment.
Zero Trust and Microsegmentation with PowerShell
Zero trust treats the internal network as if it were the public internet — an environment where nothing can be trusted, and anything can pose a threat. It requires that organizations verify the identity of all application software and devices before they are allowed to communicate.
The primary means of achieving zero trust is through microsegmentation, which establishes secure micro-perimeters directly around sensitive digital assets. By creating “secure zones” tied to the identity of communicating software, zero trust microsegmentation adds a layer of protection on the internal network which prevents unauthorized access. Only specific communications between verified, permitted applications, hosts and devices are permitted. Everything else is denied by default.
Here’s how zero trust-based microsegmentation can secure PowerShell. First, we need to create a network map to visualize all of the open communication pathways that PowerShell can use. It’s best to automate this process as doing so manually could not only take months, but will also face challenges in taking account of network changes during the mapping process. Once these paths are mapped, reduce the attack surface by eliminating paths that are unused or unnecessary for business operations. Typically, more than 90% of communications pathways can be safely shut down.
Once the map is complete, the organization needs to build policy between PowerShell and the assets it needs to access. Policy is anchored on segments of hosts and collections of application instances. When defining these collections, applications and devices shouldn’t be identified by their network address, which are changeable and can be spoofed. Instead, identity must be based on immutable properties of the digital asset itself, such as the SHA256 hash of the binary, the universally unique identifier (UUID) of the system’s BIOS, and the serial number of the CPU, among others. In this way, even when the underlying network changes, policies can still be enforced, because the control plane is decoupled from the network layer.
Building identity-based segments, and policies can be automated using machine learning. Machine learning can quickly build collections and identify patterns from the data collected during the network map, leaving the user with only the task of enforcing the resulting recommendation set.
Once the process is finished, administrators will still be able to use PowerShell in their daily workflows, but with protections in place that prevent the level of unfettered access and ability to execute remote commands that make it such a popular tool used by cybercriminals. That will help CIOs and CSOs sleep a lot better, knowing that the threat posed by PowerShell has been neutralized and their IT team can continue using it to make their daily work more efficient and effective.
