FrameworkGuidesModulesRelease NotesAbout

PowerShell Payloads in Security Testing

PowerShell occupies a unique position in security testing. It is both the most powerful administrative tool in Windows environments and one of the most commonly abused attack surfaces. This page examines PowerShell-based payloads from both the offensive and defensive perspective, covering execution policies, logging, detection mechanisms, and the organizational controls that make PowerShell safer.

Understanding how PowerShell payloads work is not an academic exercise — if you have ever triaged an incident involving fileless malware or living-off-the-land techniques, you know that PowerShell knowledge is a prerequisite for effective defense.

Why PowerShell Matters for Testing

PowerShell is pre-installed on every modern Windows system. It has deep access to .NET, WMI, COM objects, and Windows APIs. It can execute entirely in memory without writing files to disk. And until relatively recently, most organizations had minimal logging for PowerShell activity.

These characteristics make PowerShell-based payloads an essential part of evasion testing. If your detection stack cannot see PowerShell misuse, you have a significant gap — one that real adversaries are already exploiting.

Execution Policies

PowerShell's execution policy is often misunderstood as a security boundary. It is not. Execution policy is a safety feature to prevent accidental script execution, not a security control. It can be bypassed through multiple methods that do not require administrative privileges.

Organizations should understand that execution policy alone does not prevent malicious PowerShell activity. It needs to be part of a layered approach that includes logging, AMSI, and constrained language mode.

For a complete reference on execution policies, their scope levels, and configuration options, Microsoft Learn's execution policy documentation covers the technical details and administrative guidance.

Script Block Logging

Script block logging (Event ID 4104) is the single most important PowerShell monitoring capability. When enabled, it records the full text of every PowerShell script block that executes — including dynamically generated code and decoded payloads.

To enable script block logging:

  • Group Policy path: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging
  • Registry: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging

Without script block logging, PowerShell-based attacks are effectively invisible to your SIEM. Enabling it is a high-impact, low-effort defensive improvement.

AMSI (Antimalware Scan Interface)

AMSI provides real-time inspection of PowerShell content before execution. When a script or command is entered, AMSI sends the content to the registered antimalware provider for scanning. This catches many known malicious patterns even when the script is obfuscated or dynamically assembled.

However, AMSI bypass techniques exist and are actively researched. Testing your AMSI implementation against current bypass methods is a valid use of evasion testing — if your AMSI can be trivially bypassed, you need additional controls.

Constrained Language Mode

PowerShell Constrained Language Mode (CLM) restricts the language elements available in a PowerShell session. Under CLM, scripts cannot access .NET types, COM objects, or other advanced features that are commonly used in attacks. CLM is typically enforced through AppLocker or WDAC policies.

CLM is one of the most effective defenses against PowerShell-based attacks because it removes the capabilities that make PowerShell attractive to attackers. Testing whether your CLM enforcement is complete and consistent across your environment is a valuable exercise.

Defensive Recommendations for Organizations

If you are responsible for PowerShell security in your organization:

  1. Enable script block logging everywhere. This is non-negotiable for any organization that takes security monitoring seriously.
  2. Enable module logging for additional visibility into cmdlet usage.
  3. Deploy CLM through AppLocker or WDAC for standard users who do not need full PowerShell capabilities.
  4. Forward PowerShell events to your SIEM with high priority.
  5. Baseline normal PowerShell usage so you can identify anomalous activity.
  6. Test your controls regularly with tools like the Veil Framework to verify detection coverage.

Related