RDP Bitmap Cache Forensics: The Complete Guide
What the RDP bitmap cache is, where it lives, what its tiles can show about a remote session, how to date it, and how to parse bcache*.bmc and Cache*.bin files.
TL;DR. The RDP bitmap cache is a set of files that the Remote Desktop Connection client (mstsc.exe) writes on the source host, in the profile of the user who connected: C:\Users\<user>\AppData\Local\Microsoft\Terminal Server Client\Cache\. It holds thousands of small bitmaps, typically 64×64 pixels, of what the remote screen showed. Decoded and laid out, those tiles can show consoles and typed commands, folder names and tools. They carry no timestamps and no screen positions, so you date the session with other artifacts and rebuild screens by hand. RDP Bitmap Cache Parser decodes both file formats in your browser; nothing is uploaded.
This guide is the entry point to the series. Each section links to a deeper article.
What the RDP bitmap cache is
Remote Desktop sends the remote screen to the client as bitmaps. To avoid downloading the same pieces again (a window frame, an icon, a plain background), the client keeps a cache of bitmaps it has already received. With persistent bitmap caching enabled, part of that cache is written to disk and survives the session. That on-disk copy is the RDP bitmap cache.
Persistent bitmap caching is an option on the Experience tab of Remote Desktop Connection and is stored in .rdp files as bitmapcachepersistenable:i:1. It is on by default in mstsc. This series deals with the cache written by mstsc; we make no claim about other RDP clients.
Why it matters in an investigation
Most RDP evidence says that a session happened. The bitmap cache is one of the few artifacts that can show what the user saw during it:
- console windows, with commands and output as they were displayed;
- File Explorer windows, with folder and file names;
- tools opened on the remote host, dialogs, error messages;
- sometimes text typed in an editor.
It sits on the machine the session was started from. In a lateral-movement case, that means the cache on a compromised workstation or jump host can document activity on a target that was later wiped or had its logs cleared. That is the core reason to collect it on every host where mstsc was used.
Where it lives
| System | Path |
|---|---|
| Current Windows | C:\Users\<user>\AppData\Local\Microsoft\Terminal Server Client\Cache\ |
| Windows XP | C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Terminal Server Client\Cache\ |
| After an in-place upgrade | Also check C:\Windows.old\Users\... |
The cache is per user: whoever ran the client owns the files. Collection with PowerShell, KAPE, Velociraptor or from a mounted image is covered in RDP bitmap cache location and acquisition.
The two file formats
| Format | File names | Written by | Tile storage |
|---|---|---|---|
| Legacy BMC cache | bcache2.bmc, bcache22.bmc, bcache24.bmc (bmc-tools also mentions bcache23.bmc) | Older clients; still found on current systems | Fixed-size slots, 8, 16 or 32 bpp, some tiles compressed with interleaved RLE |
| RDP 8 persistent cache | Cache0000.bin, Cache0001.bin, ... | Newer versions of the client | RDP8bmp header, then uncompressed 32-bit tiles back to back |
Neither format is documented by Microsoft as a file format. What we know comes from reverse engineering, chiefly ANSSI's bmc-tools. The bitmap compression inside .bmc files, on the other hand, is the documented RDP interleaved RLE codec. Byte-level details are in the bcache*.bmc and Cache*.bin file format.
What a tile is, and what it is not
A bitmap tile is a small rectangle of the remote screen, usually 64×64 pixels, smaller at screen edges. Each is stored with a 64-bit cache key, a width and a height. That is all.
| A tile has | A tile does not have |
|---|---|
| Pixels | A timestamp |
| Width and height | Its position on the screen |
| A cache key | A session or target host identifier |
| A place in the cache order | A guarantee that it is recent |
Two consequences shape every analysis:
- Tiles are in cache order, not screen order. Neighbouring tiles in the file are sometimes neighbours on screen (a window region can end up cached row by row), but nothing in the format guarantees it.
- Identical pieces are stored once. A plain desktop background or an empty black console area appears as one tile, not as the dozens of places it covered.
In .bmc files, a slot can also keep part of an older tile when a smaller one is written over it. That leftover is a slot remnant and can show content that has otherwise been overwritten.
From tiles to screens
Parsing gives you a pile of tiles. Three views turn them into evidence:
- Gallery: every tile at readable size, with its index. Fast to skim for text.
- Collage: all tiles in one image, N per row, like bmc-tools'
_collage.bmp. When a window was cached row by row, choosing the right width makes parts of it line up. See tile collage. - Manual reconstruction: placing tiles on a grid by eye to rebuild a screen, the way BSI's RdpCacheStitcher does and the way the Reconstruct tab of this tool does.
Reconstructing RDP screens from cache tiles explains why a collage lines up in the middle and drifts at the edges, and how to finish the job manually.
Dating the activity
The cache gives content, not time. Build the timeline from the artifacts around it:
| Source | Where | What it gives |
|---|---|---|
| Cache files' NTFS timestamps | $MFT ($STANDARD_INFORMATION, $FILE_NAME), $UsnJrnl | When the client created and wrote the cache files |
| RDP client log | Microsoft-Windows-TerminalServices-RDPClient/Operational, event 1024 | Connection attempts, with the target name |
| Terminal Server Client registry | HKCU\Software\Microsoft\Terminal Server Client\Servers\<host> and ...\Default | Targets used, UsernameHint, MRU list |
Default.rdp, jump lists, Prefetch | User's Documents, profile, C:\Windows\Prefetch | Client use and recent connections |
| Target host logs | Security 4624 (logon type 10), 4778/4779; RemoteConnectionManager 1149 | Logons and reconnections on the other side |
Content visible in the tiles helps too: a taskbar clock, a date in a file listing, a transfer summary with elapsed time. Treat those as what the screen displayed, in the remote host's time zone and clock. Details are in RDP lateral movement: source host artifacts.
Tools
| Tool | What it does |
|---|---|
| bmc-tools (ANSSI, Python) | Reference decoder: exports tiles as BMP and a collage |
| RdpCacheStitcher (BSI) | A GUI that helps you stitch exported tiles into screens |
| RDP Bitmap Cache Parser | Decodes both formats in the browser, with gallery, collage, reconstruction canvas, triage hints and exports |
Our decoder is an independent implementation written from Microsoft's specifications and public research; we credit bmc-tools as the reference implementation and validated our output against it. A fair comparison, including our limits, is in RDP cache parsers compared. For a hands-on walkthrough, see how to analyze the RDP bitmap cache in your browser.
Pitfalls
- Collecting from the wrong host. The cache is on the source, not the target.
- Copying while a session is open. The files can be in use and the copy can fail. Close sessions or use a backup-mode or raw copy.
- Reading time into tile order. Cache order is not chronological order you can rely on.
- Over-reading 8-bit tiles. The palette is not stored, so colours are approximate.
- Treating hints as findings. "Console-like" means worth reading first, not malicious.
FAQ
Is the RDP bitmap cache on the client or on the server?
On the client. The Remote Desktop Connection client (mstsc.exe) writes it in the profile of the user who ran it, on the machine they connected from. The target host does not hold these files for that session.
Does the RDP bitmap cache contain timestamps?
No. Tiles carry no per-tile time, no screen position and no session identifier. Date the activity with the cache files' NTFS timestamps, the RDP client event log, the Terminal Server Client registry keys and logs on the target host.
Can I see what the attacker typed?
Sometimes. If a console or editor window was on screen, the tiles that covered it can show the command line or text as it was displayed. You read it from the images; there is no keystroke log in the cache.
Which tool should I use to parse it?
ANSSI bmc-tools is the reference decoder. RDP Bitmap Cache Parser decodes the same files in the browser with its own, independently written decoder, plus a gallery, collage and reconstruction canvas. For important findings, compare the output of two tools.