Where pass-the-hash attacks could be hiding

Windows computer and service accounts, as opposed to user accounts, can be especially vulnerable to hash theft. Here's how to reduce the risk

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.

1 2 Page 1
From CIO: 8 Free Online Courses to Grow Your Tech Skills
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.