RDP logout necessary to prevent RDP session hijacking?

Question

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.

Answer 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.