Windows Hashes

So I keep hearing people talk about pass-the-hash and Windows credentials, but they are using the terms incorrectly. This leads me to believe that there is some confusion here, which is understandable. Windows stores and transmits credentials in a variety of ways that can get confusing. A good place to start is to talk about what NTLAN Manager (NTLM) is.

NTLM

NTLM is the protocol used in Windows environments to authenticate systems and users in both networked and local contexts. The protocol has changed as new versions of Windows and Windows Service Packs have been released, but the demand for backwards compatibility has left facets of Windows authentications an easy attack point. A quick disclaimer, I am purposefully leaving quite a bit of content out of this article to make it a quick read and to save myself the time it would take to do a deep dive for each peice. In the unlikely event that anyone finds this topic facinating I would be happy to cover each topic in detail.

The Locally Stored Hash

In reading about security in books and blog posts you will commonly see references to NT or LM (hashes). In an effort to keep you password 'secure' Microsoft doesn't store your password in clear text. Instead one-way cryptographic functions are applied to the string you select as your password to generate a hash of the passwords in one of two formats (LM hash or NT hash). So when you log in to your Windows machine at home either the LM (from the days of pre-Win2K environments) or the NT hash were compared to what you typed into the password box to authenticate you. Passwords are stored using one of these hashes depending on the network, Windows version, AD, etc.

This is what you would see on a system that is storing both the LM and NTLM(AKA NT hash) hash. The first hash value (they are separated by :) is the LM portion and the value after is the NT hash.

Q97R0Vu::75EBD90ADE06046CAAD3B435B51404EE:4F39872E3BBD6750BB106EBA15EDC422

As a side note to anyone following along on their own system - to provide compatibility many networks still have LM hashes floating around. Because of this even if the LM hash isn't being used the stored password value will still have a place holder to represent the LM hash (see below). This is the equivalent of 'empty.'

aad3b435b51404eeaad3b435b51404ee

Ok now we know what it is and what it looks like. This is the value that people are talking about when the reference pass-the-hash attacks, due in part to the fact the value is treated as password equivalent (no salt). If I have shell access to the system and execute some post exploitation tool that gathers hashes for me. This is the value I end up with. For a really great rundown on all the possibilities I highly recommend this set of articles by B.G. A Bernardo Damele. For a really great run down on what values stores where and for what reason I highly recommend you take a moment to give this article a good read: Technet

The Hash Transmitted Over the Network

Next lets take a look at the Windows Challenge/Response (NTLM) authentication protocol and the credential hash generated by that process. This is once of those places where there are a lot of variations on how this actually happens based on a few different variables (interactive vs. non-interactive logon etc). For our purposes let's look back at our stored password hash value above. So we see that password equivalent hash value . That is not what Windows transmits over the network when authenticating a remote system. The value actually used in the authentication process utilizes a challenge response mechanism to transmit an protected hash value. So if we have a client system trying to authenticate to a server there is a process that takes place. This is my Barney style summation of what that might look like:

  • Client transmits username to server
  • Sever responds with a random 16-byte challenge value
  • Client encrypts the challenge value using the user's password hash
  • Client sends the newly encrypted challenge to the server
  • Sever checks with domain controller to see if this data matches up

The real point here is that we can still relay this request to gain access to a system or retrieve the users password if we can capture this transmitted value using something like NBNS/LLMNR spoofing, however, this value is NOT password equivalent (ie. it can not be used in a pass-the-hash attack).

In case you need a visual here is an example of what it might look like:

bad-user::HACKME:1122334455667788:5B1655EE1D841C2BBA222BFC3BFCF2B8:01010000000000000DCEFF65A362D1015F70313D0322F9911000000000200060053004D0042000100160053004D0042002D0054004F004F004C004B00990054000400120073006D0062002E006C006F00630061006C000300280073006500720076006500720032003000300033002E0073006D0062002E006C006F00630061006C000500120073006D0062002E006C006F00630061006C0008003000300000000000000000000000002000003CC1AD332BC45294A05472C65B7C9D31EAE6884044919222BBC21A90C7F25C080A001000000000000000000000000000000000000900120048005400540050002F0077007000610064000000000000000000