Windows Server 2025 dostał nową funkcję. Atakujący dostali SYSTEM-a

Atak, który nie chce umrzeć

Ataki relay, w których atakujący zajmuje pozycję pośrednika, to jeden z najczęstszych wektorów, jakie spotykamy zarówno na własnych pentestach, jak i w głośnych włamaniach oraz atakach ransomware. W typowej sieci zawsze znajdzie się jakiś komputer, usługa albo użytkownik, którego da się zmusić, żeby przepuścił swój ruch uwierzytelniający przez maszynę atakującego. Stamtąd blisko do eskalacji uprawnień i ruchu bocznego po sieci.

Bywa jednak, że atakujący ma pod górkę. Mało ruchu, garść usług, po sieci krąży dosłownie kilku użytkowników i nie ma do kogo zawrócić przechwyconego uwierzytelnienia. Wtedy w grę wchodzi NTLM reflection, czyli zawrócenie uwierzytelnienia do tej samej maszyny, z której wyszło. Relay do samego siebie. Gdy pod ręką nie ma innego celu, to jedna z prostszych dróg do środka.

Windows zna ten problem od 2008 roku, kiedy biuletyn MS08-068 zablokował klasyczną wersję SMB do SMB. Przez blisko dwie dekady Microsoft łatał kolejne warianty, a branża co kilka lat ogłaszała, że reflection już nie żyje. Za każdym razem wracało w nowym przebraniu.

W czerwcu 2025 badacze z Synacktiv (przy współudziale innych zespołów) pokazali, że wystarczy sprytnie spreparowana nazwa DNS, żeby oszukać system i wymusić lokalne uwierzytelnienie. To była CVE-2025-33073. Mechanizm nazywa się CMTI, czyli CredMarshalTargetInfo: do nazwy celu doklejane są dodatkowe dane, które LSASS obcina dopiero na końcu, więc uwierzytelnienie generuje się dla innej nazwy, niż się wydaje. Ta podatność figuruje w katalogu Known Exploited Vulnerabilities CISA od października 2025, z terminem naprawy dla agencji federalnych wyznaczonym na 10 listopada. Nie akademicka ciekawostka, tylko rzecz wykorzystywana w realnych włamaniach.

Dlaczego jedna łatka nie wystarczyła

Poprawka Microsoftu z czerwca 2025 zmieniła sterownik mrxsmb.sys tak, żeby odrzucał połączenia do nazw z doklejonymi danymi. Zamknęła konkretną ścieżkę. Nie ruszyła przyczyny.

Synacktiv od razu to zauważył. Ich zdaniem łatka leczyła objaw: usuwała jeden trik, a nie samą możliwość, że komponenty Windows dają się zmusić do zawrócenia lokalnego uwierzytelnienia. Zespół Guillaume'a André wrócił do tematu i w kwietniu 2026 opublikował dwuczęściowe badanie, w którym opisał obejście łatki oraz dwie nowe podatności. Pierwsza z nich to właśnie CVE-2026-24294. Tytuł ich prelekcji na Black Hat Asia 2026 dobrze oddaje sytuację: „prezent, który nie przestaje dawać”.

Dla obrońcy płynie z tego jeden wniosek. Zainstalowanie aktualizacji i zrozumienie ryzyka to dwie różne rzeczy. Wąska poprawka zamyka zgłoszony exploit, ale zostawia całą klasę zachowań nietkniętą i wtedy pojawia się kolejne CVE na to samo.

Wektor: dowolny port TCP i multipleksowanie SMB

W Windows 11 24H2 i Windows Server 2025 pojawiła się możliwość podłączenia udziału SMB na dowolnym porcie TCP, nie tylko na klasycznym 445. Robi się to parametrem /tcpport. Sama w sobie funkcja jest rozsądna, bo daje elastyczność przy nietypowych wdrożeniach. Problem nie leży w niej. Problem w tym, co stary atak potrafi z nią zrobić.

Mechanizm jest krótki. Atakujący stawia lokalny serwer SMB na niestandardowym porcie i montuje udział, co otwiera trwałe połączenie TCP:

net use \\127.0.0.1\share /tcpport:12345

Potem wymusza na uprzywilejowanym procesie (LSASS działa jako SYSTEM), żeby ten sięgnął po tę samą ścieżkę UNC. Ponieważ połączenie TCP już istnieje, Windows woli wykorzystać je ponownie niż budować nowe. Uprzywilejowana sesja NTLM jedzie przez transport atakującego i zostaje zawrócona do prawdziwej usługi SMB na porcie 445. Efekt: sesja z prawami SYSTEM.

NTLM reflection nie umarło. Zmieniło tylko transport.

Co to znaczy poza jednym serwerem

SYSTEM na jednej maszynie to już zły dzień. Ale rzadko na tym się kończy.

Jeśli przejęty serwer ma włączoną nieograniczoną delegację (Unconstrained Delegation), atakujący może wymusić uwierzytelnienie kontrolera domeny. W pamięci LSASS ląduje wtedy bilet TGT konta komputera DC. Stamtąd jest już prosta droga do DCSync i przejęcia całej domeny Active Directory. Jeden przeskok od lokalnego użytkownika do administratora domeny. Tę konsekwencję warto pokazać zarządowi, zanim wróci pytanie „ale przecież mamy wszystko załatane”.

Kto realnie jest na celowniku

Windows Server 2025 w domyślnej konfiguracji, gdzie podpisywanie SMB nie jest wymuszone, to scenariusz krytyczny. Opisana ścieżka działa i prowadzi wprost do SYSTEM.

Windows 11 24H2 domyślnie wymusza wychodzące podpisywanie SMB, co ten konkretny relay blokuje. I tu pojawia się pułapka słowa „domyślnie”. Nowe systemy przychodzą z sensownymi ustawieniami: wymagane podpisywanie SMB, channel binding dla LDAP, EPA na web enrollmencie ADCS, wyłączony NTLMv1. Na w pełni załatanym Server 2025 klasyczny łańcuch relay jest zablokowany.

Kłopot w tym, że prawie nikt nie ma środowiska w pełni jednorodnego. Wystarczy jeden kontroler domeny na Server 2019, którego nikt nie zaktualizował. Wystarczy serwer ADCS bez włączonego EPA. Atak nie idzie po najmocniejszym ogniwie, tylko po najsłabszym, a w mieszanej infrastrukturze zawsze jakieś się znajdzie. Do tego dochodzi cała rodzina technik koercji, którą atakujący ma pod ręką: PetitPotam (przez MS-EFSRPC), PrinterBug przez usługę drukowania, DFSCoerce, ShadowCoerce. Część z nich działa bez uwierzytelnienia na domyślnym Server 2019 czy 2022. A jeśli wymuszasz podpisywanie SMB, zostaje jeszcze koercja przez WebDAV, która całą tę ochronę omija, bo celuje w usługi po HTTP.

Jak się bronić

Klasyczny antywirus i EDR mają z tym problem, bo cały atak to poprawne polecenia net use i zgodny z protokołem ruch SMB. Nie ma złośliwego pliku do wykrycia. Detekcja musi patrzeć na zachowanie, nie na sygnatury: nietypowy ruch SMB wychodzący na wysokie porty, uwierzytelnienia SMB z procesów, które nie powinny ich generować, sekwencje koercji w telemetrii sieciowej.

Od strony konfiguracji warto potraktować to warstwowo, bo żadna pojedyncza opcja nie zamyka wszystkich ścieżek.

Zrób od zaraz:

• Wgraj poprawki na CVE-2026-24294 (marzec 2026) i wcześniejszą CVE-2025-33073 (czerwiec 2025), ze szczególnym priorytetem dla Windows Server 2025.
• Włącz audyt NTLM. Narzędzia są dostępne w 24H2 i Server 2025 od końca 2025 i pokazują, gdzie NTLM realnie jeszcze pracuje. Nie naprawisz tego, czego nie widzisz.
• Wymuś podpisywanie SMB na serwerach i klientach, nie tylko na kontrolerach domeny. To zapora na poziomie protokołu. Stan sprawdzisz poleceniem Get-SmbServerConfiguration | Select RequireSecuritySignature, a wymusisz przez Set-SmbServerConfiguration -RequireSecuritySignature $true.

Warstwa głębsza, bo atakujący i tak poszuka obejścia:

• Wymuś podpisywanie i channel binding dla LDAP na kontrolerach domeny (LdapEnforceChannelBinding ustawione na 2), żeby zamknąć relay do LDAP.
• Włącz EPA na web enrollmencie ADCS. To bezpośrednia ochrona przed relayem do usługi certyfikatów (ścieżka ESC8), której samo podpisywanie SMB nie łapie.
• Odetnij wektory koercji: wyłącz usługę drukowania tam, gdzie nie jest potrzebna, zastosuj filtry RPC (netsh rpc filter) ograniczające zdalne wywołania niebezpiecznych interfejsów, wyłącz LLMNR i NBT-NS.
• Ogranicz możliwość inicjowania połączeń SMB na portach innych niż 445 i monitoruj użycie net use oraz New-SmbMapping na nietypowych portach.

Warto pamiętać o czasie. Gdy publiczny PoC już istnieje (a dla CVE-2026-24294 istnieje), okno między ujawnieniem a próbami wykorzystania robi się krótkie. To nie jest poprawka na „przy najbliższym oknie serwisowym za kwartał”.

Prawdziwa naprawa jest strategiczna

Tu dochodzimy do sedna. NTLM to protokół z 1993 roku, zaprojektowany do świata pojedynczych stacji i prostych grup roboczych. Microsoft oficjalnie zdeprecjonował go w 2024 i sam mówi wprost, że część jego słabości jest nie do załatania, bo siedzi w samej konstrukcji. Reflection, pass-the-hash i relay to nie są osobne błędy. To objawy tego samego, starzejącego się mechanizmu.

Dlatego Microsoft rozpisał wygaszanie NTLM na trzy fazy. Faza pierwsza to audyt i widoczność, dostępna już teraz w 24H2 i Server 2025. Faza druga, planowana na drugą połowę 2026, dorzuca IAKerb i lokalny KDC, czyli funkcje, które usuwają najczęstsze powody, dla których systemy w ogóle sięgają po NTLM (brak łączności z kontrolerem domeny, konta lokalne). Faza trzecia, przy kolejnym dużym wydaniu Windows Server, wyłączy sieciowy NTLM domyślnie. Protokół zostanie w systemie jako opcja do świadomego włączenia, ale siatka bezpieczeństwa zniknie.

Dla zarządu tłumaczy się to na jedno zdanie: łatanie kolejnych CVE w NTLM to gaszenie pożarów, a docelowo trzeba przejść na Kerberos. Ten czas, między teraz a domyślnym wyłączeniem, to okno na zmapowanie zależności i migrację, zanim zrobi to za Ciebie kolejny system albo kolejny atakujący.

Na koniec

Najmniej przyjemne w tej podatności jest to, że nie wymaga od atakującego niczego wyrafinowanego. Powiem szczerze: na testach wewnętrznych tego typu prymitywy lubimy, bo to czysta, jednokrokowa droga do SYSTEM-a, a stamtąd zwykle blisko do całej domeny. Właśnie dlatego warto, żeby ktoś sprawdził to u Ciebie, zanim zrobi to ktoś mniej życzliwy.

Pytanie brzmi: czy na Twoich serwerach 2025 podpisywanie SMB jest realnie wymuszone, czy tylko „zaplanowane na później”? I czy wiesz, ile w Twojej sieci wciąż mówi po NTLM?