RDP-Bitmap-Cache-Forensik: der vollständige Leitfaden

Kurz gesagt. Der RDP-Bitmap-Cache ist eine Gruppe von Dateien, die der Client Remotedesktopverbindung (mstsc.exe) auf dem Quellsystem schreibt, im Profil des Benutzers, der die Verbindung aufgebaut hat: C:\Users\<user>\AppData\Local\Microsoft\Terminal Server Client\Cache\. Er enthält Tausende kleiner Bitmaps, meist 64×64 Pixel, von dem, was der entfernte Bildschirm gezeigt hat. Dekodiert und angeordnet können diese Kacheln Konsolen und eingegebene Befehle, Ordnernamen und Werkzeuge zeigen. Sie tragen keine Zeitstempel und keine Bildschirmpositionen; die Sitzung datieren Sie also über andere Artefakte, und Bildschirme bauen Sie von Hand wieder auf. RDP Bitmap Cache Parser dekodiert beide Dateiformate in Ihrem Browser; nichts wird hochgeladen.

Dieser Leitfaden ist der Einstieg in die Serie. Jeder Abschnitt verweist auf einen vertiefenden Artikel.

Was der RDP-Bitmap-Cache ist

Remote Desktop überträgt den entfernten Bildschirm als Bitmaps an den Client. Damit dieselben Teile (ein Fensterrahmen, ein Symbol, ein einfarbiger Hintergrund) nicht erneut übertragen werden müssen, hält der Client einen Cache bereits empfangener Bitmaps. Ist die persistente Bitmap-Zwischenspeicherung (englisch „Persistent bitmap caching“) aktiviert, wird ein Teil dieses Caches auf die Festplatte geschrieben und überdauert die Sitzung. Diese Kopie auf dem Datenträger ist der RDP-Bitmap-Cache.

Die persistente Bitmap-Zwischenspeicherung ist eine Option auf der Registerkarte Leistung (englisch Experience) von Remotedesktopverbindung und wird in .rdp-Dateien als bitmapcachepersistenable:i:1 gespeichert. In mstsc ist sie standardmäßig aktiviert. Diese Serie behandelt den Cache, den mstsc schreibt; zu anderen RDP-Clients treffen wir keine Aussage.

Warum er in einer Ermittlung zählt

Die meisten RDP-Spuren belegen, dass eine Sitzung stattgefunden hat. Der Bitmap-Cache ist eines der wenigen Artefakte, die zeigen können, was der Benutzer dabei gesehen hat:

• Konsolenfenster mit Befehlen und Ausgaben, so wie sie angezeigt wurden;
• Explorer-Fenster mit Ordner- und Dateinamen;
• auf dem entfernten Host geöffnete Werkzeuge, Dialoge, Fehlermeldungen;
• manchmal Text, der in einem Editor eingegeben wurde.

Er liegt auf dem Rechner, von dem aus die Sitzung gestartet wurde. Bei Lateral Movement bedeutet das: Der Cache auf einer kompromittierten Workstation oder einem Jump Host kann Aktivität auf einem Ziel dokumentieren, das später bereinigt wurde oder dessen Protokolle gelöscht wurden. Das ist der Hauptgrund, ihn auf jedem Host zu sichern, auf dem mstsc benutzt wurde.

Wo er liegt

Der Cache ist benutzerbezogen: Wer den Client gestartet hat, besitzt die Dateien. Die Sicherung mit PowerShell, KAPE, Velociraptor oder aus einem eingebundenen Abbild beschreibt Speicherort und Sicherung des RDP-Bitmap-Caches.

Die beiden Dateiformate

Keines der beiden Formate ist von Microsoft als Dateiformat dokumentiert. Was wir wissen, stammt aus Reverse Engineering, vor allem aus bmc-tools der ANSSI. Die Bitmap-Kompression in .bmc-Dateien ist dagegen der dokumentierte RDP-Codec Interleaved RLE. Details auf Byte-Ebene finden Sie unter das Dateiformat von bcache*.bmc und Cache*.bin.

Was eine Kachel ist und was nicht

Eine Bitmap-Kachel ist ein kleines Rechteck des entfernten Bildschirms, meist 64×64 Pixel, an den Bildschirmrändern kleiner. Jede wird mit einem 64-Bit-Cache-Schlüssel, einer Breite und einer Höhe gespeichert. Mehr nicht.

Zwei Folgen prägen jede Analyse:

1. Kacheln liegen in Cache-Reihenfolge, nicht in Bildschirmreihenfolge. Benachbarte Kacheln in der Datei sind manchmal auch auf dem Bildschirm Nachbarn (ein Fensterbereich kann zeilenweise im Cache landen), aber nichts im Format garantiert das.
2. Identische Teile werden einmal gespeichert. Ein einfarbiger Desktophintergrund oder ein leerer schwarzer Konsolenbereich erscheint als eine Kachel, nicht an den Dutzenden Stellen, die er bedeckt hat.

In .bmc-Dateien kann ein Slot außerdem einen Teil einer älteren Kachel behalten, wenn eine kleinere darüber geschrieben wird. Dieser Rest ist ein Slot-Rest und kann Inhalte zeigen, die sonst überschrieben sind.

Von Kacheln zu Bildschirmen

Das Parsen liefert einen Haufen Kacheln. Drei Ansichten machen daraus Beweismittel:

• Galerie: jede Kachel in lesbarer Größe, mit ihrem Index. Schnell nach Text zu durchsuchen.
• Collage: alle Kacheln in einem Bild, N pro Zeile, wie _collage.bmp von bmc-tools. Wurde ein Fenster zeilenweise zwischengespeichert, richtet die passende Breite Teile davon aus. Siehe Kachel-Collage.
• Manuelle Rekonstruktion: Kacheln nach Augenmaß auf ein Raster legen, um einen Bildschirm wiederherzustellen, so wie es RdpCacheStitcher des BSI und der Tab Rekonstruieren dieses Werkzeugs tun.

RDP-Bildschirme aus Cache-Kacheln rekonstruieren erklärt, warum eine Collage in der Mitte passt und an den Rändern verrutscht, und wie Sie die Arbeit von Hand abschließen.

Die Aktivität datieren

Der Cache liefert Inhalt, keine Zeit. Bauen Sie die Zeitachse aus den umgebenden Artefakten auf:

Auch in den Kacheln sichtbare Inhalte helfen: eine Taskleistenuhr, ein Datum in einer Dateiliste, eine Übertragungszusammenfassung mit verstrichener Zeit. Behandeln Sie diese als das, was der Bildschirm anzeigte, in Zeitzone und Uhrzeit des entfernten Hosts. Details stehen in RDP-Lateral-Movement: Artefakte auf dem Quellsystem.

Werkzeuge

Unser Decoder ist eine unabhängige Implementierung auf Grundlage der Spezifikationen von Microsoft und öffentlicher Forschung; bmc-tools nennen wir ausdrücklich als Referenzimplementierung, und unsere Ausgabe haben wir dagegen validiert. Einen fairen Vergleich, einschließlich unserer Grenzen, finden Sie in RDP-Cache-Parser im Vergleich. Eine praktische Anleitung bietet den RDP-Bitmap-Cache im Browser analysieren.

Fallstricke

• Sicherung vom falschen Host. Der Cache liegt auf dem Quellsystem, nicht auf dem Ziel.
• Kopieren bei offener Sitzung. Die Dateien können in Benutzung sein, und die Kopie kann fehlschlagen. Schließen Sie Sitzungen oder nutzen Sie eine Kopie im Backup-Modus oder eine Raw-Kopie.
• Zeit aus der Kachelreihenfolge ableiten. Die Cache-Reihenfolge ist keine chronologische Reihenfolge, auf die Sie sich verlassen können.
• 8-Bit-Kacheln überinterpretieren. Die Palette wird nicht gespeichert, die Farben sind also nur näherungsweise richtig.
• Hinweise als Befunde behandeln. „Konsolenartig“ heißt: zuerst lesen, nicht: bösartig.

FAQ

Liegt der RDP-Bitmap-Cache auf dem Client oder auf dem Server?

Auf dem Client. Der Client Remotedesktopverbindung (mstsc.exe) schreibt ihn in das Profil des Benutzers, der ihn gestartet hat, auf dem Rechner, von dem aus die Verbindung aufgebaut wurde. Der Zielhost hält diese Dateien für die Sitzung nicht vor.

Enthält der RDP-Bitmap-Cache Zeitstempel?

Nein. Kacheln haben keine eigene Zeit, keine Bildschirmposition und keine Sitzungskennung. Datieren Sie die Aktivität über die NTFS-Zeitstempel der Cache-Dateien, das Ereignisprotokoll des RDP-Clients, die Registry-Schlüssel unter Terminal Server Client und die Protokolle auf dem Zielhost.

Kann ich sehen, was der Angreifer eingegeben hat?

Manchmal. War ein Konsolen- oder Editorfenster auf dem Bildschirm, können die Kacheln, die es abgedeckt haben, die Befehlszeile oder den Text so zeigen, wie er angezeigt wurde. Sie lesen ihn aus den Bildern ab; ein Tastaturprotokoll enthält der Cache nicht.

Mit welchem Werkzeug werte ich ihn aus?

ANSSI bmc-tools ist der Referenzdecoder. RDP Bitmap Cache Parser dekodiert dieselben Dateien im Browser mit einem eigenen, unabhängig entwickelten Decoder, dazu Galerie, Collage und Rekonstruktionsfläche. Vergleichen Sie bei wichtigen Befunden die Ausgabe zweier Werkzeuge.

Verwandte Artikel

• Speicherort und Sicherung des RDP-Bitmap-Caches
• Das Dateiformat von bcache*.bmc und Cache*.bin
• RDP-Bildschirme aus Cache-Kacheln rekonstruieren