Udostępnij za pośrednictwem

Security Monitoring MP AppLocker Rules

  • Artykuł

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