CODEWITHSUNDEEP
powershellmalwareexecutionpolicy
John Dane
John Dane

Reputation: 29

Prevent bypassing PowerShell execution policy

We have PowerShell installed on our RDS environment. It's currently being used for tasks like remote management and App-V virtual application publishing. To my understanding, it's fairly easy to bypass a restricted execution policy.

I can't however find any useful information on preventing bypassing the execution policy (or making it a lot harder). I was thinking about using file screening (AppLocker) for blocking PowerShell files, but I guess then attackers could just use a VBA script attached to an Microsoft Office file to execute a PowerShell script.

For now we focus on monitoring, but I would like more attention on preventing.

Upvotes: 1

Views: 3261

Answers (3)

ThioJoe
ThioJoe

Reputation: 61

The way to do is to set the "MachinePolicy" (or "UserPolicy") scope. This can be done through the Group Policy editor, and cannot be overridden by using the bypass command. By default, if you run Get-ExecutionPolicy -List in PowerShell, you'll likely see both of those at the top as 'Undefined'.

To change it, open Group Policy Editor and navigate to: Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell and open the option called Turn on Script Execution.

By default it's Not Configured. If you set it to Disabled, it will set MachinePolicy to 'Restricted'. If you set it to Enabled you'll see a dropdown where you can select other policies like only signed scripts (The 'AllSigned' Policy).

Say you set it to AllSigned. Then if someone tries to run a command like:

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

It will respond with this:

Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of AllSigned.

If you list the current execution policies again, it will show the scope the person just set as having that execution policy. However, even if it is Bypass for example, it will not actually apply and MachinePolicy will win. This is even if PowerShell is running as administrator, the MachinePolicy will still apply.

And you can't just change the MachinePolicy through PowerShell either, even while running as Admin. If you do, it will say:

Cannot set execution policy. Execution policies at the MachinePolicy or UserPolicy scopes must be set through Group Policy.

For PowerShell 7:

If you use PowerShell 7 which is downloaded separately (not to be confused with 'Windows Powershell'), that will use totally separate ExecutionPolicies. To set the MachinePolicy for that, you also need to use Group Policy Editor, but it will not be found there by default.

To get PowerShell 7 settings to show up in Group Policy Editor, you will need to run the script included in your PowerShell 7 installation called InstallPSCorePolicyDefinitions.ps1. You must run this using PowerShell 7, and probably as Admin.

Now, you will be able to find those settings in GPE at: Computer Configuration > Administrative Templates > PowerShell Core

It will have the same set of settings as Windows PowerShell, but fortunately they have an additional option to just inherit what you set for Windows PowerShell.

Additional Notes:

  • Others mentioned using AppLocker, which is a good idea to add security, but be warned that AppLocker does NOT completely block the execution of PowerShell Scripts, even if you explicitly create a rule to block a specific script. Instead, 'Blocking' a PowerShell script in AppLocker just makes it run in "Constrained Language" mode.

  • To change the 'UserPolicy' scope, you do the same things as above, but instead of looking in "Computer Configuration" in Group Policy Editor, look for the corresponding settings in "User Configuration".

Upvotes: 0

bluuf
bluuf

Reputation: 1001

Actually, there are ways to prevent misuse of PowerShell (and making bypassing the execution policy quite useless):

  1. Configure AppLocker: also lockdown scripts
  2. Configure PowerShell to use Constrained Mode so .NET code can't be executed
  3. For your own scripts that should support .NET code you can sign the scripts with a code signers certificate (these will be allowed to run with constrained mode + AppLocker)

Besides that, configuring logging of all PowerShell commands and sending them through a central location (so an IDS can monitor this) is also a good practice.

See Detecting Offensive PowerShell Attack Tools for more detailed information about how to achieve this.

Upvotes: 0

4c74356b41
4c74356b41

Reputation: 72151

What you are trying to achieve is pointless. There are dozens of ways to bypass execution policy. In fact, it is not designed for security reasons.

  1. Install PS 5+ everywhere and implement script block logging. You can place all logs in a shared directory somewhere to analyze\ingest them.
  2. Remove PS2 everywhere
  3. Block macros from files from the web
  4. Use application whitelisting

This should be a good place to start.

PS: You can also monitor event 400, to detect bypasses to PS2 (which is something you don't want to be on your users' machines) when something reinstalls PS2 back.

Upvotes: 3

Related Questions