CodeKitHub
Kodningsverktyg

NTLM-hashgenerator

Senast uppdaterad:

En NTLM-hash beräknas genom att koda din indata som UTF-16LE (2 byte per tecken, little-endian) och sedan köra den genom meddelandesammandragsalgoritmen MD4 — den enkelriktade, osaltade operationen är hela det NTLM-hashningsschema som Microsoft Windows har använt sedan NT 4.0 för att lagra lösenordsverifierare. Det här verktyget utför exakt den beräkningen lokalt i din webbläsare, helt i JavaScript, så att inget du skriver någonsin skickas till en server. Det finns för legitimt säkerhetsarbete — att verifiera NTLM-hashexporter från Active Directory, kontrollera utdataformat från hashcat eller Mimikatz, eller lösa CTF- och pentesting-labbutmaningar — inte för att attackera konton du varken äger eller har tillstånd att testa.

NTLM Hash

Vad är detta verktyg?

NTLM (NT LAN Manager) är Microsofts äldre challenge-response-autentiseringsprotokoll, som fortfarande används idag för lokala Windows-kontoinloggningar och som reservlösning i många Active Directory-miljöer. Dess lösenordsverifierare — vanligen kallad "NTLM-hashen" — definieras i Microsofts egen MS-NLMP-protokollspecifikation som `MD4(UTF-16-LE(password))`: lösenordet kodas först som UTF-16 little-endian (så att varje tecken blir 2 byte, till skillnad från UTF-8), och den byte-sekvensen hashas sedan en gång med MD4-algoritmen från RFC 1320.

UTF-16LE-steget är den detalj som flest gör fel när de återimplementerar NTLM från grunden: att hasha UTF-8-byten för en sträng istället för dess UTF-16LE-byte ger ett helt annat, felaktigt sammandrag, även om den synliga texten ser identisk ut. Det här verktyget kodar korrekt, så dess utdata matchar det som Windows själv lagrar och det som verktyg som hashcat (läge 1000) och Mimikatz förväntar sig.

Eftersom NTLM föregår modern design för lösenordshashning saknar det alla de skydd som senare byggdes specifikt för att bromsa knäckning: inget salt per användare, ingen konfigurerbar arbetsfaktor och ingen avsiktlig iteration. Det är en enda MD4-passering, vilket gör den extremt snabb att beräkna — en egenskap som är praktisk för bakåtkompatibilitet men förödande när det gäller att motstå brute-force- och ordlisteattacker.

Varför använda det?

  • Verifiera att en hash som extraherats från en Windows SAM-databas, en NTDS.dit-dump eller en Active Directory-export matchar ett förväntat värde under auktoriserad säkerhetstestning.
  • Bekräfta din förståelse av MS-NLMP-algoritmen, eller kontrollera en hash som din egen kod har producerat mot en känt korrekt implementation.
  • Generera NTLM-hashar för hashcat (`-m 1000`) eller ordlistetestning i John the Ripper i ett labb eller en CTF-miljö du har tillstånd att attackera.
  • Korskontrollera utdata från Mimikatz eller andra pentesting-verktyg under legitima red team- eller uppdragsgranskningar av autentiseringsuppgifter.
  • 100 % lokalt: din indata lämnar aldrig webbläsaren, så det är säkert att använda även för känsligt autentiseringsmaterial i en auktoriserad bedömning.

Så använder du det

  1. Skriv lösenordet eller strängen du vill hasha i inmatningsfältet.
  2. Klicka på "Generate NTLM Hash".
  3. Läs den 32-teckens hexadecimala NTLM-hashen (utdata med versaler är aktiverat som standard, i linje med hur Windows och de flesta knäckningsverktyg visar den — avmarkera rutan för gemener).
  4. Klicka på "Copy" för att kopiera hashen till urklipp.

Exempel

Inmatning

password

Resultat

8846F7EAEE8FB117AD06BDD830B7586C

Det här är en välkänd, oberoende verifierbar testvektor: NTLM-hashen för den bokstavliga strängen "password" är alltid 8846F7EAEE8FB117AD06BDD830B7586C. Du kan jämföra det här verktygets utdata med vilken annan korrekt NTLM-implementation som helst.

NTLM jämfört med modern lösenordshashning

Tabellen nedan belyser varför NTLM anses föråldrat för att skydda nya system, trots att det fortfarande finns inbäddat i äldre Windows- och Active Directory-infrastruktur.

EgenskapNTLMbcrypt / scrypt / Argon2
Underliggande primitivEnda MD4-passeringÄndamålsbyggd långsam hash med justerbar kostnad
SaltningIngen — identiska lösenord ger alltid identisk hashUnikt slumpmässigt salt per lösenord
Iteration / stretchingIngenJusterbar arbetsfaktor, kan höjas över tid
Motstånd mot brute-forceMycket svagt — miljarder gissningar/sek på moderna GPU:erMedvetet kostsamt per gissning
Var det fortfarande finnsÄldre Windows-autentisering, Active Directory-reservNya applikationer, aktuell bästa praxis

Relaterade verktyg

Om du behöver en allmän kryptografisk hash istället för den NTLM-specifika MD4(UTF-16LE)-konstruktionen kan dessa verktyg passa bättre.

Hashgenerator med flera algoritmer · MD5-generator · Lösenordsgenerator

Vanliga frågor

Vad är egentligen en NTLM-hash?

Det är den lösenordsverifierare som Windows beräknar och lagrar för NT LAN Manager-autentisering, definierad i Microsofts MS-NLMP-specifikation som MD4(UTF-16LE(password)) — en enda MD4-passering över lösenordets UTF-16 little-endian byte-kodning. Den är alltid 128 bitar, visad som 32 hexadecimala tecken.

Varför specifikt UTF-16LE, och inte UTF-8 eller ASCII?

Windows har lagrat text internt som UTF-16LE sedan NT designades, så lösenord kodas på samma sätt innan de hashas. Varje tecken blir 2 byte (little-endian byte-ordning), inklusive vanliga ASCII-tecken som 'a', som blir 0x61 0x00 istället för bara 0x61. Att hasha UTF-8-byten för samma sträng ger ett helt annat, felaktigt resultat — det här är det absolut vanligaste felet i NTLM-implementationer skrivna från grunden.

Är NTLM säkert att använda idag?

Nej, och Microsoft självt rekommenderar att man går över till Kerberos där det är möjligt. NTLM har inget salt, så identiska lösenord ger alltid identiska hashar hos varje användare och system, vilket möjliggör uppslag via förberäknade rainbow-tabeller. Det saknar också iteration eller arbetsfaktor — en enda osaltad MD4-passering — så moderna GPU:er kan pröva miljarder gissningar per sekund mot en fångad hash. Den lever kvar främst för bakåtkompatibilitet med äldre Windows-system och applikationer.

Hur skiljer sig NTLM från modern lösenordshashning som bcrypt, scrypt eller Argon2?

Moderna lösenordshashare är medvetet långsamma och saltade: bcrypt, scrypt och Argon2 lägger var och en till ett unikt slumpmässigt salt per lösenord och en justerbar kostnadsfaktor som kan höjas med tiden när hårdvaran blir snabbare, specifikt för att göra brute-force dyrt även i stor skala. NTLM gör varken det ena eller det andra — det designades i en tid innan offline brute-force var ett praktiskt hotscenario, och det märks. Det är precis därför NTLM aldrig bör användas för att skydda något som utformas idag; det här verktygets verkliga användningsområden är kompatibilitet med befintlig Windows-infrastruktur och auktoriserad säkerhetstestning, inte att bygga nya system.

Vilka är de legitima användningsområdena för en NTLM-hashgenerator?

Att verifiera hashar hämtade från en SAM-databas eller NTDS.dit under ett auktoriserat penetrationstest eller en granskning av autentiseringsuppgifter; kontrollera att ditt eget verktyg eller skript implementerar MS-NLMP korrekt; generera testhashar för hashcat (läge 1000) eller kompatibilitetskontroller med Mimikatz-format i ett labb du kontrollerar; samt att arbeta igenom CTF- eller utbildningsövningar som uttryckligen involverar NTLM. Att använda det här verktyget för att attackera konton eller system du varken äger eller har skriftligt tillstånd att testa är inte en legitim användning.

Skickas mitt lösenord eller min indata till en server?

Nej. MD4-beräkningen körs helt i JavaScript i din webbläsare — det finns inget inbyggt webbläsar-API för MD4, så det är implementerat direkt i sidans klientkod, och inget du skriver överförs någonstans.

Relaterade verktyg