Windows Powershell policy execution bypass

Learn windows powershell policy execution bypass with practical examples, diagrams, and best practices. Covers windows, powershell, batch-file development techniques with visual explanations.
Tags:
Categories:

Understanding and Bypassing PowerShell Execution Policies

Hero image for Windows Powershell policy execution bypass

Explore the various PowerShell execution policies, their purpose, and common methods to bypass them for legitimate administrative tasks or in controlled environments.

PowerShell execution policies are a security feature designed to control the conditions under which PowerShell loads configuration files and runs scripts. While they are not a security boundary in the traditional sense (they don't prevent a determined attacker), they serve as a first line of defense against accidentally running malicious scripts. Understanding these policies and how to temporarily or permanently bypass them is crucial for system administrators and developers working with PowerShell.

What are PowerShell Execution Policies?

PowerShell execution policies define the restrictions on running scripts. They are designed to prevent the execution of potentially harmful scripts, especially those downloaded from the internet. It's important to note that these policies are applied per-scope, meaning you can have different policies for the current user, local machine, or even a specific process. The most common policies include:

  • Restricted: The default policy. No scripts can be run. PowerShell can only be used in interactive mode.
  • AllSigned: Only scripts signed by a trusted publisher can be run. This includes scripts you write yourself if you sign them.
  • RemoteSigned: Scripts created on the local computer can run. Scripts downloaded from the internet must be signed by a trusted publisher.
  • Unrestricted: All scripts can run. This is the least secure policy and should be used with caution.
  • Bypass: Nothing is blocked and no warnings are issued. This policy is often used in automated scenarios where script execution is expected and controlled.
  • Undefined: No execution policy is set for the current scope. If no policy is set for any scope, the effective policy is Restricted.
flowchart TD
    A[PowerShell Script Execution Attempt]
    B{Is Execution Policy Defined for Scope?}
    C{Effective Policy: Restricted?}
    D{Effective Policy: AllSigned?}
    E{Effective Policy: RemoteSigned?}
    F{Effective Policy: Unrestricted/Bypass?}
    G[Block Execution]
    H[Allow Execution (Interactive Only)]
    I[Check Digital Signature]
    J[Signature Valid & Trusted?]
    K[Check Origin: Local or Remote?]
    L[Allow Execution]
    M[Block Execution (Untrusted Signature)]
    N[Allow Local Scripts]
    O[Check Remote Script Signature]
    P[Signature Valid & Trusted?]
    Q[Block Execution (Remote, Untrusted Signature)]

    A --> B
    B -- No --> C
    B -- Yes --> C
    C -- Yes --> H
    C -- No --> D
    D -- Yes --> I
    I --> J
    J -- Yes --> L
    J -- No --> M
    D -- No --> E
    E -- Yes --> K
    K -- Local --> N
    K -- Remote --> O
    O --> P
    P -- Yes --> L
    P -- No --> Q
    E -- No --> F
    F -- Yes --> L
    F -- No --> G
    H --> G
    N --> L

PowerShell Execution Policy Decision Flow

Common Bypass Techniques

While execution policies are a good default, there are many legitimate reasons to bypass them, such as running a script downloaded from a trusted source, automating tasks, or developing and testing scripts. Here are some common methods:

  1. Using the Bypass Policy for the Current Process: This is one of the safest and most common methods. It sets the execution policy to Bypass only for the current PowerShell session, reverting to the previous policy once the session closes.
  2. Using the Unrestricted Policy for the Current Process: Similar to Bypass, but might still issue warnings for unsigned scripts from the internet.
  3. Executing Script Content Directly: You can pipe the script content directly to powershell.exe without saving it to a file, effectively bypassing file-based policy checks.
  4. Base64 Encoded Commands: For more complex scripts or to avoid command-line parsing issues, you can encode the script in Base64 and execute it using the -EncodedCommand parameter.
  5. Setting Policy for a Specific Scope: While not a bypass in the same sense, setting a less restrictive policy (e.g., RemoteSigned) for the CurrentUser scope is a common practice for developers.
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force

Temporarily set execution policy to Bypass for the current PowerShell process.

powershell.exe -ExecutionPolicy Bypass -File "C:\path\to\your\script.ps1"

Run a PowerShell script from a batch file with a bypass policy.

$scriptContent = Get-Content -Path "C:\path\to\your\script.ps1" | Out-String
Invoke-Expression $scriptContent

Execute script content directly using Invoke-Expression.

$script = "Write-Host 'Hello from Base64 encoded script!'"
$encodedScript = [System.Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($script))
powershell.exe -EncodedCommand $encodedScript

Execute a Base64 encoded PowerShell command.

Checking Current Execution Policies

Before attempting any bypass, it's good practice to understand the current execution policies in effect on your system. You can query them using the Get-ExecutionPolicy cmdlet. This cmdlet can also show you the policies set for different scopes.

# Get the effective execution policy
Get-ExecutionPolicy

# Get execution policies for all scopes
Get-ExecutionPolicy -List

Commands to check current PowerShell execution policies.