Editor’s note (2021-01): This particular hacking method no longer works after 2019-11 windows update. I had this article on ice for a very long time and feel confident that it won’t be abused at this time.
Preface
I feel like I shouldn’t have to say this, but please use your powers for good and not evil. The methods I’ll reveal here have quite impressive post-exploit abilities for lateral movement. If you’re thinking about getting arrested for something dumb, please don’t bring up my website at your trial. I don’t like lawyers very much (no offense lawyers).
This is an interesting technique where a priviledged user on a Windows system can take control of other user’s sessions. To be clear, this is not a vulnerability or exploit for the following reasons:
- Requires elevated priviledges
- Requires physical access to the system, or a sophisticated remote access toolkit
Either way, it’s a fun way to learn more about the inner workings of Windows, and how to use and abuse it’s quirks and features.
The Windows Display Manager
Before we get too far ahead of ourselves, let’s start with what the Windows DM is and briefly how it works. This is a quick rundown at best; if you’re looking for full blown documentation you’ll want to get a job at Microsoft. Or read Mark Russonivich’s book, that might be the closest you’ll get…
There are three primary components of the Windows Display Manager that you should know about. For more information about these, go visit the the Windows Performance Team on Technet.
- Desktops
- Contains userspace processes, applications, runtimes, and background tasks
- Generally one desktop per user, though that can be changed in more recent versions.
- Sessions
- Sessions >0 act as containers for userspace desktops
- Session 0 contains interactive services, usermode drivers, and other vestigial leftovers from the pre-vista age. In most recent versions of Windows it is locked away, difficult to tamper with, and isolated in many ways from sensitive processes.
- Window Stations
- Represent connections to a session. Most commonly this is the physical keyboard, mouse, and monitor attached to a PC, however it can also represent RDP connections.
Inspecting Sessions
The first part of the puzzle is figuring out which session contains useful information. There are generally two things to look for, processes and user accounts. From here on out, Admin access is needed to do anything useful.
Users
Getting a list of logged in users is quite simple, and probably familiar to most admins:
net session
Put a screenshot here?
Then, compare that to the list of window stations active:
qwinsta
Another one here?
Processes
Getting a process list is also quite straightforward. It requires an administrative powershell session:
Get-Process *[filter-keyword]* -IncludeUserName
Once a valuable session has been found, a priviledged user can then take control of the Display Manager to seize that session.
Switching Sessions
Because of the heavily ACL-integrated nature of the NT operating system, all objects including sessions and desktops have a set of securables. In most cases, the “owner” of a desktop is the user that created it with all other users having no access at all, other than being able to see that it exists (think about the login screen, that’s a desktop too!).
Fortunately, as with most securables, the NT AUTHORITY\SYSTEM account has full access to desktops and sessions. And this makes sense, since the operating system itself needs a way to manipulate the session manager to allow non-logged-in users to start their own sessions. However, it also means that those with more nefarious intent can seize control of sessions by elevating to SYSTEM level.
With both methods, it is required to already have a shell as Administrator; the difference is in the tools used.
Method 1: PSEXEC
This method requires the ability to download and run executables. In many cases this is not possible (for good reason), but most of the time it works just fine.
First, using the methods above locate the target session.
Then, execute tscon as system to link the target session ID to the console window station:
.\psexec.exe -s tscon /dest:CONSOLE <ID>
Within a second, the display will blank then connect to the target session. Easy!
Method 2: Scheduled Tasks
This method requires no additional binaries! Just register a scheduled task on the sytem that will trigger a tscon operation. For extra sneak factor, this task can be buried deep in the library with an inconspicuous name… Think “xbox-service-updater” or something along those lines.
schtasks.exe /create /tn sessionswap /ru "SYSTEM" /Z /tr "tscon" "/dest:CONSOLE <ID>"
schtasks.exe /run /tn sessionswap
Method 3: Service Manager
This method is my favourite, simply for the absurdity of it. There’s something delightful about creating a service that will immediately crash and land you in somebody else’s desktop. Of all these methonds, this is the least likely to work in the future, as Microsoft is actively working on securing the service control manager, and increasing the auditing ability of the system to detect tampering with services. So don’t try this if you don’t want to get caught… Hypothetically of course.
sc create sessionswap type= own type= interact start= demand binpath= C:\Windows\System32\tscon.exe /dest:CONSOLE <ID>
sc start sessionswap
Depending on the log level of the system, this service exiting will likely leave warn or error messages in the system event log.
Conclusion
With a bit of tinkering and poking, one can fairly easily traverse logged on sessions on a Windows PC or Server. If nothing else, this highlights the need to physically secure any endpoints, and secure the virtual console of any virtual machines. Though it may be possile to accomplish the same thing over RDP, I have not been able to do so (And of course please tell me if you can!).
And most importantly, always remember that admin=full control. It’s trivial to elevate to system, especially for a single task. If nothing else, this highlights the importance of the “Principal of Least Priviledge” approach to delegation.
Happy hacking!