Latest posts by Michael Pietroforte (see all)
- Results of the 4sysops member and author competition in 2018 - Tue, Jan 8 2019
- Why Microsoft is using Windows customers as guinea pigs - Reply to Tim Warner - Tue, Dec 18 2018
- PowerShell remoting with SSH public key authentication - Thu, May 3 2018
Just in case you think that this trick is based on a security hole and are wondering why Microsoft doesn’t prevent this age-old trick, there is a simple reason. It is impossible to prevent such manipulations if an attacker has physical access to a Windows computer. By the way, it is interesting to note that some third-party tools for changing passwords, such as the Trinity Rescue Kit, no longer work properly on Windows 8 and Windows 8.1 (you can still set blank passwords with these tools). Perhaps Microsoft sees such tools now as a problem rather than a solution.
However, the Utilman.exe trick and the Sticky-Keys trick still work. If you are afraid that script kiddies (perhaps your admin colleagues) will use these tricks to gain admin access to your servers and desktops, there are a few things you can do to increase security significantly and lock out these first-grade hackers.
I am aware of four countermeasures: restrict physical access, encrypt system drives, change the BIOS settings, and protect your SAM database with the SysKey utility.
Restrict physical access ^
Restricting physical access to servers is essential because all other methods can’t stop an experienced hacker. Servers often have locks that allow you to protect the machine, but the locks are usually rather simple. In my view, servers belong in lockable server racks, which have better locks. However, there is no unbreakable lock.
Your second security perimeter, therefore, is to ensure that only authorized personnel have access to server rooms. The problem is that cases exist where external people—cleaning personnel, the repair technician for the aircon, and so on—need access to a server room. Since you now know how easy it is to gain access to your servers with password reset tricks, you understand how important it is for trustworthy personnel from your company to always keep an eye on externals when they are in a room with servers.
Protecting desktops physically is a bit more difficult, although various solutions exist to do so. At the very least, computers at public places, such as training rooms, should be protected this way.
Encrypt the system drive with BitLocker ^
In my view, encrypting all system drives, desktops, and servers is a must for various reasons. Encryption with BitLocker is the most secure way to prevent password reset hacks because an attacker can’t just boot up a second operating system and manipulate an unprotected Windows installation.
Many admins still shy away from BitLocker because of the additional management work. However, BitLocker is a mature technology that can be easily deployed, and it rarely causes problems once it is properly configured. If you don’t have the resources to encrypt all your desktops, you should at least protect your servers. Just take into account that if an attacker uses the Utilman trick on a desktop, he can easily install a keylogger, and if an admin then logs on…
One problem with BitLocker is that not all Windows editions support it. Also, if the computer doesn’t have a TPM chip, handling BitLocker is cumbersome because either you always need to enter a password when the machine boots up or you have to insert a USB stick with the startup key.
You should also know that BitLocker hacks exist. The methods I have heard of require an attacker to have physical access to the machine twice. Between these two incidents, a regular user has to log on to the machine so that the attacker’s hacking tool can intercept the encryption key. However, hacks of this nature have become much more difficult because of UEFI, and, in any case, such attacks require profound technical knowledge. It is not very likely that one of these highly skilled hackers would be interested in your machines. However, it can’t be wrong to always have several security perimeters in place.
Change BIOS settings ^
Another option is to ensure that a potential attacker can’t boot up a machine from external media by changing the corresponding BIOS settings. Of course, you then also have to protect the BIOS with a password. If you want to do this remotely, you can use your vendor’s out-of-band management tools. Some manufacturers also allow you to automate the task with bulk management tools and scripts, and you might even be able to use PowerShell to modify BIOS settings. Below is a list of links that help you get started. If you want to change the BIOS settings on a large number of computers, I recommend contacting your vendor. Some PC manufacturers and server vendors offer a variety of systems management tools, and it can be difficult to find the best tool for the task.
- HP BIOS Configuration Utility (BCU)
- HP Integrated Lights-Out (iLO)
- HP Systems Insight Manager (HP SIM)
- HP Client Manager
- Automate BIOS configuration for HP clients
- Dell Systems Management
- Dell Client Configuration Toolkit - CCTK - NOTE: The latest version of CCTK is now Dell Command | Configure and is a part of the Dell Client Command Suite.
- Dell OMCI Sample Scripts
- IBM Advanced Settings Utility (ASU)
Note that various BIOS hacking tools exist that an attacker can use to change the BIOS settings even if it is protected with a password. And, if an attacker has access to the hardware, physical attacks are possible. But we are we are leaving the territory of first-grade hacking here, which is why protecting the BIOS is still a must. The vast majority of attacks from script kiddies. Nevertheless, you can add another security layer by using the SysKey utility.
Use the SysKey utility ^
The SysKey utility might be a bit outdated, but it can still be helpful in some environments because script kiddies might not know how to handle it. It allows you to move the SAM database encryption key to a USB stick. Whenever the server boots up, you will have to insert the USB stick. Another option is to store the encryption key on the computer and set a password to access it. With both methods, you have to be at the computer whenever you need to reboot it. Thus, if you want to reboot a server remotely, you need KVM access or you use an out-of-band management tool.
The SysKey tool is so old that it expects a diskette in drive A: to store the SAM database encryption key. However, you can easily assign the drive letter A: in Disk Management to your USB stick.
To start the SysKey utility, press SHIFT + R and then type syskey. You then have to decide if you want to store the encryption key on a USB stick or protect the key with a password.
When the machine boots up, you will either have to insert the USB stick or enter a password.
SysKey at startup
Note that even if you protect the SAM database this way, an attacker can still manipulate the database with various hacking tools by setting a blank password. However, since an additional password is needed to boot up the server, you have an extra layer of protection.
Of course, this method is not very practical for a large number of computers. However, it can be useful if you want to protect a single server with a Windows version that doesn’t support BitLocker and that you placed in an office where everyone has physical access. Just keep in mind that someone has to be at the computer if it needs to be rebooted.
The best and most secure way to prevent password reset hacks is to enable BitLocker on the system drive and disable the start from DVD in the BIOS. Without these security measures, you risk having anyone in your organization gain administrator rights without much effort.
Do you know of another way to prevent password reset hacks?