T1059.001: PowerShell

T1059.001 is a sub-technique of T1059 (Command and Scripting Interpreter) and falls under the Execution tactic. PowerShell ships on every modern Windows installation, is trusted by the operating system, and offers capabilities that would take attackers significant effort to replicate through custom tooling: process spawning, network access, registry manipulation, WMI interaction, Active Directory enumeration, credential extraction support, and remote command execution — all through a built-in, signed binary that most security policies never block outright.

That combination of capability and trust is why T1059 ranked second in the Picus Red Report 2026 as the most commonly observed ATT&CK technique across real intrusions. PowerShell abuse appears at virtually every stage of the attack lifecycle — initial payload execution following a spearphishing attachment, post-exploitation discovery, lateral movement, credential harvesting, defense evasion, and ransomware deployment. Its prevalence is not accidental; it reflects a rational attacker choice to use tools that defenders cannot simply remove.

How PowerShell Abuse Works

The most straightforward form of T1059.001 is direct execution: an adversary runs powershell.exe with a command or script, either interactively or through a parent process such as a document macro or a scheduled task. This basic pattern generates predictable artifacts — process creation events, command line arguments, script files on disk — that mature detection stacks catch reliably. Sophisticated adversaries therefore layer several additional techniques on top.

Fileless execution is one of the most impactful. PowerShell can download a script from a remote URL and execute it entirely in memory using a download cradle — a one-liner that fetches content from an attacker-controlled server and pipes it directly to Invoke-Expression (IEX) or Invoke-WebRequest. No script file touches disk, and standard file-based antivirus has nothing to scan. In-memory execution also applies to loading .NET assemblies and reflective DLL injection, where PowerShell serves as the bootstrap for more capable implants without ever writing an executable.

Execution policy bypass is trivially achieved. The -ExecutionPolicy Bypass flag overrides policy restrictions for a single session without requiring administrative rights or any persistent configuration change. Variations include -ExecutionPolicy Unrestricted and loading scripts through Invoke-Expression rather than invoking them as files, sidestepping policy checks entirely.

Obfuscation extends the evasion surface further. Because PowerShell is an interpreted language with substantial syntactic flexibility, attackers can represent any command in dozens of functionally identical forms: Base64-encoded arguments via -EncodedCommand, string concatenation, backtick escaping, character code substitution, and variable-based assembly of command strings. Daniel Bohannon's Invoke-Obfuscation framework systematised these approaches and demonstrated that signature-based detection of PowerShell commands cannot be reliably complete — there are effectively infinite valid representations of any given command.

AMSI bypass is a further layer. The Antimalware Scan Interface hooks into PowerShell's execution pipeline and passes script content to registered security products before execution. Adversaries counter this using .NET reflection to locate the AmsiScanBuffer function in memory and patch it to return a clean result for all subsequent input — effectively disabling the scan interface for the current session without touching any file on disk. String-splitting obfuscation of the bypass code itself is used to prevent the bypass payload from being caught by AMSI before it executes.

Execution without powershell.exe is the most advanced evasion variant. PowerShell's engine is exposed as a .NET assembly — System.Management.Automation.dll — which can be loaded and called from any managed application or through the Windows Common Language Interface. Tools such as PowerSploit's PowerPick use this to run PowerShell commands through an arbitrary host process, producing no powershell.exe entry in process telemetry at all.

Real-World Case Studies

Sandworm and the 2016 Ukraine Power Attack

During the December 2016 attack on Ukraine's power transmission infrastructure — separate from the 2015 distribution grid attack — Russia-linked Sandworm Team used PowerShell scripts to execute a credential harvesting tool entirely in memory as part of their intrusion chain. The in-memory approach avoided dropping credential-dumping binaries to disk, reducing the detection surface on the compromised ICS-adjacent Windows systems. Sandworm also deployed a PowerShell utility called TANKTRAP during the 2022 Ukraine power attack, which used Windows Group Policy to spread and launch a disk wiper across targeted operational technology systems.

BianLian and Black Basta Ransomware: PowerShell as a Defense Disabler

Ransomware affiliates have adopted PowerShell as a primary tool for neutralising endpoint defenses before deploying encryptors. In a November 2024 analysis, BianLian affiliates were observed using a PowerShell script that leveraged .NET reflection to locate and patch the AmsiUtils class in memory, disabling AMSI for the session before running subsequent malicious stages. CISA's November 2024 advisory on Black Basta affiliates documented similar PowerShell-based EDR disabling, where attackers scripted the termination of endpoint security processes and services to clear the path for ransomware execution. In both cases, the PowerShell approach required no kernel-mode exploits and worked against fully patched systems.

CoralRaider: Obfuscated Multi-Stage Delivery

A campaign analysed in April 2024 and attributed to the CoralRaider threat cluster demonstrated PowerShell's role in a multi-stage, heavily obfuscated delivery chain targeting information stealer deployment. An obfuscated HTML Application (HTA) file embedded a PowerShell decryptor that used AES-256 to unpack the next stage entirely in memory. The subsequent PowerShell loader bypassed User Account Control by abusing FoDHelper.exe, added directories to Windows Defender's exclusion list, modified registry persistence keys, and ultimately delivered LummaC2, CryptBot, or Rhadamanthys stealers to the victim system. Every stage after initial HTA execution operated in memory, with PowerShell serving as the connective tissue between each phase.

Detection Strategies

Effective detection of T1059.001 requires logging that most environments do not enable by default. The first priority for any defender is enabling PowerShell Script Block Logging, which captures the full deobfuscated content of every executed script block before it runs — including commands that were encoded, obfuscated, or downloaded from the network.

Splunk — Suspicious PowerShell Execution Patterns

# Detect encoded commands, download cradles, and execution policy bypass
# Adjust index/sourcetype to match your Windows event log ingestion
index=wineventlog (EventCode=4104 OR EventCode=4688)
| eval cmd=coalesce(ScriptBlockText, CommandLine)
| where match(cmd, "(?i)(encodedcommand|-enc\s|-e\s+[A-Za-z0-9+/=]{20})")
   OR match(cmd, "(?i)(invoke-expression|iex\s*\(|iex\s*\$)")
   OR match(cmd, "(?i)(invoke-webrequest|net\.webclient|downloadstring|downloadfile)")
   OR match(cmd, "(?i)(executionpolicy\s+(bypass|unrestricted))")
   OR match(cmd, "(?i)(amsiutils|amsi\.dll|amscanbuffer)")
   OR match(cmd, "(?i)(add-mppreference\s+-exclusion)")
| eval risk=case(
    match(cmd,"(?i)(amsiutils|amscanbuffer|add-mppreference)"), "critical",
    match(cmd,"(?i)(encodedcommand|downloadstring)"), "high",
    true(), "medium"
  )
| stats count by Computer, User, cmd, risk
| sort - risk, - count

Behavioral Indicators

Indicator	What It Means
powershell.exe spawned by winword.exe, excel.exe, or mshta.exe	Classic macro or HTA-based initial execution; legitimate Office use rarely produces this parent-child relationship
-EncodedCommand or -enc flag in command line arguments	Base64-encoded payload delivery; almost never used in legitimate administrative automation at scale
PowerShell process making outbound HTTP/HTTPS connections	Download cradle activity; Net.WebClient or Invoke-WebRequest reaching external infrastructure
Script Block Log (Event ID 4104) containing AmsiUtils or AmsiScanBuffer	AMSI bypass attempt; adversary is actively trying to disable the antimalware scan interface before running additional payloads
Add-MpPreference -ExclusionPath in Script Block Log	Programmatic Windows Defender exclusion; used by ransomware affiliates and infostealers to prevent scanning of malware staging directories
PowerShell version 2.0 invocation (-Version 2)	Downgrade attack to bypass Script Block Logging, which is not available in PowerShell v2

Known Threat Actors Using T1059.001

PowerShell abuse spans the full spectrum of threat actor sophistication. The following represent consistently documented users across nation-state espionage and cybercriminal operations.

• APT29 / Cozy Bear (Russia, SVR) — Deployed encoded PowerShell scripts through CozyCar implants to download and run SeaDuke malware; continued use of PowerShell-based tooling across multiple espionage campaigns against Western governments and defence organizations
• APT28 / Fancy Bear (Russia, GRU) — Uses PowerShell for payload download, system enumeration with Get-ChildItem and WMI queries, and credential harvesting across campaigns targeting NATO and government infrastructure
• Sandworm / APT44 (Russia, GRU Unit 74455) — In-memory credential harvesting during the 2016 Ukraine power attack; TANKTRAP PowerShell utility for wiper deployment via Group Policy in the 2022 Ukraine attack
• Lazarus Group (North Korea, RGB) — PowerShell used extensively for staged payload delivery, environment reconnaissance, and C2 communication in campaigns targeting financial institutions, defence contractors, and cryptocurrency platforms
• FIN7 (cybercriminal) — Long-standing use of PowerShell-based loaders and stagers for point-of-sale malware delivery and ransomware operations across retail, hospitality, and automotive sectors
• Black Basta / BianLian affiliates (ransomware) — PowerShell used specifically to disable AMSI, terminate EDR processes, and add Defender exclusions immediately before ransomware deployment
• Gamaredon / Shuckworm (Russia-linked) — Persistent use of PowerShell-based implants and LNK-delivered scripts against Ukrainian government and military targets through 2025

Defensive Recommendations

1. Enable PowerShell Script Block Logging (Event ID 4104): This is the foundational control for T1059.001 visibility. Enable it via Group Policy across all Windows endpoints. Script Block Logging captures the deobfuscated content of every executed script, making encoded and concatenated commands visible in plain text. It also generates alerts when AMSI bypass strings appear.
2. Enable Module Logging and Transcription alongside Script Block Logging: Module Logging (Event ID 4103) records individual pipeline execution events. Transcription writes a full session record to a log file. Together these three controls provide overlapping visibility and prevent gaps when one logging path is targeted by an attacker.
3. Block PowerShell version 2 where operationally possible: PowerShell v2 predates Script Block Logging and AMSI integration. Attackers invoke it explicitly via powershell.exe -Version 2 to escape modern logging controls. Disable the Windows PowerShell 2.0 optional feature via DISM or Group Policy, and alert on any attempt to invoke -Version 2.
4. Constrained Language Mode for non-administrative users: PowerShell's Constrained Language Mode restricts access to .NET types, COM objects, and Windows API calls — blocking many of the capabilities adversaries rely on for AMSI bypass, reflective loading, and credential access. Enforce it via AppLocker or Windows Defender Application Control policies.
5. Alert on high-risk cmdlet patterns in SIEM: Tune detection rules to fire on Invoke-Expression, Invoke-WebRequest combined with IEX, -EncodedCommand, Add-MpPreference -ExclusionPath, and references to AmsiUtils. Correlate with parent process to reduce false positives — the same cmdlets used by IT automation scripts rarely appear as children of Office applications.
6. Implement Just Enough Administration (JEA): JEA constrains what PowerShell remoting sessions can do by defining role-based endpoints that expose only specific cmdlets to specific users. This limits the blast radius if an attacker gains credentials that would otherwise allow unrestricted remote PowerShell access via Invoke-Command or Enter-PSSession.
7. Treat PowerShell execution by non-IT users as an anomaly: In environments with mature baselines, standard business users should rarely if ever execute PowerShell. Alerting on first-seen PowerShell execution by user account — particularly outside of IT and DevOps roles — provides high-fidelity early warning with a low false positive rate.

MITRE ATT&CK Mapping

Field	Value
Technique ID	T1059.001
Technique Name	Command and Scripting Interpreter: PowerShell
Parent Technique	T1059 Command and Scripting Interpreter
Tactic	Execution (TA0002)
Platforms	Windows
Data Sources	Command: Command Execution; Module: Module Load; Process: Process Creation; Script: Script Execution
Mitigations	M1049 Antivirus/Antimalware, M1042 Disable or Remove Feature or Program, M1038 Execution Prevention, M1045 Code Signing, M1026 Privileged Account Management
Version	1.5 (Last Modified: October 24, 2025)
MITRE Reference	attack.mitre.org/techniques/T1059/001

Frequently Asked Questions

What is T1059.001 PowerShell?

T1059.001 is a MITRE ATT&CK sub-technique under Execution in which adversaries abuse the Windows PowerShell scripting environment to execute commands, download and run payloads, interact with the Windows API, and operate without writing files to disk.

How do adversaries use PowerShell in attacks?

Adversaries use PowerShell to download remote payloads with Invoke-WebRequest or Net.WebClient, execute code entirely in memory to avoid disk artifacts, bypass execution policies with the -ExecutionPolicy Bypass flag, disable security tools like AMSI using .NET reflection, encode commands in Base64 to evade signature detection, and move laterally using Invoke-Command against remote systems.

How can organizations detect malicious PowerShell activity?

Detection relies on enabling PowerShell Script Block Logging (Event ID 4104), which captures the full deobfuscated content of executed scripts, Module Logging (Event ID 4103), and transcription. SIEM rules should alert on encoded commands, suspicious cmdlets such as Invoke-Expression and Invoke-WebRequest, and unusual parent-child process chains where Office applications or scripting hosts spawn powershell.exe.

Sources and References

• MITRE ATT&CK — T1059.001 Command and Scripting Interpreter: PowerShell: attack.mitre.org
• Picus Security — T1059.001 PowerShell in MITRE ATT&CK Explained: picussecurity.com
• CISA — AA24-326A Black Basta Ransomware: cisa.gov
• Mandiant — Sandworm Disrupts Power in Ukraine Using Novel Attack Against Operational Technology: mandiant.com
• Security Scientist — PowerShell T1059.001 Attacker Techniques, AMSI Bypass and Detection: securityscientist.net
• Red Canary — Atomic Red Team T1059.001 Test Procedures: github.com/redcanaryco