Skip to content
KitploitKITPLOIT
도구블로그
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
wcfproxy — net.tcp 기반 WCF 트래픽을 위한 프록시 | Kitploit
도구/GitHubGitHub/syss-research/wcfproxy
Web Proxies & InterceptionAPI Security TestingNetwork SecurityPenetration TestingBinary AnalysisAuthentication
GitHubsyss-research/wcfproxy

wcfproxy

net.tcp 기반 WCF 트래픽을 위한 프록시

저장소 보기
84개월 전아직 검토되지 않음

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유

빌드

도구를 한 번 컴파일한 후 결과 바이너리를 사용하거나 "스크립트처럼" 실행할 수 있습니다 (Go 툴체인이 즉시 컴파일합니다). 개발 시에는 후자의 옵션이 편리합니다. 실제 사용 시에는 (cli 디렉터리에서) 한 번 컴파일하고 결과 실행 파일을 사용하는 것이 좋습니다. Go 컴파일러 덕분에 Linux 또는 Windows에서 빌드하고, Linux 또는 Windows용으로 빌드할 수 있습니다. 빌드하려면 Go 1.18 이상이 필요합니다 (Go 1.23으로 테스트됨).

Linux에서 빌드

Linux에서 Windows 또는 Linux용으로 빌드하려면 GOOS를 적절히 설정하세요 (cli 디렉터리에서 실행):``` GOOS=windows GOARCH=amd64 go build -o wcfproxy.exe

root@kitploit:~
죄송합니다. 제공된 입력이 없습니다. 빈 입력이 수신되었습니다.```
GOOS=linux GOARCH=amd64 go build -o wcfproxy

Windows에서 빌드

Windows에서 빌드하려면 PowerShell에서와 같이 동등한 명령을 실행하세요:``` $env:GOOS='windows'; $env:GOARCH='amd64'; go build -o wcfproxy.exe

root@kitploit:~
입력:```
$env:GOOS='linux'; $env:GOARCH='amd64'; go build -o wcfproxy

사용법

wcfproxy의 구성은 JSON 파일을 통해 제공됩니다. 기본적으로 config.json 구성 파일이 사용되지만, 구성 파일 경로는 -config 매개변수로 지정할 수 있습니다. 구성 파일은 임의의 많은 명명된 구성을 포함하도록 설계되었습니다. 예를 들면 다음과 같습니다:```json { "my-config": { " ... ": " ... " } }

root@kitploit:~
명명된 구성 객체들의 값은 `Config` 구조체와 일치해야 합니다 ([Config structure](#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:~
NTLM 구성이 있는 경우 TLS 구성(`tls-server` 및/또는 `tls-client`)을 제공할 수 없습니다.

### Configuration options
+ `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` - 루트 CA(PEM)의 쉼표로 구분된 경로 목록; `skip-verify`와 함께 선택 사항
+ `server-name` - 서버 이름(SNI); 선택 사항
+ `skip-verify` - bool; 클라이언트가 서버 인증서 검증을 생략할지 여부 (기본값: `false`)

### NTLM 구성
NTLM 구성은 도메인, 서버 이름 및 사용자 자격 증명을 지정합니다.
프록시에 대해 인증할 수 있어야 하는 각 사용자에 대해 유효한 자격 증명이 제공되어야 합니다.```json
{
	"domain": "test.local",
	"server": "server.local",
	"credentials": [
		{ 
            " ... ": " ... "
        }
	]
}

NTLM 구성 옵션

  • domain - 인증할 도메인 (예: test.local); 비워두면 서버 이름이 사용됩니다
  • server - 인증할 서버 이름; 비워두면 현재 시스템의 호스트 이름이 사용됩니다
  • credentials - NtlmCredential 객체의 배열 (아래 참조)

NTLM 자격 증명(credentials)은 다음과 같은 구조의 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 인터셉터

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 인터셉터](#http-interceptor-1)를 참조하세요.
+ `args.proxy-url` - HTTP 프록시의 URL; 선택 사항

### 제어 서버 구성
*wcfproxy*는 두 가지 기능을 제공하는 내장 웹 서버와 함께 제공됩니다.
첫째, 전송된 모든 콘텐츠를 단순히 반사하는 HTTP 엔드포인트를 제공할 수 있습니다.
이는 [HTTP 인터셉터](#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 엔드포인트를 동시에 작업할 때 모든 엔드포인트에 대해 대상 재작성을 수행해야 할 수 있습니다. 이를 위해 retarget-map 옵션이 있으며, 이 옵션은 대상 URI 간의 매핑을 정의합니다. retarget-map에서 일치하는 항목이 없으면 대상 URI는 retarget에 지정된 값으로 변경됩니다.

유형 힌트

MC-NBFX에 의해 지정된 바이너리 XML은 기본 유형 정보를 바이너리 형식(레코드 유형)으로 인코딩합니다. 이 정보의 일부는 바이너리 XML 문서의 (텍스트) XML 표현에서 쉽게 복구할 수 없습니다. 이러한 이유로 wcfproxy는 XML 문자 데이터(및 일부 속성) 토큰에 유형 힌트를 삽입합니다. 이러한 유형 힌트는 <h>: 형식을 가지며, 여기서 <h>는 일부 유형을 인코딩하는 짧은 문자열입니다(예: 정수의 경우 i, 문자의 경우 ch). 전체 유형 힌트 목록은 typehint.go에서 확인할 수 있습니다. 유형 힌트를 조작하는 것은 권장되지 않습니다.

인터셉터

인터셉터는 수신된 트래픽이 처리되는 방식을 지정하며 인터셉터 구성을 통해 지정됩니다. 이는 양방향(클라이언트 -> 서버 및 서버 -> 클라이언트)으로 전송되는 트래픽을 처리합니다. 현재 log 및 http의 두 가지 인터셉터가 있습니다.

로그 인터셉터

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 메시지(예: 클라이언트 -> 서버)에 대해 HTTP 요청-응답 쌍이 생성됩니다.

메시지를 해당 메시지가 시작된 net.tcp 연결과 연관시키기 위해 X-Wcpf-Conn-Id 헤더가 http 인터셉터에 의해 생성된 요청에 삽입됩니다.

다음 이미지는 http 인터셉터를 사용한 데이터 흐름을 보여줍니다.

http-interceptor illustration

TLS 옵션

WCF(net.tcp를 통한)는 전송 보안을 위해 TLS를 사용할 수 있습니다. wcfproxy는 TLS 연결(SSL이 아닌 TLS 1.0 ~ 1.3만 해당)의 가로채기를 지원합니다. 서버 측 및 클라이언트 측 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 또는 Negotiate(NTLM))가 있는 경우 이를 지정하는 JSON 객체여야 합니다. 엔드포인트 URI는 target-uri 속성을 통해 제공됩니다.

예: 업그레이드 없음

업그레이드가 필요하지 않은 경우 upgrade 속성을 생략할 수 있습니다.```json { "target-uri":"net.tcp://127.0.0.1:9510/example/notes-nettcp" }

root@kitploit:~
#### 예: TLS 업그레이드
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 트래픽은 HTTP를 통해 전송되는 (거의) 일반 SOAP 봉투로 변환됩니다.
![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>"
                }
            ]
        }
	}
}

현재는 자동 구성에 의존하기보다 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 비밀을 기록할 파일