NetBIOS・LLMNR名前解決ポイズニングとは？Windowsネットワークを狙うなりすまし攻撃の仕組みと無効化設定

「NetBIOS? LLMNR? そんな古い機能、うちの社内ネットで使ってますっけ？」

インフラ担当者にこう聞くと、多くの方が首をかしげます。実は、Windowsドメイン環境のほぼすべてで、これらの機能は今もデフォルトで有効になっています。攻撃者にとっては、内部ネットワークに足場を作った瞬間から認証情報を大量に収集できる、非常に狙いやすい弱点です。

ペネトレーションテストの現場でも、LLMNR・NetBIOSポイズニングは「内部侵入後の横展開で最も成功率が高い手法」として毎回のように挙げられます。しかもResponderという無料ツールで誰でも実行でき、特殊なスキルは不要です。

この記事では、LLMNR・NetBIOSポイズニング攻撃の仕組みと、情シス1人でもグループポリシーの設定変更だけで実施できる無効化・防御手順を、現場目線で解説します。

NetBIOS・LLMNRとは？名前解決のフォールバック問題

1. Windowsの名前解決順序と危険な「フォールバック」

WindowsがIPアドレス不明のホスト名にアクセスしようとするとき、名前解決は以下の順で試みられます。

・hostsファイル（ローカルの静的設定）
・DNS クエリ（設定済みDNSサーバーへの問い合わせ）
・LLMNR（Link-Local Multicast Name Resolution）（DNSで解決できなかった場合に同一リンク内へのブロードキャスト）
・NetBIOS over TCP/IP（さらに古いフォールバック機能、UDP/137番ポート）

問題は3番目・4番目にあります。DNSで解決できなかった名前は、LLMNRまたはNetBIOSによって「ネットワーク内の全端末に向けてブロードキャスト」されます。

この仕組みを悪用すると、攻撃者はそのブロードキャストに「私が知っている、こちらへ接続しなさい」という偽の応答を返し、接続を試みた端末からNTLM認証情報を騙し取ることができます。

2. LLMNRとNetBIOSの基本情報

・LLMNR: Windows Vista以降に搭載されたRFC 4795準拠のプロトコル。UDP/5355番ポートを使用。ローカルリンク（同一サブネット）内でのマルチキャストで機能
・NetBIOS over TCP/IP: Windows 2000以前から存在する古い名前解決機能。UDP/137番・138番、TCP/139番ポートを使用
・デフォルト状態: どちらもWindows Serverを含むWindowsの全バージョンでデフォルト有効

「うちはDNSをちゃんと管理しているから大丈夫」という考えは危険です。タイポや一時的なDNS障害でフォールバックは日常的に発生します。

攻撃の仕組み（敵を知る）

1. LLMNRポイズニングの全ステップ

攻撃者が社内ネットワークに足場を確保した後（フィッシングメール感染1台でも十分）、以下の手順で認証情報を収集します。

ステップ1: Responderを起動して待ち受ける

攻撃者はKali Linuxなどに搭載されているResponderツールを起動し、LLMNRブロードキャストを全ポートで受信できる状態にします。

ステップ2: 被害端末が誤ったUNCパスへアクセスしようとする

誰かが「\\fileserver1」を「\\filesrver1」とタイポした、または存在しないネットワーク共有にアクセスしようとしたとき、その端末はDNSで解決できないと判断し、LLMNRブロードキャストを発します。

ステップ3: 偽応答を返してNTLMハッシュを収集する

Responderが即座に「私が知っている」と偽応答を返します。被害端末はResponderが動く攻撃者のPCへNTLMv2認証を試み、その過程でNTLMv2ハッシュ（ユーザー名・チャレンジ・応答を含む認証データ）が渡ります。

ステップ4: オフラインでハッシュをクラックする

収集したNTLMv2ハッシュは、hashcatやJohn the Ripperといったオフラインクラッキングツールで解析します。パスワードが8文字以下・辞書語句を含む場合、GTX1080相当のGPUで数分～数時間で平文が判明します。

# 攻撃の流れ（概念図）
[端末A: タイポで\\filesrver1へアクセス試行]
  ↓ DNS問い合わせ → DNS: 不明
  ↓ LLMNRブロードキャスト "filesrver1を知っているか？"
  ↓ Responder(攻撃者PC): "知っている、私のところへ来い"
  ↓ 端末AがNTLMv2認証を試行 → NTLMv2ハッシュが攻撃者へ渡る
  ↓ オフラインクラック → 平文パスワード取得

2. NTLMリレー攻撃への発展

ハッシュのクラックを待つ必要すらないケースもあります。取得したNTLMv2ハッシュをそのまま別のサービス（SMBファイル共有、LDAPサーバー、HTTP認証など）に中継する「NTLMリレー攻撃」が成立すると、クラックなしにそのユーザーの権限で他のサービスへアクセスできます。

NTLMリレーはActive Directory環境でラテラルムーブメント（横移動）の起点となり、最終的にドメイン管理者権限の奪取につながる深刻な攻撃です。

3. 攻撃が成立する条件

この攻撃の怖いところは、条件のハードルが低いことです。

・必要な侵入口: フィッシングメールで感染した端末1台、または不正取得したVPNアカウント1つ
・ネットワーク要件: 被害端末と同一のL2セグメント（VLANで分離されていなければ同じフロアのLANで十分）
・ユーザー側の操作: タイポや一時的なネットワーク障害など、日常的に起きる誤操作
・必要なツール: ResponderはKali Linux標準搭載の無料ツール

具体的な防御手順

1. LLMNRをグループポリシーで無効化する

最も効果的な対策はLLMNRの無効化です。グループポリシー管理コンソール（GPMC）から以下のパスで設定します。

# グループポリシーでLLMNRを無効化する
# パス: コンピューターの構成 → 管理用テンプレート → ネットワーク → DNSクライアント
# 「マルチキャスト名前解決を無効にする」 → 「有効」に設定

# PowerShellでレジストリを直接設定する場合（管理者として実行）
$path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient"
If (-not (Test-Path $path)) { New-Item -Path $path -Force }
Set-ItemProperty -Path $path -Name "EnableMulticast" -Value 0 -Type DWORD

# 設定確認コマンド
Get-ItemProperty -Path $path -Name "EnableMulticast" -ErrorAction SilentlyContinue

設定後は `gpupdate /force` でポリシーを即時反映します。この1設定だけで、LLMNRポイズニング攻撃の大部分を無効化できます。

2. NetBIOS over TCP/IPを無効化する

LLMNRを無効化してもNetBIOS over TCP/IPが有効なら攻撃者はNetBIOSブロードキャストを悪用できます。合わせて無効化します。

# PowerShellで全NICのNetBIOS over TCP/IPを無効化する（管理者として実行）
$adapters = Get-WmiObject Win32_NetworkAdapterConfiguration
foreach ($adapter in $adapters) {
    if ($null -ne $adapter.TcpipNetbiosOptions) {
        # 0=規定値(DHCPに従う) / 1=有効 / 2=無効
        $result = $adapter.SetTcpipNetbios(2)
        Write-Host "Adapter: $($adapter.Description) - Result: $($result.ReturnValue)"
    }
}

# 設定確認（値が2なら無効化済み）
Get-WmiObject Win32_NetworkAdapterConfiguration |
    Select-Object Description, TcpipNetbiosOptions |
    Where-Object { $null -ne $_.TcpipNetbiosOptions }

3. SMB署名を強制してNTLMリレーを防ぐ

ハッシュを取られても、SMBへのリレーを防ぐことでダメージを最小化できます。グループポリシーで全クライアントに強制します。

# グループポリシーでSMB署名を強制する設定パス
# コンピューターの構成 → Windowsの設定 → セキュリティの設定
# → ローカルポリシー → セキュリティオプション

# 設定1: Microsoftネットワークサーバー: 通信にデジタル署名を行う（常に） → 有効
# 設定2: Microsoftネットワーククライアント: 通信にデジタル署名を行う（常に） → 有効

# レジストリでの確認コマンド（値が1なら署名強制）
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters" `
    -Name "RequireSecuritySignature"
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" `
    -Name "RequireSecuritySignature"

SMB署名強制は、NTLMリレー攻撃の大部分を無力化します。適用前に古いNAS・プリントサーバーなどレガシー機器の互換性を確認してください。

4. LAPSでローカル管理者パスワードの統一を防ぐ

全PC共通のローカル管理者パスワードを使っている環境では、1台のハッシュクラックで全PC管理者権限を一瞬で掌握されます。Microsoft LAPSはActive Directory環境で各PCのローカル管理者パスワードを自動ランダム化する無料ツールです。

LAPS導入後は、ハッシュクラックに成功しても侵害範囲が1台に限定されます。Active Directory全体のセキュリティ強化策については中小企業のActive Directoryセキュリティ対策ガイドも参照ください。

中小企業でも今日からできること

大きな予算や専任チームがなくても実施できる対策を、優先順に整理します。

・【最優先・コストゼロ】LLMNRの無効化: グループポリシー1設定で完了。既存業務への影響はほぼなし
・【最優先・コストゼロ】NetBIOS over TCP/IPの無効化: PowerShellスクリプトで全PC一括設定できる
・【高優先】SMB署名の強制: グループポリシーで設定。レガシー機器の事前確認が必要だが効果は大きい
・【高優先・無料】LAPSの導入: Microsoftが無料提供。被害範囲を1台に封じ込められる
・【継続的】Windowsイベントログの監視: イベントID 4776（NTLM認証失敗多発）を監視し、攻撃の早期検知につなげる

Windowsイベントログで不審なNTLM認証を検知する手順についてはWindowsイベントログ監視の実践ガイドを参照してください。

よくある誤解と注意点

「DNSをちゃんと管理しているから安全では？」
DNSが正常でも、タイポや一時的なDNSサーバー障害でLLMNRフォールバックは発生します。無効化しないと根本的な解決にはなりません。

「攻撃者が内部に入っていないから関係ない」
フィッシングメール1通で内部への足場は作られます。「侵入されないこと」だけを前提にする考え方は危険です。「侵入されても被害を最小化する」設計が現代のセキュリティの基本です。

「無効化すると業務に支障が出るのでは？」
現代のWindowsドメイン環境では名前解決はDNSで完結します。LLMNR・NetBIOSを無効化しても、DNSが正しく設定されていれば業務への影響はほぼありません。ただし、Linuxサーバーや古いNAS・複合機との接続については事前確認を推奨します。

「中間者攻撃（MITM）とはどう違うのか？」
中間者攻撃（MITM）は通信経路全体を傍受する広い概念です。LLMNRポイズニングはその一種で、名前解決の応答を偽装する形でMITMを成立させる具体的な手法の一つです。

本記事のまとめ

LLMNR・NetBIOSポイズニングは「設定を変えるだけで防げる攻撃」です。それにもかかわらず、多くの企業環境で今もデフォルト有効のまま放置されています。

「まず何から始めるか」の答えは明確です。グループポリシーでLLMNRを無効化し、PowerShellでNetBIOS over TCP/IPを無効化し、SMB署名を強制する——この3つで、内部ネットワークの認証情報窃取リスクを大幅に下げられます。専任のセキュリティ担当がいなくても、今日の作業時間内に実施できる対策です。