ATTACKING WINDOWS FALLBACK AUTHENTICATION

ATTACKING WINDOWS FALLBACK AUTHENTICATION

By MATT WEEKS | THE FRONT LINE
Posted JUN. 3, 2015

BACKGROUND – KERBEROS AND NTLM

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.

ATTACKS

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.

REMEDIATION

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.

APPENDIX – CAPTURING AND CRACKING NTLMV2 HASHES

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:

    f92f4def175c6676220c915c747311420101000000000000e77bf9520f93d
    001bca888d35b2e21ca00000000020010004a0055005200410053 0053004900430
    001001a0055005300470043004200570049004e003700580036003400310004001
    a006a0075007200610073007300690063002e007000610072006b0003003600550
    05300470043004200570069006e00370078003600340031002e006a00750072006
    10073007300690063002e007000610072006b0005001a006a00750072006100730
    07300690063002e007000610072006b0007000800e77bf9520f93d0010600040002
    00000008003000300000000000000001000000002000004a77a2df5709f6953e593
    47bdc2684affb46c6ae1f67af8b8c2700a23cb5f0590a001000000000000000000000
    000000000000000900240063006900660073002f003100390032002e00310036003
    8002e00350030002e0032003600000000000000000000000000

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

    0101000000000000e77bf9520f93d001bca888d35b2e21ca00000000020010004a00
    550052004100530053004900430001001a0055005300470043004200570049004e0
    03700580036003400310004001a006a0075007200610073007300690063002e0070
    00610072006b000300360055005300470043004200570069006e003700780036003
    40031002e006a0075007200610073007300690063002e007000610072006b000500
    1a006a0075007200610073007300690063002e007000610072006b0007000800e77
    bf9520f93d001060004000200000008003000300000000000000001000000002000
    004a77a2df5709f6953e59347bdc2684affb46c6ae1f67af8b8c2700a23cb5f0590a00
    1000000000000000000000000000000000000900240063006900660073002f00310
    0390032002e003100360038002e00350030002e0032003600000000000000000000
    00000

  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”

    Administrator::JURASSIC:f132ae278ad7f7a0:f92f4def175c6676220c915c74731142:
    0101000000000000e77bf9520f93d001bca888d35b2e21ca00000000020010004a00
    550052004100530053004900430001001a0055005300470043004200570049004e
    003700580036003400310004001a006a0075007200610073007300690063002e007
    000610072006b000300360055005300470043004200570069006e00370078003600
    340031002e006a0075007200610073007300690063002e007000610072006b00050
    01a006a0075007200610073007300690063002e007000610072006b0007000800e7
    7bf9520f93d00106000400020000000800300030000000000000000100000000200
    004a77a2df5709f6953e59347bdc2684affb46c6ae1f67af8b8c2700a23cb5f0590a00
    1000000000000000000000000000000000000900240063006900660073002f00310
    0390032002e003100360038002e00350030002e0032003600000000000000000000
    000000

  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.