Adding a Domain User to Local Administrators Group without Administrative Credentials

The Goal

In this article I’ll show you how to add a regular Windows Active Directory domain user account to the local Administrators group on a PC without having access to either the domain Administrator credentials OR credentials to the Administrator account on the local PC. Why would anyone want to do this? Typically a company issues PCs to its users, but they may not want those users adding software to or removing software from that machine, so they’ll purposefully not add them to the local Administrators group on that machine. If you know anything about Windows groups, you know that if an account is added to the local Administrators group on a Windows PC, that user can do basically anything that the Administrator account can do on that machine.

As a power user, not having access to local administration privileges is annoying, since you may not be able to install software, install printers, may not be able to use any external device that requires drivers be installed, may not be able to view certain system management consoles, or many other things that require local administrative credentials.

Disclaimer: Performing this hack on a company-issued work PC could violate your company’s corporate technology policy and/or corporate security policy. Don’t get yourself in to trouble.

The Setup

Our setup here is simple. I’m performing this hack on a fully updated Windows 10 Professional machine with all of the latest updates at the time of this writing, joined to a Windows Server 2016 domain called company.local. The Windows Server 2016 server is running all of the latest updates and patches as well. Helping us out in this hack is a copy of Kali Linux – the latest version at the time of this writing – 2018.02. A domain user has been set up with the user account juser@company.local (Joe User). The user has only basic access to the physical Windows 10 machine that he has been assigned. He is able to log in to the machine and run software that has already been installed, but is not in the local Administrators group on the machine.

In this example, I’m going to assume that we have access to log in to our juser@company.local account, but don’t have access to either the domain Administrator account, or the local Administrator account.

This setup is very realistic to how corporations issue computers to their users. With best security practices, the local Administrator account (by default called “Administrator”) is disabled. In fact, since Windows Vista, when you perform a new install on bare metal you are asked during post-setup to provide a user name and password for the first account, and that first account is placed in the local Administrators group. There is an Administrator account that is also created, but it is created with a blank password and is disabled by default. This contrasts with the way Microsoft historically handled initial install on legacy NT-based Windows operating systems (NT 4, Windows 2000, etc.) where the initial password created during post-install was assigned to the Administrator account, that account was not disabled by default, and you would then use that account to join the PC to an Active Directory domain.

Most corporations that roll out a bunch of computers at once use a standardized image with a local Administrator account that is disabled, and if administration on those machines is required, domain administrators will use the domain Administrator account since it has administrative access to every machine on the domain. As a result, the local Administrator account is disabled and ignored. We will use this to our advantage to gain administrative access to the PC in question, and then using that access to add the domain user account juser@company.local to our local Administrators group, exploiting the fact that Microsoft for some reason allows local administrator accounts to add domain user accounts to local Administrator groups using only user-level network credentials.

Gaining Access to the Local Administrator Account

The first step is to gain access to the local Administrator account, which should be disabled. This is very similar to my article which explains the Windows SAM file and how to gain administrative access to a Windows machine that’s powered off. I should note up front that if the corporation is using whole-drive encryption, we won’t be able to perform this step, and thusly won’t be able to perform the hack.

In order to complete this step, you’ll need a bootable copy of Kali Linux on either a USB drive or a bootable DVD-ROM.

When logged in to the Windows PC as the juser@company.local account, we can check the Computer Management MMC (access this by right-clicking “My Computer” in an Explorer window and then choosing Manage). We’ll then navigate to Local Users and Groups and double click on the Administrators group. As you can see, our juser@company.local account is not in the local Administrators group.

We’ll want to reboot the PC and boot to the Kali USB stick / DVD-ROM. When you do this you’ll want to ensure that Windows shuts down cleanly. If it doesn’t, the Windows volume will mount as read only in Kali and we won’t be able to modify it. If Windows doesn’t shut down cleanly, boot it to the login screen and cleanly shut it down from the power icon on the lower right corner of the screen.

Once booted in to Kali, open File Manager and click “Other Locations” on the lower left corner. You should see your Windows volume in right pane of File Manager. Double click it and navigate to Windows\System32\config. Here, you’ll notice the SAM database, which we’ll be modifying.

Cover Your Tracks – Now’s a good time to make backup copy of the SAM file. If you ever want to restore the administrator password to what it was set by the company, as well as set the account to disabled, and to remove your domain user account from the local Administrators group, restoring this file from a backup is the fastest way. You may want to do this if you ever have to turn in your machine for work to be done, or return it for a new machine perhaps, and don’t want corporate administrators knowing that you modified the SAM file to gain administrative access. We will be blanking out whatever password may be assigned to the local Administrator account, so take this in to consideration.

Right click in some white-space in this directory to get a context menu and select “Open in Terminal.” You’ll be presented with a terminal and placed in the System32\config directory, which is where we want to be. We’ll then run the command chntpw -l SAM in order to list all of the local accounts and their status. (All of the commands in this tutorial are case sensitive.)

Here you can see that our Administrator account has administrative credentials and is disabled/locked. (There’s another admin account called Jason in my screenshot… ignore that). From here we’ll issue the commands to enable the account and blank out the password, so that we can log in locally with a blank password. You’ll notice that our juser@company.local account does not show up here. This is because even locally cached domain accounts are not located in the SAM file.

Issue the command chntpw -u Administrator. Here we can see that the account is disabled, and the password is set to never expire. From here we’ll want to press 1 and then Enter to blank out the password for the account, and then 2 and Enter to unlock the account. Press q and Enter to quit the program, and you’ll be asked to press y and Enter to save changes to the SAM file. At this point the Administrator account is enabled with a blank password. Reboot the PC to log in to Windows.

When prompted to log in to Windows, click “Other User” and log in with the account .\administrator with a blank password. The .\ tells Windows that we want to log in the local machine Administrator account and not administrator@company.local.

At this point we can launch Computer Management again, and navigate to Local Users and Groups > Groups. Double click the Administrators group to show its properties. In the object name box, type the name of the domain user account, in this case juser@company.local. Click the Check Names button and you’ll be prompted for a domain login.

Common sense would dictate that a domain admin would have to authorize this change, but that’s not the case here. Since you need to authenticate to the domain, you’ll need to provide a valid set of domain credentials. Fortunately for us, we have them. Log in using juser@company.local’s credentials. The operation succeeds and you’re returned to the Administrators group properties.

As you can see, juser@company.local is now in the local Administrators group. Click Ok to close this dialog, log out of Windows, and log back in as juser@company.com. You can now enjoy local administrative freedoms.

Note that at this time you’ll definitely want to set a password for the Administrator account, and you’ll likely want to disable it. In Windows 10, by default and unless you change some local Group Policy settings, an Administrator account that’s enabled with a blank password does not have access to remotely administer a machine. However, since this machine belongs to a corporation and isn’t yours, having a local Administrator account that’s enabled and/or is enabled with a blank password could result in red flags if the organization employs any kind of posturing software that monitors the desired state or “health” of a workstation. Keep that in mind.

How to Mitigate Against This Attack

If you’re an administrator reading this, you’re probably thinking “well crap.” Worry not though. To edit the SAM file, we need access to the Windows volume from Linux in a dual-boot scenario. If the system volume is encrypted, it breaks the above instructions. Luckily, Microsoft includes BitLocker with Windows 10 Pro, and that can be enabled via Group Policy on any domain PC that contains a TPM.

Conclusion

Not that not once in this attack were we required to know existing administrative credentials for either the local machine or the domain. This attack works because using only domain user credentials when logged in as a local administrator, we’re allowed to control administrative access to those domain user accounts on the local machine, thus escalating our local privileges. By disabling the local Administrator account after we’re through, we reduce the risks of the results of the escalation being apparent to any sort of system or network posturing. By saving a copy of the local SAM file, we can easily revert the Administrator account to exactly how it was before the attack was performed, including effectively changing the password back to whatever it was set to before we erased it. If we ever have to turn this PC back in, restoring the SAM file should clear our tracks.

Keep in mind that this isn’t totally foolproof. If systems or networking posturing software routinely checks the contents of the local Administrators group on each machine, a red flag will be thrown. If an administrator sees that your user account has additional software installed on a machine that you shouldn’t have access to install software to, they’re going to get suspicious. If the local Administrator account is used for any automated purposes like running scheduled tasks or scripts (which in itself is a security risk and is dangerous, and is obviously not likely if the account is disabled), execution of those things could fail.

Still, this just proves that if you have local access to a machine, even if that machine is part of a Windows domain, the machine itself is still not secure. It may also make your life easier by giving you full access to your machine if it’s been locked down by an organization. Just remember, I’m not responsible for choices you make. I hope you enjoyed this and found it helpful.