CodeKitHubCzym jest to narzędzie?
NTLM (NT LAN Manager) to starszy protokół uwierzytelniania typu challenge-response firmy Microsoft, wciąż używany do lokalnych logowań kont Windows i jako mechanizm zapasowy w wielu środowiskach Active Directory. Jego weryfikator hasła — potocznie zwany „hashem NTLM” — jest zdefiniowany we własnej specyfikacji Microsoftu MS-NLMP jako `MD4(UTF-16-LE(password))`: hasło jest najpierw kodowane jako UTF-16 little-endian (więc każdy znak staje się 2 bajtami, inaczej niż w UTF-8), a ta sekwencja bajtów jest następnie hashowana raz algorytmem MD4 z RFC 1320.
Krok kodowania UTF-16LE to szczegół, który najczęściej ktoś pomija, reimplementując NTLM od zera: zahashowanie bajtów UTF-8 tego samego ciągu znaków daje zupełnie inny, błędny digest, mimo że widoczny tekst wygląda identycznie. To narzędzie koduje poprawnie, więc jego wynik zgadza się z tym, co przechowuje sam Windows, oraz z tym, czego oczekują narzędzia takie jak hashcat (tryb 1000) czy Mimikatz.
Ponieważ NTLM powstał przed nowoczesnymi standardami hashowania haseł, nie ma żadnych zabezpieczeń zaprojektowanych specjalnie po to, by spowolnić łamanie: brak soli per użytkownik, brak konfigurowalnego współczynnika pracy i brak celowej iteracji. To pojedyncze przejście MD4, co czyni obliczenie ekstremalnie szybkim — cecha wygodna dla kompatybilności wstecznej, ale katastrofalna z punktu widzenia odporności na ataki brute-force i słownikowe.
Dlaczego warto go używać?
- Właśnie napisałeś funkcję w Pythonie, która ma implementować MD4(UTF-16LE(hasło)) dla wewnętrznego narzędzia audytowego, ale zwracana wartość nie zgadza się z oczekiwaną — wklejasz to samo hasło tutaj, porównujesz wynik referencyjny i w trzydzieści sekund wiesz, czy błąd tkwi w kodowaniu UTF-16LE, czy w implementacji MD4.
- Podczas autoryzowanego testu penetracyjnego wydobyłeś hash ze zrzutu NTDS.dit i chcesz szybko sprawdzić — zanim uruchomisz hashcat na całej liście słów — czy konkretne kandydujące hasło daje dokładnie ten hash.
- Przygotowujesz materiały szkoleniowe o NTLM na kurs bezpieczeństwa i chcesz pokazać na żywo, jak ten sam tekst daje zupełnie inne hashe w zależności od tego, czy zostanie zakodowany w UTF-8 czy UTF-16LE przed MD4.
- Kolega przesłał Ci hash NTLM z prośbą o sprawdzenie go wobec znanego hasła w laboratorium CTF, które wspólnie rozwiązujecie — generujesz tutaj hash kandydującego hasła i porównujesz znak po znaku z otrzymanym.
- Musisz udokumentować w raporcie z audytu bezpieczeństwa, dlaczego przestarzała domena Active Directory jest podatna — generujesz hash NTLM tego samego hasła dwukrotnie na różnych kontach, by wizualnie pokazać brak solenia, kluczowy punkt Twojego raportu.
- Konfigurujesz hashcat w trybie 1000 po raz pierwszy i chcesz pewnej wartości referencyjnej przed uruchomieniem prawdziwego ataku — używasz znanego wektora testowego „password”, by potwierdzić, że Twoja konfiguracja hashcat daje ten sam wynik co to narzędzie.
Jak używać
- Wpisz hasło lub ciąg znaków, który chcesz zahashować, w polu wejściowym.
- Kliknij "Generate NTLM Hash".
- Odczytaj 32-znakowy heksadecymalny hash NTLM (domyślnie wynik jest wielkimi literami, tak jak wyświetla go Windows i większość narzędzi do łamania haseł — odznacz opcję, by uzyskać małe litery).
- Kliknij "Copy", aby skopiować hash do schowka.
Przykład
Wejście
passwordWynik
8846F7EAEE8FB117AD06BDD830B7586CTo dobrze znany, niezależnie weryfikowalny wektor testowy: hash NTLM dosłownego ciągu "password" zawsze wynosi 8846F7EAEE8FB117AD06BDD830B7586C. Możesz porównać wynik tego narzędzia z dowolną inną poprawną implementacją NTLM.
NTLM a nowoczesne hashowanie haseł
Poniższa tabela pokazuje, dlaczego NTLM uznaje się za przestarzały do zabezpieczania nowych systemów, mimo że wciąż jest głęboko osadzony w starszej infrastrukturze Windows i Active Directory.
| Cecha | NTLM | bcrypt / scrypt / Argon2 |
|---|---|---|
| Podstawowy prymityw | Pojedyncze przejście MD4 | Celowo powolny hash z konfigurowalnym kosztem |
| Solenie | Brak — identyczne hasła zawsze dają identyczny hash | Unikalna losowa sól dla każdego hasła |
| Iteracja / rozciąganie | Brak | Konfigurowalny współczynnik pracy, zwiększalny z czasem |
| Odporność na brute-force | Bardzo słaba — miliardy prób/s na nowoczesnych GPU | Celowo kosztowna dla każdej próby |
| Gdzie wciąż występuje | Starsze uwierzytelnianie Windows, mechanizm zapasowy Active Directory | Nowe aplikacje, aktualne najlepsze praktyki |
Powiązane narzędzia
Jeśli potrzebujesz uniwersalnego skrótu kryptograficznego zamiast specyficznej dla NTLM konstrukcji MD4(UTF-16LE), te narzędzia mogą lepiej pasować do twoich potrzeb.
→ Generator hashy dla wielu algorytmów · Generator MD5 · Generator haseł
Częste błędy przy reimplementacji NTLM od zera
Jeśli piszesz własny kod do obliczania hashy NTLM (do narzędzia audytowego, testu jednostkowego lub żeby lepiej zrozumieć protokół), to najczęstsze pułapki, w które wpada niemal każdy.
- Kodowanie hasła w UTF-8 zamiast UTF-16LE przed zastosowaniem MD4 — pojedynczy najczęstszy błąd, ponieważ większość języków programowania używa UTF-8 jako domyślnego kodowania ciągów znaków.
- Użycie złej kolejności bajtów (big-endian zamiast little-endian) podczas kodowania UTF-16 — znak „A” musi stać się 0x41 0x00, nie 0x00 0x41.
- Mylenie NTLM z NTLMv2 lub z odpowiedzią challenge-response używaną w uwierzytelnianiu sieciowym: to narzędzie oblicza wyłącznie statyczny hash NT hasła, a nie cały wieloetapowy proces uwierzytelniania.
- Stosowanie kilku przejść MD4 zamiast jednego, czasem z przyzwyczajenia z innych, iterowanych schematów hashowania — NTLM wyraźnie określa pojedyncze przejście, bez iteracji.
Najczęściej zadawane pytania
Czym dokładnie jest hash NTLM?
To weryfikator hasła, który Windows oblicza i przechowuje na potrzeby uwierzytelniania NT LAN Manager, zdefiniowany w specyfikacji MS-NLMP firmy Microsoft jako MD4(UTF-16LE(password)) — pojedyncze przejście MD4 po bajtowym kodowaniu hasła w UTF-16 little-endian. Zawsze ma 128 bitów, przedstawianych jako 32 znaki hex.
Dlaczego akurat UTF-16LE, a nie UTF-8 czy ASCII?
Windows przechowuje tekst wewnętrznie jako UTF-16LE od czasów projektowania NT, więc hasła są tak samo kodowane przed hashowaniem. Każdy znak staje się 2 bajtami (kolejność little-endian), łącznie ze zwykłymi znakami ASCII, jak 'a', które stają się 0x61 0x00 zamiast samego 0x61. Zahashowanie bajtów UTF-8 tego samego ciągu daje zupełnie inny, błędny wynik — to najczęstszy błąd w implementacjach NTLM pisanych od zera.
Czy NTLM jest dziś bezpieczny w użyciu?
Nie, i sam Microsoft zaleca odchodzenie od niego na rzecz Kerberosa tam, gdzie to możliwe. NTLM nie ma soli, więc identyczne hasła zawsze dają identyczne hashe na każdym koncie i systemie, co umożliwia ataki z użyciem wcześniej obliczonych rainbow tables. Nie ma też iteracji ani współczynnika pracy — to pojedyncze, niesolone przejście MD4 — więc nowoczesne GPU potrafią próbować miliardy zgadnięć na sekundę wobec przechwyconego hasha. Przetrwał głównie dzięki kompatybilności wstecznej ze starszymi systemami i aplikacjami Windows.
Czym NTLM różni się od nowoczesnego hashowania haseł, jak bcrypt, scrypt czy Argon2?
Nowoczesne funkcje hashujące hasła są celowo powolne i solone: bcrypt, scrypt i Argon2 dodają unikalną losową sól dla każdego hasła oraz konfigurowalny współczynnik kosztu, który można z czasem zwiększać wraz z rozwojem sprzętu, właśnie po to, by brute-force był kosztowny nawet na dużą skalę. NTLM nie robi żadnej z tych rzeczy — powstał w epoce, zanim offline'owy brute-force stał się praktycznym zagrożeniem, i to widać. Dlatego właśnie NTLM nigdy nie powinien być używany do zabezpieczania czegokolwiek projektowanego dziś; realne zastosowania tego narzędzia to kompatybilność z istniejącą infrastrukturą Windows i autoryzowane testy bezpieczeństwa, a nie budowa nowych systemów.
Jakie są legalne zastosowania generatora hashy NTLM?
Weryfikacja hashy wydobytych z bazy SAM lub NTDS.dit podczas autoryzowanego testu penetracyjnego lub audytu poświadczeń; sprawdzanie, czy twoje własne narzędzia lub skrypty poprawnie implementują MS-NLMP; generowanie hashy testowych do sprawdzania zgodności z hashcat (tryb 1000) lub formatem Mimikatz w kontrolowanym laboratorium; oraz praca nad zadaniami CTF czy szkoleniowymi wyraźnie dotyczącymi NTLM. Użycie tego narzędzia do atakowania kont lub systemów, których nie posiadasz lub do testowania których nie masz pisemnej autoryzacji, nie jest legalnym zastosowaniem.
Czy moje hasło lub dane wejściowe są wysyłane na serwer?
Nie. Obliczenie MD4 wykonywane jest w całości w JavaScripcie w twojej przeglądarce — nie istnieje natywne API przeglądarki dla MD4, więc jest ono zaimplementowane bezpośrednio w kodzie klienckim tej strony, a nic, co wpiszesz, nigdzie nie jest przesyłane.
Dlaczego mój kod używający MD4(UTF-8(hasło)) nie daje takiego samego hasha jak to narzędzie?
To najczęstszy błąd implementacji NTLM: jeśli zakodujesz hasło w UTF-8 zamiast UTF-16LE przed przekazaniem go do MD4, otrzymasz zupełnie inny skrót, mimo że wyświetlany tekst jest identyczny. Sprawdź, czy Twoja funkcja kodująca produkuje 2 bajty na znak w kolejności little-endian przed przekazaniem ich do MD4.
Dlaczego hash NTLM zawsze ma dokładnie 32 znaki hex, niezależnie od długości hasła?
Ponieważ MD4 zawsze produkuje stały 128-bitowy skrót, wyświetlany jako 32 cyfry hex (16 bajtów × 2 cyfry na bajt), niezależnie od tego, czy dane wejściowe to 3-znakowe hasło, czy ciąg tysięcy znaków. To właściwość wszystkich kryptograficznych funkcji skrótu, nie tylko MD4.
Czy hash NTLM pustego ciągu znaków też jest prawidłową wartością?
Tak — nawet pusty ciąg zakodowany w UTF-16LE (co daje zero bajtów) jest nadal przepuszczany przez MD4, dając prawidłowy 32-znakowy hash. Ta konkretna wartość odpowiada hashowi NTLM konta z pustym hasłem, szczegół często przywoływany w audytach bezpieczeństwa.
Czy mogę użyć tego narzędzia do złamania posiadanego hasha NTLM zamiast wygenerować go z znanego hasła?
Nie, to narzędzie działa tylko w jedną stronę: od hasła do hasha, nie odwrotnie. NTLM to hash kryptograficzny i nie da się go matematycznie odwrócić — prawdziwe łamanie polega na generowaniu hashy z milionów kandydujących haseł (za pomocą narzędzi jak hashcat) i porównywaniu ich z hashem docelowym, a nie na odwracaniu funkcji.