Skip to the main content.

Security and PowerShell: How to make scripting waterproof

Table of Contents

Post Featured Image

IT security is one of the issues that really occupies businesses. Rightly so, as more and more attacks on infrastructures show. Scripts that control many tasks are also popular targets for attacks. But how can security be increased in the PowerShell environment? The following article shows a solution for some aspects.

What PowerShell has to offer

PowerShell already includes some “standard” functionalities to increase security and prevent attackers from malicious attacks, such as the execution policies, the logging and monitoring function and the digital signature. They are a good start.

Execution Policies

With PowerShell, security starts with the execution policies. The execution policies specify what conditions must be created for PowerShell to execute scripts. Here you can define different levels, for example, that local scripts can run unsigned, while downloaded scripts must be signed. In itself, this feature is useful for preventing scripts from being executed accidentally. Hackers, however, are not impressed.

Tip: If you use the Execution Policies, control them via the Group Policies. These are always located above the local permissions and are therefore more powerful in the fight against unwanted executions.

Check the set policies with “Get-ExecutionPolicy -list”. If the settings are set to RemoteSigned, this means that local scripts are always executed, downloaded scripts only with signature. If the script itself is now simply set to “unblocked” and made available locally, the hurdle is already overcome.

Logging & Monitoring

Logging & monitoring are also included in PowerShell. Here you can make sure that the execution of scripts is traceable via the Windows Event Log.  However, you should also do this via the Group Policies, since traceability can only be achieved via centralization.

Digital Signature

We have already mentioned the digital signature in the execution guidelines and found that it can be enormously important. It answers two questions: Who created the script (authentication)? And was the script changed again after signing (integrity)? It is certainly best to purchase certificates from official providers, as they are considered to be particularly secure. You can also use New-SelfSignedCertificate to create your own certificates and use them in scripts.

After every change to a script, it must be re-signed.

Constrained Language

PowerShell can be used in different language modes. One of them is the Constrained Language. It has recently been extensively implemented, but requires centralization if you want to limit the capabilities of the PowerShell language and commands.

This is because the setting is reset to FullLanguage for each new session. Centralization is therefore only possible with solutions such as Applocker or Device Guard.


The credentials required to run PowerShell scripts are an exciting topic and at the same time one of the biggest challenges.

PowerShell credentials consist of username and password, and have lost nothing in the scripts. The manual input of credentials by the user is safe, but of course prevents the automatic execution of scripts. One way to work around this problem is to encrypt the password information, which is then read at runtime by the PowerShell script. However, this only works on the machine on which the encryption was performed. If the password file is copied to another computer, the file can no longer be used there. With this method, even secure delegation cannot be implemented.

JEA – Just Enough Administration

The goal of JEA is to really only provide users with the permissions they need to perform certain actions. An example would be here the creation of a user in the Active Directory (AD), without the user thereby also still other authorizations in the AD possesses.

JEA provides a role-based access control (RBAC) platform for PowerShell. Since whitelisting is used here, it is imperative to know all actions that users should be able to perform. Thus, the maintenance of the appropriate guidelines is accordingly complex and requires still that the user PowerShell knowledge possesses.

How ScriptRunner significantly increases security

PowerShell is therefore equipped with some “basic functionalities” to be able to handle scripts safely. On the other hand, a number of problems that arise during the practical use of PowerShell are not solved. The advanced security features of ScriptRunner are described below.

Centralization of scripts

With ScriptRunner all PowerShell scripts are centrally stored and structured. This creates the prerequisite for development and use in teams.

In addition, it is ensured that all participants always work with the current script versions. Access to the scripts is controlled with the help of rights control. Using the ScriptRunner Add-In for the PowerShell ISE, scripts can be edited in the central repository and checked in and out. Integration with Git, TFS and other source code management systems is also possible.

Secure management of credentials

Credentials are required to run most PowerShell scripts. With ScriptRunner, this information can be stored centrally and securely. The Windows Credential Store on the ScriptRunner server is available for this, and Password Server Connectors from CyberArk, Pleasant and Thycotic are supported. This allows you to manage all credentials in a central repository, which simplifies administration considerably, especially when using multiple ScriptRunner instances.

No privileged permissions for users

ScriptRunner controls permissions for running PowerShell scripts from central service accounts. This means that for each so-called target (Exchange, Active Directory, Azure, Office365, VMware, etc.) the appropriate service accounts are used.

Users (e.g. from the help desk team) who should be able to start scripts therefore do not need special permissions on the corresponding targets.

This separation allows tasks to be safely delegated to users who are only standard domain users.

Secure execution & central monitoring

ScriptRunner offers all possibilities for the secure execution of PowerShell scripts: from local execution to PowerShell remoting and special execution modes for e.g. JEA, many options are available. The execution itself is possible in three ways:

  1. manual execution by users
  2. time-controlled execution
  3. automatic execution triggered by third-party systems such as monitoring or workflow systems

All activities can be tracked via the central dashboard. Important information is also available in the Windows EventLog and via Windows Performance Counter.

Secure delegation

The functions described up to now allow employees to delegate individual tasks safely and easily. Secure, as the users do not need any special permissions to perform the tasks. Simple, because employees do not need any PowerShell know-how and are operated via a convenient web interface. The required input masks are created dynamically from the respective PowerShell script. This means that there is no need to develop a user interface at all.

The result is a secure solution for the entire PowerShell lifecycle, from joint script development to use by help desk teams and end users.

PowerShell Security Ebook - Everything you need to know about PowerShell Security

Related Content

Related posts

About the author: