Sign Scripts

PowerShell has a built-in method to cryptographically sign all scripts to ensure they are not tampered with. Signing a script adds a cryptographic hash at the bottom of the script. When an execution policy is set to RemoteSigned or AllSigned , PowerShell will not allow the script to run if it detects the code has been modified since it was last signed.

Let’s quickly cover how you would sign a PowerShell script. To do so, you must first have a certificate capable of code signing. You can either use a public certificate or a self-signed one. Let’s create a self-signed certificate for simplicity using the New-SelfSignedCertificate cmdlet.

If you open up the script you just signed, you’ll see the large signature at the bottom. Now if you run this script on a computer that has an execution policy requiring signed certificates and that computer has your generated certificates, PowerShell will execute the script.

Tip Source: https://twitter.com/brentblawat

Use Scriptblock Logging

It’s critical to know what code is being executed in your environment. Unfortunately, if you download a script from the Internet, click a malicious link or a user gets a phishing email, that code may be malicious.

By enabling scriptblock logging in your environment, you can see, down to the scriptblock level, exactly what that code is doing and developing a proper audit trail.

To enable scriptblock logging, you must first enable it at the local policy or group policy level by going to the Computer Configuration ➤ Administrative Templates ➤ Windows Components ➤ Windows PowerShell. Once there, double-click Turn on PowerShell Script Block Logging. You can see what the menu item looks like in Figure 12-1.

Once you have the Turn on PowerShell Script Block Logging box open, click Enabled and OK to confirm as shown in Figure 12-2.

Now when PowerShell executes code, you’ll begin to see events written to the Microsoft/Windows/PowerShell event log as shown in Figure 12-3.

Never Store Sensitive Information in Clear Text in Code

This should go without saying but saving passwords, private keys, API keys, or any other sensitive information in code is a bad idea. PowerShell allows you many different ways to encrypt this information and decrypt it, when necessary.

Use the Export and Import-CliXml commands to encrypt and decrypt objects with sensitive information like credentials. Use secure strings rather than plaintext strings, generate your own cryptographic keys, and more with PowerShell. There are lots of ways to encrypt and decrypt sensitive information with PowerShell.

Perhaps you need to pass a PSCredential object to a service to authenticate. Typically, you’ve been using the Get-Credential cmdlet to create this object by prompting you for a username and password. You’d now like to automate this process and authenticate without any user interaction.

You now have MySecretPassword stored in plaintext inside of the script. Don’t do this. Instead, save PSCredential object to disk encrypted using Export-CliXml.

Take a look at the credential.xml file in Figure 12-4 that you just created and you’ll see the password is encrypted.

You now have a PSCredential object stored in $credential that’s exactly the same as if you obtained it via other means. And, as an added bonus, it requires no interaction and is encrypted.

Don’t Use Invoke-Expression

Using the Invoke-Expression command can open up your code to code injection attacks. The Invoke-Expression command allows you to treat any type of string as executable code. This means that whatever expression you pass to Invoke-Expression, PowerShell will gladly execute it under whatever context it’s running in. Although executing the expression you intend works great, what happens when you open up the code to others?

You’ve got a bad day on your hands. By invoking expressions blindly and allowing PowerShell to invoke any code passed to it, you’re allowing any kind of code to run which is a terrible practice!

Use PowerShell Constrained Language Mode

If you need to allow junior users, employees in your company, or service applications the ability to run PowerShell commands, you need to ensure that access is least privilege. There’s no need to allow running commands others do not need and may accidentally or purposefully introduce security issues.

PowerShell has a mode called constrained language mode that allows you to provide access to a PowerShell environment but not allow access to all commands and modules. Constrained language mode allows you to granularly define activities as allowed and disallowed giving you tight control over what can be done.

Once a PowerShell session is in constrained language mode, PowerShell does not allow you to execute certain commands or perform certain functions. You can see in Figure 12-5 an error message PowerShell will display when you hit one of these restrictions.