• Blog
  • Contact
  • About
Menu

The PowerShell Bear

I'm here to help you!
  • Blog
  • Contact
  • About
PS-Security.png

Execution Policy is not a security countermeasure

June 10, 2016

While there are some benefits to signing your PowerShell code, security really isn't one of them, at least not if your goal is to prevent malicious scripts from being run on your machine without your knowledge.  It can prevent malicious tampering with existing scripts and automated processes, but if something is run on your system that attempts to execute a malicious PowerShell script, it does not matter what your Execution Policy is set to.

Setting the Execution Policy sets the default behavior of PowerShell.  It can make it harder for you to accidentally run something you haven't explicitly trusted, but if a malicious actor has the ability to call powershell.exe, then that malicious actor will be able to run scripts on your system with whatever permissions they already have.  So, for example, if they convince you to open a Word document with macros to launch PowerShell in the background to download and run a malicious script, then they will have no trouble doing that, and with the same permissions you have.

To stress that point: it does not matter if you set your Execution Policy to "Restricted" to prevent any and all scripts from running, as it will not stop a malicious actor from running scripts on your system.  The only person it makes running scripts harder for is the user of the system.

So, how is it that Execution Policy is so easy to bypass?  Doesn't it require administrative permissions to change?

Yes, it does require administrative permissions to change…system wide.  As I mentioned before, that only affects the default behavior of PowerShell, but individual instances of powershell.exe can be run with a different Execution Policy, using the -ExecutionPolicy parameter.  The only permission required is the rights to execute powershell.exe itself.

To demonstrate this and validate it on your machine, do the following:

  1. Launch a PowerShell console as Administrator

  2. Run the following command: "Set-ExecutionPolicy Restricted"

    1. This is the most restrictive Execution Policy available, and will not allow any scripts to run by default

  3. Make a folder at "C:\temp" (or wherever you want, but make the necessary adjustments to the batch files below if you use a different folder), and create three new text files called "EP-Demo.ps1", "EP-Demo-1.bat", and "EP-Demo-2.bat" (make sure they don't have a hidden ".txt" after them)

  4. Edit "EP-Demo.ps1" and paste the following into it (minus the number):

    1. Write-Host "The Execution Policy is set to: $(Get-ExecutionPolicy)"
  5. Edit "EP-Demo-1.bat" and paste the following into it (minus the number):

    1. powershell.exe -Command "& C:\temp\EP-Demo.ps1"
      pause
  6. Edit "EP-Demo-2.bat" and paste the following into it (minus the number):

    1. powershell.exe -ExecutionPolicy Bypass -Command "& C:\temp\EP-Demo.ps1"
      pause
  7. Double click on "EP-Demo-1.bat" and "EP-Demo-2.bat" to see this in action

    1. Demo-1 will show the default behavior (what you would get if you just try to run a script under "Restricted", assuming you completed steps 1 and 2 above) and Demo-2 will show how easy that is to bypass with one simple parameter

As you can see, there is really no security benefit to changing the Execution Policy: if something can run powershell.exe, it can execute scripts just as easily.  It doesn't matter if it is being launched from a batch file, a VB script, a C# program, or a Word macro.

In Code Snippets, Just a Blog, Tips and Tricks Tags Security, Execution Policy, Best Practices, Demonstration
← Execution Policy is not a security countermeasure (Part 2: Group Policy)Scripting Games: January 2016 →

Latest Posts

Blog
Using Visual Studio Code Syntax highlighting to make PowerShell better
about 3 years ago
"PoshMailKit" Release version 1.1.0 published to Gallery
about 3 years ago
"PoshMailKit" version 0.9.1-beta2 published to Gallery
about 3 years ago
New project announcement: "PoshMailKit"
about 3 years ago
Change Report: 2021
about 4 years ago

Fresh Tweets

Whatever it is, the way you tell your story online can make all the difference.
  • #PowerShell #PoshMailKit, based on #MailKit, version 1.1.1 published to the #PowerShellGallery:… https://t.co/hj3WHKq5A9
    Jun 29, 2022, 1:54 PM
  • Using Visual Studio Code Syntax highlighting to make PowerShell better https://t.co/XoFrFonUQ9 #PowerShell #VSCode #SyntaxHighlighting
    Apr 26, 2022, 4:45 PM
  • "PoshMailKit" Release version 1.1.0 published to Gallery https://t.co/MNbDLtu8VG #PowerShell #SendMailMessage #MailKit #PoshMailKit
    Apr 20, 2022, 12:59 PM
  • "PoshMailKit" version 0.9.1-beta2 published to Gallery https://t.co/BUBdaYn86a #PowerShell #SendMailMessage #MailKit #PoshMailKit
    Mar 14, 2022, 10:55 AM
  • New project announcement: "PSMailKit" https://t.co/o3kme1upaE #PowerShell #SmtpClient #Send-MailMessage #MailKit
    Mar 8, 2022, 6:54 PM

Powered by Squarespace