Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
PhantomRPC to nowo opisana technika lokalnej eskalacji uprawnień w systemie Windows, która wykorzystuje słabość architektoniczną związaną z mechanizmem Remote Procedure Call. Nie chodzi tu o klasyczną lukę pamięci ani pojedynczy błąd w konkretnej usłudze, lecz o sposób rejestrowania serwerów RPC, obsługi punktów końcowych oraz użycia mechanizmu impersonacji przez procesy systemowe.
W praktyce oznacza to, że napastnik posiadający już lokalne wykonanie kodu i odpowiedni kontekst bezpieczeństwa może doprowadzić do przejęcia uprawnień SYSTEM. To czyni PhantomRPC szczególnie istotnym w scenariuszach poeksploatacyjnych, gdzie celem jest szybkie podniesienie uprawnień po uzyskaniu wstępnego dostępu.
W skrócie
- PhantomRPC to technika lokalnej eskalacji uprawnień wpływająca na środowisko Windows.
- Wykorzystuje fałszywy serwer RPC do przechwycenia połączenia uprzywilejowanego klienta lub usługi.
- Efektem może być podszycie się pod klienta i uzyskanie uprawnień SYSTEM.
- Opisane scenariusze obejmują m.in. Group Policy, WDI, DHCP Client, TermService oraz Windows Time.
- Według publicznie dostępnych informacji producent nie udostępnił jeszcze poprawki.
Kontekst / historia
RPC od lat stanowi jeden z fundamentów komunikacji międzyprocesowej w Windows. Liczne usługi systemowe i komponenty aplikacyjne używają go do wymiany danych i wywoływania funkcji między procesami. Z tego powodu wszelkie słabości projektowe w tym obszarze mogą mieć szeroki wpływ na bezpieczeństwo całego systemu.
W przypadku PhantomRPC problem został opisany jako architektoniczny, a nie jako pojedyncza podatność ograniczona do jednego pliku lub usługi. Sednem zagrożenia jest połączenie powszechnego użycia RPC z możliwością impersonacji klientów przez wybrane konta serwisowe, takie jak Local Service czy Network Service. Publiczne informacje wskazują, że problem zgłoszono producentowi we wrześniu 2025 roku, a jego szerszy opis ujawniono w kwietniu 2026 roku.
Analiza techniczna
PhantomRPC bazuje na założeniu, że środowisko wykonawcze RPC nie zawsze w pełni weryfikuje, czy serwer nasłuchujący na danym interfejsie lub punkcie końcowym jest rzeczywiście legalnym odbiorcą żądań. Jeśli napastnik kontroluje lokalny proces z możliwością impersonacji klienta, może uruchomić własny serwer RPC imitujący prawidłową usługę systemową.
Typowy przebieg ataku obejmuje kilka etapów. Najpierw atakujący uzyskuje kontrolę nad procesem działającym lokalnie w odpowiednim kontekście. Następnie rejestruje fałszywy serwer RPC powiązany z wybraną usługą albo z punktem końcowym, którego legalna usługa faktycznie nie wystawia. Gdy uprzywilejowany klient lub usługa wykona połączenie, złośliwy serwer odbiera żądanie i wykorzystuje kontekst bezpieczeństwa klienta do podszycia się pod niego. W rezultacie dochodzi do eskalacji uprawnień, często aż do poziomu SYSTEM.
Kluczowym elementem jest tutaj mechanizm impersonacji. W normalnych warunkach pozwala on usługom działać w imieniu klienta i realizować wymagane operacje systemowe. W scenariuszu PhantomRPC ta sama funkcja staje się narzędziem nadużycia, gdy połączenie trafia do kontrolowanego przez napastnika serwera RPC.
Opisane publicznie warianty obejmują kilka ścieżek nadużycia:
- podszycie się pod komponenty powiązane z TermService i przechwycenie połączenia inicjowanego przez usługę Group Policy działającą jako SYSTEM,
- scenariusz związany z uruchamianiem Microsoft Edge i określonymi wywołaniami RPC,
- wariant bez interakcji użytkownika z użyciem usługi diagnostycznej WDI,
- nadużycia związane z usługami działającymi jako Local Service, w tym DHCP Client i Windows Time.
Technika jest szczególnie niepokojąca, ponieważ nie wymaga klasycznego exploita typu memory corruption. Zamiast tego wykorzystuje prawidłowo działające funkcje systemu w nieoczekiwanej kombinacji. To utrudnia zarówno wykrywanie, jak i przygotowanie prostego mechanizmu naprawczego.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem PhantomRPC jest możliwość przejścia z ograniczonego lokalnego kontekstu do pełnych uprawnień SYSTEM. Taki poziom dostępu otwiera drogę do praktycznie całkowitego przejęcia hosta, w tym modyfikacji ustawień bezpieczeństwa, wyłączania części mechanizmów ochronnych oraz utrwalania obecności w systemie.
W środowisku firmowym oznacza to również wyższe ryzyko ruchu bocznego, kradzieży danych oraz dalszej kompromitacji infrastruktury. Technika może być atrakcyjna zarówno dla operatorów ransomware, jak i grup APT, ponieważ dobrze wpisuje się w etap po uzyskaniu pierwszego dostępu do stacji lub serwera.
Dodatkowym problemem pozostaje szeroka powierzchnia ataku. Ponieważ RPC jest głęboko osadzone w architekturze Windows i używane przez wiele usług, pełne oszacowanie wszystkich możliwych ścieżek nadużycia może być trudne. Opublikowane przykłady prawdopodobnie nie wyczerpują wszystkich wariantów wykorzystania tej techniki.
Rekomendacje
W sytuacji braku oficjalnej poprawki organizacje powinny skoncentrować się na ograniczeniu warunków potrzebnych do wykorzystania PhantomRPC oraz na monitorowaniu anomalii związanych z usługami i komunikacją RPC.
- wdrożyć kontrolę aplikacji i allowlisting, aby ograniczyć możliwość uruchamiania nieautoryzowanych procesów oraz usług,
- zredukować lokalne ścieżki wykonania kodu przez ograniczenie skryptów, makr, niezatwierdzonych narzędzi i technik LOLBins,
- monitorować procesy rejestrujące nietypowe endpointy RPC lub nasłuchujące na nazwanych potokach powiązanych z usługami systemowymi,
- zwracać szczególną uwagę na aktywność kont Local Service i Network Service, zwłaszcza gdy pojawiają się nietypowe przejścia do poziomu SYSTEM,
- wzmocnić reguły detekcji eskalacji uprawnień, w tym użycia SeImpersonatePrivilege oraz anomalii tokenów dostępu,
- wyłączyć lub ograniczyć nieużywane usługi i komponenty, jeśli pozwala na to analiza wpływu operacyjnego,
- hartować stacje administracyjne i systemy o wysokiej wartości, aby utrudnić wykorzystanie techniki po kompromitacji,
- na bieżąco śledzić komunikaty producenta i ustalenia badaczy dotyczące możliwych mitygacji.
Podsumowanie
PhantomRPC pokazuje, że nowoczesne techniki eskalacji uprawnień coraz częściej nie wynikają z pojedynczych błędów implementacyjnych, lecz z niezamierzonych skutków ubocznych działania legalnych mechanizmów systemowych. W tym przypadku problem leży na styku architektury RPC oraz mechanizmu impersonacji, co otwiera drogę do przejęcia uprawnień SYSTEM bez konieczności użycia klasycznego exploita pamięci.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że sama polityka szybkiego łatania nie zawsze wystarcza. Do czasu pojawienia się formalnych działań naprawczych najważniejsze pozostają kontrola wykonania kodu, monitoring nietypowych zachowań usług i endpointów RPC oraz ścisły nadzór nad kontami serwisowymi.