For IT staff and Windows power users, Microsoft Terminal Services Remote Desktop Protocol (RDP) is a beneficial tool that allows for the interactive use or administration of a remote Windows system. However, Mandiant consultants have also observed threat actors using RDP, with compromised domain credentials, to move laterally across networks with limited segmentation.
To understand how threat actors take advantage of RDP, consider the following example (and Figure 1):
Figure 1: Example of a compromise that uses RDP for lateral movement
A best practice used to identify this type of activity is network baselining. To do this, an organization must first understand what is normal behavior for their specific environment, and then begin to configure detections based on unexpected patterns. Sample questions that can help determine practical detection techniques based on the aforementioned scenario include:
While it can take time to develop a customized process to baseline the scope of user accounts, source systems – and destination systems that leverage RDP in your organization’s environment – normalizing and reviewing this data will empower your staff with a deeper understanding of user account behavior, and the ability to detect unexpected activity to quickly begin investigating and triaging.
One first step and important resource for identifying your network’s typical behavior is through the use of event logs. RDP logons can generate file, event log, and registry artifacts on both the source and destination systems involved. Page 42 of JPCERT’s reference, “Detecting Lateral Movement through Tracking Event Logs,” details many artifacts that investigators may find on source and destination systems.
For the purpose of scalability, our baselining approach will focus on three high-fidelity logon events recorded on a destination system:
The EID 21 entry shown in Figure 2 is created on a destination system when a successful interactive local or remote logon event occurs.
Figure 2: EID 21 Example Structure
The EID 25 entry shown in Figure 3 is created on a destination system that has been reconnected from a system that previously established an RDP session that was not terminated through a proper user logout. For example, closing the RDP window (which would generate EID 24), as opposed to logging off through the start menu (which would generate EID 23).
Figure 3: EID 25 Example Structure
The EID 4624 entry is created on a destination system when a logon of any type occurs. For evidence of RDP authentication, we will focus on EID 4624 entries with with Logon Type 10 as shown in Figure 4, which correspond to RDP authentications.
Figure 4: Type 10 EID 4624 Example Structure
These event log entries provide evidence of a successful RDP authentication from one system to another. For most security teams to collect this event log data, the logs must either be forwarded to an aggregation platform, such as a security information and event management (SIEM) platform, or collected using a forensic acquisition utility such as FireEye’s Endpoint Security (HX) appliance. Once extracted, the data must be processed and stacked for frequency analysis. The scope of this post is to generate metrics based on unique user accounts, source systems, and destination systems.
For both EID 21 and EID 25, the user account and source system are captured in the event log strings, while the destination system is the system that recorded the event. Note that the “Source Network Address” recorded within the log may be either a hostname or an IP address. Your data processor may benefit from mapping IP addresses and hostnames together, while keeping Dynamic Host Configuration Protocol (DHCP) leases in mind. Understanding which systems correlate to specific user accounts or business units will greatly benefit the analysis of the processed results. If your organization does not track this information, you should request for this documentation to be created or captured within an asset management database for automated correlation.
Once RDP activity is baselined across your environment via the analysis of event logs, security analysts can then begin to identify RDP activity that deviates from business requirements and normalized patterns. Keep in mind that distinguishing between legitimate and anomalous RDP activity may take time.
Not only will DHCP logs prove useful when mapping IP address to hostnames, but documentation that associates systems and user accounts with specific business units can also help with reviewing and correlating observed RDP activity for suspicious or benign behavior. Any RDP activity inconsistent with expected business practices should be investigated. Additionally, RDP logons confirmed as benign should be noted in the baseline for future investigators.
By using SIEM correlation techniques, analysts can stack RDP activity by account, source system, and destination system, to pinpoint the number/count of the following metrics-related elements, which will deepen the security staff’s understanding of RDP activity in your network:
This list of metrics is not exhaustive and can be expanded by including timestamp metadata if desired.
While baselining RDP activity may not readily identify threat actors who do not utilize this technique, or who take extra steps to blend in with legitimate user activity, it will continually help analysts better understand what normal behavior looks like in their specific environments – and could ultimately identify anomalies or potential indicators of unauthorized activity.
The following recommendations can help maximize the effectiveness of your RDP baselining exercises, while also reducing the opportunities for RDP to be leveraged for malicious actors within your environment: