PowerShell Logging and Security
This tutorial aims to help you get PowerShell logs from your endpoints into your SIEM to protect you from modern PowerShell abuse.
This tutorial will help you to gather PowerShell logs from Windows endpoints in the name of security. PowerShell exploits can be found in malware droppers and exploit kits all over the internet. PowerSploit, CobaltStrike, Metasploit and of course Empire to name a few. Taking the time to enable this protection is worth its weight in gold and should be considered by everyone with a windows domain small or large.
Introduction To PowerShell
PowerShell is a powerful scripting and administration language that comes baked into Windows. The bad guys are increasingly using PoweShell because by default it leaves little trace when used. The language is often abused to load malware into memory instead of writing to disk, meaning less breadcrumbs and detection opportunities for the good guys. This attack methodology is know as “Living Off The Land”
There are already some great guides out there (here and here) for PowerShell logging written by people better qualified than me but those guides seem to miss real world implementation scenarios and the issues that come with it. I hope to iron out some of those misses and give a more detailed set of instructions.
This guide assumes you are in a Windows domain and have a SIEM already setup that can accept Windows logs.
What you will need:
- Basic knowledge of Windows Group Policy
- Basic knowledge of your SIEM
- A workstation or server to act as the log collector
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)
Be sure to add a * in the Module Names section as shown below. The * (aka wildcard) tells Windows to log all PowerShell modules.
- 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)
Be sure to add the IP address of your Log Collector to the WinRM Service GPO.
This setting allows the collector server to connect to your machines and grab the PowerShell logs remotely.
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 with Windows Log Subscription mostly because it works better in my SIEM. If you don't require a Windows Log Subscription, skip to step four.
- 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 add a target for collection. I have added Domain Computers to my collection so logs are collected from all hosts. You can specify and regular group of computer accounts or groups of computer accounts.
Set the subscription to collect all PowerShell events:
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 there should be some PowerShell logs cached on your collector.
Open Event Viewer and click Forwarded Events
Now configure your SIEM to ingest the Forwarded Events log file:
“%SystemRoot%\System32\Winevt\Logs\ForwardedEvents.evtx”
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 to a list of suspicious commands and alarm if there is a match.
For example strings like net.webclient and encodedcommand are great indicators of a PowerShell drive by download.
You can find a comprehensive list of malicious commands here.
Load these into your SIEM for matching and configure alarms accordingly.
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.