PowerShell's Module logging

Question

I'm looking for some more information concerning the white paper which goes into some detail over PowerShell's Module logging.

Specifically, once this is enabled, are the default cmdlets logged? For example, Get-Service and so on. Looking over the About_Group_Policy_Settings for PowerShell, a reference is given to the following Group Policy path Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell where Module Logging lists an example of enabling logging for Windows PowerShell Core modules by using Microsoft.PowerShell.*

My question as it relates to InfoSec, has anyone looked into this from a defender's viewpoint? Specifically, does enabling Module logging increase the chance of exposing more attack surface and if so, are there any steps or best practices for hardening the logs and so on in an effort to mitigate the increased attack surface?

My guess would be replicate the Event Log for Windows PowerShell to a high security system or utilize encryption so that in the event an attacker discovered the Module Logging was enabled, the encryption would prevent the logs from being altered in an effort to cover the attackers tracks.

Answer 1

First, you didn't specify if this is for servers or for desktops.

But I'll assume servers for the moment. To directly address the logging aspects of PowerShell logging... Yes, it can log cmdlet calls. I believe 3.0 and above do this with the right GP settings.

Secondly, event logs aren't encrypted and ACL's to them are easily modified. So I personally suggest using a SIEM to remotely monitor them, so that you can look for some of the most important cmdlets, such as ones that deal with remoting, event log modification and anything relating to permissions and report that back to your monitoring tool so that in the event the local logs are modified by a malicious actor, you have the info back in your monitoring tool.

However, if you are truly interested in hardening against PowerShell exploits, you'll need to consider hardening PowerShell itself.

Ask yourself a few questions pertinent to your situation...

1. No matter what, upgrade to at least PowerShell 4.0. No questions on this one.

2. Do you want ANY user on the machine to run PowerShell scripts remotely? If not, disable the WinRM service and block ports 8495 and 8496.

3. Do you want ANY user to be able to execute PowerShell scripts locally? If not, rename:
   3a). C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe and powershell_ise.exe to some other name.
   3b). C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe and powershell_ise.exe to some other name.

Depending on your answers to the above, this is a good start to mount a defense. But do note, this is just one layer of many. If they have admin to the box, they can rename, re-enable everything back to default, including wiping all logs.

Depending on what SIEM you use, let's assume Splunk for the moment - you can add a source to the prefetch file for PowerShell which is generally: %systemroot%\prefetch\powershell.exe.*.pf and look for ".ps1" in the file. You can also monitor for last modified and other pertinent fields.

This is especially effective on systems which are still using PowerShell 2.0 and don't have the ability to upgrade to PowerShell 3.0 or higher to take advantage of Windows PowerShell event logs.

Answer 2

I am also interested in your question, but have you seen the following link about v5?

security advanced in powershell v.5

In addition to over-the-shoulder style transcription, PowerShell v5 and KB 3000850 introduces deep script block logging. When you enable script block logging, PowerShell records the content of all script blocks that it processes. If a script block uses dynamic code generation (i.e.: $command = "'Hello World'"; Invoke-Expression $command), PowerShell will log the invocation of this generated script block as well. This provides complete insight into the script-based activity on a system – including scripts or applications that leverage dynamic code generation in an attempt to evade detection.

As with transcription support, this deep script block logging applies to any application that hosts the PowerShell engine – the command line shell, ISE, or custom host.

To enable automatic transcription, enable the ‘Turn on PowerShell Script Block Logging’ feature in Group Policy through Windows Components -> Administrative Templates -> Windows PowerShell. For automation, the configuration settings are stored under HKLM:\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging. By default, PowerShell only logs scripts blocks the first time they are used. If you select ‘Log script block invocation start / stop events’, PowerShell also logs start and stop events for every time a script block is invoked. This latter setting can generate an extremely high volume of events, so should be enabled with caution.

Also it says:

One concern when increasing the amount of logging on a system is the danger that logged content may contain sensitive data. For example, if you log the content of every PowerShell script that was run, there is the possibility that a script may contain credentials or other sensitive data.

If an attacker later compromises a machine that has logged this data, it may provide them with additional information with which to extend their reach.

To prevent this dilemma, Windows 10 introduces Protected Event Logging. Protected Event Logging lets participating applications encrypt sensitive data as they write it to the event log. You can then decrypt and process these logs once you’ve moved them to a more secure and centralized log collector.