NTLMv1 Must Die

Foreword

I know the internet is already drowning in NTLM authentication articles. So, if you’re thinking this post might be just another drop in that ocean, I get it — and I’m sorry to disappoint. But for the newcomers or anyone still tangled in the protocol’s quirks, this might just be the lifebuoy you need. Also, I won’t be plunging into the technical details; people far smarter than I am already did, so I kindly recommend you check their work. I am merely putting into my own words something that’s been explained countless times, to help me understand it better, and hopefully, it helps you too.

At the end of this article, you will understand why:

• Configuring SMB Clients to require Session Signing does not protect them from NTLM relay attacks
• SMB Signing is just a Client’s preference, and a mere suggestion an attacker can ignore
• NTLMv1 has no concept of channel binding, making it trivial for attacker to relay authentication to arbitrary targets
• NTLM and SMB are negotiating signing twice, but SMB takes precedence over NTLM
• Upgrading from NTLMv1 to NTLMv2 provides no protection against an attacker ignoring a Client’s SMB signing requirement
• You should stop using NTLMv1 before it’s too late

NTLMv1 Authentication Flow

The assumption is that you’re already somewhat familiar with the protocol. If not, I’ll give you a quick crash course, no worries.

At a very high level, the main steps of NTLM authentication handshake are as follows:

1. First, the Client tells the Server that it wants to authenticate. That’s the NEGOTIATE_MESSAGE.
2. The Server then responds with a NTLM_CHALLENGE, which is nothing more than a random string of characters.
3. The Client encrypts this challenge with its secret (NTLM Hash of its cleartext password) and sends the result back to the Server as its response. That response is known as NTLM AUTHENTICATE_MESSAGE
4. Finally, the Server either (1) have knowledge of the user’s NTLM Hash, in which case it can complete the authentication process, or (2) it does not have knowledge of the user’s NTLM and must forward the NTLM AUTHENTICATE_MESSAGE response to the domain controller that will complete the authentication process.

Now, once the DC has validated the NTLM AUTHENTICATE_MESSAGE, the DC returns in its response a Session Key (that’s Step 5) which could be used to sign further messages exchanged if Session Signing was required by either the Client, or the Server.

Alright, now we got that out of the way, let’s discuss how this could be abused.

NTLM Relay Attack

In an NTLM Relay attack, a malicious actor positions themselves as a Man-in-the-Middle (MitM) between a Client and a target Server, and relays messages until Authentication is complete.

An NTLM Relay Attack first starts with the victim being coerced into authenticating against the attacker (another option is to poison the network traffic), after what the attacker intercepts the NTLM challenge and response messages, tamper with those if necessary, and forwards them to an arbitrary target. Because the attacker sits in the middle as a transparent proxy, the victim believes he/she’s talking to the target Server, whereas the target Servers thinks its talking to the victim.

A successful relay requires the target Server to accept the relayed authentication. In some cases, the target Server might enforce some security controls, and under the right conditions, those can be bypassed. For example, the attacker can relay the authentication to an SMB service if SMB Signing is not required by the target Server. Similarly, relaying to LDAP/LDAPS or HTTP requires the target to have LDAP Signing or Extended Protection for Authentication (EPA) disabled or unenforced on the target Server.

Scenario 1: SMB Signing is NOT Required

At the end of NTLMv1 Authentication Flow, we said that the DC is returning a Session Key.

That Session Key can be used to sign subsequent packets exchanged during the session, over a given protocol. For eg. a session over SMB, or a session over LDAP. Signing the session guarantees the integrity of the communication.

So the attacker has the Session Key returned by the DC. That’s nice and all, but now what? If either the Client or target Server are misconfigured, or in their default configuration, and the target Server does not require the session to be signed, the attacker does not need the session key and can simply ignore it.

That’s the simplest and most straightforward scenario.

Scenario 2: SMB Signing is Required

In this scenario, either the Client, or the Server, require a Session Key for the session to be signed.

If a target Server requires Session Signing and an attacker ignores the Session Key, the target Server will immediately kill the session after authentication took place because the attacker will not be able to cryptographically sign any subsequent packets.

The Loophole

Did you know that an attacker can still successfully relay an authentication to a target Server that does NOT enforce SMB Signing, even if the coerced victim’s machine explicitly required it?

This is possible because configuring SMB Clients to require SMB Signing does not protect against NTLM relay attacks.

The role of NTLM is authenticating the Client against the Server. Optionally, during that exchange, either of the parties can require subsequent messages to be signed cryptographically.

The role of SMB is establishing the Session. The SMB protocol picks it up where NTLM left it, and takes that exact NTLM Session Key created during Authentication, and use it to cryptographically sign all subsequent SMB network packets for the Session.

That is the reason why you might have already heard that NTLM is application protocol-independent, ie. NTLM messages can be embedded within the packets of various application protocols, including SMB, but also HTTP, MSSQL, SMTP, and IMAP. As a matter of fact, when a SMB Client wants to establish a connection with a SMB Server, the first thing the Client and Server do are negotiating the SMB versioning and SMB signing requirements. Only AFTER this initial negotiation is complete do the Client and Server exchange the NTLM Authentication messages.

Now, let circle back to my original statement:

An attacker can still successfully relay an authentication to a target Server that does NOT enforce SMB Signing, even if the coerced victim’s machine explicitly required it.

When a victim requires signing, you would hope that there is some information in that last AUTHENTICATE_MESSAGE sent by the victim, that would prevent the attacker from successfully relaying the message to a SMB Server that is NOT enforcing signing? I would hope that too, but this is not how NTLMv1 works.

• First, in NTLMv1, the NTLM AUTHENTICATE_MESSAGE does not contain any information preventing a relay. NTLMv1 does NOT contain a Target Info field, meaning there is no way for any recipient, or DC, to verify which Server the Client was actually intending to authenticate against. That’s the first problem.
• Second, NTLMv1 does not support Message Integrity Code (MIC) or Channel Binding (aka EPA), allowing an attacker to freely tamper with the message and remove signing negotiation flags without invalidating the authentication. So even if the victim requires Session Signing and specify that explicitly in its Authentication message, the attacker, sitting in the middle between the Client and the Server, and having intercepted that message, can remove the Session Signing flag, and forwards the packet to the target. The target Server has no way to detect the tampering; it simply assumes the Client never requested Signing in the first place !

So, (1) there is no security mechanism within NTLMv1 that would explicitly say: “Client1 can only authenticate to Server1”, and (2) there is no security mechanism within NTLMv1 that prevents an attacker from tampering with the messages.

Now that you have understood this, let’s discuss the loophole.

I mentioned earlier that SMB Servers negotiate signing at the SMB protocol level rather than the NTLM exchange level, meaning the target SMB Server will disregard the Client’s NTLM NEGOTIATE_SIGN flag — responsible for informing the Server that the Client requires Session Signing. The target Server will only look at the signing requirements negotiated within the SMB headers. Because these SMB headers exist outside of the NTLM authentication exchange, an attacker performing a relay attack can easily control and modify them to prevent the session from being signed.

So because SMB ignores the NTLM flags, an attacker performing an NTLM Relay Attack over SMB doesn’t even need to tamper with the NTLM messages in transit (like stripping the MIC or altering NTLM flags) to bypass signing. As long as the target SMB Server doesn’t strictly require signing in its own configuration, the attacker can just ignore the requirement in the SMB headers.

In the modest animated SVG I appended below, you can see that even though the Client is configured to require Signing, the attacker ignores this requirement and establishes a SMB connection with the SMB Server without signing the Session. Before you ask, this is not a NTLMv1 problem. Using NTLMv2 does not prevent an attacker from bypassing a Client’s SMB signing requirements either, and does not prevent the attacker from establishing an unsigned session, provided the target Server does not strictly require signing. NTLMv2 has no control over the surrounding SMB protocol.

Below is a high-level 3 steps breakdown of this process:

1. The coerced victim connects to the attacker. Because the admin did his homework and properly configured the Clients within the environment, in its NTLM payload the victim’s machine says, “I require signing!”.
2. The attacker intercepts this traffic. The attacker takes the victim’s NTLM AUTHENTICATE_MESSAGE (which is the last message sent by the victim as part of the NTLM exchange, and that contains the NTLM signing request) and places it inside a brand new SMB connection that the attacker opens with the target Server. Because the attacker is generating this new SMB connection, the attacker has full control over the SMB headers. The attacker alters the SMB headers to tell the target Server, “I do not support or require SMB Signing.”
3. The target Server receives the request. It looks at the outer SMB headers (manipulated by the attacker to say “no signing”) and it looks at its own configuration. If the target Server is configured so that SMB Signing is NOT required but supported (which is the default on many Windows Servers), it agrees to establish an unsigned session even though the Client explicitly asked for the session to be signed.

To summarise, because SMB Servers negotiate signing at the SMB protocol level, outside the NTLM exchange, the target Server completely disregards the fact that the inner NTLM payload requested Session Signing. The target SMB Server only considers the manipulated SMB headers, and its own configuration. Therefore, even if the victim was configured to strictly require Session Signing in the first place, it does not protect them from being relayed to a target Server that does not require it.

The only time the NTLM Relay Attack over SMB will fail is if the target Server is configured to explicitly require SMB Signing. If the target Server requires it, the attacker will not be able to interact with the target’s SMB server, because the attacker cannot mathematically compute the signature required to sign packets sent on behalf of the victim.

It is worth keeping in mind that this specific vulnerability is unique to how the SMB protocol was designed to handle NTLM. If you were relaying to an LDAP Server instead, this trick would fail. LDAP Servers do inspect the inner NTLM-level NEGOTIATE_SIGN flag, and if the victim requested signing inside the protected NTLM payload, the LDAP Server would expect a signed session and reject the attacker’s tampered packets.

Tampering is Caring

We’ve covered a lot, so pat yourself on the back, you earned it.

If you haven’t dozed off from sheer boredom and are still with me, you curious mind might have wondered: “If a target Server doesn’t enforce SMB Signing, and tampering with the messages isn’t even required regardless of the version being used, then when exactly would an attacker need to modify NTLM messages?”

An attacker must tamper with NTLM messages when attempting a cross-protocol relay to a service that handles session signing differently, such as relaying an authentication from SMB to LDAP or LDAPS.

When a Windows SMB Client initiates an authentication, it sets the NTLMSSP_NEGOTIATE_SIGN flag to 1 by default to indicate its capability to sign packets. If an attacker merely acts as a middleman and blindly forwards this NTLM message to an LDAPS Server, the target Server will reject the connection. This rejection occurs because LDAPS already secures the channel using TLS, and that TLS layer is responsible for packet signing and encryption. Therefore, there is no logical reason for a Client connecting over LDAPS to indicate it wants to handle packet signing at the NTLM level. Similarly, if the NTLM message is relayed to an LDAP Server without tampering, the Server will honor the flag, and expect the subsequent session packets to be signed, which the attacker cannot do because they lack the necessary session key.

So, how does an attacker relay to LDAP/S?

To successfully establish the session and avoid generating errors or being rejected, the attacker must perform a Cross-Protocol (Unsigning) Relay Attack.

In this specific scenario, the attacker must actively tamper with the NTLMv1 NTLM AUTHENTICATE_MESSAGE by unsetting the NTLMSSP_NEGOTIATE_SIGN flag. Because NTLMv1 does not incorporate a Message Integrity Code (MIC) to protect the negotiation flags, the attacker can freely modify the signing attributes, tricking the target LDAP or LDAPS Server into believing the Client never requested signing in the first place!

To summarize, whether you decide to relay to LDAP, LDAPS, or HTTPS, at the end of the day, in all those scenarios, you need to remove the flag that specifies Session Signing is required.

• If you relay NTLMv1 to LDAPS/HTTPS, and the NEGOTIATE_SIGN flag is set to 1, ie. signing is required, you need to tamper with it. If you were to relay this unmodified flag to an LDAPS or HTTPS Server, the Server will reject the authentication.
• If you relay NTLMv1 to LDAP, you also need to tamper with the NEGOTIATE_SIGN from the packet. If you don’t tamper with it, LDAPS or HTTPS — which instantly reject the authentication because they rely on TLS for packet signing — LDAP would accept the incoming packet. However, it will also expect all subsequent messages to be digitally signed. Because you do not know the Client’s secret, you cannot compute the required session key and you are completely incapable of signing subsequent LDAP packets. That is why it is absolutely necessary to change the value of that flag.

Message Integrity Code aka MIC

If you’re still with me, you’ve noticed I used the term MIC without defining it. Apologies about that. If you’re already familiar with MIC, feel free to leapfrog that section. If not, all good — I will try to keep it short and sweet.

Unlike Session Signing, MIC protects the Authentication.

MIC is a signature added to the final message (the NTLM AUTHENTICATE_MESSAGE ) of an NTLMv2 authentication exchange. Its purpose is to guarantee the integrity of all three messages exchanged during NTLM authentication. The MIC is computed using an HMAC_MD5 function with a session key that is derived from the Client’s secret, meaning an attacker without the secret cannot forge or re-compute it.

I already stated that NTLMv1 does not support MIC. Unlike NTLMv2, the cryptographic recipe used to create an NTLMv1 Client response relies solely on the Server’s challenge. In NTLMv1, there is no AvPairs flag or msAvFlags data structure, nor a MIC field that’d inform a Server that MIC is being used. None of those data structures exist in NTLMv1.

Because of this design flaw, NTLMv1 cannot protect its messages with a MIC.

NTLMv2, on the contrary, does implement MIC to prevent the tampering with the authentication messages. However, two vulnerabilities disrupted the status-quo in 2019.

Drop the MIC

Yaron Zinar and Marina Simakov, two security researchers working for Preempt, discovered that it was possible to modify NTLMv2 messages sent by the SMB Client, and even removing the signing requirement.

For this attack to be successful, the requirements were that the target Server must not enforce SMB Signing. If the target Server has SMB Signing set to Optional, or Not Required, and if the target SMB Server has not received the patch for CVE-2019-1040, this attack is possible.

As discussed above, the absence of AvPairs, msAvFlags, and the MIC in NTLMv1 messages, are the primary enabler for a wide range of NTLM relay attacks. Those data structures were introduced with NTLMv2 to guarantee the integrity of the messages exchanged during NTLMv2 handshake.

In order to understand Drop the Mic, let’s briefly cover the basics here.

An NTLM handshake consists in a series of three messages:

• NTLM_NEGOTIATE or NTLM NEGOTIATE_MESSAGE
• NTLM_CHALLENGE or NTLM CHALLENGE_MESSAGE
• NTLM_AUTHENTICATE or NTLM AUTHENTICATE_MESSAGE

To prevent attackers from modifying these messages, NTLMv2 added a MIC, which is a 16-byte HMAC MD5 hash of the concatenation of all three messages, generated using the secret session key, that is, the NTLM Hash of the Client:

HMAC_MD5(Session key, NEGOTIATE_MESSAGE + CHALLENGE_MESSAGE + AUTHENTICATE_MESSAGE)

Normally, the Client announces the presence of the MIC by setting the msvAvFlags field to 0x2 in the NTLM NTLM_AUTHENTICATE:

If the attacker simply removes the MIC but leaves the NegotiateFlags intact (which is another data structure indicating whether the Client wants to use session signing), the target Server will still expect all subsequent session traffic to be cryptographically signed. That’s a problem for the attacker because he cannot sign subsequent session traffic without the NTLM hash of the Client.

To bypass MIC and the surrounding data structures “protecting it”, and ultimately, successfully remove the signing requirements, an attacker intercepting the NTLMv2 messages must perform the following modifications:

1. Tamper with the NTLM NTLM_NEGOTIATE message:

When the Client initiates the authentication, the attacker intercepts that first message and must unset the signing flags of NTLMSSP_NEGOTIATE_ALWAYS_SIGN and NTLMSSP_NEGOTIATE_SIGN so that the target Server does not expect a signed session.

2. Let the CHALLENGE_MESSAGE from Server to Client pass

3. Tamper with the NTLM_AUTHENTICATE message from Client to Server

The SMB Client is completely unaware that the attacker tampered with the NTLM_NEGOTIATE message in Step 1, so the SMB Client constructs its final authentication packet assuming that a signed session was successfully negotiated. The attacker must intercept this final packet and strip out several fields and flags to match the unsigned negotiation established with the Server in Step 1.

• The MIC field must be completely removed from the message
• The Version field must also be removed. If the attacker drops the MIC without dropping the Version field, the Server will throw an error
• The Client will have set its 32-bit NegotiateFlags field to reflect its original desire to sign the session. The attacker must manually flip these specific bits back to zero:
  • NTLMSSP_NEGOTIATE_ALWAYS_SIGN
  • NTLMSSP_NEGOTIATE_SIGN
  • NEGOTIATE_KEY_EXCHANGE
  • NEGOTIATE_VERSION

It may seem strange that the attacker has to remove the signing flags in both Step 1 and Step 3. This is necessary because the Client sets the signing bits to 1 in the NegotiateFlags field of its final NTLM_AUTHENTICATE message based on its original (untampered) request. If the attacker were to simply forward this final message to the Server without flipping the bits back to 0, the Server would spot a glaring mismatch between the Signed negotiation from Step 1 and the Unsigned bitmask in Step 3, causing the authentication to fail.

I can hear some of you asking. But what about the msvAvFlag? We said that the msvAvFlag field, when it contains the flag 0x2, is used in the NTLM_AUTHENTICATE message to announce to the Server that a MIC is present in the message. Moreover, the msvAvFlag is cryptographically signed by the user’s password hash.

If an attacker were to alter or remove the msvAvFlag to falsely claim that no MIC was present, the Server’s recalculation of the NTLMv2 response would not match the Client’s original response. Because the attacker does not know the user’s password hash, the attacker cannot forge a new, valid, tampered msvAvFlag. The solution? Do nothing. Not tampering with that flag will not invalidate the message, and that’s precisely what Drop the Mic is about:

Drop the MIC 2

When I first heard about Drop the MIC, I thought to myself: “This is a once-in-a-decade kind of discovery. You don’t come across something like this every day”.

WRONG.

You are underestimating Microsoft capability at introducing security flaws, and the resilience of the researchers at Preempt.

We established earlier that the MIC is an optional field that servers check for its presence by looking at the msvAvFlag field in the NTLM_AUTHENTICATE message. With Drop the MIC (CVE-2019-1040), the server failed at invalidating the signature after the MIC and a couple of other flags were removed in transit.

With Drop the MIC 2 (CVE-2019-1166), researchers found out that it was possible to capture the NTLM_CHALLENGE message sent by the server, and inject rogue data structures indicating no MIC is present.

We have not discussed the NTLM_CHALLENGE message, yet. As a matter of fact, in the Drop the MIC attack, we completely ignored it. Let’s quickly have a look at it:

The NTLM_CHALLENGE (or CHALLENGE_MESSAGE) is the second message in the three-way NTLM authentication handshake, sent by the Server to the Client in response to the Client’s initial NEGOTIATE_MESSAGE. Its primary purpose is to ask the Client to prove its identity without transmitting the user’s actual password over the network.

The Server sends a 8-byte randomly generated number (a 64-bit nonce) known as the “Server Challenge”. To successfully authenticate, the Client must mathematically encrypt this Server Challenge with his password hash to produce a unique “Challenge Response”. This response is then sent back to the Server inside the final AUTHENTICATE_MESSAGE.

So that “Challenge Response” sent by the Client, is cryptographically signed with the NTLM Hash of the Client. So in Step 3, when the Client sends the “Challenge Response” as part of the AUTHENTICATION_MESSAGE, it’s already too late for the attacker to intercept and tamper with the message because its cryptographically signed.

Instead, what the attacker can do, is tampering with the CHALLENGE_MESSAGE in Step 2, that is, before the Client encrypts the data!

So the attacker intercepts the CHALLENGE_MESSAGE sent from the server, and maliciously injects a rogue AV_PAIR with an AvId of 0x0006 (ie. MsvAvFlags). The attacker set the Value to 0 to trick the Client into thinking no MIC is required:

Why 0x006? An AV_PAIR can take different AvId. You might have an AvId of 0x0001, which means its Value contains the server’s NetBIOS computer name. Another might have an AvId of 0x0004, meaning its Value is the FQDN of the domain.

If an AV_PAIR has an AvId of 0x0006, the AV_PAIR is then known as a MsvAvFlags, and its Value field will contain a 32-bit integer that acts as a series of configuration flags.

For example, setting the bit 0x00000002 indicates that the client is providing a MIC.

Now, if you haven’t dozed off, you should have noticed that there will be two AvPairs msvAvFlag . The legitimate one inserted by the Client, and the rogue one injected by the attacker. Due to design flaw in NTLM, the target server only takes into consideration the first msvAvFlag field it encounters and ignores any subsequent duplicates. As we will see later, we are exploiting the same behavior to bypass EPA.

By design, the NTLM protocol requires the Client to take the AV_PAIR sequence structures from the Server’s and embed it into its own NTLMv2_CLIENT_CHALLENGE structure. When the Client receives the attacker-manipulated CHALLENGE_MESSAGE, it unknowingly takes the rogue msvAvFlag and echoes it back inside its NTLMv2_CLIENT_CHALLENGE, right alongside the client’s own legitimate msvAvFlag. Because the Client includes the attacker’s injected flag in the calculation, the Client generates a perfectly valid cryptographic signature that includes the attacker’s rogue flag:

When the Client sends its final AUTHENTICATE_MESSAGE back to the Server, the Server verifies the cryptographic signature. Because the Client signed the NTLM_V2_CLIENT_CHALLENGE using its own valid password hash, the signature check passes perfectly!

Extended Protection for Authentication aka EPA

EPA, also known as Channel Binding, is another security feature introduced by Microsoft that binds the Client NTLM Authentication handshake to the TLS certificate of the Server. EPA was another attempt by Microsoft to thwart NTLM relay attacks.

With EPA, the Client generates a hash of the target server TLS certificate it wants to communicate with. The Client places this hash inside the NTLM_V2_CLIENT_CHALLENGE of the NTLM_AUTHENTICATE message, exactly the same way it would implant a rogue MsvAvFlags for bypassing MIC.

Below is another illustration that should look familiar by now. Instead of having a MsvAvFlags structure, it’s a MsvAvChannelBinding one that signals Channel Binding:

Unbeknownst to me until I started writing this article, and thanks to Ryan Grunsten magnificent blog post here, there are actually two flavours of EPA:

• Service Binding: That’s EPA binding a Client to a target service. To pull that off, it uses SPNs.
• Channel Binding: That’s the one you’re probably already familiar with, and that one binds the Client to the TLS certificate of the target the Client wants to communicate with.

This article will only focus on Channel Binding.

As we already saw, with NTLMv2, attackers cannot modify the NTLM_V2_CLIENT_CHALLENGE because the entire structure is signed using the user’s password hash, which the attacker does not know. However, as we also saw, it is possible to modify the NTLM_CHALLENGE sent from the Server to the Client, because the Server is not signing it cryptographically.

EPA Under Attack

Now that we better understand what EPA is, let’s break down the steps an attacker ought to take to remove EPA from the packets:

1. The Client sends an NTLM NEGOTIATE_MESSAGE to the Attacker. Why? Because the attacker coerced the client into doing it.
2. The attacker establishes a TLS session with the intended target server and relays the client’s NTLM NEGOTIATE_MESSAGE to it. If NegotiateFlags is informing the Server the session should be signed, the attacker must tamper with the message. The attacker doesn’t want the Server to drop the session later because he cannot sign the packets.
3. The Attacker is intercepting the NTLM CHALLENGE_MESSAGE sent by the Server. This CHALLENGE_MESSAGE contains a Payload structure holding various AvPair. Before passing this message back to the client, the attacker computes and injects the channel binding hash into the MsvAvChannelBindings value. What for you might ask? By computing the required channel binding value (based on the target server’s public certificate) and injecting it into the NTLM_CHALLENGE message, the attacker forces the client to include that cryptographically sign channel binding in its subsequent response (ie. the AUTHENTICATE_MESSAGE). Along with the attacker’s injected channel binding field, the client will append its own channel binding field (which is typically set to all zeros):

4. The attacker forward the tampered CHALLENGE_MESSAGE to the Client.
5. The Client processes the CHALLENGE_MESSAGE. Because the attacker injected the rogue Channel Binding into the challenge, the client unknowingly includes it in the final NTLM AUTHENTICATE_MESSAGE and signs the entire NTLM_V2_CLIENT_CHALLENGE using the user’s password hash:

6. The client sends this NTLM AUTHENTICATE_MESSAGE to the attacker. Because the attacker modified the NTLM CHALLENGE_MESSAGE in Step 3, if there was a MIC calculated by the client, it’d mathematically be invalid, and would cause the target server to reject the authentication. To bypass this, the attacker simply removes the MIC from the NTLM AUTHENTICATE_MESSAGE entirely.
7. The attacker relays the final, tampered NTLM AUTHENTICATE_MESSAGE to the target server.

This vulnerability is tracked as CVE-2019-1019.

In both the Drop the MIC 2 attack, where a malicious msvAvFlag is injected, and the EPA bypass, where a rogue MsvAvChannelBindings field is injected, the target server receives an NTLM AUTHENTICATE_MESSAGE containing two conflicting AVPairs. What’s amazing is that the server only considers the first field it encounters and ignores any duplicates that follow. The first field is the one the attacker injects during the CHALLENGE_MESSAGE. The second is the one injected by the client in the AUTHENTICATION_MESSAGE. In other words, the server ignores the AVPair of the Client.

Since both data structures are included in the blob signed by the user’s NTLM hash and sent back to the server, the server (1) accepts the attacker’s rogue channel binding, and (2) mistakenly believes the client’s message does not include a MIC.

In other words, this allows the attacker to bypass both MIC, and EPA protections.