Using SCOM to Capture Registering Remotely Located DLL Files

I’ve started browsing some sites that are cataloguing known attack vectors and came across this particular vulnerability that is worth discussing.  Many seasoned IT pros understand the use of RegSvr32 to register DLL files.  This executable is very integral to Windows as registers DLLs for OS and application use.  A little known flaw is that it can be used to load DLL files that are not contained on the server itself, thus bypassing antivirus detection. We’ve already built one rule set based off this flaw for a known attack method which is documented here. In this particular case, we are looking for a method to bypass AppLocker.  The attacker loads a DL file called scrobj.dll from a remote location.  While this is beneficial in detecting a known attack, this attack method can easily be altered as names of DLL files can be changed on recompile.

That said, the method is not quite as easy to adjust.  The attacker must use a URL allowing us to create a rule set in SCOM to audit process creation looking for that specific in formation.  The criterion is fairly straight forward:

  • Event ID = 4688
  • Parameter 9 contains either of these strings:
    • /s /n /u /i:http://
    • /s /n /u /i:https://

For the purpose of this rule, I’m not continuing to filter by regsvr32.  That keeps me out of playing around with case sensitivity when matching a pattern.  The switches and URL call should match.

A more thorough explanation of what is going on with this method of attack can be found at this location.

I would note that while Antivirus cannot catch this method, EMET is a mitigation for it.  If EMET is not configured for your environment though, this rule set targeted towards Windows Servers and EventCollectors should work if you have them enabled.

With that said, I’m testing this in my lab presently and plan on including it in the next release of the Security Monitoring Management Pack. I’m not expecting much in terms of noise, but if by chance you have a legitimate application that is using this method, you can use choose to add a Parameter 9 ‘does not contain’ <insert name of DLL here> to the and portion of this rule.  That will eliminate any noise associated with known applications.

Security Monitoring MP: Powershell Exploit Toolkit Rules

In this post we will discuss using SCOM to detect various PowerShell Exploits that are commercially available for download and use.  I’d note that there are limits to this type of detection activity. First, it is worth noting that good attackers don’t use commercially off the shelf attack tools but instead recompile them to suite their needs.  That makes it very difficult to detect, and any detection activity would require having access to the attackers tools (at which point, they will update them to bypass your detection).  There is some value to this from the standpoint that it increases their costs and time effort, which at some point will encourage them to find a different victim, but these detections are not something that one can rest on and say “I’m secure.”  That said, some attackers have been known to use these tools, as it requires little or no effort to get up and running.  As such, I’m building these into the Security Management Pack, as most have very little practical use in an environment.

All of these will be included in the Security Monitoring MP.  Two rule sets will be created.  One will target the Windows PowerShell log on Windows Servers.  The other will target the Forwarded Events log on the Windows Event Forwarders.  All of this requires PowerShell logging to be enabled on servers and desktops.  With desktops, those log items will need to be forwarded to the Event Collector Servers. 

  • Security Monitoring:  Invoke-Shellcode is in use – used to inject payload into an existing process and execute it.
  • Security Monitoring:  Invoke-DllInjection is in use – used to inject a DLL file into an existing process.
  • Security Monitoring:  Find-AVSignature is in use – used to split a file into multiple smaller files to determine the location of the signature that antivirus is detecting.
  • Security Monitoring:  Get-DllLoadPath is in use – Used in conjunction with Invoke-DLLInjection.  It finds the path of the DLL that an application is using.
  • Security Monitoring:  Invoke-PortScan is in use – Used to scan open ports on servers.
  • Security Monitoring:  Get-HTTPStatus is in use – Used to dictionary a web service to find status of a specific HTTP or HTTPS path.
  • Security Monitoring:  Invoke-Mimikatz is in use – this is a PowerShell version of mimikatz that sits in memory and is undetectable by AV.
  • Security Monitoring:  Get-Keystrokes is in use – this is a PowerShell key logger.
  • Security Monitoring:  Invoke-NinjaCopy is in use – this is used to make a copy of the SAM while it is in use. Said copy can be then brute forced for the secrets it stores.

Of these rules, only Invoke-Mimikatz was checked in the first release.  The rest will be in the next release.  There is not much special to these rules.  PowerShell logging generates an event ID of 800 in the Windows PowerShell log with the command that was run.  All of our rules key in on that event ID and the specific command in the Event Description.  If these tools are in use in your environment, you should get visibility.  While I don’t believe that this will be beneficial against an advanced threat, this will catch some nefarious activity if the attackers are using commercially available tools.

Security Monitoring MP AppLocker Rules

I’ll be honest in that these are included because they are easy to do, but in reality, they do not provide much in terms of protection. Traditional anti-virus works to detect many of these tools, and while an attacker can corrupt AV pretty easily, it’s also just as easy to recompile these tools so that they leave a different signature that a typical AV/malware detector cannot find. I’ve added this as a courtesy, but if that is all that is being used in this management pack, then it is not accomplishing anything.

These rules are only going to work if you have AppLocker GPOs in place to audit your environment.  I’ve provided a custom GPO I’ve written to audit the use of a few known hacking tools.  As a caveat, it is worth noting that many of these tools can be used internally for various reasons.  This isn’t to say that each alert generated by one of these tools in necessarily proof that your environment is compromised.  It is, however, something that should be investigated.  Each rule is fairly straight forward.  It is looking for event ID 8003 with an EventDescription containing the software package in question.  These events are found in the Microsoft > Windows > Applocker > EXE and DLL log.

I will also note that sophisticated attackers can get around a lot of these rules.  If they recompile the executable (or you choose not to continuously update the AppLocker GPO with the latest hashes), it essentially renders this check relatively useless.  I have individual rules for each of the tools we are checking for, but those are disabled by default.  The reason for this is that it’s very easy to bypass this check by simply renaming the executable.  As such, the only rule enabled for this section is the “Prohibited app in use” check which does not discriminate based on tool (the info is in the event description of the alert).  You’re welcome to enable the individual rules, but I suspect they won’t do much good.

One more caveat on WinRAR.  For those who are unaware, it’s a compression tool (think WinZip).   I created a rule to check for it, but I did not add it to my GPO.  I did this for good reason.  It happens to be a very useful and legitimate tool, and it is somewhat prolific in normal user environments.  If you don’t use this in your environment, I’d recommend updating the AppLocker GPO to audit its use as the bad guys seem to love this tool for whatever reason.  But by default, WinRAR use will not generate alerts, as I suspect it would generate more noise than good, but if this tool is not in use in your organization, then it would be wise to track it as for whatever reason, the bad guys like it too.

Alert flood detection is NOT enabled for these rules.  The point is that each time an alert is generated by these tools, it should be investigated.  I cannot emphasize enough that good alert management process is the key to making this MP work in any capacity.

Most of these alerts are targeted towards Windows Computer.  I know that’s not always good practice, but I did this in case you’re using SCOM to monitor desktops as well.  Intrusions typically start at the desktop level, so if you’re monitoring them (which most organizations don’t), you may as well get this information.

Also of note, my AppLocker GPO is using a hash value of these tools.  This means that when there’s a new release of said tool, that the GPO needs to be updated.  While I’ll try and update this periodically, do not assume that this is the case.  The following rules are included in this management pack:

Rule Name:  Prohibited App in use.

  • Enabled by default.
  • Scoped to Windows Computer.
  • Does a check for event ID 8003 in the AppLocker log and generates an alert.  If you’re using Applocker already, SCOM will now tell you when any audited application enforcement is generated.

Rule Name:  PSEXEC in Use

  • Disabled by default.
  • This is scoped to Windows computers (with the exception of IT uses, this should not be any desktop).
  • PSExec is a remote execution command line tool.  It is used within IT organizations for legitimate purposes.
  • If this rule is generating excessive noise due to legitimate use, it would be wise concentrate this tool on administrative workstations and override the rule for those workstations.

Rule Name:  Mimikatz in Use

  • Disabled by default.
  • This is scoped to Windows Computers.
  • Mimikatz is a credential theft tool used to perform pass the hash attacks.  It should not be in a production environment.

Rule Name:  WinRAR in Use.

  • Disabled by default.
  • This is scoped to Windows Server Operating System.  I didn’t see the point in scoping to all operating systems as it will be in a desktop environment.
  • This is a harmless tool that has good use.  It’s Shareware and used for compression.

Rule Name:  WinCE in Use

  • Disabled by default.
  • This is scoped to Windows Computers.
  • WCE is a hacking tool used to perform pass the hash attacks and enumerate wdigest passwords.  There is little reason for this tool to be in a production environment other than to test your alert management process and perform network penetration testing. 

Security Monitoring Management Pack Summary

I’m rewriting the main page for the Security Monitoring MP to be a bit less cluttered.  I will be using this space to document this management pack with a simple link off from there.  I’ll also use this space to document the change log.  As a reminder, this is more than just an import and done solution.  It is designed to augment best practices and there are plenty of pre and post configuration tasks needed.  This solution will not work if your organization’s security posture is poor. It is meant to work with a good security posture.

May 2018 Release

May 2018 Release

Initial Release May 2017

Dependencies:

Discoveries:

  • WEF Collector server discovery.  This allows for targeted rules to mine the forwarded event logs on event collectors for companies using Windows Event Forwarding.

Rule Sets:

  • App Locker rules (requires GPO for applocker rules).
  • Domain Admin, Enterprise Admin, and Schema Admin Group change monitoring (requires GPO to turn on additional auditing).
  • Pass the hash, overpass the hash, and pass the ticket detection.  I’ve created three rules, and I have enabled one of them.
    • Potential Credential Swap in Progress: Enabled and targeted at all Windows Operating Systems.  This only activates in my lab when using mimikatz to swap credentials.
    • Potential PtH in progress against tier 1:  Disabled and targeted at all Windows Operating Systems.  This also has an override for domain controllers and SQL servers as it is very noisy otherwise.  If you turn it on, you will probably want to have additional overrides against it (particularly IP address filtering).
    • Potential PtH in progress against Domain Controllers:  Disabled and targeted at all Windows Domain Controllers.  Consider enabling using IP address filtering for your environment.
  • Detect clearing of security event logs (event ID 1102) and system event log (event ID 104).
  • Detect the creation of a service on a domain controller (event ID 7045 in the system log).  I’ve also created and disabled this same rule targeting windows operating systems. This one would generate some noise under normal conditions, and as such, I’ve left it off. 
  • Detect the creation of services tied to known remote execution tools (event ID 7045)
    • PSEXECSVC
    • WINEXE
    • WCESERVICE
  • Local account created on a member server (event ID 4720 in security log).  Requires GPO.
  • Local Admin Group modified on member server (event ID 4732 and 4733).  Requires GPO.
  • Lynne Taggart’s Smart Card change monitor.  I would note that this enabled by default and targeted only to domain controllers.  There are a few differences here. Lynne’s monitor will reset when the next event is detected where someone enables a smart card. Truthfully, this shouldn’t happen much in an environment, but I’m switching this to a rule so that you will see alerts each time a smart card is disabled for interactive logon. 
  • Modified Andres Naranjo’s composite module to track GPO changes.  My modifications are noted below.
  • Rules sets for known threats that can be detected off of 4688 events.
  • Scheduled task creation.  (note that the task scheduler operational log needs to be enabled).
  • Golden Ticket detection (note this requires periodic reset of krgtgt account).
  • Disabled rule sets (these are off by default.  I don’t recommend turning them on without some thought and planning).
    • System shut down unexpectedly
    • System was rebooted
    • Software was installed on a server
    • Software was removed from a server
    • System was powered off.

Monitors:

  • Registry Monitor to detect change of UseLogonCredential registry key (for certain Wdigest attacks).  I’m not setting a GPO here because turning this on can break some legacy applications. Note that by disabling the monitor to ignore the noise, you are in essence allowing an attacker to mine clear text passwords out of the LSA.  On the other end, an attacker can potentially set this registry key to a different value to allow them to do it. This monitor would alert you to that possibility.
  • Registry Monitor to detect the existence of UseLogonCredential registry key.  No key (default setting) allows for exposure of Wdigest credentials in older Windows OS versions.  This is disabled for Server 2012 and Server 2016.  The key does not exist for these Operating Systems but is assumed to be set. I’m still monitoring in case it is set and set to a different value, but this will reduce noise specific to these OS versions.
  • Kevin Holman’s failed RDP attempts monitor.  I’ve made some changes to this worth noting:
    • The recovery is disabled by default.  I’d note that the monitor only looks for rapid succession of logon attempts and at the 5th attempt, the recovery will update the firewall to block that IP.  It is, in theory, possible for it to block a legitimate IP if by chance the 5th attempt comes from something legitimate. I don’t see that happening hardly at all, as it would be a highly improbable event, but worth noting.
    • The alert generation from this is also disabled.
    • The reason for disabling the alert is that Brad Watts wrote a module that collects and consolidates 4625 events by the IP address and will generate an alert in that capacity.  You should get an alert for each IP address doing this, allowing you to pass this on to a firewall team to block it at a hardware level or use Kevin’s recovery if the Windows firewall is in use.
    • Reports targeting this solution have also been added so that you can see a reports for failed logon and the IP addresses they are coming from.  While most attackers prefer targeted phishing, this is still useful for those that prefer to kick down the doors the old fashioned way.
  • System pending restart monitor (disabled by default).
  • Service monitor for windows event collector service (there’s also a recovery here to restart it).

Event Collection (WEF) Monitoring:

Configuration information is here.  These rules target the Forwarded events logs. It is generally recommended that desktops in particular have events forwarded to event collector servers. A SCOM agent can then be placed on the event collectors to monitor the forwarded event logs.  This will only work if the event collectors are collecting the events specified in this section.  I recommend forwarding security events, power shell logging events, Applocker events 8003 or 8004, as well as system event 7045.  This link contains what you need to know about Windows Event Forwarding.  Additional WEF links are here.  Note that most of these rules are configured for Alert Suppression based on logging computer.

  • Security log cleared (event ID 1102)
  • Powersploit use (note this still requires powershell logging. It also requires forwarding these to the event collectors.)
  • Special Logon in use.  Event ID 4964 detection.  This will generate no noise by default unless you are actively attempting to determine account usage for defined special groups.  More info on this particular event ID can be found here.
  • Detect Creation of new service:  This is disabled by default as it would generate noise in most environments.  Consider enabling in an environment where this would not be noisy.
  • Event ID 4732 or 4733 detection – A user added or removed from local admin group.
  • Detect the creation of services tied to remote execution tools (event ID 7045)
    • PSEXECSVC
    • WINEXE
    • WCESERVICE
  • Pass the Hash Detection
    • Potential Credential Swap in Progress
    • Potential PtH Attack in Progress Against Tier 2 – Note this is disabled by default since I’m unable to filter the local host name.  This may generate unwanted noise if turned on.
  • Prohibited App in Use – Event ID 8003 from Applocker
  • 4688 detections.

Should you choose to add additional event forwarding rules, please keep this article in mind.  They will not work out of the box unless the allow proxying tag is set in XML.

Views:

Intrusion Detection Alert View – keys in the value “Security Monitoring” in name of all alerts.  All rules also have this value in custom field 10.

Threat Hunting Alert View – keys in on the value “Security Monitoring Threat Hunting” name in alerts targeted towards detecting practices in need of mitigation.

Event Collector Alert View – Displays alerts for items found in the Forwarded Events log.

Event Collector State View – I only have one health monitor for event collectors and a recovery attached, so if there’s any red here, they aren’t working.

Threat Hunting:

The purpose of this section is to help you find vulnerabilities in your environment that can be addressed.  Note that this is something that can be a bit noisy.  I have event collection rules defined for these particular events which we can use reports to collect. I’ve also got alert generating rules defined for these events if you want to respond to alerts.  Alerts that are potentially noisy, I’ve disabled by default and I recommend that you use SCOM reporting to view this information.

  • Performance Collection:
    • Event ID 4964
    • Event ID 4624 logon type 4.  This type of logon leaves credentials exposed in the LSA.
    • Event ID 4672 (disabled by default.  This can generate a lot of events that could cause issues with the DW).
  • Event ID 4769 result 0x1F.  This can be potentially used in a recovery to detect golden tickets in use in the environment, though to do so, the Kerberos password will need to be reset twice.  That said, this is a rare event and worth investigating. This will generate alerts.
  • Event ID 4964 detection.  This will generate no noise by default unless you are actively attempting to determine account usage for defined special groups.  More info on this particular event ID can be found here.

Post Configuration Tasks for the Security Monitoring Management Pack

As I have mentioned in the initial posts, using the security monitoring management pack is going to require certain practices in procedures be in place.  Simply importing the management pack will not give you a picture of everything that it is designed to monitor.  Ultimately, this management pack serves two purposes.  The first is to detect certain anomalous events allowing a security team to respond to them.  It certainly will not capture everything, but it does capture a lot of events that should be investigated immediately.  The second is that it provides an organization a means to augment security best practices.  This can provide a means of check and balances so to speak that security and change management teams may care about.  If someone changes a GPO, we will tell you.  If someone adds a user to the domain admins group, we will tell you.  These are not necessarily bad things, but they are things that should happen rarely and can then be confirmed by an independent team.  This allows an organization to get a better picture of the real business process in their organization versus what they think it is.

In some cases, I’ve already posted articles on this, and as such, I’ll link to them, but for the purpose of this article, I want to discuss what businesses should be doing if they expect to have some of the functionality that is designed into this MP.

Review Auditing Settings.

These are covered in this article. It’s worth reviewing to ensure you have all auditing settings properly set.


Consider deploying accesschk.exe to be used to enumerate writeable OS locations on critical systems:

I have a write up on how this works here. Consider reviewing all parts. This does create a decent number of objects per OS instance, but there are no monitors attached to these objects.

Special Group Logon Configuration:

Jessica Payne wrote a nice article on configuring active directory to audit special group logon.  The how and why are covered in detail there, and I strongly recommend that this be implemented for the types of accounts she lists in the article (key service accounts, domain admins, etc.).  What this does is generate a 4964 event when a designated account is used.  If special group logon is not configured, 4964 events will never be recorded, which will effectively make this a useless check.  By configuring special group monitoring, SCOM will generate an alert each time one of these accounts is used. There are two alert generating rules in place for this.  One targets the forwarded events log, which if generated essentially means that these accounts are being used to sign on in a tier 2 environment, which is a terrible practice, making you ripe for easy credential theft.  The second target is watching for this event in the tier 1 and tier 0 environments.  To some extent, there could be noise here as a domain admin will occasional have a need to sign on to a domain controller, but this should be relatively rare if good security practices are in place.  That said, it will allow a security team to verify with the particular admin that they were using their account, as opposed to someone stealing that accounts credentials.  With this particular check there is also an event collection rule in place, as these events are not common.  In a later revision, we hope to add a report off of this event.

KrbTgt Password Reset:

One of the features of the new Active Directory Domain Services MP is that if you configure client monitoring, it will generate an alert telling you when the last KrbTgt password reset occurred, which for most organizations was when they upgraded their AD domain level to Server 2008.  This is essential to detecting and preventing an attacker from using golden tickets.  I’ve already written on this particular subject, and it is probably worth reading if you are not familiar with golden tickets. In general, resetting this password should not be a problem. Issues arise from resetting this password when Active Directory replication is not functioning properly, but if you are resetting this on a 90 day cycle consistent with service account passwords, this risk is mitigated.  The double reset that was described in my original article is a bit more daunting of a task.  If you do not follow this practice, this rule will never generate an alert. If you are following this practice, you will get alerts due to issues with Kerberos tickets.  This should be a very rare event, and as such, any time this is generated, it should be investigated as it means there is a high probability that an attacker attempted to use a Golden Ticket to return to your environment.  There’s obviously other implications here, namely that they’ve been there already.

Pass the Hash Configuration:

There are rules associated with pass the hash/ticket/etc. detection built into this management pack. Several are disabled by default due to noise in the environment.  I wrote about this in a multi part article in 2016.  You can find it here.

The credential swap rule is enabled by default.  In my lab environment, this never generated an alert unless I was using mimikatz to swap credentials. Beta testers also did not report any alerts associated with this rule.  As such, I’m fairly confident (at this writing at least) that this is an excellent means of catching an attacker during an attack and strongly recommend investigation if you see this alert and rules are in place to target both the server environment and Forwarded Events if you are using them.  There are also several disabled rules for pass the hash monitoring.  This is in large part because normal events can trigger these other rules, and as such, additional configuration is required.  That configuration is going to be based off of the organizations IP addressing scheme.  In particular, we are interested in tier 2 (desktop) IP addresses accessing these servers in this capacity.  As such, parameter 19 will need to be configured with these rules to match the organization’s desktop VLANs.  There are three disabled rules that can be used.

    • PtH against Tier 1 (server environment)
    • PtH against DCs (domain controllers)
    • PtH against Tier 2 (this watches the forwarded events and monitors movement within a desktop).  I had no way to test this one, so I’m not quite sure how this will work in a production environment for the record.

Failed logon checks:

There is a rule in place that will generate an alert for 5 failed logon events in a 2 minute period. This will be very quiet in most environments with an obvious exception of systems where RDP is exposed to the internet.  As an example, this is what this rule looks like in my Azure lab, which contains 4 VMs.

image

As of this writing, it has been in place for not quite 9 days and has an absurd repeat count.  This is a good example as to why exposing RDP to the internet is a bad idea, as plenty of automated tools will attempt brute force attacks against your environment.  No configuration is needed in dealing with this rule, and I’d add that there are already reports in this management pack showing you failed logons by IP address.  This will allow a security team to send reports to the firewall team so that they can block these IP addresses if for whatever reason the organization will not follow good practices regarding RDP.

There is however, one additional monitor in place.  Kevin Holman wrote one back in 2010 and built in a recovery that modified the Windows Firewall to block IP addresses.  This management pack has the same monitor setup, though there are a few minor changes. It has been updated with a new logon type to account for Network Level Authentication, which did not exist back then. Alert generation is turned off (since we already have a rule in place) and the recovery is disabled. I would recommend that this be enabled for DMZ environments where there is no hardware firewall protecting these systems.  One possible (though highly unlikely) consequence would be a scenario where the 5th failure came from an internal IP, thus prompting the recovery to block a legitimate IP address.  It would be on of those situations that is highly coincidental  due to bad timing, but it is theoretically possible.

Miscellaneous Disabled Rules:

Several rules are in place that will without a doubt generate noise, as such, they are disabled. For the most part, there isn’t a ton of value in turning these on, but there are some scenarios where an organization may be interested in generating alerts off of these events.  I’ve noted them here, and the main recommendation is to think this one through carefully before enabling.  Good maintenance practices should be in place as normal things like updates will trigger these events:

    • System shut down unexpectedly
    • System was rebooted
    • Software was installed on a server
    • Software was removed from a server
    • System was powered off.

Setting up Processes with Security Teams:

Last, but most importantly, we need to discuss business process. This MP is meant to aid security teams in keeping an eye on operational best practices in the org as well as giving them an early warning to potential threats.  This is not meant to be a “just send me an email” type monitoring solution.  This should be scoped out so that the security team can view into SCOM, see these alerts, and close the rules after they have been verified.  A good tuning process to address and respond to noise is also smart.  This means that the security team and the monitoring team need to have a good line of communication. Alerting for this management pack can essentially be broken down into five categories:

    • Forwarded Events – anything coming out of the desktop environment.  Alerts coming from these servers are a good indication that a desktop may have been compromised. Security professionals operated under an “assumed breech” module, as no matter how much you train users, they will still click on things they shouldn’t.  This allows the organization a quick response to investigate and/or re-image a desktop that has been compromised.
    • Operational Events – These are likely normal, but the types of things that need verification. It also helps determine where operational security gaps exist.  Examples include domain admin logons, creation of scheduled tasks, etc.
    • Credible Threats – These should be investigated immediately.  Examples include service creation on DCs, credential swap alerts, any 4688 detection rule in this MP, etc.
    • Exterior Threats – Presently this is only the failed logon check specified above.
    • Threat Hunting – These are monitors/rules that alert against known vulnerabilities that an org should address.  Examples include the WDigest registry keys.

Potential Areas for Noise in the Security Monitoring Management Pack

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 quite a few applications, and I suspect more will be forthcoming.  Likewise, this rule has been configured with the ability to override by specific application. If any more are identified, please post in the comments here or find me on linked in.
  • 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. AGPM will also generate noise, though an overrideable parameter is in place to allow for exclusion based on the service account that AGPM uses.
  • 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.

Event Forwarding and How to Configure it For the Security Monitoring Management Pack

One of the features that was built into the Security Monitoring Management Pack was the ability to discover and then monitor the contents of the Forwarded Events logs for suspicious activity.  The reality for most external attacks is that the breach usually occurs at the user tier through some sort of phishing attack.  Attackers will then move throughout the user environment until they are able to obtain credentials that allow them to gain access to the data tier or even worse, the identity tier.  The unfortunate reality of this is that stopping an attack at the user tier is very difficult to do.  No matter how much training people receive about opening suspicious email, we know that 10-20% of end users will open the email anyways, compromising their system.

With the release of Server 2008, Microsoft added the ability to configure desktops to forward events, but as a practical matter, monitoring event logs from hundreds, if not thousands, of desktops can be a bit tedious.  As such, it seemed like a good idea to configure SCOM to do this.  I would note that in large environments, multiple collectors is a good idea, for simple reason that SCOM can only process so much log data at a time. I’m not sure what the exact number is, but I suspect that one of the big reasons for ACS being a separate add on for SCOM has something to do with this little problem.

I won’t bore you with the details of configuring event forwarders.  That’s fairly straight forward, and if you’re not sure, visit the links below. I will however recommend that the following tier0 events be forwarded:

  • Desktop security logs
  • System Log event ID 104
  • Windows PowerShell Log – there is one rule targeted here (Powersploit monitoring)
  • Applocker/Exe and DLL log – event 8003

That’s the generic level. I would note that doing just what I’m collecting will likely mean this will need to be revisited at some point.  I’ll make an attempt to keep this page up to date with any changes, but if you’re not already forwarding something, then any new rules targeting those logs won’t work.

I would also note that since desktop environments are difficult to manage, I’m sticking mainly with rules that target credible threats. An alert generated by a forwarded event won’t necessarily mean your environment is compromised, but it does likely mean that the desktop in question has been, and should be rebuilt.

Finally, if you want to create your own rules, they will not work if you are using the SCOM console.  You will need to add the <AllowProxying> tag in the XML set to true.

The following events are presently being monitored:

  • 800 – PowerShell Operational Log – will generate an alert if the commercially available copy of PowerSploit is in use.
  • 4624 – Security Log – Generates alerts for potential credential swaps.
  • 4688 – Security Log – Generates alerts for certain types of anomalous process creation behavior.
  • 1102 – Security Log – Generates alerts for clearing the security log.
  • 4964 – Security Log – Generates alerts if a member of a special group (which you must configure) signs on to a desktop.
  • 7045 – Security Log – There are two rules here.  A disabled rule that alerts for any new service created on the desktop, and an active rule that alerts to services that are associated with known threat vectors (PSexec, WCEService, Winexe).
  • 4632 and 4633 – Security Log (creation and deletion of local user accounts).
  • 104 – System Log – Generates an alert for clearing the system log.

The following I hope to add in future releases:

  • 4720 – Security Log (for local admin changes)
  • 11707 – Application log (software install, will be disabled by default).

Info on Windows Event Forwarding.

Wiki on Windows Event Forwarding.