My wife is a school teacher (a stellar teacher, I might add). Like many families with teachers, we invest a sizable amount every year to improve the classroom experience. Part of our investment is to recycle our laptops into my wife’s classroom so her students have ready access to computers. This weekend, I stumbled across a shocking Windows security hole while troubleshooting a lost password for one of these classroom laptops. I didn’t want to spend the time to reinstall Windows, and I wanted a solution that would preserve the data, so this eliminated a fresh install anyway. I still have trouble believing what I found.
Windows Password Not Required
I’m not talking about the fact that (using normal Windows Administrator access) one can establish a Windows account which does not require a password. In the corporate world, this should be rare (hopefully non-existent). However, it turns out that by exploiting an egregious gap in Windows security, anyone with physical access to a Windows machine can–without any special software or media–gain Admin-level control of that machine in just a few minutes.
As I discovered, this is not breaking news to criminal hackers (or to older students). After just a few minutes of Google searches for “recover lost Windows 7 password,” I found this You Tube Video. I followed the steps shown in the video (detailed below so your IT staff can confirm), and I successfully used this Windows back door to change the laptop’s Windows password. There are, in fact, several variations of this exploit (for example, this and this–both of which are even easier if one has any bootable Windows media handy, and that media will work even if for a different version of Windows).
Key takeaway: If someone gets their hands on your Windows machine, they can easily bypass your password. If your data is not protected via robust volume-level encryption, your company could easily be in the “data breach” headlines.
Full-blown Data Breach Possible in 30 Minutes or Less
As mentioned above, this exploit requires physical access to the Windows machine, so the real exposure is most likely for lost laptops without robust data encryption in place. Still, I find it chilling that anyone can give themselves Administrator level control (applicable to XP through Windows 8, according to the first video) in minutes by following these steps:
1. Interrupt power during the start-up sequence. I was skeptical about this, but sure enough, when I pressed the power button right when I saw “Starting Windows” but before the Windows logo fully formed above those words, the startup process (after turning the power back on) was redirected to this “Windows Error Recovery” screen. Selecting the highlighted “Launch startup repair …” option took me to the Startup Repair screen after about 20 minutes of Windows scanning the system for problems.
2. Startup Repair: Portal to the Windows back door. This screen helpfully asks us if we want to send diagnostic information to Microsoft (who surely has hundreds of highly-paid Windows engineers just waiting to troubleshoot our every issue).
It also offers to show us “problem details.”
Clicking that yields this next helpful view, which generously offers us two additional 
ways of getting more information.
Ironically, the links at the bottom of this multi-line text box are to Microsoft’s “privacy” information–one on their web site, and one on the local machine.
It’s this second link–to the local machine–that is the gaping security hole our friends in Redmond have left for every hacker to exploit our data and violate our privacy right here on our own private PC.
Clicking that bottom link (to a text file) results in opening that file in Notepad, which seems innocent enough–until one 
realizes that this opens the machine up to complete file system access.
See that “File” menu at the top of the Notepad window? Clicking on that opens up Windows (file) Explorer as a system admin, and we are now just seconds away from everything on our PC being open to this hacker–including sensitive data stored unencrypted locally. As mentioned above, many data encryption solutions like EFS–if applied correctly–can thwart the effectiveness of this exploit. (See this video for another take on this exploit and an overview of EFS.)
Step 1: File –> Open
3. Navigate to Windows system files. It takes just six simple steps, as illustrated in these next pictures, to get us from Notepad into the guts of the operating system via Windows Explorer (with the equivalent of Administrator access), which our new worst friend will use to hack the Windows startup process and open the system up to anyone who knows to press a series of keystrokes on the login screen.
Step 2: Computer
These first three steps get us to the system drive.
Step 3: System disk (C: in my case)
Step 5 & 6: Select System32 folder, then select “All Files” to display system files.
Step 4: Select the Windows folder
We are now using Windows (file) Explorer to navigate to the folder containing our Windows system files (the “System32” folder under “Windows”, as shown in these two screenshots).
The System32 folder contains the Windows command that is used for this implementing the hack, which replaces the “StickyKeys” accessibility functionality of the Windows login screen with the Windows Command prompt.
- Other variations of this hack replace other programs available via the accessibility button on the Login screen with the Windows Command prompt, but this method is applicable to the widest range of Windows versions.
4. Hack the Accessibility feature on the Login page. In this step we rename a copy of the Windows Command prompt (cmd.exe) to sethc.exe (the StickyKeys app).
Next: Rename cmd.exe to sethc.exe.
First: Rename the real sethc.exe to some other name (sethc-1 in this example)
This results in the Windows Command prompt being launched instead of StickyKeys when someone presses the Shift key 5 times in a row on the login screen.
When that Command prompt is launched, it is as the uber-admin “system” user, which has the ability to set or change anyone’s password–among other very scary capabilities we’ll get to below.
5. Clean up and/or restart Windows for unfettered access. Because we got to Windows Explorer via the Startup Repair exploit describe in steps 1 and 2 above, we have a few screens to “clean up” as shown here, here and here.
A real hacker, of course, would dispense with all that and just restart the machine, so let’s just do that.
Windows Command on hacked Login screen
Restarting Windows produces the normal Login screen, but now our hacker can now press the Shift key 5 times, and the Windows Command console window pops up.
As mentioned above, this comes with Administrator level access, allowing our hacker full access to just about anything on the system.
This point is worth of exploring a bit. Although the steps executed so far have been with the goal of changing a Windows password, access to the system via the Windows Command console allows the hacker to do lots of damage without touching user passwords.
- For example, it is conceivable that–regardless of data encryption in place on this machine–this “Admin” level user could erase encrypted data using this Command prompt. Your may think your IT staff has you covered on this with corporate backup and recovery procedures, but it is my experience that the vast majority of IT operations never (ever) validate end-user backup or recovery processes–IF they are in place at all. You owe it to yourself to challenge my assertion about this by checking this out for yourself.
6. Change the password for the desired user. This last step is a no-brainer. Windows has a command to do this with four words: “net user <username> <newpassword>”.
This example shows a multi-step method of first getting a list of users (“net user”) then changing the password of the desired user (Debbie, in this case) using the trailing “*” to prompt for the new password when making that change.
Our hacker can now restart Windows and log in as Debbie.
Elapsed time: 30 minutes or less.
Points to Ponder
I have now spent all the time this lost-password “workaround” saved me (and then some–by a wide margin) to write this post, but if it increases awareness in the health IT community about this gaping security hole and resulting risk to patient data privacy, it will have been well worth it. I am a veteran IT consultant, but not a security guru–which leads me to:
Here’s what really scares me: If I can stumble across this security vulnerability (which I predict is more widespread than we want to admit), what other vulnerabilities are going unchecked that we not even aware of?
I am hopeful that many organizations have themselves well-protected against this vulnerability; there are several ways to do this–starting (but not ending) with robust data encryption on all laptops. I predict, in fact, that your IT team will scoff at this article and wave you away with assurances that it couldn’t happen to you. I sincerely hope that is true, but I strongly advise that you:
Ask two questions: 1) Where is the data–the proof that this cannot happen to us? 2) What other security exploits–more subtle than this–are we also protected against, and where is that data?
Here’s to your long and happy career–made possible by avoiding a patient data breach.