LM/NTLM Challenge / Response Authentication JoMo-Kun (jmk at foofus dot net) ~ 2010 Microsoft Windows-based systems employ a challenge-response authentication protocol as one of the mechanisms used to validate requests for remote file access. The configured/negotiated authentication type, or level, determines how the system will perform authentication attempts on behalf of users for either incoming or outbound requests. These requests may be due to a user initiating a logon session with a remote host or, in some cases, transparently by an application they are running. In many cases, these exchanges can be replayed, manipulated or captured for offline password cracking. The following text discusses the available tools within the John the Ripper "Jumbo" patch for performing offline password auditing of these specific captured challenge- response pairs. Why might these exchanges be of interest? A primary point of most penetration tests is to find avenues through which the assessor can gain unauthorized access to some resource. This often relies on the compromise of a system's local accounts or the exploitation of some service-level vulnerability. The ability to capture on-the-wire authentication exchanges and to crack the associated password adds another option to the mix. The fact that these exchanges can be cracked aids in demonstrating to clients why one authentication algorithm may be preferred to another. A given server is likely to use one of the following protocols for authentication challenge-response: LMv1, NTLMv1, LMv2 or NTLMv2. It should be noted that these protocols may use the LM and NTLM password hashes stored on a system, but they are not the same thing. For an excellent in-depth discussion of the protocols see the Davenport paper entitled "The NTLM Authentication Protocol and Security Support Provider" [1]. For the purposes of this discussion, the key item of note is that the LMv1 and NTLMv1 protocols consist of a only a single server challenge. This allows an attacker to force a client into authenticating using a specific challenge and then attack that response using precomputed Rainbow Tables. There are a variety of methods for capturing challenge-response pairs, including the use of tools such as MetaSploit and Ettercap. The author's preferred method is to use a modified version of Samba[2]. The provided patch sets the server's challenge to a fixed value (i.e. 0x1122334455667788) and logs all authentication attempts in a format suitable for use with John. The patch also includes a modification to the nmbd application. Nmbd is used to respond to broadcast requests for NetBIOS name/IP information. The modified service simply responds to all requests with its own IP address, often resulting in hosts unknowingly authenticating to the wrong system. Another common method of forcing systems to authenticate to the Samba server is through the use of HTML image source tags. For example, simply inserting the tag "" into a HTML message will cause some email client applications to automatically perform an authentication attempt. Other examples include the use of specialized desktop.ini files and many other mischievous tricks. It is also worth noting that these challenge/response protocols are not limited to the Microsoft File and Print Services. For example, Cisco's LEAP wireless security mechanism, EAP-PEAP and PPTP all utilize a MS-CHAP handshake, or modified variant. The NTLMv1 challenge/response set can be extracted from this exchange and subjected to a brute-force guessing attack. Further discussion on this subject is outside of the scope of this write-up, but would certainly reveal numerous additional uses. The LMv1 challenge-response mechanism suffers a number of technical limitations. As previously noted, only a server challenge is used. This means that if the challenge is set to a constant value, a given password will always result in the same client authentication response. This allows for the precomputation of password / LMv1 responses and their subsequent retrieval using tools such as RainbowCrack. To further exacerbate the issue, the LM hash used during the generation of the LMv1 response converts a password into (at most) two 7 character upper-case passwords. The LM hash is then split into three pieces prior to calculating the LMv1 response. This process greatly reduces the size of the Rainbow Tables which need to be calculated in order to break a given password. For example, the so-called "halflmchall" tables widely available on the Internet utilize only the first third of the LMv1 response to break the first 7 characters of the respective password. The netnlm.pl script discussed in this document can be used to attempt to break the remaining characters of the password and its original case-sensitive version. The following is an example of cracking a captured LMv1/NTLMv1 challenge/response set. Example LMv1/NTLMv1 Challenge/Response (.lc Format): user::WORKGROUP:5237496CFCBD3C0CB0B1D6E0D579FE9977C173BC9AA997EF:A37C5C9316D9175589FDC21F260993DAF3644F1AAE2A3DFE:112233445566778 LMv1 Response: 5237496CFCBD3C0CB0B1D6E0D579FE9977C173BC9AA997EF NTLMv1 Response: A37C5C9316D9175589FDC21F260993DAF3644F1AAE2A3DFE Server Challenge: 112233445566778 RainbowCrack look-up of password's first 7 characters (upper-cased) using first third (8 bytes) of LMv1 response: % rcrack halflmchall/*.rt -f 5237496CFCBD3C0C Result: CRICKET First netntlm.pl Pass (Crack Remaining Characters): % netntlm.pl --file capture.lc --seed CRICKET Result: CRICKET88! Second netntlm.pl Pass (Determine Case Sensitive Password)[a]: % netntlm.pl --file capture.lc Result: Cricket88! [a] Note that the case-sensitive password will be shown about a third through the script's output following the text: "Performing NTLM case-sensitive crack for account". The following is an example of cracking a captured NTLMv1 challenge/response. If the LMv1 and NTLMv1 response hashes within a given client response are identical, it typically means one of two things: either the client machine is configured to send only a NTLMv1 response (e.g. LAN Manager Authentication Level Group Policy Object set to "Send NTLM response only"), or the user's password is greater than 14 characters. If the password is indeed over 14 characters in length, it is unlikely a suitable Rainbow Table set is available and brute-force guessing will be exhaustively time-consuming. Example NTLMv1 Challenge/Response (.lc Format): user::WORKGROUP:A37C5C9316D9175589FDC21F260993DAF3644F1AAE2A3DFE:A37C5C9316D9175589FDC21F260993DAF3644F1AAE2A3DFE:1122334455667788 John Usage: % john -format:netntlm capture.lc The LMv2 and NTLMv2 challenge/response protocols both employ unique client challenges. This additional data effectively defeats the ability to precompute password/response pairs via Rainbow Tables. It should also be noted that despite its name, the LMv2 response is computed using a NTLM hash. This results in a much harder-to-crack response hash, as the password was not truncated to seven characters or upper-cased during the process. The use of NTLMv2 is now the default policy within Microsoft Windows Vista and Windows 7. Its use can be enforced for older versions via the LAN Manager Authentication Level Group Policy Object ("Send NTLMv2 response only" (level 3 or higher)). Example LMv2 Challenge/Response (.lc Format): user::WORKGROUP:1122334455667788:6FAF764ECFDF1D1D9E7BA7B517190F3B:E15C1A679C7609CE John Usage: % john -format:netlmv2 capture.lc Example NTLMv2 Challenge/Response (.lc Format): user::ATS-W759420A:1122334455667788:02E12C3C2B2F5799D2C1A7661AE80491:0101000000000000B0736308F1C9CA01DABA9E3A11AFD91F0000000002001000310030002E0030002E0032002E0032000000000000000000 John Usage: % john -format:netntlmv2 capture.lc [1] http://davenport.sourceforge.net/ntlm.html [2] http://www.foofus.net/jmk/smbchallenge.html