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_MACHINE\SECURITY. 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. |
| 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:\Windows\Repair\SAM
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:\Windows\System32\config. The hashed values of all passwords find a place in the HKEY_LOCAL_MACHINE\SAM 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.