Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに！

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
wcfproxy — net.tcpベースのWCFトラフィックのプロキシ。 | Kitploit
ツール/GitHubGitHub/syss-research/wcfproxy
ウェブプロキシと傍受APIセキュリティテストネットワークセキュリティペネトレーションテストバイナリ解析認証
GitHubsyss-research/wcfproxy

wcfproxy

net.tcpベースのWCFトラフィックのプロキシ。

リポジトリを見る
84ヶ月前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

ビルド

ツールを一度コンパイルして結果のバイナリを使用するか、または「スクリプトのように」実行することができます（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

root@kitploit:~
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

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

使用方法

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

root@kitploit:~
名前付き設定オブジェクトの値は `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": { " ... ": " ... " } }

root@kitploit:~
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（デフォルト）、

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 }

root@kitploit:~
#### 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" }

root@kitploit:~
+ `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" } }

root@kitploit:~
+ `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やいくつかの設定オプションをよりよく理解するための背景情報を提供します。

ターゲット書き換え

意図されたWCFエンドポイントは、net.tcpプリアンブルおよびSOAPエンベロープに含まれるToヘッダーにエンコードされています。 サーバーはこのエンドポイント指定が期待されるものと一致することを確認する場合があります。 クライアントが元のサーバーではなくプロキシに接続するように操作された場合、このエンドポイント指定は変更される可能性があり、サーバーが通信を拒否する可能性があります。 そのため、通常はサーバーへの送信トラフィック内のエンドポイント指定を修正することが理にかなっています。 これを行うには、設定ファイルのretargetオプションに（例えばクライアント設定から取得した）元のエンドポイント指定を指定します。 エンドポイント指定は通常、次のようになります: net.tcp://some/endpoint。

複数のWCFエンドポイントを同時に扱う場合、すべてのエンドポイントに対してターゲット書き換えを実行する必要があるかもしれません。 このために、ターゲットURI間のマッピングを定義するretarget-mapオプションが存在します。 retarget-mapで一致が見つからない場合、ターゲットURIはretargetで指定された値に変更されます。

型ヒント

MC-NBFXで指定されるバイナリXMLは、バイナリ形式（レコードタイプ）で基本型情報をエンコードします。 この情報のすべてがバイナリXML文書の（テキスト）XML表現から簡単に復元できるわけではありません。 このため、wcfproxyはXML文字データ（および一部の属性）トークンに型ヒントを挿入します。 これらの型ヒントは<h>:の形式をとり、<h>はいくつかの型をエンコードする短い文字列です（例: iは整数、chは文字）。 型ヒントの完全なリストはtypehint.goにあります。 型ヒントの改ざんは推奨されません。

インターセプタ

インターセプタは、受信したトラフィックの処理方法を指定し、インターセプタ設定を介して指定されます。 これらは双方向（クライアント→サーバーおよびサーバー→クライアント）で送信されるトラフィックを処理します。 現在、logとhttpの2つのインターセプタがあります。

ログインターセプタ

logインターセプタは、バイナリエンコードされたSOAPエンベロープを、通常のテキストベースのXMLを使用してエンコードされた人間が読める形式に変換します。 （ターゲット指定の書き換え以外の）能動的な操作は実行されません。 出力は指定されたログの場所に送信されます（デフォルトではstdout）。 ログレベルをinfo（またはdebug）に設定してください。そうしないと、関連する出力が抑制されます。

HTTPインターセプタ

httpインターセプタは、バイナリSOAPエンベロープをテキストベースのものに変換し、-http-urlで指定されたHTTPエンドポイントに送信します。 デコードされたSOAPメッセージはリクエストボディで送信されます。 HTTPサーバーは、受信メッセージと同じ形式の有効なSOAPエンベロープを返す必要があります。 これらのメッセージは元のバイナリ形式に変換され、上流サーバーに送信されます。

HTTPサーバーが単に元のメッセージをそのまま返すことは常に有効なオプションです。 しかし、目的の置き換えを実行するカスタムHTTPサーバーを提供することで、プログラムによるメッセージの操作も可能です。 SOAPメッセージの構造を壊さないよう注意する必要があります。 自分が何をしているか理解していない限り、メッセージの形式をいじらないことをお勧めします。 さらに、wcfproxyによって挿入された型ヒントは改ざんしないでください。これは、テキストベースのSOAPメッセージをバイナリに戻す変換や、正当なエンドポイント（クライアントまたはサーバー）でのメッセージ解析を壊す可能性があります。

wcfproxyには、受信したHTTPリクエストのボディを単にそのまま返す簡単なHTTPサーバーが付属しています。 このサーバーは、制御サーバー設定が提供され、enable-echoオプションがtrueに設定されている場合に起動されます。 目的のHTTPサーバーのURLは、httpインターセプタ設定のserver-urlオプションで指定します。

インタラクティブな操作を可能にするために、proxy-urlオプションでHTTPプロキシ（例: BurpSuite）を指定できます。 メッセージは指定されたHTTPプロキシを介してHTTPサーバーに送信されます。 WCFメッセージごとに（例: クライアント→サーバー）、1つのHTTPリクエスト/レスポンスペアが生成されることに注意してください。

メッセージをそれらが発生したnet.tcp接続に関連付けるために、httpインターセプタによって生成されたリクエストにX-Wcpf-Conn-Idヘッダーが挿入されます。

次の図は、httpインターセプタを使用したデータフローを示しています。

http-interceptor illustration

TLSオプション

WCF（net.tcp経由）はトランスポートセキュリティにTLSを使用できます。 wcfproxyはTLS接続のインターセプトをサポートしています（TLS 1.0～1.3のみ、SSLはなし）。 サーバー側とクライアント側のTLS設定は、対応するTLS設定（TLSサーバー設定またはTLSクライアント設定を参照）で制御できます。

NTLMオプション

wcfproxyはNTLM認証をサポートしています。 現在、直接NTLM認証またはSPNEGOを介したネゴシエーションがサポートされています。 認証を行うユーザーの資格情報を提供する必要があります。 これらの資格情報はJSON形式で提供されます。NTLM設定を参照してください。 ハッシュの受け渡しは、nt-hashプロパティを介してハッシュを提供することでサポートされています。

メッセージインジェクションと接続確立

制御サーバーが有効な場合、接続の確立や終了、既存の接続へのメッセージ注入に使用できる小さなHTTP APIが提供されます。 次のエンドポイントが利用可能です。

GET /connection

現在アクティブな接続の一覧を表示します。 サーバーのみの接続（POST /connection/newで作成されたもの）の場合、クライアントはwcfproxyとして表示されます。

POST /connection/new

新しい接続を作成します。 ボディは、意図されたアップグレード（TLSまたはネゴシエート（NTLM））がある場合、それを指定するJSONオブジェクトである必要があります。 エンドポイントURIはtarget-uriプロパティで提供されます。

例: アップグレードなし

アップグレードが必要ない場合、upgradeプロパティは省略できます。```json { "target-uri":"net.tcp://127.0.0.1:9510/example/notes-nettcp" }

root@kitploit:~
#### 例: TLS upgrade
TLS アップグレードを開始するには、アップグレード機構 `tls` を指定してください。```json
{
    "target-uri":"net.tcp://wcf-notes.local:9511/example/notes-nettcp-tls",
    "upgrade": {
        "mechanism":"tls"
    }
}

例：NTLMアップグレード

upgradeオブジェクトは、メカニズムとしてntlmを指定し、認証するユーザーを指定する必要があります。 ユーザーの認証情報は、ntlm構成で提供される必要があります。```json { "target-uri":"net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcp-winauth", "upgrade": { "mechanism": "ntlm", "ntlmuser": "wcflab" } }

root@kitploit:~
### POST `/connection/{id}/kill`
`{id}` で識別される接続を破棄します。

### POST `/connection/{id}/inject`
このリクエストの本文で提供されたメッセージを、`{id}` で識別される接続に注入します。
本文は、WCF メッセージを HTTP インターセプターに転送するために使用されるのと同じ形式でなければなりません。
そのため、観測されたメッセージをコピーし、必要に応じて変更し、このエンドポイントを介して注入するのが最適です。

デフォルトでは、注入されたメッセージへの応答は表示されません。
ただし、インターセプターがアクティブな場合、応答はそこに表示されるはずです。
便宜上、クエリパラメータ `retrieve=true` が指定された場合、`wcfproxy` は注入されたメッセージへの応答を待機し、それを表示します。

## 接続制限
同時にアクティブな接続数に人為的な上限が設定されています。
この制限は現在 20 に設定されています。
これは、制御 API を（誤って）使用した際に意図せずリソースが枯渇するのを防ぐためです（[メッセージ注入と接続確立](#message-injection-and-connection-establishment) を参照）。
これは、正当な WCF クライアントにとって問題になることはほとんどありません。
ただし、より多くの同時接続を必要とするユースケースが存在する可能性があります。
その場合は、[proxy.go](https://github.com/syss-research/wcfproxy/blob/HEAD/proxy/proxy.go) 内の定数 `maxConnections` を必要に応じて変更してください。

# 例
以下の例は、*wcfproxy* の基本的な使用方法を示しています。
正確な出力は変更される可能性がありますが、概念は伝わるはずです。

## ログインターセプターの使用
この例は、**log** インターセプターを使用した、net.tcp を介したプレーンな WCF 通信における WCF プレイグラウンド環境での *wcfproxy* の使用を示しています。```json
{
    "wcflab-plain": {
        "listen": "127.0.0.1:7201",
        "connect": "127.0.0.1:8201",
        "retarget": "net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp",
        "log-level": "debug",
        "interceptor": {
            "name": "log"
        }
    }
}

上記の設定（config.jsonに配置）を使用すると、以下のように使用できます。 プロキシを経由するトラフィックは、コンソール（stdout）に出力されるはずです。```

.\wcfproxy.exe -config .\config.json -enable wcflab-plain 2025/07/10 15:03:59 dbg: local time zone (for DateTime handling): CEST INFO: Listening on 127.0.0.1:7201 and connecting to 127.0.0.1:8201 INFO: No server certificates given. TLS upgrade not supported. INFO: No client certificates given. TLS client authentication not supported. INFO: Retargeting to net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp INFO: [proxy] Handling new connection 0: 127.0.0.1:50216 <-> 127.0.0.1:8201 INFO: [proxy] Connection 0 established (127.0.0.1:50216 <-> 127.0.0.1:8201) INFO: [proxy] Envelope (Connection 0, Client -> Server): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action> <a:MessageID>uid:urn:uuid:b2d5fc85-4bcd-6442-b701-164655365198</a:MessageID> <a:ReplyTo> <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="c:1">ch:net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp</a:To> </s:Header> <s:Body>

i:1234 i:37 </s:Body> </s:Envelope> INFO: [proxy] Envelope (Connection 0, Server -> Client): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action> <a:RelatesTo>uid:urn:uuid:b2d5fc85-4bcd-6442-b701-164655365198</a:RelatesTo> <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To> </s:Header> <s:Body> i:1271 </s:Body> </s:Envelope> INFO: [proxy] Connection 0 closed (127.0.0.1:50216 <-> 127.0.0.1:8201) ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:50217->127.0.0.1:8201: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: 127.0.0.1:50216 <-> 127.0.0.1:8201

root@kitploit:~
## **http**インターセプターの使用
次の設定では、**http**インターセプターをHTTPプロキシと組み合わせて使用します。```json
{
    "wcflab-plain-http": {
        "listen": "127.0.0.1:7201",
        "connect": "127.0.0.1:8201",
        "retarget": "net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp",
        "log-level": "info",
        "ctrl": {
            "listen": "127.0.0.1:9999",
            "enable-echo": true
        }, 
        "interceptor": {
            "name": "http",
            "args": {
                "proxy-url": "http://127.0.0.1:8080"
            }
        }
    }
}

この構成では、ログに特筆すべき内容は表示されません。```

go run ./ -config .\config.json -enable wcflab-plain-http 2025/07/10 18:06:02 dbg: local time zone (for DateTime handling): CEST 2025/07/10 18:06:02 DBG - configuring intercrptor: &{http map[proxy-url:http://127.0.0.1:8080]} INFO: Listening on 127.0.0.1:7201 and connecting to 127.0.0.1:8201 INFO: No server certificates given. TLS upgrade not supported. INFO: No client certificates given. TLS client authentication not supported. INFO: Retargeting to net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp INFO: [proxy] Starting control server on 127.0.0.1:9999 (echo enabled: true, control enabled: false) INFO: [proxy] Handling new connection 0: 127.0.0.1:22664 <-> 127.0.0.1:8201 ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:22665->127.0.0.1:8201: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: 127.0.0.1:22664 <-> 127.0.0.1:8201

root@kitploit:~
ただし、WCFトラフィックは（ほぼ）通常のSOAPエンベロープに変換され、HTTP経由で送信されます。
![http interceptor example image](https://assets.kitploit.com/production/public/readmes/13529/e10d1090b25a6364f8d5e516349a1498bdc89b120dddde2e2ed324bacd253db5.png)


## (m)TLS インターセプションの設定
*wcfproxy* は、適切なサーバー証明書とクライアント証明書が利用可能であれば、mTLSで保護されたWCFトラフィックをインターセプトするように設定できます。
クライアント認証なしのTLSの設定も同様です。この場合、クライアント証明書は必要ありません。
以下の設定は、このユースケースの例を示しています:```json
{
    "wcflab-mtls": {
        "listen": "127.0.0.1:7203",
        "connect": "127.0.0.1:8203",
        "retarget": "net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls",
        "interceptor": {
            "name": "log"
        },
        "tls-server": {
            "cert-pem": "../testdata/pki/server.pem",
            "cert-key": "../testdata/pki/server.key"
       },
       "tls-client": {
            "cert-pem": "../testdata/pki/client.pem",
            "cert-key": "../testdata/pki/client.key",
            "skip-verify": true
       }
}

なお、クライアントはサーバー証明書（server.pem）を信頼する必要があります。 さらに、サーバーは wcfproxy のクライアント部分が提示する証明書（client.pem）を信頼しなければなりません。```

.\wcfproxy.exe -config .\config.json -enable wcflab-mtls 2025/07/10 15:01:32 dbg: local time zone (for DateTime handling): CEST INFO: Using client certificate client-01.local (SHA256-fingerprint: 9b258653a4d5f338f2be1dafe0caf892b01d271183e52f0821d80439de4b7564) INFO: Listening on 127.0.0.1:7203 and connecting to 127.0.0.1:8203 INFO: Using server certificate wcflab.local (SHA256-fingerprint: 7286ff75d3bb6dc4d96c0c8ac08dbac2204af67e0b1814b3d8c59c24d5bd781a) INFO: Server supports TLS versions 1.0 - 1.3 INFO: Using client certificate client-01.local (SHA256-fingerprint: 9b258653a4d5f338f2be1dafe0caf892b01d271183e52f0821d80439de4b7564) INFO: Client supports TLS versions 1.0 - 1.3 INFO: Retargeting to net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls INFO: [proxy] Handling new connection 0: 127.0.0.1:50214 <-> 127.0.0.1:8203 INFO: [proxy] Connection 0 established (127.0.0.1:50214 <-> 127.0.0.1:8203) INFO: [proxy] Initiating TLS upgrade INFO: [proxy] 127.0.0.1:50214 <-> 127.0.0.1:7203: negotiated TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) INFO: [proxy] 127.0.0.1:50215 <-> 127.0.0.1:8203: negotiated TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) INFO: [proxy] Upgrade done INFO: [proxy] Envelope (Connection 0, Client -> Server): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action> <a:MessageID>uid:urn:uuid:d36e17be-2cc2-a94f-83a7-cd2442dba24e</a:MessageID> <a:ReplyTo> <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="c:1">ch:net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls</a:To> </s:Header> <s:Body>

i:1234 i:37 </s:Body> </s:Envelope> INFO: [proxy] Envelope (Connection 0, Server -> Client): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action> <a:RelatesTo>uid:urn:uuid:d36e17be-2cc2-a94f-83a7-cd2442dba24e</a:RelatesTo> <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To> </s:Header> <s:Body> i:1271 </s:Body> </s:Envelope> INFO: [proxy] Connection 0 closed (127.0.0.1:50214 <-> 127.0.0.1:8203) ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:50215->127.0.0.1:8203: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: 127.0.0.1:50214 <-> 127.0.0.1:8203

root@kitploit:~
## NTLM認証の設定
WCFサービスがNTLM認証に依存している場合（直接またはSPNEGO経由）、以下の設定を使用してトラフィックを傍受できます。```json
{
    "wcflab-ntlm": {
        "listen": "[::1]:7204",
        "connect": "[::1]:8204",
        "retarget": "net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth",
        "interceptor": {
            "name": "log"
        },
        "ntlm": {
            "domain": "DESKTOP-65ITJF5",
            "credentials": [
                {
                    "name": "<user>",
                    "password": "<password>"
                }
            ]
        }
	}
}

Note that currently it is more robust to provide the host name via the server or domain field than relying on automatic configuration. Furthermore, authentication in a AD domain context is not tested and therefore is likely broken for the moment. When SPNEGO is used, currently the NTLM mechanism must be the preferred one, otherwise negotiation will fail.

現在のところ、自動設定に依存するよりも、server または domain フィールドを介してホスト名を指定する方が堅牢です。 さらに、ADドメインコンテキストでの認証はテストされておらず、現時点ではおそらく機能しません。 SPNEGOを使用する場合、現在のところNTLMメカニズムが優先される必要があり、そうでなければネゴシエーションは失敗します。```

.\wcfproxy.exe -config .\config.json -enable wcflab-ntlm 2025/07/10 15:15:15 dbg: local time zone (for DateTime handling): CEST INFO: Listening on [::1]:7204 and connecting to [::1]:8204 INFO: No server certificates given. TLS upgrade not supported. INFO: No client certificates given. TLS client authentication not supported. INFO: Retargeting to net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth INFO: [proxy] Handling new connection 0: [::1]:50247 <-> [::1]:8204 INFO: [proxy] Connection 0 established ([::1]:50247 <-> [::1]:8204) INFO: [proxy] Initiating Negotiate upgrade INFO: [NTLM server] User wcflab authenticated successfully INFO: [proxy] [::1]:50247 <-> [::1]:7204: negotiated NTLM INFO: [proxy] [::1]:50248 <-> [::1]:8204: negotiated NTLM INFO: [proxy] Upgrade done INFO: [proxy] Envelope (Connection 0, Client -> Server): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action> <a:MessageID>uid:urn:uuid:f9cc5af3-3930-9242-be3c-d36d2a0cb09e</a:MessageID> <a:ReplyTo> <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="c:1">ch:net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth</a:To> </s:Header> <s:Body>

i:1234 i:37 </s:Body> </s:Envelope> INFO: [proxy] Envelope (Connection 0, Server -> Client): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action> <a:RelatesTo>uid:urn:uuid:f9cc5af3-3930-9242-be3c-d36d2a0cb09e</a:RelatesTo> <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To> </s:Header> <s:Body> i:1271 </s:Body> </s:Envelope> INFO: [proxy] Connection 0 closed ([::1]:50247 <-> [::1]:8204) ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp [::1]:50248->[::1]:8204: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: [::1]:50247 <-> [::1]:8204

root@kitploit:~
ツールをダウンロード
require-and-verify
  • keylog - NNS形式でTLSシークレットを書き込むファイル