April 12, 2023 HAWKEYE

Threat Hunting Unauthorized RDP Post-Exploitation

Users of Microsoft Windows systems can access a remote desktop on systems remotely to administer one or more workstations and/or servers using the Remote Desktop Protocol (RDP).


The adoption of RDP via the internet has expanded along with the rise in the number of businesses choosing remote work. To be used securely over the internet, RDP did not come with the security and privacy features that are now required. RDP uses the well-known port 3389 for communication, making it particularly accessible to malicious threat actors. In addition, the username and password combination is all that is required by default for authentication.

The risks to enterprises that use RDP that are exposed to the internet are greatly increased by the shortcomings of the authentication systems for RDP. RDP lacks a built-in multi-factor authentication by default (MFA). Organizations must set up a Remote Desktop Gateway or put the RDP server behind an MFA-compatible VPN in order to add MFA to RDP logins. These additional controls, however, come at a cost and with additional complexity that some businesses might not be able to handle.

We’ll talk about threat hunting unauthorized RDP post-exploitation in this blog.

Threat Hunting Steps

  • RDP logs:
    Checking RDP logs for any odd activity is the first step in looking for unauthorized RDP access. Look out for things like failed login attempts, frequent login attempts, or logins from strange IP addresses. These occurrences can suggest that an attacker has attempted to access the system.
  • Event logs:
    The system activity, including RDP sessions, is extensively documented in event logs. Examining these logs can allow one to spot any suspicious activity, such as repeated logons from the same IP address or logons at odd times of the day. You may trace the duration of an RDP session and hunt for unauthorized access attempts by looking through the event logs.
  • Network Traffic:
    Threat hunting requires you to analyze network traffic since it enables you to spot odd activity on your network. Unwanted access attempts can be spotted by examining RDP traffic. Network traffic analysis can also be used to spot odd traffic patterns, like a lot of data being sent to or coming from a certain IP address. Port 3389, the RDP default port, should show network activity. You can record and examine this traffic using network monitoring tools like Wireshark.
  • Unusual processes:
    After an attacker has gained access to a system via RDP, they could put malicious software or other tools on the system to keep themselves there. Check the system for any unusual processes or services that might be signs of infection. To hunt for these processes, utilize applications like Process Explorer or Task Manager.
  • Unusual files:
    Lastly, search the system for unusual files that might point to malicious activity. Attackers could add new files to the system or make new user accounts, for instance. Look for files with odd names or extensions, as these could point to malware.

Threat Hunting Using Logs

Attacks or RDP logons will produce numerous log events in numerous event logs. The target systems where RDP sessions were attempted or finished, or Active Directory where the authentication was handled, will show these occurrences. To generate alerts for RDP activities, these events would need to be gathered into a log management or SIEM solution.

When looking for RDP access, the previously indicated event IDs would be a good place to start. If the target host has RDP logs, an organization will need a method—or a way—to check each workstation and server for these events in the relevant logs or utilize a log management SIEM solution to do searches. Fortunately, the disconnect event will remain in the logs, allowing the investigator to discover the source of the RDP disconnect.

The query logic listed below can be utilized and includes some information about system session authentication.

Event Log = Security
Event ID = 4778 (connect)
Event ID = 4779 (disconnect)
Account Name = The user name logging off
Session Name = RDP-Tcp#3
Client Name
Client Address

Threat actors may erase one or more logs before quitting. If the logs are purged, this disconnect (event ID 24) can be used to narrow searches to the initial access point of the RDP connection.

Event ID: 21 (Remote Desktop Services: Session logon succeeded)

Confirmable Information:
– Session Connection Start Time and Date: Log Date
– Logged in Account Domain and User Name: User
– Connection Source IP Address: Source Network Address

Event ID: 24 (Remote Desktop Services: Session has been disconnected)

Confirmable Information:
– Session Connection Start Time and Date: Log Date of an Event Log with the Same Session ID in Event ID: 21
– Logged in Account Domain and User Name: User
– Connection Source IP Address: Source Network Address

Hunting for Lateral Movement Post RDP Exploitation

  • The process “C:windowsSystem32mstsc.exe,” which is an indicator for a user machine with outbound RDP connections discovered, is contained in Event ID 4648. This can be related to the active traces of lateral movement and can be mapped to MITRE T1076.
  • With the Event ID 4648, the event message contains “*/TERMSRV/*,” which is recognized by an RDP outbound connection from the end user machine. a potential lateral movement detection indicator.
  • Event ID 4648 indicates that the “C:WindowsSystem32sc.exe” process is executing and querying remote machine services. Potential lateral movement detection indicator. This corresponds to the MITRE T1021/T1035.
  • The process “wmic.exe,” which is an indicator of lateral movement with Windows Management Instrumentation, is contained in Event ID 4648. Mitre T1047 can be mapped to this.

Detection from SOC Perspective

To detect exploitation of RDP logins from a SOC perspective using Windows event logs, you can use the following steps:

  • Monitor for failed logon attempts: Monitor Windows Security event logs for Event ID 4625, which indicates a failed logon attempt. You can filter the events to show only logon events by clicking on “Filter Current Log” on the right-hand pane and selecting “Event ID 4625” in the “Event sources” dropdown list. You can look for events with the Logon Type of 10, which indicates a RemoteInteractive (RDP) logon. You can also monitor for multiple failed logon attempts from the same IP address or user account, which may indicate a brute-force attack.
  • Monitor for successful logon attempts: Monitor Windows Security event logs for Event ID 4624, which indicates a successful logon. You can look for events with the Logon Type of 10, which indicates a RemoteInteractive (RDP) logon. You can also monitor for successful logon attempts from unusual IP addresses or user accounts.
  • Monitor for Unusual Login Times: You can monitor for unusual login times by looking for Event ID 4624 and checking the “Logon Time” field. This field indicates the date and time when the RDP session was initiated. You can compare this time against normal business hours to detect suspicious activity.
  • Monitor for logon events from unusual locations: Monitor Windows Security event logs for logon events that occur from unusual locations. You can use the “IpAddress” field in the event logs to identify events that occur from unusual IP addresses.
  • Monitor for changes to RDP-related settings: Monitor Windows System event logs for changes to RDP-related settings. You can look for Event ID 4719, which indicates a change to the audit policy.
  • Monitor for Changes to Account Permissions: You can monitor for changes to account permissions related to RDP logins by looking for Event ID 4732. This event indicates that a user’s permissions have been changed.

By monitoring Windows event logs for RDP-related activities, you can detect potential exploitation of RDP logins from a SOC perspective.

Anomaly Detection in RDP Traffic using Machine Learning

  • The dataset is collected by filtering Windows event logs with event ID 4624 and logon type 10. Will be using the last 60 days’ data to train the model using an unsupervised algorithm.
  • Given this training set, what we would like to do is to carry out the estimation of the probability of p(x). x is a feature vector with values x1, x2, and so on down to xn. Our model for p(x) is going to estimate what is the probability of any given feature vector.
  • Isolation Forest is a machine learning algorithm used for anomaly detection that is particularly suited for high-dimensional datasets. The algorithm works by constructing a binary tree structure in which each internal node represents a partition of the dataset, and each leaf node represents an isolated subset of the dataset. Anomaly points can be detected by identifying data points that require fewer splits to be isolated in a leaf node compared to the majority of the data points.
  • To apply the Isolation Forest algorithm for RDP anomaly detection, we can extract relevant features from RDP traffic data such as:
    o Timestamp
    o Log Source
    o User Source Host
    o Destination Host (Server)
    o Event ID
    o Logon Type
  • Datapoint Distribution Visualization

Datapoint Distribution Visualization

  • During the training phase, the Isolation Forest algorithm randomly selects a subset of features and a random partition point for each feature to create the tree structure. The algorithm then repeats this process to create multiple trees. The anomaly score for each data point is calculated by averaging the path length to isolate the data point across all the trees. Data points with lower average path lengths are considered more anomalous.
  • TSNE Plot for Model Evaluation

TSNE Plot for Model Evaluation

  • In the detection phase, the trained Isolation Forest model can be used to identify RDP traffic that has a high anomaly score. This could potentially indicate unusual or suspicious activity that requires further investigation.
  • One advantage of the Isolation Forest algorithm is that it can handle high-dimensional datasets efficiently, which is particularly useful for analyzing RDP traffic data. Additionally, it does not require any assumptions about the underlying data distribution, making it suitable for detecting anomalies in various types of data.
, , , , ,


We welcome you to contact us for more information
about HAWKEYE - SOC As A Service.