PowerShell is a built-in scripting language and a command-line executor developed by Microsoft to provide a better interface for system administrators to simplify and automate administrative tasks.
PowerShell’s power makes it a useful tool for attackers for fileless attacks that are hard to prevent and detect.
PowerShell is known for having significant activity-logging capabilities, that can be used to detect and mitigate against the abuse of this tool on one hand, but can be leveraged by attackers, on the other hand. The following rule demonstrates this situation exactly.
This blog post will explain:
- What Script Block Logging was created for
- The potential vulnerability in Script Block Logging
- Countermeasures for preventing this vulnerability
- The potential impact when changing configurations
- This setting’s default value
- The recommended value for this policy
- How to change Script Block Logging configuration
This policy was created to help PowerShell users to prevent this tool from being leveraged by attackers. When enabling this setting, you’ll generate logs when script blocks are invoked.
Microsoft’s hardening guidance recommends enabling this value, in order to improve the investigation of PowerShell attack incidents. However, setting this value will allow any logged-on user (Interactive User) to read it. This can be a security flaw as it can expose passwords and other sensitive information to malicious users that intrude on the network.
This should be used only for debugging purposes, and not in normal operations.
Set this value to ‘Disabled’
Logging of PowerShell script will be prevented.
CALCOM’S RECOMMENDED VALUE:
Note: while the CIS recommends setting this rule to Disabled, STIG recommends enabling this option.
HOW TO CONFIGURE THE SECURITY EVENT LOG:
Computer Configuration >> Administrative Templates >> Windows Components >> Windows PowerShell >> “Turn on PowerShell Script Block Logging” to “Disabled”.