I wanted to take a few minutes and discuss current plans for upcoming changes in the security MP. I’d also like to use this space as an open forum for feature requests. While I’m not expecting tons of requests, it is worth noting that I do have a few criteria for any change I make.
- It needs to be something that should not generate a lot of noise when enabled. More than anything, that means I’ll need to have a unique way of identifying the issue in question. Several (not all) of my PtH rules are off by default for precisely that reason, they aren’t unique to PtH related events.
- For Operational Threats, I’d prefer to be tracking items that are currently in use or increasingly being used by the bad guys.
- Obviously, I need to stay within the limits of what the SCOM libraries can provide. Event log and registry key analysis are pretty easy. I’d note that anything that can be scripted in PowerShell should be relatively easy as well.
That said, feel free to drop a comment here for any ideas. You can also hit me up on linked in.
These are my current plans for updates:
- I want to rewrite the scheduled task rule to allow for overrides for specific applications. Unfortunately, this one is noisy as way too many commercial applications create their own scheduled tasks in task scheduler. This would allow users to override for specific applications in their environment.
- Similarly, I’d like to rewrite the service created on DC rule to do the same thing. In general, services should not be created on domain controllers fairly often, so this is worth monitoring for potential threats. However, it seems that some applications do occasionally create a service on a domain controller. This would allow a user to override for that specific service.
- I did find some false positives with local account creation, as those events can be generated on domain controllers. I didn’t see this in testing, but I did observe this at a customer recently. I’ve written in an override for the next release to turn this off on domain controllers.
- I would like to remove alerting for batch logons and put this in as a report. It’s worth noting that batch logons are very insecure, but this also is generating a lot of noise. The nice thing about a report is that you can see where these logons are occurring and update your applications accordingly…. at the very least, these machines could be segregated in your environment as to make it harder for an attacker to access the machine and steal credentials.
- I would like to write a collection rule/report for TLS 1.0 and 1.1 authentications. These too are insecure protocols and should be shut off in an organization. The idea behind this would be similar to the NTLM/LanMan/Wdigest/SMB1 reports. It should be able to tell a user where this authentication is happening in an environment so as to fix any applications that are using it and allow an organization to shut it off. I don’t know how easy this will be. My initial research (though to be fair I haven’t spent more than a few minutes looking into this) didn’t find an easy way to detect this. I’ll probably also need some beta-testers here as I doubt I have these protocols running in my lab.
Beyond that, I don’t have too much in the way of changes scheduled. I’d definitely like to hear more from the community as to what they would like to see. I think we’ve hit most of the low hanging fruit, which is good, but that also means it will take a lot more effort for additional features.
I’ve released an updated Management Pack for security monitoring.
The original landing page can be found here.
The change log can be found here.
The download can be found here.
This is a link to the download.
These are the changes in the newest release…
This management pack is now sealed. That’s probably the biggest change going forward as customizations can be stored in their own separate MP. There are also collection rules and reports setup to target legacy protocols. This should allow an organization to see where these protocols are being used in their environments.
- Fixed bug in Repeated Logon Event Rule that caused alert suppression failure in SCOM 2016
- Added filters to scheduled task creation rule for the following applications (due to noise):
- Symantec EndPoint Protection
- System Center Configuration Manager
- Intel Security DAT Reputation (McAffee tool). I didn’t find a lot of good info on it, but did confirm the tool is in use in my environment.
- Microsoft Office 15 Sync Maintenance
- Optimize Start Menu Cache Files
- Software Inventory Logging\Configuration (SCCM or WMI occasionally adds this task)
- Software Inventory Logging\Daily Collector
- Software Inventory Logging\Collection
- ReplaceOMCert (created during SCOM update).
- MRT_ERROR_HB (malicious software removal tool)
- Various Windows Update strings
- Windows Defender Verification
- Windows Defender Scan
- Added filter to Service Created on DC to filter for
- Microsoft Antimalware
- Windows Defender
- Added rules looking for PowerSploit tools.
- Added a collection rule for LAPS events.
- Added a rule looking for modification to DCs OU (4662 event).
- Added a rule looking at sedebug privileges. This is OFF by default, as this does generate noise. My understanding that this should not happen in an environment does not appear to be true. It can be useful, but this will need some tuning, and as such I’m allowing people to turn this on and tune as needed.
- Added a rule targeting generic crypto-ransomware installations. This is a 4688 event.
- Added a rule targeting the use of regsvr32 to load remote DLLs. This is a 4688 event.
- Added additional filtering to GPO Creation rule to eliminate noise. I mistakenly did not filter this one by source like I did the others, causing excessive GPO creation alerts.
- Added suppression for the batch logon in use rule. I never saw this in my lab and missed setting up suppression when I built this. That is an oversight on my part. There isn’t an ideal way to suppress this. If you suppress by computer, you only see one account per machine, and if you suppress by user, you lose visibility to the machines. I’ve setup a suppression by machine, as this is very noisy when this logon type is in use. This will allow a clear picture into which machines are using batch logon, allowing a security team to remediate.
- Updated System Log rule to specify the system log only. Apparently, when clearing operational logs, a 104 is generated in the system log for each operational log. I doubt this is a common occurrence, as clearing logs rarely happens, but this will reduce this rule to alerting only when the system log is cleared.
- Added filter to Service creation on DC for Windows Defender Update (Windows defender apparently creates a service temporarily for its updates).
- Fixed bug with Log Clearing alerts.
- Updated descriptions for a couple of monitors.
- Rewrote GPO Modification, Creation, and Deletion rules for AGPM.
- Added report and collection rules to detect the following deprecated protocols