{
	"id": "547dd5c9-a83c-4523-a3b4-355a2acd3b94",
	"created_at": "2026-04-06T00:08:09.136809Z",
	"updated_at": "2026-04-10T03:21:47.459611Z",
	"deleted_at": null,
	"sha1_hash": "00e27a3542a8e0dd3452374e3bfec814baf07d56",
	"title": "RDP hijacking — how to hijack RDS and RemoteApp sessions transparently to move through an…",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 384446,
	"plain_text": "RDP hijacking — how to hijack RDS and RemoteApp sessions\r\ntransparently to move through an…\r\nBy Kevin Beaumont\r\nPublished: 2020-08-05 · Archived: 2026-04-05 13:04:58 UTC\r\nHow you can very easily use Remote Desktop Services to gain lateral movement\r\nthrough a network, using no external software — and how to defend against it.\r\nAlexander Korznikov demonstrates using Sticky Keys and tscon to access an administrator RDP\r\nsession — without even logging into the server.\r\nBrief background on RDP session connection\r\nIf you’ve used Remote Desktop Services before, or Terminal Services if you’re as old as me, you will know\r\nthere’s a feature where you connect to another user’s session — if you know their password. Did you know you\r\ncan also hijack a session without the user password? Read on.\r\nYou can right click a user in Task Manager, use tsadmin.msc, or use the command tscon.exe. It will ask for a\r\npassword, and bomb if you can’t authenticate as the user:\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@networksecurity/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6\r\nPage 1 of 6\n\nSome tricks allow credential-less Session Hijacking\r\nHere’s the deal. As revealed by by Benjamin Delpy (of Mimikatz) in 2011 and by Alexander Korznikov on Friday,\r\nif you run tscon.exe as the SYSTEM user, you can connect to any session without a password. It doesn’t\r\nprompt, it just connects you to the user’s desktop. I believe this is due to the way session shadowing was\r\nimplemented in Microsoft Windows, and it runs throughout the years like this.\r\nNow, you might be saying ‘If you’re SYSTEM, you’re already root… You can already do anything’.\r\nYes. Yes you can. You could, for example, dump out the server memory and get user passwords. That’s a long\r\nprocess compared to just running tscon.exe with a session number, and instantly get the desktop of said user —\r\nwith no obvious trace, or external tools. This isn’t about SYSTEM — this is about what you can do with it very\r\nquickly, and quietly. Attackers aren’t interested in playing, they’re interested in what they can do with techniques.\r\nThis is a very valid technique.\r\nSo, you have full blown RDP session hijacking, with a single command.\r\nSome parameters about how far this reaches\r\nYou can connect to disconnected sessions. So if somebody logged out 3 days ago, you can just connect\r\nstraight to their session and start using it.\r\nIt unlocks locked sessions. So if a user is away from their desk, you steal their session AND it unlocks the\r\n‘workstation’ without needing any credentials.\r\nIt works for the physical console. So you can hijack the screen remotely. It also unlocks the physical\r\nconsole, too.\r\nYou can connect to ANY session — so if, for example, it’s the Helpdesk, you can connect to it without any\r\nauthentication. If it’s a Domain Admin, you’re in. Because of the above point (you can connect to\r\ndisconnected sessions), this makes it an incredibly simple way to laterally move through a network.\r\nYou can use win32k SYSTEM exploits — there are many — to gain SYSTEM permissions, and then use\r\nthis feature. Meaning even as a standard user, if patches aren’t applied properly you can use this.\r\nObviously, any route to SYSTEM is valid — e.g. any method to get to a local administrator (there’s a\r\nfew!).\r\nhttps://medium.com/@networksecurity/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6\r\nPage 2 of 6\n\nThere are no external tools. Nothing to get through application allow listing. No executable is written to\r\ndisk.\r\nUnless you know what to monitor (more on that later), you won’t know this is happening.\r\nIt works remotely. You can take over sessions on remote computers, even if you’re not logged into that\r\nserver.\r\nGaining SYSTEM for tscon.exe\r\nIf you’re an administrator, you can use a service as Alexander demonstrates:\r\nPress enter or click to view image in full size\r\nIn essence it is really easy, just use the quser command to get the Session ID you want to hijack, and your own\r\nSESSIONNAME. Then run tscon with the Session ID for hijack, and your own SESSIONNAME. Your own\r\nSession will be replaced with the hijacked session. The service will run as SYSTEM by default — you’re in.\r\nJust remember to delete the service afterwards, if you’re evil.\r\nHere’s an example of it in practice on a Windows Server 2012 R2 server:\r\nhttps://www.youtube.com/watch?v=OgsoIoWmhWw\r\nOther methods:\r\nYou can use Scheduled Tasks to gain SYSTEM and run the command. Just schedule the command to run\r\nimmediately as SYSTEM with interactive privileges.\r\nUse can use a variety of methods like Sticky Keys to get SYSTEM, without even needing to log in (in the\r\nfuture). See below.\r\nExploits etc (see above).\r\nLateral movement\r\nhttps://medium.com/@networksecurity/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6\r\nPage 3 of 6\n\nMost organisations allow Remote Desktop through their internal network, because it’s 2017 and that’s how\r\nWindows administration works. Also, RemoteApp uses RDP. Because of this, it’s a fantastic way to move around\r\nan organisation’s network — forget passwords, just surf around and abuse other people’s access. You appear in the\r\norganisation logs as that user, not yourself.\r\nHow to backdoor for credential-less hijacking\r\nRemote Desktop bruteforcing is a major problem. Anybody who has setup a honeypot recently will know within\r\nseconds you will be getting hit with failed RDP logins. First they portscan, then thousands of login attempts arrive.\r\nGet Kevin Beaumont’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nIt gets worse — I run RDP honeypots, and I see them regularly — when breached they get backdoored using the\r\ntechniques below.\r\nFrom research, over 1 in 200 scanned Remote Desktop servers online are already backdoored using these\r\nmethods. This means that you can session hijack with them right now, without even needing to try to log in or\r\nauthenticate in any way. That’s bad. Consider Shodan shows there are millions of RDP servers online right now,\r\nand the number grows constantly with cloud services etc, this is going to generate… issues.\r\nRDP backdoor method one — Sticky Keys\r\nThe concept here is pretty simple — Windows supports a feature called Sticky Keys, which is an Accessibility\r\nfeature built into the OS and available pre-logon (at the login screen, either via a physical console or via Remote\r\nDesktop). It runs as SYSTEM.\r\nIf you set Sethc.exe (Sticky Keys) to spawn cmd.exe, you have a backdoor you can use if you are locked out of a\r\nbox — you have SYSTEM access, so you can do anything even without an account. You can do this by either\r\nreplacing sethc.exe with cmd.exe — this requires a reboot, and physical access to the box — or just set the\r\nregistry key using the command below.\r\nREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\sethc.exe\" /t\r\nTa-da! The box is now permanently backdoored. Just Remote Desktop in and at the login screen, hit F5 a bunch of\r\ntimes.\r\nMethod two — Utilman\r\nIt’s exactly the same as before, just trojan utilman.exe instead. At the login screen, press Windows Key+U, and\r\nyou get a cmd.exe window as SYSTEM.\r\nhttps://medium.com/@networksecurity/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6\r\nPage 4 of 6\n\nREG ADD \"HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\utilman.exe\"\r\nScanning for backdoor’d RDP servers\r\nThere is a prebuilt tool here, which works wonders — just spin it up and find servers which already have a\r\nSYSTEM level backdoor exposed:\r\nFrom online scanning, a significant amount of open RDP servers online are already backdoored.\r\nMimikatz module\r\nThere is now a Mimikatz module for very easily doing this:\r\ngentilkiwi rocking it\r\nMitigations\r\nOS-I had a section about Window Server 2016 here, however after further investigation it appears to also be\r\nimpacted. After testing this applies to every OS since Windows 2000, including Windows 10 and 2016.\r\nGroup Policy — I strongly recommend you use Group Policy to log off disconnected sessions, either immediately\r\nor soon after the user disconnects. This will NOT be popular in IT environments — but the risk is now completely\r\nreal that they can very easily — with one built in command — be hijacked more or less silently in the real world. I\r\nwould also log off idle sessions.\r\nDon’t expose RDS/RDP to the internet — if you do, I strongly suggest you implement multi-factor\r\nauthentication. You can use things like Microsoft RD Gateway or Azure Multi-Factor Authentication Server to get\r\nvery low cost multi-factor authentication. If you’re exposing RDP directly to the internet and somebody creates a\r\nhttps://medium.com/@networksecurity/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6\r\nPage 5 of 6\n\nlocal user or your domain users have easy to guess or reused credentials, things will go downhill fast. Trust me —\r\nI’ve seen hospitals and others be ransomware’d by RDS servers.\r\nMonitoring\r\nIt is surprisingly very difficult to record session hijacking — there is one event log (Microsoft-Windows-TerminalServices-LocalSessionManager/Operational) which records sessions connecting — however it does not\r\nappear to differentiate between a normal user connecting and tscon.exe being used — I’ve been through every\r\nother event log and can’t see anything which suggests this is happening. This is actually a major issue and I lobby\r\nMicrosoft to add some kind of Event Log ASAP — it’s a real gap.\r\nMy suggestion is you alert for other related behaviour using the Event Log and tools like Microsoft OMS,\r\nWindows Event Forwarding, Splunk etc. You’re looking for SYSTEM being misused.\r\nFor example abnormal Service creation and abnormal scheduled task creation should be logged centrally, and\r\nrecorded against. Additionally, you can look for Mimikatz related activity.\r\nk\r\nFAQ\r\nQ: This isn’t new or a vulnerability.\r\nA: Java applets and macros aren’t new. If the technique works, it will get used. This one has flown under the radar\r\n— that doesn’t mean it is not valid.\r\nQ: If you have SYSTEM you already own the box.\r\nA: Correct. Can you type one command and get the unlocked desktop of a user, even if they went on holiday a\r\nweek ago, without a log of it? Now you can.\r\nSource: https://medium.com/@networksecurity/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da\r\n2a1e73a5f6\r\nhttps://medium.com/@networksecurity/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://medium.com/@networksecurity/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6"
	],
	"report_names": [
		"rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6"
	],
	"threat_actors": [],
	"ts_created_at": 1775434089,
	"ts_updated_at": 1775791307,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/00e27a3542a8e0dd3452374e3bfec814baf07d56.pdf",
		"text": "https://archive.orkl.eu/00e27a3542a8e0dd3452374e3bfec814baf07d56.txt",
		"img": "https://archive.orkl.eu/00e27a3542a8e0dd3452374e3bfec814baf07d56.jpg"
	}
}