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)
Add the IP address of your log collection server to this GPO

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
If you have not already enabled subscriptions a warning will appear. Please read it. We want to enable the service when the computer is started, so we will press yes.
  • 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:

Here I am adding Domain Computers to my collection. This means this subscription will try and collect Powershell logs from ALL machines on my domain. You may wish to add a narrower Computer Group here to only collect for Workstations or Servers etc.

Set events to collect:

Here we tell our subscription what events to collect. We require all Event Levels from the Windows Powershell log.

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

Forwarded Events Log filled with… logs

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 against a list of suspicious commands and alarm if we spot a match.

You can find a list of dangerous commands here.

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.

The image used in this article is called "Blue Shell" and it was created by designer Ben Bely.