Security Thoughts: Leveraging NTLM Hashes using Kerberos RC4-HMAC encryption (AKA Aorato’s Active Directory Vulnerability)

Reading Time: 5 minutes

In a blogpost today, Tal Be'ery, Vice President Research at Aorato, an Israeli security company consisting of veterans of the Israeli Defense Forces specializing in Active Directory, published how weak encryption enables an attacker to change a victim’s password without being logged.

Labeled as a vulnerability in Active Directory, this information sparked some controversy, so let’s dive into it.


About this vulnerability

Tal Be'ery and his colleagues at Aorato have found a way to use harvested NTLM hashes in RC4-HMAC-MD5-encrypted Kerberos sessions, based on the backward compatibility information in RFC 4757. Section 2 of this RFC states that “The key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) for compatibility reasons.”

The RC4 vulnerability process (click for larger view)

The attack process is depicted in the picture above, where blue items represent the legitimate processes and traffic and red items represent the attacker’s steps. After a colleague logs in with his/her user account (1), LSASS on his/her device creates hashes corresponding with its plugins (2), using, among other methods, the NT One-Way Function (NTOWF) to create the NTLM hash. When signing on to network resources, the appropriate plugin is accessed to provide the hashes, and tokens needed, without the colleague being prompted for credentials (3).

The attack method described by Tal Be’ery consists of three parts:

  1. Harvest NTLM hashes (1)
  2. Use NTLM hashes to constract valid RC4-HMAC-MD5-encrypted Kerberos tokens (2)
  3. Communicating to hosts, like Domain Controllers, in weakly-(RC4-HMAC-)encrypted Kerberos sessions (3)

About LSASS and LSASS Protection

As you might recall in my last blogpost covering LSASS protections in Windows 8.1 and Windows Server 2012 R2, I detailed how LSASS uses plug-ins per Security Support Provider (SSP) and how these create hashes using its one way hasing algorithms. I also detailed a new feature called LSASS Protection when you’re running Windows 8.1 or Windows Server 2012 R2, that protects the LSASS Memory Space and does not store all hashes in it.

About encryption algorithms

When NTLM was introduced with Windows NT in 1993, processors weren't fast enough to reliably and unnoticeable hash values with more than DES or 3DES. Despite inherent weaknesses, todays processors can brute force the original value pretty easily.

This, indeed, is a cat and mouse game. From a Kerberos authentication type point of view, Microsoft has disabled DES-CBC-CRC and DES-CBC-MD5 for Kerberos encryption from Windows 7 and Windows Server 2008 R2 onwards, by default.

Could RC4-HMAC-MD5 be the next in line to bite the dust?


Mitigating this type of attack

This attack method is made possible by three factors:

  1. The device stores NTLM hashes in the LSASS memory space, where they can be harvested with tools like the Windows Credentials Editor (wce.exe) and Mimikatz.
  2. For backward compatibility, Microsoft has introduced the ability to create RC4-HMAC-MD5-encrypted Kerberos tokens based on the NTLM hash.
  3. Hosts on the network, including Active Directory Domain Controllers, running Windows 7 and Windows Server 2008 R2 and up, negotiate Kerberos encryption types. RC4-HMAC-MD5 is allowed as a valid Kerberos encryption type, by default.

The second factor is not something that can be easily changed, but as Active Directory admins, we can address the other two factors:

Mitigate Pass-the-Hash (PtH) attacks

Since this type of attacks leverages harvested NTLM hashes, mitigating these kind of attacks makes the bottom fall out of it. Last week, Microsoft released its second version of its Whitepaper on Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft. In it, Microsoft details these steps to mitigating Pass-the-Hash attacks:

  1. Restrict and protect high privileged domain accounts
    1. Separate administrative accounts from user accounts for administrative personnel
    2. Create specific administrative workstation hosts for administrators
    3. Restrict server and workstation logon access
    4. Disable the account delegation right for privileged accounts
  2. Restrict and protect local accounts with administrative privileges
    1. Enforce local account restrictions for remote access
    2. Deny network logon to all local accounts
    3. Create unique passwords for privileged local accounts
  3. Restrict inbound traffic using the Windows Firewall

Another way is to upgrade to Windows 8.1 and Windows Server 2012 R2 to gain the LSASS Protections.

Banish RC4-HMAC-MD5

As Ned Pyle pointed out, in a blog post on the Ask the Directory Services Team blog on Hunting down DES in order to securely deploy Kerberos, you can scan the network for Kerberos encryption types. This makes it easy to see which systems still rely on the older backward-compatible RC4-HMAC-MD5 encryption scheme.

When it’s not in use, you can safely disable it using the information on Windows Configurations for Kerberos Supported Encryption Type on the Microsoft Open Specifications Support Team Blog through the Network security: Configure encryption types allows for Kerberos Group Policy:

The Network security: Configure encryption types allows for Kerberos Group Policy (click to see in separate window)

To prevent Kerberos impersonation using NTLM hashes leveraged in RC4-HMAC-MD5-encrypted Kerberos, apply this Group Policy setting to all the computer objects in the Active Directory environment. For the purpose of merely preventing password changes with this method, apply the Group Policy setting to all Domain Controllers, as outlined by Microsoft in its TechNet page on Preventing Kerberos change password using RC4 secret keys.

An alternative user object-based method is to use the Protected Users global group. The Protected Users global security group in the Users container triggers non-configurable client-side protection on devices and servers running Windows Server 2012 R2 and Windows 8.1, and (optional) additional Domain Controller protection on Active Directory Domain Controllers in domains running the Windows Server 2012 R2 Domain Functional Level (DFL).

Implementing Protected Users can be hazardous. Active Directory admins can shut themselves out, be unable to troubleshoot delegation effectively. Colleagues may need to change their passwords before protections may kick in.

The Protected Users group is only for user account objects, not for service accounts or computer account objects.

One of the (non-configurable) protection mechanisms that are part of membership of the Protected Users group is limiting the Kerberos encryption types to AES128 and AES256.



It's not the Pass-the-Hash stuff that's interesting to me in Aorato’s Active Directory vulnerability. It's what they're using the hash for; instead of using it for lateral movement or privilege escalation, they're using it to get a valid (weak) Kerberos token to change the password for the affected user with.

Microsoft offers this functionality for backward compatibility, but perhaps they shouldn't need to anymore in a next version?

Related KnowledgeBase Articles

2868725 Microsoft security advisory: Update for disabling RC4
2871997 Microsoft Security Advisory: Update to improve credentials protection and management: May 13, 2014

Further reading

Active Directory Vulnerability Disclosure: Weak encryption enables attacker to change a victim’s password without being logged
Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft, Version 2
Windows Configurations for Kerberos Supported Encryption Type
Protected Users Security Group

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.