Security Monitoring Future Plans (May 2019)

The good news about this project is that we’ve been able to knock out a lot of low hanging fruit that can be used to detect some of the bread crumbs that an attacker leaves behind as well as identifying where legacy protocols are being used. The bad news is that most of the low hanging fruit has been picked clean. This space will be used to help identify and track future plans.

I’m going to stick with a 1 year cadence. This has been developed mostly by me on my own time, and as such there’s only so many hours to go around. My current plans are as follows:

  • I would like to develop an administrative account monitoring component targeting admin accounts. I’m not sure how easily this will be able to be accomplished. Enumerating these against a DC is not that hard to do, but in order to alert on these, these objects would need to be created on each and every DC. This isn’t realistic from a performance standpoint. There’s currently an unhosted class and disabled discovery in this MP, but nothing is targeted against it. The hope would be to come up with a way to start tracking admin accounts in general, logons outside of business hours, etc.
  • I’m hoping to delve more into WMI monitoring with the next release.
  • There are a few rules that I could see re-writing to add overridable parameters.
  • Likely going to write some detection mechanisms around this SCOM vulnerability.

This is not a big list presently, but as time permits I hope to grow it. Any suggestions are always appreciated.

Security Monitoring Change Log May 2019

  • Updated Task Scheduler Creation Rule
  • Updated Service Creation on DC Rule
  • Disabled alert rule for Batch Logon. There is a report that is capturing this. The rule is still present and can be enabled.
  • Created override for Local Account Creation rules for domain controllers. While this didn’t appear in any testing, I was told that some security software can generate false positives for this one on domain controllers. Since DCs don’t have local accounts to begin with, I simply turned this off for domain controllers.
  • Fixed a bug with regsvr32 remote registration of DLL rule.
  • Added rules/discoveries associated with writeable locations in the OS. Note that there are three parts to this series.
  • Added rule to detect attempt to kill windows defender.
  • Added collection rule and report for TLS usage.
  • Added rules for suspicious PowerShell Usage.  For instructions on overrides, please see the addendum.
  • Removed dependency on SQL MP.
  • Added rule for WMI Persistence.
  • Added rules for WMI Remoting.
  • Distributed application
  • Added a timeout as an overridable parameter to the SMB1 collection rule. The specified timeout of 60 seconds was causing failures in my lab. I upped this value to 300 seconds as the default setting.
  • Turned off registry monitor for WDigest settings. This was not needed in Server 2012/2016. With Server 2008 going out of support, I’ve disabled the monitor. It is still present if someone desires to use it. 

Security Monitoring Distributed Application: Monitoring Audit Settings

One of the drawbacks to the current design of the Security Monitoring Management Pack that I felt needed to be improved the reliance on some pre-canned GPOs that I provided for documentation. The main issue at hand is that I have a lot more turned on in these GPOs for auditing purposes than what is actually being monitored by the management pack. This was in large part due to needing to turn on auditing settings to see what types of events are generated and mining them for useful information that is worth generating alerts. This leads to a bit of a documentation mess in that I’ll reference in my documentation for individual rules/monitors if something needs to be turned on, but that also requires a lot of reading/surfing for the management pack users, especially if they do not want to simply use the GPOs I provide… until now.

The first step was creating an audit policy monitor type to look at a server’s individual audit settings. I’ve documented that here.

With the help of Ian Smith and Kevin Justin, we were able to build out a distributed application that will allow users to see which required audit settings are set. We will also be incorporating some new views into the MP to make it easy for users to see which settings needs to be adjusted. I’ll address the new views in a future post. For now, we will cover the distributed application.

The DA will be broken down by domain (there will be a distributed application for each domain in your forest). Each domain is further broken into two separate groups: Domain Controllers and Member Servers. The reason is fairly straight forward. Domain controllers, by default, are isolated in their own OU and typically have different auditing settings configured. Member Servers are a bit more complicated, as in theory they can have different audit settings. I’ll cover this in a bit more detail in a bit.

For now, let’s look at DCs. As you can see from the screen shot below, new monitors have been created for each audit configuration setting. For domain controllers, these are on by default. It’s also worth noting that these monitors do not generate alerts. This was done to avoid unnecessary alerting. If too much state change is an issue in your environment, you may want to consider turning off any that you have no plans of fixing. The individual monitors roll up to a dependency monitor (which uses a worst of algorithm), so if any audit setting is not configured correctly on one domain controller, the dependency monitor should be yellow (see screenshot below). Since DCs are all in the same OU, I would expect to see all of your DCs either yellow or green, though I suppose if there’s an issue with GPO application, it’s possible for this not to be the case.  In the screen shot below, you’ll see that the command line process auditing setting is not set correctly on my DC, and as such, the MP is not fully monitoring domain controllers on this lab. This particular monitor, for the record, looks at a registry key, though most of these will look at auditpol.exe results.


Member servers function in a similar capacity, though there are a few caveats. Member server monitoring is OFF by default. This is because these monitors would effectively be targeted against every server in the environment. This could potentially generate a lot of state change related items in your production environment and potentially cause performance issues with SCOM, not to mention clouding up Health Explorer with a whole bunch of servers where one audit setting is not set correctly. There is one exception to this. Member server auditing is enabled by default for your management servers. This is done via override within the Security Monitoring MP. As such, when you look your member server monitoring, you’ll see data from the management servers. If your have one audit policy per domain, as most environments typically do, then you’re done. You really don’t need to configure anything else. However, if by chance you have audit settings set at the OU level and have multiple OUs per monitored servers, you may want to consider turning on these monitors for one server in each OU that has a different audit policy.  You’ll have to do this on a monitor by monitor basis, so I’d recommend creating a SCOM group containing the Windows Computer Object for a single server from each OU and enabling the monitor for that group. In a smaller environment, you could consider simply turning this on for all Windows Computer Objects, but I don’t recommend that.  Member server monitoring will look something like this out of the box:


You will see an enabled monitor for your management server, and everything else will be not monitored. If your audit policies are determined at the domain level, you’re done. This view will show you if your audit settings are set correctly for DCs and member servers. A DA will also enumerate for each domain that you are monitoring. However, if you have customized your audit settings and set them by OU, then you may want to consider additional configuration. You should ignore the not monitored domain controllers, since they are covered under the domain controllers audit settings discussed above. Unfortunately, that is present due more to how targeted classes roll up in SCOM. With that said, if you are setting audit policies at the OU level, you may find it necessary to turn on these monitors for additional servers. In the example below, I turned on one of the monitors for my SQL server:


This can be done via override. Now it’s worth noting that you should really do this for each audit setting. That can be a bit tedious, and you may find the need to add more servers as new OUs are created. My recommendation would be to create a SCOM group in your unsealed overrides MP and simply do a one time override for the group for each of these monitors. At that point, you can simply add servers to the group.

Now to the downside. The biggest issue that I see with this is the need for Agent Proxy to be turned on. I’ve mentioned in previous articles that this is some sort of security feature, though I’ve yet to see any documentation as to what it’s mitigating against. My best guess would be a compromised agent potentially being used to submit bogus discovery data, though I’m not aware of any such threats associated with this or what an attacker would gain by utilizing this. Most of my customers simply turn this on for every agent by default.  As it is, you most likely have this on for domain controllers if you use the AD Management Pack along with a number of member servers as it’s required in the SQL and SharePoint Management Packs. If this is a big deal for you, then you probably don’t want to turn on the discoveries, as that will trigger an agent proxy alert for whatever you turn on.

One other slight caveat is that I may choose to rewrite this to target Windows OS instead of Windows Computer. That’s not that big a deal, and I’ll update this article accordingly.

Security Monitoring: Audit Policy Monitoring for a SCOM Environment

One of the new features that will be added to the next release of Security Monitoring is a new Audit Policy Monitor Type. I don’t know if this is something that will beneficial to the average IT administrator, but I did make this a public monitor type so that people who do their own MP Authoring will have access to this type to create monitors for their own audit settings if they so choose. The Security Monitoring MP will use this to set a monitor state for audit settings that it requires in order to properly monitor your environment. My goal for this is to move you away from needing the specific GPO that I’ve written to capture it. This was done for a couple reasons. The first being that the generic GPO has more auditing turned on that what was needed. It was simply a best guess as to what this MP currently tracks and could potentially track down the road. The second means that it now shows you exactly what setting needs to be set.

The architecture is relatively simple. It is a PowerShell script that uses auditpol.exe to get the audit results of the server being targeted. Auditpol’s documentation can be found here. The script is relatively straight forward, taking the desired audit subcommand and parsing out the current setting (Success, Failure, Success and Failure, and No Auditing). It returns that value in a property bag that is used by the Monitor Type. On top of typical values used by the monitor type (Interval and Sync) the type adds the following input: Result. The Result input will allow you to write a monitor using this monitor type comparing the result from the property bag to what you want it to be. Here is some sample code from a monitor that uses this monitor type:

<UnitMonitor ID=”Security.Monitoring.SecurityAudit.ProcessCreationDC” Accessibility=”Public” Enabled=”true” Target=”Windows!Microsoft.Windows.Server.DC.Computer” ParentMonitorID=”Health!System.Health.ConfigurationState” Remotable=”true” Priority=”Normal” TypeID=”ALIAS!Security.Monitoring.AuditPolMonitorType” ConfirmDelivery=”false”>
          <OperationalState ID=”ResultBad” MonitorTypeStateID=”ResultBad” HealthState=”Warning” />
          <OperationalState ID=”ResultGood” MonitorTypeStateID=”ResultGood” HealthState=”Success” />

          <SubCommandAuditSetting>Process Creation</SubCommandAuditSetting>
          <Result>Success and Failure</Result>


The items in blue are the ones that relate to this monitor type. The items in red are items that Auditpol.exe will need to get the correct results. In the case of this sample the Process Creation setting (which generates 4688 events) needs to have a “Success and Failure” setting. I didn’t put a ton of logic into this, so to be fair, you’ll need to match the exact value (meaning that a value of Success only would in this case generate a state change).

As with any custom MP authoring, it goes without saying that you would need to know the Alias of the Security Monitoring MP in order to properly fill in the type ID.

Security Monitoring: Using SCOM to Detect Executables Run in Writeable OS Directories Part 3

Part 1 is located here.

Part 2 is located here.

This is a small addendum to this previous article. After letting this bake in my lab for a period of time, I did experience a small amount of noise. I’ve added a few minor exclusions to get around those issues, but this does strike me as a potential pain point for certain applications. While in general, it is not good practice to copy an executable into a custom writeable area of the OS, I suspect that some organizations will see some issues here. That said, I’ve rewritten both of these rules as custom data sources that can be overridden.

The instructions are fairly straight forward. Both rules related to monitoring writeable OS directions in the next release of Security Monitoring (current target is early 2019) will contain this override. The override will allow for an override based on a specific executable or a specific path. I would note that as it stands right now, these are looking in the same parameter, so technically, you can use these interchangeably, but it’s possible I may opt to change this at some point, so I recommend not doing so.


Security Monitoring–Using SCOM to Detect Executables Run in Writeable OS Directories Part 2

You can find part 1 here. You can find part 3 here.

***Please Read This First***

I need to preface this article by simply saying that this is the type of thing that needs to be thought through before simply turning on. This is mainly due to the fact that this next security monitoring solution could potentially create A LOT of objects in SCOM. I did have a brief chat with Kevin Holman about this to confirm my own concerns before publishing. It’s worth noting that a large number of objects isn’t necessarily a bad thing if there are no monitors attached. There are not in this case, but as a side note that also implies that we should not be targeting the classes this MP creates with monitors. That would be bad. Likewise, larger environments should be careful when rolling something like this out. The solution (in my lab) created about 20 objects per server. In a small environment of a couple hundred servers, this isn’t a big deal, but if you’re monitoring 5000 servers, you just created a hundred thousand objects. More objects can equate to performance issues as well as database bloat. Again, there are no monitors targeted at the class created, so performance impact should be minimal. That said, test this carefully in a big environment or roll it out selectively to critical assets.

***Thank you***

Now on to the solution. We discussed previously the issue that the problem with monitoring critical OS writeable directories is that they can be different for just about every OS. Fortunately, someone smarter than me already did most of the work. What I’ve basically done is to borrow a portion of Aaron Margosis’ “AaronLocker” solution for AppLocker and repurpose it as a SCOM discovery. Simply put, I’ve updated Security Monitoring to discover these file locations. To be clear, I do think that App Locker is the right answer here, though it can be bypassed (we have some detection for that), and it does take a bit of effort to get setup. But in terms of actually locking down these directories, this is the right answer. That said, this is not a solution that is on by default. You’ll need to do some configuration in SCOM as well as deploy a sysinternals tool to servers that you want to use.

Step 1 – Download AccessChk.exe and deploy it to the servers you want to monitor. For the record, I only tested copying this to the Windows\System32 directory, though I suspect it will work in any directory that has an environment variable configured.

Step 2 – You will need to turn this discovery on. I’ve made this fairly easy to do. I’ve written in a registry discovery that is on by default. It looks for a specific registry key HKLM\Software\SCOMSecurityMonitoringMP\DiscoverUserWriteableLocations. Once this key is created, a seed class will be discovered which will kick off this script. The registry discovery runs somewhat frequently, but the script based discovery is set to run once a day. I’ve made this fairly easy to do. Simply go to the “Windows Computer” view and use the Security Monitoring tasks to create the key:


The registry is protected, so I suspect you’ll need to enter credentials to create these keys. Alternatively, you could use a tool like SCCM or a GPO to do this. This is what you’ll see:


Note that if you use the Remove task, it will trigger an undiscover and effectively remove the new objects.

Step 3 – At this point, you’re largely done. I’ve set the script to use the %windir%, %ProgramFiles%, and %ProgramFiles% (x86) short cuts. This means that for a standard OS with one drive, you’re done. That said, some organizations carve out multiple disks, and as such, these short cuts don’t catch everything. I’ve built in a solution to the discovery to address this. You’ll need to locate the “Security Monitoring: Discover Writeable File Locations” discovery.


From here, you need to do an override. There’s a box called “AdditionalLocations” that can be passed into Aaron’s script. This is a comma delimited list. All I did was create an array and enter the contents with a split by a comma. I do recommend putting quotes around your path (i.e. ‘D:\program files’,’D:\Program Files(x86)’).


Now you are done. Your results should look something like this:


In order to minimize noise, I’ve done a couple other things. The rule described in part 1 of this article is disabled for all members of the seed class you defined. In place, a new rule is turned on. It’s a bit more simple, looking for the 4688 event ID, .exe in param 6, and requiring a match with the FolderPath class in parameter 6. It will look something like this:


A couple notes. I’ve built some alert suppression into both of these alerts. This will filter by the logging computer. This should prevent alert spam. You’ll only get a high repeat count in this scenario. For the rule in this part, you can override for specific objects, so if you have an app that executes in C:\windows\temp (this is bad practice by the way), you can override the specific object on the specific machine.

I’m also adding the rule described in part 1 to the forwarded events detection. If you’re forwarding 4688 events to a Windows Event Collector server, it will generate an alert.