PowerShell

Considering the upticks we’ve seen in using PowerShell to tamper with security products, for those using Microsoft Defender products in their enterprise, it is crucial to enable Tamper Protection. Microsoft has made substantial investments in identifying and mitigating against a large class of tampering opportunities. In the case of PowerShell tradecraft, with Tamper Protection enabled, the Set-MpPreference cmdlet cannot be used to disable or create rule exceptions.

The most effective protection against PowerShell tradecraft is through the implementation and enforcement of a strong Windows Defender Application Control (WDAC) policy, which places PowerShell into Constrained Language mode, mitigating a wide array of PowerShell tradecraft.

Visibility

Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

Defenders have been able to detect malicious use of PowerShell since the tool’s inception—and the array of relevant telemetry sources has expanded in near lockstep with adversary abuse over the years. The following data or telemetry sources are available to enterprise defenders or security vendors alike on a case-to-case basis. Some of this telemetry can be collected from commercial EDR or other security products, via native operating system logs, or both.

Process monitoring

Process execution and lineage are among the most common sources of telemetry that we leverage at Red Canary to detect all varieties of malicious activity. PowerShell is no exception. We frequently focus our detection analytics primarily on process starts, stops, and parent/child relationships while using other sources of data, like command-line parameters or network connections to enrich our detection logic. Many security tools collect process telemetry, and Red Canary leverages a variety of EDR tools to gather this information.

Command monitoring

Command-line parameters are also an effective telemetry source for detecting potentially malicious PowerShell behavior. They’re particularly useful when used in conjunction with other telemetry that’s widely available from security software, like process monitoring and network connection telemetry.

Network monitoring

Since adversaries often use PowerShell to conduct Ingress Tool Transfer or to otherwise make external network connections, security teams should consider including network telemetry in their detection analytics. In fact, one of the most common ways we detect PowerShell abuse is via a detection analytic that looks for invoke expressions that download content via HTTP.

Collection

Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

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

Designed to be consumed by security vendors, AMSI telemetry offers visibility into on-disk and in-memory execution of PowerShell and other scripting languages like VBScript, JScript, and Windows Management Instrumentation (WMI). AMSI events are not surfaced via Windows event logging, but they may be accessed through Event Tracing for Windows (ETW). We covered AMSI in depth in the Better Know a Data Source blog series.

In 2023, Red Canary continued to observe a large amount of AMSI bypasses within PowerShell payloads. A successful AMSI bypass can allow an adversary to disable logging of in-memory PowerShell execution. Fortunately, AMSI bypasses often entail a chicken-and-egg problem for adversaries, as AMSI logs the AMSI bypass attempt. It is for this reason that PowerShell detection strategies should account for robust detection of AMSI bypass attempts.

Windows Security Event ID 4104: Scriptblock logging

There are two levels of scriptblock logging: global and automatic. In Microsoft parlance, these operate at the “verbose” and “warning” levels, meaning that global scriptblock logging collects all PowerShell activity, whereas automatic scriptblock logging narrows the aperture slightly and focuses on script code that’s more likely to include malicious content. Automatic scriptblock logging is enabled by default, and it logs PowerShell script code containing suspicious terms. Microsoft’s list of suspicious terms includes the majority of the most commonly abused cmdlets and .NET APIs, so this level of logging is pretty reliable. Global scriptblock logging, on the other hand, must be enabled. It collects the same script content as automatic logging but isn’t limited to what Microsoft deems “suspicious.” It logs everything. Both methods write logs to Event ID 4104.

Note: Scriptblock logging is only compatible with PowerShell versions 5 and above.

Windows Security Event ID 400: PowerShell command-line logging

While the most effective PowerShell logging and telemetry are available in PowerShell versions 5 and above, there are some event sources that defenders can fall back on in cases where an adversary is leveraging an older version of PowerShell. Since PowerShell version 2, Event ID 400 in the “Windows PowerShell” classic event log has always provided context about PowerShell host process starts, including command-line logging.

Windows Security Event IDs 800 and 4103: Module loading and Add-Type logging

Module logging logs all loaded modules to Event ID 800 in the “Windows PowerShell” event log. This feature must be explicitly enabled. What isn’t well documented though is that 800 events also log the contents of source code supplied to the Add-Type cmdlet. Adversaries often use Add-Type in order to compile and interact with C# code. Starting in PowerShell version 5, Add-Type context is also supplied in Event ID 4103 in the Microsoft-Windows-PowerShell/Operational log.

Sysmon Event IDs 1 and 7: Process creation and Image loaded

Since monitoring for suspicious PowerShell will involve the execution of the PowerShell process, Sysmon Event ID 1 warrants mention. However, Sysmon Event ID 7 is likely an even better source for gaining visibility into PowerShell since it will record any process that runs PowerShell by focusing on the modload for System.Management.Automation.dll and System.Management.Automation.ni.dll. Olaf Hartong’s Sysmon Modular includes a PowerShell-specific configuration looking for these and other important modules, and it’s a great place to start if you’re interested in using Sysmon to track PowerShell activity.

Endpoint Detection and Response (EDR) tools

A good EDR product will provide detailed visibility into all of the data sources referenced above and offer great value to security teams seeking to detect adversaries abusing PowerShell.