Intercepting pass-the-hash attacks

Pass-the-hash attacks are among the most difficult assaults to thwart. In these attacks, an intruder — or an employee performing unauthorized activities — gains administrative (or root) access to a computer where a user logs on. With that highly elevated access, the intruder can obtain the user’s password hash from the machine’s memory and log on to other computers as the spoofed user.

Once an outsider obtains elevated access, defending against the pass-the-hash attacks is very difficult. There are even free hacking tools available to aid the process. Even worse, pass-the-hash attacks work against very long passwords, smart cards, and many other logon tokens. There aren’t a lot of defenses one can deploy to prevent them, which is why security admins fear them. However, defenses do exist.

[ Master your security with InfoWorld’s interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld’s Security Central newsletter. ]

Not just a Windows problem Some people mistakenly believe that only Windows is vulnerable to pass-the-hash attacks. (I’ll note that Microsoft is my full-time employer.) However, most of today’s popular operating systems perform subject authentication (for example, user, computer, service/daemon) using password hashes. Those hashes sit in the computer’s memory on those operating systems as readily as on Windows and can be obtained just as easily, if not more so, if public tools are on hand.

A little background first: In early and less complex operating systems, passwords were originally stored in plaintext form and often communicated between the logging-on client and the authentication server/service using an open, unencrypted communication channel. This still occurs on many insecure operating systems and programs, such as FTP and Telnet, although it is universally decried when found.

Operating system vendors decided that password hashes could make some types of password compromises harder to accomplish. With a good password hash, it’s very unlikely or very difficult for a person obtaining the password hash to convert it back to its original plaintext. Even if the attacker gets the password hash database (in Windows, this is stored in the local SAM database or in the Active Directory database) or captures the hash on the network, he or she could not immediately convert it to its plaintext equivalent for use.

Prior to Windows Vista, Windows stored password hashes in two hash forms: LANManager and NT. IBM created LANManager in the early 1980s, and it’s not considered secure. In fact, it’s readily and easily crackable when used to protect Windows passwords up to 14 characters in length.

The NT hash, on the other hand, is a good cryptographic hash and has proven resistant to cracking when lengthy and/or complex passwords are used. Unix, Linux, and BSD systems have similar password hash issues, where the early hashes are no longer considered secure, and the new hashes, including SHA-512 and Bcrypt, are recommended in order to protect against cracking.

Although a password used to be considered secure when it was at least eight characters long, today’s best public authorities such as NIST suggest 12-character minimums for regular computers. Password-cracking speeds advance every year, though, so even a 12-character password is sure to be too short in the near future.

Intercepting the pass Most researchers, myself included, have determined that pass-the-hash attacks aren’t a problem so much as a symptom of the higher risk: the fact that an attacker is able to secured highly privileged access to the hashes in the first place. After all, once attackers have admin or root access, what can’t they do? In an Active Directory network, an attacker has to be an administrator on a domain controller in order to get most of the users’ hashes, which means, in most cases, the attacker has effectively become a domain administrator. Pass-the-hash attacks are just one of your problems.

Adam Arndt, my good friend and colleague, has refused to fall into the indefensible trap. Along with dozens of other researchers concerned about same problem, he has spent months studying it. I don’t know anyone who has thought about it harder and fought to offer deployable defenses.

Adam’s biggestrecommendation is to prevent or minimize domain admins from logging on to nondomain controllers and from performing non-Active Directory management tasks. He makes the case that domain admins should only be logged on to perform tasks that are limited to domain admins. Even then, he opines, those tasks should be performed only on domain controllers. In Active Directory, 95 percent of the tasks normally assigned to domain admins (such as user and computer account management, group policy updates, and so on) can be delegated using the Active Directory Delegation Control wizard to specialized, role-specific groups that are not members of the domain admins group.

For example, by default, domain admins are made members of the local Administrators group on each domain-joined computer, which in turn gives them full control over all resources. Instead, remove the domain admins from the local Administrators group (with appropriate testing, of course) and replace it with a role-specific group that needs full control to manage particular computers. For instance, do your domain admins really require full control over your most important databases and all the sensitive data therein?

Instead, document all tasks the various domain admins perform on a regular basis. Then create role-specific groups and delegate those role-based tasks to the appropriate groups. (Microsoft provides some guidance on these tasks.) Next, remove all the “unneeded” domain admins, relate the remaining domain admins, and make them highly secure. Some companies have successfully employed special tools — CyberArk, Cloakware — to simplify the tasks of managing and controlling the remaining highly privileged admins.

The idea here is to minimize the number of highly privileged admins and to prevent them from using their credentials to log in to regular workstations — which are more likely to be compromised than better-protected domain controllers.

These recommendations are neither unrealistic nor impractical: I’ve worked with many companies that have adopted them and are working well operationally, with much less risk than before.

Other measures to thwart pass-the-hash attacks including requiring reboots on any computer where a highly privileged user has logged on. This prevents the hashes from being in memory, where a pass-the-hash attacker could easily obtain them.

Server and domain isolation is an excellent technique for minimizing the spread of pass-the-hash attacks. Not only can it prevent attackers from gaining access to most of your computers and servers, it can cause all of the hacker’s attempts to set off your other defense-in-depth programs, such as IDS and firewalls.

Additionally, it makes sense to use antimalware-scanning software to look for pass-the-hash tools. If you find any in your environment, you’ll need to investigate immediately. All of this advice is meant to supplement the defenses you should have already implemented to prevent attackers from gaining privileged access to your systems.

These recommendations boil down to nothing more than putting the least-privileged security principle into practice. Doing so improve your security posture far more than just mitigating pass-the-hash attacks.

This story, “Intercepting pass-the-hash attacks,” was originally published at InfoWorld.com. Follow the latest developments in security and read more of Roger Grimes’s Security Adviser blog at InfoWorld.com.