PowerShell Basics - Execution Policy and Code Signing Part 2

In my previous blog post where I covered Execution Policy and Code Signing I mentioned that these steps where only useful for content that is downloaded from the internet and to prevent accidental execution of scripts. Microsoft when they designed PowerShell they placed the control over it in to the user account control, in other words PowerShell will execute and have access to what the account has access to and the control stop at that. I will be honest I find the lack of control in terms of setting permission on Cmdlets and what can be executed a flawed way of implementing security, the though process that Microsoft used is that ones malware or a attacker is already present on the system there is not much one can do. I do not agree with this train of thought and I would like to explain why :

  • PowerShell is a very powerful environment that allows an attacker on a system to do many things that with simple command line tools is very difficult un less the attacker uploads the tools, so the lack of control just provides greater flexibility to the attacker.
  • Many post-exploitation tasks taken by an attacker and/or malware are automated, when these fail an attacker must take more time or find another method to achieve his task, this exposes him to detection to his actions in failing against a existing control and having to try one or more methods of escalation or bypass of controls. The event log system in Windows is a rich one that allow for proper event to get logged and reported, this in conjunction with a good log analysis engine and rules can mean the difference between a successful compromise of other system and critical data to detecting an attack in progress before he is able to reach that information that he so desires.

Those are my main points and I know many will disagree but I wanted you the reader to know where I stand on the lack of controls and to even providing such simple way to bypass the control that are in place that could have been easily been extended to cover more that accidental execution and/or downloaded code.

Bypassing Execution Policy from the Command Line

Powershell.exe provides several ways to bypass the Execution Policy on the system quite easily, in fact one only needs to look at the executable help message to see, execute the following either in a PowerShell session or in a Command Prompt Window:

powershell.exe -h

You will see several options that can be set during execution and different ways to execute commands or scripts using the executable. In PowerShell the Execution Policy is set in the variable $env:PSExecutionPolicyPreference and it can be manipulated by a user in the session:

C:\> Get-ExecutionPolicy 
C:\> $env:PSExecutionPolicyPreference = "Restricted" C:\> Get-ExecutionPolicy

When executing PowerShell we can use the –ExecutionPolicy parameter, here is the help description of the parameter:

    Sets the default execution policy for the current session and saves it
    in the $env:PSExecutionPolicyPreference environment variable.
    This parameter does not change the Windows PowerShell execution policy
    that is set in the registry.

The option will allow an attacker or a user just execute a PowerShell script disregarding the policy settings, remember the execution policy is to minimize accidental execution of code not for control. Lets look at a simple Hello World Script:

PS C:\Users\Carlos\Desktop> powershell.exe .\HelloWorld.ps1
. : File C:\Users\Carlos\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 cannot be loaded because running
scripts is disabled on this system. For more information, see about_Execution_Policies at
At line:1 char:3
+ . 'C:\Users\Carlos\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1'
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess
.\HelloWorld.ps1 : File C:\Users\Carlos\Desktop\HelloWorld.ps1 cannot be loaded because running scripts is disabled on
this system. For more information, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .\HelloWorld.ps1
+ ~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess
PS C:\Users\Carlos\Desktop> powershell.exe -executionpolicy remotesigned .\HelloWorld.ps1
Hello World


As we can see the policy was bypassed ad designed. An attacker with knowledge would not want to write his script to the file system since an AV might catch it so an option he has is to encode the script in to a Base64 string allowing him to have all kind of characters that would not be possible in a command line passing the command to powershell with the –command &{<command>} option. The PowerShell team is nice enough to provide you with an example on how to encode it:

# To use the -EncodedCommand parameter:

$command = 'dir "c:\program files" '

$bytes = [System.Text.Encoding]::Unicode.GetBytes($command)

$encodedCommand = [Convert]::ToBase64String($bytes)

powershell.exe -encodedCommand $encodedCommand

The use of an encoded command or script is useful since it will not write the file to disk and execute it, but it suffers from Windows limitation of length of a command as stated in http://support.microsoft.com/kb/830473 the limitation is of 8190 characters on modern versions of Windows that are able to run PowerShell. I have PowerShell module where I keep most of my security related functions and cmdlets called Posh-SecMod and it is located in https://github.com/darkoperator/Posh-SecMod in this module I have some simple functions for encoding commands and scripts. The function we will look at is under the PostExploitation submodule of Posh-SecMod and it is called ConvertTo-PostBase64Command:

PS C:\Windows\system32> help ConvertTo-PostBase64Command


    Converts a given PowerShell command string in to an Encoded Base64 command.

    ConvertTo-PostBase64Command [-Command]  []

    ConvertTo-PostBase64Command [-File]  []

    Converts a given PowerShell command string in to an Encoded Base64 command.


    To see the examples, type: "get-help ConvertTo-PostBase64Command -examples".
    For more information, type: "get-help ConvertTo-PostBase64Command -detailed".
    For technical information, type: "get-help ConvertTo-PostBase64Command -full".

Here is the code for the function:

function ConvertTo-PostBase64Command





# Command to Encode






# PowerShell Script to Encode




[ValidateScript({Test-Path $_})]








switch ($PsCmdlet.ParameterSetName)


"command" {$contents = $Command}

"file" {$contents = [system.io.file]::ReadAllText($File)}


$bytes = [Text.Encoding]::Unicode.GetBytes($contents)

$encodedCommand = [Convert]::ToBase64String($bytes)

# If to long tell the user

if ($encodedCommand.Length -gt 8100)


Write-Warning "Encoded command may be to long to run vian -EncodedCommand of Powershell.exe"








The function is quite simple it can take either a command or a script file and encodes it as a Base64 String

PS C:\Windows\system32> Import-Module posh-secmod
PS C:\Windows\system32> ConvertTo-PostBase64Command -File C:\Users\Carlos\Desktop\HelloWorld.ps1
PS C:\Windows\system32> powershell.exe -encodedcommand dwByAGkAdABlAC0AaABvAHMAdAAgACIASABlAGwAbABvACAAVwBvAHIAbABkACIA
Hello World


If the script is to big we can compress the script and use PowerShell .Net capabilities to decompress it in memory and execute it with Compress-PostScript:

PS C:\Windows\system32> help Compress-PostScript


    Will compress a script for use in Post-Exploitation with Powershell.exe

    Compress-PostScript [-File]  []

    Will compress a given script and return a command that can be used with PowerShell.exe -command 


    To see the examples, type: "get-help Compress-PostScript -examples".
    For more information, type: "get-help Compress-PostScript -detailed".
    For technical information, type: "get-help Compress-PostScript -full".

The code for the function is:

function Compress-PostScript





# Param1 help description




[ValidateScript({Test-Path $_})]








# Get Content of Script

$contents = [system.io.file]::ReadAllText($File)

# Compress Script

$ms = New-Object IO.MemoryStream

$action = [IO.Compression.CompressionMode]::Compress

$cs = New-Object IO.Compression.DeflateStream ($ms,$action)

$sw = New-Object IO.StreamWriter ($cs, [Text.Encoding]::ASCII)

$contents | ForEach-Object {$sw.WriteLine($_)}


# Base64 encode stream

$code = [Convert]::ToBase64String($ms.ToArray())

$command = "Invoke-Expression `$(New-Object IO.StreamReader (" +

"`$(New-Object IO.Compression.DeflateStream (" +

"`$(New-Object IO.MemoryStream (,"+

"`$([Convert]::FromBase64String('$code')))), " +


" [Text.Encoding]::ASCII)).ReadToEnd();"

# If to long tell the user

if ($command.Length -gt 8100)


Write-Warning "Compresses Script may be to long to run via -EncodedCommand of Powershell.exe"









We encode first in PowerShell:

PS C:\Users\Carlos>  Compress-PostScript -File C:\Users\Carlos\Desktop\HelloWorld.ps1
Invoke-Expression $(New-Object IO.StreamReader ($(New-Object IO.Compression.DeflateStream ($(New-Object IO.MemoryStream (,$([Convert]::FromBase64String('Ky/KLEnVzcgvLlFQ8kjNyclXCM8vyklR4uUCAA==')))), [IO.Compression.CompressionMode]::Decompress)), [Text.Enc

Now we can run the command in cmd.exe as:

C:\Program Files\Console2>powershell.exe -command "Invoke-Expression $(New-Object IO.StreamReader ($(New-Object IO.Compression.DeflateStream ($(New-Object IO.MemoryStream (,$([Convert]::FromBase64String('Ky/KLEnVzcgvLlFQ8kjNyclXCM8vyklR4uUCAA==')))), [IO.Compression.CompressionMode]::Decompress)), [Text.Encoding]::ASCII)).ReadToEnd();"

Hello World

The compression idea came from the evil mind of Dave Kennedy founder and CEO of Trustsec, he is also the author of SET (Social Engineering Toolkit) this toolkit has several payloads for us in phishing campaigns where PowerShell is used to create backdoors and inject payloads in to memory.

Detecting Abuse

I know there are many other ways to Base64 encode and run the commands via the command line but the ones I just covered are the main ones. The first thing that needs to be done is to enable process tracking so we are able to know what ran on  box a a given time. To enable Process tracking one would go in the Group Policy settings Local Computer Policy –> Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Audit Policies


Now when any new process is started it will be logged in the event log, you should also configure the event log properties on how you want to retain logs but that will vary by environment and in some cases even by regulations. On modern versions of Windows (not XP or 2003) it will generate events in the security log with the EventID of 4688. We can use PowerShell it self to find these events:

C:\Windows\system32> Get-EventLog -LogName security -InstanceId 4688 | where {$_.message -like "*powershell*"}

   Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
   14674 Mar 19 10:23  SuccessA... Microsoft-Windows...         4688 A new process has been created....
   14661 Mar 19 10:22  SuccessA... Microsoft-Windows...         4688 A new process has been created....
   14640 Mar 19 10:20  SuccessA... Microsoft-Windows...         4688 A new process has been created....


The only problem with process tracking is that it does not cover the command line arguments used to start the process. This information is critical when trying to figure out what an attacker did when PowerShell was just started and ended, when the process is left running say in the case of a reverse shell we can use the information to figure out what it is doing. Lets take for example a PowerShell reverse shell from SET when it runs on a target hosts a PowerShell.exe process is left behind and we can retrieve the code that was ran by using WMI to get the full command line used for the process:

C:\Windows\system32> Get-WmiObject win32_process | where name -eq powershell.exe | select commandline

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"  -encodedcommand ZgB1AG4AYwB0AGkAbwBuACAAYwBsAGUAYQBuAHU...

C:\Windows\system32> Get-WmiObject win32_process | where name -eq powershell.exe | select commandline | select -Last 1 | fl *

commandline : "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"  -encodedcommand ZgB1AG4AYwB0AGkAbwBuACAAYwBs

We can take that Base64 encoded script and decode it to see what it is happing, sadly most attacks leveraging PowerShell do not do it this way they run and exit, so a monitoring solution that can keep a log of the process command line would be ideal.

If you have upgraded the version of Windows Management Framework on all your servers and desktops (with the exception of Sharepoint 2010 and Exchange 2010 since PSv3 is incompatible at the moment) Microsoft added the ability to log the objects used in the pipeline for selected PowerShell Modules allowing us to track some of the actions taken in PowerShell.

In the Group Policy Management Console you can create a policy to manage PowerShell settings and go to Computer Configuration –> Policies –>Administrative Template–> Windows Components and double click on Turn Module Logging image

Click on Enable and the on Show to set the filter for the modules:



Create filters for the most common modules that may be abused like:

  • Powershell Core commands
  • Bits Transfer
  • Job Scheduling
  • CIM Cmdlets
  • WinRM Remoting
  • Server Manager
  • Active Directory
  • Group Policy

Your environment will dictate what you monitor for.


Click on Ok and then OK on the next window. You will see we can also control the default execution policy settings, you may have to set several different policies for execution policy depending on your environment.

Now when cmdlets are executed we can see events with ID 800 that logs the objects that went over the pipeline. for example if a user executes Get-Process the objects go internally thru the pipeline to be shown in the console and we can see in the event log the objects that went thru it:



Controlling Execution

As you may have seen controlling execution is not easy, the old and tried method of setting ACL (Access Control Lists) on the PowerShell.exe is always an alternative, but not the best since an attacker can upload his own copy of PowerShell. Microsoft has 2 solutions available for administrators to manage the execution of software in Windows and these are:

    • Software Restriction Policies (SRP)

    • Application Control Policies (Applocker)

      Each has it pros and cons and require very well planned implementation. The first thing is what each technology supports using GPO, Applocker:

      • Windows 7 Ultimate, Enterprise
      • Windows 8 Enterprise
      • Windows Server 2008 R2
      • Windows Server 2012 (Core not Supported)

      SRP :

      • Windows XP Professional
      • Windows Vista Business, Ultimate and Enterprise
      • Windows 7 Professional, Ultimate and Enterprise
      • Windows 8 Professional, Ultimate and Enterprise
      • Windows Server 2003 (all editions)
      • Windows Server 2008 (all editions)
      • Windows Server 2008 R2 (all editions)
      • Windows Server 2012 (all editions)

      Each solution also have different features, there is a bit of overlap as you can see in the table I got from http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?List=332991f0%2Dbfed%2D4143%2D9eea%2Df521167d287c&ID=83 




      Rules applies to (in a single GPO):

      All users

      Specified users and groups

      Default action level



      Has explicit “Allow” action



      Has explicit “Deny” actions



      Has special action



      Certificate rules



      Publisher rules



      Hash rules



      Network zone rules



      Path rules



      System environment variables



      Special environment variables



      Can read paths from registry



      Audit mode



      Rule collections



      Rule creation wizard



      Policy export/import



      PowerShell support



      Error messages when application is blocked



      Configurable extension list



      Can control Metro apps




      In my personal experience I prefer AppLocker just because I can assign rules by user groups and can also control future versions of the application, but it is limited by it’s limited support of the versions of Windows it support. If you have a standard build and have an environment very well controlled this would be the best solution but sadly some environments do not have this level of organization or have suffered from the new BYOD (Bring Your Own Device) policies that have become popular and made it very difficult to control configuration and enforce polices in many environment. SRP can be used but organization will depend on Organizational Unit design since the policies would be linked to each and controlled by WMI filters so as to be able to target the proper systems with the policies. So in very few words one requires more planning and the other is limited in terms of versions of  Windows that are supported.

      Which ever solution you decide to use one thing to remember if your users run with administrative privileges in their boxes they can bypass and disable the policies. Not only that but if they are tricked in to running code it will run as administrator so do plan accordingly, monitoring and flagging on attempted executions of the PowerShell executable will allow you to react in time, so you can look at this as a an early warning system and when you put together other types of logging information it will provide you with a good set of information from which to act upon and make decisions.

      As you can see locking down who can actually can execute PowerShell will take a bit of planning and testing. I recommend you do this in a lab and use the solution that best fits your needs.

      PowerShell v3 PSLockdownPolicy

      In PowerShell v3 a feature that was added was the __PSLockDownPolicy environment variable which allows to control of object types that can be used and created in PowerShell. This is used by Windows 8 RT to lockdown the PowerShell environment. Sadly Microsoft has not documented or made any information publicly available officially on the levels that can be set and what each of the levels can do. This does not stop us from using it. When used the constraint mode  will block most post exploitation scripts and commands I have seen in publicly available toolkits so I would recommend it as an extra lockdown step you can take for your hosts that use PowerShell v3.  Now do take in to consideration that this will also block some module and legitimate scripts to run so do test and be careful. To use this we can create a new group policy and choose in it Computer Configuration –> Preferences –> Windows Settings –> Environment


      Create a new entry for an Environment Variable and set it to Update so if not created it will and if it has another value it will change it back. Set it to __PSLockdownpolicy and set the value to 4


      You can click on OK and then apply then link the policy to any OU you want and use WMI filters to control on which host it is applied on.  Now you should use this in conjunction with WMI filters so as to target only those systems where you have deployed PowerShell v3. Again like with AppLocker and SRP if the user is able to run PowerShell with Administrative privileges he may be able to change the variable value for he current session by passing the control, but it will more than likely block most automated tools out there. Thanks to Matt Graeber for recommending the use of the variable and helping me test what scenarios it would apply to.

      As Always I hope you found the blog post useful and informative.