NTLMの「既定オフ」へ——Windowsアイデンティティの大転換が始まる

今日の深掘りポイント

• これは単なるレジストリやGPOの話ではなく、アイデンティティ境界の再設計そのものです。NTLMを消し込むには、Kerberosの通り道（DC到達・SPN・委任・暗号スイート）を現場で磨き込む必要があるからです。
• 横取り・リレー・パスザハッシュの“王道”が崩れます。一方で、攻撃側はKerberos系（Kerberoasting、AS-REP Roasting、チケット悪用）へ重心を移すはずで、守りの重心も同時に移し替える必要があります。
• 影響は情シスの外周まで波及します。MFP/プリンタ、NAS、レガシーWeb/IIS、OT/工場端末、委託先・B2B接続など、ADに「半接続」している装置ほど詰まりやすいです。早期の棚卸しと例外設計が肝になります。
• 現場は監査→抑制→既定オフの“狭間”で事故りやすいです。監査イベントの粒度設計、段階ロールアウト、ロールバック・プレイブックまでを一式で持つことが安全弁になります。

はじめに

MicrosoftがWindows全体でNTLM（New Technology LAN Manager）の無効化に明確な道筋を引き始めました。狙いは、より安全なKerberosベースの認証を既定として押し上げ、NTLM横取り・リレー系の攻撃面を構造的に潰すことにあります。発表は段階的な移行を前提にしており、まずは“どこでNTLMが生きているか”の可視化と、有効な代替（Kerberos）へのルーティング改善を促す流れです。Help Net Securityの報道はその合図として十分に重い意味を持ちます。

重要なのは、NTLMを切るとは「弱いプロトコルを無効化する」だけではなく、「Kerberosが確実に通る世界へインフラとアプリを揃える」作業だという点です。ゼロトラストを掲げる以上、ここを避けては通れません。

深掘り詳細

事実——Microsoftが既に用意しているコントロール郡

Microsoftは長年にわたり、NTLMの利用を制限・監査・段階的に拒否するためのビルトイン機能をWindows/ADに実装してきました。今回の「全体無効化」ロードマップは、それら既存のコントロールを組み合わせて現実解へ落とし込む流れの延長線上にあります。

• ドメイン全体のNTLM監査・制限
  • 「Network security: Restrict NTLM」系ポリシーで、ドメイン/サーバー/クライアントの入出力NTLMを監査・拒否できます。監査は専用イベント（LSA/NTLMイベントやセキュリティログ）に出力され、どの端点・どのプロセス・どの宛先でNTLMが使われたかを把握できます。Microsoft Learn（NTLMをドメインで制限）、受信NTLMの制限、送信NTLMの制限
• SMB・HTTPなどプロトコル層のリレー抑止
  • SMBは署名/暗号化でNTLMリレーの成功確率を大幅に下げられます。NTLM撤廃の過程でも「落ちない」守りとして重要です。SMB署名
  • Web/IISなどでは「拡張保護（Extended Protection for Authentication）」で経路保護やチャネルバインディングを適用し、NTLM/Negotiateのダウングレードやリレー成功域を縮められます。Extended Protection for Authentication
• Kerberosを使い切るための下地
  • サービスプリンシパル名（SPN）整備、委任（特にRBCD: Resource-Based Constrained Delegation）の安全な活用など、Kerberosを中心に据える設計原則は既に整理されています。Kerberos制約付き委任の概要
  • ハイブリッド/リモート環境では、Windows Hello for BusinessのCloud Kerberos Trustでクラウド側の身元保証からオンプレ資源へKerberos連携する選択肢が実運用レベルにあります。Windows Hello for Business: Cloud Kerberos Trust
• 既存の後方互換スイッチの整理
  • 歴史的な「LAN Manager認証レベル（LmCompatibilityLevel）」なども、もはや上げて当然の時代です。既定/推奨値の確認と例外の棚卸しは移行前提条件になります。LAN Manager 認証レベル

以上は“明日から使える”機能です。Microsoftが段階的に既定値を強化していくのに合わせ、組織側での監査→抑制→拒否への切替えが現実解として回る下地が整っています。

インサイト——「なぜ今、NTLMを消し込めるのか」

• Kerberosの“通り道”問題（DCへのラインオブサイト、SPN/委任の設計、暗号スイートの足並み）がクラウドとネットワークの進化で解け始めたからです。特にCloud Kerberos Trustは、従来「社外・拠点外だとNTLMに落ちがち」という構造を弱めます。
• 防御側のプロトコル・ハンドシェイク強化（SMB署名/暗号化、HTTPの拡張保護）が普及し、NTLMが残っていても「攻撃が決まり切らない」場面が増えました。だからこそ「最後の一押し」としての“既定オフ”が視野に入ります。
• 実務面では、最大の難所はアプリ互換と周辺機器です。IIS/ASP.NETで「Windows認証（Negotiate/NTLM）」の並び順が放置されていたり、プリンタ・NAS・スキャナや古いSamba/JavaスタックがNTLMに依存していたりする。ここを前倒しで洗って、Kerberosに切り替える（AD参加、SPN/Kerberos設定、ドライバやSDKの刷新）ことが最大の山場になります。

脅威シナリオと影響

NTLM撤廃は攻撃側の「常套」を直撃します。一方で、攻撃の重心がKerberos側に移る副作用も見込まれます。以下は想定シナリオ（仮説）とMITRE ATT&CKの観点です。

• 横取り・リレー（Adversary-in-the-Middle）抑止
  • 想定シナリオ（現状）: LLMNR/NBT-NS誘導→SMB/HTTPでNet-NTLM応答を取得→リレーで高権限に昇格。
  • NTLM撤廃後: 認証がKerberosに固定されることで、Net-NTLM応答自体が得られず、リレーが成立しづらくなります。SMB署名や拡張保護の既定強化が噛み合うと、成功域はさらに縮みます。
  • ATT&CK: Adversary-in-the-Middle T1557.001 LLMNR/NBT-NS Poisoning and SMB Relay
• パスザハッシュ（Pass-the-Hash）の難化
  • 想定シナリオ（現状）: LSASS/NTDS等から抽出したNTLMハッシュで横移動。
  • NTLM撤廃後: NTLMを用いた横移動（SMB/WinRM/LDAP等）が不成立となり、同手法の価値が大幅に下がります。
  • ATT&CK: Use Alternate Authentication Material T1550.001 Pass the Hash
• 攻撃の重心移動（Kerberos系TTPの増加）
  • 想定シナリオ（将来）: サービスチケット抽出とオフライン総当たり（Kerberoasting）や、事前認証なしユーザーのAS-REP Roasting、チケット偽造・悪用へのシフト。
  • 対応: AES限定化（RC4撤廃）、強パス/マネージドID、SPN最小化、TGT/TGS寿命の見直し、RBCD/委任の健全化など、Kerberos前提のハードニングが主戦場になります。
  • ATT&CK: Steal or Forge Kerberos Tickets T1558.003 Kerberoasting、T1558.004 AS-REP Roasting
• 可用性リスク（運用の“狭間”）
  • 想定シナリオ: 監査→部分ブロックの過程で、MFPのスキャンtoNAS、IISの社内SSO、レガシーJavaクライアント等が断続的に落ち、現場業務が停滞。
  • 対応: 監査イベントから「例外候補」を洗い出し、代替（Kerberos化・機器更新・一時的ネット分離）を用意してから段階ロールアウト。即時リカバリ（ロールバック）手段まで含めたチェンジ管理が重要です。

総合的に見ると、実行可能性は高く、移行の緊急度も高い一方で、新規性は“技術”より“運用設計”に宿ります。評価軸が「いますぐ手を動かせるか」「現場の詰まりを事前に解けるか」に寄るニュースです。

セキュリティ担当者のアクション

「監査で地図を描く」「Kerberosの通り道を整える」「NTLMの蛇口を締める」を並走させるのがコツです。CISO/SOC/IT運用それぞれの打ち手を、最初の90日に寄せて整理します。

• 棚卸し（Week 0–2）
  • ドメインコントローラーに「Restrict NTLM: Audit…」を適用し、NTLM使用の監査イベントを収集します。発生元（端点/プロセス/宛先）と用途（SMB/HTTP/LDAP等）でタグ付けして、クリティカル業務を特定します。ドメインでNTLMを監査・制限
  • 併せて4624/4625のログオンイベントで「Authentication Package」がNTLM/Negotiateになっているフローを抽出し、重畳分析します。
• Kerberos側の路整備（Week 1–4）
  • SPNの正規化、重複/欠落の修正。サービスアカウントはAES有効・RC4無効・マネージドID化を推進。
  • IIS/アプリのWindows認証プロバイダーを見直し、「Negotiate（Kerberos）」を優先し、NTLMを無効化または最終手段に。HTTPは拡張保護（EPA）を有効化します。Extended Protection for Authentication
  • SMBは署名（可能なら暗号化）を標準化。NAS/ファイルサーバーの設定ドキュメント化とベースライン適用を進めます。SMB署名
  • リモート/ハイブリッド利用には、Windows Hello for BusinessのCloud Kerberos Trust等で「社外でもKerberos」を設計に組み込みます。Cloud Kerberos Trust
• 周辺機器・異種OSの更生（Week 2–6）
  • MFP/プリンタ/スキャナ、NAS、Samba、古いJava/HTTPクライアント等の“要介護”資産を一覧化。AD参加・Kerberos化の可否、ドライバ/ファーム更新、置換計画を決めます。置換不可なものはネットワーク分離やプロキシ／中継ゲートウェイで「Kerberosに変換」する設計を検討します。
• 段階的な蛇口締め（Week 4–9）
  • まずは「送信NTLMの制限（リモートサーバー宛）」を厳格化し、既知のRDP/SMB/HTTPフローでNTLMフォールバックが起きないことを検証します。送信NTLMの制限
  • 次に「受信NTLMの制限」をサブセットのサーバーOUでロールアウト。例外は明示的な許可リストに限定し、イベント監視で逸脱を検出します。受信NTLMの制限
  • ドメイン全体の「NTLM認証を無効化」に近づけつつ、ロールバック手順と変更窓口を常に用意します。ドメインでNTLMを制限
• SOCの観測項目の刷新（随時）
  • これまでのNet-NTLMハッシュ露出やNTLMリレーの検知ロジックに加え、Kerberos系TTP（Kerberoasting/AS-REP Roasting/不正委任/不審SPN追加等）の検知ユースケースを優先度高く整備します。T1558.003、T1558.004
  • 変更窓口とSOCの連携を強め、ブロックによる可用性事象を速やかに切り分けられる体制を作ります。
• ガバナンス/ベンダー・マネジメント
  • 調達要件に「NTLM不使用」「Kerberos/EPA/SMB署名対応」を明文化。既存ベンダーとは“いつまでにNTLMを外すか”のロードマップ合意を取ります。
  • 経営向けには「横移動リスク低減」と「レガシー撤去による運用負債削減」をメトリクスで訴求します（例：NTLM利用端末比率、NTLMイベントの週次減少率、Kerberos成功率など）。

今回の評価指標から読み取れるのは、実行確度の高さと行動可能性の大きさです。新規性は“技術の奇抜さ”ではなく、「レガシーを剥がす現場知」を早く蓄積できるかに宿ります。棚卸しの早さが、そのまま移行コストと事故率を左右します。

参考情報

• Microsoft、Windows全体でNTLMを無効化する道筋（報道）: Help Net Security
• Network security: Restrict NTLM（ドメイン全体の監査/制限）: Microsoft Learn
• Network security: Restrict NTLM（受信の制限）: Microsoft Learn
• Network security: Restrict NTLM（送信の制限）: Microsoft Learn
• SMB署名（リレー抑止の基礎）: Microsoft Learn
• Extended Protection for Authentication（HTTP/Negotiateの保護）: Microsoft Learn
• Kerberos制約付き委任（RBCD含む）: Microsoft Learn
• Windows Hello for Business: Cloud Kerberos Trust: Microsoft Learn
• MITRE ATT&CK: Pass the Hash T1550.001、Adversary-in-the-Middle（LLMNR/NBT-NS/SMB Relay）T1557.001、Kerberoasting T1558.003、AS-REP Roasting T1558.004

読者のみなさんの現場で「最初の一歩」は監査のスイッチひとつです。見える化が進むほど、移行の怖さは薄れていきます。次の“既定”がやってくる前に、こちらから迎えにいきたいですね。