Hello, aspiring ethical hackers. In this article, you will learn how Windows authentication works? Our readers have seen multiple instances where we have dumped Windows password hashes as part of our hacking tutorials. This should have brought some pertinent questions in the minds of the readers.
As to know how hashdump command of meterpreter, Mimikatz and cachedump module of Metasploit dump credential hashes, where are these hashes stored and why are they in the form of hashes, readers need to get a deep understanding of how Windows authentication works.
Windows Logon Process starts as soon as you go to the Login Screen of a Windows system. The Logon Process is different in different network scenarios for Windows. There are two network types into which a Windows system can be configured. They are,
- WorkGroup
- Domain
Windows systems in Workgroup network use Local Authentication whereas Windows systems connected in Domain network use Remote Authentication.
How Local Authentication works in Windows?
Let’s first see how Local Authentication takes place. In local authentication, the password hash is stored on the same computer on which users are trying to log on.
In Windows, the passwords are stored in the form of a hash in a file known as Security Accounts Manager (SAM) file. The SAM file is located in %SystemRoot%/system32/config/SAM location and it can neither be deleted nor copied while Windows is running.
This is because the Windows kernel obtains and keeps an exclusive filesystem lock on the SAM file which it will release only after the operating system has shut down or a “Blue Screen of Death” exception has been thrown. It is mounted on HKLM/SAM and SYSTEM privileges are required to view it. Readers have already learnt that passwords are stored in SAM file in encrypted form. These passwords are stored in two hash formats in SAM file.
1. Lan Manager Hash (LM Hash)
2. New Technology Lan Manager Hash (NTLM Hash)
LAN Manager Hash
Lan Manager Hashing was used by Windows operating systems prior to Windows NT 3.1. In LM hashing, the password hash is computed as follows,
a. The user’s password is restricted to a maximum of fourteen characters.
b. The password of the user is converted to Uppercase.
c. Then user’s password is encoded in the System OEM code page.
d. This password is NULL-padded to 14 bytes.
e. This 14 bytes “fixed-length” password is then split into two 7-byte halves.
f. Both of these 7-byte halves are used to create two DES keys, one from each 7-byte half. This is done by converting the seven bytes into a bit stream with the most significant bit first and then inserting a parity bit after every seven bits (so 1010100 becomes 10101000). This is done to generate the 64 bits needed for a DES key.
g. Each of this two keys is used to DES-encrypt the constant ASCII string “KGS!@#$%” resulting in two 8-byte ciphertext values.
h. These two ciphertext values are then concatenated to form a 16-byte value, which is the final LM hash.
Security of LAN Manager Hash
LM Hash has several weaknesses. The major weaknesses are :
1. The maximum length of Password while using LM authentication can only be 14 characters.
2. All passwords in LM hash are converted into UPPERCASE before generating the hash value. This means LM hash treats ABcd1234, ABCD1234 and abCD1234 and AbCd1234 as same as ABCD1234. This reduces the LM hash key space to just 69 characters.
3. As already explained above, 14 character password is broken into two halves of 7 characters e- ach and then the LM hash is calculated for each half separately. This makes it easier to crack a LM hash, as the attacker only needs to brute-force 7 characters twice instead of the full 14 charact- ers.
4. As of 2020, a computer equipped with a high-end graphics processor (GPUs) can compute 40 billion LM-hashes per second. At that rate, all 7-character passwords from the 95-character set can be tested and broken in half an hour; all 7-character alphanumeric passwords can be tested and broken in 2 seconds.
5. If the password created is 7 characters or less than that, then the second half of hash will alway- s produce same constant value which is (0xAAD3B435B51404EE). Therefore, if a password is les- s than or equal to 7 characters long, it can easily be identified even without using any tools.
6. While using Remote Login over a network, the LM hash value is sent to servers without any salting, thus making it vulnerable to man-in-the-middle attacks.
7. Without salting, it is also vulnerable to Rainbow Table Attack.
To overcome this weaknesses, Microsoft Starting with Windows Vista and Windows Server 2008, Microsoft disabled the LM hash by default.
NT Hash
Also called NTLM, this is the hash many modern Windows systems store the password hashes. Introduced in 1993. The process of calculating NT Hash is,
1. The password is converted into Unicode characters.
2. Then MD4 encryption is run on these converted characters to get the NT hash which is then stored in SAM database or NTDS file (Domain). NTHash is case sensitive but it still doesn’t provide salting.
The Local Logon Process
1. The Windows authentication process starts from the Windows Login screen. LogonUI.exe han- dles the process by displaying correct logon input boxes depending on the authenticator put in place.
2. When users enter the password on the login interface, winlogon.exe collects those credentials and passes them to the lsass.exe (Local Security Authority Subsystem Service). Winlogon.exe is the executable file responsible for managing secure user interactions. The Winlogon service initiat -es the logon process for Windows operating systems by passing the credentials collected by user action to Lsass.
3. LsaLogonUser supports interactive logons, service logons, and network logons. The LsaLogon User API authenticates users by calling an authentication package which is most probably MSV1_ 0 (MSV) authentication package which is included with Windows NT.
4. The MSV authentication package is divided into two parts. In Local authentication, both parts run on the same computer. The first part of the MSV authentication package calls the second part.
5. The first part of the MSV authentication package converts the clear-text password both to a LAN Manager Hash and to a Windows NT hash. The second part then queries the SAM databas- e for the password hashes and makes sure that they are identical.
6. If the hash is identical, access is granted.
How Windows Domain Authentication takes place?
1. The Windows authentication process starts from the Windows Login screen. LogonUI.exe handles the process by displaying correct logon input boxes depending on the authenticator put in place.
2. When users enter the password on the login interface, winlogon.exe collects those credentials and passes them to the lsass.exe (Local Security Authority Subsystem Service). 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 to Lsass.
3. LsaLogonUser supports interactive logons, service logons, and network logons. The LsaLogon User API authenticates users by calling an authentication package which is most probably MSV1_ 0 (MSV) authentication package which is included with Windows NT.
4. The MSV authentication package is divided into two parts. The first part of the MSV authentication package runs on the computer that is being connected to and the second part runs on the computer that contains the user account. When the first part of the MSV authentication package recognizes that network authentication is required because the domain name passed is not its own domain name, it passes the request to the Netlogon service. Netlogon service is a Authentication Mechanism used in the Windows Client Authentication Architecture that is used to verify logon requests. It registers, authenticates and locates Domain Controllers. It’s functions include,
a. Selecting the domain to pass the authentication request to.
b. Selecting the server within the domain.
c. Passing the authentication request through to the selected server.
5. The Netlogon service (client computer) then forwards the login request to the Netlogon service on the destination computer (i.e domain controller).
6. In turn, the Netlogon service passes the request to the second part of the MSV authentication package on that destination computer.
7. First, the second part queries the password hashes from the SAM database or from the Active Directory database. Then, the second part computes the challenge response by using the password hash from the database and the challenge that was passed in. The second part then compares the computed challenge response to passed-in challenge response.
8. If the hash is identical, access is granted.
That was all about how Windows authentication.
