Working With Windows Local Administrator Accounts, Part I

In writing about hackers and their techniques, the issue of Windows local Administrator accounts often comes up. Prior to Windows 7, the Administrator account was created by default with no password. This was not a good security practice, and hackers have been taking advantage ever since.

Starting in Windows 7, the local Administrator accounts were disabled by default. And you should disable them in your domain regardless of which Windows OS you have! But for various reasons, some of them based on mistaken ideas, the local Administrator accounts hang around on many installations. They’ve too often been given easily guessable passwords by IT, and sometimes the same password across large parts of the domain.

If hackers can get a foothold on the system, they’ll look for this privileged local Administrator account as part of their evil checklist. They’ll then try to use these accounts as they start the lateral movement phase of their post-exploitation.

In short: they guess the local Administrator’s account password, grab the hashes of domain-level users with mimikatz, and then move around the network.

But I Need It!

Or they may not even have to grab hashes of domain-level users. In many environments, the local Administrator account passwords themselves are set using the same pattern: once you guess one, you can figure out the whole shebang.

In the real world, you may have to deal with IT staff arguing the Administrator accounts need to be available — perhaps because processes or software is dependent on their existence.

Is there a way to keep the Administrator accounts but lessen their power?

Microsoft has a few recommendations on how to secure them. Essentially, you configure a Group Policy Object (GPO) to disable network access, remote desktop, and a few other services through User Rights Assignment.

Just to see this how would work, I went back to my now famous Acme domain that I set up up in Amazon Web Services.

Let’s assume passwords for Acme’s local Administrator accounts are based on a pattern — the server name followed by a numeric sequence — as a memory convenience for the beleaguered IT staff.

In my pretend scenario, I used the vanilla psexec utility — which by the way played a part in the recent NotPetya ransomware outbreak — to laterally move to the Taco server. Putting on my pen-testing hat, I entered my guess for the Administrator password to Taco, and miraculously it worked.

You can see the results of my psexec activities below before I set the “deny network access” GPO.

After I set the GPO, the psexec utility complained that my user name or password was invalid — User Rights Assignment was doing its job. If you’re trying this at home, remember to run gpupdate /forceon the domain controller to trigger the GPOs to sync to all the domain members.

This is a compromise solution that lets you keep the local Administrator accounts but prevents hackers from easily exploiting them to move around the network.

Don’t Change Passwords With Group Policy Preferences

The right thing to do is to disable the local Administrator, and then set up domain-level groups with restricted privileges under the local Administrators group. We’ll start discussing how to do this further below.

But let’s say your heart is set on keeping these local Administrator accounts; you realize the passwords were set for convenience (and not for security); and you now want to improve the passwords on a global level.

Once upon a time, Microsoft introduced Group Policy Preferences (GPP) in Windows server 2008 to extend GPP. One of the new GPP capabilities allowed you to update user and group information on a domain basis. At one point, you were allowed to change passwords and then push out the updated passwords across the domain

However, hackers found a major vulnerability in GPP’s password distribution process. While Windows encrypted the password, they released — duh! — the encryption key in their technical documentation.

They’ve since put out a patch for it, and in the AWS instance I was most recently working with, the password entry was disabled — it’s grayed out in the graphic below.

However, early on in my experimenting I launched an unpatched AWS instance, where I was able to enter the password. And sure enough I could pull up the AES-encrypted password from the SYSVOL folder.

And there are no doubt many more servers out in this world without the GPP patch. In fact, pen testing utilities such as crackmapexec search for encrypted passwords — see the -gpp-passwords option — in the SYSVOL folder and then conveniently decrypts them.

Thankfully, Microsoft came out with another way to do bulk updates of Administrator passwords, giving it the catchy name of Local Administrator Password Solution, or LAPS. You can download it here. I plan on giving it a try, and I’ll let you know the results.

Restricted Groups

The better way to handle local Administrator accounts is through the Restricted Groups GPO, found under Computer Configuration > Policies > Windows Settings> Security Settings. This GPO manages the local Administrators group by letting you add a domain-level group under it and then pushing the changes out across the domain. In short: you have a special group of users that’s centrally controlled with just the privileges to do the local administrative work they need.

For my Acme domain, I delegated local Administrator powers to the Acme-IT group (below).

There are additional subtleties in working with Restricted Groups that we’ll get to next time. And we’ll also take up Organizational Units or OUs, which gives us the power to segment the domain and improve the security of our Restricted Groups.