101 things the mainstream media doesn’t want you to know about PowerShell logging*

At .conf2016 Steve Brant and I presented on how to detect PowerShell maliciousness using Splunk [2]. The only problem is, if you didn’t attend the conference and only read the PowerPoint slides you might say something like “Your presentation is just big photos and SPL”. Which is true. Frankly, we like big fonts and we cannot lie. You other presenters may deny. That when a deck goes up with a big sans-serif font and a bright image in your eyes you get… distracted by where I am going with this paragraph. As such, we are going to create blog postings of our presentation for those of you who didn’t attend our talk in person. In this missive I shall divulge the best bang-for-your-$LOCAL_CURRENCY way to log PowerShell commands. The next blogpost will show what to do with those logs. Please note that this document assumes you already have your local Windows-TA working, you are successfully collecting Windows security event logs, and a recent-ish version of PowerShell/WindowsManagementFramework.

Before we start, please note that we stand on the shoulders of giants. Michael Gough has already done the hard work of educating the world on what to enable for Windows logs. So if you want more info after you finish this article, go off and review his contributions to the subject (http://www.HackerHurricane.com [3]) . What you will quickly learn is that Windows logging guidance is similar to ancient maps with “Thar be sea monsters” scribbled in the margins. So use this blog post as a rutter to navigate yourself through the maze of GPO logging options. And before you begin muttering about how you have PowerShell logging already enabled… I would go double-check. You most likely do not. PowerShell logging is a convoluted path fraught with missteps and GPO settings of worthlessness. *ahem* but I digress once more *ahem*.

So, what is the easiest way to find PowerShell malicious activity on your network? Configure logging for Command Line Processes. Why? Because logging CommandLineProcess is like eating melange on the Microsoft planet ArrakisXPSP3. It allows you to see exactly what PowerShell commands the adversaries are executing on your network. I should note that there are several methods of logging PowerShell but these other methods can be can be bypassed by adversaries [4]. For more info on recording and ingesting PowerShell logs go review the other awesome PowerShell presentation given at .conf2016 by Ryan Chapman and Lisa Tawfall [5].

So, how do we do enable CommandLineProcess logging? The best method is via a GPO. For those of you playing at home, I recommend having an adult (Windows Sysadmin) do this for you. They tend to be very upset when other people modify their group policy settings. Open/create a GPO and navigate to:

Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Detailed Tracking\Audit Process Creation

Once that setting is open, make sure all three boxes are clicked.

Now navigate to and click enable:

Computer Configuration\Administrative Templates\System\Audit Process Creation\Include\command line in process creation events

 Sweet! This enables logging PowerShell commands under EventID 4688.

With these settings enabled any commands run on the command line of the machine (including PowerShell). This method (unlike transcript collection aforementioned) cannot be bypassed. Every process created via the command line (for better and worse) is collected in Windows Event Viewer:

Image from https://adsecurity.org/?p=1275

However, there is a catch. This means ANYTHING that someone executes in the command line will be recorded. If a user or an Admin chose to run a script/command that includes a clear text password… this will collect it [6]. Personally… I am ok with that. I’d rather know (and promptly stamp out) any use of clear text passwords in my organization but YMMV with that opinion.

In my next blog post I’ll give some examples of SPL searches you can run to find naughty PowerShell activity and disrupt the adversary. Happy (preparation of) Hunting :-).

~~~~~~

[* 1] (that title isn’t true… its another lie) Clickbait Title Generator
http://www.contentrow.com/tools/link-bait-title-generator

[2] “Hunting the Known Unknowns: The PowerShell Edition”
https://conf.splunk.com/sessions/2016-sessions.html#search=brant&

[3] “PowerShell CheatSheet” https://static1.squarespace.com/static/552092d5e4b0661088167e5c/t/5760096ecf80a129e0b17634/1465911664070/Windows+PowerShell+Logging+Cheat+Sheet+ver+June+2016+v2.pdf

[4] Investigating PowerShell Attacks
https://www.blackhat.com/docs/us-14/materials/us-14-Kazanciyan-Investigating-Powershell-Attacks-WP.pdf

[5] “PowerShell Power Hell: Hunting for Malicious Use of PowerShell with Splunk” https://conf.splunk.com/sessions/2016-sessions.html#search=Chapman&

[6] Command Line process auditing
https://technet.microsoft.com/windows-server-docs/identity/ad-ds/manage/component-updates/command-line-process-auditing