There’s been a lot of talk recently about the “Pass the hash” and “Pass the ticket” threats. In this blog post, I’ll talk a bit about what these threats are, how real they are, and what you can do to protect yourself.
So first, what is it? These are two variations of the same threat. They both work by impersonating a user on the network and spread to other systems by leveraging cached credentials. Let’s step back a bit first and discuss the basics.
At the risk of greatly oversimplifying things, I’ll break this down into very simple building blocks. With any security model, there’s generally two fundamental pieces:
- Authentication – Identify yourself to the system and prove it. This is where you type in your user name (identify yourself) and your secret password (proof). Because only you know your password, it is assumed that if your password matches you must be who you say you are.
- Access Control – Once we know who you are, we can control what you can see and do.
Pass the hash & pass the ticket are all about #1; authentication.
Much has already been written about the nuts and bolts of how authentication works, so we won’t cover all of that. Instead we’ll focus on a few important points.
Every authentication system’s goal is to verify that you are a valid and approved user. To keep out the bad actors, the system has to take great care to avoid your identity from being compromised. A big part of this involves ensuring that your password stays safe; sounds simple but it’s actually quite difficult.
People sometimes get authentication confused with access control. Authentication services identify you as a legitimate user and have no part in determining where you have access…that’s where access control comes in.
There are a couple different types of authentication systems at work on most Microsoft networks:
- NTLM, NTLM2, LanMan (originating in LanManager and Windows NT.) If you worked with LanManager then you’ve been at this for a while.
- Kerberos (Windows 2000+ using Active Directory)
NTLM is “the old way” and Kerberos is the “new way”. NTLM is less secure, Kerberos is more secure. Kerberos is an integral part of Active Directory and has been present since Windows 2000.
Both of these authentication methods are in use today regardless of your Windows version. You might think that since you’re running Windows 2008R2 or later, you’re Kerberos only…think again. If you’ve ever typed NET USE * \\COMPUTER\SHARE, you’re using NTLM authentication, not Kerberos. Many apps also use NTLM authentication.
Why does all this matter and what does it have to do with threats?
Both of these technologies work hard to keep your password and identity safe (NTLM just not as much). Let’s start with NTLM. To protect your password from prying eyes, NTLM avoids sending your password over the network. Instead, it creates a Hash of your password; an encrypted number; a sort of computed number that represents your password but can’t easily be reversed back to a password. This hash is then used in place of a password. If you want to know more, read up on NTLM challenge response authentication.
These hashes are stored on your local computer, the domain controller, and domain members. If a hacker were to obtain that hash, he can use the hash during authentication against any target he wishes (pass the hash) and the target thinks it’s you. Since your hash is effectively like your password, it’s providing the “proof” for your authentication. The attacker won’t know your actual password, but it doesn’t matter because the hash is almost as good. With hash in hand, the hacker can often acquire the actual password through the use of publicly available tools that work against a pre-computed hash table (a lookup of common passwords that have also been hashed.) Bottom line is it’s bad news.
How could this happen? First off, you have to be an administrator to obtain deep enough access to rip off the hashes. The first step in making this possible is allowing your users to login with admin privileges. This is the first no-no.
Second, when you see that email telling you that you’ve won a Home Depot gift card…think hard about clicking any links. These are usually phishing scams; the first date with the attacker. Surprisingly, many people eventually fall for this. If you’re logged in with local admin privileges, the attacker’s software is now running as an admin. Not only could your credentials be compromised, but also anyone that has logged onto your system. Now imagine that the domain admin has logged into this box at some point to do maintenance, troubleshooting, etc. Now the domain admin’s hash is cached. From here it’s a game of trial and error. With hashes in hand, the process hunts the network looking for servers that can be accessed. With domain admin credentials, the hashes can be stolen from the other computers and before you know it, the entire network is unlocked. Windows machines store the last 10 logon hashes. This is done so that you can still logon in the event that the domain controller is unavailable (e.g. you’re in a hotel room offline).
Matters get even worse. Maybe you’re just a local admin and you don’t have a cached domain admin logon. Problem is, you have a local admin account; every member machine does and it’s almost certain that its password hash has been cached. To keep things simple, many admins use the same user password for local admin accounts. This makes managing hundreds or thousands of machines simpler. They also seldom, if ever, get changed and they’re almost always cached. So, if the hacker obtains one of these hashes, then they can access the local admin account of every workstation or server that has the same password. Yikes! Then from one of these, they’ll surely find the domain admins credentials cached. Eek, you’re hosed.
Now back to Kerberos. Pass the ticket is similar but not nearly as devastating. Tickets are granted by the Key Distribution Center (KDC) and the local workstation caches them in what’s called a Kerberos Tray. In theory, this tray can be compromised just like the NTLM hash cache, and the tickets exploited to gain access. However, the good news is that tickets expire; 10 hours by default. This makes it unlikely that an attacker would obtain access to anything beyond what the local user can access. If the local user is a domain admin, you might be in trouble.
The good news is that you can take real, practical steps to prevent these attacks:
- Avoid having users logged in as admins; even local admins. This is problematic in a bring-your-own-device (BYOD) world where people want and have control of their device. For convenience, power users will often add their domain user account to the local admin group creating a very risky situation.
- Use a good SPAM filter that prevents the phishing scam. This is the entry point of the attack. If you can prevent the email from reaching the user, you’ll remove the mindless temptation to click a link.
- Avoid duplicate local admin passwords. Create unique passwords for each local admin account. Even a simple scheme of base PW + hostname will thwart these types of attacks.
- Keep up with latest OS’s and updates. Microsoft is making continued improvements to prevent these attacks, moving more towards Kerberos authentications.
- Avoid RDP administration of desktops when possible. Instead, use remote network connections, PowerShell, remote management tools, etc. RDP creates a local login and will cache your credentials on the workstation making them available to be stolen.
- Use anti-malware endpoint protection.
- Monitor for rapid horizontal movement of accounts. Compromised hashes will be used to search for network accesses. Identifying it in real-time will allow the workstation to be removed from the network and avoid the spread.
A pass the hash attack could be devastating. Information could be stolen, content deleted, spyware installed, etc. By taking just a few proactive steps, these attacks can be almost completely avoided.