Securing your PowerShell Operational Logs

So you have actually upgraded to WMF5 and/or Win10 on your systems and have enabled script block logging (w/o invocation events as those are extremely noisy) and are getting this stuff into a SIEM and maybe you are even doing stuff like looking at Lee Holmes's methods to detect obfuscated PowerShell on your network https://www.leeholmes.com/blog/2015/11/13/detecting-obfuscated-powershell/ and https://www.leeholmes.com/blog/2016/10/22/more-detecting-obfuscated-powershell/. GREAT!!! You are way ahead of the curve of most organizations.

But then someone points out to you that hey we have an enterprise script that runs on machines and well we can't fix it right now but it has some passwords hardcoded in there and they are popping in event logs on client looking like this…

And… all users of the system can view these events.

Unfortunately unlike say the Security event log of a system the PowerShell log security descriptor does allow all users of the system to view the content in that event log. There are some situations like the above where this isn't beneficial to your organization. With Windows 10 we introduced Protected Event Logging which you can read about at https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/ which will basically use certs to encrypt the events locally on a system and allow you to unencrypt them with the private key either on the same system or say an event forwarding server where you have collected them all with a PowerShell cmdlet. There are a couple of downfalls to this though in that this does not address Win7 and also I don't know of any SIEM that would know what to do with these events without doing some interesting custom integration work to decode all of these events either at ingest time or query time.

So for a more temporary solution I would recommend locking down the security descriptor on your PowerShell event logs to be more like the Security Event log. Since the PowerShell Operational Log is an Applications and Services event channel there isn't a traditional GPO setting to control this option. The blog article at https://www.frickelsoft.net/blog/?p=267 which covers setting a custom size on these logs gives the starting point at how to go about managing settings for these types of event logs. When you browse to the registry key that controls the settings for the PowerShell operational log at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-PowerShell/Operational you can see the REG_SZ string value 'ChannelAccess' which on my system has the security descriptor in SDDL listed below:

O:BAG:SYD:(A;;0x2;;;S-1-15-2-1)(A;;0x2;;;S-1-15-3-1024-3153509613-960666767-3724611135-2725662640-12138253-543910227-1950414635-4190290187)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)

I also dumped the Security Descriptor for my Security event log as I estimate that's pretty much what I want to mirror by running wevtutil gl security which produces the following SD:

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

As you can tell the PowerShell log has quite a bit more ACE's in it including the one ending in IU = Interactive User i.e. anyone logged on the box pretty much.

I won't walk through all the steps here but basically you can use the steps at https://www.frickelsoft.net/blog/?p=267 and use Group Policy Preferences to set the ChannelAccess registry value to the same security descriptor that's used against the Security Log. From my testing this seems to have no adverse effects, PowerShell data is still logged for admins/non admins etc and still correctly viewable by Admins when viewing the event log however you are now denying access for non-admins on the system as seen below:

Thanks for your time and happy defending