NTLM
パスワードの一方向ハッシュを使ったチャレンジ/レスポンス方式の認証プロトコル群(LANMAN・NTLMv1・NTLMv2を含む)。相互認証を持たず、サーバーが本物であると仮定できる環境向けに設計されている。
NTLM認証
NTLM/Operationalログ
NTLM監査の記録先ログ。ドメインコントローラーのイベント8004、メンバーサーバーの8003、クライアントの8001などが記録され、対応するセキュリティ監査イベントポリシーは存在しない。
「NTLMを制限する」ポリシー群
送信NTLMトラフィック・受信NTLMトラフィック・ドメイン内NTLM認証を、監査から拒否まで段階的に制御できるセキュリティポリシー群。
ネットワークセキュリティ: NTLMを制限する
グループポリシー
Active Directoryドメイン環境でWindowsの設定を集中構成する仕組み。
Get-WinEvent
イベントログをフィルターして取得するPowerShellコマンドレット。FilterHashtableでの絞り込みに対応し、NTLM監査ログなど大量のイベントの集計に使う。
Process Monitor(procmon.exe)
ファイルI/O・レジストリ・プロセス/スレッド活動をリアルタイムに監視できるSysinternalsのツール。Advanced Outputを有効にすると、IRPやファストI/Oのカーネル側の語彙で操作を表示する。
ドメインアカウント
Active Directoryドメインに属し、ドメインコントローラーで認証されるアカウント。NTLMでの認証はドメインコントローラーへのパススルー認証を伴う。
ドメインコントローラー
Active Directoryのディレクトリサービスを提供し、KDCの機能やNTLMのパススルー認証の相手を担うサーバー。
ローカルアカウント
MicrosoftアカウントやEntra IDに紐づかない、PC内で完結するアカウント。
ワークグループ構成
Active Directoryドメインに参加しない、Kerberosの土俵にないWindowsのネットワーク構成。この構成のシステムのWindows認証には依然としてNTLMが使われ、使われなければならない。
Kerberos
チケットによる一度だけの本人確認と相互認証を提供する認証プロトコル。Windows ServerはKerberos version 5と、公開鍵認証・認可データの転送・委任のための拡張を実装する。
Kerberos認証
TryIPSPN
SPNのホスト名としてIPアドレスを使えるようにするクライアント側のレジストリ設定(TryIPSPN)。DNS名に変更できない場合の最後の手段として、IPアドレスのSPNを手動登録する。
SPN
KDCが接続先のサービスアカウントを特定するために使う名前。登録されていなければ、KDCはそのサービスのサービスチケットを発行できない。
サービスプリンシパル名
SMBクライアント側のNTLMブロック
SMBクライアントがリモートへの送信接続でNTLM認証をブロックする、Windows Server 2025/Windows 11 バージョン24H2以降の機能。接続先のSMBサーバーがKerberosまたはPKU2Uを使えることが前提。
Windows 11 バージョン24H2 / Windows Server 2025
NTLMv1の削除、SMB署名の既定必須化、SMBクライアント側のNTLMブロック追加など、複数のセキュリティ既定値が変わった2024年後半以降のWindowsリリース世代。
NET USE /BLOCKNTLM
グループポリシーを変えずに、1つのSMB接続だけをNTLMなしで試せる確認コマンド。繋がればその経路はNTLM不要で成立している。
NTLMv1
NTLMプロトコル群の第1版。Windows 11 バージョン24H2およびWindows Server 2025で削除された。
NTLM バージョン1
セキュリティログの「パッケージ名 (NTLM のみ)」
ログオンイベントの「詳細な認証情報」に含まれる、NTLMのどのサブバージョン(V1/V2)が使われたかを示すセキュリティログのフィールド。
認証パッケージ
詳細な認証情報
Negotiate
KerberosとNTLMのどちらかを選択するセキュリティパッケージ。認証に関わるシステムのいずれかがKerberosを使えない場合を除き、Kerberosを選択する。
Negotiateセキュリティパッケージ
認証タイプへのNTLM名指し
CredentialCache.Addなどで認証タイプ文字列に"NTLM"を直接指定する実装。マイクロソフトはこれをNegotiateへ置き換えるべきとしている。
IAKerb
ドメインコントローラーへの到達性の問題を解くためのプロキシ対応Kerberos拡張。NTLM廃止フェーズ2(2026年後半予定)で提供される機能。
ローカルKDC
ローカルアカウント認証にもKerberosを使えるようにする機能。NTLM廃止フェーズ2(2026年後半予定)で提供される機能で、対応するWindows同士でのみ効く。
NTLMリレー攻撃
攻撃者が被害者とサーバーの間でNTLMのチャレンジ/レスポンスをそのまま中継し、被害者になりすます攻撃。応答が宛先を縛らないNTLMの弱点を突く。
SMBリレー攻撃
SMB署名
SMBの全メッセージにセッション鍵由来の署名(メッセージ全体のハッシュと送信者・受信者の識別情報を含む)を付け、改ざんとリレー攻撃を検知する仕組み。Windows 11 24H2/Windows Server 2025で既定値が強化された。
Pass-the-Hash
盗んだパスワードのハッシュ(NTハッシュ)を使って、平文パスワードを知らないままNTLM認証を通過する攻撃。
Pass-the-Hash攻撃
「このドメインでのNTLM認証を監査する」「受信NTLMトラフィックを監査する」「送信NTLMトラフィック=すべて監査する」の3つを有効にして利用状況を可視化してから制限へ進む
3つの監査・制限ポリシーはローカルセキュリティポリシーまたはグループポリシーで配布し、保存時点で(再起動なしに)有効になる
監査・拒否イベントは対応するセキュリティ監査イベントポリシーを持たず、Microsoft-Windows-NTLM/Operationalログに記録される
大量のイベントはGet-WinEventのFilterHashtableで「接続先×呼び出し元プロセス」単位に集計する
SMB経由の通信はPIDが常に4(SYSTEM)になるため、相手サーバーのコンピューター名とIPアドレスでパスをフィルターしたProcess Monitorと、サーバー側イベント8003のタイムスタンプを突き合わせて呼び出し元プロセスを特定する
ドメインアカウントでのNTLM認証はドメインコントローラーへの問い合わせを伴い、その痕跡がイベント8004として記録される
NTLM経由で認証された場合、ドメインアカウントの認証は、DCのイベント8004(セキュアチャネル名)→メンバーサーバーの8003(PID)→クライアントの8001(ターゲットサーバー・クライアントプロセス名)の順にたどって原因アプリを特定できる。Kerberosで認証された場合はこのログに現れない
ローカルアカウントでの共有アクセスなど、ドメインコントローラー以外でのローカルログオン認証には依然としてNTLMが使われ使われなければならず、この経路はドメインコントローラーのイベント8004には現れない
ワークグループ構成の端末はActive Directoryの外にありKDCが存在しないため、Kerberosは成立しない
TryIPSPNを1にしたクライアントで、要求されるサービスクラスごとにIPアドレスのSPNをSetspnで手動登録する必要がある。DNS名に変更できない場合の最後の手段
SMBクライアント側のNTLMブロックの前提条件は、接続先のSMBサーバーがKerberos(またはPKU2U)を使えること
SMBクライアント側のNTLMブロックは、Windows Server 2025以降またはWindows 11 バージョン24H2以降のSMBクライアントが前提
ポリシーを一切変えずに、1接続だけをNET USE ... /BLOCKNTLMで試すことで、その経路がNTLMなしで成立するかを実地確認できる
パイロット後の全体展開は、グループポリシーの「NTLM をブロックする (LM、NTLM、NTLMv2)」またはSet-SmbClientConfiguration -BlockNTLMで行う
NTLMを完全に無効化しなくても、SMBクライアント側のこの保護層だけを先に有効化して依存を段階的に減らせる
NTLMv1はWindows 11 バージョン24H2およびWindows Server 2025で削除されており、これらのバージョンでは使えない
セキュリティログのログオンイベントにある「詳細な認証情報」の「パッケージ名 (NTLM のみ)」を見ると、そのホストがNTLM V1かV2かを判別できる
非推奨化の告知は、NTLMの呼び出しをNegotiateの呼び出しに置き換えるべきだとしている。アプリはNTLMセキュリティパッケージへ直接アクセスすべきではない
フェーズ2(2026年後半予定)のIAKerbは、ドメインコントローラーへ到達できない経路が原因のNTLM依存を減らすことを狙う
フェーズ2(2026年後半予定)のローカルKDCは、ローカルアカウント認証でのNTLM依存を減らすことを狙うが、対応するWindows同士でしか効かない
Kerberosはクライアントが提示するSPNからサービスアカウントを特定してチケットを発行するため、SPNの誤りは監査で見つかる典型的なNTLMフォールバック原因になる
監査で見つかるNTLM依存箇所は、そのままSMBリレー・中間者攻撃・総当たり攻撃に対する脆弱性でもある
SMB署名が有効な相手にはリレー攻撃が成立しないため、SMBを宛先とするリレー経路は塞がる。ただし捕捉したNTLM認証をLDAPやHTTPなど別プロトコルへ中継する経路までは防げない
ドメインアカウントでのNTLM認証では、リソースサーバーは新しいアクセストークンが必要になるたびにドメインコントローラーへ問い合わせる
NTLM/Operationalログでの監査結果を裏取りしてから、SMBクライアント側のNTLMブロックをパイロット展開するのが定石
クライアント側でTryIPSPNを設定しIPアドレスのSPNを登録すれば、DNS名に変更できない相手でもKerberosを成立させNTLMへの依存を避けられる。ただしDNS名への変更ができない場合の最後の手段
自作アプリを含め、NegotiateはKerberosとNTLMのどちらかを選択し、認証に関わるシステムのいずれかがKerberosを使えない場合を除きKerberosを選ぶ
Kerberosが使えない場合にだけ、NegotiateはNTLMへフォールバックする
監査で見つかるNTLM依存箇所の資格情報はパスワードのハッシュそのものであり、盗まれればPass-the-Hashが成立する