Remote Desktop Puzzle Attack. Jak trwałe buforowanie map bitowych w RDP może stać się narzędziem ataku

Zdalny pulpit (RDP) od lat jest jednym z kluczowych mechanizmów administracji systemami Windows. W środowiskach korporacyjnych, rządowych i wojskowych stanowi fundament pracy zdalnej oraz utrzymania infrastruktury. Paradoksalnie jednak to właśnie mechanizmy zaprojektowane z myślą o wydajności i komforcie użytkownika mogą stać się wektorem ataku. Jednym z mniej znanych, a jednocześnie wyjątkowo podstępnych przykładów jest opcja trwałego buforowania map bitowych (persistent bitmap caching), która w określonych warunkach umożliwia ujawnienie zawartości sesji RDP choćby długo po jej zakończeniu. O atakach na RDP pisaliśmy już dużo na Kapitanie.

Trwałe buforowanie map bitowych – niewinna optymalizacja

Trwałe buforowanie map bitowych to funkcja w kliencie RDP (np. mstsc.exe), który zapisuje na dysku „płytki” (tile = małe bitmapy, np. 64×64 px) z renderowanego ekranu, żeby przy kolejnych wyświetleniach serwer mógł wysłać jedynie odniesienie (hash) zamiast całego obrazka — co oszczędza pasmo i przyspiesza odświeżanie. Cache przechowywany jest lokalnie w plikach typu Cache*.bin / bcache.bmc. Z punktu widzenia użytkownika wszystko dzieje się w tle: sesja działa szybciej, animacje są płynniejsze, a obciążenie sieci mniejsze.

Problem polega na tym, iż zapisane bitmapy nie są powiązane wyłącznie z jedną sesją ani jednym serwerem. Trafiają na dysk w postaci plików cache i mogą przetrwać restart systemu, wylogowanie użytkownika czy zakończenie pracy. W tym miejscu optymalizacja zaczyna przypominać archiwum wrażliwych informacji.

Gdzie pojawia się wektor ataku?

Atak wykorzystujący trwałe buforowanie map bitowych nie polega na klasycznym „włamaniu” do serwera RDP. Jego istotą jest nadużycie zaufania klienta RDP do własnego cache. jeżeli atakujący doprowadzi do sytuacji, w której ofiara połączy się z kontrolowanym przez niego serwerem RDP albo uzyska dostęp do plików cache na stacji roboczej (np. w ścieżce %LOCALAPPDATA%\Microsoft\RDP Cache lub %LOCALAPPDATA%\Microsoft\Terminal Server Client\Cache), może zacząć składać obraz z zapisanych wcześniej fragmentów ekranu.

Ważne niuanse (często pomijane)

• To nie jest cache sesji przychodzących na serwer – serwer Windows nie przechowuje bitmap cache klientów.
• Jeżeli Windows Server 2022 działa jako jump host / bastion i on łączy się dalej przez RDP, wtedy cache będzie zapisany lokalnie na tym serwerze, w profilu użytkownika, który uruchamia mstsc.exe.
• Cache jest per-user, więc przy analizie IR trzeba sprawdzić każdy profil użytkownika, nie tylko Administratora.

Mechanizm ten bywa określany jako atak typu „puzzle”. Klient RDP, zamiast pobierać nowe bitmapy, otrzymuje od serwera jedynie odwołania do kafelków już zapisanych na dysku. o ile takie kafelki istnieją, zostają użyte do odtworzenia obrazu. W praktyce oznacza to, iż elementy ekranów wyświetlanych w przeszłości – okna aplikacji, fragmenty dokumentów, paski narzędzi, a czasem choćby tekst – mogą zostać ponownie zrenderowane w nowym kontekście.

Rekonstrukcja ekranu z pozornie losowych danych

Pojedynczy kafelek bitmapy nie zdradza wiele. Jednak przy odpowiedniej liczbie elementów i ich korelacji możliwe jest odtworzenie większych fragmentów interfejsu. Badania i analizy powłamaniowe pokazały, iż z bitmap cache da się wyciągnąć nazwy hostów, fragmenty wiadomości e-mail, zawartość okien menedżerów haseł czy elementy paneli administracyjnych.

Co istotne, atak ten nie musi pozostawiać wyraźnych śladów w klasycznych logach. Dla systemu jest to normalne użycie mechanizmu cache. Z perspektywy zespołów bezpieczeństwa oznacza to, iż wyciek informacji może nastąpić bez alarmów, exploitów czy podejrzanych błędów.

RdpCacheStitcher – narzędzie do rekonstruowania obrazów

Jednym z najbardziej znanych narzędzi do rekonstrukcji obrazu z cache RDP jest RdpCacheStitcher. To projekt, który powstał z myślą o analizie kryminalistycznej (forensics) i wspiera analityków w odtwarzaniu użytecznych obrazów z bitmap cache RDP. Umożliwia przeglądanie kafelków, podpowiada miejsca, gdzie mogą być dopasowane, i pozwala eksportować uzyskane obrazy jako pliki PNG.

Przed użyciem narzędzia należy jednak przekonwertować binarne pliki cache na bitmapy. Można do tego użyć programu BMC-Tools napisanego w Pythonie.

I na końcu próba rekonstrukcji sesji RDP z kafelków dzięki RDPCacheStitcher – widać wyraźnie elementy pulpitu Windows oraz naszą tapetę Kapitana.

Dlaczego jest to groźne?

Największym zagrożeniem nie jest jednorazowy wyciek, ale trwałość artefaktów. Bitmapy zapisane na dysku stacji roboczej mogą przetrwać miesiącami. choćby jeżeli użytkownik przestrzega zasad bezpieczeństwa, zmienia hasła i zamyka sesje, fragmenty wrażliwych danych wciąż mogą znajdować się w cache.

W środowiskach o podwyższonym poziomie bezpieczeństwa – takich jak infrastruktura krytyczna czy systemy wojskowe – oznacza to możliwość pasywnego zbierania informacji i budowania obrazu środowiska bez bezpośredniej ingerencji w serwery. Atakujący nie musi „kraść” danych w tradycyjny sposób; wystarczy, iż je cierpliwie odtworzy.

Wykrywanie i analiza powłamaniowa

Z perspektywy DFIR trwałe buforowanie map bitowych jest mieczem obosiecznym. Z jednej strony może zostać nadużyte przez atakującego, z drugiej stanowi cenne źródło dowodów. Analiza plików bitmap cache pozwala czasem odtworzyć aktywność użytkownika lub intruza z dokładnością, której nie dają same logi zdarzeń.

W związku z powyższym w przypadku podejrzenia incydentu zaleca się zabezpieczenie tych plików do analizy offline, zanim zostaną wyczyszczone przez automatyczne polityki lub działania naprawcze.

Jak się bronić przed „cichym” atakiem?

Najskuteczniejszą ochroną jest wyłączenie trwałego buforowania map bitowych tam, gdzie nie jest ono niezbędne lub podczas sesji np. narzędziem mtsc.exe używać przełącznika „/public”.

W nowoczesnych sieciach koszt wydajnościowy jest zwykle pomijalny w porównaniu z ryzykiem wycieku danych. Dodatkowo najważniejsze znaczenie ma ograniczenie ekspozycji RDP, stosowanie NLA i MFA oraz rygorystyczna kontrola tego, z jakimi serwerami klienci mogą się łączyć.

Krótkie, praktyczne kroki:

1. Wyłączyć persistent bitmap caching na klientach (opcje RDP / GPO). jeżeli nie jest potrzebne, wyłącz – to najbardziej bezpośrednia kontrola.
2. Ograniczyć ekspozycję RDP: nie wystawiać RDP bezpośrednio do Internetu, wymagać VPN/NAC, filtrować po adresach źródłowych.
3. Włączyć Network Level Authentication (NLA), MFA dla RDP oraz mocną politykę haseł.
4. Automatyczne czyszczenie/cache-wipe po sesji: skrypty lub GPO, które usuwają pliki cache (Cache*.bin) po zakończeniu sesji użytkownika.
5. Monitorowanie i EDR/ SIEM: alarmy na nietypowe połączenia, wykrywanie tworzenia/odczytu plików cache z nieoczekiwanych procesów (może wskazywać malware).
6. Patching: utrzymywać systemy zaktualizowane – ataki RDP często łączą się z innymi podatnościami protokołu; łatać znane CVE.

Uzupełnieniem powinna być polityka regularnego czyszczenia cache na stacjach roboczych oraz monitoring nietypowych połączeń RDP. Trwałe buforowanie map bitowych samo w sobie nie jest podatnością typu CVE, ale w rękach atakującego staje się skutecznym narzędziem rozpoznania i eksfiltracji informacji.

Podsumowanie

Atak wykorzystujący persistent bitmap caching pokazuje, iż w bezpieczeństwie nie istnieją funkcje całkowicie neutralne. To, co przyspiesza pracę użytkownika, może jednocześnie stać się nośnikiem wrażliwych danych. W przypadku RDP zagrożenie to jest szczególnie podstępne, bo działa cicho, bez exploitów i bez sygnałów ostrzegawczych. Dlatego trwałe buforowanie map bitowych powinno być traktowane nie jako detal konfiguracyjny, ale jako realny element powierzchni ataku.