Demystifying the NTDS #3 - Password Hashes

Part 3 : Password Hashes

In this article, we discuss the most sensitive data that is stored in the NTDS: the cryptographic hashes of user passwords (also called hash or password hashes). In the previous article Part-2 – The Datatable, we listed all the columns of the datatable according to the different functional levels of Active Directory (cf. https://github.com/xmco/ntds_extract/tree/main/Part-2-La-Datatable )

Within the ATTk589879 and ATTk589914 columns, we will find the cryptographic hashes of user passwords in two formats: LM (LAN Manager) and NT (NT hash).

Attacks on LM and NT hashes can be classified into several categories, including:

1 – Brute force attacks: These attacks consist in trying all possible combinations of characters until the one that corresponds to the cryptographic hash of the password is found. Tools such as Hashcat and John the Ripper are commonly used;

 2 – Dictionary attacks: Dictionary attacks use a defined set of words and phrases, often taken from lists of common passwords or dictionaries, to try to guess the passwords corresponding to LM and NT cryptographic hashes. Attackers can also use variations of these words by applying simple transformations, such as character substitution or adding prefixes and suffixes. Tools such as John the Ripper or Hashcat are also used;

 3 – Rainbow Tables attacks: Rainbow tables are pre-calculated data structures that allow passwords to be quickly retrieved from their cryptographic hashes. These are faster than brute force and dictionary attacks because they take advantage of memory space to reduce search time. Tools such as RainbowCrack and Ophcrack are popular for performing this type of attack.

We systematically perform these three attacks during our password audits conducted through our IAMBuster managed service.

The LM format

The LM format is the oldest and has been considered obsolete by Microsoft since 2006 and the release of Windows Vista. In fact, the password size cannot actually exceed 14 characters and is not case-sensitive (lowercase letters are converted to uppercase). In addition, by construction, it is weak against cryptanalysis attacks which only require bruteforcing two 7-character uppercase passwords. Here is a diagram illustrating the creation of an LM hash.

schema hash LM
Description of the creation of a LM hash (1)

1 – Conversion of the password to uppercase

2 – Padding addition if the length of the password is less than 14 characters (NULL character)

3 – Separation of the password into 2 passwords of 7 characters (the password is truncated to 14 characters)

4 – Application of the DES algorithm to encrypt the arbitrary character string “KGS!@#$%” using the 2 passwords as keys

5 – Concatenation of the two results to obtain the LM hash

An attacker who obtained LM hashes can recover the original password via different types of attacks that can take from a few minutes to a few hours. One of them relies on a time/memory trade-off, by using pre-calculated result tables, called Rainbow Tables.

Since Windows Vista and Windows Server 2008, LM format generation is disabled and a GPO is also available. The password is only stored in the NT format. When a user account has an LM hash associated with a non-empty password, it is necessary to ensure that storage in the LM format is disabled via the GPO (2) ‘Network security: Do not store LAN Manager hash value on next password change’ and, above all, to change the password after application.

Although obsolete and not generated by default for over 15 years, LM-format hashes are still used in many companies (between 1 and 3% of passwords according to our IAMBuster audits). Removing LM-format hashes requires changing the password after applying the GPO, so it is still common to see old service accounts whose passwords have never been changed and still have their LM hash.

The NT format

The NT format appeared in 1997 with Windows NT 4 Service Pack 3 and corrects the flaws of the LM hash:

The encoding is switched to Unicode UCS-2 which increases their potential complexity (each character is encoded on two bytes)

  • The supported password length increases from 14 to 255 characters
  • The DES algorithm is abandoned in favor of MD4
  • The latter is much more resistant to the attacks mentioned in the introduction.

Below is a table that shows some examples of the two password storage formats.

Mot de passeHash LMHash NT
jedimaster1934425df90e03b45acc35a98e0ae6f9454da4021f7b054cbdeb3885ad8d1b1c
wcsRb0lePdhS52f2eadda0a87897b214e2be51e01fadfb1588d471d3f3fb8cee550b916d2d04
(empty)aad3b435b51404eeaad3b435b51404ee31d6cfe0d16ae931b73c59d7e0c089c0
Password LM hash NT hash

Note : It is very common to observe many user accounts with empty LM and NT hashes. These accounts are generally from another domain that has a trust relationship. Their password hashes are actually stored in the NTDS database of another Active Directory.

Another interesting point is the absence of salt in the hash generation. The salt is a random string added during the generation process to make a hash unique. Thus, with salt, two identical passwords will have a different generated hash. However, this absence of salt makes it possible to know the number of identical passwords by comparing the hashes without needing to know the cleartext value.

Note : Comparing hashes makes it easy to identify users who, when they have multiple accounts for different uses, reuse the same password on their accounts. A common example is an administrator who uses the same password for their desktop account and privileged administration account.

Extraction in the NTDS

In the NTDS, the fields corresponding to cryptographic hashes are as follows:

HashColumnLDAP Name
LMATTk589879dBCSPwd
NTATTk589914unicodePwd

However, the hashes stored in the NTDS are encrypted and not directly accessible like other attributes such as the user login or description.

To exploit user hashes, it is necessary to decrypt them with the PEK (Password Encryption Key). This key is used to encrypt “sensitive” data in the NTDS and has the same value for the entire domain. Thus, the key used for the primary domain controller’s NTDS will be identical to the key for the secondary domain.

The PEK is also stored in encrypted form in the NTDS itself (column ATTk590689). To decrypt it, the BOOTKEY, stored in the SYSTEM registry hive (C:\Windows\System32\config\SYSTEM), will be needed. Without the SYSTEM hive, you will not be able to access encrypted data contained in the NTDS such as password hashes, historical password hashes, and other additional attributes that may contain secrets (supplementalCredentials).

Note : When an NTDS backup is made with the NTDSUtil utility, the SYSTEM hive is always exported with it.

Microsoft has implemented three layers of encryption to protect NT and LM hashes contained in NTDS. Here are the three steps:

  • Decrypt the PEK with the BOOTKEY (RC4 – layer 1).
  • Decrypt the hash for the first time with the PEK and RC4 (layer 2).
  • Decrypt the hash for the second time with the DES algorithm and a key based on the user’s RID(3) (layer 3).

Here are some tools available to perform the operation:

  • The Get-ADDBAccount module from DSInternals: https://github.com/MichaelGrafnetter/DSInternals/
  • The Secretsdump module from Impacket (https://github.com/fortra/impacket)

Example of the process of extracting user hashes with the Impacket module:

Command used to extract user hashes from a NTDS file
Command used to extract user hashes from a NTDS file
  1. The BOOTKEY is extracted from the provided system hive.
  2. The user hashes are retrieved (ATTk589879 and ATTk589914 columns for each user object).
  3. Search for the PEK (object with non-empty ATTk590689 column).
  4. The PEK is decrypted with the BOOTKEY (layer 1).
  5. Decrypt the user hashes with the PEK (layer 2 and layer 3).

Password exploitation:

As previously mentioned, a user password in LM format will not resist you for long due to its design. However, the NT format, even after 20 years, remains resistant to brute-force cryptanalysis attacks, as long as the password is complex enough. Thus, a password derived from the login, derived from the name of the company, or present in a dictionary on the Internet will not resist the various cracking attacks to retrieve its clear value for long. However, a password of more than 12 random and varied characters (special characters, numbers, etc.) will be very resistant.

Although a strong password in NT format cannot be broken in a reasonable time, an attacker can skip this step. Indeed, through the NTLM network authentication protocol, still ubiquitous in Active Directory environments, only the user’s password hash is necessary to connect to a remote service such as SMB. This technique, discovered in 1997 (but really exploited 10 years later), was dubbed “Pass-The-Hash” and still works today.

We will come back to password hashes in other parts of the series (krbtgt service account, Kerberos tickets, etc.).


2) Group Policy (GP) allows for centralized management of computers and users in an Active Directory environment.

(3) The Relative ID (RID) is a part of the Security Identifier (SID), which is a unique and immutable alphanumeric security identifier assigned in Active Directory for each system, user, or object.

Translated by Florian Duthu

Bastien Cacace

Découvrir d'autres articles

  • NTDS - 6
    Active Directory

    Demystifying the NTDS #6 – LAPS, particular attributes (1/2) 

    Lire l'article
  • NTDS - 5
    Active Directory

    Demystifying the NTDS #5 – Machine Accounts in the Active Directory 

    Lire l'article
  • ntds 4
    Active Directory

    Demystifying the NTDS #4 – Active Directory Accounts

    Lire l'article