JUN. 3, 2015


On a Windows domain, users authenticate to resources like file shares using the Kerberos protocol by default. Older
versions of Windows defaulted to the NTLM protocol, which is still enabled on newer systems (in the updated NTLMv2
form), but only used by default when accessing a non-domain resource, or accessing a server by IP address instead of

The NTLM protocol uses a challenge-response handshake based on the hash of the user’s password to authenticate the
user. For example, suppose the administrator Alice needs to see the files on a web server named WEBSERVER1 in a Windows
domain. Since the hash of Alice’s password is only available on a domain controller or Alice’s system, when she
accesses WEBSERVER1, WEBSERVER1 must pass through the challenge and response to a domain controller to authenticate

NTLM Pass-Through Authentication. Source: Microsoft

Kerberos is based on the domain controller granting tickets to named resources. When logging in, Alice obtains a
Ticket-Granting-Ticket (TGT) from a DC which Alice then presents back to a DC whenever necessary to obtain service
tickets to access remote servers, such as WEBSERVER1. This ticket will then be authenticated by WEBSERVER1’s secret
hash, which is known only by the DC and WEBSERVER1, and contain all the information necessary to authenticate Alice to
WEBSERVER1. Now WEBSERVER1 no longer needs to talk to a DC for each authentication, since Alice’s computer already did,
and the DC only needs to validate the user’s password once. This elimination of challenge-response helps Kerberos
improve speed, one of its main advantages.

Kerberos Authentication. Source: Microsoft

Critically for security, this process introduces another advantage; WEBSERVER1 no longer observes a challenge-response
based on Alice’s password. If Henry the hacker has managed to compromise WEBSERVER1, as frequently happens to
internet-facing web servers, Henry will want Alice’s password to take over the rest of the network, but he won’t see
any indication of it by passively listening, even if Alice remotely authenticates to and manages WEBSERVER1.

Henry could try to guess Alice’s password on the live network, but after a few tries, he will lock out Alice’s account,
preventing him from guessing further and alerting Alice that something is wrong. On the other hand, if Alice’s computer
used NTLM to authenticate to WEBSERVER1, Henry would be able to copy the challenge-response back to his own computer
and crack it offline. NTLMv1 and earlier can be considered completely broken, and as a result are now disabled by
default, but NTLMv2 can still be brute-forced offline. A decent computer can try 1 billion passwords per second against
an NTLMv2 challenge-response and has a good chance at cracking the password quickly, even if it was a complex password.
Since this happens offline, no alerts will be triggered and Alice’s account will not be locked out. In contrast, if
Alice’s computer uses Kerberos, Henry no longer sees any network traffic based on Alice’s password and so cannot launch
an offline brute-force attack.


The good news for Henry is that as long as NTLMv2 is enabled on Alice’s computer (and it is enabled by default), he may
be able to get Alice to downgrade from Kerberos. While proper downgrade techniques from a higher version of NTLM/LM to
a lower version have been published and implemented before (but are now generally blocked by NTLMv2 minimum version policies), we’re
unaware of any transparent downgrade attacks from Kerberos to NTLM, since it was designed to prevent that. However,
Henry can still achieve a downgrade with the following methods if some additional requirements can be met:

  1. Supply a link with an IP Address
    The first option is the well-known method for using an IP address in the path to the authentication target.
    Unfortunately, this only works if Henry has control over the path that Alice is accessing. Typically this
    requires Henry to send a link to Alice or place UNC links to his IP address in files in open fileshares or
    intranet sites. Although this frequently works, some of these actions may not be available in different
    networks, and/or Henry may not want to risk detection via this method.
  2. Block Kerberos from initiating system
    The second option is available if Henry is able to block access to the DC from Alice’s computer. This could
    happen if WEBSERVER1 is on the same subnet as Alice’s computer and can ARP spoof Alice’s computer, or if it can
    observe DNS requests looking for the DC and spoof responses, or if Henry can launch a denial-of-service attack
    on the DC (which would cause lots of problems) or just gets lucky and there is a network failure between Alice
    and the DC. In this case, Alice will receive a warning and password prompt when accessing WEBSERVER1 by name:

    But if Alice puts in her username and password, her computer will still send the NTLMv2 challenge-response to
    WEBSERVER1 for Henry to attempt to crack.

  3. Block Kerberos on authentication target
    A third option is to prevent Kerberos from functioning on the authentication target (WEBSERVER1). Henry can
    accomplish this by forcing only incompatible Kerberos encryption types on WEBSERVER1. For example, in a default
    configuration, Windows systems will support RC4, AES128, AES256, and above. Henry can disable support for those
    encryption types and only enable support for the legacy DES modes by setting the SupportedEncryptionTypes DWORD
    value of the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\kerberos\parameters registry key to
    3 (instead of 0x7ffffff8) and restarting. Once Alice tries to access the system, after about a 30-second
    timeout, she will receive a nondescript “Windows cannot access…” error:

    As this error is a very common error that can come up due to any of a number of network issues (e.g. DNS), in
    our experience, administrators will attempt to retry using the system’s IP address. In this case, NTLMv2 will
    once again be used and can be cracked offline.


The most effective remediation against this attack is to disable the use of all NTLM protocols, using group policies
first implemented in Windows Server 2008r2. By blocking outbound NTLM requests from domain systems, clients will no
longer send out NTLM authentication to any servers that have not been specifically exempted.

Another effective method for remediation of this attack is to enforce the use of smart cards. When an account is set to
require smart card authentication, the NTLM hash will be randomized into 128 random bits, which is well beyond the
reach of bruteforce cracking. Smart cards have many other benefits, but do entail additional costs and logistics issues
as well. However, using smart cards will not stop the related NTLM relay attack which is beyond the scope of this blog post. Disabling NTLM either client-side
or server-side or domain-wide is required to prevent the NTLM relay attack.


The following procedures will show how to extract an NTLMv2 challenge/response from a standard pcap packet capture and
crack them with oclHashcat

  1. Open in Wireshark and copy out server challenge (NTLMSSP_CHALLENGE packet)export a subscription: wecutil gs
    “Powershell Invocation” /f:xml >Powershell.xml

    It will be displayed as: “NTLM Server Challenge: <16 hex digits>” (in our case, “NTLM Server Challenge:

  2. Copy out the hash (HMAC-MD5, a.k.a. NTProofStr in Wireshark; in the NTLMSSP_AUTH packet)

    It will be displayed as: “NTProofStr: <32 hex digits>” (in our case, “NTProofStr:

  3. Copy out the entire “NTLMv2 Response” blob as a hex stream

    It will copy out as a long hex string of variable length. It may be shorter or longer than this example:

    001bca888d35b2e21ca00000000020010004a0055005200410053 0053004900430

  4. This hex string will start with the same bytes as the NTProofStr. Remove those. Once removed, it will most
    likely start with 0101000000000000:


  5. Now save the SMB domain name and username (will be visible in the packet title)

  6. Combine all of the above information into a single oclHashcat-compatible line (format
    Username::Domain:ServerChallenge:NTLMv2hash:entire NTLMv2 response except the HMAC that was in the preceding
    field) and save in a file “ntlmv2.txt”


  7. Run oclHashcat to crack it, specifying “5600” as hash type oclHashcat64 -m 5600 ntlmv2.txt wordlist.txt
  8. Wait for oclHashcat to crack the hashes and display the passwords.