NTLM認証の実務ガイド：脆弱性とリスクからKerberos移行までの対策と運用ポイント
エバープレイ編集部はじめに — NTLM認証とは何か
NTLM（NT LAN Manager）は、Microsoft が開発したプロプライエタリな認証プロトコルで、Windows ネットワーク環境で長年にわたり使われてきました。ドメイン参加前のワークグループ環境や、Kerberos が利用できない環境、HTTP の「Integrated Windows Authentication」でブラウザが Kerberos を使えない場合のフォールバックとして広く利用されます。NTLM はチャレンジ・レスポンス方式の認証を行い、パスワード自体をネットワーク上に平文で送らない設計になっていますが、設計上の制約から現代のセキュリティ要件では脆弱性や攻撃手法の標的となることが多く、移行・制限が推奨されています。
歴史と位置づけ
NTLM は Windows NT 世代から存在しており、後継である NTLMv1、改良版の NTLMv2 といったバージョンが存在します。現行の環境でも後方互換性のために残っていますが、Active Directory ドメイン環境では Kerberos が優先され、NTLM は補助的に使われることが多いです。Microsoft は NTLM の仕様を公開文書（MS-NLMP 等）として提供しています。
基本的な動作（プロトコルの流れ）
NTLM 認証は一般に「NTLMSSP（NTLM Security Support Provider）」でラップされ、以下の 3 メッセージ交換（Negotiate → Challenge → Authenticate）で行われます。
- 1) Negotiate（クライアント→サーバ）: クライアントがサポートする機能（Unicode、署名、セッションセキュリティ要求 など）を通知。
- 2) Challenge（サーバ→クライアント）: サーバが 8 バイトのランダムチャレンジ（nonce）を送る。サーバは同時にサーバ側の機能要求も示す。
- 3) Authenticate（クライアント→サーバ）: クライアントは受け取ったチャレンジとクライアント保有の資格情報（パスワードから導出したハッシュ等）を用いてレスポンスを計算し送信。サーバはこれを検証して認証を許可する。
HTTP や SMB、RPC など複数のプロトコルの上で使われ、HTTP では SPNEGO（Negotiate）を介して Kerberos と NTLM を切り替えます。
NTLMv1 と NTLMv2 の違い（暗号的な観点）
NTLM のバージョン間ではセキュリティ面の差が大きいです。
- LM ハッシュ：古い LAN Manager（LM）ハッシュは非常に弱く、7 バイトずつに分けて DES で処理するなどの欠陥があるため、現代では無効化・非推奨。
- NT ハッシュ（NTLM ハッシュ）：パスワードの UTF-16LE 表現を MD4 によりハッシュ化したもの。これ自体が「資格情報の代替物」として使われるため、盗まれると危険です（pass-the-hash）。
- NTLMv1：サーバチャレンジに対するレスポンスを DES チャレンジレスポンスで作る方式。辞書攻撃やレインボーテーブルで解かれやすく、脆弱。
- NTLMv2：クライアントチャレンジ（クライアントのランダム値）やタイムスタンプ、ユーザ名／ドメインを含め、HMAC-MD5 を用いてレスポンスを生成。NTLMv1 より強固だが、デザイン上の欠陥（リレーや資格情報再利用）には注意が必要。
代表的な攻撃手法とリスク
NTLM を悪用する代表的な攻撃と、そのポイントは次の通りです。
- パスワード解析（リプレイ／辞書／ブルートフォース）：NTLMv1 は特に脆弱で、キャプチャしたレスポンスからパスワードを解読されやすい。
- Pass-the-Hash（PtH）：攻撃者が NT ハッシュ（またはその派生）を入手すると、パスワードの平文を知らなくても認証に成功できる。ローカルの資格情報ストアやメモリからハッシュが盗まれると発生。
- NTLM リレー攻撃：攻撃者がクライアントとサーバ間の NTLM ハンドシェイクを中継し、正当なクライアントになりすまして別のサービスへ接続する。SMB/HTTP などのプロトコルで有効。SMB 署名や Extended Protection が未設定だと成功しやすい。
- ダウングレード：クライアントとサーバの交渉で弱い NTLMv1 にダウングレードさせることで解析を容易にする。
検出・監視のポイント
NTLM ベースの攻撃を防ぐためには検出も重要です。ログやイベントを見るポイントは以下です。
- Windows セキュリティログ（Event ID 4624 等）と「NTLM ログ」：NTLM 認証の発生元・宛先・ユーザ情報を把握。
- Network Monitor / Wireshark：NTLMSSP の Negotiate/Challenge/Authenticate パケットのキャプチャでクロスチェック。
- グループポリシー「Restrict NTLM」設定を段階的に有効化し、監査モードで影響範囲を把握。
緩和策（防御と設定）
NTLM に起因するリスクを低減するための実務的対策：
- Kerberos の優先利用：可能な限り Kerberos 認証へ移行。Active Directory ドメイン環境では Kerberos が推奨。
- NTLM の制限/無効化：段階的に「Network security: Restrict NTLM」ポリシーで NTLM の使用を禁止または制限。まずは監査モードで影響を確認。
- SMB 署名の強制：SMB におけるリレー攻撃のリスクを減らす。
- Extended Protection for Authentication（EPM）：HTTP/IIS などでの NTLM リレー対策。
- 強力なパスワードと多要素認証（MFA）：資格情報の盗難リスクを下げる。
- Credential Guard / LSA Protection：メモリからのハッシュ抽出を困難にする Microsoft の技術を活用。
- 最小権限と分離：サービスアカウントや管理者アカウントは最小限に限定し、ネットワーク的に隔離。
運用上の注意点と設定例
実運用で注意すべき点をいくつか挙げます。
- レガシーアプリケーションやデバイス：古いプリンタやデバイス、サードパーティ製アプリケーションは Kerberos をサポートしないことがあるため、NTLM を完全に切れないケースがある。影響範囲調査が必須。
- ブラウザの振る舞い：Internet Explorer / Edge / Chrome / Firefox は SPNEGO を通じて Kerberos を使うが、DNS 名解決やブラウザ設定次第で NTLM にフォールバックすることがある。
- 段階的な移行：まずは監査ログを有効にして NTLM の利用状況を把握、次にドメイン内での NTLM 制限を段階的に適用するのが安全。
なぜ Kerberos に移行すべきか
Kerberos は第三者攻撃やリプレイ、資格情報の再利用に対する耐性が高く、チケットベースで短命な認証情報を使うため、企業ネットワークでは推奨されます。Active Directory と連携した Kerberos はスケーラビリティとセキュリティの両面で優位です。ただし、Kerberos が使えない特殊なケースでは NTLM が残るため、その場合は限定的かつ監査・保護下で運用します。
まとめ（結論）
NTLM は歴史的に重要で、多くの環境で未だに利用されている認証方式ですが、暗号的弱点や「ハッシュの再利用」による攻撃（pass-the-hash）、リレー攻撃などのリスクが存在します。可能であれば Kerberos に移行し、移行が難しい部分については NTLM の使用を制限・監査し、SMB 署名や Extended Protection、Credential Guard 等の技術を併用して防御することが推奨されます。技術的な仕様や設定を理解した上で段階的に対応することが現実的な運用方針です。
