ビルド

ツールを一度コンパイルして結果のバイナリを使用するか、または「スクリプトのように」実行することができます（Goツールチェーンがその場でコンパイルします）。開発には後者のオプションが便利です。本番環境では、一度コンパイルし（cli ディレクトリから）、結果の実行可能ファイルを使用することを推奨します。Goコンパイラのおかげで、LinuxまたはWindowsからビルドし、それらのOS用にビルドできます。ビルドには少なくともGo 1.18が必要です（Go 1.23でテスト済み）。

Linuxからビルド

LinuxからWindowsまたはLinux用にビルドするには、適宜 GOOS を設定します（cli ディレクトリから実行）。``` GOOS=windows GOARCH=amd64 go build -o wcfproxy.exe

Full Report - `-pr` 有効な権限を含む整ったレポートを表示します。

## 🧰 モジュールとオプション

SPNMap はモジュール化されたアーキテクチャで構築されています。すべてのチェックやアクションはモジュールとして実装されています。

以下は現在利用可能なモジュールです：

- `bloodhound-integration` - ユーザーとグループのデータでの BloodHound 統合を有効化します。
- `bloodhound-ce` - `bloodhound-integration` が必要で、現在のユーザーの BloodHound カスタムプロパティの Windows エンドポイントを強調表示します。
- `constrained-delegation` - 制約付き委任をチェックし、ユーザーとコンピュータをリスト表示します。
- `kerberoast` - 高特権グループのメンバーを含む Kerberos サービスプリンシパル名（SPN）に関連付けられたユーザーアカウントをリスト表示する Kerberoasting モジュール。
- `asreproast` - DONT_REQ_PREAUTH フラグが設定されたユーザーアカウントをリスト表示する ASREPRoasting モジュール。
- `find-delegation` - 制約なし委任、制約付き委任、リソースベースの委任など、あらゆるタイプの委任が設定されたアカウントをすべてリスト表示します。
- `delegation-from` - 指定されたアカウントから他のアカウントへの委任を検索します。
- `smb-signing` - 指定されたリモートマシン上の SMB 署名の状態をテストします。
- `find-mssql` - ネットワーク上で MSSQL インスタンスを検索し、認証を試みます。
- `unconstrained-delegation` - 制約なし委任が設定されたオブジェクトを列挙します。
- `pass-pol` - ドメインからパスワードポリシーを抽出します。
- `install` - SPNMap に必要な Python モジュールをインストールします。
- `update` - SPNMap を最新バージョンに更新します。```
GOOS=linux GOARCH=amd64 go build -o wcfproxy

Windows からのビルド

Windows からビルドするには、同等のコマンドを実行します。例: PowerShell から:``` $env:GOOS='windows'; $env:GOARCH='amd64'; go build -o wcfproxy.exe

No content provided.```
$env:GOOS='linux'; $env:GOARCH='amd64'; go build -o wcfproxy

使用方法

wcfproxy の設定は JSON ファイルで提供されます。 デフォルトでは設定ファイル config.json が使用されますが、-config パラメータで設定ファイルのパスを指定できます。 設定ファイルには、任意の数の名前付き設定を含めることができます。例:```json { "my-config": { " ... ": " ... " } }

名前付き設定オブジェクトの値は `Config` 構造体と一致する必要があります（[Config構造](#config-structure) を参照）。
このソースファイルに含まれるコメントは、`wcfproxy` の設定オプションに関する最も正確なドキュメントとしても機能します。
提供されるすべての設定のうち、使用するものは、`-enable` コマンドラインオプションによって名前で識別されます。```
wcfproxy.exe -config config.json -enable my-config

設定構造

各設定オブジェクトの最上位構造は以下の通りです。```json { "listen": "[::1]:8000", "connect": "[::1]:9000", "retarget": "net.tcp://127.0.0.1:8000/WCFLab/WCFDemoService/nettcp", "retarget-map": { "nettcps": "net.tcp://localhost:8210/WCFLab/WCFDemoService/nettcps", "winauth": "net.tcp://localhost:8220/WCFLab/WCFDemoService/nettcp-winauth" }, "log-level": "debug|info|warn|error", "log-file": "path/to/log/file", "tls-server": { " ... ": " ... " }, "tls-client": { " ... ": " ... " }, "ntlm": { " ... ": " ... " }, "interceptor": { " ... ": " ... " }, "ctrl": { " ... ": " ... " } }

TLS設定（`tls-server` および/または `tls-client`）は、NTLM設定が存在する場合は提供できません。

### 設定オプション
+ `listen` - *wcfproxy* が待ち受けるTCPエンドポイント、例：`127.0.0.1:8000` または `[::1]:8000`
+ `connect` - 上流のWCFサーバーのTCPエンドポイント、例：`127.0.0.1:9000` または `[::1]:9000`
+ `retarget` - 元のターゲット指定（および `retarget-map` のフォールバック）。説明は [ターゲット書き換え](#target-rewriting) を参照
+ `retarget-map` - `retarget` の一般化。複数のエンドポイントに対するターゲット書き換えを可能にする（同じポート上で複数のWCFサービスを扱う場合にのみ有用）
    + `retarget-map` のキーのいずれかが現在のターゲットと一致する場合、上流通信のためにターゲットURIが指定された値に置き換えられる
    + `retarget-map` のどのキーも現在のターゲットと一致しない場合は、代わりに `retarget` が使用される
+ `log-level` - ログレベル。使用可能な値：`debug`、`info`（デフォルト）、`warn`、`error`
+ `log-file` - ログファイルへのパス。パスが指定されない場合、ログは `stdout` に出力される
+ `tls-server` - `TlsServerConfig` のインスタンス（[TLSサーバー設定](#tls-server-configuration) を参照）。TLSアップグレードをサポートする場合にのみ必要
+ `tls-client` - `TlsClientConfig` のインスタンス（[TLSクライアント設定](#tls-client-configuration) を参照）。TLSアップグレードをサポートする場合に関連
+ `ntlm` - `NtlmConfig` のインスタンス（[NTLM設定](#ntlm-configuration) を参照）。NTLMアップグレード（直接またはSPNEGO経由）をサポートする必要がある場合にのみ必要
+ `interceptor` - `InterceptorConfig` のインスタンス（[インターセプター設定](#interceptor-configuration) を参照）。必須
+ `ctrl` - `ControlServerConfig` のインスタンス（[コントロールサーバー設定](#control-server-configuration) を参照）。デフォルトのHTTPエコーサーバー（HTTPインターセプターと組み合わせて有用）と、メッセージフローを制御するための小さなAPI（開発中）を提供できる

### TLSサーバー設定
TLSサーバー側の設定は、通常関連するTLSサーバー設定のほとんどを制御します。
以下の構造を持ちます：```json
{
	"cert-pem": "path/to/certificate",
	"cert-key": "path/to/certificate-key",
	"max-version": "1.0|1.1|1.2|1.3",
	"min-version": "1.0|1.1|1.2|1.3",
	"client-roots": "path/to/client-ca1,path/to/client-ca2",
	"client-auth": "none|request|require-any|verify-if-given|require-and-verify",
	"keylog": "path/to/keylog-file"
}

TLS サーバー設定オプション

• cert-pem - X.509証明書（PEM形式）へのパス
• cert-key - 証明書に対応するキーへのパス
• max-version - 許容される最大TLSバージョン。 1.0、1.1、1.2、1.3（デフォルト）のいずれか
• min-version - 許容される最小TLSバージョン。 1.0（デフォルト）、1.1、1.2、1.3のいずれか
• client-roots - クライアント認証用の許容ルート証明書（PEM）へのパスのカンマ区切りリスト。オプション
• client-auth - クライアント認証ポリシー。最も有用な値: none（デフォルト）、require-and-verify
• keylog - NNS形式でTLSシークレットを書き込むファイル

TLS クライアント設定

TLSクライアント側の設定は、通常関連するTLSクライアント設定の大部分を制御します。 以下の構造を持ちます：```json { "cert-pem": "path/to/certificate", "cert-key": "path/to/certificate-key", "max-version": "1.0|1.1|1.2|1.3", "min-version": "1.0|1.1|1.2|1.3", "roots": "path/to/root-ca1,path/to/root-ca2", "server-name": "therealone.local", "skip-verify": false }

#### TLSクライアント設定オプション
+ [TLSサーバー設定オプション](#tls-server-configuration-options)と類似
+ `roots` - ルート認証局（PEM）へのパスをカンマ区切りで指定；`skip-verify`と共にオプション
+ `server-name` - サーバー名（SNI）；オプション
+ `skip-verify` - ブール値；クライアントがサーバー証明書の検証を省略するかどうか (デフォルト: `false`)

### NTLM設定
NTLM設定は、ドメインとサーバー名、およびユーザー資格情報を指定します。プロキシに対して認証できる各ユーザーに対して、有効な資格情報を提供する必要があります。```json
{
	"domain": "test.local",
	"server": "server.local",
	"credentials": [
		{ 
            " ... ": " ... "
        }
	]
}

NTLM 設定オプション

• domain - 認証対象のドメイン（例：test.local）。空欄の場合はサーバー名が使用されます。
• server - 認証対象のサーバー名。空欄の場合は現在のシステムのホスト名が使用されます。
• credentials - NtlmCredential の配列（以下参照）

NTLM 資格情報は NtlmCredential オブジェクトの配列として渡され、次の構造を持ちます：```json { "name": "wcflab", "password": "Sup3rS3cr3t", "nt-hash": "a8fc07dede90b0ec10bc1ef355f99292", "lm-hash": "3e9cb63e11a812cbc467021088dc706f" }

+ `name` - ユーザー名
+ `password` - ユーザーのパスワード; これからハッシュが導出されます; ユーザーに指定されたハッシュを上書きします
+ `nt-hash` - ユーザーパスワードのNTハッシュ（16進数）; パスワードの代替
+ `lm-hash` - ユーザーパスワードのLMハッシュ（16進数）; パスワードの代替; ほとんどの場合必要ありません

パスワードが指定された場合、LMハッシュ（すべてのパスワードで可能ではない）とNTハッシュがそれから計算されます。このユーザーに与えられたハッシュ値は計算されたハッシュで上書きされます。ユーザーハッシュのみを指定することも可能です。LMハッシュはほとんどのシナリオで不要です。

### インターセプター設定
インターセプター設定は、使用するインターセプター（名前で指定）と、オプションでインターセプター固有の引数を指定します。インターセプターの説明については、[インターセプター](#interceptors)を参照してください。

#### ログインターセプター
ログインターセプターを使用するには、以下のインターセプター設定を使用するだけです。出力はメインのログ出力先に書き込まれます。これは、`log-file`設定に応じてファイルまたは`stdout`になります。```json
{
	"name": "log"
}

Http interceptor

HTTPインターセプターを使用するには、適切なオプションをserver-urlおよびproxy-urlに指定して、以下のインターセプター構成を使用してください。```json { "name": "http", "args": { "server-url": "http://127.0.0.1:9999/echo", "proxy-url": "http://127.0.0.1:8080" } }

+ `args.server-url` - HTTPサーバーインターセプションエンドポイントのURL (例: シンプルなエコーエンドポイント); HTTPインターセプターの動作の詳細は [HTTP Interceptor](#http-interceptor-1) を参照
+ `args.proxy-url` - HTTPプロキシのURL; オプション

### コントロールサーバーの設定
*wcfproxy* には2つの機能を提供する組み込みWebサーバーが含まれています。
最初に、送信されたすべてのコンテンツを単に反映するHTTPエンドポイントを提供できます。
これは [HTTP Interceptor](#http-interceptor-1) と組み合わせて便利です。```json
{
	"ctrl": {
		"listen": "127.0.0.1:9999",
		"enable-control": false,
		"enable-echo": true
	}
}

[!WARNING]
APIにアクセスできる人は誰でも、提供された資格情報（NTLMまたはTLSクライアント証明書）を使用して認証できます。 共有システムでは、APIがローカルでのみ利用可能な場合でも、これが重要になることがあります。

制御サーバー設定オプション

• listen - 制御サーバーがリッスンするTCPエンドポイント
• enable-contorl - メッセージインジェクションや接続確立などの制御機能を有効にします（メッセージインジェクションを参照）
• enable-echo - http://{listen}/echo でシンプルなHTTPエコーサーバーを有効にします

詳細

以下のセクションでは、WCFやいくつかの設定オプションをよりよく理解するための背景情報を提供します。