Freely subscribe to our NEWSLETTER

Since 95% of all Fortune 1000 companies have an Active Directory deployment, we consider this vulnerability highly sensitive.

Using the new password, an attacker can fully impersonate the victim to access various enterprise services which require the explicit use of the victim’s password such as Remote Desktop Protocol (RDP) Logon and Outlook Web Access (OWA).

The worse part? Logged events miss the vital indication of an identity theft attack. The attacker can perform this activity unbeknownst to event logs, making log-based SIEMs and Big Data Security Analytics useless against these kinds of advanced attacks.

High-Level Anatomy of an Attack

Attacker uses a publicly-available free penetration testing tool (such as WCE or Mimikatz) that steals an authentication component, named NTLM hash, from the employee’s device. The NTLM hash resides by default on all devices that connect to enterprise resources.

Since this authentication component is known to be a security hazard which leads to identity theft attacks, through the notorious Pass-the-Hash (PtH) attack, protections have been placed to prevent its misuse. For example, many enterprises try to limit the use Active Directory’s older – yet still enabled by default –authentication protocol (i.e. NTLM). In other scenarios, enterprises log and audit NTLM activity.

The attacker forces the client to authenticate to Active Directory using a weaker encryption protocol. At this stage, the attacker uses the Active Directory flaw where the encryption protocol relies on the NTLM hash.
This activity is not logged in system and 3rd party logs- even those that specifically log NTLM activity. As a result, no alerts, or forensic data, ever indicate that an attack takes place.

The attacker proves its so-called legitimate identity to Active Directory using the weaker authentication protocol. Consequently, the attacker is able to:
Authenticate themselves to restricted services

Change the password of the victim

The attacker uses the changed password to fully steal the identity of the victim and access all of the victim’s enterprise resources.

Following Responsible Disclosure

We have provided Microsoft a full and responsible disclosure of this episode. In fact, Microsoft recognized our findings to be valid but confirmed that this is a “limitation” that cannot be fixed as it stems from the design of the authentication protocols. Additionally, since these protocols’ specifications are publicly available, Microsoft considers this “limitation” to be “well known”.

This is where we disagree:

We consider the fact that attackers can change the victim’s password by only knowing the NTLM hash to be a flaw. If this flaw is by design, this simply makes it a “by-design” flaw.
While Microsoft considered the protocol’s design limitation public and “well known”, it is the combination of the different aspects which makes this revelation novel. In fact, each piece of the protocol within itself is indeed public knowledge, appearing in various public documents. However, the actual correlation- and its dire consequence – when placing the pieces together has never been investigated before.
The fact that this behavior is not logged has not been addressed by Microsoft.
Since we consider this issue a “by design” flaw, it also requires its own set of mitigation measures which we provide at the end of this entry.

Technical Details

The Protocols behind Active Directory: NTLM and Kerberos

For the techie readers who are already familiar with NTLM and Kerberos: feel free to skip this section.

To understand this vulnerability, let’s first take a look at the protocols behind Active Directory’s Single Sign On (SSO) authentication – NTLM and Kerberos. SSO is what allows users to provide their password only once even though they access various services – whether in the corporate network or in the Cloud. As mentioned, the underlying SSO authentication protocols are NTLM and Kerberos. NTLM is the older Windows’ authentication protocol which, although still enabled by default due to backward compatibility reasons, suffers from security issues and so has been superseded by the Kerberos protocol.

Both the NTLM and Kerberos protocols are based on using the user’s password as a proof of the user’s identity. The key difference between them is the way they use of the user’s password:

The NTLM protocol computes a relatively weak cryptographic hash function based on the user’s password to create the NTLM hash. From that point on, the protocol uses that NTLM hash as a replacement for the user’s password in order to authenticate to various services.
Kerberos works by exchanging the password for a ticket (formally known as the TGT – Ticket Granting Ticket). This time around, Kerberos uses safer cryptographic methods than that of NTLM’s. The Kerberos ticket contains all of the user’s relevant authentication and authorization information. This information enables the KDC (i.e. the Key Distribution Center. Consider it as the Kerberos’ “key master” which grants specific access to other organizational services) to rely solely on the ticket information for the user’s authentication and authorization.
It’s important to stress is that Kerberos supersedes NTLM due to security issues. Accordingly, there shouldn’t be a dependence of Kerberos on NTLM.

The Active Directory Vulnerability: NTLM’s Hash is Kerberos’ RC4-HMAC Key

The thing is that Windows supplemented the Kerberos standard with an encryption method that allows users to obtain a ticket with… the older NTLM hash.

Microsoft’s reasoning? To support a slick upgrade from strictly NTLM supporting versions (Windows NT 4.0 and lower) to Kerberos supporting versions (Windows 2000 and thereafter).

Technically, this upgrade was achieved by adding support in Kerberos for the encryption algorithm named RC4-HMAC.
And herein lies the problem: the RC4-HMAC encryption algorithm uses the NTLM hash as its key.

This fact is explicitly stated in section 2 of RFC 4757: “The key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) for compatibility reasons.”

Other than the RC4-HMAC encryption, Kerberos supports other stronger ciphers such as the AES encryption (or more formally: “AES256-CTS-HMAC-SHA1?), which is the default encryption for Kerberos in Windows. The stronger encryption methods do not accept the NTLM hash as their key.

(in)Security Side-Effect: Attacker Can Access Sensitive Enterprise Resources albeit Protection Measures

The side-effect of this vulnerability? Attackers can obtain a valid Kerberos ticket if they are able to obtain a user’s NTLM hash.

The reason is that they can change the encryption settings from the default, stronger, AES encryption to the weaker RC4-HMAC and use the stolen NTLM hash as the Kerberos’ password encryption key. As a result, attackers can prove their identity to Active Directory and in turn, receive a valid Kerberos ticket.

As opposed to other attacks which relied on the direct use of the stolen NTLM hash such as Pass-the-Hash (PtH), in this attack the attackers can obtain a fresh, legitimate Kerberos ticket with by the stolen NTLM hash. This fact changes the main tactic used by targeted attacks, namely carrying out an attack using PtH.

Unfortunately, many mitigation and solutions to counter Pass-the-Hash are based on allowing only Kerberos authenticated users or detecting anomalous NTLM authentication. However, as demonstrated, an attacker using this vulnerability can create a valid Kerberos ticket and authenticate to various systems by impersonating the victim whose NTLM hash was stolen. Consequently, these anti-PtH techniques are rendered useless.

The Security Impact: Attacker Can Change the Victim’s Password

The dire consequence? Attackers can use the stolen NTLM hash to change the victim’s password to one of their choice.

To see how, let’s first take a look at the Change Password mechanism. Naturally, changing the password is an ultra-sensitive operation. In fact, as opposed to all other activities that can be executed by anyone who has access the computer, changing the password requires knowledge of the older password to prevent attackers who have already gained temporary access to the computer from making the access persistent.

Knowledge of the old Password is needed to change password

Technically, the password change functionality is achieved by supplementing Active Directory’s regular authentication module (named “Krbtgt”) with a dedicated module that handles authentication requests for password changes (named “Kadmin”). Kadmin module is very similar in operation to the Krbtgt module and most importantly to our case, uses the same Kerberos logic and hence is exposed to the same flaws.

As a result, using the above techniques of using an NTLM hash as the RC4-HMAC key for Kerberos authentication against Active Directory’s Kadmin module, attackers are able to change the password of their victim to an arbitrary password of their choice.

In fact, we had validated this behavior with a Proof-of-Concept tool we had built.

The immediate consequence is that an attacker can leverage an NTLM hash in order to change the victim’s password to that of their own. As a result, the attacker can access interfaces that require explicit use of the password, such as Remote Desktop (RDP) Logon and Outlook Web App (OWA).

Using this vulnerability, Anti Pass-the-Hash solutions and mitigations that are based on allowing only Kerberos authenticated users or detecting NTLM authentication are rendered useless.

Meanwhile in Log City: No Action Detected!

The defensive side should not lose hope, though. After all, indication of an attack can seemingly be indicated by the use of the encryption algorithm, Rc4-HMAC. Unfortunately, users relying on Windows internal log system (Event logs) are in for a bitter disappointment.

One of the inherent shortcomings of logs is that they are a summary of the information. During the process of summarizing some information is bound to get “lost in translation”. Therefore, building a security system and strategy to rely on logs rather than on the actual traffic means that they are built on some shaky foundations.

This case is not different. Although Windows had created a relatively verbose Kerberos event logging system, it fails to show the pertinent attack information. As a result, the logs lack indication of something fishy going on.

The lack of log activity is demonstrated through the following series of screenshots.

In the first screenshot you can see the relevant Event Log (Event ID 4768), generated by Aorato’s attack’s Proof-of-Concept tool. The only information related to encryption, “Ticket Encryption Type”, is not the field which the attacker uses. (For those readers who are intrigued by this value, note that it is 0×12 which represents the AES encryption. As mentioned, it is irrelevant to this attack scenario – its value remains the same even when the RC4-HMAC encryption algorithm is used. For a list of all possible values of the field refer to the table in http://blogs.technet.com/b/askds/archive/2010/10/19/hunting-down-des-in-order-to-securely-deploy-kerberos.aspx)

The attack-related event log: no indication of attack

Unfortunately, the log of password changes presents a worse picture as the event log for a successful password change does not include ANY Kerberos information, let alone the needed encryption information.

Password change event log: no Kerberos (let alone Kerberos’ encryption) information is present
Password change event log: no Kerberos (let alone Kerberos’ encryption) information is present

Mitigation Techniques

Since there is no inherent solution, full mitigation must be provided externally. Measures include:

Detecting authentication protocol anomalies. For instance, the use of a non-default encryption algorithm.

Identifying the attack by correlating the abnormal use of encryption methods with the context in which the victim’s identity is used (e.g. unusual services accessed, unusual time of day, day of week, etc.).

Applying measures to reduce the attack surface. Note that these measures only reduce the attack surface and do not eliminate it altogether or solve the root cause:
Limiting the attacker’s opportunities to steal the NTLM hash in the first place. This is detailed in Microsoft document “Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques”. However, it is important to note that this provides only partial mitigation as detailed in our blog post “Windows Update to Fix Pass-the-Hash Vulnerability? Not!”.

Ensuring that Windows-based computers in the enterprise are updated with the kb2871997 patch, in which several protections had been introduced to make it harder for the attacker to steal the NTLM hashes.
If using Windows Server 2012 R2 Domain Functional Level (DFL) domains, add privileged users as members of the newly added Protected Users group. This will disable RC4-HMAC usage in Kerberos for these users. Note that this measure is suitable only for privileged users since the Protected Users group imposes many other restrictions on its members.

We would like to raise the reader’s attention to the fact that Microsoft provided in its response two additional measures: the first is to use a smart card authentication and second, to remove the weaker encryption (i.e. RC4-HMAC) from the systems. However, we do not see either as viable and practical solutions:

Smart cards are expensive and difficult to deploy throughout an enterprise.
Removing older encryption algorithms require removing its usage throughout the enterprise which may prevent users from accessing older systems.

Vendor statement

“This report is about a limitation in the Kerberos Network Authentication Service (V5) standard (RFC 4120), that is well-known within the industry, whereby an attacker can authenticate as a user, or change that user’s password, if they know that user’s secret key. Possession of a user’s password-derived secret keys (RC4 and AES by default) is validated during the Kerberos password change exchange per RFC 4757. The user’s plaintext password is never provided to the Key Distribution Center (KDC) and Active Directory (AD) domain controllers do not possess a copy of plaintext passwords for accounts by default. If the Domain Controller (DC) does not support a Kerberos encryption type then that secret key is not allowed to be used to change a password.

In Windows, there are three ways to block changing passwords when using Kerberos with RC4 secret keys:

Configure user account as “Smart card is required for interactive logon”. This limits the user to only be able to sign on with a valid smart card, so RC4 AS-REQs are rejected.

Disable Kerberos RC4 support on all domain controllers. This requires, at minimum, Windows Server 2008 Domain Functional Level (DFL) domain and an environment where all Kerberos clients and application servers, as well as trusts to and from the domain, support Advanced Encryption Standard (AES). Windows began supporting AES with Windows Vista and Windows Server 2008.
Deploy Windows Server 2012 R2 DFL domains and configure users as members of the new Protected Users well-known security group. This feature disrupts more than just RC4 usage in Kerberos.