Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Publicznie opisany exploit dotyczący sterownika jądra powiązanego z narzędziem ThrottleStop ujawnia groźną podatność umożliwiającą lokalną eskalację uprawnień w systemie Windows. Problem wynika z niebezpiecznej obsługi żądań IOCTL, która pozwala na dostęp do mapowanej pamięci fizycznej, a następnie na wykonanie zapisu w przestrzeni pamięci jądra.
W praktyce oznacza to, że atakujący posiadający już możliwość uruchomienia kodu na hoście może wykorzystać sterownik do obejścia zabezpieczeń systemowych, przejęcia kontroli nad uprzywilejowanymi procesami i uzyskania bardzo wysokich uprawnień. To klasyczny przykład zagrożenia z obszaru BYOVD, czyli wykorzystywania podatnych sterowników do działań post-exploitation.
W skrócie
Opisywana podatność ma charakter lokalnego błędu typu kernel out-of-bounds write i prowadzi do podniesienia uprawnień w Windows. Publicznie dostępny kod PoC pokazuje, że sterownik może zostać użyty do odczytu i zapisu pamięci jądra poprzez operacje na adresach fizycznych.
- atak wymaga wcześniejszego lokalnego dostępu do systemu,
- exploit zapewnia silne prymitywy odczytu i zapisu w pamięci jądra,
- możliwa jest modyfikacja struktur procesów chronionych, w tym LSASS,
- skutkiem może być kradzież poświadczeń, obejście EDR i pełna kompromitacja hosta.
Kontekst / historia
Podatne sterowniki od lat pozostają jednym z najważniejszych wektorów eskalacji uprawnień w środowiskach Windows. W wielu przypadkach atak nie polega na zdalnym wykonaniu kodu, lecz na wykorzystaniu zaufanego lub możliwego do załadowania sterownika, który udostępnia zbyt szeroki dostęp do pamięci, rejestrów lub przestrzeni I/O.
W analizowanym przypadku publiczne materiały wskazują na sterownik ThrottleStop dla Windows oraz wersję 3.0.0.0. Podatność została powiązana z identyfikatorem CVE-2025-7771 i wpisuje się w dobrze znany scenariusz, w którym napastnik po uzyskaniu przyczółka na systemie poszukuje szybkiej ścieżki do praw SYSTEM lub do wyłączenia ochrony kluczowych procesów bezpieczeństwa.
Tego rodzaju błędy są szczególnie niebezpieczne w realnych incydentach, ponieważ często stanowią pomost między początkowym dostępem a pełnym przejęciem kontroli nad stacją roboczą lub serwerem. Z perspektywy obrońców oznacza to konieczność traktowania sterowników jako elementu krytycznego dla powierzchni ataku.
Analiza techniczna
Z technicznego punktu widzenia exploit korzysta z interfejsu sterownika udostępnianego przez urządzenie \\.\ThrottleStop oraz z określonego kodu IOCTL 0x8000645C. Kod PoC definiuje strukturę wejściową zawierającą adres fizyczny i rozmiar operacji, a następnie wykorzystuje mechanizm translacji adresów do odczytu i zapisu wybranych obszarów pamięci jądra.
Kluczowy problem polega na tym, że sterownik zwraca wskaźnik do mapowanej pamięci, co umożliwia procesowi użytkownika wykonanie bezpośredniego zapisu wskazanej wartości. W efekcie powstaje bardzo niebezpieczny prymityw zapisu do pamięci jądra, wystarczający do modyfikowania krytycznych struktur systemowych odpowiedzialnych za integralność i bezpieczeństwo systemu operacyjnego.
Publiczny PoC demonstruje pełny łańcuch ataku. Najpierw sterownik jest ładowany jako usługa typu sterownika jądra, następnie otwierany jest uchwyt do urządzenia, po czym kod lokalizuje bazę jądra systemowego oraz strukturę procesu systemowego. W dalszej kolejności exploit przechodzi po liście aktywnych procesów, odnajduje strukturę EPROCESS procesu lsass.exe i modyfikuje pola odpowiedzialne za jego ochronę.
Najbardziej istotnym elementem demonstracji jest wyłączenie mechanizmów ochronnych procesu LSASS, w tym pól związanych z ochroną typu PPL oraz poziomem podpisu. To sprawia, że proces zaprojektowany do przechowywania wrażliwych danych uwierzytelniających przestaje być odpowiednio chroniony przed narzędziami post-exploitation działającymi z wysokimi uprawnieniami.
Z punktu widzenia atakującego taki wektor jest wyjątkowo wartościowy. Pozwala nie tylko na obejście zabezpieczeń lokalnych, ale również na przygotowanie środowiska do dalszego dumpingu poświadczeń, omijania narzędzi EDR czy utrwalania obecności w systemie na poziomie trudniejszym do wykrycia.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją podatności jest możliwość szybkiej eskalacji uprawnień do poziomu, który umożliwia pełną kontrolę nad systemem Windows. W środowiskach firmowych oznacza to ryzyko przejęcia poświadczeń, wyłączenia mechanizmów ochronnych i ułatwienia dalszego ruchu bocznego w sieci.
Ryzyko operacyjne rośnie z kilku powodów. Po pierwsze, publiczny PoC obniża próg wejścia dla przestępców i operatorów ransomware. Po drugie, wykorzystanie podatnych sterowników często bywa mniej oczywiste z punktu widzenia klasycznych mechanizmów detekcji niż typowe działania malware w przestrzeni użytkownika. Po trzecie, wiele organizacji nadal nie posiada dojrzałej polityki blokowania sterowników podatnych lub niepożądanych.
Choć podatność nie zapewnia początkowego dostępu, w praktyce może odegrać kluczową rolę w fazie post-compromise. To właśnie lokalna eskalacja uprawnień bardzo często decyduje o tym, czy napastnik z ograniczonego konta użytkownika przejdzie do pełnej dominacji nad hostem i krytycznymi procesami systemowymi.
Rekomendacje
Organizacje powinny rozpocząć od ustalenia, czy podatny sterownik lub powiązane z nim oprogramowanie znajdują się w środowisku. Dotyczy to nie tylko stacji roboczych użytkowników technicznych, lecz także systemów administracyjnych, laboratoriów testowych i maszyn wykorzystywanych do diagnostyki sprzętowej.
Jeżeli komponent nie jest niezbędny biznesowo, najbezpieczniejszym działaniem pozostaje jego usunięcie. Równolegle warto wdrożyć polityki ograniczające możliwość ładowania podatnych sterowników oraz egzekwować reguły integralności kodu i kontroli aplikacji.
- zidentyfikować obecność sterownika ThrottleStop i podobnych komponentów niskopoziomowych,
- włączyć listy blokowania znanych podatnych sterowników,
- monitorować tworzenie i uruchamianie usług typu kernel driver,
- analizować nietypowe wywołania
DeviceIoControlkierowane do sterowników, - śledzić anomalie związane z ochroną procesu LSASS i dostępem do jego pamięci,
- ograniczać lokalnym użytkownikom możliwość uruchamiania nieautoryzowanego kodu.
W środowiskach o wyższym poziomie wymagań bezpieczeństwa wskazane jest także okresowe przeglądanie listy dozwolonych sterowników, testowanie odporności na scenariusze BYOVD oraz stosowanie zasady najmniejszych uprawnień dla kont użytkowników i administratorów.
Podsumowanie
Przypadek sterownika ThrottleStop pokazuje, jak groźne mogą być błędy w sterownikach jądra udostępniających zbyt szerokie możliwości operacji na pamięci. Nawet jeśli atak wymaga wcześniejszego lokalnego dostępu, publiczny exploit dowodzi, że taki przyczółek może zostać szybko przekształcony w niemal pełną kontrolę nad systemem.
Dla zespołów bezpieczeństwa to kolejny sygnał, że skuteczna ochrona Windows nie może ograniczać się wyłącznie do warstwy user-mode. Zarządzanie sterownikami, blokowanie podatnych komponentów i monitoring aktywności w jądrze powinny stanowić integralny element strategii hardeningu i detekcji.
Źródła
- Exploit Database – Throttlestop Kernel Driver – Kernel Out-of-Bounds Write Privilege Escalation
https://www.exploit-db.com/exploits/52512 - NVD – CVE-2025-7771
https://nvd.nist.gov/vuln/detail/CVE-2025-7771 - TechPowerUp – ThrottleStop
https://www.techpowerup.com/download/techpowerup-throttlestop/ - Xavi Beltran – Using vulnerable drivers in red team exercises
https://xavibel.com/2025/12/22/using-vulnerable-drivers-in-red-team-exercises/ - Microsoft Learn – Driver Security Guidance
https://learn.microsoft.com/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules