S 4.421 Securing Windows PowerShell

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

Windows PowerShell (WPS) is a .NET-based script environment for interactive system administration. WPS is also able to run administrative scripts. Scripts are a list of individual commands stored in a text file and opened in the command line.

If WPS is not required, it should be uninstalled.

In Windows 7 and higher, the PowerShell script environment can only be removed by uninstalling the .NET-Framework. If this is required for other applications, the following security aspects must be observed for the PowerShell environment:

On 64-bit systems, a 32-bit PowerShell and a 64-bit PowerShell exist in parallel. The 32-bit environment uses the 32-bit emulation layer SysWOW64 in order to access the file system and the registry. SysWOW64 may cause malfunctions when accessing system areas. Furthermore, 32-bit scripts may be characterised by incompatibilities with the 64-bit environment and vice versa. Therefore, only the 64-bit PowerShell should be used on 64-bit systems. Scripts created and tested on a 32-bit system should not be used on a 64-bit system.

Securing on file level

Only administrators should be allowed to open the program files C:\Windows\WindowsPowerShell\powershell.exe and powershell_ise.exe. For that reason, only the Administrators group should be granted the Execute right in the security settings of these files. On 64-bit systems, the 32-bit versions can be found in folder C:\Windows\SysWOW64 and must also be secured.

It should be considered to restrict the access to certain administrator accounts, for example if automatically executing scripts or executing scripts over the network is planned. In this regard, it is advisable to define a separate security group locally or within a domain and to grant this group the required authorisations.

Note: The security groups System and TrustedInstaller must not be removed for programs disposing of authorisations for running WPS!

Securing the PowerShell profile

The user-specific PowerShell profile loaded when opening WPS should be secured. In WPS, the $profile command can be used in order to determine which file contains the profile for the currently logged in user. Normally, the profile can be found in a folder within the Windows user profile that can only be accessed by the user and the administrators. In order to rule out any unauthorised access attempts, object monitoring should be enabled for the profile files (for more information see S 4.344 Monitoring of Windows Vista, Windows 7 and Windows Server 2008 systems). In particular, every group also disposing of general change privileges must also be added as SACL (System Access Control List) for the profile files (Properties | Security | Advanced | Monitoring). The monitoring events should be analysed randomly in the events display.

Securing the script execution

It is also necessary to secure the executed scripts. The PowerShell profile is of particular importance, since it is started in a user-specific manner when opening WPS. The execution of scripts may be critical to the stability and integrity of the operating system and the applications, even without any administrative access to operating system components. For that reason, the following executable script files and auxiliary files should be equipped with the correspondingly restricted authorisations on file system level:

The Change authorisation regarding the scripts should be restricted to certain groups in order to guarantee the integrity of the scripts.

The execution of PowerShell scripts should furthermore be restricted by the Set-ExecutionPolicy command. In doing so, it is defined which conditions the scripts must meet in order to be executed. The following options are possible:

The execution of PowerShell scripts should be restricted to signed scripts. For this, the following command is executed in the PowerShell environment:

Set-ExecutionPolicy AllSigned

Signing PowerShell scripts

Signing scripts requires a class 3 Authenticode code signature certificate that can be obtained in 3 ways.

Institutions disposing of an internal Public Key Infrastructure (PKI) can create the required certificate themselves if the related internal Certification Authority is classified trustworthy by all IT systems within the information system connected to the PKI.

The second option is to use an external Certification Authority (CA). Windows Vista and Windows 7 systems are already configured in such a way that they trust the certificates of leading external CAs.

The third option is to create a self-signed certificate by means of the Makecert.exe tool. This free tool is delivered together with the Windows platform SDK and installed automatically in some Microsoft Office editions. The disadvantage is that a certificate can always only be used on the IT system it was created on. In order to execute PowerShell scripts over the network, for example as login script (see S 2.326 Planning the Windows XP, Vista and Windows 7 group policies), an internal or external Certification Authority is recommended.

Review questions:

© Federal Office for Information Security. All rights reserved.