smallsec
about | contact

Windows Credentials

I spent a little over a decade of my professional career ignoring how Windows stores and uses credentials. When I started to get more into offensive security, specifically finding, stealing, and reusing credentials, I paid a bit more attention. Eventually, I realized that my lack of knowledge was probably more of a liability than anything else and decided to go deep. Here's what I found out.

Security Account Manager

When you create a local user account on a Windows machine, your username and password are stored in the Security Account Manager, a database found in %systemroot%\System32\config\SAM and mounted in the registry under HKEY_LOCAL_MACHINE\SAM. Since it would be rather silly to store the credentials in cleartext, they're stored in their hashed form.

In Windows NT 4.0 SP3, Microsoft introduced Syskey, a utility that encrypts these hashes using RC4. That's why an attacker needs both the Syskey from the SYSTEM hive and the SAM before they can access the stored hashes.

When it comes to the types of hashes you'd find stored on your computer, there are two types: LM and NT.

LM Hashes

LM hashes have been around forever and were stored by default along with the NT hash (if configured) until Windows Vista came along and put an end to that. If you were to look at a hash retrieved post-Vista, you'd still see the hash in LM:NT format, but the LM value will be aad3b435b51404eeaad3b435b51404ee which indicates that it's blank.

If you're feeling sorry for the poor deprecated LM hashing algorithm, take a gander at how LM hashes are made and see if that changes your tune:

  1. Reject any password longer than 14 characters.
  2. Convert password to uppercase.
  3. Pad the password with NULL characters until it is 14 characters long.
  4. Split the password into two 7-character (56-bit) passwords.
  5. Convert each of those passwords into a 64-bit DES key by adding a null bit every 7 bits.
  6. Encrypt the string KGS!@#$% with each of the two keys, creating two 8-byte encrypted strings.
  7. Concatenate the two to form a 16-byte (128-bit) string.

You can probably see some of the problems with this approach.

First entropy is reduced by eliminating mixed-case, then the password is split into two halves. This means that an attacker isn't cracking a 14-character password (9514), they're cracking two 7-character passwords (2 x 957)1.

Next, if your password is less than 8 characters long, KGS!@#$% will be encrypted using a key of 00000000, which results in a known output of aad3b435b51404ee, meaning only the remaining 7-character password needs to be cracked.

Finally DES has long been broken by the horsepower of modern computers. Reduce entropy by several orders of magnitude + weak encryption = security fail.

NT Hashes

NT hashes are the new hotness. They're a lot simpler, they're a lot stronger, and they are a much better dancer than LM hashes could ever hope to be.

Here's how you'd go about making one:

  1. Run the password through the MD4 hashing algorithm.

What about NTLM? NTLMv1? NTLMv2? Net-NTLM? WTF is a Kerberos?

This is something that confused me as well. When hashes are stored, they exist as LM, NT, or both. When they are transferred across the network, they pick up some extra baggage as a result of the challenge/response authentication process2.

There are three possible challenge/response mechanisms used in Windows networks: LM, NTLM, and Kerberos.

In ascending order of both security and complexity, here are our options:

  1. LM
  2. NTLM/NTLMv1
  3. NTLMv2
  4. Kerberos

To make matters worse, many popular tools refer to NTLMv1/v2 as NetNTLMv1/v2. These terms do not appear anywhere on Microsoft's site, but you're going to run into them so you may as well know.

Picking a Protocol

So what gets used when? Technically that depends on the environment, but realistically you're going to be dealing with either NTLMv2 or Kerberos v5.

The default since Windows 2000 is Kerberos, but in certain circumstances NTLM will be chosen instead. These circumstances are:

Here's what happens after you enter a username and password:

  1. The Local Security Authority (LSA) contacts the Security Support Provider Interface (SSPI), which is sort of an authentication clearinghouse for Kerberos and NTLM.
  2. SSPI sends the credentials to the Kerberos Security Support Provider (SSP).
  3. Kerberos SSP contacts the Kerberos Key Distribution Center (KDC), which runs on each domain controller in an Active Directory domain, and is responsible for providing the tickets that grant a. user or computer access to resources. The Kerberos SSP also determines whether the local computer or domain name was referenced during logon.
  4. If the domain name is referenced and the KDC knows the user, Kerberos authentication proceeds.
  5. If the username is not recognized, the KDC passes an error message to the SSPI, which restarts the process at 1, but instead uses the NTLM driver.

ELI5

If you're running anything post-Vista, you likely only have NT hashes stored on your system. Unless your sysadmin goes out of his way to make you store LM, which would be a little questionable, but also not uncommon.

NT hashes are just MD4 hashes of your real password and are used as an input into both the NTLM and Kerberos families of challenge/response authentication as the secret key.

The NT hash is password-equivalent, which means an attacker with administrative acccess to your computer (or its backups) can effectively become you without ever knowing what your password is in what is known as a pass-the-hash attack.

We're going to talk more about both NTLM and Kerberos in later posts. For now, just know that Windows will choose which is appropriate and that your NT hash will be used as the shared secret key for both of them.

Resources

  1. The 95 comes from the number of printable ASCII characters. ↩︎

  2. This baggage is represented by the "LM" tacked on to the end. ↩︎

>>