Do You Have an Account Named “Administrator”?

Morey Haber, Chief Technology Officer
April 3rd, 2018

One of the most coveted targets for a threat actor is to gain ownership and access to a Windows Administrator account. While local accounts are valuable, domain administrator accounts are even more valuable since they essentially give access to every Windows asset in the environment. If the threat actor can easily identify the account by the username “Administrator”, you have actually made it easy for them to target the credentials for some form of a privilege escalation attack.

Outside of them identifying the SID (Security Identifier) for administrator accounts, identifying which accounts are administrators is normally trivial if they are named Administrator (by default) or renamed something like “x-admin” (or similar). An enumeration of user accounts by name, therefore, becomes a dead giveaway.

The United States Department of Defense (DoD) Security Technical Implementation Guide (STIG) recommends that all default administrator accounts be renamed using the following procedure to obfuscate the name even on workstations:

  • Run “gpedit.msc” – Local Group Policy Editor
  • Navigate to Local Computer Policy >> Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options
  • If the value for “Accounts: Rename administrator account” is set to “Administrator”, then the default value has not been changed

While this can be set using Group Policy, it will change the name to the same value on all systems governed by that policy. If you know the value of one system, then you know it on all systems, and odds are the password is the same for all of them, too. This is another security risk that could result in lateral movement.

So, what is an organization to do to mitigate these threats? Minimize risk, and keep this account secretive?

First, consider renaming the local administrator account to something different on every workstation. In order to avoid the guessability of “x-admin” consider something like “x-{Serial Number}” or “x-{Service Tag}”. This means physical knowledge from the asset is needed to guess the local administrator username or the data must be obtained from an asset management database.

Next, keep the passwords unique per asset. This can be done with Microsoft LAPS or with a privileged access management solution like PowerBroker Password Safe. If the devices are mobile, PowerBroker for Windows can be linked to PowerBroker Password Safe to also make these passwords unique across the Internet or VPN. And, it can rotate these passwords on a frequent basis to keep them secure from insider threats. This solves multiple problems:

  • Secures the administrator account according to some of strictest hardening guidelines like the DoD STIGs
  • Mitigates the threat of password re-use for local accounts by keeping them all unique
  • Obfuscates the administrator username to something cryptic and makes it difficult to guess without enumerating the asset directly
  • Minimizes the risk of lateral movement by not having the same local administrator accounts on multiple systems
  • Secures remote access for team members (like help desk) that may need to assist an end user without additional exposure

If you consider that modern threats target privileges, knowing the local administrator account is named “administrator” makes it one step easier for a threat actor to guess or obtain a password. If the administrator account’s username is obscure it is that much more difficult to compromise and conduct lateral movement. I recommend following the STIGs recommendations and using a privileged access management solution to manage the accounts passwords. This will prevent many modern threats and help contribute to good cybersecurity hygiene.

If you would like to learn more about how to administer Windows without domain admin privileges, download this free white paper by cybersecurity expert, Russell Smith:  An 8-Step Guide to Administering Windows without Domain Admin Privileges.

Morey Haber, Chief Technology Officer

With more than 20 years of IT industry experience and author of Privileged Attack Vectors, Mr. Haber joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition. He currently oversees BeyondTrust technology for both vulnerability and privileged access management solutions. In 2004, Mr. Haber joined eEye as the Director of Security Engineering and was responsible for strategic business discussions and vulnerability management architectures in Fortune 500 clients. Prior to eEye, he was a Development Manager for Computer Associates, Inc. (CA), responsible for new product beta cycles and named customer accounts. Mr. Haber began his career as a Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelors of Science in Electrical Engineering from the State University of New York at Stony Brook.