Remotely Unlock a Windows Workstation

Overview

In this article, I'll show a method/hack that allows you to "unlock" a locked Windows 2003, XP, or 2000 computer (see Figure 1) without knowing the logged-on user's password and without logging that user off. Along the way, we'll use some mildly-thrilling techniques such as DLL injection, remote Windows Service creation, and embedding and extracting other executable files in your EXE.

To be fair, this technique doesn't quite unlock the workstation the same way as hitting Ctrl-Alt-Delete and entering the user's credentials would (which is why I've put quotation marks around the word "unlock"), but it does permit you to access the logged-on user's desktop.

Figure 1: If you've never seen this window before, please enroll in a basic computer-security class at your local community college.

Some Background

Obviously, Windows does allow the computer to be unlocked by the user who locked it. We'll call this user the "interactively logged-on user". (Note: I'm referring to the user who has logged on via the physical keyboard and monitor...this technique isn't designed to unlock a Terminal Services session).

So, when the computer is locked and the interactive user hits Ctrl-Alt-Delete and enters his or her credentials, the desktop is restored and the user can continue working. Alternatively, a user who is a member of the local Administrators group can enter their credentials instead. In this case, the interactive user is logged off (which includes forcefully closing all running applications) and the administrator is returned to the standard logon prompt. What the administrator can't normally do is to unlock the computer and start using the interactive user's session. There may, however, be legitimate scenarios where an administrator needs to do just this. (I haven't actually thought of any, but either way, please keep reading.)

A Quick Disclaimer

The one thing preventing this tool from wreaking havoc on office LANs everywhere is that the user running the application must be in the local Administrators group on the target machine. This is consistent, of course, with the premise that once you have administrative rights on a machine, you can do pretty much anything you'd like. An administrator accessing a user's interactive session has never been explicitly forbidden; it's just never been exposed either programmatically or through the UI.

Some Basics

So, if we're not really unlocking the workstation then what exactly is happening?

To make a long story very short, in Windows there is something called a "desktop". Now don't think of a desktop as the place where your Recycle Bin and My Computer icons live. It's a more fundamental concept. Think of a "desktop" as a logical container for other Windows...a blank slate that holds all of the windows you see when you use your computer.

The following should help clarify the "desktop" concept:

There are at least two desktops that exist on your computer at all times: they are named Default and Winlogon. As you read this, you're looking at the Default desktop. If you'd like to see the Winlogon desktop, just hit Ctrl-Alt-Delete. The Winlogon desktop will become the active, visible desktop, and the Default desktop will be hidden. The Winlogon desktop is home to the "Windows Security" dialog box that appears when you hit Ctrl-Alt-Delete and the "Computer Locked" window that appears when you click the "Lock Computer" button (again, see Figure 1). Every other window you're likely to see lives on the Default desktop.

By the way, the Winlogon desktop is named for the process winlogon.exe, which is what you're interacting with when you walk up to a locked or un-logged-on computer. It listens for Ctrl-Alt-Delete, asks you for your credentials, authenticates you, and eventually starts up Explorer so that you can actually start using your computer. It then goes back to sleep, quietly waiting for you to hit Ctrl-Alt-Delete again, in which case it activates the Winlogon desktop as described above.

The one thing to take away from this is that when you lock a workstation, your application windows (including your desktop icons and task bar) are not individually hidden. Rather, the desktop that they live on is hidden and the Winlogon desktop becomes visible.

Think of a stack of two index cards: hitting Ctrl-Alt-Delete simply takes the Winlogon desktop from the bottom and places it on the top of the Default desktop.

Why this Technique is a Hack

Essentially, this application (which I call "RemoteUnlock") bypasses the actual "unlocking" code in the winlogon process and simply switches the visible desktop back to Default. An interesting side-effect of this is that Windows (specifically winlogon) still thinks the computer is locked. You can see this when you run RemoteUnlock because while the computer is "unlocked", hitting Ctrl-Alt-Delete does nothing. Why? Because, Ctrl-Alt-Delete is handled by the winlogon process and, as far as it's concerned, the system is still locked. Since a locked computer should already be showing the Winlogon desktop, the system (incorrectly) sees no need to activate the Winlogon desktop again.

For this reason, RemoteUnlock will "re-lock" the workstation upon termination. (More specifically, it will switch back to the Default desktop.) Otherwise, the system would be in some weird limbo-state where Ctrl-Alt-Delete doesn't work as expected.

Maybe someday I'll figure out a way to truly unlock the workstation, but for now, this should be sufficient.

How RemoteUnlock Works

First, here's the "how":

1. When you run RemoteUnlock.exe, we extract two files that are embedded inside of the executable image and copy them to the remote machine using the path \\remotemachine\\admin$ (which refers to the remote Windows directory, usually "C:\Windows"). The files copied are:
   • RemoteUnlockService.exe
   • RemoteUnlockDll.dll
2. Next, we connect to the Service Control Manager on the remote machine and create a Windows service called "RemoteUnlockService". The executable image for this service is RemoteUnlockService.exe (which we copied to the remote machine in Step 1).
3. We now start the service on the remote machine. When the service is started, it performs the following actions:
   1. First, it finds the instance of winlogon.exe that is running in the "console" session. (There may be multiple Winlogon processes on machines running either Terminal Services or Windows XP's Fast User Switching.)
   2. Next, it creates a thread inside of the Winlogon process. This thread is responsible for loading RemoteUnlockDll.dll into winlogon's address space.
   3. The DLL, now running inside of the Winlogon process, opens a handle to the Default desktop and calls SwitchDesktop(). At this point, the Default desktop for the interactive user is visible and can be used just as if the computer had never been locked.
   4. The DLL then goes to sleep (using WaitForSingleObject), waiting for RemoteUnlockService to be stopped (see below to find out how and when this happens). When the service does stop, the DLL will switch back to the Winlogon desktop and unload itself from Winlogon's address space. Everything is back to normal at this point.
4. Back on your computer (the one you're running RemoteUnlock.exe from), you'll see a prompt that reads "Workstation should be unlocked. Hit Enter to re-lock and quit."
5. When you hit Enter, another call is made to the Service Control Manager on the remote machine, this time to stop RemoteUnlockService. As the service is stopping, it calls SetEvent to signal RemoteUnlockDll.dll to re-lock the workstation and unload itself from Winlogon's address space (as described above).
6. RemoteUnlockService.exe and RemoteUnlockDll.dll are deleted from the remote machine.
7. Finally, a call to the Service Control Manager deletes RemoteUnlockService.

Now, here's the "why":

Why do we have to create a service on the remote machine?

In Windows, creating a remote service is an easy way to start a process on a remote machine. Basically, the only way to execute code on a remote machine is to get something already running there to execute it for you. As long as you have the appropriate permissions, the Service Control Manager on the remote machine is happy to launch an executable for you. It's also programmatically accessible from across the network, which makes it a perfect fit in this scenario.

OK, so why inject a DLL into the Winlogon process if we already have RemoteUnlockService.exe running on the remote machine?

Now here's where I can't speak definitively, but after messing around with a few other techniques, this is the only one I could get to work. I first tried just switching desktops from RemoteUnlockService itself, but this had no effect (even though it was running as NT AUTHORITY\SYSTEM and had the "Allow service to interact with desktop" box checked). My theory is that there is some mechanism in place that, on a locked workstation, will only allow a SwitchDesktop() call to succeed when made from the Winlogon process (when switching from the Winlogon to the Default desktop, that is). Or, quite possibly, I may have completely missed the boat when it comes to the proper way to switch desktops. Either way, this seems to work just fine. Plus, DLL injection is exciting.

Usage

Simple: from a command prompt, (or, if you're on the bleeding-edge, from Windows PowerShell) just run:

RemoteUnlock.exe computername

If everything goes according to plan, you'll see a message telling you the remote machine has been unlocked. At this point, go wreak whatever havoc you intend to. Just remember to come back to your computer and hit Enter to re-lock the remote machine.

Notes

• I haven't tested this on Vista. (The one guy at work running Vista is also smart enough to put his machine behind an iptables firewall. Oh well.)
• Also, I have no idea what will happen if you:
  • Try to "unlock" a workstation that doesn't have a logged on user.
  • Manage to kill RemoteUnlock.exe without hitting Enter and "re-locking" the remote machine.
  • Fail to secure employment after being let go from your current position because you used this program for less-than-ethical purposes. (Although, in that case, please post your résumé where I can see it...we're always hiring.)

References

• Programming Windows Security by Keith Brown. This is an invaluable reference for learning about logon sessions, window stations and desktops.
• Programming Applications for Microsoft Windows, Fourth Edition by Jeffrey Richter. This is the definitive source for DLL-injection techniques.