Tips for Securing PowerShell

In 2020, system administrators will be using PowerShell. There is no tool more powerful in Windows than the little blue shell with its forgiving syntax, unprecedented access to the operating system, and the flexibility to do anything an admin could want in a few simple, scriptable lines.

Yet this powerful tool is the bane of cybersecurity engineers worldwide. Even before system administrators had embraced PowerShell, hackers were using it to manipulate and exploit Windows operating systems for ransomware, crypto mining, exfiltration, credential stuffing, or even to destroy entire systems. Worse still, their efforts have been packaged into open source, free-to-download, and easy-to-use tools like PowerSploit, Mimikatz, and PowerShell Empire. You don’t have to be an advanced threat to be persistent or effective anymore.

What can security teams do to protect themselves? Historically there have been two (bad) options:

1. Whitelist PowerShell: The system administrator’s preferred solution is to whitelist PowerShell throughout the organization. Currently, their scripts can run without being blocked by antivirus or being alerted by EDR tools. Work gets done more effectively within IT operations. Unfortunately, it also undermines every security control in place on the endpoint. Attackers can now move invisibly throughout the environment, running their network scans, malware, and ransomware with impunity. Still, this is the choice of many organizations that must use PowerShell. It is a major vulnerability, but one they are willing to risk.
2. Blacklist PowerShell: The preferred method of cybersecurity engineers everywhere, blacklisting PowerShell removes any and all attacks related to PowerShell – which is a lot. Most malware will try to use PowerShell in some way, so removing it completely closes some major potential holes in an organization’s security posture. However, removing PowerShell is like cutting the legs out from IT operations. At a minimum, the ability to automate all but disappears from Windows environments. At worst, system administrators will find a way around the blacklist to use PowerShell behind security’s back and ultimately undermine blacklisting in the first place.

Neither solution is good – and yet they are the choices made by organizations every day. The industry needs a third option, one that gives system administrators full use of PowerShell while blocking attackers from doing the same. But how?

With CRITICALSTART the solution is simple. Our Zero-Trust approach allows our SOC to find and stop any and all attacks using PowerShell while also allowing system administrators to write scripts and use PowerShell to its full ability. Even better, this approach can be onboarded in under six weeks for most organizations!

How does it work?

1. During onboarding, CRITICALSTART will work with your organization to determine what administrators and users in your company are approved to use PowerShell, what scripts/commands they are allowed to run, and even when they are allowed to run them.
2. Expert security analysts will build playbooks to auto-resolve security alerts related to the known good activity of your system administrators.
3. When a security event comes in, CRITICALSTART’s Zero-Trust Engine investigates the event looking for matches to the known good criteria.
4. When a match occurs, the Zero-Trust Engine will auto-resolve the event as false-positive eliminating any impact to the system administrators.
5. If no match occurs, the event is escalated to the CRITICALSTART CYBERSOC and investigated, triaged, and responded to by our analysts.

CRITICALSTART is the only Managed Detection and Response (MDR) service with true Zero-Trust capabilities, allowing organizations to gain full access to PowerShell while stopping all breaches. It is truly the best of whitelisting without the added risk and the best of blacklisting without degrading system administrators.

By Alex Humphrey | Manager MDR Sales Engineer
December 10, 2019