Using SCOM to Capture Suspicious Process Creation Events
Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.
I recently had the privilege of chatting with Greg Cottingham on the Azure Security Center Analyst Team about process creation events and how to use them to detect anomalous events that need to be investigated. It was a very interesting discussion and I was given a few real world examples of how the bad guys can move around in your networks.
To start with the basics, process creation is a fairly routine thing in the Windows world. If I execute a program, it can generate one or many processes which will remain open until the program completes. This can be audited, as a process creation will generate event 4688 in the security event log. With that said, it is disabled by default. Server 2012 R2 added an additional feature, in that with an additional GPO setting, you can audit the command line that was executed. So in short, you need to turn some things on to capture this functionality.
Before you run and do that though, you probably should review your environment. This will generate a lot of security events. If you have tools such as ArcSight, Splunk, OMS, or SCOM collecting these events, you’d be wise to do this incrementally to ensure that you aren’t overloading these tools, and I’d add that if you don’t have a plan in place to review and respond to what you find, then you should think about that before you start turning on auditing that won’t be looked at. The other problem is that by turning on command line auditing, anyone that can read security events could read the contents, and potentially read something sensitive. So please, think this through carefully. A full write up on TechNet can be found here.
Turning this on is fairly easy. A simple GPO will suffice. Instructions are here. In my lab, this was quite easy:
Enabling command line:
Within minutes of doing this, 4688 events start showing up in various event logs.
Next up, we need to determine what to look for. These events contain a couple of useful parameter. The full list can be seen in this screenshot:
Parameter 6 (New Process Name) and Parameter 9 (Command Line) will generally contain the items worth triggering on, but we can use SCOM to report or filter out on other things such as the user name (parameter 2). Again, we don’t want to simply alert on 4688 events, as that will generate significant amounts of noise, but we can target this to specific events that should be investigated every time. Here are some examples:
Applocker Bypass – an intruder uses javascript or regsvr32 to work around applocker rules
Command line FTP – an attacker uses command line to download an execute a payload.
Manipulating the PowerShell Window position – an attacker executes a powershell command, but manipulates the window position as such so that the logged on user cannot see it.
Command Execution in Folders with no executables – this folder list could be long when you think about it, but these are common destinations.
Manipulation of run key – an attacker adds a line to start a process at startup. I’d note this is an example where you may need to add some “does not contain” options so as to avoid alerting for legitimate events.
Happy hunting.
I’m working on a management pack that contains these monitors along with additional security rules along with other security related items that SCOM can provide. My only test environment is my lab, which is hardly a production grade environment. I do welcome feedback. While I can only support this to the best of my ability, I can provide it if this is something you are interested in trying it out. My main goal is to keep the noise down to a minimum so that each alert is actionable. While that is not always easy to do, trying this out in other environments will go along way to getting it to that point. If this is something you are interested in testing, please hit me up on linked in or have your TAM reach out to me internally.