LLMjackingがDeepSeekを標的にする

本文の内容は、2025年2月7日に Sysdig Threat Research Team が投稿したブログ(https://sysdig.com/blog/llmjacking-targets-deepseek/)を元に日本語に翻訳・再構成した内容となっております。

Sysdig 脅威リサーチチーム (TRT) が2024 年 5 月に LLMjacking を発見して以来、私たちはこれらの攻撃に関する新たな知見と用途を観察し続けています。大規模言語モデル (LLM) は急速に進化しており、私たちはまだその最適な使用方法を学んでいるところですが、同じように、攻撃者も進化を続け、悪用するユースケースを拡大しています。最初の発見以来、DeepSeek などの新しい LLM への急速な拡大を含め、攻撃者が LLMjacking を実行する新たな動機と方法を観察してきました。

9 月に報告したように、LLM ジャッキング攻撃の頻度と人気は高まっています。この傾向を考えると、DeepSeek がメディアで話題になり、使用率が急増してから数日以内に標的になったことは驚きではありません。LLM ジャッキング攻撃は、認証情報を盗み、それを使用して生成 AI (GenAI) サービスを悪用したサイバー犯罪者を標的としたMicrosoft の訴訟など、世間の注目もかなり集めています。訴状では、被告が DALL-E を使用して不正なコンテンツを生成したと主張しています。これは、 9 月の LLM ジャッキング更新で無害なイメージ生成の例を紹介したときからエスカレートしたものです。

クラウドベースの LLM の使用コストは膨大で、毎月数十万ドルを超えることもあります。Sysdig TRT は、OpenAI、AWS、Azure など、さまざまなサービスで盗まれた認証情報を使用しているプロキシサーバーを 12 台以上発見しました。LLM のコストが高いため、サイバー犯罪者 (以下の例のような) は LLM サービスに料金を支払うのではなく、認証情報を盗むことを選択します。

Sysdig TRT によるこの LLMjacking アップデートでは、標的となる新しい戦術とモデル、プロキシのビジネス、脅威リサーチャーの最新の調査結果について説明します。

LLMjackersはすぐにDeepSeekを採用

攻撃者は最新モデルがリリースされるとすぐにそれを実装します。たとえば、2024 年 12 月 26 日に DeepSeek は高度なモデルであるDeepSeek-V3をリリースしましたが、数日後には HuggingFace でホストされているこの OpenAI リバースプロキシ (ORP) インスタンスにすでに実装されていました: https://huggingface.co/spaces/nebantemenya/joemini。

このインスタンスは、 agalq13/lollllllでアクセス可能な ORP のフォークに基づいており、DeepSeek の実装を含むコミットがプッシュされました。数週間後の 2025 年 1 月 20 日、DeepSeek はDeepSeek-R1と呼ばれる推論モデルをリリースしました。その翌日、このフォークされたリポジトリの作成者もそれを実装しました。

DeepSeek などの新しいモデルのサポートが実装されただけでなく、複数の ORP に DeepSeek API キーが設定され、ユーザーがそれらを活用し始めていることもわかりました。以下の ORP には、すでに 55 個の DeepSeek API キーがあることがわかります。

LLMjacking と OpenAI リバースプロキシ

LLMjackingにOAI Reverse Proxy（ORP）が使用されていることが元の記事で報告されており、その人気は続いています。ORPは、さまざまなプロバイダーのLLMに対するリバースプロキシサーバーとして機能します。ドキュメントによると、ORPサーバーは、ユーザーが指定したドメインを使用したNginx構成や、TryCloudflareのような自動生成された動的ドメインを通じて公開することが可能です。これらのサブドメインは、ソースIPやドメインを隠すために使用されることがあり、これはLABRATなどの他の脅威アクターでも見られた手法です。

以下のスクリーンショットは、攻撃者によって運用されているORPインスタンスを示しています。ORPは、プロキシの現在の状態に関する統計情報を提供し、利用可能なキーの数、待ち時間、および各種LLMの使用頻度などを表示します。以下の例では、OpenAI、Google AI、Mistral AIのキーが数百個使用されており、その多くは盗まれたものである可能性が高いと考えられます。

私たちは他にも多くの公開されたORPインスタンスを発見しましたが、その中でも特に注目を引いたのは、 https://vip[.]jewproxy[.]tech にホストされているものです。このプロキシへのアクセスは、カスタムストアフロント (hxxps://jewishproxy[.]sell[.]app/product/vip-token).で販売されており、30日間のアクセス用トークンは30ドルで提供されています。さらに詳細な情報は、作成者のウェブページ(hxxps://rentry[.]org/proxy4sale)に記載されています。

このプロキシは非常に広範囲に利用されており、多くのユーザーが複数のLLMを活用している可能性が高いと考えられます。残念ながら、このインスタンスは定期的に再起動されるため、ウェブページ上の統計データがリセットされてしまいます。しかし、私たちはこのインスタンスのスナップショットを取得し、大量の使用が行われていることを確認しました。以下は、そこで観測された主要な統計データです。

"uptime": 395555,

...

    "proompts": 132651,

    "tookens": "2.213b ($21868.20)",

    "proomptersNow": 18,

    "openaiKeys": 32,

    "openaiOrgs": 13,

    "google-aiKeys": 2,

    "awsKeys": 1,

    "azureKeys": 1,

    "turbo": {

      "usage": "5.87m tokens ($5.87)",

...

    "gpt4-turbo": {

      "usage": "16.02m tokens ($160.16)",

...

    "gpt4o": {

      "usage": "694.17m tokens ($3470.85)",

...

    "o1-mini": {

      "usage": "233.6k tokens ($1.17)",

...

    "o1": {

      "usage": "3.81m tokens ($76.28)",

...

    "gpt4": {

      "usage": "1.19m tokens ($35.68)",

...

    "gpt4-32k": {

      "usage": "4.84m tokens ($290.69)",

...

    "gemini-pro": {

      "usage": "15.23m tokens ($0.00)",

...

    "gemini-flash": {

      "usage": "559.6k tokens ($0.00)",

...

    "aws-claude": {

      "usage": "605.45m tokens ($4843.64)",

...

    "aws-claude-opus": {

      "usage": "865.59m tokens ($12983.87)",

...

ORP はこのコードを使用してモデルの使用コストを計算します。これらの統計は再起動のたびにリセットされ、記載されている稼働時間に対して有効です。コードの最初のコメントにあるように、すべてのトークンを入力トークンと見なすため、これらのコストは過小評価されています。入力トークンは出力トークンよりもコストが低くなります。トークンとは、大規模言語モデル (LLM) がテキストを処理するときに生成される単語、文字セット、または単語と句読点の組み合わせです。LLM は多くの場合、入力と出力の両方のトークンで使用量を測定します。

これらのコストを入力コストと出力コストの平均として計算すると、合計額はほぼ 50,000 ドル (49,595.83 ドル) に増加します。395,555 秒の「稼働時間」に基づくと、この数字は 4.5 日で達成されました。

Claude 3 Opusは最も使用されている高額なモデルであり、使用されたトークン数は865.59百万トークンに達しています。Bedrockのドキュメントに記載されているトークン単価を基に試算すると、このモデル単体でアカウント所有者に発生したコストは38,951.55ドルと推定されます。

観測可能な期間内で、すべてのORPによる総トークン使用量は20億トークンを超えていました。

では、これらのリソースの費用を支払っているのは誰でしょうか？それは、盗まれたキーに紐づくアカウントの所有者たちです。LLMjackingのシナリオでは、攻撃の被害者はクラウドアカウントを侵害されたユーザーであり、攻撃者が被害者のコンピュートリソースを利用し、高額な請求を発生させるという点で、クリプトジャッキングと類似しています。

LLMの運用には多額のコストがかかります。OpenAIのデータが示すように、これらのサービスへのアクセスは適切に保護されるべきです。これは、不正利用による経済的損失を防ぐためだけでなく、データ漏洩のリスクを軽減するためにも重要です。

LLMジャッキングの戦術、テクニック、手順

LLMjacking は、もはや単なる一時的な流行やトレンドではありません。ツールやテクニックを共有するためのコミュニティが構築されています。ORP は、LLMjacking オペレーション専用にフォークされ、カスタマイズされています。クラウド認証情報は、販売される前に LLM アクセス用にテストされています。LLMjacking オペレーションでは、独自の TTP セットを確立し始めており、以下にそのいくつかを示します。

コミュニティ

NSFW コンテンツに LLM を使用したり、ロールプレイング用の AI キャラクターを作成したりすることを中心に、多くのアクティブなコミュニティが存在します。これらのユーザーは、4chan や Discord でのコミュニケーションを好みます。彼らは、プライベートとパブリックの両方の ORP を介して LLM へのアクセスを共有します。4chan のスレッドは定期的にアーカイブされますが、ツールとサービスの概要は、リンクや関連するアクセス情報を共有するための一般的な選択肢である pastebin スタイルの Web サイト Rentry.co でよく利用できます。Rentry でホストされているサイトでは、マークダウンを使用したり、カスタム URL を提供したり、投稿後に編集したりできます。

調査中に、20 を超える ORP プロキシが見つかりました。その中には、カスタムドメインを使用しているものもあれば、 “https://examined-back-breakdown-diabetes.trycloudflare[.]com/” などのTryCloudFlare トンネルを使用しているものもありました。

クラウドハニーポット環境で LLMjacking 攻撃を調査しているときに、LLM プロンプトログに TryCloudflare ドメインがいくつか見つかりました。攻撃者は LLM を使用して ORP と対話する Python スクリプトを生成していました。これが TryCloudFlare トンネルを使用していたサーバーへの追跡の始まりでした。

認証情報の盗難

攻撃者は、Laravel などの脆弱なサービスを通じて認証情報を盗み、以下のスクリプトを検証ツールとして使用して、認証情報が ML サービスにアクセスできるかどうかを判断します。システムへのアクセスが取得され、認証情報が見つかると、攻撃者は収集したデータに対して検証スクリプトを実行します。認証情報のもう 1 つの一般的なソースは、公開されている可能性のあるパブリックリポジトリ内のソフトウェアパッケージです。

すべてのスクリプトには、多数の（盗まれた）キーをより効率的に処理するための同時実行性と、自動化を念頭に置いて構築された、いくつかの共通の属性があります。

スクリプト	ターゲット	目的
_AWSGetValid.py	AWS	AWS STS でキーを検証する
_AWSdragoChecker.py	AWS	AWS キーをグループに分類無効なキー請求アクセスIAM プロファイル更新機能さまざまな Claude モデルへのアクセス (Opus、Sonnet 3.5、Sonnet、Claude 2)アクティブな AI モデルと支出をチェック
ドラゴベターAwsライブラリ.py	AWS	Anthropicモデルをアクティブ化し、呼び出す
_AZUREdragoChecker.py	Azure	Azure OpenAIエンドポイントの可用性をテストし、コンテンツフィルタリングの状態を確認します
_OAIdragoChecker.py	OpenAI	OpenAI APIキーを検証し、モデルのアクセスレベルをチェックし、サブスクリプション層を決定し、使用制限と割り当てを追跡します

OAI リバースプロキシのカスタマイズ

この図は、盗まれた認証情報から最終的に顧客がプロキシ経由で ML サービスにアクセスするまでの全体フローを示しています。各コンポーネントステップを調べてみましょう。

KhanonによるオリジナルのOAI Reverse Proxyには、多くのフォークやカスタム構成が存在し、その中にはプライバシーやステルス機能を強調して宣伝されている改変版も含まれています。これらの機能には、アラートを発生させずに動作する機能や、ログ記録を改変する機能が含まれています。プロンプトの合法性がしばしば問題視される中、これらの改変はユーザーのプロンプトを完全に非公開にすることを目的としています。

ORP を難読化するための取り組みの例:

オペレーターはウェブサイトのスタイルを変更して難読化のレイヤーを追加できます。CSS を使用してページの読み取りを非常に困難にするプロキシが 1 つ見つかりました。適切にアクセスできるようにするには、ユーザーは CSS を無効にする必要があります。
オペレーターはプロキシを調整してパスワード認証を有効にすることで、管理するキーの数をより機密に保つことができます。さらに、ユーザーを怖がらせるために、すべての認証エラーをログに記録します。

運用セキュリティ

ORP オペレーターは、サーバーを保護するために、プロキシをデプロイするために使用する IP または VPS を隠そうとするのが一般的です。一時的なドメインを作成するために登録を必要としない TryCloudflare トンネルを使用することがよくあります。ドキュメントに示されているように、セットアップは迅速かつ簡単です。その後、4 つの単語で構成されるランダムに生成されたリンクがユーザーと共有されます。

一部のオペレーターは、アクセスを制限するために、プロキシリンク共有プロセスに難読化のレイヤーを追加します。たとえば、ORP 情報を含む一部の Rentry ページでは、Trycloudflare サブドメインを作成するために使用される 4 つの単語がランダムな場所に表示されています。この方法は、Web スクレイピングシステムから URL を隠すのに役立ちます。

結局のところ、Rentry のリンクはフォーラムやチャットルームで流通していますが、他の地下グループと同様に、詐欺が横行しています。

LLMjacking を検知して対抗するためのベストプラクティス

LLMjackingは、主に認証情報やアクセスキーの侵害によって実行されます。この攻撃は十分に一般的になったため、MITREはMITRE ATT&CKフレームワークにLLMjackingを追加し、この脅威に対する認識を高め、防御側が攻撃をマッピングできるよう支援しています。

AIサービスアカウントの侵害を防ぐには、アクセスキーの保護、強力なID管理の実施、脅威の監視、最小権限の原則の徹底が重要です。以下は、アカウント侵害を防ぐためのベストプラクティスです。

アクセスキーを保護する

アクセスキーは主要な攻撃ベクトルであるため、慎重に管理する必要があります。

認証情報をハードコーディングしないでください。APIキー、アクセスキー、認証情報をソースコード、構成ファイル、またはパブリックリポジトリ (GitHub、Bitbucket など) に埋め込まないでください。代わりに、環境変数または AWS Secrets Manager、Azure Key Vault、HashiCorp Vault などのシークレット管理ツールを使用します。

一時的な認証情報を使用します。AWS STS AssumeRole、Azure Managed Identities、Google Cloud IAM Workload Identity などの長期間有効なアクセスキーの代わりに、一時的なセキュリティ認証情報を使用します。

アクセスキーをローテーションします。定期的にアクセスキーを変更して露出を減らします。可能な場合はローテーションプロセスを自動化します。

公開された認証情報を監視します。自動スキャンを使用して、公開された認証情報を検出します。ツールの例としては、AWS IAM Access Analyzer、GitHub Secret Scanning、TruffleHog などがあります。

アカウントの動作を監視します。アカウントキーが侵害されると、通常、通常の動作から逸脱し、疑わしいアクションを実行し始めます。Sysdig Secure などのツールを使用して、クラウドおよび AI サービスアカウントを継続的に監視します。

まとめ

高度なLLMへのアクセス需要が高まるにつれ、LLMjacking攻撃はますます広まっています。高額なコストがかかるため、OAI Reverse Proxyを利用したブラックマーケットが形成され、地下サービスプロバイダーが需要に応じる形で台頭しています。LLMjackingのプロキシ運営者は、認証情報へのアクセスを拡大し、サービスをカスタマイズしながら、DeepSeekのような新しいモデルを追加し始めています。同時に、AWSやAzureも最近、Amazon BedrockやAzure AI FoundryにDeepSeekモデルを追加しました。

その一方で、正規のユーザーが主要な標的となっています。不正なアカウント利用によって、被害者は数十万ドル規模の損害を被っており、アカウントや関連するAPIキーの適切な管理が極めて重要になっています。

LLMjacking攻撃は進化を続けており、それを動機とする要因も変化しています。最終的に、攻撃者はLLMへのアクセスを狙い続け、新たな悪意ある用途を見出すでしょう。ユーザーや組織は、これらの脅威を検知し、防御する準備を整える必要があります。