Corelight recently released a new package, focused on RDP inferences, as part of our Encrypted Traffic Collection. This package runs on Corelight Sensors and provides network traffic analysis (NTA) inferences on live RDP traffic.
Which inbound RDP connections were initiated by attack tools? Did an RDP connection use a Kerberos ticket for authentication or a password? Do any of my RDP servers use UDP?
The RDP Inference package provides these insights along with many others. These new insights bring valuable context to threat hunters and incident responders who struggle with visibility in encrypted environments.
What is an RDP inference? Corelight security strategist and author in residence Richard Bejtlich provided a great explanation in a previous blog post. An analogy follows: In order to count cards whilst playing blackjack, one never needs to directly observe the top card of the deck. It’s value can be inferred. Similarly, you don’t need to see what’s inside an encrypted tunnel to infer what’s occurring within it.
With increases in remote work, VPN and RDP services are prime targets for gaining unauthorized access to organizations. RDP services secured by passwords are subject to brute-force guessing and credential stuffing attacks, not to mention remote exploitation. If successful, these types of attacks can lead to the installation of ransomware. Last March Trickbot, a contender for replacing Emotet, added RDP brute-forcing to its capabilities. Recently, Palo Alto Networks reported that the Matrix ransomware family was seen brute-forcing RDP services in order to gain initial access. According to FireEye, groups such as APT39 and APT40 also make use of this tactic. CISA recently published Alert AA21-131A, detailing threat actors distributing the DarkSide ransomware; the actors also make use of legitimate RDP services. For more on how RDP can leave your environment exposed, see these blogs by Duo and ZScaler.
By enabling the RDP Inference package on a Corelight sensor, customers can quickly access many new capabilities and insights around RDP traffic. These new features are briefly outlined below. If you’re a customer and would like a more detailed look at the feature set, see the Corelight sensor documentation.
It’s important to note that these inferences only work when RDP is transferred over TLS, regardless whether the RDP server was configured to use Network Level Authentication (NLA) or not. When used in combination with JA3 fingerprints these inferences can be a force multiplier. For RDP that uses no encryption, or the protocol’s native encryption scheme of RC4, which has long been discouraged, we’ve incorporated the rdfp fingerprinting technique. More on that later. First, let’s jump into the RDP-over-TLS inferences.
The following are some categories and example types of the authentication and client inferences that will be present in a newly added field, inferences, of the RDP log if present during an RDP connection:
Authentication inferences – A set of identifications for types of authentication which do not require a client to successfully authenticate. These inferences provide an inferred authentication result as well the inferred authentication method such as a Kerberos ticket, a password, or an NTLM hash (such as the case with Restricted Admin Mode).
Client inferences – A set of identifications of specific RDP clients or attack tools which do require a client to successfully authenticate, as they are based on how the client behaves during and immediately after authentication. Client inferences can identify SharpRDP, The Metasploit Framework, Hydra, rdpscan, and others.
In addition to inference tags, the RDP log format has been extended to include the following new fields:
rdfp_hash and rdfp_string – As previously mentioned, we incorporated the rdfp fingerprinting technique into the package as a handy dual to the TLS-based inferences we developed. These fields will only be set if a connection uses RC4, also referred to as native or standard encryption. The rdfp fingerprinting technique was first implemented by Adel Karimi, now a security engineer at Google, and the rdfp Zeek script was originally released by Jeff Atkinson, now a principal security engineer at Verizon Media. Big thanks go to Adel, Jeff, and anyone else involved in the creation of rdfp.channel_joins – This is different from the existing client_channels log field, which records the channels which are negotiated in the clear and are directly observed. The number of channels joined during the Channel Connection stage of the Connection Sequence is not directly observable, as the messages are sent over TLS, and are instead inferred. Channels are used for emulating things like clipboards, serial ports, printers, plug and play (PnP) devices, and more. RDP supports a maximum of 32 channels; the Bluekeep vulnerability works by requesting a server to bind to the “MS_T120” channel.rdpeudp_uid – This field will be set with the unique connection identifier of the RDPEUDP connection, the UDP counterpart to the TCP-based RDPBCGR, if one was used. If you’re interested in more on the RDPEUDP, see this blog to understand the process of writing an analyzer for the protocol.auth_success – This is a boolean field, and is similar to the field in Zeek’s SSH Info record. If the client authenticated successfully to the server then this field is set to true, otherwise it is false. To learn more about how this inference works, see the resources from the 2020 Zeek Week CTF, specifically the rdp-auth challenge’s pcap.In addition to the inferences and new log fields, the package comes with new notice types which highlight bruteforcing attacks (including tracking success) and anomalous channel usage.
The following video demonstrates the package’s ability to infer the authentication result and method of authentication for an RDP connection:
The video below shows an experimental prototype feature, not yet available in the package, which is capable of identifying human-driven mouse movements:
The inferences included in this package are built using similar concepts as the SSH Inference package. By analyzing connections’ sequences of lengths and inter-arrival deltas (SOLIDs) and applying domain specific knowledge about how RDP behaves on live networks at scale, Corelight Labs is able to provide similar inferences. The following section describes some of the exploratory experiments Corelight Labs conducted to understand RDP in great depth.
To better understand what RDPBCGR connections look like as sequences of lengths, we collect the first 75 TLS record lengths of just over 2,300 RDPBCGR connections. In figure 1, below, each line represents a single connection and is made slightly transparent so overlapping lines become apparent. Along the y-axis there are dotted vertical lines which indicate the index of the message in the connection. Positive values along the x-axis are message lengths sent by the originator of the connection. Negative values indicate message lengths sent by the responder. Some interesting visual patterns are: the range of positive values at index 2, the lack of variance in indices 10 through 17, and the ceiling of positive values which begins around index 28.
To better understand how keystrokes manifest within RDP connections, we studied the different types of Input Event PDUs. In figure 2 below, we compare connections’ time series of only the originator endpoints of four RDPBCGR connections, two that transmitted keystrokes generated by humans and two that transmitted keystrokes generated by the SharpRDP tool. The time series only includes messages sent by the originator of the connection after RDPBCGR’s Connection Sequence completed.
To explore how RDPEUDP messages manifest, we synthesized a set of pcap files containing RDP sessions which used both TCP and UDP for transport. The optional Multitransport Bootstrapping stage of the RDPBCGR Connection Sequence negotiates the use of UDP. Figures 3 and 4, below, compare RDPEUDP message lengths. The lengths were extracted from our pcaps by using Zeek’s open source RDPEUDP analyzer. The x-axis of the graphs is the message index while the y-axis represents the length and sender of the UDP datagram. These figures do not include RDPBCGR messages.
One immediate observation is that Socks Over UDP is quite noisy. RDPEUDP is used to transport Dynamic Virtual Channels and when those channels are used to implement a SOCKS proxy that UDP connection stands out compared to other uses of those channels.
Corelight sees the RDP Inference package as a perfect complement to our SSH Inference package, as both provide additional analyses on encrypted protocols often used for remote access and lateral movement. Corelight is releasing the RDP Inference package to customers as part of our Encrypted Traffic Collection.
How frequently is RDP being used on your network? Are the connections long-lived or short? What’s the primary method of authentication for your RDP connections?
Do you want to know more about the existing RDP traffic on your network? If so, Corelight can provide you with the insights outlined above.