Stop pass-the-hash attacks before they begin

These tips can help you prevent attackers from getting to your password hashes -- because once they do, it's game over

Oh how I long for the days of hackers simply cracking password hashes. Defending against that technique required only three steps: First, protect your password hashes from being stolen. Second, use strong password hashes. Third, make your passwords long enough to prevent easy cracking.

These days, cracking password hashes is passé. Today's hackers are all about pass-the-hash (PTH) attacks. With PTH attacks, the bad guys steal the hashes -- either from the password-hash-storage databases or from memory -- and reuse them to create brand-new authenticated sessions.

[ Download Roger Grimes' new "Data Loss Prevention Deep Dive" PDF expert guide today! | Master your security with InfoWorld's interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. | Get a dose of daily computer security news by following Roger Grimes on Twitter. ]

The password hash -- or whatever the authentication token -- is the ultimate logon secret. They're the keys to the kingdom, granting the attacker the authentication data that nearly every other protection mechanism is trying to protect. He or she has superadmin access, can do anything, and can bypass anything you throw in the attacker's path -- and there's no defense.

PTH-style attacks can be successful against any operating system and any authentication protocol, even Kerberos. The technique also can be used successfully against smartcard logons (because in Microsoft Windows, the NT password hash is still stored and used for NTLM authentication).

I keep trying to tell clients to worry about keeping the bad guys from getting the kind of access they need to pull off PTH attacks and not so much about PTH itself. Concentrating on PTH when the bad guy is a superadmin is like worrying about your brakes after a thief steals your car. Still, when you're repeatedly the victim of PTH attacks, it inevitably draws your attention -- and my clients are being hit by PTH attacks more than ever.

Block the pass
As I said, there is ultimately no defense against PTH attacks, but that doesn't mean you can't do anything to minimize the risk. Security isn't binary, after all. It's not black and white. It's shades of gray.

I've seen the technique of disabling weak password hashes work against APTs (advanced persistent threats), even when the attacker's own tool worked just fine using the stronger password hashes. The attackers didn't know that the weaker hashes were disabled, so they gave up attempting PTH attacks.

The best defense against PTH attacks is to prevent the attackers from getting superadmin access in the first place. Unfortunately, that involves nearly every traditional computer security defense I've discussed in this blog for years: least-privilege user logons, antimalware software, whitelisting, firewalls, and so on. Usually my clients aren't coming to me for PTH-defense advice until they realize they have a poor track record with their first lines of defense -- on to Plan B.

We can make it harder for the attackers to lift the hashes out of memory. In Windows, the password hashes can be pulled out of memory for the following logon types: interactive, batch, service, unlock, remote interactive, and cached interactive. That may seem like every type of logon you can think of, but it doesn't include network logons. Thus, simply accessing a NetBIOS drive share doesn't throw your password hash into memory.

Also, logging off often removes the password hash from memory, although it can be left intact by applications and APIs, so you never know. Rebooting a computer after logging out is one way to make sure your hash does not remain in memory.

Sever those ties
I frequently advise clients to minimize the logon types listed above from privileged accounts. Most environments I review frequently have admins using Remote Desktop Protocol (RDP) or some other sort of interactive remote software to administer, troubleshoot, and access servers and workstations throughout the environment. It's easy and effective, but it has the distinct side effect of leaving privileged hashes sitting around the environment -- on machines that are often not clean or trusted.

Instead, I encourage clients to use noninteractive ways to manage computers. Instead of using RDP, go with a console tool that allows you to connect to remote computers. Most of the Microsoft Management Console (MMC) tools can be retargeted to remote computers. Use PowerShell scripts instead -- at least the ones that don't require passing passwords.

Many of my smart coworkers and I are becoming even bigger proponents of getting rid of all superadmins or leaving, at most, only one. In Microsoft Active Directory (I'm a full-time Microsoft employee), you can use "delegation" to give admins just the rights they need without giving them superadmin privs, such as with domain admin or enterprise admin. No single domain or enterprise admin I've seen needed to do all the tasks those superaccounts allow. Instead, use delegation and hand out just the permissions and privileges necessary to tackle the tasks required for those individuals. If their hashes are stolen, the bad guy doesn't have a superadmin account.

A number of my clients are resorting to ultrafrequent password changes or one-time passwords. If attackers get the hash, their usable time period is of short duration. There are lots of vendor tools that will assist with both of these efforts. Also, minimize password reuse so that the theft of one password hash doesn't lead to other security domains falling.

Try to run the latest operating systems. They always have enabled defenses that earlier versions don't have. Vista, Windows 7, and Windows Server 2008 (and later versions), for example, use Kerberos with an AES hash instead of the traditional NT hash. While PTH attackers could ultimately use the AES hashes instead, they don't look for them right now, and none of the publicly available PTH tools work with them. Although this is sure to change in the future, remember security is not binary. Everything you do decreases the risk of PTH attacks.

Jump around
Another important suggestion: Admins should always perform admin tasks from ultrasecure, trusted computers. You shouldn't undertake admin duties from boxes that are exposed to the Internet every day through Web browsing, picking up email, and visiting social networking sites. Instead, create "jump" boxes for use, whenever possible, when an admin task needs to be addressed. These jump boxes will be less likely (hopefully) to be compromised, thus protecting the superadmin hashes. When the admins are on the jump boxes, they should use noninteractive remote tools to administrate the other boxes. That way, the hashes aren't stored in the other computer's memory. If an admin has to log on interactively to another untrusted computer, make sure the computer is rebooted as the admin logs out.

Some companies go so far as to have "jump" domains for admin use only. They implement one-way, selective trusts to minimize what authentication information is passed between the trusted and untrusted domains.

Consider using IPsec or AuthIP to restrict logons between particular computers to prevent bad guys from using a stolen hash on all computers. Lastly, remember to run antimalware scanning tools that detect PTH tools. Finding one of those lying around your network marks the start of a busy workday.

I hope I've shared a few new ways that you can implement to decrease the risk of PTH attacks. Send me your suggestions if you have something that has worked for you.

This story, "Stop pass-the-hash attacks before they begin," was originally published at Keep up on the latest developments in network security and read more of Roger Grimes's Security Adviser blog at For the latest business technology news, follow on Twitter.

Join the discussion
Be the first to comment on this article. Our Commenting Policies