Cache Me If You Can: Uncovering Clues in Bitmap Forensics

Introduction

During incident response, investigators rely on a well-established set of forensic artifacts, data sources, and Endpoint Detection and Response (“EDR”) telemetry to triage hosts for signs of threat actor activity. Once a host is identified as compromised, its timeline of threat actor activity can act as a guide for performing deeper analysis. Beyond its primary purpose of establishing what occurred during an incident, the host timeline also helps investigators determine when to perform deeper analysis of additional forensic artifacts, particularly those that are impractical to examine across all hosts or are circumstantial but can provide key insights when relevant. Creating an initial host timeline is like reading through a book and uncovering the main storyline and key plot points. But sometimes, the real insights live in the margin notes with their subtle details that expose what the writer was really thinking. These specialized artifacts are those margin notes, easily missed, but potentially deeply revealing with new context or brand-new information.

In this post, we’re digging into one of these specialized artifacts – the RDP bitmap cache. We’ll break down what it is, why it matters, and share some of the most compelling real-world examples we’ve encountered from cases. As we experienced, when anti-forensic techniques have been deployed and other sources of evidence have rotated, or even a system has become entirely unavailable, a deeper dive into specialized artifacts is required to locate key information for a case.

The host timeline provides the essential structure of an investigation, showing what happened and when. But to uncover additional details, or sometimes new key findings, you often need to examine more specialized forensic artifacts. While these artifacts aren't practical to collect from every host, they can yield decisive insights when examined in the right context.

RDP Bitmap Cache Background

The Remote Desktop Protocol (“RDP”) allows a user to remotely connect to a Windows-based computer over a network connection, providing a graphical interface as if they were sitting in front of the remote machine. Developed by Microsoft, RDP is included by default on all Windows editions except Home, making it a commonly used service for both legitimate IT administration and lateral movement by threat actors.

RDP bitmap caching is a feature of the Remote Desktop Protocol (RDP) that stores images of parts of the screen, called bitmaps, on the client machine to improve performance during remote sessions. The Persistent bitmap caching setting for the RDP client on Windows is enabled by default, which saves this cache on disk rather than only memory.

The Bitmap cache is located at the following path for Windows Vista\Server 2008 (both original and R2) or newer systems:

C:\Users\[UserName]\AppData\Local\Microsoft\Terminal Server Client\Cache

If you happen to find yourself examining a Windows XP or Server 2003 system, they are located at:

C:\Documents and Settings\[UserName]\Local Settings\Application Data\Microsoft\Terminal Server Client\Cache

Within this folder, you'll find two types of files: bitmap cache files with the .bmc extension that begin with “bcache”, and binary files with the .bin extension that begin with “Cache”. On older systems like Windows Vista and Windows Server 2008 (non-R2), bitmap cache files use the .bmc format and typically end in 2, 22, or 24, reflecting bitmap quality levels. On Windows 7 and later, these were replaced with .bin files Cache0000 through Cache0005

Now it’s onto the actual processing of these files, which involves extracting the bitmap images contained within them. A popular tool of choice for this step is bmc-tools, created by the French National Cybersecurity Agency (“ANSSI”). Both RDP bitmap cache file types are supported by this tool, which extracts images from both types of bitmap files in a destination folder into a target output folder.

In your designated output folder, you’ll find the extracted bitmap tiles, each named according to the cache file they originated from.

bmc-tools also provide a -b (-bitmap) switch that generates a collage of all the tiles based on their order in the cache which is a great way to quickly gain an understanding of what activities are contained in it and if it is worth exploring further.

For reassembling the extracted title images back into as complete as possible pictures, we utilize the tool RdpCacheStitcher created by the German Federal Office for Information Security. This tool loads in all bitmap images inside a specified directory, making it seamless to ingest the output of bmc-tools into it. Within the application you have a tiled main section in which you can reassemble images as much as possible with the imported bitmap tile images. While there is an “Autoplace” button that isn’t meant to be perfect, the suggestion feature makes it easy to quickly run through potential matching tiles looking for a perfect match.

Before we move on to examples of recovered images from actual cases, it's important to first discuss the types of forensic evidence that help determine whether a specific RDP bitmap cache is relevant to an investigation. This ties back to the opening point about using the host timeline as a guidepost for deeper forensic analysis.

The forensic artifacts we review for RDP lateral movement, in tandem with the last modified time of any cache files present, act as the guide for locating potentially relevant caches to review.  On the client, recent RDP activity for user accounts can be found in the Default and Servers subkeys under HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client. The Windows event log Microsoft-Windows-TerminalServices-RDPClient/Operational log provides the event IDs 1102 and 1104 for attempted outbound RDP connections.

For the server side of RDP connections, there are many well-documented Windows Event Logs related to inbound RDP activity, including the well-established 4624 Type 10 logon event in the Security log, as well as events from the TerminalServices-RemoteConnectionManager and TerminalServices-LocalSessionManagerlogs.

These overlapping evidence sets from both the client and server are essential to combat against anti-forensics and log rotation, ensuring relevant RDP bitmap caches aren’t missed. However, the last modified timestamp for cache files for compromised accounts can also be reviewed as a failsafe to ensure any potentially relevant RDP caches have not been missed for analysis.

With the stage now set with the technological background and methodology, let’s explore why this artifact can be so impactful with real-world examples.

Example 1 – RansomHub readme.txt

We begin with a “readme.txt” text file related to a variant of the RansomHub ransomware family that was used by a threat actor. It contains instructions on deploying ransomware, with a great reminder of “!!! Don’t let the victim see this text !!!”.

Not only does this provide some very interesting insight into the approach taken by the threat actors for deployment, but it also details the parameter options for their ransomware program.

Also recovered from this same RDP cache was an image showing the ransomware running in “Global” mode, which matches up with them having the command for this mode highlighted for copying in the “readme.txt” image.

Example 2 – Anti-Forensics

The second set of recovered RDP bitmap cache images includes two examples, from separate cases, showing threat actors conducting anti-forensic activity on compromised hosts.

The recovered images show anti-forensics commands in a Windows PowerShell window and the Windows PowerShell Integrated Studio Environment (ISE), both running at the administrator level. These extensive collections of commands clear out forensic artifacts across files, the Windows Registry, and Windows Event Logs.

The clearing of the Terminal Server Client registry keys and Windows Event Logs in this example highlight how it is still worthwhile comparing the last modified time of the bitmap cache files for accounts used by a threat actor on a host, even if it appears that outbound RDP didn’t originate from it. This process is what led to us reviewing this particular bitmap cache and recovering these images for the first image in this set. This information that was only available from the bitmap cache for each of these cases shows a very interesting overlap between two different threat actors.

Example 3 – Persistence and Credential Access

Our third example set of images starts with the threat actor achieving persistence with a scheduled task named “System” and a Windows DLL file named “dede.dll”.  The threat actor first ensured that a scheduled task of this name didn’t already exist and then manually launched the scheduled tasks after its creation.  

The next two images were reassembled along with two accompanying tiles that show the threat actor generating a copy of the Active Directory database file “ntds.dit” and the Windows registry files needed to decrypt it. They did this using a misleading but valid folder name of “123.txt” that they compressed into “123.txt.zip”. This is a great example of using all available context from an RDP bitmap cache to reconstruct what occurred, as a perfect picture is rarely available.

Example 4 – Stealthy LSASS Extraction

Our final example comes from an investigation where standard triage across hosts showed no clear evidence of unauthorized access. The threat actor had entered through the VPN and logged into a host using an account that regularly connected in that manner. Logs and artifacts had already rotated by the time our investigation began.

After connecting to the initial host, the threat actor moved laterally within the environment, using another account that routinely accessed the second system via RDP.

Some initial suspicious indicators were present on the initial host. Network mapping tools were commonly used on this host, however, the use of a somewhat recently downloaded network tool stood out. The RDP cache was pulled, and as soon as “lsass” and “Dump File” were seen during my initial cursory run through of the extracted images we knew this evidence set was going to be the smoking gun for threat actor activity.

In the initial image from this set, we see the contents of the Local Security Authority Subsystem Service “lsass.exe” process being written to a file using Windows Task Manager. By living off the land with the built-in Windows Task Manager, the threat actor avoided leaving behind execution artifacts tied to overtly suspicious programs. Based on the extracted RDP cache tiles with clear alignment, this image also includes the website sendspace[.]com open in the background behind task manager.

The next set of images confirms more details about the created file, including its name “lsass.DMP”, its modification timestamp at the time of its deletion, and its file size of 63.5 MB.

And the final set of images from this cache shows that the “lsass.DMP” file was uploaded to the file hosting website “sendspace[.]com” for exfiltration by the threat actor. This group of images is another great example of working with the context provided by the available tiles to create a set of images that tell a clear story. The single tile of “ass.DMP” unfortunately did not have a connecting tile, but it’s clear this was “lsass.DMP” above the upload progress bar for “sendspace[.]com”. In addition, the “Uploaded 53MB of 64MB” text matches the confirmed file size of the “lsass.DMP” file.

Conclusion

These examples demonstrate that RDP bitmap cache artifacts can surface meaningful forensic evidence even when traditional logs are missing or tampered with. Whether it’s uncovering ransomware deployment details, anti-forensic efforts, or credential dumping, these artifacts can preserve a visual narrative that’s otherwise difficult to reconstruct.

‍