Pass-the-Hash (PtH)

[Disclamer: this Wiki page is just an explanation of how Pass-The-Hash attack works and how it can be carried out and is done only for educational purposes. The author does not hold any responsibility for any misuse of the information included in this Wiki page and advises not to use it for any illegal actions nor in any way that could be harmful to any person or entity.]

Introduction

Since 1991, when Microsoft introduced the Lan Manager, local Windows networks had a weak point which made it possible for an attacker to authenticate themself as a user in the network if they gained access to a machine in the network. A Windows network consists of several systems, machines and protocols which work together to authenticate a user or a machine in said system. But early Windows iterations came with an authentication mechanism which was insecure and easy to attack once an attacker had an entry point into a Windows network.

With Pass-The-Hash attackers can authenticate themself to a domain server, even if they do not have the real password in plaintext! On a machine under an attackers control, they can read the hash values of all user who logged onto that machine and gain access to files and services the corresponding users would have access to. Once in possession of the password hash, they can exploit a design weakness in the authentication protocols Windows implements to impersonate themself as registered users in the system.

While still all Windows operating systems implement this protocols, they are not configured by default and a system administrator must switch them on intentionally. So, if no mistakes were made during configuration of the Windows local network, the Pass-The-Hash attack should not be feasible anymore.

Windows network authentication

When a user loges onto a Windows network, several systems and protocols need to work together to allow the user access to machines, files and services in the system.

Local Security Authority Subsystem Service (LSASS)

The LSASS is the local authentication service which handles all users and logins on a single machine. When a user enters its credentials, the LSASS authenticates them by either looking up the stored passwords locally, or, when the user wants to log onto a network, communicates with the domain controller to authenticate the user. For authentication in a network it uses the Lan Manager (LM) or later the New Technology Lan Manager (NTLM) to encrypt a challenge send by the domain controller to verify the user.

Lan Manager (LM)

The Lan Manager was introduced to Windows in 1991 to authenticate users in a local network. Its tasks are to hash the user password and to encrypt the challenge send by the domain controller to authenticate a user. To generate the hash it follows this steps:

1. The password gets converted to uppercase.
2. The string gets padded to 14 bytes
3. and split into two halves which each build a DES key.
4. Each key then encrypts a constant.
5. The results get concatenated which build the LM hash.

Then to answer the challenge from the domain controller the LM

1. pads the Hash to 21 bytes
2. which get split into three parts to 7 bytes each.
3. Each part is used as a DES key
4. to encrypt the challenge.
5. The three results get concatenated to the answer.

If the domain controller calculates the same answer, the user now is authenticated in the network.

Even by the time it was introduced, the LM was not considered safe. Some of the vulnerabilities in its algorithms and protocols were:

• No distinguishing between capital and small letters, i.e., case-insensitive.
• It did not allow long passwords, but only up to 14 chars.
• Only 56 Bit out of 128 Bits were used for the key

New Technology LAN Manager (NTLM)

1993 Microsoft introduced the NTLM (version 1) to new Windows iterations. It came with a few security improvements like an improved challenge and it didn't transfer the has in plaintext anymore. The most important change though was the use of the MD4 hash function to calculate the password hash.

Three years later, 1996, Microsoft introduced the second version of the NTLM which improved the security further by implementing longer passwords and a once again improved challenge. This new challenge was now calculated as followed:

1. The password hash was calculated using the MD4 hash algorithm.
2. Username and domain name get concatenated
3. and this value gets encrypted using the HMAC-MD5 algorithm with the password hash as a key which results in the NTLM v2 password hash.
4. A BLOB gets generated and concatenated with the challenge.
5. The result gets encrypted with the HMAC-MD5 algorithm using the NTLM v2 password hash as a key.
6. The resulting value is then concatenated with the BLOB and send to the domain controller as the answer.

Although these changes did improve the security of the protocol by helping to mitigate offline relay attacks, but leave NTLMv2 exposed to other NTLMv1 vulnerabilities and therefore still does not meet the standards required today. It still uses the MD4 hash, which by today's standards is not satisfactory, and saves the hashes unsalted on the local machine, before sending it salted over the wire. New authentication suites such as Kerberos help mitigate many of these vulnerabilities. Kerberos adds more security measures such as relying on a third server to authenticate both parties, so the client and the server are certain they are communicating with the correct opposites.

Pass-The-Hash

For the attack to be viable, a few preconditions need to be met:

• The attacker already needs to have access to a vulnerable machine in the network.
• On this machine the attacker needs to have local administrator rights.
• LM or NTLM need to be configured to be used by the LSASS.

Accessing the password hash

There are a couple of ways to do access a user password hash on a local machine:

• Windows stores hashes of users in the network that logged onto on that machine in a process called Local Security Authority Subsystem Service (lsass.exe). An attacker can read from this running programm to access the password hashes. As soon as the machine shuts down, the hashes are no longer stored.
• The hashes local users are stored in a registry file or also called the Security Account Manager (SAM). This file is always accessible, even after a restart of the machine.
• Sniffing the network for any hashes that are being transferred.

The SAM database does not guarantee access to a network account, so the safest attack route would be to access the password hashes stored in the lsass.exe. To read out the LSASS process or the SAM, the program needs local admin rights. Thus, the user has to be tricked into executing it with the according rights.

Tools

There are several tools which can be used to perform the Pass-The-Hash attack. Consequently, two of the most popular tools are introduced :

• Samdump2
• Mimikatz

Samdump2

samdump2 tool was designed to get dumps of Windows password hashes, namely Windows XP, NT, and 2k, and as the name suggests it does this by taking a dump of the SAM file using something called syskey, which is a feature in Windows that is supposed to strengthen the SAM database by adding and an additional layer of encryption.

Mimikatz

Mimikatz, on the other hand, tries to extract hashes, PIN codes, as well as passwords in plain text from memory. It is a much stronger tool since it allows a wider variety of other attacks that are mainly focused on playing with the weak security of Windows systems that use the protocols mentioned above. Mimikatz is also one of few tools that got updated after Windows Defender Credential Guard (WDCG) was enabled by default with Windows 10. WDCG made access to the LSASS process extremely difficult. This concludes the set of tools that are going to be used in the accompanying demonstration of this essay to demonstrate how PtH attack works when using these tools.

Passing the hash

After stealing the password hash, the attacker can access every file and service authorised for the user whos password hash they now possess. They now simply answer the domain controllers challenge with the password hash they stole and perfectly impersonate the target user. If the user happens to be an administrator in the domain, the attacker now has full control over the network.

Mitigation and preventive measures

Over the years, many improvements to the vulnerable protocols in question have been released, and more and more studies are being done by Microsoft [5] and other institutions to mitigate this attack. Some of the mitigation techniques that are mentioned in these studies are:

1. Protecting the accounts that have high privileges by adding more restrictions to them like not having email accounts.
2. Removing administrative privileges to local accounts and then restricting these accounts to help to prevent the attackers from taking advantage of such accounts.
3. Adding firewall rules that would restrict the incoming traffic to the server.
4. Correlating Authentication Services.

This is by no means an exhaustive list, simply a guide in the proper direction. Other principles like security by obscurity, by hiding the LSASS memory location, are not viable options in this case. This is due to the fact that the IT security field is so vast and the knowledge of Windows infrastructure so known, that it would be found again very quickly. Additionally, some more recommendations are listed below:

Other recommendations:

1. Do not let highly privileged accounts browse the Internet
2. Standard users should be removed from the local Administrators group
3. Ensure that administrative accounts do not have email addresses
4. Update operating system and applications
5. Limit the amount of privileged domain accounts and their use
6. Domain controllers must be secured and managed

Demonstration using mimikatz

In our scenario, we have two computers that belong to different domains but are inside the same intranet network, let us say one belongs to the administrators' domain, and the second one belongs to the employees' domain.

All that is left now is for someone from the employee domain, to ask someone from the administrators' domain to install something on their PC using their admin account.

When the administrator logs in to the employee's pc, the hash value is saved locally in the LSASS process. Now the attack is ready to be carried out.

Because the employee knows a way to become a local admin he downloads mimikatz, executes it, and types the following:

privilege::debug;

This command grant mimikatz debug rights which are also needed.

sekurlsa::logonpasswords;

This would then show a dump of all the NTLM hashes that are stored on the system, and of course, it also includes the NTLM hash of the domain administrator.

Now the employee can use the information of that admin (username, domain, and NTLM hash) to authenticate to other clients and servers in that domain using mimikatz:

sekurlsa::pth /user:USER /domain:DOMAIN /ntlm:NTLM_HASH /run:cmd

After this, a cli should open with administrative privileges and the employee is able to extract any information he or she wants.

Furthermore, the hash value of the password can even be cracked. If the password is not secure enough such as ”123456789”, you can find out the actual password by using a random free password hash cracker on the internet. This is the reason being, why passwords should be taken much more into consideration.

Conclusion

The pass-the-hash attack can be a horrifying attack given what kind of privileges it gives the attacker in the case of a successful attack, but this is not the end of the mitigation methods that were implemented with a regular update to the system it should mitigate the attack and protect servers against it. Also, there is a server lining, in that it pushes forward the security of Windows servers and lets the developers focus on improving them to let system administrators have much more secure servers to deal with. Although , it cannot be ruled out completely that attackers would find new approaches to exploit vulnerabilities in authentication protocols.

Sources

• https://github.com/gentilkiwi/mimikatz
• https://linux.die.net/man/1/samdump2
• https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation-33283
• https://www.microsoft.com/en-us/download/details.aspx?id=36036
• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/a4f28e01-3df1-4fd1-80b2-df1fbc183f21
• https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/2871997?redirectedfrom=MSDN
• https://ieeexplore.ieee.org/document/7474171
• https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-windows-10-39170
• https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/ntlm-user-authentication
• https://www.sans.org/white-papers/33283/