Security Monitoring: A Possible New Way to Detect Privilege Escalation

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.

The problem that most defense mechanisms have in detecting the adversary is that they tend to be focused on detecting the tools far more so than detecting the results. There are reasons for this, the most obvious being that it is very easy for there to be false positives within the results, and as such, we don’t want our AV products to become denial of service tools. As it is, many of these products have caused extensive downtime in organizations due to ‘detecting’ something that wasn’t bad.  Unfortunately, that makes life for attackers fairly easy. It’s not hard, for instance, to recompile a publicly available attack tool so that it avoids AV detection. If you don’t believe me, read the “Detecting Mimikatz” section of this article.

This is the premise behind the Security Monitoring Management Pack in SCOM. Simply alerting for the sake of alerting generates a lot of noise, but if it was possible to detect something unique to an attacker, then we have the ability to respond in real time (assuming of course, the organization responds to alerts with something more than an email that no one reads)…

This is where some of the new audit capabilities of Server 2016 and Windows 10 come in to play. It’s worth noting that the method I’ll describe below is not replicated on my Server 2008 system in the same domain because this is a new feature. However, it is potentially a powerful one as it exploits the ability to audit a basic function needed for credential theft: namely debug privileges. Even for standard administrators, debug privileges are not needed, and as such they are not assigned to an administrative token. For credential theft, however, this is required (side note, this is something that is occasionally needed outside of credential theft, but elevating this permission outside of WMI is not something that should happen very often, if at all, in a production environment). That said, because administrators are God to the computer, any administrator can effectively elevate their token to grant themselves debug rights when needed. This is why tools such as WCE or Mimikatz require administrative rights. Their users effectively need to assign themselves SeDebugPrivilege in order to mine the LSA for your credentials. New features, such as Credential Guard, make this much more difficult to do, but one should not rest on these new feature sets. There’s no such thing as a 100% secure environment.

Enter the new method:

First, this will require a GPO. The “Audit Token Right Adjusted” audit event will need to be set.  Documentation for this setting can be found here. This is part of the Advanced Audit Policy Configuration under “Detailed Tracking”.

This will start generating 4703 events. It’s worth noting that 4703 will be a fairly common event once enabled. They are generated at logon and at various uses on a system.  Security features such as user account control practically require it. So simply searching for a 4703 is a bad idea. However, this does allow us to look for events unique to the bad guy. In the screen shot below, I used Mimikatz to elevate my token from an administrator to debug rights. This is accomplished directly via Mimikatz command line.

As noted before, the process name can potentially change, but we can clearly see when a token is escalated to the privilege necessary to attempt to mine the LSA. For those following along at home, this can be accomplished via the SCOM console with a simple rule looking for Event ID 4703 and Parameter 11 = SeDebugPrivilege.  That’s it.

I’ll be testing this in my lab for noise, and hopefully this should be included in the next Security Monitoring MP release. The only obvious note so far is that WMI seems to need to elevate itself on a consistent basis, so excluding wmi would be wise. As always, feel free to reach out to me on linked in or leave a comment here if you desire.