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.
I stated that a main purpose of this management pack is to keep noise volume to a minimum. As such, the bulk of the rules in place that will catch normal business activity are disabled. That said, testing has revealed some alerts that will generate in certain circumstances. For various reasons, it was decided to keep these enabled. This is a quick article to summarize the details of those alerts and what should be done.
- UseLogonCredential Registry Key does not exist. This was added to address a Wdigest vulnerability that existed in Windows OS releases from 2008 R2 and back. The vulnerability and fix are documented on Kurt Falde’s blog. A patch was released to correct the issue, but what was lesser known was that in order to activate said patch, this registry key had to be created in order to protect against it. In Server 2012 and above, the key is not needed. Any Server 2008 R2 and below system will generate an alert if this key is not present. Another monitor will alert if the key is created and value is incorrect. No recovery was built for this monitor. The reason for this is that this could break some legacy applications. While it is highly recommended that this vulnerability be addressed, it worth checking to see if WDigest is still in use for your environment before shutting this off.
- Scheduled Task was created. This is an operational event that does not necessarily mean you’ve been compromised. In an ideal world, there is a security team watching alerts from this MP and responding to them. Their job should be to verify with the person who created the scheduled task that it was in fact created. If the admin did not do this, more investigation is needed. There is some noise with this rule as some applications can create their own scheduled tasks. We’ve built exceptions into the rule for the following applications, and I suspect more will be forthcoming. If any more are identified, please post in the comments here or find me on linked in.
- Microsoft AntiMalware
- Symantec EndPoint protection (next release)
- System Center Configuration Manager (next release).
- Repeated Logon Event Detected. This one is a threat, particularly to any system exposed to the internet. There is a separate monitor with a recovery that must be enabled to update the Windows firewall to block said IP addresses, but this is best handled with the reports included in this MP. These can be handed to a firewall administrator to block these attempts at a hardware level.
- Domain/Enterprise/Schema Admin Group Changed. This too is a normal operational event, but it should be somewhat rare. Again, if used in conjunction with a good alert management process, the security team should be contacting the user who changed the membership(s) of these groups and verifying the activity.
- GPO modification. This is also a normal operational event. I’d expect to see it in an environment periodically, but it isn’t something that should happen frequently. A security team should verify with the user in question that GPOs are being modified.
- Local Admin Changes. This is another operational event, but one that should be verified, much like the others. It should not happen frequently in an environment.
- Forwarded Event alerts. These are most likely threat based alerts. The idea behind this area is to target the security logs on desktop environments for suspicious activities. These logs are forwarded to Windows Event Collectors which this management pack will monitor. The reasons will certainly vary, but the alerts with “Forwarded Events” in the name fall under these rules. This generally means the desktop in question has been compromised. This is, unfortunately, something I would expect to see in most environments. On its own, this is not a catastrophe. The desktop should be immediately pulled off the network and investigated. It will likely need to be rebuilt.