This blog was originally published on October 8, 2019.

On October 8, 2019, aka Patch Tuesday, Microsoft released patches for CVE 2019-1166 and CVE-2019-1338 — two important vulnerabilities discovered by Preempt (now CrowdStrike):

CVE 2019-1166: This vulnerability allows attackers to bypass the MIC (message integrity code) protection on NT LAN Manager (NTLM) authentication and thereby modify any field in the NTLM message flow, including the signing requirement. This bypass allows attackers to relay authentication attempts that have successfully negotiated signing onto another server while tricking the server into ignoring the signing requirement. All servers that do not enforce signing are vulnerable to this attack. This is the second MIC bypass vulnerability found by the Preempt (now CrowdStrike) team.

CVE 2019-1338: This vulnerability allows attackers to bypass the MIC protection along with other NTLM traffic exchange relay. Unsuccessful mitigations such as enhanced protection for authentication (EPA) and target service principal name (SPN) validation used by old NTLM clients send Lan Manager v2 (LMv2) challenge responses. This attack allows adversaries to use NTLM relay to successfully authenticate to critical servers such as Outlook Web Access (OWA) and Active Directory Federation Services (ADFS) and steal valuable user credentials and data.

NTLM Relay Attacks Background

NTLM relay is one of the most prevalent attacks on the Active Directory infrastructure. The most important defenses against NTLM relay are server signing and Enhanced Protection for Authentication (EPA). When these defenses are strictly enforced, the network is fully protected from NTLM relay attacks. However, for various reasons ranging from configuration errors and unsupported applications to more malicious intent, most networks are not fully protected. Modern NTLM implementations include special MIC protection. When the MIC is used by an NTLM client, launching NTLM relay attacks is much more difficult and in many cases, impossible. 

In CVE 2019-1166, we were able to bypass the MIC protection, overcoming the fix for our previously disclosed vulnerability on the issue. In CVE-2019-1338, we were able to bypass the MIC protections, along with other NTLM relay mitigations such as EPA and the group policy object (GPO) for service principal name (SPN) target name validation for clients which add an LMv2 response to their NTLM authentication. 

NTLM Relay Attacks Background

NTLM relay is one of the most prevalent attacks on the Active Directory infrastructure. The most important defenses against NTLM relay are server signing and Enhanced Protection for Authentication (EPA); you can read more about these mitigations in June’s security advisory. When these defenses are strictly enforced, the network is fully protected from NTLM relay attacks. However, for various reasons ranging from configuration errors and unsupported applications to more malicious intent, most networks are not fully protected. Modern NTLM implementations include special MIC protection. When the MIC is used by an NTLM client, launching NTLM relay attacks is much more difficult and in many cases, impossible. 

For an overview of the MIC and the first vulnerability we discovered, you can review our previous blog post. In CVE 2019-1166, we were able to bypass the MIC protection, overcoming the fix for our previously disclosed vulnerability on the issue. In CVE-2019-1338, we were able to bypass the MIC protections, along with other NTLM relay mitigations such as EPA and the group policy object (GPO) for service principal name (SPN) target name validation for clients which add an LMv2 response to their NTLM authentication.  

CVE 2019-1166 – Drop The MIC 2

The MIC is an optional field provided by NTLM clients to ensure attackers cannot tamper with NTLM messages (e.g. using NTLM relay). The presence of the MIC is announced in the msvAvFlag field in the NTLM_AUTHENTICATE message (flag 0x2 indicates that the message includes a MIC) and it should fully protect servers from attackers who attempt to remove the MIC and perform NTLM relay.

In our previous disclosure (CVE-2019-1040), we presented a way to remove the MIC from the message without tampering with the msvAvFlag field, simply by dropping it from the message along with the version field and some additional negotiation flags. After the fix, removing the MIC is no longer an option due to the validation performed on the msvAvFlag field. However, we were able to find an additional way to trick the server into believing the message does not include a MIC, allowing us to modify any stage of the NTLM authentication flow (e.g., remove the signing requirement).

NTLM MIC Technical details

The key to this new vulnerability is the understanding that the MIC is an optional field, and the only way NTLM servers can validate that this field is present is by inspecting the flags in the msvAvFlag field. In addition, since the msvAvFlag field is signed by the user’s password hash, attackers have no way of modifying it.

However, there is still a way they can bypass the MIC protection and modify any part of the NTLM negotiation stage at the signing requirement. This can be done in a similar manner to the technique we have disclosed in CVE-2019-1019 in our EPA bypass vulnerability. The EPA bypass vulnerability allows attackers to inject a msvAvFlag field into the av_pairs in the TargetInfo field of the NTLM_CHALLENGE, which would be echoed back in the NTLM_AUTHENTICATE message. If attackers set the msvAvFlag field to zero, this field would be injected into the NTLM_AUTHENTICATE message, along with an additional msvAvFlag field stating the correct value calculated by the client (which would be set to 0x2 if a MIC was added to the message). 

The last question that remains: What will the attacked target do when receiving an NTLM_AUTHENTICATE message with two different msvAvFlag fields? Luckily for the attackers (and not so lucky for everyone else), the server only takes the first field into consideration, i.e., the one injected by the attackers stating that a MIC is not present in the message. All that is left for the attacker is to simply remove the MIC from the NTLM_AUTHENTICATE message and bypass any security feature protected by this field.

The exact attack flow to bypass session signing while removing the MIC is as follows:

1. Unset the signing flags in the NTLM_NEGOTIATE message (NTLMSSP_NEGOTIATE_ALWAYS_SIGN, NTLMSSP_NEGOTIATE_SIGN)
2. Inject a rogue msvAvFlag field in the NTLM_CHALLENGE message with a value of zeros
3. Remove the MIC from the NTLM_AUTHENTICATE message
4. Unset the following flags in the NTLM_AUTHENTICATE message: NTLMSSP_NEGOTIATE_ALWAYS_SIGN, NTLMSSP_NEGOTIATE_SIGN, NEGOTIATE_KEY_EXCHANGE, NEGOTIATE_VERSION.

We believe that this is a serious attack, as it adds unnecessary risks to server message block (SMB) relay in most networks, which is further compounded with the additional danger of bypassing EPA in certain NTLM clients.

CVE-2019-1338 – Exploiting LMv2 Clients

Most clients today do not send an LM response during an NTLM authentication flow since it is considered less secure than NTLM. However, there are still some clients that send LM responses (specifically, LMv2 which is considered more secure) such as Firefox on macOS or Linux machines. While it is no trivial feat to perform a brute-force attack on an LMv2 response, we discovered that the consequences of sending an LMv2 response along with an NTLMv2 response are more severe than we imagined. If a client sends both responses, attackers can relay the authentication while bypassing various NTLM relay mitigations such as the MIC, EPA or the GPO for SPN target name validation. 

Technical details

When a client sends both LMv2 and NTLMv2 responses, the target server relies on values in the av_pairs inside the NTLMv2 response for various security features, such as the channel_bindings for the EPA protection or the av_flags for the MIC protection. However, when the Domain Controller receives such a response, it validates only the LMv2 response. This means a relayer can target clients which send both LMv2 and NTLMv2 responses and modify any part of the NTLMv2 response when relaying the authentication against the attacked target. The heart of the problem lies in the fact that the target server relies on values in the NTLMv2 response, however, the DC does not validate the NTLMv2 response if an LMv2 response is present.

The Impact

The impact of these vulnerabilities is far-reaching and, in some cases, can cause full active domain compromise of a network. For example, by performing NTLM relay to a sensitive server that does not enforce SMB signing, or by performing NTLM relay to LDAP on a Domain Controller in order to modify sensitive active directory (AD) objects (LDAP signing was enforced by default only from January 2020). All active directory customers with default configurations are vulnerable to such attacks. Moreover, organizations that do not block LM responses and have clients who still send these default responses are vulnerable to targeted attacks on these clients to bypass additional NTLM protections. Despite Kerberos being the more prevalent authentication protocol in most organizations, NTLM is still enabled and thus abused by attackers to exploit the vulnerabilities that we have described above. 

How can you protect your network?

1. Enforce NTLM mitigations. To be fully protected from NTLM relay attacks, you will need to enable server signing and EPA on all relevant servers.
2. Patch! Make sure your systems are fully protected with the latest security updates from Microsoft.
3. Apply advanced NTLM relay detection and prevention techniques similar to the ones disclosed by Preempt (now CrowdStrike) in our Black Hat 2019 talk.
4. Some NTLM clients use weak NTLM variations (e.g., don’t send a MIC). This puts your network at a greater risk of being vulnerable to NTLM relay. Monitor NTLM traffic in your network and try to restrict insecure NTLM traffic.
5. Get rid of clients sending LM responses and set the Group Policy Object (GPO) network security: LAN Manager authentication level to refuse LM responses.
6. NTLM is not recommended to use in general as it poses some security concerns: NTLM relay, brute-force attacks and other vulnerabilities. As a rule of thumb, try to reduce NTLM usage in your network as much as possible.

Additional Resources

• Learn more by reading the white paper, “The Security Risks 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.