A look inside the Microsoft Local Administrator Password Solution

Hashtag chalk marks
Michael Coghlan (CC BY-SA 2.0)

Windows administrators have a problem -- passwords. Specifically, administrator passwords that lurk out there, identical across machines, just ready to be compromised. But there is finally a solution at the right price that mitigates this problem almost completely. Interested? Let's dive in.

The scenario

The issue at hand is simple: Every Windows NT-based box, as far back as Windows 2000 and up to Windows 10, including all of the server releases, has a local administrator account. This account, sometimes called the "500" account after the group ID number it has within the bowels of the Windows operating system, has full control over the machine on which it is located. It does not by default have any domain privileges. (Domain administrator accounts, of course, also have by default full control over local machines that are members of the domain -- but this can generally be scoped to a more limited set of permissions if necessary.)

Once you join a machine to a domain, the local administrator account does not go away. It stays there, enabled in most cases unless you explicitly disable it or rename it or engage in other some such method of obfuscation.

Since it is a local account, however, you do not get the benefit of being able to synchronize passwords and centralize them among domain controllers. Each local administrator account password just sort of sits there. This creates an uncomfortable situation where out of a lack of other resources, most automated installations and deployments (hello Windows Deployment Services) simply put in a secure but identical password for each and every single system they touch.

It is not ideal, but you might be thinking at least the password is secure. Or maybe you actually try to keep track of multiple different local administrator passwords in a spreadsheet.

Managing these local administrator accounts has been a problem for as far back as I can remember, even back when I was part of the administrator team at a major research university in North Carolina. It has been over a decade, so I do not remember exactly how we managed the different passwords, but as I recall it was done with a massive spreadsheet and a regular password change interval for all of the local administrator accounts across the hundreds of machines in the department.

The problem

A new element, though, has emerged in the past few years. What is different these days is automated pass-the-hash attacks. What once was a sort of esoteric attack that was not a huge remote threat has become basically a standard operating procedure for crackers once they get access to a compromised Windows box. And those cracked Windows machines are widely available, even inside large organizations with generally decent security and IT practices.

Essentially, within Windows, passwords are converted by Windows into a "hash" -- a fixed-sized 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, of course, you're turned away.

But what if you were able to access the hash database for privileged accounts -- like 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.

This whole scenario transforms from theoretical to probable and practical with the advent of tools that are freely available and downloadable from the Internet. For example, here is a quick narrative of how this would work: Log on to your member server with the local administrator account. Then log off, and then log on to your member server with the domain administrator account. Next, log off there, and then log back into the member server with the local administrator account.

Google around and find the lslsass64.exe utility and run it with the dump option to dump the hashes currently stored in memory. Look for things like DOMAIN\administrator or DOMAIN\admin. Google around again and find the runhash64.exe utility, and then run that to pass the hash.

The resulting 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.

Voila, you have passed the hash. You are now a cracker. Hopefully you are white hat.

Now picture this attack scenario where a cracker compromises a domain-joined Windows machine -- and all of the domain-joined Windows machines have identical local administrator accounts. The cracker uses the tools above, or some others that are even easier and more oriented toward launching remote attacks on multiple compromised machines, and thus already knows the right hash.

In doing so, he or she basically owns all of the computers in the enterprise. Game over, do not pass Go, do not collect $200 -- in fact, you might be collecting unemployment.

1 2 Page 1
Page 1 of 2
The 10 most powerful companies in enterprise networking 2022