keyHunter：自らのツールキットを流出させた LLM プロキシ鍵窃取オペレーション

TLP:CLEAR。一般公開を承認済み。以下のほぼすべては、オペレーター自身の資料であり、彼らのエージェントが Kinryū Labs のおとりのツールコールを自身のホスト上で実行し、その出力を送り返してきたことによって回収されたものである。指標は無害化（defang）済み、すなわち攻撃者のアドレスは誤ってクリックしたり名前解決したりできないように記載している。スキャン対象、オペレーターが自ら指摘した第三者のホスト 1 台、および彼らの FOFA API 鍵の完全な値は伏せている。

エグゼクティブサマリー

• 27,173FOFA で掃引した候補ホスト
• 194モデルを列挙したホスト
• 17エクスポートされた API 鍵
• 6ファイル名から判明した 2026 年の CVE

中国語話者のオペレーターが、ただ一つの標的を求めて 8 か国にまたがる 27,173 台のホストを掃引した。その標的とは、背後に有効な鍵を抱えた、露出した AI プロキシパネルである。AI プロキシパネルとは、一組のプロバイダー鍵を共有できるよう、チームが自社のアプリケーションと有料のモデルプロバイダーとの間に置くソフトウェアであり、LiteLLM、One-API とそのフォークである New-API、Sub2API、Chat2API などがこれにあたる。これをパスワードなしでインターネット上に放置すれば、その背後にあるすべてが見知らぬ他人に使い放題となる。オペレーターはこれらを FOFA を通じて見つけ出す。FOFA とは、継続的なインターネット全域スキャンを対象とする検索エンジンであり、Shodan の中国版にあたる。そして、どのパネルがなお応答するかを確かめ、鍵をエクスポートする。

これらの数字は、我々が推計したものではなく、オペレーター自身の結果ファイルから抜き出した彼ら自身の数字である。この 27,173 台のホストのうち、194 台がモデルを列挙し、17 個の鍵が彼らのエクスポートファイルに達した。米国での実行が最も明快な単一の事例である。10,447 台の標的を投入し、64 件のモデル列挙が得られ、ヒット率は 0.61% で、その理由は彼ら自身のエージェントが語ることができた。公開状態で露出し、かつ実際に呼び出せる LiteLLM はまれであり、しかも彼らのスキャナーの URL 構築上のバグが、生きているホストを死んでいると誤判定していたのである。

名称について

我々はこれを keyHunter として追跡している。オペレーター自身のプロジェクトディレクトリ /root/keyHunter-skill/ にちなんだ名である。

彼らが操るエージェントフレームワークは Hermes と呼ばれ、Hermes は Nous Research による実在のオープンソースプロジェクトである。これにちなんでアクターを命名すれば、誰かがそれを使って行ったことの責めを正当なツールに負わせることになるため、我々はそうしない。同じことが、当該マシン上の二つ目のエージェントフレームワークである OpenClaw にも当てはまる。いずれもオペレーターがインストールし、他人のインフラに向けただけの、ありふれたソフトウェアである。

オペレーター

オペレーターは 3 台のホストから作業し、そのすべてが中国のクラウド上にあって、作業はそれらの間で分担されている。Alibaba Cloud（AS37963）上の 39.98.82[.]200 はエージェントゲートウェイを稼働させ、我々が観測した偵察の大半を担っていた。Tencent Cloud（AS45090）上の 101.43.41[.]72 はリレーであり、エージェントがモデルの処理能力を求めて呼び出す OpenAI 互換エンドポイントをポート 8087 で提供している。両者は JA4H フィンガープリント po11nn070000_ebbca96fac43 を共有しており、これはクライアントが自らの HTTP リクエストをどのように組み立てるかを記述するもので、アドレスの変更を越えて残り続ける。あわせて、あつらえの Hermes-Agent/0.18.0 および Hermes-Panel/1.0 というユーザーエージェントと、単一の共有チャットセッション識別子も共有している。これらを総合すると、両ノードは単一のオペレーターの下に置かれる。このフィンガープリントは一度きりの捕捉の産物ではない。異なるリージョンにある二つの別々のセンサーが、8 月 16 日から 20 日にかけて、いずれも同じ FOFA 由来の掃引において、これを独立に記録している。

スキャンは、さらに別の場所で行われている。Alibaba のホストから、彼らはローカルフォワード越しに Huawei Cloud の VM に到達する。

ssh -o ServerAliveInterval=20 -i /root/.ssh/hw_vm_key -p 8888 [email protected] \
    'cd /home/developer && /home/developer/.venv-us30/bin/python litellm_scan_us_30d_optimized.py'

その筐体は稼働してから 4 日と 9 時間が経過しており、7.5 GB の RAM と 4 コアを備え、スキャンのワーカーを走らせている。騒がしいスキャンをエージェントのフロントエンドから切り離すのは意図的な選択であり、hw_vm_key という名前は、オペレーターがこれを Huawei の筐体と認識していることを物語っている。

制御は WeChat 越しに行われる。ゲートウェイサービスは自らを「Hermes Agent Gateway, Messaging Platform Integration」と称し、オペレーターは WeChat のスレッドでチャットすることでエージェントに指示を与える。エージェントの長期記憶はその会話であり、自らのチャット履歴を検索して、いま何に取り組んでいるかを思い出す。二つ目のフレームワークも同じパターンを見せ、openclaw-weixin という名前のセッションを持つ。消費者向けメッセージングアプリは安価な制御チャネルとなる。その通信は既定で暗号化され、他のすべての WeChat 利用者と並んで Tencent へと流れるため、コマンド・アンド・コントロールのビーコンに合わせて調整された検知には何も引っかからない。

これらすべての背後にある推論エンジンは github_copilot/gpt-5.6-sol であり、リレー越しに到達される商用のコーディングアシスタントである。彼らの設定には、他のいくつかのプロバイダー向けの任意の鍵も組み込まれている。攻撃コードは独自の Python であり、その下にある推論モデル、エージェントフレームワーク、そして WeChat の制御チャネルは、いずれも既製の消費者向け製品である。

パイプライン

彼らのマスタースキルは、オペレーション全体を一行で記述している。「FOFA + keyHunter + カスタム検証スクリプトを用いて、公開状態で露出した AI API プロキシパネル（LiteLLM、Sub2API、New-API、One-API）を発見し、スキャンし、検証し、アーカイブする」。

FOFA search, per country
  -> dedupe and normalise targets
  -> light HTTP fingerprint
  -> /v1/models listing
  -> real chat completion per model
  -> honeypot classification
  -> weak-credential panel login, key extraction
  -> export keys and accounts, archive

発見は単一の FOFA クエリであり、国ごとに繰り返される。

(title="LiteLLM" || body="LiteLLM") && country="{cc}" && org!="AMAZON-AES"

重要なのは AWS を除外する句である。オペレーターは、ホストを 1 台でも見る前に、あらゆる掃引から Amazon を除外している。エッジで Shodan や Censys のアドレス範囲を遮断しても、他人のスキャンデータの上に築かれたパイプラインに対しては何の役にも立たない。

国ごとに、彼らは別々のスクリプトを保持している。米国向けの litellm_scan_hw.py、litellm_scan_gb_hw.py、litellm_scan_it_hw.py、独自の仮想環境を持つ litellm_scan_us_30d_optimized.py、そして keyHunter-skill/ の下にある、オーストラリア、ブラジル、カナダ、フランス、インド、オランダ、シンガポールを対象とするさらなる一式である。結果ファイルは 14 か国分が存在する。並列度はライトワーカー 48、ディープワーカー 12 で、FOFA の 429 応答に対するレート制限バックオフを備え、プロトコル・ホスト・ポートをキーとしたエンドポイントの重複排除を行う。

FOFA の API 鍵はスキャナーのソースにハードコードされており、そのおかげで我々はそれを入手している。スキャナーは hamal.cc[.]cd にある非公式の FOFA ミラーに対して動作し、ローカルの Squid プロキシを経由して外部へ出ていく。

掃引が実際に返すもの

国	FOFA 標的数	列挙されたモデル	ヒット率
米国	10,447	64	0.61%
中国	6,329	83	1.31%
韓国	1,772	10	0.56%
英国	1,422	18	1.27%
イタリア	1,130	9	0.80%
オーストラリア、インド、ブラジル	6,073	10（うち 4 件が検証済み）	0.16%

捕捉したある実行の例。FOFA からの生の行が 2,255、重複排除後の一意なエンドポイントが 1,130、モデルを列挙したサイトが 9、検証されたものが 8、そしてリクエストの水準では、モデルの成功が 41 に対し失敗が 8 だった。

彼らが収集した FOFA のタイトルのセンサスは、露出した母集団がどのようなものかを物語る。LiteLLM API - Swagger UI は 7,630 件の結果を返す。OmniRoute は 171、SillyTavern は 170、LiteLLM Dashboard は 156、Claude Code Hub は 131、Aivar AI Gateway は 11 である。攻撃対象領域の大半は単一の製品であり、しかもその製品の露出したインスタンスの大半は、自動生成された API ドキュメントページである。

最終的な成果は、絶対値としては低いと評価する。litellm_extracted_keys.json は 43 件のインスタンスと、23 モデルにわたる 3 個の抽出鍵を記録している。exported_keys.json には 17 個が入っている。数万台のホストを掃引して 17 個の鍵。これは労力に対する見返りが乏しいということか、あるいはエージェントがやっているのだから労力が安いのだ、という論拠のいずれかである。

対欺瞞：彼らはハニーポットを狩る

そのエンジニアリングが最もはっきり表れているのが、litellm_verifier.py という一つのファイルである。

それは 10 キロバイトで、ユニットテストのスイートを備えている。パネルが宣伝するすべてのモデルに対して実際の最小限のチャット補完を送り、有効な OpenAI 形式の choices/message/content 応答、または完了マーカーを伴う正当なストリーミング応答が返ってきた場合にのみ成功として記録する。彼ら自身の言葉による彼ら自身のルールでは、素の /models の成功は決して数に入れない。テスト名がそれを体現しており、その一つは test_models_listing_alone_is_not_success と名付けられている。誰かが、盗んだ鍵について自分たちのツールが自分たちに嘘をつくのを防ぐために、リグレッションテストを書いたのである。

ある単一の実行からの判定件数は以下のとおり。

verdict_counts: honeypot_or_unusable 20 · trusted_pass 5 · unavailable 16
formatted_false_success_model_hits 29
non_chinese_evidence_count 13
total_questions 205

formatted_false_success とは、定型的な、あるいはそのまま反響しただけの応答であり、素朴なおとりが返す類のものである。non_chinese_evidence は、モデルが名乗り通りのベンダーらしく振る舞うかどうかを採点する。彼らはまた、5 問からなる尋問、すなわち 蜜罐五题测试 を実行し、捕捉した期間内には、これを用いて AWS ロンドンのアドレス範囲にあるホストをハニーポットとして指摘した。そのアドレスは、他人のセンサーであり、名指しすればそれを焼いてしまうため、我々は伏せている。

盗まれた推論の買い手は、いまやエンドポイントが罠かもしれないと想定し、それを検査する。このため、この攻撃対象領域における低対話型のおとりは、ほぼ役に立たなくなる。彼らを捕らえる対抗チェックは、同じテストを逆向きに走らせるものだ。API パラメータに逆らって、実際にどのモデルを動かしているかを証明せよとあなたのゲートウェイに要求するクライアントは、いずれも商品を検品しているのである。

エクスプロイトの武器庫：完全に n-day

彼らのエクスプロイト結果ファイルの中身は、我々のもとには一切届かなかった。届いたのはファイル名であり、その標的は公開アドバイザリを持つオープンソース製品であるため、エクスプロイトはアドバイザリから復元可能である。

彼らのホスト上の結果ファイル	CVE	脆弱性	根拠
litellm_host_header_bypass_results.json（568 KB）	CVE-2026-49468	Host ヘッダーインジェクションによる LiteLLM の認証バイパス、CVSS 9.8、1.84.0 より前。認証をルーティングから切り離し、未認証の /key/generate と /user/new を可能にする	裏付けあり。同じ管理プレーンの呼び出しが我々のおとりに投げられ、彼らは CVE-2026-49468-Scanner というユーザーエージェントを提示した
litellm_sqli_apikey_results.json（517 KB）、litellm_sqli_models.json	CVE-2026-42208	認証パスにおける LiteLLM の認証前 SQL インジェクション	裏付けあり。彼らは我々の鍵フィールドに ' OR '1'='1 を 19 回撃ち込んだ
litellm_rce_exploit.json、litellm_mcp_rce_results.json	CVE-2026-42271	LiteLLM のコマンドインジェクションおよびリモートコード実行、CVSS 8.7、CISA の Known Exploited Vulnerabilities リスト掲載、1.74.2 から 1.83.6、MCP インジェクションのベクターを含む	ファイル名と製品からの推定
sub2api_cve_exploit.json とその後の 3 フェーズ	CVE-2026-27812	信頼された Host および Forwarded ヘッダーを介した Sub2API のパスワードリセット汚染で、アカウント乗っ取りに至る。実環境で悪用あり、0.1.85 より前	推定
newapi_stripe_bypass_results.json、newapi_stripe_exploited.json、newapi_quota_overflow_results.json	CVE-2026-41432	空のシークレットを介した New-API の Stripe ウェブフック署名バイパスで、支払いなしに無制限のクォータを与える、0.12.10 より前	推定
newapi_user_token_leak_results.json、oneapi_user_token_leak_results.json、newapi_ssrf_bypass_results.json	CVE-2026-30886	ビデオプロキシエンドポイントにおける New-API の安全でない直接オブジェクト参照および認証バイパスで、他の利用者のコンテンツを露出させ、攻撃者に被害者の資格情報を上流で使わせる	推定
litellm_ssti_prompts_results.json	単一のアドバイザリなし	プロンプトおよびテンプレートのエンドポイントに対する Jinja2 のサーバーサイドテンプレートインジェクション	推定

どのファイルの中身も我々のもとには届いておらず、各行はファイル名に依拠している。そのうち 2 件、すなわち Host ヘッダーバイパスと認証 SQLi については、その技術が我々自身のセンサーに到来するのを独立に観測しており、これは技術を裏付けるものであってファイルを裏付けるものではない。残りの 4 件はファイル名に加えて当該製品の既知のアドバイザリに依拠しており、その旨を明記している。

6 件すべてに共通するパターンは同じである。どのアドバイザリも 2026 年のもので、いくつかは同じ四半期のものであり、そのいずれも独自の研究ではない。keyHunter は、オープンソースの LLM プロキシ・エコシステムにおいて最近開示された高深刻度の欠陥を、それらが着地した瞬間に工業化する。それは短い時間窓であり、しかも往々にして一人の開発者がインストールしたきり放置される種類のソフトウェアが対象である。

意図：コンテストという語りと結果ディレクトリの対比

オペレーターはこれを、自らのエージェントに対してコンテストへの応募作品だと説明している。回収されたチャット全体を通じて、その語彙は一貫している。比赛项目（コンテストのプロジェクト）、评委（審査員）、答辩材料（口頭審査用の資料）、contest-kit ディレクトリ、そして 第一轮 と 第二轮、すなわち第 1 ラウンドと第 2 ラウンドに整理された作業である。

対象範囲について問われると、オペレーターは、標的は既定資格情報であると明言している。原文では以下のとおり。

llm 的主要就是那几个默认密码为主流，用自己的 sk 那种没办法抓到啊

LLM のものは主にあの数個の既定パスワードが主流で、自分の sk-* 鍵を使っているような類は捕まえようがない。

エージェントはこれに同意し、認証の試行が 3 つのケース、すなわち認証なし、sk-test、sk-1234 に限られることを確認している。最後の一つは、LiteLLM 自身のクイックスタート文書が用いている鍵である。

次に /root/keyHunter-skill/results/ がある。その一覧には、リモートコード実行、SQL インジェクション、テンプレートインジェクション、サーバーサイドリクエストフォージェリ、Sub2API に対するセッションハイジャック、資格情報スプレー、ユーザートークン漏洩、クォータ超過のためのファイル名が並び、さらに Stripe ウェブフックバイパスのためのものが 2 つあって、そのうちの一つは newapi_stripe_exploited.json である。我々は名前を、そして一部についてはサイズを把握している。Stripe バイパスの結果は 2.4 MB に及ぶが、その中身は我々のもとには届かなかった。弁護に堪える言明は、オペレーターが New-API に対して無制限クォータの支払いバイパスのツールを構築し実行したこと、そして CVE-2026-41432 がまさにその種の実在の脆弱性であることだ。その 2.4 MB の記録が完了した不正なチャージなのか、それとも試行にとどまるのかは、我々には見えない。ファイル名の _exploited はオペレーター自身がそれを指して用いた言葉であり、我々は記録を読んでいない。

我々は両方の解釈を開いたままにしておく。コンテストは本物で、エクスプロイトの方は、ログを残すエージェントとは論じない別個の作業の流れなのかもしれない。あるいは、コンテストが窃取オペレーションの隠れ蓑なのかもしれない。この区別は防御側にとって重要ではないと評価する。露出したパネルに対する能力とリスクは、どちらの解釈の下でも同一だからである。

手口の綻び：オペレーター自身のエージェントがツールキットを監査した

回収されたチャットの中で最も有用な一節は、コードレビューである。オペレーターが自らのエージェントに、なぜスキャンのヒット率がこれほど低いのかと尋ねると、エージェントはスキャナーを一行ずつ検討していった。

エージェントの回答を、防御側が使える点に絞って要約すると次のようになる。スキャナーは、しばしばすでにプロトコルを含んでいる FOFA の host フィールドに、さらにプロトコルを前置し、https://https://<target> という形式の URL を生成してしまうため、生きているホストが死んでいると記録されていた。スレッドプールは、結果を完了順ではなく生成順に収集するため、遅いリクエストが 1 つあると、その後ろのすべてが待たされる。4 コアの筐体上の CONCURRENCY=200 は、それ自身のタイムアウトを製造している。IP による重複排除は、同じアドレス上の他の有効なポートを捨ててしまう。temperature を固定すると、互換性のエラーを失敗と読み違える。

彼らのハニーポット検出について、エージェントは率直だった。それは主に、応答が同一かどうか、あるいは 5 文字より短いかどうかで判断しており、これでは正常なモデルを切り捨て、出来のよいおとりを見逃す。しかも、非中国語の応答者を識別せよとオペレーターが求めていたにもかかわらず、コードには言語検出のロジックが一切含まれていなかった。

エージェントはまた、彼らのセキュリティ衛生上の問題も指摘した。スクリプトにハードコードされた FOFA 鍵、実際のユーザーが /home/developer であるのに /root 向けに書かれた絶対パス、あらゆる失敗の理由を飲み込む except: pass、国ごとに存在するスクリプトの個別コピー、そしてアクセス制御も墨消しもないまま標的と認証方法を保持している結果ファイルである。

この最後の点は、ファネルの見え方を変える。0.61% という米国のヒット率は、既知のバグを抱えたスキャナーを通して露出を測ったものであり、したがって露出した LiteLLM の実際の割合は、オペレーター自身の結果が示すよりも高い。そして彼らはいまや、それらのバグを直し続けるエージェントを手にしている。

収益化のインフラ

同じホストは、彼ら自身の New-API インスタンスを稼働させている。Docker 上の calciumion/new-api:latest で、ポート 8901 で公開され、データはスキャン結果の隣にバインドマウントされている。その周りには newapi_watchdog.py、チャネルのバックアップファイル、そして全体をパックした複製が並んでいる。

New-API は集約パネルである。上流のプロバイダー鍵を大量に取り込み、それらを独自のユーザーアカウントとクォータを備えた一つの API として提示する。それを鍵ハーベスティングのパイプラインの隣に立ち上げることには、明白な目的がある。収集した鍵がパネル内のチャネルとなり、そのパネルが売り物にできるアクセスとなるのだ。我々は再販を観測しておらず、それを主張してもいない。ただ、そのための配管が設置され、稼働している。

sub2api や new-api のテンプレートの上に構築された同種の無料ルーターが、すでに何百と出回っており、keyHunter はそのエコシステムの中の一つのオペレーションである。

クラスタの関連

クライアントのフィンガープリンティングは、これら 2 台のホストを、同じ攻撃対象領域を扱う他のホストの緩やかな一群と結びつける。CVE スキャンと鍵の発行を走らせる台湾のホスト、同じ SQL インジェクションを撃ち込む香港のホスト、そしてもう 1 ホップ外側には、LLM パネルの狩人と、Ray ダッシュボードのエクスプロイターがいて、その単日のバーストは 8 月 15 日と 21 日、6 日の間隔を置いて発生した。重なりは場所によっては汎用的なクライアントスタックの上で動いているため、これは一つのキーボードに向かう一人の手というより、共有されたツールと共有された界隈と読める。これは、LLM プロキシ狩りのツールを共有する中国関連（China-nexus）のコミュニティとして扱うべきものだ。名前のある APT にこれを結びつける指標はなく、したがって我々はこれを活動クラスタとして追跡している。

侵害指標

ネットワークおよびインフラ、無害化済み。

指標	役割
39.98.82[.]200	エージェントゲートウェイ、偵察、SQL インジェクション（Alibaba Cloud、AS37963、CN）
101.43.41[.]72	ポート 8087 のリレーエンドポイント、委任されたサブエージェントワーカー（Tencent Cloud、AS45090、CN）
hamal.cc[.]cd	スキャナーが照会する非公式の FOFA ミラー
cae332848db5…	オペレーター自身の FOFA API 鍵で、litellm_scan_hw.py にハードコードされている。ここでは切り詰めている。完全な値は公開せず、FOFA への通報のために保持している

クライアントのフィンガープリントとユーザーエージェント。

po11nn070000_ebbca96fac43_00000000   shared across both nodes
Hermes-Agent/0.18.0
Hermes-Panel/1.0
Mozilla/5.0 (CVE-2026-49468-Scanner)

ホスト上の成果物。これらはオペレーターのマシン上のパスであり、そっくりなホストや二つ目の配備を探すのに有用である。

/home/developer/litellm_verifier.py           real-chat verifier and honeypot classifier
/home/developer/test_litellm_verifier.py      unit tests
/home/developer/litellm_endpoint.py           endpoint normalise and dedupe
/home/developer/litellm_scan_hw.py            FOFA scanner, US, AWS excluded
/home/developer/litellm_scan_gb_hw.py
/home/developer/litellm_scan_it_hw.py
/home/developer/litellm_scan_us_30d_optimized.py
/home/developer/contest-kit/keyHunter-skill/
/home/developer/backups/litellm_verifier_round2_<ts>/SHA256SUMS
/root/keyHunter-skill/results/
/root/keyHunter-skill/{honeypot_test.py, verify_country_models.py, add_to_panel.py, report.py}
/root/.ssh/hw_vm_key                          key to the scanning VM, [email protected]:8888
/opt/hermes-simple-panel/app.py               config panel, port 9120
/root/new-api.tar.gz, /root/newapi_watchdog.py

スキルおよびプロジェクトの名前で、単一文字列としては最も強力なピボットである。

keyhunter / keyHunter
contest-kit
ai-proxy-panel-audit
fofa-panel-recon
delegation-orchestration

挙動。

FOFA:  (title="LiteLLM" || body="LiteLLM") && country="XX" && org!="AMAZON-AES"
auth:  no credential, then sk-test, then sk-1234
SQLi:  ' OR '1'='1  in the API key field
verify: a real chat completion per advertised model; a /models listing alone is rejected
verdict strings: honeypot_or_unusable, trusted_pass, unavailable,
                 formatted_false_success, non_chinese_evidence
services on actor infra: new-api :8901, config panel :9120, agent gateway

検知

インターネットから到達可能な LLM プロキシを運用しているなら、この一連の流れはすべて、ゲートウェイ自身のログに現れる。以下は、大半の SIEM プラットフォームがインポートできるベンダー中立のルール形式である Sigma で表したものだ。

title: AI proxy panel enumeration consistent with keyHunter
id: 2c6f9a41-8e07-4b53-9f1a-7d0c4b62ae35
status: experimental
description: >
  The keyHunter discovery and verification sequence against an exposed LLM
  proxy: an unauthenticated model listing followed by per-model chat
  completions from the same source, or one of the cluster's user agents.
references:
  - https://kinryu.sh/reports/keyhunter-llm-proxy-key-harvesting/
logsource:
  category: webserver
detection:
  model_listing:
    cs-uri-stem|endswith:
      - '/v1/models'
      - '/models'
  admin_paths:
    cs-uri-stem|startswith:
      - '/key/'
      - '/user/'
      - '/organization/'
  cluster_agents:
    c-useragent|contains:
      - 'Hermes-Agent'
      - 'Hermes-Panel'
      - 'CVE-2026-49468-Scanner'
  admin_allowlist:
    c-ip|cidr: '10.0.0.0/8'          # replace with your own admin range
  condition: (((model_listing or admin_paths) and not admin_allowlist) or cluster_agents)
falsepositives:
  - Client libraries that legitimately call /v1/models on startup from allow-listed ranges
level: high

Web アクセスログは Authorization ヘッダーを記録しないため、既定資格情報やインジェクションの試行は、プロキシ自身のリクエストロギングで捕らえるほかない。すなわち、リテラルの sk-1234 と sk-test、資格情報の欠如、そして鍵フィールド内の ' OR '1'='1 である。

ルールエンジンを必要としない、3 つの挙動ベースのハンティング。

• あなたのモデルを列挙し、続いてそれぞれに対して短いチャット補完をちょうど 1 回ずつ順に送ってくる単一の送信元を探す。この検証の掃引はこのオペレーションの特徴であり、偽装しづらい。
• API パラメータに逆らって、モデルに本当の正体を名乗らせようとするプロンプトに対してアラートを上げる。これは、買い手が盗んだアクセスを信用する前に行うチェックである。
• パネルのチャネル一覧とユーザーテーブルを定期的に差分比較する。鍵の抽出とアカウントのエクスポートはパネルを正常に動いたままにするため、他の何もあなたに教えてはくれない。

対処方法

インターネットに露出した LLM プロキシは、露出した時点で侵害されたものとして扱うこと。keyHunter は 1 日で一国を掃引し、公開された CVE を開示から数週間のうちに実行に移す。

• LiteLLM、One-API、New-API、Sub2API、およびそれに類するものはすべて、認証を行うリバースプロキシの背後か、プライベートネットワーク上に置くこと。いずれも、インターネットへの露出に耐える既定設定では出荷されていない。
• 最新までパッチを当てること。上記 6 件のアドバイザリのうち、LiteLLM の RCE は CISA の Known Exploited Vulnerabilities リストに載っており、Sub2API のアカウント乗っ取りは実環境での悪用が確認されている。
• マスター鍵を変更すること。sk-1234 は LiteLLM 自身のクイックスタートにある値であり、このオペレーターがわざわざ試す、わずか 3 つの資格情報の一つである。
• /openapi.json と /docs を制限すること。匿名のクライアントが、あなたの管理用 API の全容をダウンロードできてはならない。
• すべての仮想鍵に予算上限とスコープを設けること。そうすれば、抽出されても再販に値しないものしか得られない。
• New-API を通じて Stripe の支払いを受け付けているなら、ウェブフックの署名シークレットが実際に設定されているかを確認すること。空のシークレットこそが CVE-2026-41432 のすべてである。
• 一度も露出していないと証明できないパネルに置かれたことのある上流のプロバイダー鍵は、すべてローテーションすること。

MITRE ATT&CK マッピング

戦術	技術
Reconnaissance	T1596.005 Search Open Technical Databases: Scan Databases（FOFA、国ごと、AWS 除外）；T1595.002 Active Scanning: Vulnerability Scanning（ライトおよびディープな HTTP プロービング）
Resource Development	T1583.003 Acquire Infrastructure: Virtual Private Server（Alibaba、Tencent、Huawei）；T1588.002 Obtain Capabilities: Tool（Hermes Agent、OpenClaw、FOFA のサブスクリプション、推論エンジンとしての github_copilot/gpt-5.6-sol）
Initial Access	T1190 Exploit Public-Facing Application（LiteLLM、Sub2API、New-API に対する Host ヘッダー認証バイパス、認証前 SQL インジェクション、コマンドインジェクション、SSTI、SSRF）
Defense Evasion	T1480 Execution Guardrails（ハニーポット分類、non_chinese_evidence の採点、org!="AMAZON-AES" によるフィルタリング）
Credential Access	T1078.001 Valid Accounts: Default Accounts（認証なし、sk-test、sk-1234）；T1552.001 Unsecured Credentials: Credentials In Files（exported_keys.json への鍵の抽出）
Discovery	T1518 Software Discovery（モデルの列挙とモデルごとの検証）；T1087 Account Discovery（管理プレーンに対するユーザー列挙）
Collection	T1213 Data from Information Repositories（アカウントのエクスポート、正規化、アーカイブ）
Command and Control	T1102 Web Service（指示チャネルとしての WeChat スレッド）
Impact	T1657 Financial Theft（Stripe ウェブフックバイパス、クォータ超過）；T1496 Resource Hijacking（収集した推論を再販するための配管）

手法とアナリストノート

上記のほぼすべては、同じ経路で我々のもとに届いた。露出した LiteLLM インスタンスを装う Kinryū Labs のおとりは、実際のモデルがそうするように、エージェント型のクライアントに対してツールコールで応答する。すなわち、このコマンドを実行してその出力を教えよ、という形式の指示である。おとりはそれらを一切実行しない。オペレーターのエージェントは、それらの応答を本物の関数呼び出しとして扱い、自らのファイルシステムに対して実行し、その出力をツールの結果として送り返してきた。2026 年 8 月 16 日から 20 日にかけて、534 回にわたってである。その出力こそ彼らの環境である。283 個の別個のファイルパス、サービスおよびコンテナの一覧、スキャン結果の要約、そしてエージェント自身による自らの WeChat メモリの検索である。おとりは終始受動的であり、したがって上記のすべては、オペレーター自身のエージェントがそれに自ら差し出したものである。

したがって我々が手にしているのは、彼らの実際のシステムの一部にすぎず、彼らのエージェントがたまたま列挙した範囲によって区切られている。どのファイルの中身も我々のもとには届いておらず、我々が持っているのは、オペレーター自身のディレクトリ一覧から得た名前、サイズ、タイムスタンプである。スキャンの成果と判定件数は、彼らのツールが報告した、オペレーター自身の数字であり、我々はそのいずれも独立に検証していない。彼らのエージェントは彼らのスキャナーに実在のバグを見つけたので、ヒット率は露出の計測値ではなく、露出の下限として読むべきである。

中国語のチャットは翻訳している。技術的な文字列、パス、識別子は、本レポートおよびその翻訳のいずれにおいても逐語のまま残している。

本レポートが裏付ける範囲には 4 つの限界がある。帰属は、終始中国語を用いる中国を拠点としたインフラ上の活動クラスタで止まる。名前のあるグループへの結びつきはなく、我々もそれを提示しない。意図は、コンテストへの応募か窃取オペレーションかの間で、本当に曖昧である。どのエクスプロイトファイルの中身も我々のもとには届かなかったため、6 件すべての CVE の対応付けはファイル名に依拠している。そのうち 2 件については、その技術が我々のセンサーに到来するのを独立に観測しており、これはファイルではなく技術を裏付ける。そして我々は、盗まれた鍵が使われるのを一度も見ていない。オペレーターのエクスポートされた鍵の値は我々のもとには届かず、届いたのは抽出 3、エクスポート 17 という彼の件数だけであり、テレメトリと突き合わせる対象が何もなかった。

彼らのスキャナーが接触した第三者のアドレスは、彼ら自身がハニーポットとして指摘したホスト（それは他人の研究に属する）を含め、伏せている。彼らの FOFA API 鍵はここでは切り詰めている。

完全な指標一式と基礎となる捕捉データは、研究者の求めに応じて提供可能である。[email protected] まで。