Security Monitoring: Updating Local Account Monitoring for GPO Enforced Settings

It was brought to my attention that the local admin group monitoring rule that I’ve written becomes incredibly noisy if GPO enforcement is used on local admin groups. Essentially what happens in that situation is that every time a machine applies the GPO, it fires off the 4732 and 4733 events that are being monitored. This can lead to thousands of alerts in this scenario. As such, I’ve re-written the rule, but I’d note that it gets a bit tricky. The main issue revolves around how SCOM processes events. It’s worth noting that SCOM only processes the XML, so using the friendly names won’t work. I’ve attached a couple of examples from my lab to show the difference.

This first screenshot is the friendly view. As you can see, it’s pretty straight forward. I used my admin account in this case to add a test account to the local administrator group on my SCOM server.


The XML view shows something completely different.


As you can see from the screenshots, for whatever reason, the SID is recorded in the XML view. I looked into a couple different ways to reduce noise for this; but unfortunately, the only workable solution would be to filter the rule based on the user IDs being recorded in the event, and since these are SIDS, we will need to obtain the SIDs from either ADSI Edit or from the Attribute Editor in Active Directory Users and Computers. I’ve baked 5 SID based overrides into this rule, which should hopefully be enough. It looks like this if you need to override it:


The easiest method to obtain the SID of the account(s) in question is to use the Attribute Editor in Active Directory Users and Computers. This requires advanced features to be turned on (this is in the view menu, and there should be a check box next to advanced features if it’s enabled).

It will look like this:


Please note for any bugs and/or feature requests, please reach out to me on LinkedIn.

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–Additional PowerShell Detections Addendum

This is a follow up article to this piece that I wrote in early September. Not surprisingly, there was some noise in my initial lab tests. Two rules in particular were noisy, and the chief culprit happened to be SCOM. The rule governing PowerShell running in memory only  as well as the rule to bypass execution policy. When you think about it, both make sense to some extent, and that’s part of the reason why these features are built in to PowerShell.

If SCOM could not bypass execution policy, for instance, none of its script based data sources could execute if users set their execution policies wrong. As such, I decided to do a minor rewrite of all of the rules to allow for two overridable path based exclusions as I suspect specific applications could generate some noise. I know that SCOM uses a lot of PowerShell scripts. I believe that Exchange does as well. This also allows someone to do an override for a specific object, a group, for for an entire class. I may revisit this to add more, but I that most of our applications keep these items in specific folders, so there shouldn’t need to be any changes there.  I’ll also use this data source for any PowerShell detection I write in the future that may need to be overridden.

I’ve also created similar rules targeted at Windows Event Collector servers. To me, this is probably a bigger thing. It shouldn’t be terribly noisy, as this type of behavior in the desktop environment strikes me as something that should be more rare, but perhaps I’m wrong. As such, there’s nothing overridable in that environment for now.

To override for a specific path, do the following:

  • Identify the rule and the type of override you wish to do (i.e. group, all objects, specific object, etc).
  • Configure the path based override as follows:


Security Monitoring–Using SCOM to Detect Legacy TLS Protocol Usage

This has been on my bucket list for a while now, and I finally got around to figuring it out. TLS is a transport layer protocol that is effectively a part of SSL. Basically, it’s used to encrypt web based traffic so that prying eyes cannot see. Like every protocol, over time its weaknesses are exposed and newer versions are released. Like every protocol, the older versions remain on given that legacy applications can break. Last year, Microsoft started releasing updates to their applications to eliminate TLS 1.0 and 1.1 from usage, and it’s officially recommended that these protocols be shut off with only TLS 1.2 being used.

I spent some time trying to figure out how to audit legacy TLS usage and found that to be an incredibly frustrating search. There’s not much out there on auditing TLS. The answer, as it usually is, was right in front of me from a Kevin Holman article on how to force SCOM to use TLS 1.2. As such, I’ve setup a collection rule to collect these events. That said, this is not plug and play. Before I get into the details, it’s worth noting that event collection rules can generate lots of data in your DataWarehouse. In my own lab, I’m seeing about 600 events a day across 2 systems. So just imagine for a second what that might look like with thousands of systems. You may want to consider turning this on in small quantities (and turning it off once you have the data you need).

Step 1 – Enable Schannel Logging. Kevin covered the details of how to do this in his post. I simply created a GPO and linked it at the domain, though you may want to link to specific OUs instead. In my case, I set a GPO preference to change the following registry key: HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging

This is a REG_DWORD value that needs to be set to 7.

Step 2 – wait a day and run the report. It should look like this:


Security Monitoring–Additional PowerShell Detections

Note that there is an addendum to this piece for override purposes. That can be found here.

A colleague of mine turned me on to this particular article on ways to use PowerShell to bypass execution policies. It’s worth noting that PowerShell is a powerful tool that was designed to give a lot of flexibility to IT professionals and developers. That said, this type of a tool can also be leveraged by the bad guys. As such, it makes sense to target certain types of behaviors that are not very common under normal circumstance, but can see elevated usages by threat actors when they are moving through your environments. I’ve added four rules to the next version of Security Monitoring to alert on suspicious behavior. Three are (at least after initial rounds of testing) on by default. The fourth is off and if noise is a problem, will likely need to remain off.  I would also note that I wouldn’t be surprised if more of these ends up being turned off. PowerShell is used on the back end by a number of applications, and as such, I wouldn’t be surprised to see some of this being done as normal behavior or via design in heavily scripted environment. In that case, you may need to turn these off altogether or simply override for particular machines. This can, however, provide a nice defense in depth posture. It will also help the IA folks reviewing these alerts see what is actually going on in production and decide if these practices should be rethought.

First, as goes without saying, you need Process creation auditing turned on as well as the GPO setting to include command line parameters in audit events set. If you’re already following me or using this solution, you’ve probably already done this. For record, I do keep a public version of the GPOs I’m using here. These are simply auditing GPOs applied at the domain level. But it’s worth emphasizing that a lot of the detection that has been built into this tool requires this auditing to be turned on.

Rule 1: PowerShell script run natively to bypass existing execution policy

In this particular rule, we’re looking for PowerShell scripts being run with a specific execution policy switch. This allows scripts to run regardless of execution policy settings.  This can be by design in a user environment, so simply seeing this doesn’t mean that much. That said, I’m tracking 4688 events that are generated by ‘powershell.exe’ with the –ExecutionPolicy switch set to either bypass or unrestricted. This is also something that could generate noise. SCOM is an offender here, and it’s default install path is excluded for noise reduction purposes.

Rule 2: PowerShell used to Invoke a Remote Expression

I would hope that this is not used with much frequency in a typical environment. Effectively, PowerShell can be leveraged to run remote code. Threat actors love this, as they can effectively use their scripts to connect to an http/https share they have online and execute their custom malware. The best part is they can run this in memory only, making it even harder for AV scanners to detect them. Again, we are looking for 4688 events generated by PowerShell. I’m looking for the “Downloadstring” method and an http or https pattern in the command line.  I wouldn’t expect to see this one happen often, so for now, it’s on.

Rule 3: PowerShell used to Invoke an Encoded Command

This is another one that I wouldn’t expect to see run that frequently. Basically, you can convert any text to a base 64 encoded string. This again can be normal, as it gets around formatting issues that can plague script writers or people like me who aren’t PowerShell experts. With that said, however, the bad guys can use this to hide what they are doing from security software, AV, or security analysts. As such, this rule will generate an alert whenever PowerShell is run with the –ENC or –EncodedCommand switches. Like the remote expression rule above, I don’t see this as something that will happen a lot, but it’s possible that this is legitimate.

Rule 4:  PowerShell Running Only in Memory

Simply put, this is a PowerShell script runs in memory instead of on disk. It’s run using the –NoProfile or –Nop switches. I suspect that this is something that could generate noise. In testing, SCOM was a big one here, which makes sense as MPs run PowerShell scripts. I would not be surprised if other applications such as Exchange generate noise here too.

As always, if you want to test this, reach out to me on Linked In.

Security Monitoring–Configuring SCOM to alert on attempts to kill Windows Defender

This is just a quick update to the next revision of Security Monitoring. If you don’t use Windows Defender, this will not generate any alerts, and in general it should be quiet even if you do use Window Defender.  This will only work if you have the audit process creation GPO set. I’d also note, that you need to have command line auditing turned on as well. I’ve referenced that in other places, but here’s a screenshot if you’re unsure:


If these are set, there is now a new rule that will look for 4688 events with various kill switches meant to stop that process. This alert will also be available if you’re using Windows Event Collectors.