NTLM-Hash-Generator

Ein NTLM-Hash entsteht, indem die Eingabe als UTF-16LE kodiert (2 Byte pro Zeichen, Little-Endian) und anschließend durch den MD4-Message-Digest-Algorithmus geschickt wird — diese eine, ungesalzene Operation ist das gesamte NTLM-Hashing-Verfahren, das Microsoft Windows seit NT 4.0 zum Speichern von Passwortverifikatoren nutzt. Dieses Tool führt genau diese Berechnung lokal in deinem Browser aus, vollständig in JavaScript, sodass nichts von dem, was du eingibst, jemals an einen Server gesendet wird. Es dient legitimer Sicherheitsarbeit — dem Prüfen von Active-Directory-Hash-Exporten, dem Kontrollieren von hashcat- oder Mimikatz-Ausgabeformaten oder dem Bearbeiten von CTF- und Pentesting-Lab-Aufgaben —, nicht dem Angriff auf Konten, die dir nicht gehören oder für die du keine Testberechtigung hast.

Was ist dieses Tool?

NTLM (NT LAN Manager) ist Microsofts älteres Challenge-Response-Authentifizierungsprotokoll, das bis heute für lokale Windows-Anmeldungen und als Fallback in vielen Active-Directory-Umgebungen genutzt wird. Sein Passwortverifikator — gemeinhin „der NTLM-Hash“ genannt — ist in Microsofts eigener MS-NLMP-Protokollspezifikation als `MD4(UTF-16-LE(password))` definiert: Das Passwort wird zunächst als UTF-16 Little-Endian kodiert (jedes Zeichen wird so zu 2 Byte, anders als bei UTF-8), und diese Byte-Sequenz wird dann einmal mit dem MD4-Algorithmus aus RFC 1320 gehasht.

Der UTF-16LE-Schritt ist das Detail, das bei einer eigenen NTLM-Implementierung am häufigsten falsch gemacht wird: Wer stattdessen die UTF-8-Bytes einer Zeichenfolge hasht, erhält einen völlig anderen, falschen Digest — auch wenn der sichtbare Text identisch aussieht. Dieses Tool kodiert korrekt, sodass die Ausgabe genau dem entspricht, was Windows selbst speichert und was Tools wie hashcat (Modus 1000) und Mimikatz erwarten.

Da NTLM älter ist als modernes Passwort-Hashing-Design, fehlen ihm sämtliche Schutzmechanismen, die später gezielt entwickelt wurden, um das Knacken zu verlangsamen: kein benutzerspezifisches Salt, kein konfigurierbarer Arbeitsfaktor, keine bewusste Iteration. Es ist ein einziger MD4-Durchlauf, was die Berechnung extrem schnell macht — praktisch für die Kompatibilität mit Altsystemen, aber katastrophal in Bezug auf die Widerstandsfähigkeit gegen Brute-Force- und Wörterbuchangriffe.

Warum sollte man es nutzen?

Du bist mitten in einem autorisierten Pentest, hast gerade die NTDS.dit des Domain Controllers gedumpt und musst schnell bestätigen, dass ein bestimmter Hash zu dem Passwort passt, das du gerade mit hashcat geknackt hast — ohne irgendetwas auf einen Online-Dienst hochzuladen.
Du hast ein eigenes Python-Skript zur NTLM-Hash-Berechnung geschrieben, und das Ergebnis stimmt nicht mit Mimikatz überein — du brauchst eine verlässliche Referenzimplementierung, um zu isolieren, ob der Fehler in deiner UTF-16LE-Kodierung liegt oder woanders.
Du bereitest ein Sicherheits-Trainingslab für dein Team vor und musst mehrere NTLM-Hashes von Beispielpasswörtern erzeugen, damit das Team mit hashcat im Modus 1000 üben kann, ohne echte Credentials preiszugeben.
Du löst eine CTF-Challenge, die verlangt, den NTLM-Hash eines bestimmten Strings zu erzeugen, bevor du zur nächsten Phase weiterkommst.
Du prüfst die Altkonfiguration eines Active Directory und musst manuell verifizieren, ob ein altes Dienstkonto noch ein bekanntes, schwaches Passwort verwendet.
100 % lokal: Deine Eingabe verlässt den Browser nie, weshalb sich das Tool auch für sensibles Credential-Material im Rahmen einer autorisierten Prüfung eignet.

Anleitung

Gib das Passwort oder den zu hashenden Text in das Eingabefeld ein.
Klicke auf „NTLM-Hash generieren“.
Lies den 32-stelligen hexadezimalen NTLM-Hash ab (Großschreibung ist standardmäßig aktiviert, so wie Windows und die meisten Cracking-Tools ihn anzeigen — für Kleinschreibung die Checkbox deaktivieren).
Klicke auf „Kopieren“, um den Hash in die Zwischenablage zu übernehmen.

Beispiel

Eingabe

password

Ausgabe

8846F7EAEE8FB117AD06BDD830B7586C

Dies ist ein bekannter, unabhängig überprüfbarer Testvektor: Der NTLM-Hash der wörtlichen Zeichenfolge „password“ lautet immer 8846F7EAEE8FB117AD06BDD830B7586C. Du kannst die Ausgabe dieses Tools mit jeder anderen korrekten NTLM-Implementierung vergleichen.

NTLM im Vergleich zu modernem Passwort-Hashing

Die folgende Tabelle zeigt, warum NTLM für den Schutz neuer Systeme als veraltet gilt, obwohl es weiterhin fest in älterer Windows- und Active-Directory-Infrastruktur verankert ist.

Eigenschaft	NTLM	bcrypt / scrypt / Argon2
Zugrunde liegende Primitive	Einzelner MD4-Durchlauf	Speziell für Langsamkeit entwickelter Hash mit einstellbaren Kosten
Salting	Keins — identische Passwörter ergeben immer identische Hashes	Eindeutiges zufälliges Salt pro Passwort
Iteration / Stretching	Keine	Konfigurierbarer Arbeitsfaktor, im Lauf der Zeit erhöhbar
Brute-Force-Widerstand	Sehr schwach — Milliarden Versuche/Sekunde auf aktuellen GPUs	Bewusst kostspielig pro Versuch
Wo es noch vorkommt	Ältere Windows-Authentifizierung, Active-Directory-Fallback	Neue Anwendungen, aktueller Best-Practice-Standard

Häufige Fehler bei einer eigenen NTLM-Implementierung

UTF-8 statt UTF-16LE vor dem MD4 kodieren — der häufigste Fehler, der einen korrekt aussehenden (32-stelligen Hex-)Hash liefert, der aber völlig falsch ist.
Vergessen, dass MD4 nicht MD5 ist: unterschiedliche Algorithmen mit unterschiedlichen Ausgaben, obwohl beide einen 128-Bit-Digest liefern — versehentlich eine MD5-Bibliothek zu verwenden ist ein sehr verbreiteter stiller Fehler.
Die Little-Endian-Byte-Reihenfolge innerhalb jedes UTF-16-Paars nicht prüfen — manche Sprachen verwenden standardmäßig Big-Endian, Little-Endian muss dann explizit erzwungen werden.
Den Basis-NTLM-Hash mit dem NTLMv2-Sitzungs-Hash verwechseln — das sind unterschiedliche Berechnungen, und Letzterer hängt von einer Server-Challenge ab, die sich nicht allein aus dem Passwort reproduzieren lässt.

Häufig gestellte Fragen

Was genau ist ein NTLM-Hash?

Es ist der Passwortverifikator, den Windows für die NT-LAN-Manager-Authentifizierung berechnet und speichert, definiert in Microsofts MS-NLMP-Spezifikation als MD4(UTF-16LE(password)) — ein einzelner MD4-Durchlauf über die UTF-16-Little-Endian-Byte-Kodierung des Passworts. Er ist immer 128 Bit lang und wird als 32 Hexadezimalzeichen dargestellt.

Warum genau UTF-16LE und nicht UTF-8 oder ASCII?

Windows speichert Text intern seit dem Design von NT als UTF-16LE, daher werden auch Passwörter vor dem Hashen so kodiert. Jedes Zeichen wird zu 2 Byte (in Little-Endian-Reihenfolge), auch einfache ASCII-Zeichen wie „a“, das dadurch zu 0x61 0x00 statt nur 0x61 wird. Wer stattdessen die UTF-8-Bytes derselben Zeichenfolge hasht, erhält ein völlig anderes, falsches Ergebnis — das ist der mit Abstand häufigste Fehler bei selbst geschriebenen NTLM-Implementierungen.

Ist NTLM heute noch sicher einsetzbar?

Nein, und Microsoft selbst empfiehlt, wo immer möglich auf Kerberos umzusteigen. NTLM verwendet kein Salt, sodass identische Passwörter bei jedem Benutzer und auf jedem System immer denselben Hash ergeben — das ermöglicht Lookups über vorberechnete Rainbow Tables. Es gibt auch keine Iteration oder keinen Arbeitsfaktor — nur einen einzigen ungesalzenen MD4-Durchlauf —, sodass moderne GPUs Milliarden Versuche pro Sekunde gegen einen abgefangenen Hash durchführen können. NTLM überlebt im Wesentlichen nur wegen der Kompatibilität mit älteren Windows-Systemen und -Anwendungen.

Wie unterscheidet sich NTLM von modernem Passwort-Hashing wie bcrypt, scrypt oder Argon2?

Moderne Passwort-Hashing-Verfahren sind bewusst langsam und gesalzen: bcrypt, scrypt und Argon2 fügen jeweils ein eindeutiges, zufälliges Salt pro Passwort sowie einen einstellbaren Kostenfaktor hinzu, der mit zunehmend leistungsfähigerer Hardware im Lauf der Zeit erhöht werden kann — genau um Brute-Force selbst in großem Maßstab teuer zu machen. NTLM tut nichts davon: Es wurde in einer Zeit entworfen, in der Offline-Brute-Force noch kein praktisches Bedrohungsmodell war, und das merkt man ihm an. Genau deshalb sollte NTLM niemals zum Schutz von heute neu entworfenen Systemen eingesetzt werden; die eigentlichen Einsatzzwecke dieses Tools sind Kompatibilität mit bestehender Windows-Infrastruktur und autorisierte Sicherheitsprüfungen, nicht der Aufbau neuer Systeme.

Was sind legitime Einsatzzwecke für einen NTLM-Hash-Generator?

Das Verifizieren von Hashes aus einer SAM-Datenbank oder einem NTDS.dit während eines autorisierten Penetrationstests oder Credential-Audits; das Prüfen, ob eigene Tools oder Skripte MS-NLMP korrekt implementieren; das Erzeugen von Test-Hashes für hashcat (Modus 1000) oder Kompatibilitätsprüfungen im Mimikatz-Format in einem selbst kontrollierten Labor; sowie das Bearbeiten von CTF- oder Trainingsaufgaben, die explizit NTLM betreffen. Dieses Tool zum Angriff auf Konten oder Systeme zu nutzen, die einem nicht gehören oder für die keine schriftliche Testberechtigung vorliegt, ist kein legitimer Einsatzzweck.

Wird mein Passwort oder meine Eingabe an einen Server gesendet?

Nein. Die MD4-Berechnung läuft vollständig in JavaScript in deinem Browser ab — es gibt keine native Browser-API für MD4, daher ist sie direkt im clientseitigen Code dieser Seite implementiert —, und nichts von dem, was du eingibst, wird irgendwohin übertragen.

Warum stimmt mein Hash nicht mit dem aus einem kleinen Python-Skript überein?

Die häufigste Ursache ist, die Zeichenfolge vor MD4 als UTF-8 statt UTF-16LE zu kodieren — prüfe, ob dein Skript `.encode('utf-16le')` in Python verwendet und nicht `.encode('utf-8')`, den Standardwert der meisten Bibliotheken und den häufigsten Fehler bei einer eigenen NTLM-Implementierung.

Ändert sich der Hash, wenn das Passwort Umlaute oder ß enthält?

Ja, und das zu Recht: UTF-16LE kodiert jedes Unicode-Zeichen originalgetreu, daher erzeugt ein Passwort wie "Straße123" andere Bytes — und damit einen anderen Hash — als eine Version ohne Umlaute oder ß. Genau das macht Windows intern auch.

Kann ich mit diesem Tool den NTLMv2-Hash statt nur den einfachen NTLM-Hash berechnen?

Nein — dieses Tool berechnet nur den Basis-NTLM-Hash (MD4 über UTF-16LE), den gespeicherten Passwortverifikator. NTLMv2 ist ein Challenge-Response-Protokoll, das diesen Basis-Hash als Eingabe für eine zusätzliche HMAC-MD5-Berechnung zusammen mit Sitzungsdaten nutzt und Parameter erfordert, die über ein einfaches Eingabepasswort hinausgehen.