ShieldBreak – nowy exploit lokalnej eskalacji uprawnień przez Microsoft Defender

Badacz bezpieczeństwa działający pod pseudonimem Nightmare Eclipse ponownie zwrócił uwagę na Microsoft Defender. Zaledwie dzień po wydaniu przez Microsoft sierpniowego Patch Tuesday opublikował Proof of Concept exploita lokalnej eskalacji uprawnień, nazwanego ShieldBreak. Później został on sklasyfikowany jako CVE-2026-69414. Exploit pozwala uzyskać uprawnienia NT AUTHORITY\SYSTEM na podatnych systemach Windows.

Autor przedstawia ShieldBreak jako obejście poprawki przygotowanej dla RoguePlanet, wcześniejszego exploita badacza. Warto przy tym zauważyć, że RoguePlanet również został opublikowany tuż po comiesięcznym cyklu aktualizacji Microsoftu (zaledwie kilka godzin po wypuszczeniu czerwcowego Patch Tuesday).

Sam mechanizm RoguePlanet oraz spór związany z jego zgłoszeniem opisywaliśmy już wcześniej na Kapitanie – zainteresowanych tym wątkiem odsyłam do wcześniejszego artykułu.

W przypadku ShieldBreak pojawiło się jednak nowe pytanie – czy rzeczywiście mamy do czynienia z obejściem wcześniejszej poprawki, czy raczej z odrębną podatnością wykorzystującą inny mechanizm techniczny, ale prowadzącą do tego samego rezultatu?

ShieldBreak

ShieldBreak, jak już wspomnieliśmy, to exploit prowadzący do lokalnej eskalacji uprawnień. Do jego wykorzystania niezbędna jest możliwość uruchomienia kodu na komputerze. Posiadając lokalny dostęp, atakujący może przejść z konta o ograniczonych uprawnieniach do kontekstu NT AUTHORITY\SYSTEM, posiadającego najwyższy poziom lokalnych uprawnień w systemie Windows.

Z informacji opublikowanych przez autora wynika, że PoC został przetestowany na Windows 11 25H2, w tym na kompilacjach Canary, a także Windows Server 2025, osiągając w jego testach 100% skuteczności. Badacz wskazuje również, że choć exploit nie został przygotowany dla Windows 10 ani innych wersji Windows Server, systemy te mogą być podatne na ten sam problem.

Działanie ShieldBreak zostało dodatkowo potwierdzone przez niezależnych badaczy, między innymi Kevina Beaumonta i Willa Dormanna. Ich analizy zwracają uwagę na istotną kwestię – mimo podobnego efektu końcowego, sposób działania ShieldBreak różni się od tego, jaki wykorzystywał RoguePlanet.

Żeby lepiej zrozumieć, na czym polegają te różnice, warto przyjrzeć się łańcuchowi prowadzącemu do eskalacji uprawnień w przypadku ShieldBreak.

Sposób działania ShieldBreak

Punktem wyjścia działania ShieldBreak jest Cloud Filter API (CFAPI) – funkcja systemu Windows wykorzystywana między innymi przez rozwiązania synchronizujące pliki z chmurą, takie jak OneDrive. Pozwala ona tworzyć lokalne pliki typu placeholder, których właściwa zawartość jest pobierana dopiero w momencie, gdy aplikacja próbuje uzyskać do nich dostęp.

ShieldBreak wykorzystuje sposób, w jaki Microsoft Defender obsługuje ten rodzaj plików podczas skanowania. Exploit przygotowuje specjalny placeholder, a następnie wymusza jego analizę przez Defendera przy użyciu ciągu EICAR – standardowego wzorca testowego wykrywanego przez rozwiązania antywirusowe.

W momencie, gdy Defender próbuje uzyskać dostęp do zawartości pliku, exploit korzysta z operacji wykonywanych przez system Windows podczas tego procesu. W tym celu używane są między innymi mechanizmy Windows takie jak Object Manager symbolic links oraz Common Log File System (CLFS), które pozwalają manipulować ścieżkami oraz danymi wykorzystywanymi w kolejnych etapach łańcucha ataku.

W efekcie łańcuch prowadzi do sytuacji, w której payload kontrolowany przez exploit zostaje wykorzystany jako biblioteka phoneinfo.dll umieszczona w lokalizacji oczekiwanej przez mechanizm ładowania bibliotek Windows. Nie oznacza to, że Defender tworzy lub uruchamia tę bibliotekę – jego uprzywilejowane działanie jest jednym z elementów wykorzystywanych do osiągnięcia tego celu.

Kolejny etap to użycie istniejącego mechanizmu Windows Error Reporting. ShieldBreak uruchamia zadanie harmonogramu QueueReporting, które powoduje start procesu wermgr.exe w uprzywilejowanym kontekście. Proces ten podczas działania próbuje załadować bibliotekę phoneinfo.dll. Ponieważ w oczekiwanej lokalizacji znajduje się już biblioteka kontrolowana przez exploit, jej kod zostaje wykonany z uprawnieniami SYSTEM.

W przypadku PoC zaprezentowanego przez Nightmare Eclipse końcowym rezultatem jest uruchomienie procesu conhost.exe jako NT AUTHORITY\SYSTEM.

Jak widać, ShieldBreak nie opiera się na pojedynczym błędzie jednej funkcji. Łączy kilka elementów systemu Windows, a kluczowym aspektem całego łańcucha jest wykorzystanie uprzywilejowanych operacji wykonywanych przez Microsoft Defender podczas obsługi plików CFAPI.

RoguePlanet a ShieldBreak

Nightmare Eclipse opisuje ShieldBreak jako obejście poprawki przygotowanej dla RoguePlanet. Faktycznie na pierwszy rzut oka taki wniosek może wydawać się logiczny. Microsoft publikuje poprawkę, a kilka tygodni później ten sam badacz publikuje kolejny exploit wykorzystujący Microsoft Defender do eskalacji uprawnień do SYSTEM.

Jeżeli z kolei przyjrzymy się aspektom technicznym, różnice są dużo większe i bardziej widoczne.

RoguePlanet wykorzystywał race condition związany z operacjami na systemie plików i zachowaniem procesu kwarantanny Defendera. ShieldBreak nie używa tego mechanizmu. W jego przypadku kluczowe jest zachowanie Defendera podczas skanowania plików obsługiwanych przez CFAPI. Również pozostałe elementy wykorzystane w procesie eskalacji uprawnień nie odpowiadają rozwiązaniom zastosowanym w RoguePlanet.

Niezależni badacze również zwrócili na to uwagę. Po przetestowaniu ShieldBreak potwierdzili jego działanie, jednocześnie wskazując, że sposób wykorzystania Defendera różni się od RoguePlanet.

Określenie patch bypass najlepiej traktować zatem wyłącznie jako stanowisko autora exploita. Nie ma wątpliwości, że na systemie z poprawką dla RoguePlanet ponownie można doprowadzić do lokalnej eskalacji uprawnień z wykorzystaniem Microsoft Defender. Nie oznacza to jednak automatycznie, że Microsoft nieskutecznie załatał podatność, której dotyczyło CVE-2026-50656.

Stanowisko Microsoft

Początkowo, krótko po publikacji ShieldBreak, Microsoft poinformował, że analizuje zgłoszenie. 17 sierpnia firma potwierdziła jednak, iż pracuje nad aktualizacją bezpieczeństwa mającą usunąć problem.

W międzyczasie Microsoft Defender może wykrywać elementy publicznie dostępnego PoC. Oznacza to, że konkretna wersja exploita może zostać zablokowana przez mechanizmy detekcji, jednak zachowanie prowadzące do eskalacji uprawnień będzie możliwe do wykorzystania do czasu wydania poprawki. Sama detekcja znanego narzędzia nie jest równoznaczna z usunięciem przyczyny problemu.

Na co zwrócić uwagę w swoim środowisku?

Do czasu wydania poprawki warto skupić się przede wszystkim na detekcji behawioralnej oraz ograniczaniu możliwości wykorzystania lokalnej eskalacji uprawnień.

Szczególną uwagę należy zwracać na procesy uruchamiane w kontekście SYSTEM, które nie pasują do standardowego działania systemu lub używanego oprogramowania. Przykładem może być conhost.exe działający z tak wysokimi uprawnieniami, jeżeli jego uruchomienie nie wynika z normalnej aktywności hosta.

Dodatkowo warto monitorować nietypowe zachowanie wermgr.exe, wywołania zadania QueueReporting oraz pojawienie się lub modyfikację biblioteki phoneinfo.dll w katalogu C:\Windows\System32.

Po stronie zabezpieczeń warto zadbać przede wszystkim o odpowiednią konfigurację Microsoft Defendera oraz mechanizmy ograniczające możliwość uruchomienia nieautoryzowanego kodu na stacjach roboczych. Tamper Protection, reguły Attack Surface Reduction oraz kontrola uruchamianych aplikacji mogą ograniczyć możliwość wykorzystania podobnych technik jako elementów dalszego łańcucha ataku.

Podsumowanie

Historia RoguePlanet i ShieldBreak pokazuje, że nawet komponenty odpowiedzialne za ochronę systemu operacyjnego mogą stać się miejscem wystąpienia poważnych podatności.

Niezależnie od klasyfikacji relacji ShieldBreak do RoguePlanet oba przypadki udowadniają, że uprzywilejowane komponenty Microsoft Defender mogą zostać wykorzystane jako element łańcucha prowadzącego do lokalnej eskalacji uprawnień.

Opublikowany PoC prezentuje możliwość uzyskania uprawnień NT AUTHORITY\SYSTEM na podatnych wersjach systemu Windows. Do czasu wydania poprawki należy więc traktować go jako istotny problem, wymagający monitorowania.

Dla administratorów najważniejsze pozostaje nie tylko oczekiwanie na aktualizację, ale również obserwacja nietypowych zachowań w systemach Windows – szczególnie procesów uruchamianych z uprawnieniami SYSTEM oraz działań, które nie odpowiadają standardowej aktywności danego hosta.