Using SCOM to Detect Service Creation

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.

For those that cover security, this piece of information is not all that new, but for those that happen to be SCOM administrators and not necessarily security people by trade, this might be useful.

Detecting service creation is the easy part. When a service is created on a system, event ID 7045 is generated in the system log.  Note that this is not on its own a security event, and as such, you will not see anything in the security log associated with service creation.  The rule is straight forward:

So why do we care?

The answer is remote execution tools.  In order to remotely execute software on another system, tools such as PSExec will execute a payload on a remote server that starts up a service that it can communicate with.  On it own, this is not necessarily a bad thing, as IT professionals use tools like PSExec from time to time.  The problem, however, is that the bad guys use the same tools too.  Malicious malware is also known to create benign looking services on a machine that will be easily not be spotted by the untrained eye.  They use these services to allow for ease of entry and remote execution in your environment.  Detecting services specific to malware can be a bit difficult.  Some attackers are lazy and simply use the well known tools such as PSEXEC. Others write and compile their own.

Implementation can be a bit tricky. As a general rule of thumb, domain controllers are static devices. Once that server is promoted to a DC, there really should not be any new services created on it.  As such, a simple rule such as this targeted to your domain controllers should suffice.  In a typical environment, this should not generate any noise.  Member servers, on the other hand, are a bit more difficult to deal with.  Service creation can happen when an application is installed.  As such, a generic rule looking for and alerting on 7045 events can prove to be a somewhat noisy.  This will likely generate alerts, and I’ve found that when alerts are of the “false positive” variety, they start getting ignored quickly.  If you have a process in place that installs SCOM after a server is officially production, that should get around most noise caused by environmental issues, at which point the original rule will suffice.  If you have your own internal tool that creates a service on the fly, you may want to consider adding a “does not contain” expression to filter out your service as well.  You may also want to consider the alternative which modifies the 7045 to look for services tied to known attack vectors.  It would look something like this:

While I don’t have a complete list of known services associated with remote execution tools, this will detect some of the common ones.  A good attacker can get around this fairly easily, especially if they are writing their own tools, but this can provide a means of defense in depth targeting your tier 1 environment.  And I definitely recommend watching for 7045s on domain controllers.  That should not be happening on your DCs.

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.