Prevent your systems from being hijacked: A quick guide

It’s time to rethink some old, and now outdated, security truisms that enable a very scary kind of attack.

As computing power and programming prowess have increased, so have the means to make this attack simple, effective and lightning-quick, to the point where it’s now a huge risk. Tools are freely available to let someone own your entire Active Directory infrastructure in a matter of minutes, without brute-force cracking or any other compute-intensive resources.

The attack is not new: It’s known as a “passing-the-hash” attack, and it’s been around for years. Those proficient in security matters know of the attack and the general principle behind it: Passwords are converted by Windows into a “hash” — a fixed-size string of cryptographically transformed data — every time they are created. This way, your passwords aren’t sitting in plain text anywhere on your machine, nor are they transmitted in clear text when the authentication happens over the wire.

When authentication does need to happen against one resource or another, Windows hashes the password you provide and then submits that hash to the host. The host then compares it with the hash it has on record; if it’s the same, you’re granted access; if not, you’re turned away, of course.

But what if you were able to access the hash database for privileged accounts — for, say, an administrator — and pass that hash directly to a resource? Remember, Windows never transmits the passwords themselves. The only computation that is done is matching the transmitted hash to a hash that’s stored in a database of valid authentication data. If you connect and pass an administrative username and an administrator’s hash, that’s all you need to gain privileged access to a system. You don’t need to know the password; you just need the hash.

So what’s the problem here?

For years, security experts have been preaching the importance of secure passwords. Given that that’s the most prominent entry point into most systems — the combination of usernames and passwords as a primary set of credentials — this advice has usually been well-placed and certainly well-intended.

In addition, many administrators have been conditioned to believe that as long as passwords, or better yet, pass-phrases, are in use, granting local administrator rights to users is typically not a significant risk to a network.

The emphasis in those equations is local administrator — really, the domain is where the real jewels are. Going a bit farther, granting junior administrators limited administrative rights to reset passwords on certain machines in a domain has also been considered a medium to low risk for years.

But as you will see, the passing-the-hash attack makes a lot of this kind of thinking outdated. Luckily, there are some things you can do to avoid having this happen on your systems.

Performing a test attack, live

This whole scenario transforms from theoretical to probable and practical with the advent of tools that are freely available and downloadable from the Internet. Here’s how to make the attack work in your lab environment.

You need two computers, with one, as you might expect, being a domain controller. The other can simply be a member server. And you need the lslass and RunhAsh utilities from Truesec.

You can download lslsass x86 here, lslsass x64 here, RunhAsh x86 here and RunhAsh x64 here.

Get the appropriate compile for your client computer’s instruction set. Then, follow this procedure:

1. Log on to your member server with the local administrator account.
2. Log off, and then log on to your member server with the domain administrator account — the domain represented by the domain controller on your other machine.
3. Log off, and then log back in to the member server with the local administrator account.
4. Run the lslsass64.exe utility with the dump option (that is, run lslsass64.exe dump from the command prompt) to dump the hashes currently stored in memory. Look for things like DOMAINadministrator or DOMAINadmin — whatever your domain administrator account is. You’ll see the hash in there if a domain administrator has ever logged on to this machine.
5. Write down, or cut and paste into Microsoft’s Notepad, the domain administrator hash you find.
6. Use the runhash64.exe utility to pass the hash and finalize your rooting of your own lab domain. A new command prompt will open.
7. The new command prompt that opens has the hash of your domain administrator account injected, so you can run privileged commands against your domain controller from this command prompt. Windows will faithfully execute them as if you were logged in directly with the admin account.
8. Try running Active Directory Users and Computers from the console and create a new account.
9. Try running the same lslsass64.exe utility against the domain controller and dump all of the hashes you find there. Those are the keys to your kingdom, exposed for the taking right there.
10. Install something else, maybe a back door. Download sensitive information from anywhere on your network.

In 10 steps, you just went from a local administrator to a fully rooted network, and there weren’t any roadblocks whatsoever to prevent that from happening.

Apart from never granting anybody local administrator rights to anything — a practice not particularly realistic — and using your domain administrator credentials only on domain controllers (and saving other administrative tasks for another delegated administrator account), there is something you can do to thwart this type of attack.

Meet Windows Server’s authentication mechanism assurance

Enter authentication mechanism assurance, a feature new to Windows Server 2008 R2. This feature works with smartcard deployments to create different levels of access based on the way users authenticate to a system.

By issuing a special smartcard template and tying it together with a dynamic group, you can ensure that when users log on to a system based on that smartcard, they are promoted to being members of that group. When they log off, they are removed from that dynamic group.

So in this sense, you can create three custom smartcard templates — client administration, server administration and domain administration — and then create custom policies to restrict their issuance to certain users. Then create universal groups on your domain under the same names, and tie the issuance policies together with group membership. (For a walk-through on this linking process, see TechNet.)

How does this help? It kills the passing-the-hash attack. While it doesn’t prevent a nefarious user from finding the domain administrator hash on a system he’s recently used, the hacker can’t actually use that hash to obtain privileged access to other resources on the network.

If the hacker tries to pass the hash without the smartcard present, the appropriate administrative group’s security identifier, or SID, will not be present in the hacker’s injected session. By limiting the membership of the group to smartcard logons and not just matched-hash authentication, the hash becomes rather useless for the purpose of injection attacks.

And restricting the access to the admin groups dynamically lets administrators work in their normal accounts in their everyday roles, without worrying about keeping track of multiple credentials, delegated accounts and so on. When they need to perform a task on the network that requires privileged access, they can just insert the right smartcard and then perform that task.

For this to work, you obviously need the infrastructure for smartcards, but that equipment has been standard on many corporate-issue laptops for some time now. On the software side, you just need to upgrade your domain controllers to Windows Server 2008 R2. No other system upgrades are required, and everything is backward-compatible on the client side. Clients using systems as old as Windows XP can still be protected using this method.

It’s very inexpensive insurance to completely prevent this devastating attack.

Other means of protection

If you’re not able to upgrade to Windows Server 2008 R2 and use the authentication mechanism assurance feature to protect yourself, here are some suggestions for other steps you can take.

• Don’t grant your users local administrator rights. This is cumbersome, but it ensures that the local hash database resists compromise, keeping other users’ hashes away from prying eyes.
• Use domain administrator credentials only on machines with domain controller roles installed. Use delegated administrator accounts with fewer rights to perform privileged actions on other machines like client computers and member servers.
• Don’t grant junior administrators local administrator rights on servers. For that matter, avoid granting anyone local administrator access on servers, for the same reason — to keep the hash database secure.
• Consider setting up a whitelist of known-good applications. For some organizations, this is a trivial task, but it will prevent the operation of the utilities we used in the attack and any other utilities that may come out to make this attack easier to execute.
• Never use the domain administrator account to grant privileges to service accounts. When service accounts access resources across the domain with the domain administrator account, they spread that hash everywhere. This is a huge vulnerability.

Jonathan Hassell is an author, consultant and speaker on a variety of IT topics. His published works include a variety of books on Windows clients and servers, including Learning Windows Server 2003. You can reach Jon at jhassell@sunvalleygp.com or follow him on Twitter at @jghassell.