Hash format are modern windows login passwords stored in

Passwords are the main means used by any user to authenticate in any service or system. However, the problem with passwords is that people usually tend to forget them a lot. In this case, they usually consult IT specialists or computer engineers who crack these passwords using various hashing algorithms. And you will know some knowledge about your computer: hash format are modern windows login passwords stored in. But for the sake of convenience, this article also offers a Windows password recovery tool: UnlockGo – Windows Password Recovery, you can crack the computer password at home without bothering others. Let’s dive in!

For Windows operating systems, the hash of the passwords of the users of each machine is found in the SAM (Security Account Manager) file and depending on the version of the operating system, one of two algorithms is used: LM or NTLM.

LM (Lan Manager) encryption is a weak algorithm because of the way it is designed since, for example, it splits the password into two blocks of 7 bytes, converts all characters to uppercase and pads unused bytes with zeros; all of this facilitates a brute force attack. When it was replaced by NTLM (NTLan Manager), these errors were corrected, but even so, many systems for compatibility continue to store passwords in both formats, which is a clear security flaw.

So, in short, the answer to the question: What hash format are Windows passwords stored in” is an NT hash system.

How to Crack Windows Login Password with Hash

On Windows, the password is normally stored in the SAM file at %SystemRoot%System32config. Windows uses the NTLM hash; during boot time, the SAM file hashes are decrypted using SYSKEY, and the hashes are loaded into the registry, which is then used for authentication purposes.

Windows do not allow users to copy the SAM file to another location, so you have to use another operating system to mount the Windows system on top of it and copy the SAM file. Once the file is copied, we will decrypt the SAM file with SYSKEY and get the hashes to crack the password.

Note: This method is difficult and time-consuming for common computer user to crack Windows password, so this way is the perfect choice for you to disable windows password with ease.

Extracting Windows Password Hashes Using Cain

1. First, download and install the famous Cain and Abel software by visiting the link Download Cain.
2. In the next step, select “Run as Administrator” and open Cain for the first time.
3. In Cain, click the Cracker icon from the upper set of tabs.
4. Now by clicking in the right window, select ‘add to list’ as shown below.



5. In the left section “Add NT Hashes from” box, accept the default selection of the system and “Import Hashes from the local system”, as shown below, and select ‘Next’.



6. The retrieved password hashes appear, as shown below.

Cracking Windows Password with Acquired Hash Using Ophcrack

The NTLM technique stores the hash in the MD4 algorithm, which can easily be cracked by the hackers, the above diagram shows the encrypted hash by Cain, and we will be using Ophcrack (A recovery tool) to crack the acquired Md4 hash.

Now, as we have acquired the hash, here comes the next step of choosing the best and fastest tool to crack the windows password hash.

1. On your computer, visit the Ophcrack website and download Ophcrack LiveCD, which is compatible with Windows 10. The downloaded file will be in ISO format.



2. After downloading the Ophcrack LiveCD, you will need to burn the ISO file to a CD or flash drive.



3. From there, you can insert the bootable media into the computer to reset the computer. You will then see a screen like this.
4. The Ophrcrack LiveCD menu should now appear. Please be patient while the computer loads this menu. However, you can still press the Enter button while still in the Ophcrack Graphic mode – auto menu.



5. Once the menu has loaded, you will see a command line appear on the screen. Here Again, you don’t have to do anything but wait, as those are just commands that show Ophcrack LiveCD software is loading which will allow you to crack Windows 10 password.



6. Then a window will appear shortly confirming the content of the encrypted password that is in the device that was inserted into the computer.
7. The program will retrieve the administrator password and display it in the window. Click through the list and view the administrator account password.



8. After making a note of the password, you can now log into your computer.

Ophcrack uses the famous Brute Force dictionary attack technique to crack windows password hash. Brute forcing is the most effective algorithm among all the hashing algorithms for windows. It works on Dump and Loads to utilize the real-time graphs for analyzing the windows password hash.

How to Crack Windows Login Password with Hash Alternative (Time-saving and Easy)

Cracking Windows passwords is not an easy task, and sometimes it would surely take too much time. Individuals working in offices and different sectors might sometimes lose their passwords and end up losing access to your Windows. This situation might be so hectic, but now no need to be worried, UnlockGo – Windows Password Recovery will surely help you to set out the new password for your windows without remembering the old one within a few clicks and minutes.

Just follow the below steps, and you can easily crack your windows password:

🔔 Step 1: First, install UnlockGo windows password recovery on your PC.

🔔 Step 2: Create a Windows password reset CD/DVD or USB, whatever is available.

🔔 Step 3: Now, after the bootable USB drive is ready, with UnlockGo, you have the option to reset or crack your windows password, delete the password or create a new account for the windows.

🔔 Step 4: Select the reset password option, and you are now all set to regain access to your computer.

FAQs about Windows Password Hash Format

❓ 1. How to acquire password hashes?

There are different ways to acquire password hashes:

Acquisition from the Machine In-Question

Although Windows password hashes are stored in the SAM file, their encryption is within the system boot key stored in the SYSTEM file. Both of these files are stored in C: WindowsSystem32Config. If someone accesses both of these files, then he can use the SYSTEM file for decrypting the passwords in the SAM file.

Using Authentication to a Remote Server

Taking the benefit of authentication to a remote server is another way of acquiring password hashes. This works by sending a user link pointing to a file on the hacker-controlled server in the form of a phishing email. This link can trick the target computer, which then tries to authenticate the activity with the current login credentials. Thus, stealing a password hash becomes possible by this method.

❓ 2. What password cracking tools, we can use?

There are different ways of cracking Windows passwords using different tools, such as Hashcat, John the Ripper, and Ophcrack.

Hashcat: It is a free, open-source password cracker for all DOS having GPU support.

John the Ripper: It is a password cracking tool. Its free version is available for all the Operating Systems, while its Pro version is available for *nix Operating Systems.

Ophcrack: It is yet another password cracking tool available for all operating systems.

❓ 3. How are Passwords Stored in Windows?

There are three ways the passwords are stored in Windows. These are:

Passwords being stored as OWF

OWF stands for One-way Function. It is a one-way method of mathematical transformation of data related to hashing algorithm for Windows. The data is transformed through this method and is converted only through one-way encryption, and this process cannot be reversed.

Passwords being Stored in Active Dictionary

The passwords at rest are secured in the Active Dictionary Database. The NT password hash gets protected by a dual encryption layer when stored in this form.

Passwords being Stored in Local SAM

A local Security Account Manager (SAM) is used for storing the local user account password hashes. The password hashes encrypted in SAM are done in the same way as the Active Dictionary.

Summary

Just like any piece of modern technology, Windows has also faced numerous updates with time. It has changed its interface and applications quite a lot. Also, its operability has been modified, but still, it is facing critical security issues. Windows needs to work on its hashing algorithm in the upcoming versions to ensure maximum security for its users; otherwise, the intruders and crackers might hack into windows easily. You can change them within months, and no worry about forgetting with our UnlockGo – Windows Password Recovery, feel free to encrypt your computer.

Most of the theory here has been taken from SANS documentation (https://www.sans.org/reading-room/whitepapers/testing/paper/39170) . This is intended to provide a summary about NT hashes and Pass the hash.

LM Password Hashes

The LAN Manager hash was one of the first password hashing algorithms to be used by Windows operating systems, and the only version to be supported up until the advent of NTLM used in Windows 2000, XP, Vista, and 7. These newer operating systems still support the use of LM hashes for backwards compatibility purposes. However, it is disabled by default for Windows Vista and Windows 7.

In earlier versions of Windows, the LM hash is typically stored and transmitted by default. However, in Windows Vista and versions above, the LM hash is not stored by default, nor is it used by default during network authentication. Instead, the newer versions use the NTLMv2 hash as the default authentication method.

Example

If LM hashes are enabled on your system (Win XP and lower), a hash dump will look like:

• Administrator:500:01FC5A6BE7BC6929AAD3B435B51404EE:0CB6948805F797BF2A82807973B89537:::

If LM hashes are disabled on your system (Win Vista, 7, 8+), a hash dump will look like:

• Administrator:500:NO PASSWORD*********************:0CB6948805F797BF2A82807973B89537:::

LM hash break down

• First field: the username
• Second field: the SID (Security IDentifier) for that username
• Third field: the LM hash
• Forth field: the NTLM hash

LM hash mechanics

• When a user creates a new password, this password is converted to all uppercase
• then it’s padded out to 14 characters
• The password is then split into two 7-byte chunks
• The two chunks then will be used as a key in a Data Encryption Standard (DES) encryption to encrypt a fixed value
• The values of the two DES operations are concatenated and the result is stored as the LM hash

LM hash weaknesses

• The password length is limited to 14 characters, broken up into two independent 7-byte chunks
• the password is case-insensitive which decreases the key space available for the users to choose their passwords from

NTML hash

NT LAN Manager (NTLM) is the Microsoft authentication protocol that was created to be the successor of LM. NTLM was accepted as the new authentication method of choice and implemented with Windows NT 4. It MD4 hashing algorithm to create the hash based upon a series of mathematical calculations

MD4 is considered to be significantly stronger than DES as it allows for longer password lengths, it allows for distinction between uppercase and lowercase letters and it does not split the password into smaller, easier to crack chunks.

Windows does not utilize a technique called salting. Salting is a technique in which a random number is generated in order to compute the hash for the password. This means that the same password could have two completely different hash values, which would be ideal. It is a good practice to use a salt when storing passwords.

NTLM mechanics

• It takes the password, hashes it using the MD4 algorithm
• It does not break up the password into chunks
• the password is case-sensitive
• can support very long passwords (127 characters)

NTLMv1

To generate the NT hash from a plaintext password 1), one needs to apply the MD4 hashing function to the UTF-16 Little Endian encoding of the password.

NT_Hash(password) = MD4(UTF-16-LE(password))

• NT_Hash(“pass1”) = “8D7A851DDE3E7BED903A41D686CD33BE”

identical passwords can be identified based on the NT hashes solely, without breaking the encryption. It is worth noting that NT hashes, in many scenarios, are equivalent to passwords themselves.

The NTLMv1 hashing algorithm takes as input the NT hash of a password and a challenge provided by the server. It concatenates the NT hash with five bytes of zeros. It splits this string into three 7-byte keys. Those keys are used to encrypt the challenge using DES. The cryptograms are concatenated to create the NTLMv1 hash

c = challenge

K1 | K2 | K3 = NT_Hash(password) | “0000000000”

NTLMv1(password, c) = DES( K1, c) | DES( K2, c) | DES( K3, c)

• c = “1122334455667788”
• NTLMv1(“pass1”, c) = “151814cebe6083b0551173d5a42adcfa183c70366cffd72f”

It is essential to notice that NTLMv1 hashes can be cracked, revealing the NT hash that was used to generate them. Rainbow tables exist for chosen NTLMv1 challenges, making it possible to obtain the hash in minutes.

NTLMv2

The NTLMv2 hashing algorithm concatenates a user name and domain name, and then it applies the HMAC-MD5 hashing function using the NT hash of a password as the key. Next, it concatenates a server and client challenges and again applies the same hashing function, using the output of the previous calculation as the key.

NTLMv2 is stronger than NTLMv1. Usually, brute-force or dictionary attacks, using tools like hashcat or john, need to be applied to break the hash. These attacks are feasible and commonly applied leading to the recovery of the password rather than the NT hash.

Credential Process

Windows credentials are validated against the Security Accounts Manager (SAM) database on the local computer, or against Active Directory on a domain-joined computer, through the Winlogon service. Credentials are collected through user input on the logon user interface or programmatically via the application programming interface (API) to be presented to the authenticating target.

The credentials used in authentication are digital documents that associate the user’s identity to some form of proof of authenticity, such as a certificate, a password, or a PIN.

Local security information is stored in the registry under HKEY_LOCAL_MACHINESECURITY. Stored information includes policy settings, default security values, and account information, such as cached logon credentials. A copy of the SAM database is also stored here, although it is write-protected.

This has been taken from (https://docs.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication)

The following diagram shows the components that are required and the paths that credentials take through the system to authenticate the user or process for a successful logon.

The following table describes each component that manages credentials in the authentication process at the point of logon.

Authentication components for all systems

Component	Description
User logon	Winlogon.exe is the executable file responsible for managing secure user interactions. The Winlogon service initiates the logon process for Windows operating systems by passing the credentials collected by user action on the secure desktop (Logon UI) to the Local Security Authority (LSA) through Secur32.dll.
Application logon	Application or service logons that do not require interactive logon. Most processes initiated by the user run in user mode by using Secur32.dll whereas processes initiated at startup, such as services, run in kernel mode by using Ksecdd.sys. For more information about user mode and kernel mode, see Applications and User Mode or Services and Kernel Mode in this topic.
Secur32.dll	The multiple authentication providers that form the foundation of the authentication process.
Lsasrv.dll	The LSA Server service, which both enforces security policies and acts as the security package manager for the LSA. The LSA contains the Negotiate function, which selects either the NTLM or Kerberos protocol after determining which protocol is to be successful.
Security Support Providers	A set of providers that can individually invoke one or more authentication protocols. The default set of providers can change with each version of the Windows operating system, and custom providers can be written.
Netlogon.dll	The services that the Net Logon service performs are as follows: — Maintains the computer’s secure channel (not to be confused with Schannel) to a domain controller. — Passes the user’s credentials through a secure channel to the domain controller and returns the domain security identifiers (SIDs) and user rights for the user. — Publishes service resource records in the Domain Name System (DNS) and uses DNS to resolve names to the Internet Protocol (IP) addresses of domain controllers. — Implements the replication protocol based on remote procedure call (RPC) for synchronizing primary domain controllers (PDCs) and backup domain controllers (BDCs).
Samsrv.dll	The Security Accounts Manager (SAM), which stores local security accounts, enforces locally stored policies and supports APIs.
Registry	The Registry contains a copy of the SAM database, local security policy settings, default security values, and account information that is only accessible to the system.

It is known that Windows computers can be configured to be in a workgroup or joined to a domain. In a workgroup, each computer holds its own SAM which contains information about all its local user and group accounts. The passwords associated with each of these accounts are hashed and stored in the SAM. The hashing of passwords offers some measure of security and minimize the risks of an attack. The Local Security Authority (LSA) validates a user’s logon attempt by verifying their credentials against the data stored in the SAM. A user’s logon attempt is successful only when the entered password matches the password stored in the local SAM.

In a domain-joined computer, there can be two types of logons: a local logon (that is handled by the SAM as described above) and a domain user logon using the Active Directory (AD) database with the WinLogon service. However, when a user logs on to a computer as a local user, the user will not be able to access the network resources. A Windows server that has been promoted to a DC will use the AD database instead of the SAM to store data. The only instance it will use the SAM would be to boot into DSRM for performing maintenance operations. This is because the DSRM administrator password is stored locally in the SAM and not in AD.

Credential storage

Cached Credentials

Validation mechanisms rely on the presentation of credentials at the time of logon. However, when the computer is disconnected from a domain controller, and the user is presenting domain credentials, Windows uses the process of cached credentials in the validation mechanism.

Each time a user logs on to a domain, Windows caches the credentials supplied and stores them in the security hive in the registry of the operation system.

With cached credentials, the user can log on to a domain member without being connected to a domain controller within that domain.

In other words, Cached credentials is a term used to describe the process of storing the domain login credentials so that a user can login locally to a domain member without being connected to a domain controller

To get Sam dump or Hash of passwords from registry hive we need system privileges or NT Authority privileges

Where do I find the SAM/Hashes?

It can be found on the hard drive in the folder %systemroot%system32config. However this folder is locked to all accounts including Administrator while the machine is running. The only account that can access the SAM file during operation is the «System» account.

You may also be able to find the SAM file stored in %systemroot% repair if the NT Repair Disk Utility (rdisk) has been run and the Administrator has not removed the backed up SAM file.

The final location of the SAM or corresponding hashes can be found in the registry. It can be found under HKEY_LOCAL_MACHINESAM. This is also locked to all users, including Administrator, while the machine is in use

Memory

Windows caches users’ passwords hashes (NT hash, and LM hash) in a memory location whenever a user logs on interactively or via terminal service. This location is accessible only by the operating system, and any process acting as the operating system.

• The operating system uses this cached hash to authenticate the user whenever the user tries to access a network resource, and that resource requires authentication
• This is done transparently for the user, who otherwise would be entering her password every time she tries to access a resource on the network
• The memory location is purged as soon as the user locks his system or logs off

Reversibly Encrypted

In this form passwords are stored reversibly encrypted. This encryption can be reversed and the clear-text password(s) can be revealed. This form of password storage is disabled by default

Backups

SAM file can also be stored in a backup location: C:WindowsRepairSAM

Security Accounts Manager database

The Security Accounts Manager (SAM) is a database that stores local user accounts and groups. It is present in every Windows operating system; however, when a computer is joined to a domain, Active Directory manages domain accounts in Active Directory domains.

If someone attempts to log on to the system and the user name and associated passwords match an entry in the SAM, a sequence of events takes place ultimately allowing that person access to the system. If the user name or passwords do not properly match any entry in the SAM, an error message is returned requesting that the information be entered again.

The SAM database runs automatically as a background process when the computer starts up. The SAM also works together with other processes and services that run on the computer, by providing the security information needed.

The Windows SAM database file resides in C:WindowsSystem32config. The hashed values of all passwords find a place in the HKEY_LOCAL_MACHINESAM of the registry. However, there are rules that govern ‘when’ and ‘who’ can access this file.

Local Security Authority LSA

The Local Security Authority (LSA) is a protected system process that authenticates and logs users on to the local computer. In addition, LSA maintains information about all aspects of local security on a computer (these aspects are collectively known as the local security policy), and it provides various services for translation between names and security identifiers (SIDs). The security system process, Local Security Authority Server Service (LSASS), keeps track of the security policies and the accounts that are in effect on a computer system.

The Local Security Authority Subsystem Service (LSASS) stores credentials in memory on behalf of users with active Windows sessions. The stored credentials let users seamlessly access network resources, such as file shares, Exchange Server mailboxes, and SharePoint sites, without re-entering their credentials for each remote service.

LSASS can store credentials in multiple forms, including:

• Reversibly encrypted plaintext
• Kerberos tickets (ticket-granting tickets (TGTs), service tickets)
• NT hash
• LAN Manager (LM) hash

If the user logs on to Windows by using a smart card, LSASS does not store a plaintext password, but it stores the corresponding NT hash value for the account and the plaintext PIN for the smart card. If the account attribute is enabled for a smart card that is required for interactive logon, a random NT hash value is automatically generated for the account instead of the original password hash. The password hash that is automatically generated when the attribute is set does not change.

If a user logs on to a Windows-based computer with a password that is compatible with LAN Manager (LM) hashes, this authenticator is present in memory.

The storage of plaintext credentials in memory cannot be disabled, even if the credential providers that require them are disabled.

The stored credentials are directly associated with the Local Security Authority Subsystem Service (LSASS) logon sessions that have been started after the last restart and have not been closed. For example, LSA sessions with stored LSA credentials are created when a user does any of the following:

• Logs on to a local session or Remote Desktop Protocol (RDP) session on the computer
• Runs a task by using the RunAs option
• Runs an active Windows service on the computer
• Runs a scheduled task or batch job
• Runs a task on the local computer by using a remote administration tool

In some circumstances, the LSA secrets, which are secret pieces of data that are accessible only to SYSTEM account processes, are stored on the hard disk drive. Some of these secrets are credentials that must persist after reboot, and they are stored in encrypted form on the hard disk drive. Credentials stored as LSA secrets might include:

• Account password for the computer’s Active Directory Domain Services (AD DS) account
• Account passwords for Windows services that are configured on the computer
• Account passwords for configured scheduled tasks
• Account passwords for IIS application pools and websites
• Passwords for Microsoft accounts

How passwords are used

OLD

Both LM and NTLM are very similar, but differ mainly in the hash used to compute the response. LM and NTLM are used for authentication in workgroups. They are also used in a domain environment if either the client, or the server is not a domain member, or if a resource within the domain is accessed by its IP address instead of its NetBIOS or DNS name.

All Windows OSs prior to Windows Server 2003 send both LM and NTLM responses by default. In Windows Server 2003 only the NTLM response is sent by default, while the LM response field is mostly unused

CURRENT

NTLMv2 improves upon LM and NTLM hashes and their weaknesses. It uses the NT hash; however, it also includes a client challenge in the computation. NTLMv2 also includes timestamps which makes it immune to reply attacks and is the default authentication method used from Windows Vista onward

NTLMv2 hash is not stored in Windows, it is generated on the fly. NTLMv2 authentication uses both the client nonce and the server nonce/challenge to calculate the response, unlike NTLM authentication, which uses a fixed server challenge. This calculation process eliminates the possibility of precomputed attacks against NTLMv2

DOMAIN

Kerberos is a set of services only used in a domain environment when a NetBIOS name or DNS name is used to connect. If a user connects to a resource via IP, then Kerberos will not be used. LM, NTLM, or NTLMv2 will be used instead to authenticate the user.

• Kerberos provides authentication for both the user and the server.
• The client and server agree on the encryption algorithm, the shared secret key, and the recognition data
• the authenticator, which can include the sender’s name, domain, time, IP, and the MD5 checksum of the authenticator.
• When the client and server decrypt the recognition data, the data let them prove to one another that they know the shared 128-bit secret.
• Windows versions prior to Server 2008 use the RC4 encryption algorithm
• Windows Server 2008 uses AES which is much more secure than RC4

How can passwords be attacked?

The two popular attacks against passwords are online and offline attacks. There are also other

forms of attacks against passwords, for example via key loggers, shoulder-surfing, social engineering, etc.

Online Password Attack – Password Guessing

An online password attack, also known as password guessing, is the process of attempting to find passwords by trying to login. Online password attacks are relatively slow, typically rated at about 50 password attempts a minute. A true brute force attack takes a lot longer. Under these conditions, trying millions of passwords simply isn’t an option. In this attack, an attacker can either manually enter passwords or use some software tools to automate the process

Offline Password Attack – Password CrackingAn offline password attack, also known as password cracking, is used when the attacker has captured the password hash. In this attack, the attacker will start cracking the password by creating a hash of a password or a challenge-response sequence and comparing it to the hash or response that he captured. If a match is found, the attempt to crack the hash is considered successful

Difference

The difference between online and offline attacks is that, in an online attack, the password has the protection of the system in which it is stored on. However, in offline attacks, passwords have no such protection. For this reason, offline attacks are in general much faster than online attacks.

Precomputed hash attack

Precomputed attacks are a form of offline attacks. In this attack, also known as ‘rainbow table attack’, the password hashes are stored in a file. The size of this file can be very large, for example storing all LM hashes requires 310 terabytes of storage.

Precomputed hashes can greatly decrease the time needed to crack passwords. In fact they can decrease the time required to find a password from months or weeks to just a few hours or even minutes.

Pass the hash

it is essential to understand that the PtH attack uses the actual NT hash. PtH in Windows 10 is closely related to the NTLMv2 authentication protocol. Windows implements a Single Sign-On (SSO) system, which caches credentials after the initial authentication and uses them later to access hosts, file shares, and other resources.

The NTLMv2 authentication process applies a challenge/response exchange, which, instead of using the user’s password, uses its NT hash. This feature allows the attacker to authenticate with the NT hash (Pass-the-Hash), without the knowledge of the corresponding password.

The PtH attack is composed of two primary steps:

• Extraction of hashes from an already compromised host or from another, not-yet-compromised host via network communication
• Application of the extracted hashes to gain access to the same or a different machine

Important (Mimikatz)

• The attacker need at least an account or shell in the server
• That user need administrative privileges

In a pass-the-hash attack, the goal is to use the hash directly without cracking it, this makes time-consuming password attacks less needed.

How do you Prevent Pass-the-Hash Attacks

For a PtH attack to succeed, the perpetrator must first gain local administrative access on a computer to lift the hash. Once the attacker has a foothold they can move laterally with relative ease, lifting more credentials and escalating privileges along the way.

Implementing the following security best practices will help eliminate, or at least minimize the impact of, a PtH attack:

• A least privilege security model: Can limit the scope, and mitigate the impact of a PtH attack, by reducing an attackers ability to escalate privileged access and permissions. Removing unnecessary admin rights will go a long way to reducing the threat surface for PtH and many other types of attacks.
• Password management solutions: Can rotate passwords frequently (and/or after a known credential compromise) can condense the window of time during which a stolen hash may be valid. By automating password rotation to occur after each privileged session, you can completely thwart PtH attacks, and exploits relying on password reuse.
• Separation of privileges: meaning separating different types of privileged and non-privileged accounts, can reduce the scope of usage for administrator accounts, and thus, reduce the risk for compromise, as well as the opportunity for lateral movement.

Ethical hacking and penetration testing

InfoSec, IT, Kali Linux, BlackArch

How to hack a Windows password

In this article, we will find out where the user password is stored in Windows, how to extract data for cracking the Windows password, how to hack user password and what is Pass the hash attack.

Not everyone uses a password on Windows – it is especially rare for users to set a password on a home computer that only one person works on. But in a corporate network or when using Windows as a server, a password is required. Another interesting property of a Windows user password: if a user has an online Microsoft account, the password hash is still stored on the local computer, and the decrypted password can be used to log in for both the local computer and Microsoft online services.

Where does Windows store user login password?

Windows user passwords are stored in the hives of the Windows registry called SYSTEM and SAM in the files:

• C:/Windows/System32/config/SAM
• C:/Windows/System32/config/SYSTEM

Instead of a plain text password, Windows stores password hashes. These hashes can be brute-forced easily. But even without cracking, Windows password hashes can be used to collect data and carry out attacks.

How to get Windows password hashes

Dump Windows password hashes on a running computer

On a running system, it is problematic to access the C:/Windows/System32/config/SAM and C:/Windows/System32/config/SYSTEM files, although this is possible. To save copies of these files, you can use the reg utility:

In some tutorials, instead of SYSTEM, the SECURITY hive is saved – this is a mistake, you cannot restore the hash with the SECURITY and SAM hives, we just need SYSTEM and SAM!

The password hash is also contained in RAM, namely in the Local Security Authority Process (lsass.exe). This process is always launched in running Windows and you can dump it (a copy of the process in RAM is saved to disk as a file). You can use various utilities to create a dump, including two official ones:

There is already a task manager on every Windows, to open it press Win+r and type taskmgr, then press ENTER. Or, right-click on the taskbar (that is, on the bottom bar where the clock, start button, etc.) are located and select “Task Manager” in the context menu.

In the Task Manager, click “Details” and in the “Processes” tab, in the “Windows Processes” section, find the Local Security Authority Process, right-click on it and select “Create Dump File” in the context menu:

Wait for completion:

The file will be saved along the C:UsersUSERNAMEAppDataLocalTemplsass.DMP path. I have the MiAl username and the path to the file C:UsersMiAlAppDataLocalTemplsass.DMP.

Dump Windows password hashes on a turned off computer

On the turned off computer, for subsequent retrieval of the user’s password, it is enough to copy the files:

• C:/Windows/System32/config/SAM
• C:/Windows/System32/config/SYSTEM

The same files can be found in the Windows backup or in the Shadow copy of the disk, or you can copy it by booting from the Live system.

What is the difference between NTLM and NTLMv1/v2 hashes and Net-NTLMv1/v2

Now we will hunt for the NTLM hash. In the article “Windows Network Authentication Hacking”, we already hunted for the NTLMv1 and NTLMv2 hashes, whose name is pretty similar.

Actually, NTLM and NTLMv1/v2 are quite different things. The NTLM hash is stored and used locally, and the NTLMv1/NTLMv2 hashes are used for network authentication and are derived from the NTLM hash. Using any of these hashes, you can decrypt the Windows user password, but these are different encryption/cracking algorithms.

For the Pass-the-hash attack (we will cover it in this article), we use only the NTLM hash, and the NTLMv1/NTLMv2 hashes are not suitable.

There is one more question what is the Net-NTLMv1/v2 hashes. Net-NTLMv1/v2 hashes is an abbreviation for NTLMv1/v2 hashes, i.e. NTLMv1/v2 and Net-NTLMv1/v2 are the same. And NTLM is different.

In this article, we will extract, crack and exploit without brute-force the NTLM hash.

What is mimikatz

mimikatz program is well-known for the ability to extract passwords in plain text, hashes, PIN codes and kerberos tickets from memory. mimikatz can also perform pass-the-hash, pass-the-ticket attacks or build Golden tickets.

In this guide, we will only look at mimikatz’s ability to extract NTLM hashes. Remember, mimikatz also has other very interesting features – look at its extensive help: https://github.com/gentilkiwi/mimikatz/wiki

There are implementations of mimikatz in Meterpreter & Metasploit, DLL reflection in PowerShell and other products. mimikatz can be run in Wine on Linux, but functions related to extracting data directly from Windows will not work; functions for extracting hashes from dumps or decryption from registry files should work on Linux.

How to install mimikatz on Windows

mimikatz is a portable command line utility. That is, installation is not required, but you need to be able to start if you are not very familiar with the command line.

1. Go to https://github.com/gentilkiwi/mimikatz/releases, download the mimikatz_trunk.7z or mimikatz_trunk.zip file. Unzip the downloaded archive.

2. Open PowerShell (Win+x → Windows PowerShell (administrator)) or the command line (Win+r → cmd).

3. At the command prompt, use the cd command to navigate to the folder with the mimikatz.exe executable file. For example, the archive is unpacked into the C:UsersMiAlDownloads folder, then the executable file will be in the C:UsersMiAlDownloadsmimikatz_trunkx64 folder:

4. Run the executable file.

The following commands must be executed in the mimikatz console.

The log command enables writing all output to a FILE:

For example, to run all output in a hash.txt file:

I copied the SYSTEM and SAM files from the turned off computer, now to extract the hash I need to run a command of the form:

An example of my command:

The output is quite extensive and there is a lot of data. Of interest are sequential lines of the form:

In my example, interesting lines:

There are also lines with usernames:

But after them there are no strings with the NTLM hash, because these users do not have a password in the system.

If you want to extract data from the registry files of the current operating system, then exit mimikatz, for this press Ctrl+c.

Now we will dump the SYSTEM and SAM registry hives of the current system:

Run mimikatz again:

Turn on logging:

And we execute a command indicating the files into which dumps of the registry hives are saved, that is, SystemBkup.hiv and SamBkup.hiv:

Only one user with a hash was found here:

In fact, to extract NTLM hashes from the local system, it was not necessary to dump the registry hives. Another option is to increase the privileges of the mimikatz program itself and extract hashes directly from the system. To do this, run the commands:

Logically (and in practice) in the dump of the Local Security Authority Process should only be the hash of the user who logged in with a password.

First, specify the path to the dump file with a command of the form:

Then run the command:

How to brute-force NTLM hash

For hacking I will take the following hash:

Take a look at the Hashcat help to find out the NTLM hash mode number:

That is, the NTLM hash number is 1000 (hashcat mode).

To launch a mask attack to crack NTLM in Hashcat, you need to run a command of the form:

An example of my real command:

In this command:

• hashcat is the name of the executable file. On Windows, it could be hashcat64.exe.
• —force means ignore warnings
• —hwmon-temp-abort=100 means setting the maximum temperature, after which the brute-force attck will be interrupted, by 100 degrees Celsius
• -m 1000 means NTLM hash type
• -D 1,2 means to use both the central processor and the video card for brute-force
• -a 3 means mask attack
• -i means gradually increase the number of characters in the generated passwords
• —increment-min 1 means start with mask length equal to one
• —increment-max 10 means to end the search with a mask length of ten
• -1 ?l?d means custom character set number 1, it includes small Latin letters (?l) and numbers (?d)
• ca76a176340f0291e1cc8ea7277fc571 is the hash for hacking
• ?1?1?1?1?1?1?1?1?1 is a mask from a custom character set

Let’s hack one more hash:

Command (another hash and another set of custom characters):

So, in this article, we learned how to extract an NTLM hash and crack a Windows password. But what if you fail to crack NTLM? See the second part, entitled “Pass-the-hash attack (how to use NTLM without cracking a password)” for the answer.

Introduction to Hashing and how to retrieve Windows 10 password hashes

Jul 3, 2019 · 6 min read

In the security world, you might have heard of the exploit used by hackers to reveal passwords from their hashed counterparts. We call this technique password cracking or in practicality ‘password guessing’. Even with the complexity of password controls put in by organizations today, this threat is very much real. This tutorial is intended for any individual with a mindset of security who wants to learn more about how hackers are able to crack Windows stored user passwords.

Introduction to hashing, rainbow tables

Hashing is a software p rocess of generating fixed character length hash values for a text file. This is a one-way function meaning the original text file cannot be generated back from the hash value. This hash value is used to verify the integrity of original text when it is sent over a communication medium. For example, when A sends a text message to B, it first creates a SHA-2 ( popular hashing algorithm) hash of the message and sends it along with the message. When B receives the message, it also creates a hash of the text message using same SHA-2 algorithm and compares it with the hash provided by A. If the hashes match, B can be rest assured that the original message has not been corrupted on the way.

Application engineers also use this technique for securing passwords of users logging into their systems. Instead of storing passwords in the back-end database in clear text, password hashes are used. This protects clear-text passwords from internal application developers and also from hackers in case they are able to breach the database. Hackers are cognizant of this process and have lot of tools in their arsenal to efficiently guess the passwords from the hashes. I use the word ‘guess’ because remember hashes are one-way functions, you cant decode them like you can do to an encrypted string. You would need to create a hash of a guessed password and compare to the extracted hash to determine if you have guessed correct.

Free online tables are available which store password hashes of common passwords which can make a hackers job lot easier if people are not serious about password complexities. These tables are called rainbow tables or hash tables. In case of complex passwords, there are free tools which use a brute-force approach of comparing hashes of multiple combinations of text. Regardless of the approach being used, it is appropriate to state that password hashes are NOT SAFE if in the hands of an ill-will hacker.

Windows hashing basics

You really need to know only the following three basic concepts before extracting Windows hashes:

LAN Manager (LM) hash is an old and weak Windows technique for creating hashed passwords, which has been disabled by default in current Windows environments. But this can still be enabled manually on current systems — See Microsoft documentation on how to protect your systems from using it:

Cached and Stored Credentials Technical Overview

Applies To: Windows Vista, Windows Server 2008, Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

This topic for the IT professional describes how credentials are formed in Windows and how the operating system manages them.

IntroductionВ

When a user or service wants to access a computing resource, they must provide information that proves their identity. Their identity is typically in the form of their account’s user name. This might be the user name that is the Security Accounts Manager (SAM) account name or the User Principal Name (UPN). But to prove their identity, they must provide secret information, which is called the authenticator. An authenticator can take various forms depending on the authentication protocol and method. The combination of an identity and an authenticator is called an authentication credential.

The process of creating, submitting, and verifying credentials is described simply as authentication, which is implemented through various authentication protocols, such as the Kerberos protocol. Authentication establishes the identity of the user, but not necessarily the user’s permission to access or change a specific computing resource. That process is known as authorization.

Credentials are typically created or converted to a form that is required by the authentication protocols that are available on a computer. Credentials can be stored in the Local Security Authority Subsystem Service (LSASS) process memory for use by the account during a session. Credentials must also be stored on a hard disk drive in authoritative databases, such as the SAM database and in the database that is used by Active Directory Domain Services (ADВ DS).

For more information about storage, see Credentials storage in this topic.

Credential authenticators

The authenticator types used in the Windows operating system are as follows:

Plaintext credentials

When a user signs in to a computer running Windows and provides a user name and credentials (such as a password or PIN), the information is provided to the computer in plaintext. This plaintext password is used to authenticate the user’s identity by converting it into the form that is required by the authentication protocol. Some versions of Windows also retain an encrypted copy of this password that can be unencrypted to plaintext for use with authentication methods such as Digest authentication.

Windows operating systems never store any plaintext credentials in memory or on the hard disk drive. Only reversibly encrypted credentials are stored there. When later access to the plaintext forms of the credentials is required, Windows stores the passwords in encrypted form that can only be decrypted by the operating system to provide access in authorized circumstances.

These protections, however, cannot prevent a malicious user with system-level access from illicitly extracting them in the same manner that the operating system would for legitimate use.

NT hash

The NT hash of the password is calculated by using an unsalted MD4 hash algorithm. MD4 is a cryptographic one-way function that produces a mathematical representation of a password. This hashing function is designed to always produce the same result from the same password input, and to minimize collisions where two different passwords can produce the same result. This hash is always the same length and cannot be directly decrypted to reveal the plaintext password. Because the NT hash only changes when the password changes, an NT hash is valid for authentication until a user’s password is changed.

To protect against brute-force attacks on the NT hashes or online systems, users who authenticate with passwords should set strong passwords or passphrases that include characters from multiple sets and are as long as the user can easily remember. For password complexity guidelines, see the Strong passwords section in the Passwords Technical Overview.

LM hash

LAN Manager (LM) hashes are derived from the user password. Legacy support for LM hashes and the LAN Manager authentication protocol remains in the NTLM protocol suite. Default configurations in Windows and Microsoft security guidance have discouraged its use.

LM hashes inherently are more vulnerable to attacks because:

LM hashes require a password to be less than 15 characters long and they contain only ASCII characters.

LM hashes do not differentiate between uppercase and lowercase letters.

Windows logon cached password verifiers

These verifiers are not credentials because they cannot be presented to another computer for authentication, and they can only be used to locally verify a credential. They are stored in the registry on the local computer and provide credentials validation when a domain-joined computer cannot connect to AD DS during a user’s logon. These “cached logons” or more specifically, cached domain account information, can be managed using the security policy setting Interactive logon: Number of previous logons to cache (in case domain controller is not available).

Credentials storage

The following sections describe where credentials are stored in Windows operating systems. Windows credentials are composed of a combination of an account name and the authenticator. These are stored and retrieved from the following locations depending on the status of the user’s session, which might be active or inactive, and local or networked.

Security Accounts Manager database

The SAM database is stored as a file on the local hard disk drive, and it is the authoritative credential store for local accounts on each Windows computer. This database contains all the credentials that are local to that specific computer, including the built-in local Administrator account and any other local accounts for that computer.

The SAM database stores information on each account, including the user name and the NT password hash. By default, the SAM database does not store LM hashes on current versions of Windows. No password is ever stored in a SAM database—only the password hashes. The NT password hash is an unsalted MD4 hash of the account’s password. This means that if two accounts use an identical password, they will also have an identical NT password hash.

LSASS process memory

The Local Security Authority Subsystem Service (LSASS) stores credentials in memory on behalf of users with active Windows sessions. This allows users to seamlessly access network resources, such as file shares, Exchange Server mailboxes, and SharePoint sites, without re-entering their credentials for each remote service.

LSASS can store credentials in multiple forms, including:

Reversibly encrypted plaintext

Kerberos tickets (TGTs, service tickets)

If the user logs on to Windows by using a smart card, LSASS will not store a plaintext password, but it will store the corresponding NT hash value for the account and the plaintext PIN for the smart card. If the account attribute is enabled for a smart card that is required for interactive logon, a random NT hash value is automatically generated for the account instead of the original password hash. The password hash that is automatically generated when the attribute is set does not change.

If a user logs on to Windows with a password that is compatible with LM hashes, this authenticator will be present in memory.

The storage of plaintext credentials in memory cannot be disabled, even if the credential providers that require them are disabled.

The stored credentials are directly associated with the LSASS logon sessions that have been started since the last restart and have not been closed. For example, LSA sessions with stored LSA credentials are created when a user does any of the following:

Logs on to a local session or RDP session on the computer

Runs a task by using the RunAs option

Runs an active Windows service on the computer

Runs a scheduled task or batch job

Runs a task on the local computer by using a remote administration tool

LSA secrets on the hard disk drive

A Local Security Authority (LSA) secret is a secret piece of data that is accessible only to SYSTEM account processes. Some of these secrets are credentials that must persist after reboot, and they are stored in encrypted form on the hard disk drive. Credentials stored as LSA secrets might include:

Account password for the computer’s AD DS account

Account passwords for Windows services that are configured on the computer

Account passwords for configured scheduled tasks

Account passwords for IIS application pools and websites

ADВ DS database (NTDS.DIT)

The Active Directory Domain Services (ADВ DS) database is the authoritative store of credentials for all user and computer accounts in an ADВ DS domain. The two types of domain controllers in ADВ DS that manage credentials differently are:

Writable   Each writable domain controller in the domain contains a full copy of the domain’s AD DS database, including account credentials for all accounts in the domain.

Read-onlyВ В В Read-only domain controllers (RODCs) house a partial local replica with credentials for a select subset of the accounts in the domain. By default, RODCs do not have a copy of privileged domain accounts.

The database stores a number of attributes for each account, which includes user names types and the following:

NT hash for the current password

NT hashes for password history (if configured)

NT hash values are also retained in ADВ DS for previous passwords to enforce password history during password change operations. The number of password history NT hash values retained is equal to the number of passwords configured in the password history enforcement policy.

LM hashes may also be stored in the ADВ DS database depending on the domain controller operating system version, configuration settings, and password change frequency.

Credential Manager store

Users may choose to save passwords in Windows by using an application or through the Credential Manager Control Panel applet. These credentials are stored on the hard disk drive and protected by using the Data Protection Application Programming Interface (DPAPI). Any program running as that user will be able to access credentials in this store.

Credential Manager can obtain its information in two ways:

Explicit creationВ В В When users enter a user name and password for a target computer or domain, that information is stored and used when the users attempt to log on to an appropriate computer. If no stored information is available and users supply a user name and password, they can save the information. If the user decides to save the information, Credential Manager receives and stores it.

System populationВ В В When the operating system attempts to connect to a new computer on the network, it supplies the current user name and password to the computer. If this is not sufficient to provide access, Credential Manager attempts to supply the necessary user name and password. All stored user names and passwords are examined, from most specific to least specific as appropriate to the resource, and the connection is attempted in the order of those user names and passwords. Because user names and passwords are read and applied in order, from most to least specific, no more than one user name and password can be stored for each individual target or domain.

Credential Manager uses the Credential Locker, formerly known as Windows Vault, for secure storage of user names and passwords.

Windows hashes are saved in SAM file (encrypted with SYSTEM file) on your computer regardless of the fact that you are using Microsoft account. It needs to be done this way to allow you to log in to your computer, even if you are not connected to the internet. If you change your password using account.microsoft.com, you will still be able to log in to your computer with your old password (even if you are using Microsoft account). After logging in to the system, you will be prompted to type new password, but as long as you don’t type new password, you will be able to use old password to log in to your computer. After you type new password, SAM (and possibly SYSTEM) file will be updated.

You (wrongly) get 31d6cfe0d16ae931b73c59d7e0c089c0 hash of your password because format of the SAM and/or SYSTEM files has changed since Windows 10 Anniversary update (see: similar problem), thus tools like chntpw, bkhive, pwdump, samdump2 print hash of the empty password (I verified it on my Windows 10). Since this update, Windows uses AES128 to encrypt password’s MD4 hash. Because of that, nearly all tutorials regarding Windows password recovery became outdated.

Fortunately there is a tool called mimikatz (Windows-only, but can be ran on Linux by using Wine) created by Benjamin Delpy, that can read passwords’ hashes saved in Windows’ new format. Note that Windows Defender and Symantec antivirus treats it as a ‘Hack Tool’ and removes it, so you need to disable them before running mimikatz (run as a administrator).

mimikatz consists of many modules, but you should explore lsadump module, particularly lsadump::sam function.

Excerpt from docs:

If you’re not SYSTEM or using an impersonated SYSTEM token, you’ll have access denied error:

mimikatz # lsadump::sam
Domain : VM-W7-ULT-X
SysKey : 74c159e4408119a0ba39a7872e9d9a56
ERROR kuhl_m_lsadump_getUsersAndSamKey ; kull_m_registry_RegOpenKeyEx SAM Accounts (0x00000005)

In this case, you can use psexec to begin SYSTEM (or other tools) or elevate with token::elevate command to impersonate a SYSTEM token:

mimikatz # privilege::debug
Privilege '20' OK

mimikatz # token::whoami
 * Process Token : 623884       vm-w7-ult-xGentil Kiwi S-1-5-21-1982681256-1210654043-1600862990-1000  (14g,24p)       Primary
 * Thread Token  : no token

mimikatz # token::elevate
Token Id  : 0
User name :
SID name  : AUTORITE NTSystème

228     24215           AUTORITE NTSystème     S-1-5-18        (04g,30p)       Primary
 -> Impersonated !
 * Process Token : 623884       vm-w7-ult-xGentil Kiwi S-1-5-21-1982681256-1210654043-1600862990-1000  (14g,24p)       Primary
 * Thread Token  : 624196       AUTORITE NTSystème     S-1-5-18        (04g,30p)       Impersonation (Delegation)

mimikatz # lsadump::sam
Domain : VM-W7-ULT-X
SysKey : 74c159e4408119a0ba39a7872e9d9a56

SAMKey : e44dd440fd77ebfe800edf60c11d4abd

RID  : 000001f4 (500)
User : Administrateur
LM   :
NTLM : 31d6cfe0d16ae931b73c59d7e0c089c0

RID  : 000001f5 (501)
User : Invité
LM   :
NTLM :

RID  : 000003e8 (1000)
User : Gentil Kiwi
LM   :
NTLM : cc36cf7a8514893efccd332446158b1a

You can download x86 and amd64 binaries of the mimikatz here.

As a side note – if you want to make sure that password’s hash is hash of your password, you can easily do it using Python:

user@mycompa:~$  python3
Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib, binascii
>>> passwd = "password"
>>> hash = hashlib.new('md4', passwd.encode('utf-16le')).digest()
>>> print(binascii.hexlify(hash))
b'8846f7eaee8fb117ad06bdd830b7586c'