Carbon Black & VMware Announce Expanded Partnership to Secure the Software-Defined Data Center (SDDC) Learn more

Controlling PowerShell Behavior Using a Positive Security Model

February 10, 2016 / Richard Perkins

PowerShell is a powerful tool for both systems administrators and attackers alike and its use as an attack tool has become more and more prevalent. Unfortunately, we can’t just “turn PowerShell off” in most cases because our systems administrators and domain administrators use it.

We have written numerous blog posts about preventing and detecting the malicious use of PowerShell using Carbon Black Enterprise Response and Carbon Black Enterprise Protection.

In the post linked to above, I illustrated how to control PowerShell by preventing it from being a child process of things such as Adobe, Word, Excel, WScript, etc.

With more than 1 million new malware samples being released every day, it is impossible to look for every known (or unknown) bad sample. We have to change our way of thinking. We have to rely on what is known good and trusted and assume everything else is bad. (This is how detecting credit card fraud works.)

Keeping that positive security model in mind, I would go back and rewrite that previous blog post to look a little more like this:

Knowing that powershell.exe is used in a number of attacks as well as a significant part of the Powershell Empire, we need to be able to control how PowerShell, a trusted process, behaves on our endpoints. We should analyze the behavior of powershell.exe or other risky processes in our environments and determine what good looks like for us. In other words, we should establish a baseline of “known good.”

Launching powershell.exe from the Windows “Start” button and then using Carbon Black Enterprise Response to analyze the process tree provides us with the following information:


Powershell.exe is a child process of explorer.exe. This is the known good behavior in my environment. Your environment may be different. In your environment, powershell.exe may be called by login scripts or by in-house developed applications.

Doing a little more research yields the same results for cmd.exe, another useful tool for both the systems administrator and the attacker.

Now that we know what good looks like in the lab environment for powershell.exe and cmd.exe, we can implement some security around that baseline using a positive security model.

In Carbon Black Enterprise Protection, we can create a custom execution control rule for both powershell.exe and cmd.exe.


This rule prevents powershell.exe from being a child process of anything except explorer.exe, which is known good behavior. Now, instead of trying to block based on known bad (Adobe, Word, etc.), we enabled a protection/detection that will work even if the attackers change tactics and tomorrow discover a way to use chrome or Firefox to launch PowerShell directly.

We can use this same approach to control other potential risky yet trusted applications in our environment; WScript, CScript, WMIC, and “Net.exe,” for example.

Determine what “normal” looks like in your environment and then report on or prevent anything outside the known good behavior. Stop trying to know what the bad is. Credit card companies have figured out that to detect fraud, you need to try to look for known good and alert on the anomalies. There’s clear evidence that this approach works in a world where it is hard to predict what the next “bad” will look like.

TAGS: Carbon Black / Positive security model / PowerShell / security

Related Posts