This tutorial aims to help you get PowerShell logs from your endpoints into your SIEM to protect you from modern PowerShell abuse. It does not matter if you're a small shop or a huge multi-national, you should have PowerShell logging enabled and doing so will protect you from a myriad of threats like Emotet and PowerSploit.
Introduction To PowerShell
PowerShell is a powerful scripting and administration language that comes baked into Windows. By default PowerShell leaves little trace of its activity which makes it an attractive utility for bad actors, bad guys enjoy abusing PowerShells powers because they have to drop less code onto your machine leaving less breadcrumbs and detection opportunities, this methodology is know as “Live Off The Land”
There are already some great guides out there (here and here) for this kind of PowerShell logging and protection, written by people better qualified than me. However this article fills in the gaps we found during implementation, the other guides I have read so far miss those small details that are so critical to getting this protection setup right.
This guide assumes you are in a Windows domain environment and looking to push your PowerShell logs into a SIEM for retention and threat response.
What you will need:
- Basic knowledge of Windows Group Policy
- Basic knowledge of your SIEM tool
- A workstation or server to act as the “collector” or “log cache”
Step 1 — Group Policies
For this protection to work we need to enable some Group Policies:
- Computer Configuration > Policies > Administrative Templates > Windows Components > Powershell > Turn on Module Logging (Tells Windows to log Powershell activity to disk)
- Computer Configuration > Policies > Administrative Templates > Windows Components > Powershell > Turn on PowerShell Script Block Logging (Makes the above logs more verbose)
- Computer Configuration > Policies > Administrative Templates > Windows Components/Windows Remote Management (WinRM)/WinRM Service (Allows remote collection of the above Powershell logs we just created)
Apply all of these group policies to a OU of your choosing for testing.
Step 2 — Log Collector
Some folks like to use their SIEM to collect logs directly from endpoints. I prefer to cache workstation logs on a “Collection Server”, mostly because it works better in my SIEM. This section of the guide will explain how to setup this “Collection Server” If you don’t require this skip to step 4 where we will list what commands you should alerting on.
- On the server you have for log collection, open Event Manager and then click Subscriptions
- Next we need to configure our log subscription. Click Create Subscription on the right side of the Event Viewer window:
Fill in subscription name and target for collection:
Set events to collect:
Checkpoint — Have you completed these tasks?
-Enabled and applied TWO Powershell GPOs
-Enabled and applied WINRM Service GPO
-Created your Event Log Subscription and added Powershell to it
If you have passed the above checklist, its time to check for events. Make sure your new GPOs are applied to a test OU and then fire up the event viewer on your log collection server. Open the Forwarded Events log
Now configure your SIEM to ingest the Forwarded Events log file
Step 4 -What to alarm on
Now that your Powershell logs are being ingested we need to build some alarms to detect malicious activity. We should use our SIEM to compare the Powershell logs against a list of suspicious commands and alarm if we spot a match.
This list will help you detect a lot of modern Powershell exploit techniques and tools. I hope you found this guide helpful, if you do have any more questions or suggestions please reach out to me on Twitter using @Secprentice.