Thursday, April 21, 2011

Attacking LM/NTLMv1 Challenge/Response Authentication

In Part 1 of the “LM/NTLMv1 Challenge/Response Authentication” series I discussed how both the LANMAN/NTLMv1 protocols operate and the weaknesses that plague these protocols. In this post I will demonstrate how attackers leverage these weaknesses to exploit the LANMAN/NTLMv1 protocols in order to compromise user credentials.

For the remainder of this article I will be focusing on attacking the SMB protocol (Windows file sharing) as this is where LANMAN/NTLMv1 is most commonly used.

Capturing the Response

In order to capture a client’s LANMAN/NTLMv1 response, attackers will often utilise one of two methods:

  1. Force the client host to connect to them
  2. Conduct a man-in-the-middle (MITM) attack and “sniff” the client’s response

To demonstrate these methods, I will be using the Metasploit Framework or Cain and Abel respectively.


In order for a client host to connect to us, we first need to create a listening SMB service that will accept incoming connections. Fortunately, the Metasploit Framework has already provided us with a module to do this :)

1. Fire up Metasploit

2. Load the SMB server module

msf > use auxiliary/server/capture/smb

3. Set the server host address

msf > set srvhost x.x.x.x

4. Run the module

msf > run


Now that we have a listening SMB service, all that is needed is for a victim to connect to our machine. By calling “info” on the SMB server module, the module’s description explains “The easiest way to force a SMB authentication attempt is by embedding a UNC path (\\SERVER\SHARE) into a web page or email message.”

A successful capture will look something like this:


Cain and Abel

The second method we can use to capture a client’s response is by conducting a MITM attack using Cain.

1. Start Cain’s sniffer

2. In the “Sniffer” tab, select the “Plus” icon and choose the hosts victims to poison.


3. Activate Cain’s ARP Poison Routing feature

4. Select the bottom “Passwords” tab and wait for the client’s response to appear in the left pane under “SMB”.


Cracking the Response

Three approaches are often referenced when cracking a LANMAN/NTLMv1 response:

  1. Rainbow Tables
  2. Dictionary Attack
  3. Brute Force

All of these methods use what is known as the “known challenge attack” technique. In order to crack the LANMAN/NTLMv1 response we are exploiting the fact that the only randomness (or entropy) that makes the LANMAN/NTLMv1 response unique every time is the challenge sent by the Server. As the attacker is always the Server, we can send the client a static challenge. This effectively defeats any randomness in the protocol. Because we now know what the challenge will be every single time, we can effectively crack the LANMAN/NTLMv1 response as if it were a static response.

Note: It is common practice to use \x11\x22\x33\x44\x55\x66\x77\x88 as the static challenge.

Before we look at each of these methods it should be noted that LANMAN responses are only configured on Windows XP and Server 2003 system (by default). Windows 7, Vista and Server 2008 systems are configured to utilise NTLMv2 by default.

A simple test to check which protocol is currently in use is to see if the LM Hash and NT Hash are different in the capture logs. A difference in these hashes would indicate LANMAN is in in use. If these hashes are the same, LANMAN is disabled and NTMLv1 is in use.



1. Rainbow Tables

As you would remember from Part 1 of this series, the difference between LANMAN challenge/response and NTLMv1 is that the former uses the locally stored LM Hash whilst the latter uses the locally stored NT Hash. This fundamental difference makes a substantial difference when it comes to cracking the LANMAN response. Because LANMAN utilises the weaker LM hashing algorithm, an attacker can trivially obtain the plain-text of a LANMAN response within minutes.

The quickest approach to cracking the LANMAN response is by using rainbow tables. Due to the nature of the LM Hash, rainbow tables are very effective against this hash type. The rainbow tables necessary for this exercise are called “halflmchall” and can be found here. To use these rainbow tables the rcracki_md tool will need to be downloaded.

The following rcracki command will inflate the rainbow table chains and attempt to find the plaintext password for the LANMAN response:

> rcracki_mt.exe –h b4dfbf8fa9eaac3 "C:\rainbowtables\*.rti”

Note: We are only cracking the first 8 bytes of the captured LANMAN response. Due to the nature of the LM Hash, we are only able to use rainbow tables on the first portion of the LANMAN response. The rest we will have to use brute-force.

A successful result will look like this:


The remaining characters we can brute force using the Metasploit “halflm_second.rb” script. This can be found in the “tools” directory in the root Metasploit directory. The script is run as follows:

# ruby halflm_second.rb –n 5b4dfbf8fa9eaac3d939df32af8c61a0c122288e90918896 –p ADMINIS

Where –n is the LANMAN response and –p is the discovered plaintext.

Whilst it is possible to crack an NTLMv1 response using rainbow tables, I have yet to come across any that have been pre-computed. Due to the nature of NT Hashes, NTLMv1 rainbow tables would be far more time consuming to generate and require large amounts of disk space.

2. Dictionary Attack

The second method often used to crack LAMNAM/NTLMv1 responses is a dictionary attack.

I will demonstrate the dictionary attack using two common tools:

  • John the Ripper
  • Cain and Abel

John the Ripper

The following syntax is used to mount a dictionary attack against LANMAN responses:

# ./john –format:netlm /tmp/capture.txt

Where capture.txt is the file containing the LANMAN response. The format of capture file must be as follows:


Where test is the username, home is the workgroup/domain, the first hash is the LM Hash, the second hash is the NT Hash and the final value is the challenge.

To use john against NTLMv1 specify netntlm with the -format flag.

Cain and Abel

If Cain was used to sniff the capture, right click on the entry and select “Send to Cracker”.


In the “Cracker” tab, right click on the entry and choose your appropriate option from the “Dictionary Attack” menu option.


Note: For a list of dictionary files see my post on wordlists.

If you did not capture the response using Cain, and are importing a capture file, the file must be in the following format:


3. Brute Force

Whilst crude, brute-forcing can be effective against weaker passwords.

To brute-force in Cain, follow the steps detailed above and select “Brute-Force Attack” from the menu item.

For the sake of brevity, I will not go into how John the Ripper can brute-force hashes. This is quite a lengthy topic in itself. Further reading on this topic can be found using Google.

Wednesday, April 20, 2011

LM/NTLMv1 Challenge/Response Authentication Explained

The Microsoft Windows platform uses a myriad of protocols to authenticate users across a network. Two such protocols widely in use today are the LANMAN challenge/response and NTLMv1 protocols. Whilst newer, more secure protocols (such as NTLMv2) are ready to take their place, LANMAN challenge/response and NTLMv1 are still widely deployed today for reasons of interoperability. As with most things Microsoft-related, ubiquity often equates to exploitability.

In this two part series I will discuss how the LANMAN challenge/response and NTLMv1 protocols operate, how malicious users can take advantage of their shortcomings, and best practice recommendations for securely deploying these protocols.

Microsoft Windows supports two primary algorithms for locally authenticating users. These algorithms generate what’s known as an “LM Hash” or an “NT Hash”.

Enabled by default in Windows NT, 2000, XP, and Server 2003, the LM Hash has become synonymous with bad hashing practices over the years. Used for backward compatibility, this older hashing method has several inherit flaws, making it trivial for attackers to crack LM Hashes within minutes.

The second, more secure, hashing algorithm generates what’s known as an NT Hash. Exclusively on by default in Windows Vista, 7, and Server 2008, this hash is generated using the MD4 hashing algorithm.
Note: By default, Windows XP stores both the LM Hash and the NT Hash.

Whilst this reading does not require a technical understanding of how the NT Hash and the LM Hash are generated, some readers may like to broaden their understanding of how these hashes are generated. The following paper provides an in depth discussion on the topic.

Before we begin looking at the Microsoft network authentication protocols, it is important to note that LANMAN challenge/response and NTLMv1 are the same protocol except for one key difference: LANMAN challenge/response utilises the locally stored “LM Hash” whilst NTLMv1 uses the locally stored “NT Hash”. Aside from this, the protocols (for all intensive purposes) operate exactly the same way.

The LANMAN challenge/response and NTLMv1 protocols authenticate users in the following manner:
1. Client sends an authentication request to the Server.
2. A protocol negotiation occurs between the Client and Server.
3. The Server sends the Client a (pseudo-random) 8-byte challenge.
4. The Client sends a 24-byte response.
5. The Server authenticates the Client.
The Client’s response is made up of the following steps:
  1. Split the locally stored 16-byte hash (LM Hash for LANMAN challenge/response or NT Hash for NTLMv1) into three 7-byte portions.
  2. Using the DES encryption algorithm, encrypt the Server’s challenge three separate times using each of the keys derived in Step 1.
  3. Concatenate the response of all three outputs.
Now, at first glance this protocol seems fairly sensible. But you may have noticed something in Step 1 of the Client’s response. If the hash (LM or NT) is 16-bytes long, how do we break it up into three 7-byte portions? i.e. 7 does not divide into 16 evenly.
To combat this unevenness, the LANMAN and NTLMv1 algorithms pad the third key with 5 nulls. By doing this, we now have three evenly portioned keys.
So, the response process in its entirety looks something like this:
Now that we have an understanding of how the LANMAN challenge/response and NTLMv1 protocols work, let’s take a look at some of the deficiencies these protocols inherit.
  1. There is no “diffusion” within the protocol. That is, there are three separate parts to the response that could individually be attacked. Diffusion would ensure each part of the DES output relied on the previous – increasing the overall complexity.
  2. DES is old and considered cryptographically weak by many.
  3. The third DES key is weak. As the third DES key is padded with 5 nulls, there are only 2^16 possible unknown values. This would take a modern computer seconds to crack.
  4. There is a lack of randomness. The only randomness occurring within the algorithm is that provided by the pseudo-random challenge generated by the server.
In Part 2 of this series I will demonstrate how attackers can take advantage of the aforementioned deficiencies in the LANMAN challenge/response and NTLMv1 protocols.