Technique T1059.001

PowerShell

PowerShell was the most common technique we observed in 2020, affecting nearly half of our customers. It remains among the most versatile of built-in utilities for adversaries, defenders, and system administrators alike.

#1

Parent technique rank

48.7%

Organizations affected

2366

Confirmed threats

Analysis

Why do adversaries use PowerShell?

PowerShell is a versatile and flexible automation and configuration management framework built on top of the .NET Common Language Runtime (CLR), which expands its capabilities beyond other common command-line and scripting languages. PowerShell is included by default in modern versions of Windows.

Adversaries use PowerShell to obfuscate commands in hopes of achieving any of the following:

  • evading detection
  • spawning additional processes
  • downloading and executing remote code and binaries
  • gathering information
  • changing system configuration

Adversaries rely on PowerShell’s versatility and ubiquitous presence on target systems, minimizing the need to additionally customize payloads.

How do adversaries use PowerShell?

While PowerShell offers adversaries a plethora of options, the most common uses include:

  • executing commands
  • leveraging encoded commands
  • obfuscation (with and without encoding)
  • downloading additional payloads
  • launching additional processes

PowerShell is frequently observed in phishing campaigns, where emails with weaponized attachments containing embedded code launch a payload. In many cases, such as with Emotet, this payload executes encoded and obfuscated PowerShell commands that download and execute additional code or a malicious binary from a remote resource.

We encounter encoding or obfuscation more than any other variety of malicious or suspicious PowerShell. PowerShell’s flexibility—along with its support for aliases, abbreviated cmdlets, argument names, and calling .NET methods—offers attackers many ways to invoke Base64 and other encoding. Below is a case-agnostic review of the methods we commonly observe in rank order, with approximate percentages representing their frequency of occurrence in our detections:

  • 27%: -e
  • 25%: -ec
  • 21%: -encodedcommand
  • 15%: [System.Convert]::FromBase64String()
  • 6%: -encoded
  • 4%: -enc
  • 1%: -en
  • .4%: -encod
  • .01%: -enco
  • < .01%: -encodedco, -encodedc, -en^c

Given PowerShell’s support for shortened command-line arguments, escape characters in the command line, and more, do not consider the above list comprehensive.

Emerging PowerShell tradecraft 

While leveraging PowerShell, adversaries have been known to use format string obfuscation (i.e., the dynamic building of strings by using non-standard sequences of format string operators like {0} and {1}) instead of Base64 encoding. We’ve also encountered different mechanisms to obfuscate commands and payloads; these not only leverage common characters for obfuscation (such as ^ or +), but also variables that are broken up initially to help evade detection and then concatenated back together for execution.

Definition

Detection

Collection requirements

Process and command-line monitoring

Command-line parameters are by far the most efficacious for detecting potentially malicious PowerShell behavior, at least as far as standard process telemetry is concerned. Logs such as Anti-Malware Scan Interface (AMSI), script-block, or Sysmon can be particularly helpful for detecting PowerShell.

Detection opportunities

Encoding command switch

Encoding and obfuscation tend to go together. Watch for the execution of powershell.exe with command lines that include variations of the -encodedcommand argument; PowerShell will recognize and accept anything from -e onward, and it will show up outside of the encoded bits. The following are example variations on the shortened, encoded command switch:

  • -e
  • -ec
  • -encodedcommand
  • -encoded
  • -enc
  • -en
  • -encod
  • -enco

This is a starting point, so be prepared for some initial noise as you implement and tune this detection logic.

Base64 encoding

Base64 encoding isn’t inherently suspicious, but it’s worth looking out for in a lot of environments. As such, looking for the execution of a process that seems to be powershell.exe along with a corresponding command line containing the term base64 is a good way to detect a wide variety of malicious activity. Beyond alerting on PowerShell that leverages Base64 encoding, consider leveraging a tool—like CyberChef, for example—that is capable of decoding encoded commands.

Obfuscation

Once decoded (from Base64), you may encounter compressed code, more Base64 blobs, and decimal, ordinal, and obfuscated commands. Obfuscation (whether inside or outside the encoding) breaks up detection methodologies by splitting commands or parameters, inserting extra characters (that are ignored by PowerShell), and other janky behavior. You can use regular expressions (such as regex) to increase fidelity and help flag more interesting activity from within the decoded sections. Monitoring for the execution of PowerShell with unusually high counts of characters like ^, +, $, and % may help you detect suspicious and malicious behavior.

Suspicious cmdlets

Once the command line is decoded to human-readable text, you can also watch for various cmdlets, methods, and switches that may indicate malicious activity. These may include strings such as Invoke-Expression (or variants like iex and .invoke), the DownloadString or DownloadFile methods, or unusual switches like -nop or -noni.

Weeding out false positives

Monitoring for encoded commands may seem like an easy win, and it is certainly a place to start. However, you will quickly find that many platforms and administrators leverage PowerShell and use encoded commands as a part of normal workflows. As such, flagging activity simply based on variations of the -encodedcommand switch may generate a significant amount of noise. Start with queries against offline or static data to get a feel for volume.

Once you have a better understanding of your overall volume, identify patterns within the decoded data. Leverage your knowledge of what is normal for your environment in order to identify what is potentially malicious. Automation is critical to not just detecting encoded commands, but the contents of those commands once decoded. Prior to applying detection logic, feed encoded command lines into a workflow that decodes them; that way, you are increasing fidelity from the start.

Testing

Getting Started With Atomic Red Team

Start testing your defenses against PowerShell using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.

Getting started

View atomic tests for T1059.001: PowerShell. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using PowerShell or Command Prompt:
powershell.exe -e JgAgACgAZwBjAG0AIAAoACcAaQBlAHsAMAB9ACcAIAAtAGYAIAAnAHgAJwApACkAIAAoACIAVwByACIAKwAiAGkAdAAiACsAIgBlAC0ASAAiACsAIgBvAHMAdAAgACcASAAiACsAIgBlAGwAIgArACIAbABvACwAIABmAHIAIgArACIAbwBtACAAUAAiACsAIgBvAHcAIgArACIAZQByAFMAIgArACIAaAAiACsAIgBlAGwAbAAhACcAIgApAA==

What to expect

Running this test should print “Hello, from PowerShell!” to the terminal. Decoded, the command runs the following obfuscated PowerShell code:

& (gcm ('ie{0}' -f 'x')) ("Wr"+"it"+"e-H"+"ost 'H"+"el"+"lo, fr"+"om P"+"ow"+"erS"+"h"+"ell!'")

Deobfuscated, it is equivalent to the following:

Invoke-Expression “Write-Host ‘Hello, from PowerShell!'”

Useful telemetry will include:
Data sourceTelemetry
Data source:

Process monitoring

Telemetry:

A powershell.exe process will start.

Data source:

Process command-line parameters

Telemetry:

Command-line logging will capture the encoded PowerShell content.

Data source:

PowerShell logs / Windows event logs

Telemetry:

PowerShell ScriptBlock Logging will capture the decoded PowerShell contents via Microsoft-Windows-PowerShell/Operational Event ID 4104

Review and repeat

Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:

  • Were any of your actions detected?
  • Were any of your actions blocked or prevented?
  • Were your actions visible in logs or other defensive telemetry?

Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.

Frank McClain
CIRT Training Lead
Frank is responsible for building and maintaining the Red Canary CIRT training program. He leads all aspects including onboarding new employees and fostering the development of new or expanding skillsets. Frank is an accomplished cyber security investigator and information assurance practitioner with deep experience in digital forensics and incident response (DFIR). He paid his dues in DFIR consulting before going on to manage security operations for a national financial services firm, where he built and led the team responsible for continuous monitoring, threat analysis, and incident response.
Frank is responsible for building and maintaining the Red Canary CIRT training program. He leads all aspects including onboarding new employees and fostering the development of new or expanding skillsets. Frank is an accomplished cyber security investigator and information assurance practitioner with deep experience in digital forensics and incident response (DFIR). He paid his dues in DFIR consulting before going on to manage security operations for a national financial services firm, where he built and led the team responsible for continuous monitoring, threat analysis, and incident response.