Controlling PowerShell with zero trust microsegmentation

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:

1. Block PowerShell from executing where it is
   not needed;
2. Allow PowerShell to perform local
   administrative tasks but block it from accessing the network;
3. Allow PowerShell to connect to specific remote
   hosts when run from administrative systems but block it from accessing the
   internet; and
4. 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.

Comments are closed.