Safeguard
Application Security•

Detecting and Mitigating PowerShell Abuse (T1059.001)

PowerShell can run code in memory and reach remote hosts. Learn what MITRE documents, which logs to turn on and how to restrict it without breaking admins.

Safeguard Security Team
4 min read

PowerShell (MITRE ATT&CK T1059.001) is an execution technique. PowerShell is a command line interface and scripting environment built into Windows, and it can also be installed on Linux and macOS. MITRE lists all three as platforms. Adversaries use it for discovery and for running code.

How attackers use it

MITRE gives these examples of what PowerShell can do. The Start-Process cmdlet runs an executable. Invoke-Command runs a command locally or on a remote computer, though connecting to remote systems requires administrator permissions.

PowerShell can also download and run executables from the internet, either from disk or in memory without touching disk. That in-memory option is why file based scanning alone is not enough.

MITRE notes that a number of PowerShell based offensive testing tools exist, and that PowerShell commands can run without ever starting powershell.exe. They can go through the System.Management.Automation assembly, exposed through .NET and the Windows Common Language Interface. So a rule that only looks for the powershell.exe process name will miss some activity.

How to detect it

MITRE's detection strategy describes behavioral chains: PowerShell launched with encoded commands, unusual parent processes or suspicious modules loaded, potentially followed by network connections or child process creation. It covers both direct launches of powershell.exe and indirect .NET automation.

Useful data sources and settings:

  • Process creation with command lines. Security event ID 4688 and Sysmon event ID 1 are common sources.
  • PowerShell script block logging, which records the code that actually ran, including decoded content. It writes event ID 4104 to the Microsoft-Windows-PowerShell/Operational log.
  • PowerShell module logging, event ID 4103 in the same log.
  • Module and image loads, for instance Sysmon event ID 7, to catch System.Management.Automation loaded into processes that are not PowerShell.
  • Network connections from processes that start PowerShell.

Signals worth alerting on:

  • Encoded or heavily obfuscated command arguments.
  • PowerShell started by Office applications, script hosts or web server processes.
  • Download and execute behavior in one script block.
  • Remote execution from workstations to many servers.
  • Use of Add-Type to reach Windows APIs.

Baseline first. Administrators and management tools run a lot of legitimate PowerShell. Know which accounts and hosts normally use it so that the unusual stands out.

How to reduce the risk

From MITRE's mitigations:

  • Remove PowerShell where it is not needed, but review first, since it may support many legitimate administrative functions.
  • Disable or restrict the WinRM service to limit remote execution through PowerShell.
  • Set the execution policy to run only signed scripts, and consider limiting policy changes to administrators. MITRE warns that execution policy can be bypassed depending on configuration.
  • Use Just Enough Administration (JEA) to limit what administrators and users can do through remote sessions.
  • Use application control. Constrained Language mode restricts sensitive language elements, for example Add-Type.
  • Use antivirus to quarantine suspicious files.

Treat these as layers. Logging tells you what happened, constrained language and application control limit what can happen, and JEA limits how much a stolen admin session is worth.

Check your own environment

Windows PowerShell, read-only checks:

Get-ExecutionPolicy -List
$ExecutionContext.SessionState.LanguageMode
Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' -MaxEvents 20 | Where-Object Id -eq 4104
Get-Service WinRM

What each tells you: policy by scope, language mode of your session, whether script block events are being recorded, and whether WinRM is present and running. To check logging policy in the registry:

reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging

If the key is missing, script block logging is not enforced by policy on that host. Then ask who is allowed to run Invoke-Command against your servers, and whether those sessions are logged centrally.

Quick check

Can a rule on the powershell.exe process name catch all PowerShell activity?

No. MITRE notes PowerShell can run through System.Management.Automation without starting powershell.exe, so also watch module loads and script block logs.

What does PowerShell Constrained Language mode limit?

Sensitive or dangerous language elements, such as those used to run arbitrary Windows APIs or files, for example Add-Type.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.