Because we are so aware of the sophistication of some of the ‘Data-raids’ and identity-thefts by cyber-criminals and malign hackers over the internet, we can sometimes forget that anyone who is able to gain physical access to a Windows machine can then access just about anything on the machine that the administrator can get to, unless it is encrypted. Even the term ‘Physical access’ is getting to be rather a blurred concept, since something like physical access can be gained from thousands of miles away with such wonders as KVMoIP (most servers have DRAC or ILO or something similar) and even the advent of the more advanced Intel vPro/AMT chipsets give standard desktop and laptop PCs lights-out management.

There is a difference between knowing how insecure a password system is, and experiencing it. I was recently given a family member’s laptop to scrape clean of a rather nasty malware infection. After making a complete image of the hard drive for safekeeping, I booted into Windows and then stared at the login screen when I realized that I didn’t know their password. Could I call them? Were they busy? I hate asking for people’s passwords anyway.

My first thought was to look for one of my boot disks which have a few tools which allege to be able to overwrite / reset the NTLM hashes. In my experience, results with those are a bit ‘hit and miss’. I could possibly brute force the hashes with Cain and Abel. I doubt this person’s password would make Bruce Schneier very proud: Meh… that just seemed too complicated. Then, in the darker recesses of my memory came the remembrance of an old stand-by method for getting into a password protected Windows machine. I tried it and it worked beautifully. It was also ridiculously simple. I’d like to share it with you since it has been public, published, knowledge for a long time, but before I do let me make note of a few important points.

First, you need physical access to the PC. This is not some super-secret “haxor” method to recover passwords across a network. You need to be able to touch the PC and also have some kind of boot disc that allows you to have access to the PC’s file system. For the record, it’s game over for any PC that you have physical access to, so don’t feel too proud about successfully pulling this method off.

Second, this will not recover a password. This resets the password. You will not be able to find what the unknown password is; you will only be able to overwrite the existing password with the password of your choice. This is very important because resetting the password will render all EFS encrypted files and folders unrecoverable unless you reset the password back to what is was prior. You have been warned.

Third, this method is specifically to reset a local Windows account and not a domain account.

Fourth, this is not new, I did not discover this, this is not original research and you can find plenty of other tutorials on the internet about exactly this method. I decided to add my own contribution to the subject for two reasons. First to help other technologists out by adding more quality content to Google (these instructions can be found on some rather dicey websites). Second, to directly impact many of my colleagues who expressed that they had never heard of any such “accessibility tools exploit”. This method is already well-known to all the villains.

Lastly, please use this information for good and not evil. Of course, if you perform a corporate or governmental caper with this knowledge, I am unlikely be obliged to respond to any court summonses that your defense team sends to me.

The Overview

Have you ever looked in the lower right corner of the Windows login screen and seen a little button that looks like this:

Pressing that icon allows you to launch various accessibility tools. The vulnerability that exists centers on Windows’ behavior of launching the accessibility tools as the SYSTEM user. For example, if you launch the On Screen Keyboard, osk.exe is launched as the SYSTEM user and thus has total administrative authority. The magnifier is the same way:

Further compounding the problem over how Windows launches administrative tools is that it is purely based on the filename and not some form of the file’s hash value. The login screen merely searches the System32 folder for a file called “magnify.exe” (or whatever other accessibility tool you choose) and launches it. The trick is to replace magnify.exe with a more useful tool for our password resetting purposes. A tool like… oh… cmd.exe.

Let’s begin.

The “Hack”

Step 1:

Acquire offline access to the filesystem of the PC that needs a password reset. This can mean booting from a live CD of some kind or physically extracting the hard drive of the PC in question and slaving it to another PC. You can use virtually any Windows installation disc to perform this operation on virtually any other version of Windows. You could also use a simple Linux live CD or an old-school bootable floppy.

Assuming that you now have offline access to the filesystem, we can progress forward.

Step 2:

Navigate to the %systemdrive%\WINDOWS\System32 folder and rename one of the accessibility tools to get it out of the way. I typically rename magnify.exe to something like magnify.exe.bak.

Next, make a copy of cmd.exe and name it magnifiy.exe. The command sequence would be something like this if you’re using a Windows command prompt:

Step 3:

Boot the PC up and wait for the login screen to appear.

Step 4:

At the login screen, click the accessibility icon and choose the accessibility tool that you renamed and replaced with cmd.exe. In my case, it’s the magnifier.

A command prompt will pop up running as the SYSTEM user so you pretty much own the OS from stem to stern at this point.

Step 5:

Now you can change the password with NET USER [username] *

Step 6:

Log in with the newly chosen password!

That’s all there is to it. If done swiftly with the right boot medium (a minimalist Linux shell, for example), it shouldn’t take more than three minutes to change any password on a Windows PC. But remember, as Uncle Stan Lee said “With great power, there must also come – great responsibility!” Use your knowledge for good.

The Evil Within

I did this for the best of reasons, and pretty well all IT people will be in the same boat. However, if someone who doesn’t have your best interests at heart uses the same technique, what then?

Sure, you can now reset the password for an administrator account. Of course, the better option for nefarious purposes would be to create a new account so as not to arouse suspicion when someone inevitably notices that a known local account has had a password change. However, what if someone is bent on doing long term damage? What could be done from here to gain a deep foothold in that server and by consequence the network that it is on?

The most obvious option would be for someone to install a rootkit on the server. Antivirus currently installed? Oh please. Remember, there is no account more powerful than SYSTEM, so any files that a rootkit would need to touch will bow in obeisance to the wishes of your command prompt. (This is also ignoring the fact that if you have physical access, you could conceivably boot up from media intended to infect the offline file system, making the need to use a SYSTEM command prompt extraneous).

Any rootkit worth its weight in stolen credit card numbers will sufficiently cover its tracks and obscure the true malignant processes running underneath everything. From there, any amount of destruction can be wrought.

A complication of Installing a rootkit is that you would have to  acquire a rootkit, and that acquisition might not be so easy for certain classes of would-be attackers. For those attackers that don’t have deep roots in the malware underground, plenty of other tools abound! For example, just about every Windows admin knows about the Sysinternals Suite, written by Mark Russinovich. One of the tools that could be used would be PsExec. This handy scrap of code allows for the execution of a program on a remote PC. Knowing the credentials of an administrative user account on the attacked server, the remote attacker could easily launch a basic Windows command prompt running on the remote machine. As an aside, setting up an SSH server on a Windows machine is easy to do as well.

Another option would be redirect all network traffic to a remote PC. Certainly there’s quite a stream of valuable 1s and 0s traversing your network cards, be they LAN networks or SANs. Imagine a constanly flowing mirror of your data being collected and reassembled in real time on a remote machine. Or don’t imagine it; you might not sleep tonight.

Perhaps an attacker doesn’t have any outside tools to install. Not to worry, for Windows has quite a number of inbuilt opportunities for mischief. An attacker could simply enable WinRM and have PowerShell at his remote beck and call. If it’s an older operating system that doesn’t support WinRM, that’s almost better! An attacker could install a Windows component using the add/remove programs control panel that has a known vulnerability. From there, he could quietly slip away and remotely use an exploit database (Metasploit, for example) to deliver a poisoned payload and insert any arbitrary code that he wishes. Installing a Windows server 2000 or 2003 version of the FTP service could result in a full VNC server being installed due to a buffer overflow attack allowing for arbitrary code execution.

This is all assuming that the attacker wants continued access to the server. Perhaps they just want some simple data. How about some juicy SQL Server databases? Certainly an attacker who had physical access could merely keep the server booted into a live CD long enough to copy the databases of. But perhaps the databases are rather large, like many are, and the server being down that long would arouse enough suspicion to cause a server-room inspection. By executing this accessibility tools exploit, the server should only be down for a few minutes.

Now with either a command prompt or some form of remote tool installed, it’s trivial to start a virtually unnoticed copy procedure. With admin rights, one might be able to gain privileges to the SQL Server depending on the authentication method in place. Then a backup or replication procedure could be started so that data is copied while the server can still process transactions. If you can’t get to SQL Server’s own backup commands, then you could check for any third party backup tools and attempt to swashbuckle that system into handing you a copy of the data. Lastly, if you can’t get a backup or replication going, then you’ll have to take your chances with bringing the service down and copying the MDF and LDF files right out of the SQL Server directory.

Encryption of sensitive files is an essential defense that would mitigate some possible attack vectors. You can even encrypt all of your live database files with a product like, oh… say SQL Storage Compress. But I digress…

What else can one say? Evil is as evil does, and evil loves some physical access to your servers. In the end, protect your servers physically, and that includes KVMoIP access, as if you were guarding crates of nitro glycerin balanced on a Jenga tower made of golf balls (don’t ask me how that works).

A video by Wesley describing this technique is available here: Screencast: How to Reset a Windows Password Through a Backdoor