2

We recently got a strengthened security policy where people are required to log out of any RDP connections at the end of the day. So when I turn off my laptop, it is not enough to merely close the RDP connection, I actually have to log out of it.

Naturally, this causes all kinds of complications because then I will also lose any active ssh connections from that server to elsewhere, or any tasks I'm running, various open browsers and notepads with remarks etc., and I many times continue the work when I arrive home, or I might be telecommuting and moving while working. While it is possible to put browsers and Notepad++ to modes where they remember where you left off, it still complicates things, especially if I am on call duty and I am supposed to react fast.

I was told the reason is that cyber attackers can possibly hijack any active or "disconnected" RDP sessions, and was pointed to e.g. this article, which didn't really help me understand how such hijacking is possible:

https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/ransomware-hive-conti-avoslocker

So is this really the case that merely closing the RDP connection is a security threat, and logging out of the session is the only solution?

E.g. locking the RDP session to the login screen is not enough, a hijacker can still use your active RDP connection, even without knowing your password (if he knows my password, then I guess it doesn't matter either way, he can log into the RDP session even if I was logged out)?

I think we are also introducing MFA for those RDP sessions (naturally we have MFA already for VPN), but I got the impression even that doesn't help with the problem; if you haven't logged out, your RDP session can be hijacked.

Is this considered as a "feature" of RDP and just the way it is, or is this an issue (i.e. the ability to hijack active RDP sessions) that Microsoft or whoever is supposed to fix in the RDP protocol?

Note: I do understand it is a good practice to log out if you are not going to use the server for some time (vacations etc.), and also not to increasingly hog system resources, but I am strictly asking about the security implications so that I really should log out each day.

4
  • You are correct. That article is not relevant to explaining how logging out of an RDP session would prevent session hijacking.
    – schroeder
    Mar 31, 2023 at 7:56
  • If it makes a difference starting a new RDP session from reconnecting to an existing RDP session, then the difference can only be related to the authentication. Do you also have to perform a 2FA login if you reconnect to an already running RDP connection?
    – Robert
    Mar 31, 2023 at 8:23
  • Robert, if i connect to (my) existing disconnected RDP session, certainly I have to provide my username and password for that. I presume that if and when we get 2FA for that, it will require 2FA even when connecting to an existing RDP session. However, is that relevant for the RDP session hijacking? I got the impression the session can be hijacked without providing any credentials, either password or MFA?
    – timppu
    Mar 31, 2023 at 9:10
  • Session hijacking is possible only for local (not in a physical sense, but from a security PoV) users with Administrator/SYSTEM level credentials which means the server is completely compromised and trying to keep user sessions intact while keeping it that way is ultimately pointless as it can and most likely will result in further damage to the infrastructure. I cannot imagine how these measures can protect you for any meaningful amount of time. The attacker will absolutely try to gain further access. It's basically a security theater if you ask me. Mar 31, 2023 at 9:41

1 Answer 1

1

Yes, it is possible to hijack an RDP session. The method even has its own entry in MITRE ATT@CK:

Adversaries may perform RDP session hijacking which involves stealing a legitimate user's remote session. Typically, a user is notified when someone else is trying to steal their session. With System permissions and using Terminal Services Console, c:\windows\system32\tscon.exe [session number to be stolen], an adversary can hijack a session without the need for credentials or prompts to the user.

These techniques were developed in 2017, and there might be mitigations in place in your environment to prevent it, but it is a risk to consider.

How it works:

  • You can connect to disconnected sessions. So if somebody logged out 3 days ago, you can just connect straight to their session and start using it.
  • It unlocks locked sessions. So if a user is away from their desk, you steal their session AND it unlocks the ‘workstation’ without needing any credentials.
  • It works for the physical console. So you can hijack the screen remotely. It also unlocks the physical console, too.
  • You can connect to ANY session — so if, for example, it’s the Helpdesk, you can connect to it without any authentication. If it’s a Domain Admin, you’re in. Because of the above point (you can connect to disconnected sessions), this makes it an incredibly simple way to laterally move through a network.

And there is a mimikatz module for doing this.

And since it hijacks the existing logged in session, no credentials are needed and MFA doesn't help.

One of the mitigations is to actually close the RDP session. There is even a Group Policy setting to automatically log off disconnected RDP sessions to enforce this.

So, your security team is correct, at least in part. We aren't privy to their environment to know if this policy is required, but, using the tools above, it is easy enough to test.

9
  • Thanks for the comprehensive answer. When you say it is easy to test whether the RDP sessions are "hijackable", does that mean it is also possible to somehow strengthen the server or RDP so that it isn't possible, at least with that particular exploit?What I am trying to understand that is that logoff requirement pretty much compulsory for security, or can users still enjoy the benefits of disconnected sessions, without compromising security?
    – timppu
    Mar 31, 2023 at 9:18
  • There might be ways to mitigate this with recent developments. I'm not sure. But whatever mitigations there might be can be tested. Your security team appears to have concluded that there is no mitigation in place, so the policy is necessary.
    – schroeder
    Mar 31, 2023 at 9:22
  • Thanks, still one question. Is the main concern with the hijacked RDP session that it might have open connections (ssh, browser logins etc.) into various places and services? So as long as those are not active and open, hijacking the RDP session of even an admin group user does not really cause any extra concern, beyond that compromised RDP server?
    – timppu
    Mar 31, 2023 at 9:37
  • So the security policy is mainly to make sure no users have such open connections to other servers and services?
    – timppu
    Mar 31, 2023 at 9:37
  • The secondary connections (ssh, etc.) don't need to be open. The session into the machine that grants access to those other systems is a problem in and of itself because those connections can be re-opened. Notepad can be searched for passwords, IPs, and connection strings. The tools you used can be opened and closed sessions re-established, etc. Think of it like "now someone is sitting down at my RDP session".
    – schroeder
    Mar 31, 2023 at 9:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .