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...
Michael Buckbee
3 min read
Last updated August 19, 2022

This article is part of the series "Working With Windows Local Administrator Accounts". Check out the rest:

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.

Get the Free Pentesting Active
Directory Environments E-Book

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.

Dmc user rights

Enabling “deny access to this computer from the network” in the User Rights Assignment GPO.

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.

Taco psecec

Taking advantage of silly Administrator passwords with psexec.

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.

Taco gpp

In my AWS environment, the GPP feature for updating passwords is disabled. You may not be so lucky.

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).

taco restricted

Restricted Groups! Control local Administrators across the domain in one swoop.

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.


What should I do now?

Below are three ways you can continue your journey to reduce data risk at your company:


Schedule a demo with us to see Varonis in action. We'll personalize the session to your org's data security needs and answer any questions.


See a sample of our Data Risk Assessment and learn the risks that could be lingering in your environment. Varonis' DRA is completely free and offers a clear path to automated remediation.


Follow us on LinkedIn, YouTube, and X (Twitter) for bite-sized insights on all things data security, including DSPM, threat detection, AI security, and more.

Try Varonis free.

Get a detailed data risk report based on your company’s data.
Deploys in minutes.

Keep reading

Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.

Working With Windows Local Administrator Accounts, Part III
One point to keep in mind in this series is that we’re trying to limit the powers that are inherent in Administrator accounts. In short: use the Force sparingly. In...
Group Policy Editor Guide: Access Options and How to Use
Group Policy Editor (gpedit) is an important part of the Active Directory system administrator’s toolkit. Read this blog for more details about gpedit.
Working With Windows Local Administrator Accounts, Part II
Before we delve into Restricted Groups, I thought it might be worthwhile to take a closer look at how hackers take advantage of Administrator passwords. For Pass-the-Hash fans, this post...
Einstein's Wormhole: Capturing Outlook & Google Calendars via Salesforce Guest User Bug
If your organization uses Salesforce Communities and Einstein Activity Capture, you might have unknowingly exposed your administrator's Outlook or Google calendar events to the internet due to a bug called...