by Calum MacLeod
There was a time many moons ago when, in an age of innocence, the term, “pass the hash” had an entirely different meaning. For some of us old enough to remember, or still have our wits about us, “pass the hash” was something you did at the back of the school on a Friday night. But times move on, and suddenly it seems that “pass the hash” is in vogue again.
But like so many other things, the meaning has changed. I recently heard Craig Groeschel talking about how words have changed. Ridiculous now means “really good,” sick means “cool,” bad means “good.” And by the way, if you’re wondering how someone who played “pass the hash” knows about Craig Groeschel, well that’s a cool – as in “nice”, not “cold” – story. Anyway, I digress.
Suddenly it seems that “pass the hash” is back in vogue. You’d think it had only just been discovered, and that this is suddenly the latest exploit that is about to be unleashed on the corporate landscape. Yes, within a week or two, you’ll be having the inside sales departments calling to ask if you have pass the hash, or “PTH” problems. In fact, come April, we can expect to see every vendor in the security space having PTH solutions on their stands at tradeshows. This, of course, will be followed by the PTH User Groups sponsored by vendors desperately trying to save you from PTH attacks. APTs will have become a distant memory, as that was all solved in 2013. 2014: the year of PTH!
What Is It?
Now, if like me, you haven’t graduated much beyond understanding the “original hash,” then it has loads to do with math – which is probably why I should ask my wife to write this, since she has the math degree.
A PTH attack can happen when just the password hash is sufficient to authenticate a user to a system. This is more of an issue on older windows systems, such as XP and 2003. Because of the way in which administrative accounts were set up and stored on a system, it means that, very often, the local administrator account is vulnerable. And because it is used for many administrative tasks such backups, patching, installing software, etc., it becomes a security risk. If one of the machines is compromised, then the local hashes can be dumped out of the Security Account Manager (SAM) database, which is present on servers running Windows Server 2003. The SAM stores user accounts for users on the local computer, so if an attacker has now gained administrative access to that machine, other machines on the networks become easy targets.
Newer versions of Windows are less vulnerable because of the way in which a machine acts when added to a domain, but it still carries risk. If you’d like a more intelligent description, you should have a look at Still Passing the Hash 15 Years Later. At this point, I should confess that imitation is the best form of flattery. And you will see that much of my “research” came from the site! My thanks to the authors!
Where Does It Leave Us?
Contrary to the claims of certain security vendors, PTH is neither new nor solved by simply changing administrative passwords.
That is, unless by administrative passwords you mean administrators, service accounts, scheduled tasks, and all the other accounts in a system that are likely to be using the Administrative password. Simply changing your administrator user password is not going to protect you. It may give you that nice feeling that the original PTH gave, but you can be sure that one of these days you are going to wake up with a terrible headache, and discover that changing your admin accounts didn’t offer any real satisfaction.
Ultimately, you need to have a complete inventory of everything from your registry onwards. And it’s no good having last week’s inventory!
Vigilance was key in the original PTH scenario. Someone had to be constantly on the lookout for “hackers” – be they teachers, parents or the dreaded “I am the law.” The same applies for the 21st century PTH. Organizations need to have continuous monitoring in place for the complete Windows environment and be dynamically discovering every location throughout the environment that an account is referenced by a Windows service, task, COM/DCOM object, or AT account.
Discovering where the accounts are used is half the battle. And snapshots in time are not going to do it. It didn’t work in the old PTH days, and it doesn’t work now. You can’t manage what you don’t know, and unless you are checking continuously, you will get caught. I know from past experience! And, of course, should you decide to change the passwords regularly, don’t end up starting some process to change passwords by creating yet another password on that system so that you can logon on to change the passwords. At this time, you might be saying to yourself: “This doesn’t make any sense.” And you’d be right; it doesn’t make sense. But that’s another story.
Is There A Moral?
I suppose you could say that PTH has never been good for anyone, and both variants can be life changing, and not necessarily for the better. Pass The Hash in IT terms has been around for close to 15 years, and exploits were available several years ago. It’s not a new vulnerability, but it is something that you should be aware of. Taking proper precautions, such as ensuring that passwords are changed regularly, will help. It is also important to ensure that services and scheduled tasks are not using the same passwords across your infrastructure. A way to avoid this is to segment your environment in such a way that a breach can be contained. Oh, and always be vigilant. Now please “pass the hash.”
Calum MacLeod is responsible for European business development at Lieberman Software.