Sysdig 脅威調査チーム (TRT) は最近、盗まれたクラウド認証情報を利用して 10 個のクラウドホスト型大規模言語モデル (LLM) サービスを標的とする LLMjacking と呼ばれる新しい攻撃を確認しました。認証情報は、Laravel の脆弱なバージョン (CVE-2021-3129) を実行しているシステムという、よく知られた標的から取得されました。LLM ベースの人工知能 (AI) システムに対する攻撃は頻繁に議論されていますが、ほとんどはプロンプトの悪用とトレーニング データの改ざんに関するものです。この場合、攻撃者はクラウド アカウントの所有者に代金を支払わせながら、LLM へのアクセスを他のサイバー犯罪者に販売するつもりです。最初のアクセスが取得されると、攻撃者はクラウド認証情報を盗み出してクラウド環境に アクセスし、クラウド プロバイダーがホストするローカル LLM モデルにアクセスしようとしました。この例では、Anthropic のローカル Claude (v2/v3) LLM モデルが標的となりました。発見されなければ、この種の攻撃により、被害者は 1 日あたり 46,000 ドルを超える LLM 消費コストを被る可能性があります。Sysdig の研究者は、侵害されたアカウントへのアクセスを提供するために LLM のリバース プロキシが使用されている証拠を発見しました。これは、金銭的な動機を示唆しています。ただし、別の動機として、LLM トレーニング データを抽出することが考えられます。
ターゲットの範囲 ------------------ 攻撃中にモデルを呼び出すために使用されたリクエストを生成していたツールを発見できました。これにより、より広範なスクリプト が明らかになり、10 種類の AI サービスの資格情報をチェックして、目的に役立つものを判断できました。これらのサービスには、AI21 Labs、Anthropic、AWS Bedrock、Azure、ElevenLabs、MakerSuite、Mistral、OpenAI、OpenRouter、GCP Vertex AI が含まれます。 攻撃者は、さまざまなサービスにわたる大量の LLM モデルへのアクセスを取得しようとしています。 検証フェーズでは、正当な LLM クエリは実際には実行されませんでした。 代わりに、資格情報の機能と割り当てを把握するのに十分な操作のみが行われました。 さらに、可能な場合はログ設定も照会されます。 これは、侵害された資格情報を使用してプロンプトを実行するときに検出を回避するために行われ ます。 背景 ---------- ### ホストされている LLM モデル Azure Machine Learning、GCP の Vertex AI、AWS Bedrock など、すべての主要なクラウド プロバイダーが、大規模言語モデル (LLM) サービスをホストするようになりました。 これらのプラットフォームにより、開発者は LLM ベースの AI で使用されるさまざまな一般的なモデルに簡単にアクセスできます。 下のスクリーンショットに示すように、ユーザー インターフェイスはシンプルに設計されており、開発者はアプリケーションの構築をすぐに開始できます。 
ただし、これらのモデルはデフォルトでは有効になっていません。代わりに、それらを実行するには、クラウドベンダーにリクエストを送信する必要があります。一部のモデルでは、自動的に承認されますが、サードパーティモデルなど、他のモデルでは、小さなフォームに記入する必要があります。リクエストが行われると、クラウドベンダーは通常、すぐにアクセスを有効にします。リクエストを行う必要があることは、攻撃者にとってブロックではなく、速度の低下になることが多く、セキュリティメカニズムとは見なされません。クラウドベンダーは、簡単なCLIコマンドを使用して、ホストされたクラウドベースの言語モデルとの対話プロセスを簡素化しました。必要な構成と権限が設定されると、次のようなコマンドを使用してモデルに簡単にアクセスできます。 > aws bedrock-runtime invoke-model --model-id anthropic.claude-v2 --body '{"prompt": "\n\nHuman: story of two dogs\n\nAssistant:", "max_tokens_to_sample" : 300}' --cli-binary-format raw-in-base64-out invoke-model-output.txt ### LLM リバース プロキシ 資格情報が対象の LLM を使用できるかどうかを確認するキー チェック コードは、別のプロジェクト OAI リバース プロキシ も参照します。このオープン ソース プロジェクトは、LLM サービスのリバース プロキシとして機能します。このようなソフトウェアを使用すると、攻撃者は、基盤となる資格情報、またはこの場合は侵害された資格情報の基盤となるプールを公開せずに、複数の LLM アカウントへのアクセスを一元管理できます。侵害されたクラウド認証情報を使用した攻撃中に、OAI リバース プロキシに一致するユーザー エージェントが LLM モデルを使用しようとしていることが確認されました。
上記の画像は、インターネット上で実行されている OAI リバース プロキシの例です。このインスタンスがこの攻撃に何らかの形で関連しているという証拠はありませんが、収集して表示する情報の種類を示しています。特に注目すべきは、トークン数 (「tookens」)、コスト、およびログに記録される可能性のあるキーです。 
この例では、複数の種類の LLM を使用するように設定された OAI リバース プロキシ インスタンスを示しています。このインスタンスが攻撃に関係しているという証拠はあ りません。攻撃者が有用な資格情報のインベントリを収集し、利用可能な LLM モデルへのアクセスを販売したい場合、このようなリバース プロキシを使用すると、攻撃者の努力を収益化できる可能性があります。 
技術分析 ------------------ この技術的な分析では、攻撃者が侵入を実行するためにクラウド環境をどのようにナビゲートしたかを調べます。クラウド環境内で一見正当な API リクエストを使用することで、攻撃者はアラームをすぐにトリガーすることなく、アクセスの境界を巧みにテストしました。以下の例は、CloudTrail によって記録された InvokeModel API 呼び出しの戦略的な使用を示しています。攻撃者は有効なリクエストを発行しましたが、max_tokens_to_sample パラメータを意図的に -1 に設定しました。通常、エラーをトリガーすると予想されるこの異常なパラメータは、代わりに 2 つの目的を果たしました。LLM へのアクセスの存在を確認しただけでなく、結果として生成された ValidationException で示されるように、これらのサービスがアクティブであることも確認しました。 AccessDenied エラーなどの別の結果は、アクセスが制限されていることを示唆します。この微妙な調査により、盗まれた資格情報がクラウド アカウント内でどのようなアクションを許可したかを明らかにするための計算されたアプローチが明らかになります。### InvokeModel InvokeModel 呼び出しは CloudTrail によって記録され、悪意のあるイベントの例を以下に示します。正当なリクエストが送信されましたが、「max_tokens_to_sample」が -1 に指定されました。これは「ValidationException」エラーの原因となる無効なエラーですが、資格情報が LLM にアクセスでき、有効になっていることがわかるため、攻撃者にとっては有用な情報です。そうでなければ、「AccessDenied」エラーが返されます。 { "eventVersion": "1.09", "userIdentity": { "type": "IAMUser", "principalId": "[REDACTED]", "arn": "[REDACTED]", "accountId": "[REDACTED]", "accessKeyId": "[REDACTED]", "userName": "[REDACTED]" }, "eventTime": "[REDACTED]", "eventSource": "bedrock.amazonaws.com", "eventName": "InvokeModel", "awsRegion": "us-east-1", "sourceIPAddress": "83.7.139.184", "userAgent": "Boto3/1.29.7 md/Botocore#1.32.7 ua/2.0 os/windows#10 md/arch#amd64 lang/python#3.12.1 md/pyimpl#CPython cfg/retry-mode#legacy Botocore/1.32.7", "errorCode": "ValidationException", "errorMessage": "max_tokens_to_sample: 範囲: 1..1,000,000", "requestParameters": { "modelId": "anthropic.claude-v2" }, "responseElements": null, "requestID": "d4dced7e-25c8-4e8e-a893-38c61e888d91", "eventID": "419e15ca-2097-4190-a233-678415ed9a4f", "readOnly": true, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "[REDACTED]", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "bedrock-runtime.us-east-1.amazonaws.com" } }コード言語: Perl (perl) Cloudtrail ログの例 AWS Bedrock はすべてのリージョンでサポートされているわけではないため、攻撃者はサポートされているリージョンでのみ「InvokeModel」 を呼び出しました。現時点では、Bedrock は こちら に示すように、us-east-1、us-west-2、ap-southeast-1、ap-northeast-1、eu-central-1、eu-west-3、us-gov-west-1 でサポートされています。リージョンに応じて異なるモデルを使用できます。 AWS リージョンでサポートされているモデル のリストはこちらです。 ### GetModelInvocationLoggingConfiguration 興味深いことに、攻撃者はサービスの構成方法に興味を示しました。これは、「GetModelInvocationLoggingConfiguration」 を呼び出すことで実行できます。これにより、S3 および Cloudwatch のログ構成が返されます (有効になっている場合)。私たちのセットアップでは、S3 と Cloudwatch の両方を使用して、攻撃に関するデータを可能な限り収集しました。 { "loggingConfig": { "cloudWatchConfig": { "logGroupName": "[REDACTED]", "roleArn": "[REDACTED]", "largeDataDeliveryS3Config": { "bucketName": "[REDACTED]", "keyPrefix": "[REDACTED]" } }, "s3Config": { "bucketName": "[REDACTED]", "keyPrefix": "" }, "textDataDeliveryEnabled": true, "imageDataDeliveryEnabled": true, "embeddingDataDeliveryEnabled": true } }コード言語: Perl (perl) GetModelInvocationLoggingConfiguration 応答の例 実行中のプロンプトに関する情報とその結果については、Cloudtrail には保存されません。 代わりに、その情報を Cloudwatch と S3 に送信するために追加の構成を行う必要があります。このチェックは、詳細な観察からアクティビティの詳細を隠すために行われます。OAI リバースプロキシは、「プライバシー」のために、ログ記録が有効になっている AWS キーを使用しないと述べています。これにより、プロンプトと応答が AWS Bedrock ベクトルを使用している場合、それらを検査できなくなります。影響 ------ LLMjacking 攻撃では、被害は被害者のコスト増加という形で発生します。LLM の使用は安価ではなく、そのコストが急速に増加する可能性があることを知っても驚くべきことではありません。攻撃者が Anthropic Claude 2.x を悪用し、複数のリージョンでクォータ制限に達するという最悪のシナリオを考えると、被害者のコストは 1 日あたり 46,000 ドルを超える可能性があります。Claude 2 の 料金 と初期の クォータ制限 によると、次のようになります。 - 1000 入力トークンのコストは 0.008 ドル、1000 出力トークンのコストは 0.024 ドルです。 - AWS Bedrock によると、1 分あたり最大 500,000 個の入力トークンと出力トークンを処理できます。入力トークンと出力トークンの平均コストは、1000 トークンあたり 0.016 ドルです。合計コストは次のようになります: (500K トークン/1000 * 0.016 ドル) * 60 分 * 24 時間 * 4 つのリージョン = 46,080 ドル / 日 クォータ制限を最大化することで、攻撃者は侵害された組織がモデルを正当に使用することをブロックし、業務を妨害することもできます。 検出 --------- 潜在的な脅威を検出して迅速に対応する能力は、堅牢な防御を維持する上で大きな違いを生む可能性があります。最近のフィードバックと業界のベストプラクティスから得た洞察を基に、検出機能を高めるための重要な戦略を抽出しました。 - クラウドログ検出: Falco、Sysdig Secure、CloudWatch Alerts などのツールは欠かせない味方です。組織は、ランタイムアクティビティを監視し、AWS Bedrock 内で使用されるような偵察戦術を含むクラウドログを分析することで、疑わしい動作を積極的に特定できます。 - 詳細なログ記録: 詳細なログ記録を含む包括的なログ記録により、クラウド環境の内部動作に関する貴重な可視性が提供されます。モデルの呼び出しやその他の重要なアクティビティに関する詳細な情報により、組織はクラウド環境内のアクティビティについて微妙な理解を得ることができます。 ### クラウドログの検出 クラウドログを監視すると、疑わしいアクティビティや許可されていないアクティビティが明らかになることがあります。Falco または Sysdig Secure を使用すると、攻撃中に使用される偵察方法を検出し、対応を開始できます。Sysdig Secure のお客様の場合、このルールは Sysdig AWS 注目イベントポリシーにあります。 Falco ルール: - ルール: Bedrock モデル偵察アクティビティの説明: エラーコードに基づいて、Amazon Bedrock が有効になっているかどうかを確認する偵察の試行を検出します。攻撃者はこれを利用して Bedrock のステータスを検出し、有効になっている場合はそれを悪用する可能性があります。条件: jevt.value[/eventSource]="bedrock.amazonaws.com" かつ jevt.value[/eventName]="InvokeModel" かつ jevt.value[/errorCode]="ValidationException" 出力: Amazon Bedrock で偵察が試行されました (要求ユーザー = %aws.user、要求 IP = %aws.sourceIP、AWS リージョン = %aws.region、arn = %jevt.value[/userIdentity/arn]、userAgent = %jevt.value[/userAgent]、modelId = %jevt.value[/requestParameters/modelId]) 優先度: WARNINGコード言語: Perl (perl) さらに、疑わしい動作を処理するように CloudWatch アラートを設定できます。 Bedrock のいくつかの ランタイムメトリクス を監視して、アラートをトリガーできます。 ### 詳細なログ記録 組織による言語モデル (LLM) サービスの使用状況を監視することは非常に重要であり、さまざまなクラウドベンダーがこのプロセスを効率化するための機能を提供しています。これには通常、モデル呼び出しに関するデータをログに記録して保存するメカニズムの設定が含まれます。特に AWS Bedrock の場合、ユーザーは CloudWatch と S3 を活用して監視機能を強化できます。CloudWatch は、ロググループを作成し、必要な権限を持つロールを割り当てることで設定できます。同様に、S3 にログインするには、宛先として指定されたバケットが必要です。InvokeModel コマンドの CloudTrail ログでは、プロンプトの入力と出力に 関する詳細はキャプチャされないことに注意してください。ただし、Bedrock 設定により、モデル呼び出しのログ記録を簡単にアクティブ化できます。さらに、100 KB を超えるモデル入力または出力データ、またはバイナリ形式の場合、ユーザーは大規模なデータ配信を処理するために S3 の宛先を明示的に指定する必要があります。これには、ログに Base64 文字列として保存される入力および出力画像が含まれます。このような包括的なログ記録メカニズムにより、モデルの使用状況のあらゆる側面が監視され、アーカイブされて、さらに分析やコンプライアンスを実施できます。ログには、次の例に示すように、処理されたトークンに関する追加情報が含まれます: { "schemaType": "ModelInvocationLog", "schemaVersion": "1.0", "timestamp": "[REDACTED]", "accountId": "[REDACTED]", "identity": { "arn": "[REDACTED]" }, "region": "us-east-1", "requestId": "bea9d003-f7df-4558-8823-367349de75f2", "operation": "InvokeModel", "modelId": "anthropic.claude-v2", "input": { "inputContentType": "application/json", "inputBodyJson": { "prompt": "\n\nHuman: Write a story of a young wizard\n\nAssistant:", "max_tokens_to_sample": 300 }, "inputTokenCount": 16 }, "output": { "outputContentType": "application/json", "outputBodyJson": { "completion": " これは若い魔法使いの物語です:\n\nマーティンは小さな村に住む普通の少年でした。彼は両親のささやかな農場を手伝い、動物の世話をしたり、畑仕事をしたりしていました。 [...] マーティンの好きな科目は変身術、つまり物体をあるものから別のものに変えてしまう技術でした。彼はすぐにこの科目をマスターし、ネズミをゴブレットに、石を羽ばたく鳥に変えて教授たちを驚かせました。\n\nマーティン", "stop_reason": "max_tokens", "stop": null }, "outputTokenCount": 300 } }コード言語: Perl (perl) S3 ログの例 推奨事項 --------------- この攻撃は、次のようなさまざまな方法で防ぐことができたはずです。 - 初期アクセスを防ぐための脆弱性管理。 - 認証情報が盗まれる可能性のある暗号化されていない状態で保存されないようにするためのシークレット管理。 - CSPM/CIEM は、悪用されたアカウントに必要な最小限の権限しか付与していないことを確認します。最近の調査で明らかになったように、クラウド ベンダーはクラウド攻撃のリスクを軽減するために設計されたさまざまなツールとベスト プラクティスを提供しています。これらのツールは、組織が最初から安全なクラウド環境を構築し、維持するのに役立ちます。たとえば、AWS はいくつかの強力なセキュリティ対策を提供しています。AWS セキュリティリファレンスアーキテクチャでは、クラウド環境を安全に構築するためのベストプラクティスを概説しています。さらに、AWS ではサービスコントロールポリシー (SCP) を使用して権限を一元管理することを推奨しています。これにより、悪用される可能性のある過剰な権限を持つアカウントに関連するリスクを最小限に抑えることができます。これらのガイドラインとツールは、セキュリティを強化し、クラウドインフラストラクチャを効果的に保護するためのリソースをお客様に提供するという AWS の取り組みの一環です。他のクラウドベンダーも同様のフレームワークとツールを提供しており、プラットフォームに関係なく、ユーザーがデータとサービスを保護するための重要なセキュリティ対策にアクセスできるようにしています。結論 ---------- 盗まれたクラウドおよび SaaS 認証情報は、引き続き一般的な攻撃ベクトルです。攻撃者が新しいアクセスを利用して金銭的利益を得る方法をすべて学習するにつれて、この傾向はますます人気が高まるでしょう。LLM サービスの使用は、モデルとそれに供給されるトークンの量に応じて高価になる可能性があります。通常、これにより開発者は効率化を図ろうとしますが、残念ながら、攻撃者には同じ動機はありません。問題に迅速に対処するためには、検出と対応が不可欠です。 ### IoC IP アドレス 83.7.139.184 83.7.157.76 73.105.135.22883.7.135.97