NTLM relay: SMB signing, LDAP channel binding i EPA

NTLM relay nie polega na złamaniu hasła ani odwróceniu odpowiedzi challenge–response. Atakujący przekazuje negocjację uwierzytelnienia prawowitego klienta do innej usługi, a następnie używa powstałej sesji w granicach uprawnień tej tożsamości. Łańcuch jest możliwy, gdy klient emituje NTLM do pośrednika, protokół docelowy nie wiąże uwierzytelnienia z właściwym kanałem lub usługą, a relayowane konto ma użyteczne prawa.

Najważniejsza odpowiedź obronna jest warstwowa: SMB signing chroni sesję SMB, LDAP signing chroni integralność LDAP, LDAP channel binding wiąże uwierzytelnienie z TLS, a Extended Protection for Authentication robi analogiczną pracę dla Windows Authentication w IIS. Te mechanizmy nie są zamienne. Samo włączenie HTTPS albo „używamy NTLMv2” nie zamyka wszystkich ścieżek relay.

W artykule opisujemy bezpieczny audyt i detekcję bez gotowych payloadów, komend wymuszających uwierzytelnienie ani instrukcji przejęcia domeny. Aktywna walidacja powinna odbywać się tylko pomiędzy dedykowanymi hostami i kontami testowymi z nieszkodliwymi prawami.

Jak działa NTLM challenge–response?

NTLM jest rodziną protokołów uwierzytelniania używaną przez Windows i wiele urządzeń. W uproszczonym przepływie klient deklaruje możliwości, serwer przesyła wyzwanie, a klient odpowiada wartością wyliczoną z sekretu i danych sesji. Serwer lub kontroler domeny weryfikuje odpowiedź. Hasło nie musi przejść po sieci w postaci jawnej.

Brak hasła na przewodzie nie rozwiązuje problemu relay. Pośrednik nie musi znać sekretu: pobiera wyzwanie od celu, przekazuje je klientowi, a odpowiedź klienta przesyła z powrotem do celu. Jeżeli cel nie potrafi potwierdzić, że uwierzytelnienie zostało wygenerowane dla jego konkretnego kanału lub usługi, może utworzyć sesję dla pośrednika.

NTLMv2 wzmacnia wiele elementów w porównaniu z NTLMv1, ale nie jest ogólną ochroną przed relay. Message Integrity Code, channel binding i podpisywanie protokołu zależą od wariantu, negocjacji i poprawek. Dlatego audyt nie może kończyć się na wartości „LMCompatibilityLevel”. Potrzebna jest macierz klientów, celów i wymaganej ochrony.

Trzy elementy każdego łańcucha relay

1. Źródło uwierzytelnienia

Klient musi wysłać NTLM do hosta kontrolowanego przez pośrednika. Może to wynikać z błędnej nazwy, automatycznego rozpoznawania, odwołania do zdalnego zasobu, funkcji aplikacji pobierającej URL albo mechanizmu RPC, który inicjuje połączenie. Istnienie techniki wymuszającej nie oznacza jeszcze skutecznego relay; jest jedynie pierwszym warunkiem.

W audycie katalogujemy usługi zdolne do inicjowania uwierzytelnienia, strefy sieciowe, polityki outbound SMB/HTTP, rozwiązywanie nazw i konta usług. Szczególnie ważne są konta komputerów serwerów wysokiej wartości, bo ich uprawnienia w katalogu mogą być większe niż zwykłego użytkownika.

2. Cel bez wiązania lub integralności

Usługa docelowa musi zaakceptować uwierzytelnienie bez kontroli, która uniemożliwia przekazanie. Dla SMB kluczowe jest wymaganie podpisu. Dla LDAP zależy to od transportu i mechanizmu: signing zabezpiecza komunikaty SASL, a channel binding zabezpiecza uwierzytelnienie nad TLS. Dla IIS Windows Authentication rolę pełni EPA poprzez channel albo service binding.

3. Użyteczne uprawnienia tożsamości

Relay tworzy sesję w kontekście klienta, nie „automatycznie administratora”. Wpływ zależy od praw na celu. Zwykły użytkownik może mieć tylko odczyt, konto komputera może zarządzać określonym obiektem, a operator usługi — konfiguracją aplikacji. Raport powinien oddzielić możliwość uwierzytelnienia od operacji, które cel faktycznie autoryzuje.

To rozróżnienie zapobiega zawyżaniu wyników skanera. Jednocześnie graf uprawnień może pokazać, że pozornie ograniczona sesja prowadzi do kolejnego kroku, np. zmiany delegacji albo szablonu certyfikatu. Dlatego relay oceniamy razem z bezpieczeństwem Active Directory.

SMB signing: integralność wiadomości i ochrona przed relay

SMB signing używa klucza sesji i algorytmu zależnego od dialektu do podpisania wiadomości. Odbiorca weryfikuje integralność oraz to, że pakiet należy do wynegocjowanej sesji. Relay nie może po prostu używać sesji SMB, jeśli cel wymaga poprawnych podpisów, których pośrednik nie potrafi wytworzyć bez właściwego klucza sesji.

Ważne jest słowo wymaga. Ustawienie „enabled if negotiated” nie gwarantuje ochrony, jeśli druga strona może wynegocjować sesję bez podpisu. Audytujemy oddzielnie zachowanie klienta outbound i serwera inbound oraz realną negocjację dla każdego typu urządzenia. Kontrolery domeny, serwery plików, appliance’y NAS, drukarki i stare systemy mogą mieć różne wartości.

Microsoft wzmocnił domyślne zachowanie w Windows 11 24H2 i Windows Server 2025. Dokumentacja rozróżnia jednak edycje oraz kierunki: nie należy przenosić jednego zdania o „domyślnym signing” na wszystkie hosty. Upgrade zachowujący stare GPO też może różnić się od nowej instalacji. Prawidłowy audyt zbiera konfigurację i potwierdza sesję, a nie wnioskuje wyłącznie z wersji OS.

Szyfrowanie SMB chroni poufność i integralność danych, ale jest osobną kontrolą. Podpisywanie powinno być wymagane niezależnie od tego, czy konkretne udziały wymagają encryption. Wyłączenie signingu dla kompatybilności z urządzeniem legacy otwiera całe miejsce docelowe; bezpieczniej zmodernizować, wymienić albo odizolować urządzenie.

LDAP signing: co dokładnie odrzuca kontroler domeny?

LDAP signing kryptograficznie chroni komunikaty LDAP w sesjach SASL, takich jak Negotiate, Kerberos lub NTLM. Gdy kontroler domeny wymaga signing, odrzuca SASL bind, który nie prosi o integralność, oraz prosty bind wykonywany bez szyfrowanego transportu. Microsoft dokumentuje politykę Domain controller: LDAP server signing requirements i zaleca etap audytu przed egzekwowaniem.

Port 389 nie oznacza automatycznie cleartext: może używać STARTTLS lub SASL signing. Port 636 nie oznacza automatycznie pełnej ochrony przed relay: LDAPS daje TLS, ale jeśli NTLM nad TLS nie jest związany z tym kanałem przez CBT, wybrane scenariusze pozostają możliwe. Raport musi opisywać konkretny bind i jego zabezpieczenie, nie tylko numer portu.

Zdarzenia 2886–2889 pomagają migrować. 2887 daje podsumowanie niebezpiecznych bindów, a po zwiększeniu diagnostyki 2889 wskazuje adres klienta i tożsamość dla pojedynczych przypadków. Wartość tę zbieramy przez pełny cykl biznesowy: miesięczne zadanie albo rzadki system HR może nie pojawić się w krótkim oknie.

Włączenie „Require signing” bez inwentaryzacji może zatrzymać aplikacje, urządzenia sieciowe i skanery. Poprawny proces to observe → identify owner → upgrade/reconfigure → pilot → enforce → monitor rejected binds. Cofnięcie polityki po pierwszym błędzie przywraca ryzyko; lepszy jest formalny wyjątek sieciowy z datą końcową.

LDAP channel binding: dlaczego TLS nie wystarcza?

Channel Binding Token (CBT) wywodzi wartość z właściwości sesji TLS i przekazuje ją w uwierzytelnieniu. Serwer porównuje token z własnym kanałem. Jeżeli pośrednik zakończy jedną sesję TLS z klientem, a utworzy inną do serwera, wartości nie będą pasować. To wiąże uwierzytelnienie warstwy aplikacyjnej z konkretnym tunelem.

Polityka LDAP channel binding ma tryby pozwalające obserwować kompatybilność i wymagać CBT. Microsoft opisuje zdarzenia 3039–3041 dla braku wsparcia, błędu i sukcesu. Przed pełnym egzekwowaniem identyfikujemy klientów NTLM/Simple Bind over TLS, biblioteki nieprzekazujące CBT i urządzenia, których producent nie udostępnia poprawki.

Signing i channel binding rozwiązują różne problemy. LDAP signing zabezpiecza integralność komunikatów SASL. CBT dotyczy związania uwierzytelnienia z TLS. Organizacja może potrzebować obu, zależnie od używanych ścieżek. Nie traktujemy LDAPS jako zamiennika polityki signing bez analizy rodzaju bindu.

EPA w IIS: channel binding i service binding

Extended Protection for Authentication rozszerza Windows Authentication o dwie koncepcje. Channel binding wykorzystuje CBT przede wszystkim w połączeniach TLS. Service binding wykorzystuje SPN, aby klient i serwer uzgodnili właściwą usługę, co jest istotne w scenariuszach bez TLS lub z offloadingiem na reverse proxy/load balancerze.

Konfiguracja EPA wymaga zrozumienia topologii. Przy TLS termination backend może nie widzieć tego samego kanału co klient; niewłaściwy tryb może złamać logowanie lub pozostać nieskuteczny. Inwentaryzujemy SPN, kernel-mode authentication, tożsamość app pool, proxy, host headers i dozwolone scenariusze. Najpierw test w środowisku reprezentatywnym, potem stopniowe enforcement.

AD CS Web Enrollment i CES są szczególnie wrażliwe, bo udana sesja może pozwolić relayowanej tożsamości poprosić o certyfikat dostępnego szablonu. Microsoft Defender for Identity klasyfikuje endpointy bez HTTPS/EPA jako ryzyko ESC8. Pełny model omawiamy w przewodniku ataków certyfikatowych AD CS i klas ESC.

EPA powinno także objąć inne aplikacje IIS korzystające z Windows Authentication: panele administracyjne, narzędzia wdrożeniowe, systemy raportowe. Każdy z nich ma inny wpływ po utworzeniu sesji, dlatego priorytet łączymy z prawami użytkowników i kont komputerów.

Relay między protokołami

Atakujący nie musi przekazywać SMB do SMB. NTLM może zostać odebrane w jednym kontekście i skierowane do LDAP albo HTTP, jeżeli negocjowane właściwości i zabezpieczenia na to pozwalają. Właśnie dlatego sam SMB signing na serwerach plików nie zamyka relay do katalogu lub endpointu WWW.

Obrona wymaga macierzy źródło–cel:

Źródło NTLM	Potencjalny cel	Kontrola docelowa
SMB/UNC	SMB	wymagany SMB signing
SMB/HTTP/RPC	LDAP SASL	wymagany LDAP signing
NTLM nad TLS	LDAPS	LDAP channel binding / CBT
Windows Authentication	IIS HTTPS	EPA channel binding
Windows Authentication za proxy	IIS	poprawny service binding/SPN i architektura EPA

Tabela nie jest listą exploitów. Służy właścicielowi obrony do weryfikacji, czy każda usługa odrzuca uwierzytelnienie przeniesione do innego kontekstu.

Bezpieczna metodologia pentestu NTLM relay

Faza pasywna

Zbieramy polityki NTLM, wymagania SMB signing, ustawienia LDAP signing/channel binding, konfigurację Windows Authentication i EPA, SPN, serwery proxy oraz logi. Identyfikujemy hosty legacy i systemy korzystające z IP/CNAME, które często powodują fallback z Kerberos do NTLM.

Model przepływów

Tworzymy mapę client/service → protocol → destination → authentication package → binding/integrity → effective rights. Potwierdzamy, dlaczego Kerberos nie jest używany: brak SPN, połączenie po IP, alias bez właściwej konfiguracji, brak trustu albo aplikacja wymuszająca NTLM.

Walidacja kontrolowana

Aktywny scenariusz obejmuje tylko host źródłowy, pośredni i cel należące do klienta, dedykowane konto bez praw administracyjnych i nieszkodliwy zasób. Wcześniej ustalamy limity, adresy, monitoring i awaryjne przerwanie. Nie wymuszamy uwierzytelnienia kontrolera domeny, CA ani konta administratora na produkcji.

Dowodem może być potwierdzona negocjacja bez wymaganej ochrony wraz z odczytem testowego zasobu. Jeśli konfiguracja jednoznacznie pozwala na krytyczny łańcuch, aktywne przejęcie nie jest konieczne. Celem pentestu jest zmniejszyć ryzyko, nie maksymalizować wpływ demonstracji.

Cleanup i retest

Rotujemy sekret konta testowego, usuwamy zasoby, przywracamy zatwierdzoną konfigurację i potwierdzamy, że po włączeniu signing/CBT/EPA ten sam negatywny scenariusz jest odrzucony. Weryfikujemy też działanie legalnych klientów.

Detekcja NTLM relay

Najlepsza detekcja łączy anomalne uwierzytelnienie z sesją docelową. Sam event NTLM jest częsty. Szukamy niezgodności: konto komputera uwierzytelnia się z nieoczekiwanego hosta; źródło geograficznie/sieciowo nie odpowiada urządzeniu; jedna tożsamość inicjuje niemal jednocześnie sesje do różnych usług; po uwierzytelnieniu następuje nietypowa zmiana AD albo issuance certyfikatu.

Przydatne źródła to NTLM Operational log, zdarzenia logowania 4624 z pakietem NTLM, 4776 dla walidacji poświadczeń, logi SMB, IIS, Directory Service 2887/2889 i 3039–3041, modyfikacje katalogowe oraz logi AD CS. Microsoft Defender for Identity ma alerty dla wybranych wariantów relay, ale żaden produkt nie zastępuje wymuszenia integralności.

Budujemy alerty korelacyjne:

nowe lub rzadkie NTLM z serwera, który normalnie używa Kerberos;
konto komputera serwera krytycznego logujące się do nietypowego endpointu;
LDAP bind i zaraz potem zmiana ACL, RBCD, grupy albo klucza credential;
HTTP enrollment po nietypowej autentykacji i wydanie certyfikatu;
wzrost 2889/3039 podczas rollout-u oraz próby po enforcement;
wyłączenie SMB signing, LDAP policy albo EPA przez zmianę GPO/IIS.

Logi powinny trafić do odseparowanego SIEM, a konta SOC korzystać z zasad opisanych w bezpieczeństwie Microsoft 365 i PAM.

Migracja z NTLM bez przestoju

Docelowym kierunkiem jest preferowanie Kerberos i nowoczesnych mechanizmów, a następnie ograniczenie lub blokada NTLM. Nie zaczynamy jednak od globalnego deny. Najpierw włączamy audyt, katalogujemy proces, właściciela, cel i przyczynę fallbacku. Naprawiamy SPN oraz DNS, użycie IP i aliasów, konta usług, biblioteki i urządzenia.

Dla wyjątków tworzymy minimalny zakres, segmentację i termin wycofania. Host legacy nie powinien móc inicjować ruchu do kontrolerów domeny i paneli administracyjnych poza tym, co niezbędne. Mikrosegmentacja jest praktycznym elementem Zero Trust, ale nie zastępuje kryptograficznego związania sesji.

Rollout kontroli wykonujemy falami:

audit NTLM, unsigned LDAP i brak CBT;
wymagany SMB signing na zasobach krytycznych;
naprawa klientów LDAP i wymuszenie server signing;
channel binding dla LDAPS po okresie obserwacji;
EPA na endpointach IIS, najpierw AD CS i administracja;
ograniczanie outbound NTLM i reguły wyjątków;
monitoring odrzuceń oraz usuwanie wyjątków.

Checklista anty-relay

Wniosek

NTLM relay jest problemem kontekstu: odpowiedź kryptograficznie poprawna dla użytkownika zostaje użyta w niewłaściwej sesji lub usłudze. Skuteczna obrona wymaga, aby każdy cel potrafił powiedzieć nie tylko „to właściwa tożsamość”, ale także „to uwierzytelnienie należy do tego kanału i tej usługi”.

Jeżeli potrzebujesz mapy ekspozycji, bezpiecznego pilota signing/CBT/EPA albo technicznego retestu po migracji, skontaktuj się z Breachroad. Ocena pokaże realne warunki, wpływ praw i telemetryczne punkty kontrolne bez gotowych technik wymuszenia uwierzytelnienia.