Last updated at Tue, 16 Jan 2024 16:01:51 GMT

On Tuesday, November 18th, Microsoft released an out-of-band security patch affecting any Windows domain controllers that are not running in Azure. I have not yet seen any cute graphics or buzzword names for it, so it will likely be known as MS14-068, CVE-2014-6324, or "that Kerberos vulnerability that is being exploited in the wild to completely take over Windows domains" because it rolls off the tongue a little better.

There is a very informative description of the vulnerability, impact, and detection options on Microsoft's Security and Defense Blog, so I won't rehash every detail, but the key points are that this vulnerability is a significant flaw in the way Kerberos validates tickets, you absolutely must patch it, and we can help you detect malicious parties when they attempt to exploit it.

Don't freak out, but definitely patch every domain controller you have before you finish reading this

The only good news about this vulnerability is that attackers need compromise an account in your domain before they can exploit it. You should have already patched by now because this improper validation of the PAC in your Kerberos tickets gives an intruder the power to turn an unprivileged user into a domain administrator. This is the equivalent of playing a game of chess, taking your opponent's first pawn, and declaring "Check mate"; no fun back-and-forth, no lateral movement, and no clever escalation of privileges on a random desktop.

Since no domain controller should ever be exposed to the Internet, someone looking to exploit this vulnerability needs to get into a position to do so by gaining remote access to your network and stealing a single set of domain credentials, likely through phishing or any number of exploits that would give them user context. From there, this intruder need only use the compromised account (or hash) and exploit this vulnerability to forge a Kerberos "golden" ticket that remotely elevates the stolen credentials to domain administrative privilege across your domain. That would be a worst-case scenario because as Microsoft states: "The only way a domain compromise can be remediated with a high level of certainty is a complete rebuild of the domain".

Detect anyone that even TRIES to exploit it because there is no legitimate reason

Within their blog, Microsoft explains how to detect attempts to forge Kerberos tickets using this vulnerability on both patched and unpatched domain controllers. We have added detection to UserInsight for both indicators and found that Microsoft was, in fact, right about this alert not generating noise because so few legitimate behaviors would cause a false positive. The detection method for an unpatched server has been added just in case there are some servers in your organization left unpatched, but as I stressed above, you need to patch because remediation for an alert that someone successfully exploited this vulnerability is to send everyone home for the week while you delete your domain and start over.

Assuming that you have followed Rapid7's and Microsoft's suggestion to patch every domain controller everywhere, knowing that someone is trying to fraudulently escalate privileges is always worthy of notification. We believe that the incident response team needs to be notified about certain indicators every time they occur, so alerting when someone unsuccessfully attempts to exploit CVE-2014-6324 fits in nicely with our alerts that "someone new is scanning your internal network" and "someone has deleted event logs on a system" because none of these events should ever occur. When new vulnerabilities are inevitably announced, UserInsight will rarely need to add new detection specific to them because of how we identify "normal" and anomalous behavior on your network, but this specific forgery is the kind of extremely concerning edge case that warranted its own new alerts.

But also, detect them before the attack gets to that point

We did add this new detection to notify you when an attacker reaches this stage of infiltrating your network, but in our opinion, you need to have ways to detect an intruder long before they reach the domain controller. This is why we have built UserInsight alerts focused on many stages of the process:

  • the initial theft of credentials
  • the first use of stolen accounts to access your network
  • mapping and testing your network to plan expansion
  • account impersonations (and passing the hash) for lateral movement
  • escalation of privileges
  • unusual access to systems with valuable data

If you are relying solely on an indicator like this specific exploit to detect an intruder, you are taking a serious gamble. No one technique is going to be used in every attack.

If you are interested in a personal, guided demo of UserInsight, or a proof of concept in your environment, please provide your details on the demo request page. We'll show you how we can detect the attempts to exploit this vulnerability, but more importantly, how we have focused on detecting every stage of an attack.