Adversaries may use Valid Accounts to log into a computer using the Remote Desktop Protocol (RDP). The adversary may then perform actions as the logged-on user.
Remote desktop is a common feature in operating systems. It allows a user to log into an interactive session with a system desktop graphical user interface on a remote system. Microsoft refers to its implementation of the Remote Desktop Protocol (RDP) as Remote Desktop Services (RDS).
Adversaries may connect to a remote system over RDP/RDS to expand access if the service is enabled and allows access to accounts with known credentials. Adversaries will likely use Credential Access techniques to acquire credentials to use with RDP. Adversaries may also use RDP in conjunction with the Accessibility Features technique for Persistence.
Detection Profile
Triggers
- A host connects to an internal RDP server with a keyboard layout or a product ID different than the one usually seen in conjunction with the specified RDP client token
- A host connects to an internal RDP server with a keyboard layout that is unusual for that RDP server
- A host connects to an internal RDP server with a keyboard layout that is different from those usually seen on the network
Possible Root Causes
- An external foreign attacker who has taken over control of an internal host is using it with unusual keyboard layouts to connect to RDP servers to move laterally in the network
- An external attacker who has taken over control of an internal host has brought along their own RDP stack and is using it to connect to internal RDP servers to move laterally in the network
- An employee has switched to their native keyboard layout while accessing an RDP server
- An employee has installed a new RDP client with a new product ID and is accessing an RDP server
Business Impact
- Along with SSH, RDP is one of the most useful lateral movement protocols for attackers as it allows remote control of the target as well as the copying of files across the connection
- This type of control and data acquisition may happen well in advance of actual exfiltration attempts and represents a great chance to head off attacks before any substantial damage occurs
Steps to Verify
- For keyboard layout anomalies, inquire whether the user of the internal host is fluent in the language of the flagged keyboard layout
- For an RDP product id anomaly, inquire whether IT has installed new RDP client software or ask the user of the host whether they have done so
Example of a Suspicious Remote Desktop Protocol Session
Vectra Recall tracks and parses all RDP sessions that are seen on the network. In Vectra Recall, open the saved search “RDP Table view”, you will see a list of recent RDP sessions with the most common fields of interest will be listed. You should look to exclude sessions which are expected for your organisation to find any suspicious instances, for example you might want to exclude jump servers or system admins who typically leverage RDP for their dayto-day operations.
A good place to start is to look at the keyboard_layout in use in RDP connections. Commonly, this information is encrypted. If you search by:
NOT keyboard_layout: “encrypted RDP keyboard”
You will see all unencrypted keyboard layouts, look through these, and see if any keyboard layouts don’t align with where your normal users are based. If you are an American organisation, and spot a French keyboard layout, that could be suspicious.
You could also look for abnormal desktop screen sizes, which can be symptomatic of malicious actors masquerading as normal users. But first you need to remove encrypted communications, where the screen size will be shown as 0 with this search:
NOT desktop_height: 0 AND NOT desktop_width: 0
You will see the request dimensions for any remaining values. Values which do not represent standard screen sizes (1280 x 720 etc.) are suspicious and may warrant further investigation.
Finally, you could look to see if any RDP requests were made from external locations. External sources should not be able to make requests against internal instances. To find these requests, search for:
NOT local_orig: “true”
For each item listed here, check and see if the IP is from a known, safe, subnet, check what machine is being RDP’d to, and check the cookie that was used to log in, these will indicate if a connection warrants further investigation.
In a recent investigation RDP data came to be a very handy source of evidence, RDP sessions inherited whatever the source systems details are (hostname, keyboard layout, screensize etc). Leveraging this we can look for unusual hostnames leveraging RDP on our network, would you expect a guest device to RDP? If your organisation uses clear precise naming convention for hosts we can filter out the expected hosts and look for unusual hosts.
For example leveraging the following query we’ll find any clients with default hostnames initiating RDP sessions, can you account for these clients?
client_name:DESKTOP-* OR client_name:WIN-*
We’ve found this to be a very good indicator in several customer environments while hunting for suspicious sessions.