Ataki przekaźnikowe NTLM (NTLM relay attacks) to jeden z najprostszych i najskuteczniejszych sposobów naruszenia bezpieczeństwa hostów podłączonych do domeny. Choć wielu specjalistów ds. bezpieczeństwa uważa ten problem za rozwiązany, w rzeczywistości sytuacja wciąż budzi poważne obawy – a nawet się pogarsza. Z doświadczenia wiemy, że ataki te są obecne w większości incydentów bezpieczeństwa i w ostatnich latach znacznie zyskały na powszechności.
W podatnych środowiskach NTLM umożliwia przemieszczenie się atakującego „poziomo” (lateral movement) oraz eskalację uprawnień. Co ważne, ataki te są inicjowane przez uwierzytelnionych użytkowników, co oznacza, że mogą prowadzić do przejęcia uprawnień domenowych – z potencjalnie krytycznymi konsekwencjami.
Przypomnijmy podstawy
NTLM to przestarzały protokół uwierzytelniania, opracowany w latach 90. XX wieku. Obecnie preferowanym mechanizmem uwierzytelniania w środowiskach Active Directory jest Kerberos. Niemniej gdy Kerberos nie jest dostępny, NTLM wciąż bywa stosowany. Co więcej, wiele aplikacji zostało zaprojektowanych tak, by wymuszać użycie NTLM, zamiast stosować pakiet Negotiate, który automatycznie wybiera najlepszy dostępny protokół (Kerberos lub NTLM).
Proces uwierzytelniania NTLM składa się z trzech komunikatów: Negotiate, Challenge i Authenticate. Klient inicjuje uwierzytelnienie, serwer odpowiada losowym wyzwaniem, a klient przesyła odpowiedź kryptograficzną potwierdzającą jego tożsamość. Mechanizm ten zapobiega atakom typu replay (powtórzona kryptografia), ponieważ każda wymiana danych jest unikalna.
NTLM jest za to podatny na ataki przekaźnikowe, w których atakujący przekazuje wiadomości uwierzytelniające pomiędzy ofiarą a serwerem aż do momentu nawiązania sesji. W efekcie atakujący może wykonać dowolne operacje z uprawnieniami ofiary – bez konieczności łamania haseł. Sprawia to, że NTLM jest wyjątkowo atrakcyjnym celem. Można zapytać, czy atak relay nie wymaga, by ofiara spróbowała się uwierzytelnić w odpowiednim momencie. Niekoniecznie. Tego typu ataki często łączone są z technikami wymuszającymi uwierzytelnienie, takimi jak Printer Bug czy PetitPotam (które zmuszają ofiarę do natychmiastowej próby uwierzytelnienia). Co istotne, techniki te mogą być stosowane przez dowolnego uwierzytelnionego użytkownika, co czyni atak łatwym do przeprowadzenia.
Cele ataków NTLM Relay
Ataki na protokół NTLM mają trzy podstawowe powszechne zastosowania:
1. Serwery SMB
Udany atak relay na serwer SMB umożliwia nawiązanie sesji z uprawnieniami ofiary. Dalsze działania atakującego zależą od poziomu dostępu, jaki posiada ofiara. Mogą obejmować m.in.:
- dostęp do udziałów systemowych, takich jak C$ czy ADMIN$,
- zrzut tajnych danych LSA z rejestru zdalnego, w tym hasła konta komputera,
- ruch boczny przy użyciu Menedżera Kontroli Usług (SCM).
Często spotykany scenariusz obejmuje wymuszenie uwierzytelnienia na serwerze lokalizacji SCCM i przekaźnik do serwera bazy danych SCCM – co prowadzi do przejęcia całej infrastruktury SCCM. Większość hostów z systemem Windows – szczególnie serwery – jest podatna na tego typu ataki. Microsoft podejmuje działania zmierzające do ich ograniczenia: kontrolery domeny od systemu Windows Server 2008 oraz wszystkie hosty od wersji Windows Server 2025 i Windows 11 domyślnie wymagają podpisywania SMB, co uniemożliwia relaying NTLM. W starszych wersjach systemu funkcja ta jest jednak domyślnie wyłączona, a wiele organizacji jej nie aktywuje.
2. LDAP / LDAPS
Ataki na LDAP lub LDAPS są bardziej złożone niż ataki na SMB, ale potrafią być równie skuteczne. Obecnie większość kontrolerów domeny jest podatna na relaying NTLM za pośrednictwem LDAP.
Zabezpieczenia przed tego typu atakami obejmują:
- podpisywanie LDAP (LDAP signing),
- wiązanie kanałów LDAP (LDAP channel binding).
Aby były skuteczne, oba te mechanizmy muszą być wymuszone – jednak domyślnie nie są, a większość organizacji pozostawia te ustawienia bez zmian. Co istotne, są to ustawienia konfigurowane na poziomie kontrolera domeny, a nie całej domeny – co oznacza, że różne DC w tym samym środowisku mogą mieć różne konfiguracje. Na szczęście od wersji Windows Server 2025 kontrolery domeny domyślnie wymuszają szyfrowanie (sealing) sesji LDAP SASL, co sprawia, że relaying do LDAP lub LDAPS przestaje być możliwy. Wraz z upowszechnieniem tej wersji systemu ryzyko ataku powinno się zmniejszyć.
3. Web Enrollment w ADCS (atak ESC8)
Relaying do usług certyfikatów Active Directory (ADCS) jest technicznie bardziej wymagający niż ataki na SMB, ponieważ nadużycie certyfikatu wymaga spełnienia wielu warunków. Sama logika przekaźnikowa pozostaje jednak stosunkowo prosta.
Atakujący może przekazać uwierzytelnienie do usługi web enrollment w ADCS i uzyskać certyfikat dla ofiary, który następnie posłuży do podszycia się pod nią. Technika ta została odkryta i opisana przez Willa Schroedera i Lee Chagolla-Christensena w publikacji Certified Pre-Owned. Jeżeli urząd certyfikacji (CA) jest podatny na relay, każde urządzenie zdolne do zapisania się na odpowiedni szablon certyfikatu jest zagrożone. Warto podkreślić, że domyślny szablon certyfikatu „Machine” spełnia warunki tego ataku, co oznacza, że potencjalnie zagrożone są wszystkie komputery w domenie.
Słowo na koniec
Microsoft pracuje nad kilkoma sposobami zapobiegania powyższym atakom, w tym nad domyślnym wyłączeniem protokołu NTLM. Jest to jednak kwestia co najmniej kilku lat. Najlepszy sposób ochrony przed atakami retransmisyjnymi w najbliższej przyszłości to zapewnienie, że wszystkie serwery będą wymuszać podpisywanie i wiązanie kanałów uwierzytelniania. Jest to uciążliwe dla serwerów, które nie obsługują tych funkcji, dlatego najlepiej precyzyjnie określić, które funkcje mają być wymuszane na poszczególnych serwerach. Zalecamy ocenę środowisk pod kątem ataków retransmisyjnych NTLM i ciągłe priorytetyzowanie celów o wysokim ryzyku.