This blog was originally published on June 11, 2019.

As announced in our recent security advisory, Preempt (now CrowdStrike) researchers discovered a critical vulnerability that allows attackers to retrieve the session key for any NTLM authentication and establish a signed session against any server. Any domain environment which does not entirely block NTLM traffic is vulnerable.

Motivation/Background

NTLM relay is one of the most common attack techniques used in Active Directory environments. The attack allows actors to capture an authentication and relay it to another server, granting them the ability to perform operations on the remote server using the authenticated user’s privileges. Even though NTLM relay is an old technique, it still poses a significant risk to enterprises, with new vulnerabilities discovered constantly.

Various mitigations have been introduced to defend domain networks from such attacks, the most critical being server signing. This mitigation requires the session (after the authentication completed) to be signed, with the signing key being known only to the original client and the target server. Since attackers do not have a way to retrieve the session key, they are not able to send requests on the established signed session and such an attack would fail. The only obstacle is the session key, but what if there was an easy way to retrieve the session key for any server? As we at Preempt discovered, until the latest Microsoft security update, there was.

NTLM and NETLOGON Brief Overview

If you are already familiar with these protocols, feel free to jump straight to the vulnerabilities section.

NTLM is a challenge-response authentication protocol. When a domain user authenticates to a remote domain machine using the NTLM protocol, the target machine provides the user with a challenge using an NTLM_CHALLENGE request. The user then needs to encrypt the challenge using a cryptographic hash of his password (the NT HASH) and send it back to the server using an NTLM_AUTHENTICATE message. Since the server does not store users’ passwords, it needs to validate the credentials against a domain controller. This is done by sending a NETLOGON request to the domain controller over an encrypted secure channel.

This message contains parts of the NTLM_AUTHENTICATE request that was sent to the server. The domain controller validates the NTLM challenge and response and sends a response that indicates whether the authentication attempt was successful or not. The domain controller also attaches a session key which would be used to encrypt/sign the communication if session encryption/signing was negotiated. Since the session key is computed based on the password of the authenticating account, the client would calculate it independently. To prevent accounts from being able to retrieve session keys for sessions that were not addressed to them, proper validation methods need to be in place on domain controllers.

CVE-2015-005

In 2015, Core Security published a blog that described a vulnerability in the way domain controllers validate NETLOGON requests, which enabled attackers to retrieve the session key for an authentication attempt. We recommend reading it to understand the details of the vulnerability. 

To summarize, any computer was able to retrieve the session key by simply sending a regular NETLOGON request, even for authentication that was targeted to another server.

Microsoft subsequently fixed the issue by comparing the target server in the NTLM_AUTHENTICATION request to the machine account that established the NETLOGON secure channel. If the latter is different, the domain controller would deny the request.

CVE-2019-1019

We discovered that although domain controllers would deny requests if the expected computer name is different from the one that established the secure channel, it would accept requests in which the computer name field is simply missing. Modifying the target hostname in the NTLM_AUTHENTICATION request is not possible without knowing the user’s password (or NT HASH). However, this field, along with many others in the NTLM_AUTHENTICATION request, is just copied from the previous NTLM_CHALLENGE message that is sent by the target server. Since the attacker functions as the target server for the original client, he can remove this field from the NTLM_CHALLENGE message.

However, modifying NTLM requests is not trivial, especially if there is a MIC (message integrity code) present (which is the default in the new protocol versions). The MIC verifies that the three NTLM messages [NTLM_NEGOTIATE, NTLM_CHALLENGE, NTLM_AUTHENTICATE] were not modified during transit.

Lucky for us, the MIC is calculated using the session key, and because we have the ability to retrieve the session key, we also have the ability to recalculate the MIC using the original NTLM_CHALLENGE message.

Attack Flow

The following scenario includes four computers — CLIENT, RELAYER, TARGET, DC — where the CLIENT machine connects to the RELAYER, which relays the credentials to TARGET. The DC is the domain controller that validates the NETLOGON requests.

1. CLIENT initiates an NTLM authentication flow against the RELAYER using an NTLM_NEGOTIATE message.
2. RELAYER forwards the NTLM_NEGOTIATE message to SERVER, the attacked machine, without modifications.
3. SERVER replies with an NTLM_CHALLENGE message.
4. RELAYER removes the hostname field from the Target Info field in the NTLM_CHALLENGE message and forwards the modified message to the CLIENT.
5. CLIENT responds with an NTLM_AUTHENTICATE message that contains the response to the NTLM challenge. The NTLM_AUTHENTICATE message does not contain a hostname in the Target Info fields.
6. RELAYER sends a NETLOGON message to DC. Since the target hostname field is not present, the message successfully passes the required validation and the DC responds with a message containing the corresponding session key.
7. RELAYER calculates the MIC in the NTLM_AUTHENTICATE request using the retrieved session key and sends the message to TARGET.
8. The target successfully verifies the MIC and forwards the NTLM_AUTHENTICATE message to DC using a NETLOGON request. The DC responds with a successful authentication message and attaches the same session key as was sent to RELAYER.
9. RELAYER is able to establish a signed session against TARGET.

Vulnerable Clients and Servers

Not all clients are vulnerable to the attack; some clients would not accept an NTLM_CHALLENGE message without a target present in the Target Info field. We were not able to attack the Windows SMB client (we are not sure what the root cause for this might be, perhaps spending some time to reverse engineer it might result in a successful exploit against this client as well). All the web clients that we tested (IE, Chrome, Firefox) were vulnerable to the attack and responded to the modified challenge.

Using this vulnerability, we were able to initiate a signed SMB session and execute code remotely on the attacked server. All Windows versions (fully patched) were vulnerable to this attack.

Bonus Fact

Since NTLMv1 does not contain a Target Info field, there is no way to verify that the server that established the secured channel against the DC is the actual target of the NTLM authentication. Hence, any NTLMv1 authentication attempt is vulnerable to this attack. (We still need to check whether the patch. handles this scenario, or if NTLMv1 authentication remains vulnerable.)

Defending Your Domain

If you want to make sure your environment is not vulnerable to the attack described above, make sure to follow these simple steps:

1. Patch always.
2. Enable server signing: Enable SMB signing on every workstation possible. By default, only domain controllers enforce SMB signing. This means if you did not change the default behavior of the domain, your environment will be vulnerable to much simpler NTLM relay attacks which do not require establishing a signed session. Enable LDAP signing and LDAP channel binding to protect your domain controllers from NTLM relay attacks. By default, this setting is disabled.
3. Reduce NTLM usage as much as possible. Even with the best configuration, NTLM still poses a significantly greater risk than Kerberos. We suggest reducing the usage of NTLM to scenarios that are strictly required, preferably by applying active policies. In any case, you should block all NTLMv1 usage in your domain (this can be done with a simple GPO).

Microsoft has released the following fix:

CVE-2019-1019 | Microsoft Windows Security Feature Bypass Vulnerability

Additional Resources

• Learn more by reading the white paper, “The Security Risk of NTLM.”
• Visit the CrowdStrike Falcon® Identity Protection solutions webpage.
• Request a demo of CrowdStrike Falcon Zero Trust or Falcon Identity Threat Detection products.
• Read expert insights and analysis on other complex threats — download the CrowdStrike 2020 Global Threat Report.