Threat Hunting with Splunk: Part 1, Intro to Process Creation Logs

Windows event logs are, in a word, complicated. There are so many things that can be captured by Windows, it’s hard to know where to begin if you’re trying to find anomalous activity. An easy place to start would be by examining process creation logs.

What I’m hoping to convey in this series of tutorials is that threat hunting isn’t super hard, there’s just a lot of data to analyze and it’s nice to have some pointers when you’re working with these logs.

Enabling Process Creation Logs

In the Windows world, there are two ways to get process creation logs:

1. Via the ‘Security Auditing’ group policy settings, you can configure ‘Audit Process Creation’ to log successes (and failures, if that’s your thing). Process Creation events are logged to the Security log as event ID 4688
2. Via the sysinternals tool, Sysmon. Process Creation is logged as event ID 1

Key Data Fields

In the case of both the Windows audit policy as well as Sysmon logging, the process creation logs have several useful fields:

New Process Name (audit log)/Image (sysmon): This is the name of the process that has executed, including the full directory path to the executable. With this field alone, you can do frequency analysis to see if there are tools/commands being run out of unusual directories (e.g. %APPDATA%, %TEMP%, Windows\Temp, etc.). Sysmon users should be aware that on several Splunk deployments, there is an app field that is functionally identical to the Image field. If for some reason the Image field is NOT extracted, try checking for the app field instead.

Process Command Line (audit log)/CommandLine (sysmon): If the process was logged with any options or command line arguments, this field would capture it. An example where this might be interesting is watching powershell.exe executions where the -enc (encoded command) option is deployed. This allows users to pass base64 strings to Powershell and allows the Powershell process to decode then execute the strings. Attackers use this obfuscation to hide the true nature of the scripts or commands they are attempting to execute. Much like the previous field, unusual command line options you don’t see regularly will stand out if you’re grouping your hunt results by command line arguments.

Security ID/Account Name (audit log)/User (sysmon): These fields let you know who created the process in question. The audit log further breaks this down into creator and target subjects for the process in question. Knowing the user who created a given process is a crucial bit of information. For example, it would be unusual if a user from the accounting department ran netstat.exe or whoami.exe, but these commands may not be all that unusual for the network or system administrators group. Likewise, it would be highly unusual to see service accounts running anything other than the service(s) they are configured to run.

Timestamps (both): While both logs have timestamps available for events (usually, Splunk provides a field internally, _time), sysmon is awesome enough to provide UTC timestamps (via the UtcTime field. In either case, time is very important if you want to hunt for process executions that deviate outside of a given user’s working hours, or look for unusual patterns of execution (e.g. malware C2 beacons occurring at a given time interval).

If you’re fortunate enough to be getting process creation logs via Sysmon, there are a couple of additional fields that provide you even more data to drive your hunting investigations:

Hashes: This field provides you with a SHA-256 hash of executable that has run, which is a huge step up from the audit policy logs available. Imagine characterizing something unusual running in your environment almost immediately after finding it. Take the file hash you get here, head on over to VirusTotal or your favorite online threat intelligence exchange, enter the file hash, and see what results come up. Of course, there is no guarantee that you’ll get any useful results doing this, but the ability to find out if this file has been seen in the wild is invaluable to your investigations, even more so if it has been marked as malicious by another security company.

ParentImage: Almost all processes spawned have a parent/child relationship–that is, one process is responsible for spawning another process. For example, if you’re using Windows 10 and you double click a link for firefox.exe to start the Firefox web browser, the GUI–explorer.exe–was responsible for launching the child process, firefox.exe. This field tells you the name and path of the process that was responsible for launching the process being reviewed. In some cases, it’s totally normal for firefox.exe to be launched by explorer.exe. In other cases, having explorer.exe as a parent for “svchost.exe” is not normal and definitely warrants a closer look.

ParentCommandLine: The ParentCommandLine is much like the CommandLine field mentioned above, except this field shows you the arguments that were passed to the parent process that spawned the process being reviewed. Using Powershell as an example again, let’s say we are reviewing a process creation log for a new executable we haven’t seen before, and we see that its parent process is powershell.exe with the command line “powershell.exe -nop -noni -win hidden -exec bypass -enc [blob of base64 here]” that definitely looks suspicious.

Onboarding Your Logs

So far, we have described what process creation logs are and why you’d want them. Now, we are going to focus on getting them into Splunk.

As far as the audit logs are concerned, it’s really straightforward–simply follow the installation steps for installing a Universal Forwarder on your Windows server you want to collect logs from, ensure that the option to collect Security event logs is checked, and that’s pretty much all there is to it. Provided you pointed your universal forwarder to the right indexer and your search head is in good working order, the logs should show up pretty quickly.

Now, with regards to sysmon logs, it’s a little bit more complicated, but not by much. Fortunately, there’s a really awesome guide by “SmUrF3R5” that describes how to install sysmon and set it up to forward its event logs to your Splunk indexer. Alternatively, Tom Kopchak informed me that there is a github repository that will more or less automate installing Sysmon and configure the Universal Forwarder for you. Splunk also has some guidance for using Sysmon logs as well.

The only other thing that I would consider mentioning is there is now a Splunk app for Sysmon you can install on your searchhead that comes with a bunch of pre-built alerts and reports you can use right from the get-go.

More to Come in Part 2

So far we’ve covered an introduction to process creation logs in Windows, and the two primary sources they come from. We’ve also covered key data fields from the logs that you might be interested in, as well as an explanation as to how to get these logs into Splunk for further analysis. Stay tuned for Part 2, in which we go over queries you can use in Splunk for analyzing these logs further.