CodeKitHubこのツールとは？
NTLM（NT LAN Manager）は Microsoft の従来型チャレンジレスポンス認証プロトコルで、現在もローカルの Windows アカウントログオンや、多くの Active Directory 環境でのフォールバックとして使われています。一般に「NTLMハッシュ」と呼ばれるそのパスワード検証子は、Microsoft 自身の MS-NLMP プロトコル仕様 で `MD4(UTF-16-LE(password))` と定義されています。パスワードはまず UTF-16 リトルエンディアン（UTF-8 と異なり、1文字がすべて2バイトになります）としてエンコードされ、そのバイト列が RFC 1320 の MD4 アルゴリズムで一度だけハッシュ化されます。
NTLM を自前で再実装する際に最も間違えやすいのが、この UTF-16LE の工程です。文字列の UTF-8 バイト列をハッシュ化してしまうと、表示上のテキストは同じに見えても、まったく異なる誤った結果が生成されます。このツールは正しくエンコードするため、その出力は Windows 自体が保存する値、そして hashcat（モード1000）や Mimikatz が期待する値と一致します。
NTLM は最新のパスワードハッシュ設計より前に作られたため、後になって解読を遅らせるために意図的に組み込まれた保護策——ユーザーごとのソルト、調整可能なワークファクター、意図的な反復処理——を一切持ちません。単発の MD4 パスであるため計算は極めて高速です。この性質はレガシー互換性の面では都合が良い一方、総当たり攻撃や辞書攻撃への耐性という点では致命的です。
なぜこれを使うのか？
- 許可を得たペネトレーションテスト中にクライアントのNTDS.ditからハッシュのバッチを抽出し、フルダンプをhashcatに投入する前に、自作の解析スクリプトが正しいハッシュ形式を生成できているかを確認したいとき。
- 認証情報監査用のカスタムツールを作っていて、MS-NLMP仕様から独自にMD4(UTF-16LE)実装を書き終えたばかりのとき——「password」のような既知のテストベクタをここに入力し、正しい8846F7EAEE8FB117AD06BDD830B7586Cと一致することを確認してから実データに使いたい場合。
- Windows認証をテーマにしたCTF課題や自宅ラボの演習に取り組んでいて、Windows VMをわざわざ立ち上げずに、あるパスワードのNTLMハッシュがどうなるかをすぐ確認したいとき。
- レガシー認証の弱点を扱うセキュリティ講座を教えていて、NTLMにソルトがないせいで、アカウントやドメインに関係なく同じパスワードが常に同一のハッシュになることを、その場で受講者に見せたいとき。
- 100% ローカル処理：入力がブラウザの外に出ることはないため、正当な評価業務であれば機微な認証情報を扱う場合でも安心して使えます。
使い方
- ハッシュ化したいパスワードや文字列を入力ボックスに入力します。
- 「Generate NTLM Hash」をクリックします。
- 32文字の16進数の NTLM ハッシュを確認します（Windows やほとんどの解読ツールの表示に合わせ、既定では大文字出力になっています。小文字にしたい場合はチェックを外してください）。
- 「Copy」をクリックしてハッシュをクリップボードにコピーします。
例
入力
password出力
8846F7EAEE8FB117AD06BDD830B7586Cこれはよく知られた、独立して検証可能なテストベクタです。文字列「password」の NTLM ハッシュは常に 8846F7EAEE8FB117AD06BDD830B7586C になります。他の正しい NTLM 実装の出力と照らし合わせて本ツールを検証できます。
NTLMと現代のパスワードハッシュの比較
以下の表は、NTLM が今も古い Windows や Active Directory のインフラに組み込まれている一方で、新規システムの保護には時代遅れとみなされる理由を示しています。
| 特性 | NTLM | bcrypt / scrypt / Argon2 |
|---|---|---|
| 基盤となるプリミティブ | 単発のMD4パス | 調整可能なコストを持つ、低速化を目的に設計されたハッシュ |
| ソルト | なし——同じパスワードは常に同じハッシュになる | パスワードごとに一意のランダムソルト |
| 反復／ストレッチング | なし | 調整可能なワークファクター。時間とともに引き上げ可能 |
| 総当たり耐性 | 非常に弱い——最新GPUで1秒間に数十億回の推測が可能 | 1回の推測ごとに意図的に高コスト |
| 現在も使われている場所 | レガシーなWindows認証、Active Directoryのフォールバック | 新規アプリケーション、現在のベストプラクティス |
関連ツール
NTLM 特有の MD4(UTF-16LE) 構成ではなく、汎用の暗号学的ハッシュが必要な場合は、以下のツールがより適しているかもしれません。
よくあるNTLM検証ワークフロー
このツールが最も役立つのは、より大きな正規ワークフローの中で行う簡易チェックの段階です——パイプライン全体を置き換えるのではなく、次のステップに進む前に値を信頼できるかどうかを確認するために使います。
| シナリオ | 確認していること | 重要な理由 |
|---|---|---|
| 自作スクリプトの検証 | 自分のMS-NLMP実装を既知のテストベクタと照合 | データセット全体が気づかぬうちに壊れる前に、UTF-8とUTF-16LEの取り違えを発見できる |
| 抽出済みハッシュの抜き取り確認 | 抽出したSAM/NTDS.ditの1エントリを想定される平文と照合 | 抽出ツールがフォーマットを正しく解析できているかを確認できる |
| hashcat/Mimikatz形式の確認 | 出力構造がモード1000の想定に合っているか | 不正な形式のハッシュリストに対する無駄な解読処理を防げる |
| トレーニングやCTF課題 | 自分で手計算したハッシュとツールの出力を照合 | MS-NLMPが実際どう動くかを段階的に体感で理解できる |
よくある質問
NTLMハッシュとは具体的に何ですか？
Windows が NT LAN Manager 認証のために計算・保存するパスワード検証子で、Microsoft の MS-NLMP 仕様 において MD4(UTF-16LE(password)) と定義されています。パスワードの UTF-16 リトルエンディアンのバイト列に対して MD4 を一度だけ適用したものです。常に128ビットで、16進数32文字として表示されます。
なぜUTF-8やASCIIではなくUTF-16LEなのですか？
Windows は NT の設計当初からテキストを内部的に UTF-16LE で保持しているため、パスワードもハッシュ化前に同じ方式でエンコードされます。'a' のような単純な ASCII 文字であっても、0x61 だけではなく 0x61 0x00 というように、すべての文字が2バイト（リトルエンディアンのバイト順）になります。同じ文字列の UTF-8 バイト列をハッシュ化すると、まったく異なる誤った結果になります。これはゼロから実装した NTLM で最もよくあるバグです。
NTLMは今でも安全に使えますか？
いいえ。Microsoft 自身も可能な限り Kerberos への移行を推奨しています。NTLM にはソルトがないため、同じパスワードはすべてのユーザー・すべてのシステムで常に同じハッシュになり、事前計算されたレインボーテーブルによる照合を許してしまいます。また反復やワークファクターもなく、単発のソルトなし MD4 パスであるため、現代の GPU であれば1秒間に数十億回もの推測を試すことができます。今も存在するのは、主に古い Windows システムやアプリケーションとの互換性維持のためです。
bcrypt、scrypt、Argon2 のような現代のパスワードハッシュとNTLMはどう違いますか？
現代のパスワードハッシュ方式は意図的に低速かつソルト付きです。bcrypt、scrypt、Argon2 はそれぞれパスワードごとに一意のランダムソルトを付与し、ハードウェアが高速化するにつれて引き上げられる調整可能なコストファクターを持ち、大規模な総当たり攻撃を意図的に高コストにします。NTLM はそのどちらも備えておらず、オフラインでの総当たり攻撃が現実的な脅威モデルとして想定されていなかった時代に設計された名残がそのまま表れています。だからこそ NTLM を今日新しく作るものの保護に使ってはいけません。このツールの正当な用途は、既存の Windows インフラとの互換性確認と許可を得たセキュリティテストであり、新規システムの構築ではありません。
NTLMハッシュジェネレーターの正当な用途にはどんなものがありますか？
許可を得たペネトレーションテストや認証情報監査の中で SAM データベースや NTDS.dit から抽出したハッシュを検証すること、自作のツールやスクリプトが MS-NLMP を正しく実装しているか確認すること、自分が管理するラボで hashcat（モード1000）や Mimikatz 形式との互換性チェック用にテストハッシュを生成すること、NTLM を明示的に扱う CTF やトレーニング課題に取り組むことなどが挙げられます。自分が所有していない、または書面での許可を得ていないアカウントやシステムを攻撃するためにこのツールを使うことは正当な用途ではありません。
パスワードや入力内容はサーバーに送信されますか？
送信されません。MD4 の計算はすべてブラウザ内の JavaScript で実行されます。MD4 に対応するブラウザネイティブ API は存在しないため、このページのクライアント側コードで直接実装されており、入力した内容がどこかに送信されることはありません。
このツールはLMハッシュも扱いますか、それともNTLMだけですか？
NTLMのみです。より古いLMハッシュはまったく別の、より弱い方式（パスワードを7文字ずつ2つに分割し、それぞれをDESでハッシュ化）を使っており、Microsoft はWindows Vista以降デフォルトでLMハッシュの保存を無効にしています。レガシーなLMハッシュを扱う必要がある場合は、そのアルゴリズム専用の別ツールが必要です。
なぜ同じ入力は常にランダム性なく、まったく同じハッシュになるのですか？
これは想定通りで、実際のNTLMの挙動そのものです——NTLMにはソルトがないため、MD4(UTF-16LE(入力)) は純粋な決定的関数です。同一の入力は常に同一の出力を生み、これこそが事前計算されたレインボーテーブル攻撃に対してNTLMを脆弱にしている弱点です。
パスワード以外、たとえばユーザー名やチャレンジ値のハッシュ化にも使えますか？
技術的には可能です——このツールは入力したどんなテキストに対してもMD4(UTF-16LE(入力))を計算するだけなので、任意の文字列に対応します。ただし、より完全なNTLMv2のチャレンジレスポンスのやり取り（NTLMハッシュに加えてサーバーチャレンジ、クライアントノンス、HMAC-MD5を含む）を扱う場合は、この単純なハッシュ計算だけでは足りず、追加のステップが必要になります。
このツールの出力が正しいことをどうやって確認できますか？
組み込みの例を使ってください——文字列「password」のNTLMハッシュはよく知られた、独立して公開されているテストベクタで、8846F7EAEE8FB117AD06BDD830B7586Cです。これを入力してぴったり同じ結果になることを確認し、さらに確信を得たい場合はhashcat自身のテストベクタなど、別の信頼できる実装と照合してください。