PhantomRPC w Windows: niezałatana słabość RPC umożliwia lokalną eskalację uprawnień - Security Bez Tabu

PhantomRPC w Windows: niezałatana słabość RPC umożliwia lokalną eskalację uprawnień

Cybersecurity news

Wprowadzenie do problemu / definicja

PhantomRPC to nowo opisana technika eskalacji uprawnień w systemach Windows, wykorzystująca słabość architektoniczną mechanizmu Remote Procedure Call (RPC). Problem nie wynika z klasycznego błędu pamięci ani pojedynczej podatności implementacyjnej, lecz z zachowania platformy, które pozwala zarejestrować złośliwy serwer RPC pod punktem końcowym legalnej usługi, jeśli ta usługa nie jest aktywna. W praktyce może to umożliwić przejęcie kontekstu bardziej uprzywilejowanego procesu i podniesienie uprawnień nawet do poziomu SYSTEM.

W skrócie

Badacz bezpieczeństwa opisał niezałataną słabość nazwaną PhantomRPC, dotyczącą architektury RPC w Windows. Scenariusz ataku zakłada wcześniejsze uzyskanie lokalnego dostępu do systemu oraz możliwość uruchomienia procesu dysponującego uprawnieniem do impersonacji klienta. Atakujący może wystawić fałszywy serwer RPC, który przechwyci połączenia kierowane do niedostępnej legalnej usługi, a następnie wykorzysta je do eskalacji uprawnień.

Microsoft nie nadał tej kwestii identyfikatora CVE i ocenił ją jako problem o umiarkowanej wadze, co oznacza brak natychmiastowej poprawki. Dla organizacji oznacza to konieczność wdrażania własnych mechanizmów detekcji oraz ograniczania powierzchni ataku.

Kontekst / historia

Mechanizm RPC od lat stanowi jeden z fundamentów komunikacji międzyprocesowej w Windows. Jest szeroko wykorzystywany zarówno przez usługi systemowe, jak i komponenty aplikacyjne, dlatego każda słabość związana z jego architekturą może mieć rozległe konsekwencje operacyjne.

W przypadku PhantomRPC raport techniczny został przekazany do Microsoft Security Response Center we wrześniu 2025 roku. W październiku 2025 roku producent zaklasyfikował problem jako umiarkowanie istotny, bez przyznania CVE i bez dalszego śledzenia sprawy. Publiczna analiza została następnie opublikowana w kwietniu 2026 roku.

Istotne jest jednak to, że nie chodzi o zdalne, nieuwierzytelnione przejęcie systemu. PhantomRPC wymaga już skompromitowanej maszyny lub lokalnego punktu zaczepienia. Mimo tego technika ma dużą wartość operacyjną, ponieważ może stanowić pomost między początkową kompromitacją a przejęciem pełnej kontroli nad hostem.

Analiza techniczna

Sedno problemu polega na sposobie, w jaki Windows obsługuje połączenia RPC do usług, które w danym momencie nie są uruchomione. Jeżeli legalny serwer RPC nie nasłuchuje, system może dopuścić rejestrację innego procesu pod tym samym punktem końcowym. To tworzy warunki do podszycia się pod autentyczną usługę i odbierania wywołań RPC przeznaczonych dla prawdziwego komponentu.

Jeżeli do takiego podstawionego serwera połączy się proces działający z wyższymi uprawnieniami, a proces atakującego dysponuje przywilejem SeImpersonatePrivilege, możliwe staje się przejęcie tożsamości klienta i wygenerowanie tokenu umożliwiającego dalszą eskalację. To właśnie ten warunek był jednym z argumentów ograniczających ocenę wagi problemu, jednak z perspektywy obrońców nie eliminuje on ryzyka.

Autor badań opisał kilka ścieżek eksploatacji wynikających z tej samej klasy zachowania architektonicznego. Różnią się one zestawem procesów i usług użytych do wymuszenia połączenia do fałszywego serwera RPC, ale wspólny wzorzec pozostaje taki sam:

  • atakujący rejestruje punkt końcowy legalnej, lecz nieaktywnej usługi,
  • odbiera połączenie od bardziej uprzywilejowanego klienta,
  • wykorzystuje impersonację do uzyskania wyższego poziomu dostępu.

Badania oraz proof-of-concept były testowane na Windows Server 2022 i Windows Server 2025 z aktualnym stanem poprawek dostępnym przed zgłoszeniem problemu. Jednocześnie wskazano, że źródłem zagrożenia jest szersze zachowanie warstwy RPC, co może oznaczać podatność także innych wersji Windows.

Konsekwencje / ryzyko

Najważniejszym skutkiem PhantomRPC jest możliwość przejścia z ograniczonych uprawnień lokalnych do poziomu SYSTEM. W środowiskach korporacyjnych oznacza to istotne zwiększenie skuteczności działań post-exploitation, obejście części mechanizmów segmentacji uprawnień oraz łatwiejsze utrwalenie obecności w systemie.

Po uzyskaniu tokenu SYSTEM napastnik może modyfikować ustawienia zabezpieczeń, instalować trwałe komponenty, manipulować usługami oraz przygotowywać dalszy ruch boczny. Ryzyko rośnie szczególnie tam, gdzie:

  • na hostach działa wiele usług RPC zależnych od stanu uruchomienia,
  • konta usługowe posiadają SeImpersonatePrivilege,
  • środowisko dopuszcza uruchamianie niestandardowych procesów z rozszerzonymi uprawnieniami,
  • monitoring zdarzeń RPC jest ograniczony lub nie istnieje,
  • organizacja opiera ochronę głównie na patch management, a nie na detekcji zachowań.

Choć PhantomRPC nie daje zdalnego wejścia sam w sobie, stanowi bardzo użyteczne narzędzie dla operatorów ataków po uzyskaniu pierwszego dostępu. Z praktycznego punktu widzenia jego znaczenie może więc być większe, niż sugeruje formalna klasyfikacja problemu jako umiarkowanego.

Rekomendacje

Podstawową rekomendacją jest ograniczenie użycia przywileju SeImpersonatePrivilege wyłącznie do procesów, które rzeczywiście go wymagają. Każde nadmierne przypisanie tego uprawnienia zwiększa prawdopodobieństwo skutecznej eskalacji po lokalnej kompromitacji.

Drugim kluczowym działaniem jest wdrożenie monitoringu ETW dla aktywności RPC. Event Tracing for Windows może pomóc w obserwowaniu wyjątków RPC, prób połączeń do niedostępnych serwerów oraz nietypowych zachowań związanych z rejestracją endpointów.

Dla zespołów SOC szczególnie istotne powinny być reguły wykrywające:

  • połączenia RPC do nieaktywnych usług,
  • nietypową rejestrację punktów końcowych RPC,
  • uruchamianie procesów nasłuchujących pod endpointami kojarzonymi z usługami systemowymi,
  • nietypowe użycie tokenów i operacji impersonacji.

W niektórych środowiskach można dodatkowo zmniejszyć powierzchnię ataku przez zapewnienie, że oczekiwane legalne usługi RPC pozostają uruchomione i dostępne. Takie podejście wymaga jednak ostrożności operacyjnej i analizy wpływu na stabilność systemów.

Warto również:

  • przeprowadzić przegląd kont usługowych oraz przypisanych im przywilejów,
  • audytować niestandardowe usługi i aplikacje uruchamiane z podwyższonymi uprawnieniami,
  • monitorować tworzenie i modyfikację usług systemowych,
  • wdrożyć telemetrykę pozwalającą korelować zdarzenia RPC z procesami źródłowymi,
  • traktować lokalne konta usługowe jako potencjalny punkt wyjścia do dalszej eskalacji.

Podsumowanie

PhantomRPC pokazuje, że poważne ryzyko w Windows może wynikać nie tylko z klasycznych luk programistycznych, ale również z decyzji architektonicznych i dopuszczalnych zachowań platformy. Opisana technika nie zapewnia zdalnego dostępu bez uwierzytelnienia, ale dla atakującego posiadającego już lokalny foothold może być skuteczną drogą do przejęcia pełnej kontroli nad systemem.

Brak poprawki i brak identyfikatora CVE nie oznaczają braku zagrożenia operacyjnego. Dla obrońców najważniejsze pozostają ograniczenie SeImpersonatePrivilege, monitoring ETW dla RPC oraz kontrola stanu usług i niestandardowych procesów uprzywilejowanych.

Źródła

  • https://www.darkreading.com/vulnerabilities-threats/unpatched-phantomrpc-flaw-windows-privilege-escalation
  • https://securelist.com/phantomrpc-rpc-vulnerability/119428/
  • https://github.com/klsecservices/PhantomRPC