There are a lot of benefits of using Windows PowerShell over the more popular Command Prompt. But using PowerShell without digitally signing scripts can leave you vulnerable to attacks.
This post will explain the importance of PowerShell script signatures and mention some best practices so your scripts remain secure.
What is Windows PowerShell?
Windows PowerShell was designed to replace the Command Prompt. Just like the Command Prompt, PowerShell uses a command line environment that gives access to services in your operating system.
While Command Prompt commands still work in PowerShell, the latter can run more complex operations such as batch renaming files in one folder.
PowerShell is based on the .NET framework. It’s compatible with Windows, MacOS, and Linux.
Where to Find PowerShell in Windows 10
The fastest way to access Windows PowerShell is by using the Run feature. Go to Run (Windows + R) and type PowerShell. This should launch Windows PowerShell.
You can also go to Start and on the search bar type PowerShell. The program should come up as one of the suggestions. Click it to launch or right-click then select Run as Administrator to make changes on an admin level.
What is a PowerShell script?
PowerShell scripts let system administrators run commands that allows them to manage operating systems through command lines. In PowerShell, these commands are referred to as cmdlets. While lay-people might find cmdlets confusing, administrators find them easier to use compared to the old standard.
You can use Notepad to write scripts and save them with the file extension .ps1 so they are recognized as PowerShell scripts.
As a safety measure, files saved with this extension cannot be run by double-clicking.
Why sign a script?
Signing your scripts will do two things. One: it will authenticate that the people using the script are also the authors of the script. Two: it will make sure the scripts had not been tampered with in any way.
A system will have a group policy assigned to it. This will affect how your system will treat scripts that are executed on your computer.
- Restricted – Scripts will not be executed. This is the default setting.
- RemoteSigned – You can run scripts that either you or a trusted publishers created.
- AllSigned – Any script that is created locally or downloaded can run as long as they are digitally signed.
- Unrestricted – Run any script after confirmation.
- Bypass – Run any script without the need for confirmation.
You can change the policy through the Set-ExecutionPolicy command.
SET-EXECUTIONPOLICY -EXECUTIONPOLICY <POLICY NAME> -SCOPE <SCOPE NAME>
Where you replace the <POLICY NAME> with one of the group policy values and <SCOPE NAME> is replaced by one of the following:
- Process – Affects only the current PowerShell session.
- CurrentUser – The change will only affect the current user.
- LocalMachine – All changes made will affect all the users of the computer.
For example, you want a RemoteSigned policy where the policy is implemented across all users, you would use this command:
SET-EXECUTIONPOLICY -EXECUTIONPOLICY REMOTESIGNED -SCOPE LOCALMACHINE
PowerShell Best Practices
There’s a chance that you won’t be able to disable PowerShell for practical reasons. But there are things you can do to prevent people from launching an attack on your system.
Use PowerShell Constrained Language Mode
The Constrained Language Mode removes advanced feature support like .NET and Windows API calls. PowerShell attack tools rely on these functionalities so the lack of support would put any attack on hold.
To turn on the PowerShell through the group policy, open Group Policy and go to Computer Configuration > Preferences > Windows Settings > Environment.
Use PowerShell v.5 With Applocker and Device Guard
A featured called Device Guard can also be used to leverage advanced hardware features to whitelist applications. It can also enforce the constrained language mode.
Log PowerShell Activity
Activity monitoring for PowerShell can be enabled by editing the group policy. Active Directory, for example, is a script that logs cmdlet use. GroupPolicy does the same but logs the use of the group policy cmdlet instead.
You must feed the logs to a central logging system for them to be of any use. Configure the logs to send alerts for known attack methods.