Enabling deep script block logging

User Rating: 2 / 5

As of the KB3000850 update and PowerShell 5.0, PowerShell has included script block logging so that admins would have more tools for the blue team side of pen testing. If you’re unfamiliar or have never heard of it before, I recommend giving this blog post a read.

Not only does the post describe what script block logging is, but it outlines two separate ways to enable it. For example, you can edit your group policy and enable the “Turn on PowerShell Script Block Logging feature” through Windows Components -> Administrative Templates -> Windows PowerShell.

Of course, this being PowerShell, the other way to enable it is a change to a registry key that can be done with a custom function or cmdlet. The blog article even goes as far as providing you with a custom function that will do just this.

What does this have to do with SAPIEN?

While the function provided will enable script block logging, it doesn’t modify the registry in the same way the policy editor does. If you make the modification using the function from the mentioned blog post, the key becomes an REG_SZ with the value of 1.

This technically will work with PowerShell, and the logs will be created as expected. The problem is, if any other application or script relies on that value to determine if logging is enabled, they must account for it being a String instead of an int or their app will crash. Which is exactly what happened recently when we were testing the new features around script block logging that were added to PrimalScript and PowerShell Studio.

With that being said, I’ve written a script that contains the same 4 functions from the blog post except they’ve been slightly modified. Each enable-function checks to see if the key exists, if it does and is of the right data type, nothing is done. If it exists and is of the wrong data type, it is removed and the correct type is added.

Manage_PSScript_Block_Logging

• Next