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”>
        <Category>ConfigurationHealth</Category>
        <OperationalStates>
          <OperationalState ID=”ResultBad” MonitorTypeStateID=”ResultBad” HealthState=”Warning” />
          <OperationalState ID=”ResultGood” MonitorTypeStateID=”ResultGood” HealthState=”Success” />
        </OperationalStates>

        <Configuration>
          <IntervalSeconds>86400</IntervalSeconds>
          <SyncTime></SyncTime>
          <SubCommandAuditSetting>Process Creation</SubCommandAuditSetting>
          <Result>Success and Failure</Result>

        </Configuration>

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.

image

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:

image

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:

image

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:

image

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.

image

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:

image

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:

image

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.

image

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)’).

image

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

image

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:

image

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.