NTLM Passwords: Can’t Crack it? Just Pass it!

In my prior article, “Cracking 14 Character Complex Passwords in 5 Seconds” we looked at how safe Windows LM based passwords were. But what about NTLM based Passwords?

Windows systems usually store the NTLM hash right along with LM hash, the NT hash being more secure. What many readers wanted to know is how much longer would it take to access the user account, if only the NTLM hash was available?

This is a great question, and the answer is, if certain circumstances are met and a certain technique is used, it could take the same amount of time. Even more shocking is the fact that it may actually be quicker.

Let me explain, if you can retrieve the LM or NT hashes from a computer, you do not need to crack them. There is really no need.

Sometimes you can simply take the hash as-is and use it as a token to access the system. This technique is called “Pass the Hash”.

Several programs exist that perform “Pass the Hash” type attacks. In this example I used the “Pass the Hash” capability of Backtrack 4.

What is nice about this is that once you retrieve the hash, you can copy the hash and place it right into Backtrack 4’s “Pass the Hash” routine.

I will not show the step by step process, but will show you the passwords used and the outcome. The password hashes are taken from an updated Windows XP SP3 system and a Windows 7 system.

Without further ado, let’s see this in action.

First we will try feeding the XP hash for the 17 character password %P”m<[87cR?^)+=Tu into the “Pass the Hash” program, and see if we can log in with it.

But before we do, let’s make sure the Objectif’s Online XP Scanner can’t crack it:

Hash: aad3b435b51404eeaad3b435b51404ee:473f053cd2e842a2faacff9d4888f051
Password:  LM hash empty, NT Hash cannot be cracked by this table.”

  

OK, so we know that we only have an NT hash. Let’s see if we can get into the system by just passing the hash.

Placing the hash into the program, a few seconds later we get this:

 

Process 3540 created.
Channel 1 created.
Microsoft Windows XP [Version 5.1.2600]
© Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>

An open session with the PC and a remote shell. Looks like it worked…

Now let’s try the same 17 character complex password on the Windows 7 PC.

Placing the Windows 7 hash into the program, we get this:

 

Process 3392 created.
Channel 1 created.
Microsoft Windows [Version 6.1.7600]
Copyright © 2009 Microsoft Corporation. All Rights reserved.

C:\WINDOWS\system32>

A Windows 7 remote shell. Wow, that worked too.

Let’s try one last one:

Long pass phrases with multiple words are more secure right?

Password:  TheQuickBrownFoxJumpsOverTheLazyD0g!

And the results? A Windows 7 command prompt.

Does the password length make any difference at all? Using this technique the answer is no. The password length or complexity made no discernable difference at all, because we are just passing the hash as-is and not cracking it.

What can be done to prevent this type of attack? Using the built in Windows firewall with the Windows 7 machine was a hindrance.  

I also found that this attack would not work at all on Windows 7 if the User Account Control (UAC) setting  was turned on to any level except “Do Not Notify Me”.

The utility that many complained about in Windows Vista (and turned off!) actually does improve the security of your system.

Additionally, turning off LM and NTLM altogether and enabling NTLMv2 thwarted this attack.

This was accomplished by setting the authentication level to “Send NTLMv2 response only\refuse LM & NTLM” in the security policy.

Next, one would wonder about just using Kerberos authentication. From what I saw, there seems to be no sure fire way to force Kerberos across the board.

Also, Infoworld released an interesting article in April called “Don’t count on Kerberos to thwart pass-the-hash attacks”.

Kind of makes multiple authentication methods look pretty enticing doesn’t it?

Cross-posted from Cyber Arms

Note: the views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post. Infosec Island reserves the right to remove or edit the content of all material submitted by our members.

View the original article here