Operating systems have developed a whole pool of security measures to mitigate and detect malicious activity at various stages. Authentication subsystems, authorisation, privilege escalation controls, anti-virus solutions, group policies and more, allowing for a wider range of system control.
In this article we will look at one of these security mechanisms and learn how to configure policies to control the launch of scripts on the OS!
What are Execution Policies?
Literally we can interpret this mechanism as execution policies for PowerShell scripts. The PS interpreter itself is an OS shell that manages services, processes, devices and control of OS objects in general.
Before running commands, the interpreter can perform additional checks according to its configurations and mechanisms. One of them Execution Policies sets a policy for an object by which it will be determined whether the current script can be run.
For example, a user on our domain network decides to open a script that is potentially malicious according to our policy:
We get a logical answer that the system has a policy that prohibits the launch of scripts. The policy itself can be set with the command:
Where the values of scope or scope, as well as the category of the prohibition policy itself vary. You can select one of the presented scopes:
- LocalMachine - manually modified in the HKEY_LOCAL_MACHINE registry, applies to all users and is independent of GPOs;
- MachinePolicy - centrally managed through GPOs and applies to the entire computer.
- UserPolicy - centrally managed through a GPO, but applies only to individual users;
- Process - The policy applies to the process in which the script restriction command was executed;
- CurrentUser - the policy will be applied to the current user from the HKEY_CURRENT_USER registry branch.
Priority of application: if the parameter is set in several places at once, the priority will be as follows:
- Process - the policy set in Process has the highest priority and overrides all others;
- UserPolicy (configured via GPO for the user);
- MachinePolicy (configured via GPO for the computer);
- CurrentUser (HKEY_CURRENT_USER registry entry);
- LocalMachine (HKEY_LOCAL_MACHINE registry entry).
The logic behind this prioritization is quite clear, for the bulk of the devices the configuration is done through GPOs, selecting users and machines. For those users or devices that are not affected by the policies are used settings from the registry. But where without exceptions in the form of priority for processes.
And the presented variations of policy types perform the following functions:
- Restricted - prohibition to run any scripts both on the local device and from the Internet;
- AllSigned - prohibit running unsigned scripts by a trusted publisher. However, if you add a self-signed CA certificate to the root trusted folder, the check will allow the script to run;
- RemoteSigned - not allowed to run unsigned remote scripts, all local scripts are allowed;
- Unrestricted - all scripts are allowed to run, requires confirmation before running;
- Bypass - similar to Unrestricted, but does not require confirmation. It is implemented for the purpose of automating tasks and is not recommended for use in regular workstations and servers.
- Default - with Windows 10 the value is Restricted, and for servers it is RemoteSigned.
Once we've covered the basic options and syntax, let's get practical!
How do I configure Execution Policy via GPO?
To get started, you can find out what policy is set on your machine now with the command:
After you can set policies globally via GPO, on a domain controller go to:
.
You need to enable the policy as well as its type:
Then save and apply to an organisational unit of devices or users:
On the client device, you can update the policies without waiting for the automatic update Win+X → Terminal/PowerShell:
And after that, let's check the settings via the command:
Depending on whether you have assigned the policy to devices or users, the MachinePolicy or UserPolicy parameter will be changed.
How do I configure Execution Policy via PS?
If you want to change the settings locally on your machine, then run the command we have explained earlier. For example, let's allow local scripts but disallow unsigned remote scripts:
Note that the actions must be performed by a person who has permissions to the registry branch. After we run an unsigned file from an external network, usually such files have a MotW tag that marks the file as external. The policy worked and the script was not run, this mechanism is great for mitigating malicious activity in a domain network on endpoints, in server solutions. This tool would be a great addition to your existing AppLocker policy and file launch zones!
If you don't have sufficient resources than you can perform actions on powerful cloud servers. Serverspace provides isolated VPS / VDS servers for common and virtualize usage.