Detecting and Mitigating RDP Session Hijacking (T1563.002)

A disconnected remote desktop session is a logged-in desktop waiting to be reused. RDP Hijacking (T1563.002) is a Lateral Movement technique for Windows, and a subtechnique of Remote Service Session Hijacking.

How attackers use it

MITRE explains that remote desktop lets a user log into an interactive session with the graphical desktop of a remote system. Microsoft's implementation of the Remote Desktop Protocol is called Remote Desktop Services.

In RDP session hijacking, an adversary steals a legitimate user's remote session. Normally the user is notified when someone else tries to take their session. But MITRE says that with System permissions and the Terminal Services Console, using the tscon.exe tool with the session number to take over, an adversary can hijack a session with no credentials and no prompt to the user. It can be done remotely or locally, against active or disconnected sessions.

The consequences are described as Remote System Discovery and Privilege Escalation, for example by taking over the session of a Domain Admin or a more privileged account. MITRE notes all of this can be done with native Windows commands, and that it has been added as a feature in red teaming tools.

Two things follow for defenders. The adversary already has SYSTEM on the host, so this is a post-compromise technique. And because no password is entered, there may be no authentication event for the hijacked session.

How to detect it

MITRE's analytic suggests looking for suspicious use of tscon.exe or equivalent methods, along with:

• Session reassignments that have no matching authentication.
• Processes spawned in the context of a hijacked session.
• Unusual RDP network traffic flows that deviate from your baseline.

Process creation logging catches the command. Look for tscon.exe with a session ID, especially when the parent process is not an interactive administrator tool. Also watch for service-created processes that run tscon, since MITRE ties the technique to System permissions.

Windows also records session state changes. Events for session reconnect and disconnect appear in the Security log (4778 and 4779), which let you see a session being picked up by a different client.

Sessions have a life cycle, and that is where the controls live

A Remote Desktop session can be active, or disconnected but still running on the server. A user who closes the window instead of logging off leaves the session alive. That is the convenient state for both the user and the attacker, because the programs and the logged-in identity are still there.

Group policy lets you control that life cycle. Under the Remote Desktop Session Host settings, the session time limit policies set how long a disconnected session stays and how long an active session may run, which is the control MITRE recommends. Choose limits that match how people really work, and make logging off the norm.

Privilege exposure matters most

The consequence MITRE highlights is taking over a session that belongs to a more privileged account. Two habits reduce that risk sharply.

• Do not let domain admins sign in to ordinary servers or workstations. If a privileged session never exists on a host, there is nothing to hijack.
• If administrators must connect, have them log off when done, not disconnect.

If you suspect a hijack

1. List sessions on the host and compare against who should be logged on.
2. Search process creation logs for tscon.exe, and find the account and parent process that ran it.
3. Look at what ran in the taken-over session after that moment, using process and network logs tagged with the session.
4. Treat the account whose session was taken as exposed, and reset its credentials.
5. Treat the host as compromised, because the adversary needed System permissions to do this.

How to reduce the risk

MITRE lists five mitigations.

1. Limit access to resource over network. Use remote desktop gateways.
2. Network segmentation. Block RDP traffic between network security zones with firewall rules.
3. Operating system configuration. Change group policy to define shorter session timeouts and a maximum time for any single session to stay active. Also set a maximum time that a disconnected session stays active on the RD session host server.
4. User account management. Limit remote user permissions where remote access is necessary.
5. Audit. Review the Remote Desktop Users group regularly, and remove unnecessary accounts and groups.

The group policy item matters most. A disconnected session that ends after a short time is a smaller target than one that lingers for days.

Check your own environment

These are read-only.

# Windows (cmd): list sessions on this host, including disconnected ones
query user

# Windows (cmd): list members of the Remote Desktop Users group
net localgroup "Remote Desktop Users"

Then work through the checklist:

• Do any hosts show disconnected sessions that have been idle for days, especially for privileged accounts?
• Is there a group policy that ends disconnected sessions and caps session length?
• Does anyone with domain admin rights log in to ordinary servers over RDP?
• Is RDP reachable between network zones that do not need it, and is a gateway in front of the rest?
• Are tscon.exe launches logged and alerted on?

Common mistakes

• Setting a session limit for active sessions but leaving disconnected sessions unlimited. The disconnected ones are the easiest to take over.
• Allowing privileged accounts to RDP into every server for convenience, which creates high-value sessions everywhere.
• Logging process creation on domain controllers only. Hijacking happens on whichever host holds the session.

Quick check

Sources

• MITRE ATT&CK T1563.002: RDP Hijacking