With the amount of remediation folks have these days to catch malicious execution of powershell or the use of tools like psexec, red teams have to be asking themselves – what approach is next for lateral movement after you get that first foothold?
For me, if the easy stuff isn’t an option, SharpRDP makes a pretty easy “next tool on the shelf”
SharpRDP takes advantage of the fact that Microsoft took a lot of pages from the Citrix ICA protocol when they put the RDP protocol together. RDP isn’t just for remote desktop – it implements “channels” which can be used for all sorts of things. In the past, the most common use of channels in ICA is to differentiate printer traffic from interactive traffic, and apply different QOS policies to it. But SharpRDP takes it to the next level, and allows you to start a session, and instruct it to execute code after it starts!
For the red team, this has oodles of attraction – often you don’t have a GUI, and this lets you run pretty much anything you want on a remote host over a traditionally “GUI” protocol. Since it’s in an RDP session, it’s an actual terminal session (not a shell), so all of your inputs and outputs are handled correctly. While you could theoretically run a CLI terminal session over this, I’m not sure that this is implemented – I haven’t needed to figure that piece out yet if it is.
For someone on the blue team, this is a tough thing to catch – it’s going to look like any other RDP session that your admins might make, executing “something” after it starts.
What does a session look like? It’s as simple as:
>SharpRDP.exe computername=targetservername command=”” username=> password=
Normally I’ll have the “command” be a CMD file that does whatever I’m trying to accomplish – usually it’s data collection of some kind, with the data coming back to the host that I have my foot-hold on. Remember that if your command is not an actual executable (for instance, “dir” is not an executable file. it’s part of cmd.exe), you will have to use “c:windowssystem32cmd.exe /c” to load the cmd interpreter prior to executing your “thing”.
My go-to is single letter CMD files, so for instance t.cmd. This file is usually homed on my foot-hold server, and sends the data back to a share on that same server. Also the output normally has %COMPUTERNAME% in the filename so I can keep the files straight (and not have name collisions).
Protections? LAPS is a good one – if every target host has a different password, you’ll have to collect all of that first before you can use SharpRDP. (https://isc.sans.edu/forums/diary/Microsoft+LAPS+Blue+Team+Red+Team/24528/). Really though if an attacker is far enough in to fire up RDP sessions to arbitrary hosts, harvesting the LAPS passwords isn’t too tough, once you figure out that LAPS is in play. MFA on RDP sessions is really your best bet. I’ve got a few clients running this, and it’s pretty slick. Most MFA solutions allow you to extend RDP authentication, usually it’s a “click OK” or a biometric confirmation (Face-ID usually) on your phone to complete the RDP session.
If you’ve got MFA on your servers for RDP access, then SharpRDP use is defeated nicely, and your detection that you can code into your SIEM is whatever event is generated by “failed MFA on RDP”. Your next-level protection in that case is “alert on any new registration of MFA users”. You’ll want any registration of new users, or registration of new phones to existing users to go to a number of people – once MFA is a main protection, it also of course becomes a main target.
All that being said, MFA on RDP is not widely implemented in March of 2021 – there are a lot of people working on fixing this though. The uptick in migrating VPN’s and Citrix Gateways to newer MFA solutions means that it’s becoming much easier to extend MFA to more and more platforms, and RDP is one of the easier and more impactful ones that we see picked.
SharpRDP is homed here:
And has a full write-up here:
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.