Microsoft’s Remote Desktop Protocol (RDP) is used to remotely administer systems within Windows environments. RDP is everywhere Windows is and is useful for conducting remote work. Just like every other remote administration tool, RDP can be used for legitimate or malicious control of a computer and is used by administrators and attackers alike for command and control of a remote system. As RDP also can be used to move laterally through a victim network it’s a great example of attackers living off the land. The Restricted Admin Mode (seemingly now replaced by Remote Credential Guard) introduced into Windows even enables pass-the-hash style authentication for RDP clients. Tools, such as SharpRDP and Sticky-Keys-Slayer are able to automate command execution and RDP interactivity. The latter is also a tool for gaining initial access to systems through RDP services, a strategy adopted by multiple attackers for manually spreading ransomware. To distribute Crysis, for example, attackers would brute force guess credentials, or use stolen ones, to control RDP servers exposed to the Internet and then manually implant ransomware. A similar strategy has been seen by actors distributing GoGoogle and RobbinHood ransomware. 

Financially motivated attackers aren’t the only classes of threat making use of RDP, however. RDP services are also a vector of attack for advanced offensive groups like APT39 and APT40. Discovered in January of 2020, the Trickbot malware family added a new module, rdpScanDll, giving the malware the capability of credential bruteforcing. Wormable exploits like BlueKeep, DejaBlue, and BlueGate plague RDP servers across the Internet. Shodan recently identified an increase in publicly exposed RDP services on the Internet, a measure which Shadowserver and Kaspersky also monitor. Given RDP’s complexities and extendability, I would not be surprised if more RDP remote code execution vulnerabilities exist.

Zeek is capable of analyzing RDP connections and does a fantastic job handling the many options and configurations the RDP protocol supports. For performance reasons, Zeek disables the SSL analyzer after encryption begins. This blog serves as a closer examination of encrypted RDP communications, specifically those over TLS. It contains sections on RDP’s background, its encryption and authentication methods, and the differences between its TCP and UDP transports. It will conclude by looking at how encrypted RDP connections can be conceptualized with sequences of lengths and inter-arrival deltas (SOLID, a retrofitted name for “sequences of lengths”) and how patterns within those SOLID can potentially be used to create inferences. Inferences on encrypted RDP connections could provide forensic value without TLS decryption, without endpoint monitoring, and without having to know where RDP services are located on your network.

Background

The Remote Desktop Protocol, which is used by Windows Terminal Services, consists of many sub-protocols, extensions, redundancies, and options. This plethora of choice is best demonstrated by the Protocol Relationship Diagram (section 2.2.1) in Microsoft’s specification for RDP. For this blog, “RDP” will refer to MS-RDPBCGR and all its options and extensions while “RDPEUDP” will refer to both MS-RDPEUDP and MS-RDPEUDP2.

RDP is conceptually similar to SSH in that it provides a client an interactive console to a server. Both RDP and SSH services are often exposed over the Internet for administrative access. RDP and SSH are different, however, in that the RDP console will always be graphical and human driven. RDP aims to emulate an entire desktop environment, which is a large feat. SSH, on the other hand, is much simpler, only emulating a text-based terminal. SSH also supports automation. It includes file transfers and other “headless” modes-of-use. In fact, SSH’s headless tunneling capabilities are sometimes used to transport RDP through firewalls with reverse shells, which the latest version of the SSH Inferences package is able to infer. RDP is also conceptually similar to Powershell Remoting in that both can be used to administer and control a server. Powershell Remoting is, however, similar to SSH in that it is a command-line interface. RFB (VNC) and X11 also share similarities with RDP, being protocols which facilitate virtual desktop experiences.

RDP makes use of channels which are multiplexed over the TCP connection alongside other message types. Examples of RDP static virtual channels are, “rdpdr” (redirection), “rdpsnd” (sound), “cliprdr” (clipboard). Others static virtual channels enable USB device access, shared drives, and more. Static virtual channels are “joined” during the Channel Connection stage of the Connection Sequence (see Figure 1 below). These channels are conceptually similar to SSH channels. This CTF challenge walk-through demonstrates how contents from the clipboard static virtual channel can be recovered from a trace of an RDP connection.

One static virtual channel, the dynamic virtual channel, is used to extend the number of available static virtual channels. Dynamic virtual channels provide things like USB device access, graphics output, and more (including unconventional purposes, like tunneling SOCKS). It seems as though the RDP protocol was originally designed with a limited amount of static virtual channels and dynamic virtual channels are a method of extending the protocol to support more features. A major difference in static virtual channels compared to dynamic virtual channels is that dynamic virtual channels’ messages may be transported over RDPEUDP. This reduced set of messages simplifies analyses of RDPBCGR SOLID.

RDP’s complexity makes it complicated to comprehend. RDP was built on top of protocols whose creation preceded the more “modern” TCP/IP. Furthermore, it carries a bunch of backwards compatibility around which makes interoperability between different Windows operating system versions achievable. Wikipedia lists over 10 versions of the RDP protocol. The technical specification has had 52 major revisions since 2007. Features of the protocol have been developed over multiple Windows operating system versions and some features have been provided through Microsoft acquisitions. And, according to the National Software Reference Library, Microsoft has released 128 versions of mstsc.exe, the main driver program for Windows RDP clients. It has also released 107 versions of mstscax.dll, which provides functions used by mstsc.exe. 

The good news is that Microsoft maintains open specifications for the RDP and dochelp@microsoft.com is both responsive and helpful! The FreeRDP project’s open and auditable source code is also an invaluable resource.

Authentication and Encryption

RDP supports two types of encryption, enhanced and standard (sometimes called native). RDP supports two categories of authentication, Network Level Authentication (NLA) and non-NLA, the latter should not be used. These authentication and encryption schemes can be combined in the following ways:

1. Standard encryption and non-NLA authentication. This manifests as “RDP” in the security_protocol field of the RDP log. An example of this can be found in tests included in Zeek.
2. Enhanced encryption and non-NLA authentication. This manifests as “SSL” in the security_protocol field of the RDP log. 
3. Enhanced encryption and NLA authentication. This manifests as “HYBRID” or “HYBRID_EX” (if the client also supports the Early User Authorization Result PDU) in the security_protocol field of the RDP log. An example of this can be found in tests included in Zeek. “HYBRID_EX” is generally considered the most secure configuration for RDP connections.

With standard encryption, much of the RDP Connection Sequence (which is conceptually a handshake) occurs in the clear. Encryption begins with the Secure Settings Exchange stage (note that at the time of writing, Zeek’s RDP analyzer currently only supports parsing of messages through the Basic Settings Exchange stage while Wireshark has very limited support for dissecting messages beyond the Connection Sequence). The rdfp Zeek package makes use of these clear-text messages to fingerprint RDP clients using standard encryption.

With enhanced encryption, TLS (TLS and SSL are used interchangeably in this blog and in the Zeek source code) is shimmed between the Connection Initiation and Basic Settings Exchange stages of the Connection Sequence. This means anything after the Connection Initiation stage is encrypted if TLS is employed. Luckily, Zeek can be used to provide inferences about connections even if their contents are encrypted.

With non-NLA authentication, client authentication takes place after the RDP Connection Sequence. An RDP connection is established and a client can interact with the server’s login screen. With NLA authentication, RDP uses the Credential Security Support Provider (CredSSP) Protocol, a Security Support Provider composed of TLS and SPNEGO (an extension to RFC 4718). CredSSP can also be used by WinRM (Powershell remoting) for authentication. The CredSSP portion of an RDP connection occurs between the Connection Initiation and Basic Settings Exchange stages of the Connection Sequence. The TSRequest structure is the format CredSSP uses, while SPNEGO refers to its structures as Tokens. These tokens are present in the negoTokens field of the TSRequest.

Figure 1 (below) diagrams an example RDP Connection Sequence which used both enhanced encryption and NLA authentication with support for the Early Authentication Result PDU. This configuration would manifest as “HYBRID_EX” in the security_protocol field of Zeek’s RDP log. If you find the RDPBCGR Connection Sequence daunting, just look at what happens when a Remote Desktop Gateway proxy is used in conjunction with RDPBCGR (Figure 8).

Transport

RDP can be transported over TCP or TCP and UDP. This is an example of Multiband Communication (MITRE ATT&CK technique T1026). RDP over UDP (RDPEUDP) has been supported and preferred since Windows Server 2012. It seems only Windows clients currently support the RDPEUDP transport mechanism. Zeek supports identifying RDPEUDP connections and will set the conn log’s service field appropriately.

RDPEUDP has two versions; version 1 bootstrap version 2. RDPUEDP2 can be considered an extension to RDPEUDP and only can be used after the RDPEUDP connection’s “Connection Initialization” phase. RDPEUDP supports lossless and lossy transmissions, while RDPEUDP2 only supports lossless. Lossless mode uses TLS while lossy mode utilizes DTLS. RDPEUDP begins with its own handshake, similar to the TCP 3-way handshake, over UDP. RDPEUDP can be thought of as TCP features (e.g. 3-way handshake, state, acknowledgements, retransmissions, keep-alives) implemented on top of UDP without all those “pesky” TCP side effects (like congestion control and backoffs) that make TCP play nicely with other network applications.

RDPBCGR, the main protocol most think of when the term RDP is used, is transported over TCP, as shown in the cyan circle of Figure 1. All the stages of RDPBCGR’s Connection Sequences can be seen within the reddish circle of Figure 1. RDPEUDP is an extension to the RDP protocol which is bootstrapped through the optional stage of RDPBCGR’s Connection Sequence named the Multitransport Bootstrap stage. Between the Licensing and Capabilities Exchange stages, the server will send an Initiate Multitransport Request PDU to the client. This will indicate to the client that the server is accepting UDP connections. The client will then send an RDPEUDP SYN message to the server. The server responds with an RDPEUDP SYNACK. The client then sends a final RDPEUDP ACK and the first payload, thus establishing an RDPEUDP connection. If successful, this UDP connection will be used to transport dynamic virtual channel messages instead of the TCP connection. If the RDPEUDP handshake fails, RDPBCGR will use the existing TCP connection for all messages. If the RDPEUDP handshake succeeds, the TCP connection and UDP connection will be used in tandem. Certain messages, like dynamic virtual channel messages, will only be transported over the UDP connection. This separation of message types can make analyzing the TCP connection simpler. 

Conclusion

RDP is a very popular method for remotely controlling a system. It’s used by legitimate administrators and malicious actors alike. The protocol is quite old and provides many features, attempting to emulate an entire desktop. The RDP is often treated as an opaque service which “just works” when the correct ports are open on a firewall. Hopefully this blog stands as a resource for learning about RDP and for understanding RDP’s different mechanisms for encryption, client authentication, and transport.

If you don’t know if RDP is being used on your network, you may consider evaluating Zeek. If you know you use RDP on your network, you should consider reading our previous blog on mitigating RDP vulnerabilities. To learn more about the solutions Corelight can provide around the RDP, contact us.