Pass-the-Hash (PtH) attacks have become probably the most common form of credential attacks used in the hacking community. Especially in Microsoft Windows environments, PtH tools are so popular and easy to use, that many attackers no longer even bother to crack passwords anymore. Why waste the time when an administrator’s hash is just as convenient, if not more so, to expand the scope of a breach?
PtH attacks work by abusing the way Windows and other operating systems store the authentication credentials used to login to a system. Rather than store the clear-text password, the system stores a one-way cryptographic hash of the password. This hash is then provided to other systems for authentication in place of the password. Attackers who gain Administrator-level access to one system are able to steal its hashes and use them to authenticate to other systems.
The real crux of the problem lies in the convenience of Single Sign On (SSO) features. Windows allows users to do things like access network file shares, connect Microsoft Outlook to an Exchange server, and authenticate to a SharePoint website without having to constantly re-enter their user credentials. Instead the hash is stored locally and then passed along each time a network service needs to authenticate. Unfortunately if the system is able to access the hash, then an administrator can as well.
For most system administrators in Windows environments, the threat of PtH attacks have simply been an indefensible risk that must be accepted. The business will never sacrifice the features, so the attack will always be a weak point in the armor. But that is starting to change. Last year Microsoft released a white paper titled Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques. In the paper they discuss PtH techniques in detail and provide specific recommendations for mitigating the threat of these attacks in modern Windows environments.
The guidance from Microsoft contains three specific mitigation techniques that are “effective, practical, and broadly applicable,” as well as nine additional recommendations that can increase a network’s resistance to PtH attacks. Lastly, the paper outlines four commonly suggested mitigations that have significant costs and minimal effects.
Here are the top three:
Mitigation 1: Restrict and protect high privileged domain accounts
The goal is to limit an attacker’s ability to access hashes of Domain Admin and similar accounts by minimizing their user, and restricting them to only be used on secure systems. This also means that system administrators should have secondary accounts for administrative actions that are not used for non-administrative activities.
Mitigation 2: Restrict and protect local accounts with administrative privileges
This step outlines steps for disabling remote access and administration of machines by local administrator accounts. It also includes setting unique passwords for the local administrator account on every machine. The aim is to prevent attackers from easily using a local administrator hash against another machine with the same local administrator password.
Mitigation 3: Restrict inbound traffic using the Windows Firewall
Most workstations rarely need to accept incoming traffic from other workstations. As much as possible, all systems (servers included) should restrict all incoming traffic to only that which is absolutely necessary. This prevents an attacker from bouncing around the network looking for higher level hashes.
In addition these three guidelines, Microsoft strongly encourages using the following nine recommendations as well. Though they may not be “as effective, practical, and broadly applicable,” they will have a considerable impact on an intruder’s ability to successfully use a PtH attack. These recommendations do however have a much wider range of effectiveness and level of effort required to implement.
- Do not allow browsing the Internet with highly privileged accounts
- Remove standard users from the local Administrators group
- Configure outbound proxies to deny Internet access to privileged accounts
- Ensure administrative accounts do not have email accounts
- Use remote management tools that do not place reusable credentials on a remote
- Avoid logons to less secure computers that are more likely to be compromised
- Update applications and operating systems
- Limit the number and use of privileged domain accounts
- Secure and manage domain controllers
- Remove LM hashes
- Disabling the NTLM protocol
- Smart cards and multifactor authentication
- Using Jump servers for administrative access
- Rebooting workstations and servers after privileged accounts log off.
Nathan Sweaney is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at email@example.com or visit the Secure Ideas – Professionally Evil site for services provided.