Threat Defiance Report

Attacking Windows Fallback Authentication


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 name.

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 Alice.

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: f132ae278ad7f7a0”)

  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: f92f4def175c6676220c915c74731142”)

  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.