Gaining Administrative Access to a Powered-Down Windows 10 PC

The Windows SAM File – A History

Note: If you already know what the Windows SAM database is and want to get straight to the good stuff, skip this section (a history lesson) and go on to the next.

The Windows SAM file is a database file that’s located in the directory C:\Windows\System32\config. It’s an encrypted database file that contains all of the usernames and password hashes for the local machine. It does not contain any cached domain credentials or hashes, or in Windows 8 and 10, credentials or hashes for users who log in with an online Microsoft ID. There are two possible ways that passwords can be stored in this file – either as a LM hash, an NTLM hash, or both.

LM (LAN Manager) hashes date back to the pre-Windows NT days, back when IBM and Microsoft were buddies and OS/2 was a thing. This form of hash is inherently broken, because of the way it’s calculated. Passwords that are stored as LM hashes are limited to 14 characters. Anything past 14 characters as set by the user is ignored. The 14 character password is then split in to two 7-character passwords, and converted to all uppercase.

This means that MyPaSSW0rd! and mYPassw0RD! would both be converted to MYPASSW0RD!, split in to two parts of a hash – MYPASSW and 0RD! – and be stored as the same hash. Not only does this greatly reduce the number of possible passwords, it also makes cracking them much faster, since instead of cracking a 14 character password with mixed case, alphanumerics, and special characters, you are instead cracking two 7-character passwords with only upper, numbers, and specials. With my GeForce 1070, I can brute force all possible combinations in about 10 minutes.

Since it was obvious that as the speed of hardware increased, LM became less and less susceptible to brute force attacks, it was replaced with NTLM. NTLM (NT LAN Manager) is what’s still used today in Windows 7, 8 and 10. NTLM is better than LM, since it respects case, doesn’t split passwords in to smaller chunks, and if you have a long and complex password, even modern hardware generally takes a long time to brute force the hashes. With that same GeForce 1070, a 6 character NTLM hash with all possibilities takes about 1 minute and 15 seconds to brute force. 7 characters extends that time to 2 hours and 9 minutes. 8 characters – 10 days. 9 characters – over 2 years. When I try to go out to 10 characters, hashcat64 errors out with “Integer overflow detected in key space of mask.”

As a result of this, 10+ character secure passwords hashes in NTLM (upper/lower, numbers, specials, and no dictionary words) are generally considered to be “safe” even now, which is probably why Microsoft is still using them.

Within the past couple of years, Windows 10 has been getting updates that change how the SAM file is encrypted, which has broken a lot of audit tools and has forced them to require an update. The pwdump and ophcrack suites that come on the latest version of Kali 2018.2, for example, won’t provide the correct hashes when the SYSTEM and SAM files are processed by those tools. Other tools have been updated (pwdump7 for example) or created (mimikatz) to solve the problem. Luckily for us in this attack, the tool that I’ll be showing you how to use, chntpw, still works just fine with the latest version of Windows 10 with all updates as of the time of this writing.

Outlining the Attack

For this attack, you’ll have to have a couple of things. First, you’ll need a copy of the latest version of Kali Linux on a bootable USB drive. This shouldn’t be too hard to accomplish, and I’ve already done a tutorial for setting one of those up here if you’re using macOS. If you’re using Linux, obviously the same dd command applies. For Windows users, you can follow the official guide.

Second, you’ll need physical access to the PC that you’ll be attacking. If it’s not powered off, it should be. Essentially we’ll be booting in to Kali using the USB drive that we created above, and manipulating the SAM file to give ourselves access. On Windows 10, the perfect scenario is already teed up for you. By default on Windows 10, the Administrator account is disabled with no password. In this tutorial, that’s the account we’ll be enabling and using to grant ourself access. Of course if the Administrator account is enabled and has a password assigned, this attack will still work just fine. It should be noted, however, that a clean shutdown of the Windows system is required. If the Windows machine is shut down forcefully during boot, Linux will likely only be able to mount the volume as read only. If this happens, you can restart the machine without booting to the USB drive, boot Windows to the login prompt, and then shut Windows down gracefully from there.

One thing to note here, if the machine you’re trying to compromise has whole-disk encryption enabled, this won’t work. On the non-Pro versions of Windows, BitLocker isn’t included as an option from Microsoft, so those machines will likely not be encrypted. It’s possible that a user could be using a third party encryption software, but that’d be the exception. With corporate machines, Windows 7/8/10 Pro will likely be installed, since that version is required to join an Active Directory domain, so per corporate policy, BitLocker may be enabled.

Performing the Attack

First thing’s first, we need to boot to our USB drive. How you’ll do this varies from machine to machine. I attempted this attack against my Lenovo T450S, which required me hold the Enter key upon turning the machine on to interrupt startup, and on a Lenovo YOGA 13, which required me to push a little hardware button with a small item like a paper clip or pushpin. Every machine is different, so you’ll have to do some research.

Once you’ve got the Kali boot menu up, select the top option to boot to “Live system.”

Once Kali boots, you’ll want to launch File Manager and click on the “Other Locations” option on the bottom left.

You should be able to see the local hard disk where Windows is installed. Here, mine’s labeled “511GB Volume,” but this could say anything. Double-click on that volume to mount it. You’ll then want to navigate to Windows\System32\config, as that’s where the SAM database is stored.

Once in this directory, right click in some white space (not on a file), and select “Open Terminal Here” from the drop down menu. That should drop you in to a terminal and you should already be placed in the Windows\System32\config directory.

From here, we can run a command that will read the SAM file and provide us with some information about the accounts on the machine. chntpw -l SAM 

Here, you can see that my machine has five accounts. All but one are disabled. My account (jason) and the local Administrator account are both in the Local Administrators groups. Now, we’ll edit the Administrator account. Our goal is to ensure that the password is blanked out, and enable the account. We don’t have to move it the Local Administrators group because according to the “Admin?” column, it’s already in that group. To edit the account, run chntpw -u Administrator SAM

Remember that we’re working in Linux and everything is case sensitive, including the Windows usernames, when using these commands. This screen gives us much more details about the account. We can see that the account is disabled, the password is set to never expire, and that someone has tried to log in to it 0 times with 0 failed logins. The tool recognizes that the hash for the account isn’t present, so the password hasn’t been set (it’s blank).

Just to ensure it’s blank, we’ll type 1 and press Enter. This will forcefully clear out the password even if there was one. We want to unlock the account as well, so we’ll type 2 and press Enter. If this user wasn’t in the Local Administrators group we could type 3 and press Enter and that would add them. If they’re already in a group, the tool’s documentation warns not to add them to the group again, as this could break things, so we won’t do it.

When we’re done editing, we’ll type q and press Enter to quit. The tool will then ask us if we want to save our changes by writing the hive files. We’ll type Y and press Enter, and we’re done.

At this point you can shut down the machine from the menu within Kali and remove the USB drive. The Administrator account is now enabled and the password is blank. Just to verify, I’ll reboot my machine and log in with my jason account, and use MMC to check that our changes were actually made.

As you can see, the “Account is Disabled” box is no longer checked, and (as you can’t see) the password is blank. I was able to log in to the Administrator account via the console on the machine itself.

Considerations / Covering Your Tracks

By default on Windows 10 machines, any and all remote access is disabled to the machine if the Administrator account has a blank password. This is a security measure that you must override by logging in to the machine via the console with the Administrator account at least once and manually changing the password after logging in. Optionally, you could use a third party utility to change the password in a similar way that we used chntpw to clear the password. I have not tested this myself, but it seems like it would be a better way of going about things since if you did log in as the administrator at the Windows login screen, the machine’s user would know since they’d have to manually change back to their own user the next time they tried to log in. I have not tested this yet. If anyone does, please respond with your method of attempt, tools you used, and if it was successful or not in the comments below.

Once the Administrator account has a password, you should be able to do remote administrative tasks like remotely edit the registry from another machine, connect to administrative shares to remotely access files, utilize the psexec suite of tools from Microsoft to remotely control the machine, etc.

Next, and very important, don’t leave the administrator password blank. As nice as it is having access to the machine, but we don’t want it to be compromised by someone else. Setting a strong password will take care of that.

Going above and beyond, we’ll need to hide the account from the login screen. One thing that you can’t see from the screen shots above is that after being enabled, the Administrator account appears as a selectable entity on the Windows 10 login screen. If the machine only has one other user account on it, this will instantly look foreign to whoever regularly uses the machine when they go to log in. We’ll want to keep the Administrator account from appearing an an option there, which we can do by remotely editing the registry.

After launching “regedit.exe” on your machine, you can click on File > Connect Network Registry… and input the hostname of the compromised machine. After logging in with our Administrative credentials, we should then be able to edit the registry of that machine remotely. Using regedit, browse to the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Right click on the Winlogon container and chose New > Key. Name the new key SpecialAccounts. Right click the SpecialAccounts container and choose New > Key. Name the new key UserList. Right click the UserList container and choose New > DWORD 32-bit Value. Name the DWORD Administrator. Double click the newly created DWORD and ensure that the value is set to 0 (zero). When the remote machine goes through a logout cycle (if someone is currently logged in) or if the machine goes through a reboot cycle (required if nobody is logged in), the Administrator account will no longer appear on the login screen.

How to Protect Yourself from This Attack

Protecting yourself from this attack is simple. First, ensure that your machines are stored in a secure location. If someone has physical access to any of your machines, that’s not good. Second, whole-drive encryption is a solid choice. Microsoft provides this in Windows “Pro” editions via it’s BitLocker feature. If you don’t have a “Pro” version of Windows, you could optionally upgrade your existing version to a Pro version, or seek whole-disk encryption through a third party software.

Final Thoughts

There are some legitimate uses for the above tutorial. Forgetting your own password and needing to reset it is the most likely cause. If you manage to somehow delete all of the accounts on your machine that have administrative access and need to elevate another existing account because the Administrator account is disabled, that’d be a  great legitimate use as well. A lot of power lies here though, in regards to gaining either local or remote access to a networked machine, and the attack can be pulled off in less than a minute if you’re quick about it. As always, use this information for good.