Edit

Share via

PowerShell security features

PowerShell has several features designed to improve the security of your scripting environment.

Execution policy

PowerShell's execution policy is a safety feature that controls the conditions under which PowerShell loads configuration files and runs scripts. This feature helps prevent the execution of malicious scripts. You can use a Group Policy setting to set execution policies for computers and users. Execution policies only apply to the Windows platform.

For more information, see about_Execution_Policies.

Use of the SecureString class

PowerShell has several cmdlets that support the use of the System.Security.SecureString class. And, as with any .NET class, you can use SecureString in your own scripts. However, Microsoft doesn't recommend using SecureString for new development. Microsoft recommends that you avoid using passwords and rely on other means to authenticate, such as certificates or Windows authentication.

PowerShell continues to support the SecureString class for backward compatibility. Using a SecureString is still more secure than using a plain text string. PowerShell still relies on the SecureString type to avoid accidentally exposing the contents to the console or in logs. Use SecureString carefully, because it can be easily converted to a plain text string. For a full discussion about using SecureString, see the System.Security.SecureString class documentation.

Module and script block logging

Module Logging allows you to enable logging for selected PowerShell modules. This setting is effective in all sessions on the computer. PowerShell records pipeline execution events for the specified modules in the Windows PowerShell event log.

Script Block Logging enables logging for the processing of commands, script blocks, functions, and scripts - whether invoked interactively, or through automation. PowerShell logs this information to the Microsoft-Windows-PowerShell/Operational event log.

For more information, see the following articles:

AMSI Support

The Windows Antimalware Scan Interface (AMSI) is an API that allows applications to pass actions to an antimalware scanner, such as Windows Defender, to scan for malicious payloads. Beginning with PowerShell 5.1, PowerShell running on Windows 10 (and higher) passes all script blocks to AMSI.

PowerShell 7.3 extends the data it sends to AMSI for inspection. It now includes all .NET method invocations.

For more information about AMSI, see How AMSI helps.

Constrained language mode

ConstrainedLanguage mode protects your system by limiting the cmdlets and .NET types allowed in a PowerShell session. For a full description, see about_Language_Modes.

Application Control

Windows 10 includes two technologies, App Control for Business and AppLocker that you can use to control applications. PowerShell detects if a system wide application control policy is being enforced. The policy applies certain behaviors when running script blocks, script files, or loading module files to prevent arbitrary code execution on the system.

App Control for Business is designed as a security feature under the servicing criteria defined by the Microsoft Security Response Center (MSRC). App Control is the preferred application control system for Windows.

For more information about how PowerShell supports AppLocker and App Control, see Use App Control to secure PowerShell.

Software Bill of Materials (SBOM)

Beginning with PowerShell 7.2, all install packages contain a Software Bill of Materials (SBOM). The PowerShell team also produces SBOMs for modules that they own but ship independently from PowerShell.

You can find SBOM files in the following locations:

  • In PowerShell, find the SBOM at $PSHOME/_manifest/spdx_2.2/manifest.spdx.json.
  • For modules, find the SBOM in the module's folder under _manifest/spdx_2.2/manifest.spdx.json.

The creation and publishing of the SBOM is the first step to modernize Federal Government cybersecurity and enhance software supply chain security. For more information about this initiative, see the blog post Generating SBOMs with SPDX at Microsoft.

Secure data transfer in PowerShell remoting

Prior to PowerShell v7.6-preview5, a Session_Key is used to encrypt a SecureString before sending it a PowerShell remote session. The PowerShell Remoting Protocol (PSRP) performs a key exchange between client and server when a SecureString object needs to be transferred. The exchange involves the following steps:

  1. The client side generates a public/private key pair and sends the public key to the server.
  2. The server generates a session key for symmetric encryption.
  3. The server uses the public key to encrypt the session key and sends it to the client.
  4. Both the client and server use the new session key to encrypt a SecureString object.

The PowerShell Remoting Protocol (PSRP) uses the RSAEncryptionPadding.Pkcs1 algorithm during the key exchange. The algorithm is NOT secure, so the key exchange doesn't provide any extra security.

Important

You must use a secure transport layer to ensure secure data transfer over PSRP.

Beginning in PowerShell v7.6-preview5, the key exchange was deprecated. The version of PSRP was incremented to v2.4 and includes the following changes:

  • The following PSRP messages are deprecated when both client and server are v2.4 or higher:

    • PUBLIC_KEY
    • PUBLIC_KEY_REQUEST
    • ENCRYPTED_SESSION_KEY

  • The encryption and decryption steps for SecureString are skipped when both client and server are v2.4 or higher.

This change is backward compatible.

  • For old clients or servers (v2.3 or lower), the key exchange is still used when needed.
  • PSRP can use a named pipe remote sessions when both client and server are on the same machine. Since it's possible for a remote client to connect to named pipe and the data is no longer encrypted with a session key, the named pipe (used for Enter-PSHostProcess) rejects the remote client.

Security Servicing Criteria

PowerShell follows the Microsoft Security Servicing Criteria for Windows. Only security features meet the criteria for servicing.

Security features

  • System Lockdown with App Control for Business
  • Constrained language mode with App Control for Business

Defense in depth features

  • System Lockdown with AppLocker
  • Constrained language mode with AppLocker
  • Execution Policy