Partager via

Potential Areas for Noise in the Security Monitoring Management Pack

  • Article

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.

Comments

  • Anonymous
    November 28, 2017
    Hi Nathan,Not sure if this is the right place to ask this. but we are getting some noise from the mp that i thing is more of a bug. Some servers from a client are reporting "Alert Parameter Replacement Failures" with the SecurityMonitoring.Event.FailedLogin rule. the issue is that the source ip could not be replaced "Source Ip Address:$Data/Params/Param[20]$I could not find anything regarding this online so it might be somemthing in my config. Hopefully you have an idea as to how I can fix this?Kind regards,Marco
    • Anonymous
      December 04, 2017
      hit me up on linked in with contact info and I can take a look. I saw some issues with that on SCOM 2016 early on, but I thought we had corrected them.