Badacze z RedTeam Pentesting odkryli nieznaną wcześniej technikę ataku relay, w której zamiast dobrze znanego NTLM wykorzystuje się protokół Kerberos. Nowa metoda, nazwana Reflective Kerberos Relay Attack, umożliwia przekaźnictwo (relay) biletu Kerberos otrzymanego od systemu Windows z powrotem do tego samego systemu, co skutkuje przyznaniem najwyższych uprawnień (NT AUTHORITY\SYSTEM). Choć NTLM relay działa także w środowiskach, które w całości opierają się na Kerberosie i gdzie NTLM jest wyłączony – co do tej pory uznawano za bezpieczne.
Nowa podatność – CVE‑2025‑33073
Podczas analizy wewnętrznych mechanizmów uwierzytelniania Kerberos badacze odkryli, iż w określonych warunkach możliwe jest uzyskanie eskalacji uprawnień do poziomu SYSTEM przez relay biletów Kerberosowych. Problem dotyczy wielu wersji Windows, w tym Windows 10, 11 oraz Windows Server (od 2019 wzwyż). RedTeam Pentesting zgłosił podatność do Microsoftu w styczniu 2025 roku i jest ona zarejestrowana jako CVE‑2025‑33073. Po weryfikacji przez zespół MSRC luka została oznaczona jako wysokiego ryzyka. Co ciekawe, początkowo wniosek o bounty został odrzucony – z powodu zbyt ogólnej kategorii. Po ponownej analizie i naciskach ze strony badaczy Microsoft przyznał jednak nagrodę w wysokości 5000 USD. Producent wydał poprawkę w ramach cyklicznej aktualizacji Patch Tuesday 11 czerwca 2025 roku.
Mechanika ataku – od coercion do SYSTEM
Atak polega na dwóch kluczowych elementach: wymuszeniu uwierzytelnienia (tzw. coercion) oraz przekaźnictwie uzyskanego biletu Kerberos do systemu, który go wygenerował. Po wymuszeniu połączenia SMB z serwerem atakującym ofiara (np. inny host w domenie) uwierzytelnia się dzięki Kerberosa. Następnie atakujący przekazuje ten bilet z powrotem do oryginalnego systemu – ofiary. W rezultacie system rozpoznaje bilet jako własny, a po stronie SMB sesja zostaje autoryzowana jako NT AUTHORITY\SYSTEM.
Technika coercion – zmuszanie hosta do uwierzytelnienia się
Ważnym krokiem ataku jest zmuszenie maszyny-ofiary do nawiązania połączenia SMB z hostem kontrolowanym przez atakującego. W tym celu wykorzystano techniki znane z wcześniejszych badań nad coercion – m.in. przez RPC (Remote Procedure Call). RedTeam Pentesting używał narzędzia coercer, wykorzystującego protokoły takie jak EFSR (Encrypting File System Remote), RPRN (Print Spooler), WSP (Web Services on Devices) czy DFSNM (Distributed File System Namespace Management). Dzięki tym metodom maszyna-ofiara sama inicjuje połączenie z serwerem atakującego.
Źródło: RedTeam PentestingAby atakujący był w stanie wykorzystać bilet Kerberos, konieczne jest „rozdzielenie” nazwy SPN (Service Principal Name) od adresu, z którym łączy się klient. W typowym przypadku klient tworzy bilet dla serwera SMB o nazwie np. host/server.lab.local. Atakujący modyfikuje tę nazwę, wstawiając odpowiednio spreparowaną strukturę danych w polu adresu SMB (np. przez UNC path z zakodowanym base64 hostem). W rezultacie system Windows generuje bilet z poprawnym SPN, ale nawiązuje połączenie do serwera atakującego – co jest kluczem do dalszego przekazania biletu.
Wymuszenie Kerberos nad NTLM – SMB signing jako wytrych
Domyślnie połączenia loopback przez SMB (np. \\127.0.0.1) mogą automatycznie przełączać się na NTLM – co nie jest użyteczne w tym ataku. Aby wymusić Kerberos, autorzy zmodyfikowali narzędzie krbrelayx tak, by wyłączało obsługę NTLM w negocjacji SMB. Dzięki temu klient nie ma innego wyboru, niż użyć Kerberosa. W efekcie serwer atakującego otrzymuje istotny bilet TGS, który może przekazać z powrotem do oryginalnego hosta.
Demonstracja ataku. Narzędzia – krbrelayx, wspcoerce, coercer
W demonstracji ataku badacze użyli następujących narzędzi: wspcoerce do wymuszenia połączenia SMB z innego hosta w domenie, krbrelayx.py jako zmodyfikowanego serwera relayingowego obsługującego Kerberosa, oraz coercer do testowania różnych wektorów coercion. Po uruchomieniu ataku z linii poleceń otrzymano zdalną powłokę z uprawnieniami SYSTEM, wykonując prostą komendę whoami.
Przeprowadzenie eskalacji Kerberosa do użytkownika SYSTEM
Początkowo oczekiwano, iż bilet TGS uwierzytelniający komputer otrzyma ograniczone uprawnienia (jako konto komputera), więc eskalacja do SYSTEM była niespodzianką. Autorzy spekulują, iż Windows, widząc bilet generowany lokalnie i przekazywany przez loopback (czyli z adresem IP 127.0.0.1 lub lokalnym hostname), traktuje go jako tzw. bilet lokalny. W rezultacie system nadpisuje token sesji z oryginalnego procesu (np. serwera SMB), co skutkuje tokenem SYSTEM. Mechanizm ten związany jest z rozszerzeniami KERB_LOCAL i KERB_AD_RESTRICTION_ENTRY, które są częścią nieudokumentowanej logiki Kerberosowego uwierzytelniania lokalnego.
Czy jest się czego bać?
Prawie wszystkie współczesne wersje Windows, zarówno klienckie (Windows 10, 11), jak i serwerowe (2019, 2022, Insider Builds), okazały się podatne. Aby atak zadziałał, potrzebne były jednak jednocześnie możliwość wymuszenia uwierzytelnienia z innego hosta oraz brak podpisu SMB po stronie serwera docelowego. W praktyce oznacza to, iż w domenach AD bez włączonego wymuszonego SMB signing może być podatna duża część środowiska.
Zabezpieczenia i rekomendacje dla administratorów
Organizacje powinny nie tylko zastosować najnowsze poprawki, ale również wdrożyć zalecane ustawienia zabezpieczeń:
- wymuszony SMB signing po stronie serwera,
- channel binding dla LDAP i SMB, EPA (Extended Protection for Authentication)
- oraz blokadę starych protokołów NTLM.
Dodatkowo powinno się ograniczać prawa kontom komputerowym, eliminować zbędne kanały RPC oraz segmentować sieć w taki sposób, by uniemożliwić dowolnemu hostowi nawiązywanie połączeń SMB do innych w sieci.
Znaczenie i przyszłość bezpieczeństwa Kerberosa
Microsoft wydał poprawkę w czerwcu 2025 roku. Analiza aktualizacji wykazała, iż modyfikuje ona sposób, w jaki system interpretuje połączenia Kerberos loopback, blokując możliwość lokalnego uwierzytelniania przez relayed ticket. Modyfikacje obejmują warunki tokenizacji i rozpoznawania SPN w kontekście adresu źródłowego – system wymaga teraz spójności pomiędzy nazwą hosta a źródłem połączenia.
Odkrycie Reflective Kerberos Relay udowadnia, iż choćby z wyłączonym NTLM środowiska Windows pozostają podatne na ataki relay. Pokazuje to, iż fundamentalne założenia bezpieczeństwa protokołu Kerberos w Windows mogą być obchodzone w kreatywny sposób – zwłaszcza w kontekście loopback, coercion i token relogin. Organizacje muszą być świadome, iż „wyłączenie NTLM” nie wystarcza – potrzebne są głębsze zabezpieczenia całej infrastruktury uwierzytelniania.
