Your Session Key is My Session Key: How to Retrieve the Session Key for Any Authentication

As announced in our recent security advisory, Preempt researchers discovered a critical vulnerability which 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 in order 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 & NETLOGON Brief Overview

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

DevOps Unbound Podcast

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 the 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 which was sent to the server. The domain controller validates the NTLM challenge & response and sends a response which 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. In order to prevent accounts from being able to retrieve session keys for sessions which were not addressed to them, proper validation methods need to be in place on domain controllers.   

NTLM authentication flow

Figure 1 – NTLM authentication message flow


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

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

Microsoft since then fixed the issue by comparing the target server in the NTLM_AUTHENTICATION request to the machine account which established the NETLOGON secure channel. If the latter are different, the domain controller would deny the request.


We discovered that although domain controllers would deny requests if the expected computer name is different than the one which 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, are just copied from the previous NTLM_CHALLENGE message which 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.

Removing target NetBIOS name from the NTLM_CHALLENGE message

Figure 2 – Removing target NetBIOS name 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 3 NTLM messages [NTLM_NEGOTIATE, NTLM_CHALLENGE, NTLM_AUTHENTICATE] were not modified during transit.

The MIC field protects NTLM messages from being modified

Figure 3 – The MIC field protects NTLM messages from being modified

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

Detailed attack flow:

Detailed attack flow

Figure 4 – Detailed attack flow

The following scenario includes 4 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 which 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_CHALLANGE message.
  4.  RELAYER removes the hostname field from the Target Info field in the NTLM_CHALLANGE message and forward the modified message to CLIENT.
  5.  CLIENT responds with an NTLM_AUTHENTICATE message which 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 the 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 the 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 & 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, may result in a successful exploit against this client as well). All the web clients that we tested (IE, Chrome, Firefox) were all 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 which 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!
  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 to reduce the usage of NTLM to scenarios which is 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

How Preempt can Help

Preempt constantly works to protect its customers. Customers who have deployed Preempt have been consistently protected from NTLM relay attacks. The Preempt Platform provides full network NTLM visibility, allowing you to reduce NTLM traffic and analyze suspicious NTLM activity. In addition, Preempt has innovative industry-first deterministic NTLM relay detection capabilities and has the ability to inspect all GPO configurations and will alert on insecure configurations.

For non-Preempt customers, this configuration inspection is also available in Preempt Lite, a free lightweight version of the Preempt Platform. You can download Preempt Lite here and verify which areas of your network are vulnerable.

An additional blog containing an analysis of Microsoft’s patch will be released in the next few days.

We will present a full description of this vulnerability, including many other discoveries and insights this year at Black Hat USA 2019 – stay tuned!

*** This is a Security Bloggers Network syndicated blog from Preempt Blog authored by Marina Simakov. Read the original post at:

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)