Unraveling the clues: RDP artifacts in incident response

Remote Desktop Protocol (RDP) is a powerful tool for remote administration, but it can also be a gateway for attackers seeking unauthorized access. For digital forensics professionals, RDP artifacts are critical in tracing an intruder’s steps.  

In this blog, we will explore what RDP digital artifacts entail, where they are located, how they can be interpreted, and illustrate their use in an incident response case example. 

Understanding RDP artifacts 

What do RDP artifacts contain? 

RDP artifacts can provide a wealth of information, including session details such as: 

  • Usernames 
  • Machine names 
  • IP addresses 
  • Timestamps of RDP logins 

Where are RDP artifacts located on the endpoint receiving an RDP connection?

RDP artifacts are crucial for digital forensic investigations as they provide insights into the usage and security of RDP sessions. These artifacts are stored in various locations within the Windows operating system. Here’s an enhanced look at where to find these artifacts, including additional Event IDs:

Event Logs

Event Logs in Windows are pivotal in recording RDP session activities, which include user logins, system events, and session-specific actions:

  • Security Logs:
    • Event ID 4624: Logs successful account logon events, a key indicator of a session start. Remote Desktop events will be identified as “Type 10,” distinguishing it from other logon events like ‘Interactive’ (Type 2), ‘Network’ (Type 3), ‘Service’ (Type 5) and others.
    • Critical information from this Event ID includes originating IP and Login Username:
  • Event ID 4625: Logs failed login attempts, which can be useful for detecting unauthorized access attempts.
    • Event ID 4778 and 4779: Track session reconnections and disconnections, providing insights into session stability and user activity.
    • In these Event IDs, you can identify the username and originating IP of the incoming system:
  • RemoteDesktopServices-RdpCoreTS Logs:
    • Event ID 131: A server accepted a new TCP connection from a client
    • Includes incoming IP address
  • Event ID 98: A TCP Connection has been successfully established
  • Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx Logs:
    • Event ID 1149: Indicates user authentication, capturing the username and the IP address of the connecting client
  • Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx Logs:
    • Event ID 24: Recorded when a session is disconnected from the client side.
    • Event ID 25: Indicates when a session is reconnected.
    • These also provide username and originating IP address

Prefetch/ShimCache Files

Prefetch and ShimCache files can reveal the execution of important RDP-related executables, indicating user activity and potential administrative actions:

  • RDPClip.exe: Manages clipboard sharing during RDP sessions. Execution traces can be important for data transfer investigations.  From the ShimCache:
  • Evidence of activity of rdpclip.exe can also be contained in the SRUM application resource usage artifact for example, we see activity captured here:
  • TStheme.exe: Handles theme applications on remote desktops, with execution traces showing changes made during the session.
  • From the Prefetch artifact:

Case example: incident response using RDP artifacts

In response to suspicious RDP activity detected at a corporate network, a digital forensic investigation was launched, focusing on the destination endpoint—the server receiving the RDP connections. Below is a detailed narrative that guides through the investigative steps taken to uncover the details of the breach.

Step 1: Collecting and analyzing event logs

The first step in our investigation involved gathering and scrutinizing the Windows Event Logs from the affected server to construct a timeline and context for the RDP sessions involved in the incident.

  • Security Logs:
    • Event ID 4624 (Successful Logins): We filtered the logs for logon type 10 entries, indicating successful remote desktop logins. Each entry was examined for user accounts involved, source IP addresses, and timestamps of the logins.
    • Event ID 4625 (Failed Login Attempts): These logs were crucial for identifying brute-force attempts or other unauthorized access attempts. Analyzing these failures helped infer potential attackers’ methods by examining frequency and origin.
    • Event ID 4778 and 4779 (Session Reconnections and Disconnections): Insights into session stability and persistence were gained here, highlighting any unusual patterns that could suggest session hijacking or other malicious activities.
  • TerminalServices-RemoteConnectionManager Logs:
    • Event IDs 21 and 22 (New Local Session): Event ID 21 “Session logon succeeded” is frequently followed by an Event ID 22 “Shell Start Notification”.  These Event IDs are triggered when a user successfully authenticates for a local or remote interactive login and does not already have an existing local session.We reviewed these logs for any administrative shadowing, which could indicate internal misuse or post-incident investigative actions.
    • Event ID 1149 (Authenticated User Information): Confirmed identities of users who successfully authenticated, aiding in distinguishing legitimate actions from those involving compromised credentials.
    • Event ID 24 (Session Disconnections): This event provided details on when and how RDP sessions were disconnected, crucial for understanding if disconnections were user-initiated or caused by network issues or potential external interventions.
    • Event ID 25 (Session Reconnections): Analysis of these logs helped identify any sessions that were unexpectedly resumed, which could be a sign of an attacker attempting to maintain persistence within the network.

Step 2: Examining registry settings

We delved into the server’s registry settings to check for any anomalies or exploitable configurations:

  • TSAppAllowList: Located under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal Server, this registry key lists applications permitted through RDP sessions. We scrutinized this list to detect any unusual or unauthorized applications that might facilitate unauthorized actions or data exfiltration.

Step 3: Forensic analysis of network traffic

With a focus on the network traffic logs, we searched for anomalies in RDP traffic patterns:

  • Network traffic logs: We analyzed the network traffic by examining data from the SRUM artifact, focusing on session timings related to RDP traffic. Large data transfers or sessions occurring at unusual times (e.g., late nights or weekends) were flagged for further analysis as potential indicators of data exfiltration or other malicious activities.

Resolution of the investigation

The comprehensive examination of the collected data revealed that an external attacker had gained access to the network using compromised employee credentials. The security logs, registry settings, and network traffic analysis pointed towards unauthorized access and potential data exfiltration activities.

By piecing together the timeline and methods used by the attacker, we implemented several remedial measures:

  • Credential reset: Immediate reset of compromised credentials and strengthening of password policies.
  • Network security enhancements: Review and enhancement of network defenses, including better monitoring of RDP sessions and restrictions on allowed applications.
  • Incident response plan update: Updating the incident response plans to incorporate lessons from this incident to better respond to similar future threats.

The timely analysis and detailed investigative approach not only helped us understand the breach but also fortified the organization’s defenses against similar future attacks, enhancing its overall security posture.

Artifacts found on the initiating endpoint

In the previous example, we only had access to the endpoint that received the RDP connection.  However, you may have access to the endpoint that initiated the RDP session.  The number of artifacts available in this scenario is much greater.  These artifacts can help reconstruct user actions and validate the sequence of events leading to, during, and following an RDP session. Here’s an overview of the relevant artifacts found on the client side:

Event Logs

  • Event ID 4648: A logon attempt using explicit credentials. This event indicates that a user is attempting to use explicit credentials to authenticate to a remote system, which is commonly seen in RDP scenarios.  From this Event, we can see items that include:
    • Current logged on User Name
    • Destination Host Name
    • Attempted logon username
  • From this data, we can see that the originating endpoint was logged in by “James.Arden” on the domain “HMNET”.  We can see that the destination endpoint is “147” in the domain “OURNET” and that the login is attempted with the username “student”. 
  • Event ID 1024: This event typically indicates the successful initialization of an RDP client connection. It logs when the RDP client has successfully connected to the RDP server, essentially marking the establishment of the session from the client’s perspective.  It can contain valuable information, such as the destination host name. 
  • Event ID 1102: This event occurs after a successful RDP client connection and will provide the destination IP address.

Registry entries

  • NTUSERSoftwareMicrosoftTerminal Server ClientServers: This registry path contains entries for each remote server to which a user connects using RDP, storing the IP addresses or hostnames. This can be crucial for identifying the targets of RDP sessions. Here we see the information parsed from the Registry in Magnet Axiom Cyber:

Windows artifacts

  • ShimCache (AppCompatCache): Provides a list of executables that were run on the system, including mstsc.exe, which could prove that the RDP client was launched.
  • AmCache: Stores records about executables based on file path and last execution time, useful for showing when mstsc.exe was last used.
  • UserAssist: Tracks files and applications opened via the GUI, which could include mstsc.exe if it was launched from a graphical interface.
  • Jump Lists: Maintains a list of recently accessed or frequently used files and applications, including those accessed via RDP.
  • This particular artifact provided a wealth of information. We see the destination IP as an argument, we see the last accessed date/time, and finally, we see the target NetBIOS name. 

File system artifacts

  • Prefetch: Prefetch files such as those associated with mstsc.exe (the RDP client) can provide information on the number of times an application was run and the last run time.
  • Bitmap cache: Located at %LOCALAPPDATA%MicrosoftTerminal Server ClientCache, these files store the bitmap images to improve the performance of graphical elements during RDP sessions. Forensic examination of these files can reveal graphical data from the remote session, potentially reconstructing activities or views from the RDP session.

RDP artifacts: key to effective incident response

RDP artifacts are a goldmine of information in digital forensics. Understanding where to find these artifacts and how to interpret them can be crucial in incident response. As demonstrated in the case example, effective use of digital forensic techniques can help quickly resolve security incidents and strengthen cybersecurity measures. This exploration underscores the importance of thorough monitoring and analysis of remote access protocols, reminding us of the ever-present need for robust security practices in the digital age.

The post Unraveling the clues: RDP artifacts in incident response  appeared first on Magnet Forensics.

Share:

More Posts