The Suspicious Remote Desktop Protocol (RDP) detection identifies unusual or unauthorized attempts to establish remote desktop connections to internal systems. RDP is commonly used for remote administration, but it is also a frequent target for attackers seeking to gain unauthorized access to network resources. Detecting suspicious RDP activity is crucial to prevent potential security breaches and unauthorized access.
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.
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.
Scenario 1: An internal server receives multiple RDP login attempts from an external IP address during non-business hours. Investigation reveals that an attacker used brute-force attacks to gain unauthorized access.
Scenario 2: A sudden increase in RDP connection attempts from an unfamiliar geographic location is detected. Further analysis indicates that a legitimate third-party vendor was performing scheduled maintenance, causing the detection to trigger.
If this detection indicates a genuine threat, the organization faces significant risks:
Successful unauthorized RDP connections can lead to unauthorized access to sensitive data and critical systems.
Attackers can exfiltrate data, leading to potential financial and reputational damage.
Unauthorized RDP access can be used as a foothold to launch further attacks, including lateral movement, privilege escalation, and deployment of malware.
Examine logs for RDP login attempts, focusing on the frequency, source IP addresses, and times of the attempts.
Determine if the source of the RDP attempts is known and authorized. Check if the IP address belongs to a trusted entity.
Look for other signs of compromise or related suspicious behavior, such as failed login attempts, unusual network traffic, or malware alerts.
Confirm if any authorized remote access activities were scheduled or performed by IT administrators, remote workers, or third-party vendors.