How to defend against Pass-the-Hash (PtH) attacks

As pen testers we’re pretty familiar with Pass-the-Hash (PtH) attacks.

We’ll use and abuse them on engagements regularly. If your role involves defending against network intrusion, then chances are you’ll have at least heard of the attack.

Whatever your experience, you may not fully appreciate the depth of the problem or how it can be tackled. Note: Tackled NOT Fixed.

In a nutshell

An attacker who finds their way into a Windows computer with a local admin account can probe memory for stored password hashes- for other local or domain accounts that have logged into that computer since it has been running. These hashes can be ‘passed’ (without cracking) onto other computers and services as means of authentication.

This means that a domain can be compromised at its highest level by first compromising a seemingly unimportant server or workstation that a domain administrator account has been logged into from, for example to perform support tasks.

The problem with PtH

Consider this fairly common scenario:

• A workstation is compromised (no biggie!)
• But the local administrator account has the same password across all other workstations
• The attacker extracts all hashes from memory but a domain administrator account isn’t there (hmm…). The attacker also extracts all local hashes including the administrator account’s
• The attacker then uses PtH to login into all other workstations using the extracted local administrator hash and repeats the process (automatically – also known as a hash spray attack). A list of local and domain account hashes will be extracted in the process (Ah, I see where this is going…)
• Eventually one workstation will have a privileged domain account hash in memory which will used to gain access to databases, file servers and domain controllers, again using PtH (D’oh!)

PtH is not necessarily an exploitation technique, it is a feature provided by Microsoft Windows. Therefore there is no fix. It is possible to manage the risk of PtH style attacks but it requires horizontal segregation of authentication privileges.

Horizontal segregation of privileges within the domain

Mitigating the risk of a PtH attack is essentially a matter of assigning administrative accounts to limited security perimeters. Or when considered the other way around, it’s minimising the scope of access of all support and management accounts.

The strategy to follow is to severely limit the number of services or hosts an attacker would be able to compromise by gaining access to any account in the domain. For example, compromising a development workstation should not leak any hashes of accounts that are also administrators on development servers (or production servers or other workstations or domain controllers).

So in a very abbreviated way, here’s a number of steps that could be followed to minimise the risk of PtH attacks:

Step 0: The basics

• Ensure that all servers, workstations, laptops or anything with a network port has been security hardened. Make sure support for LM hashes is disabled
• Ensure that a very strong password policy is in place. If this is correctly implemented, your users will hate you. This is a good thing
• Please do not reuse passwords anywhere, including service or administrator accounts. Do not set simple passwords on service accounts.Your developers will hate you now. This is also a good thing
• Please do not reuse passwords anywhere, including service or administrator accounts. Do not set simple passwords on service accounts
• Ensure that all local administrator passwords are unique. Now even your network admins will hate you. This is also a good thing ;-)

This will make it far more difficult for an attacker to gain a foothold on your network. Without hashes and access to a host, there’s no PtH attack to conduct.

Step 1:

Security perimeters should be defined- such as HR workstations, Development workstations, Finance laptops, DMZ servers, Test servers, etc. The more the better. Each security perimeter should be assigned a domain account with administrative privileges (absolutely not a domain administrator) over the hosts in this specific group. This account should be set up in a way that it cannot access any other services or hosts, most importantly it should not be administrator of anything else on the network.

The rationale for this is that compromising one machine in one security perimeter will limit the breach to that perimeter. This is because any highly privileged accounts compromised should not have access to hosts on other perimeters.

Step 2:

Domain administrator accounts should only be used and allowed to access domain controllers. Every time one of these accounts is used, it leaves behind a trace of some sort – be it cached credentials or LSA secrets, etc.

If an attacker manages to compromise a domain controller, then it’s game over. All hashes can be extracted and by then PtH becomes a much smaller problem.

Step 3:

Service accounts should be considered on a case-by-case basis and attributed the lowest possible set or privileges required for the service to work properly. This is a significant risk with regards to PtH attacks and one that we regularly exploit.

Conclusion

Pass-the-Hash is something we take advantage of regularly during engagements. It is an effective way of exploring the network and extending (and hopefully elevating) the level of access gained in a network.

As discussed before, Pass-the-Hash is not a vulnerability, but rather an abusable feature provided by Microsoft. Therefore it can’t be fixed but its risk can be reduced. It requires a suitable approach to securing and managing a Domain based network.

Microsoft released two white papers respectively in 2012 and 2014 (better late than never, right?) called ‘Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques’ and ‘Mitigating Pass the Hash Attacks and Other Credential Theft, version 2’ which make for very interesting and very useful reading (link below). Will take a bit longer than this blog post though, you’ve been warned.

Pass-the-Hash (PtH) – https://technet.microsoft.com/en-us/dn785092.aspx

It’s also wise to ensure that Network Access Controls are implemented to restrict access to management services (and servers) to the hosts that absolutely require it. It’s not a silver bullet, but it’ll help.

Good luck!