10 PowerShell Security Best Practices

PowerShell is a powerful scripting language that can be used by attackers to gain control of systems. As such, it is important to follow best practices for PowerShell security in order to prevent attackers from using PowerShell to gain access to systems.

In this article, we will discuss 10 PowerShell security best practices that should be followed in order to secure systems. These best practices include disabling PowerShell, using least privilege, and more.

1. Use the Most Secure Execution Policy

PowerShell’s execution policies determine how (or if) PowerShell runs scripts. There are four different levels of execution policy, ranging from “Restricted” (which doesn’t allow any scripts to run) to “Unrestricted” (which allows all scripts to run).

The most secure execution policy is “RemoteSigned”, which allows local scripts to run and requires all scripts downloaded from the internet to be signed by a trusted publisher.

Using the most secure execution policy will help protect your system from malicious PowerShell scripts, so it’s important to set your execution policy to “RemoteSigned” if possible.

2. Run PowerShell as a Standard User

When you run PowerShell as an administrator, all the commands you execute have full administrative rights. This means that if a malicious command is executed, it could do serious damage to your system.

On the other hand, when you run PowerShell as a standard user, the commands you execute are limited to the permissions of that user. This means that even if a malicious command is executed, it can only do damage that the standard user has permission to do.

Of course, this doesn’t mean that you should never run PowerShell as an administrator. There are times when you need to use administrative privileges, but in general, it’s best to run PowerShell as a standard user.

3. Sign Your Scripts and Configuration Files

When you sign a PowerShell script or configuration file, you’re essentially creating a digital signature that can be used to verify the authenticity and integrity of the file. This is important because it helps to prevent malicious changes from being made to your files without your knowledge.

Signing your scripts and configuration files also allows you to control who can run them. For example, you can specify that only users who have a specific digital certificate installed on their computer can run the file.

PowerShell includes built-in support for signing scripts and configuration files. To sign a file, you first need to create a digital certificate using the New-SelfSignedCertificate cmdlet. Once you have a digital certificate, you can sign a file using the Set-AuthenticodeSignature cmdlet.

4. Avoid Running Unsigned Scripts

PowerShell is a powerful scripting language that can be used to automate many tasks. However, because of its power, it can also be used by malicious actors to gain access to systems and data.

To help mitigate this risk, PowerShell includes a security feature called “script signing.” Script signing allows you to digitally sign scripts, which verifies the authenticity of the script and ensures that it has not been tampered with.

If you try to run an unsigned script, PowerShell will display a warning message. It’s important to heed this warning and not bypass it, as doing so could allow a malicious script to execute on your system.

If you’re unsure whether a script is signed or not, you can check the properties of the script file. If the “Digital Signature” tab is present, then the script is signed. If not, then the script is unsigned and should not be run.

5. Disable Scripting Where Possible

PowerShell is an incredibly powerful scripting language, capable of automating just about any task you can think of. However, this power comes at a price –– PowerShell scripts can be used by attackers to gain access to systems and data, or to launch attacks against other systems.

To mitigate this risk, it’s important to disable PowerShell scripting where possible. For example, if you don’t need PowerShell for a particular task, don’t enable it. If you only need PowerShell for specific tasks, consider using a whitelist to only allow certain scripts to run.

By disabling PowerShell scripting where possible, you can help reduce the attack surface of your systems and make it more difficult for attackers to use PowerShell to gain access to your data or launch attacks.

6. Limit Access to the PowerShell Console

The PowerShell console is a powerful tool that can be used to manage and automate many tasks in Windows. However, it can also be used to maliciously modify system settings, install malware, or even delete data.

Therefore, it’s important to only allow trusted users to access the PowerShell console. One way to do this is to use role-based access control (RBAC) to limit who can run PowerShell commands.

RBAC is a built-in feature in PowerShell that allows you to control who can run PowerShell commands based on their roles within an organization. For example, you could allow members of the IT team to run PowerShell commands, but not members of the marketing team.

To learn more about how to configure RBAC, check out Microsoft’s documentation.

7. Restrict Network Access

By default, PowerShell remoting is not encrypted. This means that if an attacker were to gain access to your network, they could potentially use PowerShell to remotely execute commands on your systems without your knowledge.

To mitigate this risk, you should only allow PowerShell remoting from trusted computers and networks. You can do this by using the built-in Windows Firewall or a third-party firewall solution.

Additionally, you should consider disabling PowerShell remoting entirely if it’s not needed. If you do need PowerShell remoting, make sure to use it over an encrypted connection such as SSL/TLS.

8. Monitor for Suspicious Activity

If an attacker gains access to your system, they will likely try to use PowerShell to further their goals. By monitoring for suspicious activity, you can detect and stop an attack before it does serious damage.

There are a few different ways to monitor for suspicious activity. One is to look for unusual PowerShell usage patterns. For example, if you normally only use PowerShell to run a few specific commands, but suddenly you see someone running hundreds of different commands, that could be an indication that something is wrong.

Another way to monitor for suspicious activity is to look for changes in the way PowerShell is being used. For example, if you normally use PowerShell to connect to remote systems, but suddenly you see someone trying to run PowerShell scripts locally, that could be an indication that they’re trying to do something malicious.

Finally, you can also monitor the PowerShell event logs for signs of suspicious activity. The PowerShell event logs contain information about all the PowerShell commands that have been run on a system, so they can be a valuable source of information for detecting attacks.

9. Harden Remote Desktop Services

If an attacker can gain access to a system with unsecured RDP, they can easily launch attacks on other systems on the network. Additionally, unsecured RDP can be used to pivot to other systems and gain access to sensitive data.

To harden RDP, you should enable Network Level Authentication and restrict RDP access to only trusted IP addresses. You can also use PowerShell to audit RDP settings and ensure that only authorized users have access.

10. Enable PowerShell Logging

By default, PowerShell doesn’t log anything. This means that if an attacker were to use PowerShell to do something malicious on your system, there would be no record of it.

Enabling PowerShell logging will give you a record of everything that PowerShell is used for on your system. This can be incredibly useful when investigating an incident or trying to determine what happened after an attack.

To enable PowerShell logging, you need to edit the registry. The specific keys and values that need to be changed depend on the version of PowerShell that you’re using. For PowerShell 5.1, the keys and values are as follows:

Key: HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging

Value name: EnableModuleLogging

Value type: REG_DWORD

Value data: 1

For PowerShell 6.0 and later, the keys and values are as follows:

Key: HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription

Value name: EnableInvocationHeader

Value type: REG_DWORD

Value data: 1

After changing these values, you need to restart PowerShell for the changes to take effect.