eBPFでTLS平文を直接“掴む”ecapture、CA挿入不要のオンエンドポイント復号が突き付ける現実です

今日の深掘りポイント

• ネットワーク経路での復号やCA挿入ではなく、ユーザー空間ライブラリの関数にeBPFを“張る”ことで、暗号化前後の平文を取得する発想の転換が本質です。
• 端点が一度乗っ取られればTLSは守ってくれない、という「防御の前提」を企業に再確認させる出来事です。証明書ピンニングも無力化されます。
• 防御側は「eBPFをどう使うか」だけでなく「誰が、どのBPFを、どこに張ったか」を継続的に可視化・監査する体制構築が急務です。
• 実務の要は、CAP_BPF/CAP_PERFMONの委譲管理、unprivileged BPFの無効化、perf_eventの制御、LSM（SELinux/AppArmor）・seccomp・Kubernetesポリシーでの“BPF面の最小権限化”です。
• 可観測性の軸をbpftool・auditd・Tetragon/Tracee/Falcoなどで揃え、「正当なBPF」と「不正なBPF」のベースラインを持つことが、検知の起点になります。

はじめに

パケットの外側ではなく、アプリの“口元”で言葉を拾う——この比喩が、ecaptureの本質をよく表しています。TLSインスペクション用に社内CAを挿すでも、鍵を抜き取るでもなく、SSL_read/SSL_writeのような関数にeBPFのuprobesを仕掛け、暗号化前（あるいは復号後）の平文を直接観測するアプローチです。便利であると同時に、攻撃者が後付けの盗聴を容易にしてしまう危うさもはらんでいます。端点の支配を許せば、通信の“前”に情報は抜かれる——その現実にどう向き合うかを、今日は掘り下げます。

深掘り詳細

事実整理（一次情報）

• ecaptureは、Linux/Android上でeBPF uprobesを用い、OpenSSL/LibreSSL/BoringSSL、GnuTLS、NSS/NSPR、Goのcrypto/tls等の関数呼び出しにフックして平文データを取得できるツールです。対応アーキテクチャはx86_64とaarch64です［プロジェクトREADME］。GitHub: ehids/ecapture
• しくみの要は「ユーザー空間プローブ（uprobes）」で、ユーザー空間の関数エントリ/リターンにフックし、メモリ上の引数や戻り値を観測することです。カーネルのトレーシング機構としてのuprobeは公式にドキュメント化されています［Linux kernel docs］。Uprobe tracer
• eBPFプログラムのロード・アタッチには通常root権限が必要で、Linuxの権限モデル上はCAP_BPFやCAP_PERFMON、場合によってはCAP_SYS_ADMIN等が絡みます［man-pages］。man7: capabilities(7)
• セキュリティハードニングの観点で、unprivileged BPFを無効化するsysctl、ならびにperf_eventの利用制御は広く周知の対策項目です［Linux kernel docs］。
  • unprivileged BPFの無効化: kernel.unprivileged_bpf_disabled［Linux kernel docs］。sysctl kernel: unprivileged_bpf_disabled
  • perf_eventの制限: kernel.perf_event_paranoid［Linux kernel docs］。Perf security
• Android自体もシステム機能でeBPFを活用しており、仕組みや権限制御は公開されています。企業配布端末では、そもそもroot化を許さない運用が前提です［Android Open Source Project］。Android eBPF architecture
• MITRE ATT&CKでの関連は、技術そのものは「ネットワークスニッフィング（平文取得を含む）」「APIフックを用いた入力/資格情報捕捉」、加えて持続化や隠蔽の実装次第で“ルートキット的”回避にも接続します［MITRE ATT&CK］。
  • Network Sniffing: T1040
  • Credential API Hooking（APIフックで資格情報を盗取）: T1056/004
  • Create or Modify System Process（Linuxのsystemd等で持続化）: T1543/002
  • Rootkit（検知回避のための隠蔽）: T1014

参考（セカンダリ情報）: KitPloit: eCapture — Capturing SSL/TLS Text Without a CA

インサイト（編集部の視点）

• CA挿入型のTLSインスペクションは「ネットワーク上で暗号を開ける」発想でしたが、ecaptureは「アプリが暗号化する前に観る」という設計です。証明書ピンニングやTLS1.3の鍵合意の堅牢性は、端点の支配が起きた瞬間に意味を失います。これは“TLSの強度”議論ではなく“エンドポイントの完全性”の問題です。
• 防御側の使い所は明確です。IRの現場で未知マルウェアのデータ持ち出し先や送信内容を手早く可視化したいとき、アプリ改変やMITMをせずに平文を観測できるのは強力です。ただし常用監視に組み込むなら、プライバシー・法令遵守・保管ポリシーの基準を先に整えてください。平文を見られることは、見てしまう責任も同時に生みます。
• 悪用面では、ポストエクスプロイトの“静かな収集”がしやすくなります。特に資格情報・トークン・個人情報・機微ログなど、TLSで守られているはずのデータがそのまま抜かれます。対策は結局「eBPFのガバナンス」と「BPFの見える化・検知」に帰着します。BPFプログラムのロード・アタッチ・ピン留め・uprobes設定を監査し、許容リストを持つ体制が求められます。
• 実務判断としては、本件は新規性・実運用への適用可能性・検知/防御の難しさがいずれも高い事案です。一方、前提権限（root/CAP_BPF等）を要すること、オンホストでしか効かないことから、即時の“広域横断リスク”ではなく、端点侵害後の被害拡大ドライバーと捉えるのが適切です。すなわち、プリベンションよりもディテクション/レスポンスの強化が効果を発揮しやすい領域です。

脅威シナリオと影響

以下は仮説シナリオです。具体的な挙動は環境差分や攻撃者の実装に依存します。

• シナリオ1：侵害済みLinuxサーバ上での“静かな盗聴”

  • 流れ（仮説）：攻撃者が権限昇格後、ecapture相当のuprobesでWebサーバやCLIツール（curl、wget）が利用するSSL/TLSライブラリにフック → リクエスト/レスポンス平文、Bearerトークン、Cookie、認証コードを収集 → 外部に送出。
  • ATT&CKマッピング：T1040（Network Sniffing）、T1056/004（Credential API Hooking）、持続化にsystemd等を用いればT1543/002、隠蔽にeBPFルートキット要素を組み合わせればT1014。
  • 影響：資格情報・セッショントークンの横取り、DLP迂回、検知困難な低ノイズの情報流出。

• シナリオ2：Kubernetesノードでのサイド観測

  • 流れ（仮説）：管理権限を得た攻撃者がホスト側でuprobesを設定し、コンテナ内アプリのTLSライブラリ呼び出しを横から観測。Pod/Namespaceの境界を“ホスト側の観測”で跨ぐ。
  • ATT&CKマッピング：T1040、T1056/004、持続化はT1543/002（ノード上のサービス化）。
  • 影響：サイドカーやEnvoy経由の従来可視化を回避しつつアプリ平文へ直接アクセス。Zero Trustの東西観測の盲点化。

• シナリオ3：root化Android端末でのスパイ行為

  • 流れ（仮説）：不正アプリ/ツールがroot権限でeBPFプログラムをロードし、BoringSSL/Conscrypt等の関数にフックしてアプリのTLS平文を窃取。
  • ATT&CKマッピング：T1040、T1056/004、持続化の実装に応じてT1543相当。
  • 影響：メッセージ、決済、業務アプリのセッション・個人情報漏えい。MDM適用端末では原則root不可のため、主戦場は持ち込み端末や開発端末に集中。

全体として、この手口は「侵害後の被害半径」を拡大する加速器です。侵入防止だけでなく、侵入後の“どこまで見られるか・どう検知するか”の準備が組織の損害期待値を大きく左右します。

セキュリティ担当者のアクション

優先度順に、現場で動かせるチェックリストを提示します。

• eBPFガバナンスの基本線を固める

  • unprivileged BPFを無効化（恒久設定）し、例外を最小化します［kernel.unprivileged_bpf_disabled］。Linux kernel docs
  • perf_eventの利用を厳格化（kernel.perf_event_paranoid）し、uprobes/traceの乱用リスクを下げます［Perf security］。Linux kernel docs
  • CAP_BPF/CAP_PERFMON/CAP_SYS_ADMINの委譲方針を見直し、systemd単位・コンテナ単位での最小権限化を徹底します［capabilities(7)］。man7: capabilities(7)
  • AndroidはMDMでroot化・OEMアンロックを禁止し、違反端末のアクセスを遮断します［Android BPF/権限制御の基本理解の上で］。AOSP: eBPF architecture

• 「誰が、どのBPFを、どこに張ったか」を常時可視化する

  • bpftoolでの定期的スナップショットと差分監査（プログラム/マップ/ピン留め、アタッチ先がkprobe/tracepoint/uprobesかの把握）を日次業務に組み込みます［bpftool docs］。bpftool
  • トレース設定の監視：/sys/kernel/tracing/uprobe_eventsの変更を監査対象に入れ、異常なユーザー空間関数へのフック追加を検出します［Uprobe tracer］。Uprobe tracer
  • ランタイム監視製品の活用：Tetragon（Cilium）やTracee（Aqua）、Falco等でBPF_PROG_LOAD、perf_event_open、uprobes設定のイベントを拾い、許容リスト外のフックをアラート化します。Tetragon, Tracee, Falco

• 監査ログの強化（侵害後の“証拠”を残す）

  • bpf()やperf_event_open等に対する監査を有効化し、BPFプログラムのロードやアタッチ試行を追跡可能にします（環境標準に合わせた監査ルールでの実装を推奨します）。
  • uprobe/kprobeイベントの追加・削除操作を監査し、異常な関数名（例：SSL_read/SSL_write/gnutls_record_* など）をシグネチャとして扱います。

• Kubernetes/クラウドにおける境界の再定義

  • ワーカーノード上のBPF運用方針（CNIや可観測性エージェントが使用する正当なBPFの一覧）を明文化し、これを逸脱するBPFのロード/アタッチを即時検知します。
  • Pod Security/OPA Gatekeeper/Kyverno等でCAP_BPF/CAP_SYS_ADMINの付与を原則禁止し、seccompでbpf()・perf_event_openの呼び出しをブロックします。

• データ最小化と法令準拠

  • 平文観測は“必要最小限・最短保持・アクセス厳格化”を原則に。業務上の正当な目的・手順・保管期間・削除手順・監査の四点セットをガバナンス文書へ反映します。

• 教育と想定演習

  • SOC/IR向けに「TLSは端点支配の前では無力」という前提転換を周知し、想定演習で“平文抜き取り後の検知・封じ込め”を取り入れます。CA挿入では見えないものをどう可視化するか、eBPF監査を組み込んだ運用手順に落とし込みます。

最後に、今回の出来事は「新奇さ」「実用性」「すぐに取りうる手」がいずれも高い類の技術だと捉えます。一方で、端点での復号という性格上、万能の予防線は存在しません。だからこそ、権限の委譲設計とBPFの見える化・監査・検知という“地味だが効く”基礎を、今週のうちに前へ一歩進めておきたいところです。技術は両刃です。使う側の透明性と自制が、組織の信頼を支えます。

参考情報

• GitHub: eCapture（ehids/ecapture）: https://github.com/ehids/ecapture
• Linux kernel docs: Uprobe tracer: https://www.kernel.org/doc/html/latest/trace/uprobetracer.html
• man7: capabilities(7): https://man7.org/linux/man-pages/man7/capabilities.7.html
• Linux kernel docs: sysctl kernel（unprivileged_bpf_disabled）: https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html#unprivileged-bpf-disabled
• Linux kernel docs: Perf security（perf_event_paranoid）: https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
• MITRE ATT&CK T1040: https://attack.mitre.org/techniques/T1040/
• MITRE ATT&CK T1056/004: https://attack.mitre.org/techniques/T1056/004/
• MITRE ATT&CK T1543/002: https://attack.mitre.org/techniques/T1543/002/
• MITRE ATT&CK T1014: https://attack.mitre.org/techniques/T1014/
• bpftool: https://www.kernel.org/doc/html/latest/bpf/bpftool.html
• Tetragon: https://github.com/cilium/tetragon
• Tracee: https://github.com/aquasecurity/tracee
• Falco: https://github.com/falcosecurity/falco
• AOSP: eBPF architecture: https://source.android.com/docs/core/architecture/kernel/bpf
• KitPloit: eCapture記事: https://kitploit.com/en/posts/ecapture-e69ee0dac15e351a

（注意）本記事は公開ドキュメントに基づく技術分析であり、不正利用を助長するものではありません。運用の際は必ず適用法令・社内規程・契約上の義務を順守してください。