NTLMの全体像と現代の対策: 脆弱性・攻撃手法・移行ロードマップを解説
エバープレイ編集部NTLMとは — 概要
NTLM（NT LAN Manager）は、Microsoft が Windows プラットフォームで長年使ってきた認証プロトコルの総称です。Active Directory（AD）環境で標準の Kerberos 認証が利用できない状況や後方互換性のために残されており、SMB、RPC、HTTP（Windows 統合認証）など複数のプロトコル上で利用されます。認証方式としてはチャレンジ／レスポンス（challenge–response）方式を採用しており、パスワードそのものではなくハッシュ値や応答データをやり取りする点が特徴です。
歴史とバージョン
- LM（LAN Manager）ハッシュ：初期の Windows（古い MS-DOS/Windows ネットワーク）で使われた方式で、パスワードを大文字化して14バイトにし、2つの7バイトブロックに分けて DES で平文定数を暗号化するという非常に脆弱な方式でした。現代では無効化が推奨されます。
- NTLMv1：NT 系 OS で導入された方式で、パスワードから生成される NT ハッシュ（MD4 による UTF-16LE パスワードのハッシュ）を用いたチャレンジ／レスポンスを行います。LM ハッシュとの互換性のために弱い要素が残ることやリプレイ対策が不十分であることから脆弱です。
- NTLMv2：脆弱性を改善するために設計されたバージョンで、NTLMv2 ハッシュ（NT ハッシュを鍵にした HMAC-MD5 を利用）やクライアント側のチャレンジやタイムスタンプ、AV ペア（ターゲット情報）を含む blob を導入し、リプレイや辞書攻撃への耐性を高めています。現代の環境では NTLMv2 を最小ラインとすべきです。
動作原理（高レベル）
NTLM の基本フローは次の通りです（簡略化）：
- クライアントがサーバへ接続を要求すると、サーバは 8 バイトのランダムなチャレンジ（nonce）を生成してクライアントに送る。
- クライアントは自分の資格情報（パスワードから導出したハッシュ）とサーバのチャレンジ、および（NTLMv2 では）クライアントチャレンジ・タイムスタンプ・AV ペアを元に応答（レスポンス）を作成して送る。
- サーバは期待されるレスポンスを計算して比較し、一致すれば認証成功となる。
重要なポイント：
- パスワード自体はネットワーク上で平文送信されないが、サーバ側ではパスワードハッシュ（NT ハッシュ）を使って応答の検証ができるため、そのハッシュが盗まれると直接認証に使えてしまう（後述の「pass-the-hash」）。
- NTLM 特有のメッセージ構造（NTLMSSP）や、NTLMv2 で使われる blob（タイムスタンプやターゲット情報を含む）がある。
どんな場面で使われるか
- ドメイン参加していないワークグループ環境や、クロスドメイン／外部ドメイン間で Kerberos が使えない場合。
- SMB（ファイル共有）、RPC（リモートプロシージャコール）、LDAP（認証バインド）、HTTP の Windows 統合認証（IIS の NTLM フallback）など。
- Windows の後方互換性のために、多くのクライアント／サーバ製品でサポートされ続けている。
主な脆弱性とリスク
- LM と NTLMv1 の弱点：LM ハッシュは極めて弱く、辞書攻撃や総当たりが容易。NTLMv1 もリプレイ対策や鍵の扱いで弱点があるため現代では非推奨。
- パス・ザ・ハッシュ（Pass-the-Hash, PtH）：攻撃者がシステムから NT ハッシュ（または LM ハッシュ）を抜き取ると、そのハッシュを使ってパスワードを知らなくてもネットワーク上で認証可能になります。これは NTLM の設計上の根本的な問題（サーバ側がハッシュを検証材料として持っている）に由来します。
- NTLM リレー攻撃：攻撃者がネットワーク上で被害者の認証要求を中間で受け取り、別のターゲットサービスにそのまま中継して認証を通してしまう攻撃です。NTLM はデフォルトで相互認証（サーバ→クライアントの検証）やチャネルバインディングが弱く、リレーが成立しやすいことがあります。
- ダウングレード攻撃：サーバやクライアントが古いバージョン（LM / NTLMv1）までフォールバックする設定だと、攻撃者がそれを誘導して弱い方式に落とし込める可能性があります。
具体的な攻撃ツールと手法
- Mimikatz：メモリから認証トークン、NT ハッシュ、Kerberos チケット等を抽出するツール。取得した NT ハッシュで PtH 攻撃が可能です。
- Responder：LLMNR/NBT-NS を悪用して名前解決の応答を偽装し、SMB/HTTP 等の認証要求を誘導して NTLM レスポンスやハッシュを回収します。
- ntlmrelayx（Impacket）：受け取った NTLM 認証を別サーバにリレーして、権限昇格や任意コマンド実行を狙うツール群です。サービスによってはそのまま認証が通るため危険です。
防御 / 運用上の対策（実務的推奨）
- 可能な限り Kerberos を使う：AD 環境では Kerberos が既定の優先プロトコルです。Kerberos を正しく構成し、NTLM へのフォールバックを最小化してください。
- NTLMv1 と LM を無効化する：グループポリシーで LM と NTLMv1 をブロックし、NTLMv2 のみ許可する設定にします（多くの現代的環境で問題なく動作します）。
- NTLM 制限ポリシーの適用：Windows の「Restrict NTLM」ポリシーで、どのコンピュータ／ドメインで NTLM を許可するか詳細に制御できます。段階的に監査 → 制限へ移行するのが現実的です。
- SMB 署名（SMB Signing）を有効化：SMB の通信に署名と整合性検証を適用することで、リレーや中間者攻撃の成功確率を下げます。
- Extended Protection / チャネルバインディングの活用：HTTP（IIS）やサービスでチャネルバインディング（CBT）を使うと、TLS と認証を結び付けられ、NTLM リレーのリスクを低減できます。
- 資格情報の保護（Credential Guard 等）：Windows の Credential Guard や LAPS、最小権限原則を用いて資格情報抽出のリスクを下げます。
- 不要なサービスの停止・ポリシーでの制限：古いアプリケーションやデバイスが NTLMv1 / LM を要求する場合はアップデートまたは分離を検討します。
監視と検出のポイント
- Windows の監査ポリシーで「NTLM の使用を監査」する設定を有効にし、どのクライアント／サーバが NTLM を使っているか把握する。
- 代表的なイベント ID：4624（成功したログオン）、4625（失敗したログオン）、4648（明示的な資格情報でのログオン試行）、4776（資格情報検証の試行）など。これらログの Authentication Package や Logon Type から NTLM による認証を特定できます。
- ネットワーク側では不審な SMB/HTTP の接続や、LLMNR/NBT-NS の応答が発生していないかを監視。Responder のようなツールによる名前解決偽装の痕跡をチェックする。
- 異常に多い外部への NTLM 認証要求や、単一アカウントから多数のターゲットへ認証がなされている状況はリレーや横展開の兆候です。
現実的な移行シナリオ
組織での対応は段階的に行うのが現実的です。まずは NTLM 使用の監査を有効にして実態把握（どのアプリ／デバイスが依存しているか）。次に不要な LM／NTLMv1 をブロック、SMB 署名やチャネルバインディングの適用を進め、最終的には「必要最小限の NTLM のみ許可」あるいは完全無効化を目指します。古い組み込み機器やレガシーアプリケーションは例外管理や分離で対応します。
まとめ
NTLM は長年にわたって使われてきた認証方式であり、その互換性ゆえに現在でも多くの環境で残っています。しかし LM や NTLMv1 の脆弱性、パス・ザ・ハッシュやリレー攻撃といった現実的なリスクがあるため、現代のセキュリティ対策としては NTLMv2 への強制、NTLM の使用最小化、Kerberos 優先の運用、SMB 署名やチャネルバインディングの導入、さらに資格情報保護技術の採用が必須です。監査と段階的な移行計画を立てて対処することを推奨します。
参考文献
- MS-NLMP: NT LAN Manager (NTLM) Authentication Protocol（Microsoft Open Specifications）
- NTLM overview (Windows Server documentation)（Microsoft）
- Restricting NTLM authentication in your domain (Microsoft)
- mimikatz (GitHub)（資格情報抽出ツールのリポジトリ）
- Responder (GitHub)（ネットワーク名解決関連の攻撃ツール）
- ntlmrelayx (Impacket examples)（NTLM リレー攻撃ツール）
投稿者プロフィール
