Where pass-the-hash attacks could be hiding

A knowledgeable customer of mine recently inquired if there was a security risk in not changing Windows computer account passwords on certain computers. Like user accounts, computer accounts have logon names (they end with the $ symbol) and passwords, which they use to log on to Active Directory.

Most Active Directory shops know how computer accounts work. What they seldom know is that these computer accounts can be used for malicious purposes. My customer understood this and wondered what the threat model looked like. I love customers like this because they don’t do anything unusual without considering the possible side effects. The security of their environments usually ranks above average.

[ Find out how to block the viruses, worms, and other malware that threaten your business, with hands-on advice from expert contributors in InfoWorld’s “Malware Deep Dive” PDF guide. | Keep up with key security issues with InfoWorld’s Security Central newsletter. ]

Special risks for computer and service accounts

When computer accounts are established, Windows gives them random, long, and complex passwords. And by long and complex, I mean 127 characters long and complex enough that they don’t have to worry about password-cracking. They are changed every 30 days by default, but the length of time can be changed using a group policy setting or registry edit.

The real threat from a computer account is its storage password hash. If retrieved from memory or from the Active Directory database (NTDS.DIT), it can be used just like any other password hash or credential theft in PtH (pass-the-hash) attacks. Many PtH attack tools, like the Windows Credential Editor, will readily grab computer account password hashes and allow you to use them.

Nearly any Windows subject (user, computer, or service) can be commandeered in PtH attacks. I’ve seen service accounts used many times before, and they often have elevated privileges — including domain administrator. One enterprising advanced persistent threat even hijacked the built-in krbtgt account, which is used by Active Directory for Kerberos authentication. Windows creates the account, gives it a password, and uses it behind the scenes. You’re not supposed to touch it, delete it, or change its password under normal circumstances.

The great thing about using krbtgt in a PtH attack is that almost no one ever thinks about the krbtgt account as a logon account. Certainly no one worries about it. But in one PtH attack scenario, the attackers used it to sustain their access to an environment when all the other passwords were changed.

This one threw both the client and me for a loop — until we figured out how they were getting back in. We had to reset the account to keep the attackers out, which caused all sorts of troublesome operational problems. Score one for the attackers.

When attackers gain access to password hashes from any user, computer, or service account, they obtain the security context of the stolen credentials. Service accounts often belong to elevated groups. Although most people don’t know this, their domain-joined computer belongs to one or more groups.

To see what groups a domain-joined Windows belongs to, at an elevated prompt type the following:

gpresult.exe /scope computer /z

Then hit Enter.

Your computer always belongs to the Domain Computers group, which is an authenticated group, and usually many more (such as Domain Controllers, Pre-2000 Windows Authentication, and so on). Each of these groups has permissions to one or more folders and files. For example, every computer account can easily access a domain controller’s Netlogon folder, which contains scripts and other programs used when a computer and user logs on to the domain.

Many attacks simply need authenticated access to succeed. An attacker can get that by using a computer or service account, and either of those may belong to one or more elevated groups.

To answer my customer’s original threat modeling question, you must treat a computer account just like any other user account — with one big caveat. Fortunately, so far I haven’t seen attackers using computer accounts in the wild, even though multiple PtH attack tools readily use them. This is good. It’s usually because, in general, computer accounts do not belong to highly privileged groups. PtH attackers concentrate on user and service accounts because they are more likely to belong to groups that will get them what they need. Until those attacks start getting harder to accomplish, you probably don’t have to worry as much about computer accounts.

Defending computer accounts against PtH attacks

Now that we’ve talked about the risk, what can you do?

First, be aware that bad guys can use computer accounts to attack, even though user and service accounts are their first choices.

Second, if you have to change all passwords after a successful attack, you may also need to change your computer accounts. Personally, I’d want to see evidence that the bad guys used computer accounts first before I changed them, because changing them is an operational nightmare. You will absolutely have logon and password synchronization issues for each one that you change. It’s not pretty.

Some customers ask me if shortening the default 30-day password change window helps. The answer: Yes and no. Enabling more frequent password changes does decrease risk. It means that if a bad guy succeeds in capturing your machine password hashes, they’re useful for a shorter period of time. Experiment and implement with caution. Again, personally, I would go down this route only if I knew an attacker was using it or if I ran out of other troubleshooting options.

Third, don’t forget that other built-in accounts, like krbtgt, have been successfully used in the past. Again, if I suspect they have been used, I’ll change their passwords/hashes.

Make sure to frequently change service account passwords. Consider using a third-party tool or Windows’ own built-in service account password-changing service. Huh, you say? Windows has the ability to change service account passwords? Since when? Since Windows Vista and Windows Server 2008. Microsoft offers two types of built-in service accounts: virtual service accounts and managed service accounts. In Windows 8 and Windows Server 2012, they added a third option called group managed service accounts.

The password-changing function can be used only in particular service account scenarios. But if enabled, Windows or Active Directory takes over the creation and changing of the very long and complex passwords. When using virtual or (group) managed service accounts, the passwords are changed every time the hosting computer account’s password is changed (every 30 days by default). As discussed above, you can shorten this interval if you want.

When taking advantage of the new anti-PtH methods in Windows Server 2012 R2, make sure to apply them to any at-risk service or computer accounts.

I don’t want everyone to start making massive changes to their computer accounts or worrying too much over malicious hackers using those accounts for mischief. But simply knowing that it’s a possibility can help make you the smart person in the room when the topic comes up.

This story, “Where pass-the-hash attacks could be hiding,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’ Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.