Remote Desktop Application vs MSTSC Forensics: The RDP Artifacts You Might Be Missing

Many threat actors utilize Remote Desktop Protocol (RDP) to move laterally within an environment once they have compromised it. There has been quite a bit of documentation around forensic artifacts associated with the Microsoft MSTSC client which has been around since 1998. However, there is also a Microsoft Remote Desktop App that is available in the Microsoft store.

There are several forensic artifacts that incident responders utilize when looking for RDP activity, such as: 

• Event logs 
• Registry hives 
• Jump Lists 

If threat actors are using the Microsoft store version of the application to conduct lateral movement, some forensic artifacts related to this app are NOT stored in the locations where examiners normally look. Most notably, Jump List entries and the RDP Hint registry entries are not created. Examiners also get some additional forensic artifacts to review, such as thumbnail images and RDP-specific Windows Event Trace Logs (ETL).

We’ll start with the two places where an examiner might expect to find RDP activity: the Jump Lists and the RDP Hint registry key.

No RDP Hints

The RDP Hint registry key, located in the user’s ntuser.dat hive, can contain systems where a user connected via RDP when using the MSTSC client. An example of this registry entry is shown below with two systems the user connected to:

When using the Microsoft Remote Desktop app to connect to these systems, an entry is not made in the RDP Hint registry key.

Jump List Entries

When the older MSTSC client is used, a Jump List entry is created that contains the systems and the time where the user connected to. Here’s an example of an MSTSC Jump List parsed with Eric Zimmerman’s jlecmd.exe tool with the relevant information highlighted:

When using the Remote Desktop App to connect into systems, testing indicates there is no Jump List created for the application. However, we can see what looks like a Jump List for the application:

So where does this information reside if  no Jump List is created? The Remote Desktop application data is stored in the packages directory under the user’s folder:

%LOCALAPPDATA%\Local\Packages\Microsoft.RemoteDesktop_8wekyb3d8bbwe.

The Jump List entries for the Remote Desktop app are located in a subfolder named “\LocalState\RemoteDesktopData\JumpListConnectionArgs.” This folder contains a .model file for each system where the user connected.

The created date corresponds to the first time a user made a connection, and the modified date corresponds to the last date a user connected.

Each .model file is an XML file that contains various fields. Some fields of note are as follows:

• a:Description: system connected to by user
• a:LastLaunch: time of last successful connection
• a:DisplayName: “Friendly name” given by the user for the system.
• a:ConnectionId: a unique value that will correspond to other forensic artifacts

Thumbnails

The Microsoft Remote Desktop App contains thumbnails of what was on the screen when the user last disconnected. This may be useful to see what directories a threat actor had on the screen, or even what tools the threat actor was running while logged in. Below is a screenshot of how the Remote Desktop application uses these thumbnails when presenting the previous RDP sessions to the user. Note the use of a friendly name for each session:

These thumbnails are stored in the subfolder: \LocalState\RemoteDesktopData\RemoteResourceThumbnails.

The file names have the format <connection_id>.model, where connection_id can be mapped back to the corresponding Jump List model file via the <a:ConnectionId> field.

This xml file contains a field called <a:EncodedThumbnail> which contains a base64 encoded value that decodes to a jpg image.

Using a site like CyberChef,  this can be easily decoded to a JPEG image. Although the image is small, the decoded example below the image shows a network scanning tool that was left to run in the background:

RDP Event Trace Log

In addition to the typical RDP event log entries, the Microsoft Remote Desktop App stores application-specific Windows Event Trace Logs (ETL) may contain additional information for analysis. These files are located in the subfolder named “\LocalState\Logs” and contain an event trace log for each time the application is launched.

The built in Windows tool tracerpt can be used to parse the ETL files. 

The ETL files can contain information for multiple connections made during the session. The username used to log in to the remote computer and the remote computer name were located in the ETL files. Note that the IP address is stored in the other forensic artifacts. Having the computer name may assist an examiner,, especially if DHCP is in use and the IP address may change over time. Filtering for these two fields in the parsed ETL file in the “user” column will help locate relevant entries:

• "InternalConnectionStateManager::OnLoginCompleted()"
•  "RemoteDesktopConnection::Close()"

The Clock-Time is stored in Windows Filetime format and initial testing indicates these times correlate to when the remote login started and when the connection was closed. An example of a log is shown below (note that not all fields are shown):

Credentials

If the user elects to have their credentials saved for future connections, the username and PasswordVaultResourceID value are stored in a .model file under “\LocalState\RemoteDesktopData\credentials.”

The PasswordVaultResourceID can be used to locate the credentials and password in the Windows Credential manager under Web Credentials:

Connections

The folder named “\LocalState\RemoteDesktopData\LocalWorkspace\connections” contains  a <connection_id>.model file for each connection established. Once again, the connection ID can be used to correlate the Jump List and thumbnail artifacts. These files contain settings such as the resolution, scale, friendly name, and hostname connected to.

Reviewing Application-Specific Locations

This post was a walkthrough of some forensic artifacts related to RDP that may not be in traditional locations that incident responders check. As more applications start migrating to the Microsoft store or using packing technologies like MSIX, reviewing application-specific locations will become important, especially since some long standing forensic artifact locations are no longer capturing some of the threat actor activity.

Your Partner in Digital Forensics and Incident Response

In today’s world,  if you’re a victim of a cyber attack, it’s critical to have experienced and qualified experts ready to spring into action. With rapid, efficient response times, best-in-class threat intelligence, and more than 20 years of combined expertise managing and responding to incidents, ZeroFox is the  trusted partner in digital forensics and incident response. 

Learn more and talk to our response team today.

Tags: Breaches, Incident Response