Friday, March 17, 2017

Passwordless RDP Session Hijacking Feature All Windows versions

* This post periodically updated, all updates in the end of the post.

Update: Added Windows Server 2016 Datacenter Demo

Hey there,

Blogpost in 20 seconds: Fun with sethc backdoored host :) somewhere in the internet:

Recently i've played with sethc/utilman logon screen backdoors, and almost everytime i used just command line.
Occasionally i've looked at Users tab in Task Manager (taskmgr.exe), and clicked connect button, and surprisingly i've got connected to selected user's session.

When i checked it again with local admin rights, it failed by asking user's password.
Why and how that happened? Let's dig deeper.

Related to Microsoft documentation:

we can see couple important remarks:


  • You must have Full Control access permission or Connect special access permission to connect to another session.
  • The /dest:<SessionName> parameter allows you to connect the session of another user to a different session.
  • If you do not specify a password in the <Password> parameter, and the target session belongs to a user other than the current one, tscon fails (not really).
I've got it! Sticky Keys (cmd backdoor) at windows login screen runs with NT AUTHORITY/SYSTEM and have Full Control access permission, and can connect to EVERY user session without asking for a password.

So we've got a session hijacking here. The most funny thing is that the legit user isn't asked for logout, by using this technique the user just will be kicked out of the session without any notification.

Attack Vector Details:

A privileged user, which can gain command execution with NT AUTHORITY/SYSTEM rights can hijack any currently logged in user's session, without any knowledge about his credentials.
Terminal Services session can be either in connected or disconnected state.

This is high risk vulnerability which allows any local admin to hijack a session and get access to:
1. Domain admin session.
2. Any unsaved documents, that hijacked user works on.
3. Any other systems/applications in which hijacked user previously logged in (May include another Remote Desktop sessions, Network Share mappings, applications which require another credentials, E-mail etc.)

Example scenario: 

Some bank employee have access to billing system, and it's credentials to login.
One day, he come to work, logging in to the billing system and start to work. At lunch time he will lock his workstation, and out to lunch.
Then, system administrator gets to employee's workstation, and logs in with his administrator's account.
According to the bank's policy, administrator's account should not have access to the billing system, but with couple of built-in commands in windows, this system administrator will hijack employee's desktop which he leaved locked. From now, sysadmin can perform malicious actions in billing system as billing employee account.

There are huge amount of scenarios like this.

Furthermore, an attacker doesn't need to use tools like metasploit, incognito, mimikatz etc, which is commonly used for user's token manipulation and impersonating logged in users. Everything is done with built-in commands. Every admin can impersonate any logged in user either locally with physical access or remotely via Remote Desktops (see PoC).

Tested on:

Windows 2016 (Confirmed by Kevin Beaumont @GossiTheDog)
Windows 2012 R2
Windows 2008
Windows 10
Windows 7

We can talk about endless amount of examples.

It can be done remotely, as shown in Proof of Concepts.

An attacker can hijack active or disconnected session remotely via remote desktops.
I use this technique about three weeks in my on-going penetration tests on daily basis. It in very simple way helps me to get access to sensitive information like emails, opened documents, clear-text passwords that administrators write down in notepad (not intended for saving, but for temporally writing it somewhere), opened RDP sessions to another external domains (think cloud), or another applications that make use of different login credentials.

Someone can say, if you admin, you can dump server's memory and parse it. That's correct, but you don't need it any more. Just two simple commands and you are in. The most incredible thing, is that I don't need to know the credentials of hijacked user, it is pure passwordless hijacking.

A successful attack heavily related on time and gathered information. If you need to dump a memory, to get your sensitive info, you're in problem. That means that you've tried all quick-wins that you know.

In example of hijacking user (active or disconnected) while he is working now remotely on some sensitive server that i have no access to, and haven't even knew about it, this technique allows me to compromise that server in less than a minute. Everything is real and from my own experience.

Furthermore, as I understand it is very hard to catch if this attack happen. Kevin Beaumont @GossiTheDog make an alert on tscon.exe usage, with Microsoft OMS.

I had a conversation about this finding with Benjamin Delpy @gentilkiwi author of mimikatz:
"That is normal Windows API, that's the design flow, they use it. As mentioned earlier, if you admin, you can do everything. But here is the point. Why and HOW you become admin? If some unprivileged user becomes admin using some kind of local privilege escalation - that's the problem and not the design flow we are talking about. You can do everything, even patch terminal services the way that it will accept your token and allow shadowing mode, without user's knowledge.", he said.

Proof of Concept:

Microsoft documentation helps us to do that from command line:

All we need is NT AUTHORITY/SYSTEM command line. 
Easiest method with psexec, but requires psexec.exe to be there: 
psexec -s \\localhost cmd

Another method is to create a service that will connect selected session to ours.

1. Get all sessions information:
C:\Windows\system32>query user
 administrator                             1  Disc            1  3/12/2017 3:07 PM
>localadmin            rdp-tcp#55          2  Active          .  3/12/2017 3:10 PM

2. Create service which will hijack user's session:
C:\Windows\system32>sc create sesshijack binpath= "cmd.exe /k tscon 1 /dest:rdp-tcp#55"
[SC] CreateService SUCCESS
3. Start service:
net setart sesshijack

Right after that your session will be replaced with target session.

Proof of Concept video:

Windows Server 2016 Demo (new):

Windows 7 via Task Manager:

Windows 7 via command line:

Windows 2012 R2 via service creation:

Update:  has found that before in 2011, so that is a feature and not zero-day:

Update: If you still think that this don't have high attack value, read a great writeup by Kevin Beaumont about this feature:

Update: RedSnarf has now support in RDP Hijacking


  1. Thanks a lot for the information !!
    I love to read your blog
    i tried it now with Server 2012 R2
    but when i start my custom service i got error
    thanks shai

  2. This comment has been removed by the author.

  3. Just stop using this M$ shit :)

  4. What about M$ protection ? released M$ security vulnerability updates ?

  5. This *bug* is due to a call to WTSQueryUserToken, which gives you a token handle that you can then pass into CreateProcessAsUser. You have the SE_TCB_NAME privilege set, hence why you need to do it as SYSTEM. I released code to exploit this in 2010. sjl

    1. where can i see the exploit code?

    2. first of all, I'm not the same anonymous :)

      Hi Alexander, thanks a lot for sharing your findings. Even if I knew @gentilkiwi's work I admit I missed his post about this issue.

      Doing a bit of googleing on "SE_TCB_NAME" I found this link:

      Alex Fedotov in 2001 wrote:

      Re: How _programmatically_ grant privilege SE_TCB_NAME

      [...]You should never grant the SE_TCB_NAME privilege to any real
      user account, even administrator's account. It's too dangerous. If
      you need to call LogonUser and CreateProcessAsUser, ***do it in a service
      that runs in the LocalSystem logon session***.[...]

      At the time, soon.exe and srvany.exe ( were commonly used to do such things (i.e. bypass user specific ACL). Just login as local admin, soon.exe in order to spawn a cmd as NT/SYSTEM and do... what you had to do. At least I finally found WHY this was working.

      There is also an old MS KB article showing "How To Manage User Privileges Programmatically in Windows NT" ( so, MS told us HOW do this programmatically since 2005.

      That is to say, I think that is not so important who is the first that "discovers" something (or when) but what you someone can actually do with such "discovery".

    3. Why you so anonymous? :) thanks for your comment!

  6. If you are a local machine admin you are by definition a "god" on that machine. Similar to Linux root. Windows UAC notwithstanding, there is no such thing as a higher privileged account. This is a failure in understanding by the poster. A "domain account" is not "higher" either. Why would it be? Local machine admin is god on that machine.

    1. on that machine, not on the domain.

    2. As the blog post suggests, if a domain admin is *also* logged on to the machine (first off, why is he on your machine?), then yeah, he now has an active session on *that* machine and you can take over his account because you are the god on that machine just like Linux root. This just doesn't sound like vulnerability but a general misunderstanding on the part of the poster.

    3. think about domain post exploitation.
      1. an attacker have hash of local admin
      2. an attacker executes command on some fileserver with system privilege (adding sethc backdoor for example)
      3. connects via rdp and hijacks session of domain admin

      There can be endless amount of scenarios.

      On other hand, you are talking about linux root. How hard it will be to hijack some ssh linux session? But you are the "god" in that machine?

      In case of windows, it's done with one command now.

    4. @Carlos this is certainly not a misunderstanding on the part of the poster. This effectively gives anyone with a local admin on 1 machine in a domain, the possibility to easily become domain admin. Good practice is to log out fully, but in reality it can be forgotten or just not always done. This is a very major security flaw

    5. But it is all based on the premise that there is a domain admin currently logged into the workstation. When and why in the world would that happen? And you're telling me root on Linux can't spy on another Linux session on the machine using Screen or otherwise do a whole host of other stuff? C'mon now. The attacker in this case must already be a local admin. Why would you ever give anybody Local Admin privileges? Why would you ever log into a machine (via RDP or otherwise) where a local admin existed and then leave that session running knowing full well Local Admin is God on that machine???

    6. BTW, there is a security "best practice" for this. If you must allow a user to have local admin rights (bad idea, but whatever) and you are afraid some IT person (domain admin) might log in (via RDP or locally) and leave a session running, then DISALLOW that machine from joining the domain. The user can still access domain resources as whatever low-level limited user they are: Windows will just prompt the user for their AD domain credentials when they try, but no "domain admin" can RDP or log into your machine. Your machine is technically "off" the domain. This is done with consultants all the time.

    7. Imagine scenario like this (real life scenario):
      1. We have regular domain
      2. Domain Users doesn't have local admin privileges except of IT Dept.

      So, the attack flow:
      1. User John boot form USB/CD/Network some kind of linux/rescue_cd
      2. John backdoors it's own workstation with sticky key backdoor.
      3. With next boot, John have system privileges.
      4. John dumps local hashes with command "reg save hklm\sam" (legit right?)
      5. John call IT Dept for remote help
      6. John catch with netstat the IP address of IT Admin
      7. John connects back with pass the hash technique and execute command as system
      8. John connects to the IP of the Admin and hijacks it's session while admin out for lunch.
      9. Game over.

      Full disk encryption. But if you have an enterprise of 2000 employees, it is relatively hard to implement.

      It happens everywhere. You can harden the things, but almost everywhere you can do everything with built-in commands.

      You are right, it's not zero-day, it's not vulnerability - it is attack vector.

    8. Maybe I'm misunderstanding but how is any of this different than John, local admin (again, God on the machine), installs keylogger on system message pump (something I can do in 10 minutes in C++). John asks IT to RDP into their machine. John has all their passwords. That's an even worse scenario because I no longer need the Domain Admin to be logged in any more (via RDP, local session, or otherwise). This is also possible in Linux (as root).

    9. I think (maybe I'm wrong) that the problem is the idea that Local Admin is below System. But, they are not. Windows is not designed this way. A real Local Admin is "root"... System is just a variant of Local Admin. Local Admin can always escalate to System otherwise they are *not* "Local Admin." You can create other locked down accounts via AD and Group Policy that come close to having some of the same rights, but they would not be Local Admins (such as Local Root without network access, network access without local rights, etc)... and indeed we do this all the time. Disclosure: I am a developer, with a strong interest in security, but I am not IT. I'm open-minded.

    10. Yes, you can do anything. Everything is depends on point of view and scenarios that we can mind. By the way, IMHO one-two commands is much simpler than writing a keylogger. :) again, it's an attack vector, and i know that admin can do what ever he wants.

    11. Agreed. It is definitely an attack vector. And I think this vector illustrates a weakness in using RDP to administer systems. But similar issues exist with using VNC to administer Linux or Mac boxes. It's probably even worse there. I understand that RDP is the quick and easy way for domain admins to administer Windows boxes who don't really care to use PowerShell, remote CMD, or any of the myriad of MSC Remote Management Console tools available.

    12. Again, maybe I'm misunderstanding the issue, but you wouldn't use VNC to administer a Linux box. Why would you (not you personally- an admin) use Remote Desktop to administer a Windows box? And, if you do use RD, why in the world do you not understand that a Local Admin on that box is God over your (essentially *local*) console session? The same exact problem exists on Linux and every other OS AFAIK.

    13. :-) Also, perhaps not 2-lines of CMD commands, but a keylogger is like 5 lines of code (not just on Windows, but on any OS). The issue is getting it to run as SYSTEM. Which you can't do unless you're a *Local Admin*.

  7. Hey mate you arrive late, this is a design flow, in windows basically the system account can impersonate each user.
    You can find more info on impersonation and a tool made by us here or a video here, have fun!

    1. Just for clarification. I've not invented pass the token.
      In your video demo, you show some kind of external program which behave like incognito or mimikatz, and can pass the token.
      I assume that the attacker is on the left side, and the client on the right side.
      So, left side is never get gui session of impersonated user, on the right side you are connecting an active user (which may be legit) to another session. Pointless.
      I'm talking about full GUI RDP passwordless session hijacking, that's all.

    2. Without any external program:
      sc create myserv binpath= "tscon 2 /dest: tcp-rdp#0 "
      sc start myserv

      "NT AUTHORITY\SYSTEM" can impersonate each user, no zero day, no feature, simply how windows is built.
      You understand that from System to one user the way is easy, you can do that because system account can open handles to each user token on the machine and our software does exactly the same. I hope you understand what we means... In any case mimikatz do something completely different...

      Anyway we are opened to collaborate on this theme....

  8. This is not really an exploit... if you have local admin you can record windows sessions or use a keylogger or pretty much anything you want. It's like giving somebody root access when it's not needed (always).

  9. This is not really an exploit... if you have local admin you can record windows sessions or use a keylogger or pretty much anything you want. It's like giving somebody root access when it's not needed (always).

  10. Can this technique be used remotely? I don't see a remote parameter for tscon.

  11. Seriously, just remove your "0day" and "privilege escalation" keywords from your title, this is SO inaccurate (and you seem to know it regarding your own comments).

    If you still think this is a security issue, let me give you another "0 day" for your next blogpost: on Linux, you may use a live CD in order to become root, and then if you're root you can "su" any user without knowing his password. You're welcome.

    Ps: for your "a local user may become a local administrator using a live USB/CD/whatever", let me introduce you to a new security concept: Bitlocker + TPM. Can be enabled through GPO and is enabled in lots of large companies.

    1. You don't even need bitlocker if you use SSD's like Samsung's EVO. The data is automatically encrypted *by default* and the factory encryption key (obviously accessible at first) can in turn be encrypted using simple, classic Class 0 BIOS password (the kind that "protected" old HDD's- but never really did). I don't know, but I think many SSD's do this as a matter of course- not just Samsung. And there are more Enterprise-managed options (Opal, for instance) on the same.

  12. This comment has been removed by the author.

    1. Carlos, because of your comments count, I see that you are very interested in this "feature" :) so would you like to continue conversation via email? :) nopernik at gmail

    2. Sure. I highly respect your work. Sorry for the deletes. Just wanted to clarify my post (below). Feel free to respond to the thread.

  13. BTW, couple of food-for-thought things:

    1) I wonder if Microsoft's remote tools like remote MSC or remote PowerShell sessions can be hijacked locally by a Local Admin? I don't think either establish local "user sessions" but I could be wrong.

    2) I would think remote CMD (WinRM) would suffer similarly to RDP since I think that gives you the option of loading the domain user's *local* profile environment on that machine (C:\Users\...Desktop etc) and the profile would be created on the fly if it doesn't exist (just like RDP does).

    3) How about VNC sessions? Can they be hijacked by Local Admin? I would think yes. Things like VNC and TeamViewer are especially problematic because they install privileged System Windows Services with console interactive rights (the login screen) as opposed to RDP, which does not do that (although it *appears* to do it and for all intents and purposes does, but it really doesn't... on Windows Pro it mimics the login screen, on Windows Server it absolutely does not because of Terminal Services... but neither really use the real console).

  14. this does not works under Windows Server 2016 Datacenter, running a full RDP server.
    I watched your video and instructions and did exactly the same psexec command. The outcome is that task manager or prompt is opened, but inside the user session. It does not "pop out" on my session just like your video, so it is useless. And yes, I am a local admin and domain admin, so that is not a priviledge problem.

    But I was able to reproduce under my another Server 2012R2 RDP server.

    1. Specially for you