Defeat dreaded pass-the-hash attacks

Perfect security is elusive, but companies can take key steps to keep malicious hackers from taking over their systems

Successful PTH (pass the hash) attacks are becoming increasingly common in the corporate world in recent months, a trend I've witnessed first-hand in the IT security trenches. PTH goes hand-in-hand with the types of infamous APT (advanced persistent threat) attacks that have staggered companies such as RSA, Sony, Dupont, and others, so organizations need to be prepared do defend against them. There's just one surefire way to prevent them: Secure all your systems perfectly.

Pulling off that feat is far easier said than done. Ask any IT admin at a company that has undergone penetration testing by an outside hacker team. It's hard to stave off a determined aggressor. When I was a professional penetration tester for nine years, I was not stopped once from gaining privileged access in a forest. In every case but one, it took less than an hour. There is always an unpatched machine or easy-to-find opening to pull off a privilege-escalation attack. It's almost child's play once you know what you are doing.

[ Security Adviser Roger A. Grimes explains why you should not count on Kerberos to thwart PTH attacks. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

That's no reason to up and surrender to would-be attackers, though. Pulling off perfect security is extremely difficult to achieve. However, based on the work that my peers and I have been doing in the field of late as PTH attacks have risen, I can confidently recommend some critical steps for organizations to take to protect themselves.

As a refresher, PTH attacks are a subset of attacks otherwise known as authentication token theft and reuse. Although PTH attacks can be used against any popular OS (Windows, Mac OS X, Linux, BSD, and so on), they are most often associated with Windows authentication because of the readily available, public attack tools for the Microsoft platform. Like any token-theft attack, they work on the very basic and simple principle that once a bad guy knows your ultimate authentication "secret," he or she can reuse it to open new authentication sessions. In the most common scenarios, attackers steal the victim's LM or NT Windows password hashes from a Windows authentication database or from a server's memory, then reuse them to create new authentication sessions.

Once the attacker has your hashes, it can be difficult to prevent him or her from wreaking havoc. After all, once an attacker gets at your hashes, he or she must already have superprivilege access. They are already king on the computers or in the compromised domains/forests. What can't they do? It's like worrying about how car thieves will treat the brakes.

Traditionally, defending against a PTH attack has been reactionary, entailing figuring out how the attackers got in your network, fixing the holes, kicking out the attackers, changing all passwords, and working hard to prevent it from occurring again. Ideally, all those holes should have been closed off in the first place. But again, that's the toughest thing about minimizing the risk of PTH attacks. In order to prevent them, you must essentially do everything. It's hard to pull off perfectly -- but there are many ways to minimize the risks.

The first step is to get rid of as many elevated logon accounts as you can. PTH only works if the attackers can gain local Administrator or domain Administrator permissions and privileges. Most companies have far more elevated logon accounts than they need. Microsoft (my full-time employer) recommends two domain admins per domain. Most companies I survey have dozens to more than 100.

Rarely should someone log on as domain admin. Almost no single person in a company needs the ability to do everything to a domain, such as manage users, modify all computers, modify all Active Directory attributes, change or reset everyone's password, and so on, unless you're a small team in a small company. In most cases, delegation is the way to go instead.

1 2 Page 1
Page 1 of 2
Microsoft's very bad year for security: A timeline