LLMjacking:あなたのAWS請求で攻撃者がLLMを動かす

通常なら1日120ドルほどのサンドボックスアカウントが、わずか14時間で85,000ドルを請求される。11か月間誰も触れていなかった休眠中のメンバーアカウントが、誰かが請求書を開く前に75,000ドルを使い込まれる。欧州の小売企業のアカウントでは、月数百ドルだった費用が2日足らずで522,000ドルに跳ね上がる。

これらの攻撃者は、データを盗んだわけでもランサムウェアを仕掛けたわけでもありません。クラウドの認証情報を奪い、それを使ってAmazon Bedrock上で最も高価な大規模言語モデルを呼び出し、請求だけを被害者に残していったのです。これがLLMjackingです。2026年には、DoiTのサポートチームに寄せられるセキュリティインシデントの中で、最も件数が多く、最も高額なものの一つとなっています。

本記事では、この攻撃の仕組みと、今年のインシデントから見えてきた実態を解説します。続いて、攻撃を防ぐためのAWSの対策を順に説明します。最後に、請求書ではなくアラートで異変に気づけるよう、DoiT Cloud Intelligence™(DCI)を設定する方法を紹介します。

Part 1:LLMjackingを防ぐAWSの対策

盗む価値のある認証情報をなくす

• **長期間有効なIAMユーザーキーの発行をやめる。**人による利用にはIAM Identity Centerを使います。ワークロードには一時的な認証情報を持つIAMロールを割り当てます。GitHub ActionsにはOIDC、IRSAまたはEKS Pod Identity、そしてインスタンスプロファイルです。AWSのIAMベストプラクティスでも明確に推奨されています。
• **既存のキーを監査する。**90日間使われていないキーは削除します。無効化だけで済ませてはいけません。どのみちインシデント後にはAWSから削除を求められます。共有キーをCI変数、Helmのvalues、エージェントやMCPの認証情報ファイルに置くのは厳禁です。
• **Bedrock APIキーをシークレットとして扱う。**有効期間が最大12時間の短期キーを優先し、長期キーがある場合は棚卸しして権限を絞ります(AWS)。
• ソース管理側でシークレットスキャンとプッシュ保護を有効にする(GitHub)。AWSがユーザーにAWSCompromisedKeyQuarantineV3ポリシーをアタッチした場合は、インシデント対応を開始してください。このポリシーはキーでできることを制限しますが、攻撃者を排除するわけではありません(AWS)。

ルートを保護する

ハードウェアMFAを使用し、ルートのアクセスキーは作成せず、ルートのメールアドレスには自社が管理し、常に監視しているドメインを使います。休眠中のアカウントも含め、すべてのアカウントにSECURITYおよびOPERATIONSの代替連絡先を設定し、AWSからの警告が実際に読む人に届くようにします。

Organizationレベルでガードレールを設置する

IAMの最小権限により、各ワークロードを必要な特定のモデルとリージョンに限定すべきです(AWSポリシー例)。そのうえでサービスコントロールポリシーが、侵害されたプリンシパルには取り除けない防波堤を追加します。以下はその出発点です。まず非本番のOUでテストしてください:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyMarketplaceSubscribeExceptPlatformRole",
      "Effect": "Deny",
      "Action": "aws-marketplace:Subscribe",
      "Resource": "*",
      "Condition": {
        "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/ai-platform-admin" }
      }
    },
    {
      "Sid": "DenyBedrockOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["us-east-1", "us-west-2"] }
      }
    },
    {
      "Sid": "DenyFederationTokenConsoleBypass",
      "Effect": "Deny",
      "Action": "sts:GetFederationToken",
      "Resource": "*"
    }
  ]
}

いくつか注意点があります。クロスリージョン推論プロファイルはリクエストを他のリージョンにルーティングするため、実際に使用するプロファイルに照らしてリージョン条件を検証してください(AWS)。サンドボックス、休眠アカウント、AIプラットフォーム外のほとんどの本番アカウントなど、生成AIを一切使うべきでないアカウントもあります。そうしたアカウントには、bedrock:*を単純に拒否するほうがシンプルで安全です。

資金が流出する速度を制限する

• Bedrockの1分あたりトークン数クォータを各ワークロードに必要な水準まで引き下げ、引き上げには承認を必須にします(AWS)。クォータが制限するのは総量ではなくレートですが、時間を稼げます。
• **実験は境界を区切ったアカウント内にとどめ、**専用の予算を設定します。

ログと検知

• ロックダウンされたログアーカイブアカウントに配信される、マルチリージョンのOrganization CloudTrail証跡。
• 承認済みワークロードに対するBedrockモデル呼び出しログ(AWS)。
• すべてのアカウント・すべてのリージョンでAmazon GuardDutyを有効化し、AI関連の保護機能もオンにします。あるインシデントの後、AWSは管理アカウントだけでなく、影響を受けたメンバーアカウントでセキュリティサービスの有無を確認しました。
• 実際のインシデントで早期に現れたシグナルに対するアラート:
  • 新しいMarketplace契約
  • GetFederationTokenの呼び出し
  • 引き受けたロールによるCreateAccessKeyの呼び出し
  • ルートのサインインやMFAの変更
  • SES送信量の急増

Part 2:DoiT Cloud Intelligenceをトリップワイヤーとして設定する

DCIはGuardDutyやCloudTrailの代わりにはなりません。ここでの価値は、DCIがAWSアカウントの外側にあるコスト管理プレーンだという点にあります。あなたのAWSキーを握った攻撃者はAWS Budgetsを閲覧・編集できますし、実際にそうした例を確認しています。しかし、DCIで設定したアラートや予算には手を出せません。

アラート、予算、異常検知が支出を監視します。ComposerとSecurity Insightsは、攻撃者の侵入口となるギャップを塞ぎます。CloudFlowは、それらのいずれかを通知、チケット、承認済みの封じ込め手順に変換します。

1. ベースライン不要のしきい値アラート

アラートは固定ルールで発火するため、初日から、一度も使ったことのないモデルに対しても機能します。LLMjackingに対して最も頼りになるDCIの制御手段です。

• **すべてのAIモデル支出をまとめるアロケーションを作成する:*Amazon Bedrockに加えて*「(Amazon Bedrock Edition)」のMarketplace製品も含めます。新しいモデルは自動的にここに含まれるため、来月のモデルリリースをアラートが静かに見逃すことがなくなります。
• **アカウントごとの日次支出アラート:**このアロケーションにスコープを絞り、Metricを「Cost」、Intervalを「Daily」に設定します。条件はis > $Xとし、Xは通常日の2〜3倍にします。Evaluate for each: Accountをオンにすれば、1つのルールですべてのアカウントをカバーできます。
• **「ゼロであるべき」アラート:**サンドボックス、休眠アカウント、AIワークロードを実行していないアカウントには、1日> $10でアラートを設定します。
• 前日比の急増:percentage change is > 100%。
• **予測アラート:**月次で、is forecasted to be >に計画しているAI支出を設定します。

アラートはメールと、誰かが実際に見ているSlackチャンネルの両方に送りましょう(Slackへのアラート配信)。

2. すべてのアカウント、特に動きのないアカウントに予算を

各AWSアカウントに、50%、85%、100%のしきい値を持つ月次の定期予算を設定します。予算の提案機能を使えば、適切な金額を見積もってくれます。ひと目で把握できる2つ目のトリップワイヤーとして、AIアロケーションに日次予算を追加します。休眠アカウントとサンドボックスアカウントが攻撃者に好まれるのは、まさに誰も予算を設定していないからです。0ドルのアカウントに50ドルの予算を設定すれば、非常に優秀な警報になります。

予算は支出そのものを止めはしませんが、侵害されたアカウントの外側からそれを知らせてくれます。

3. 異常検知を、確実に届くようにチューニングする

コスト異常検知は、特に攻撃に伴うEC2、GPU、SageMakerの不正利用に対しては、依然として有効です。重要な設定は3つです:

• **重大度フィルターを広げる。*メール通知のデフォルトはCritical*のみです。「Warning and above」または「All severity levels」に設定しましょう(通知設定)。
• **再通知を有効にする。**拡大し続けるアクティブな異常について、再度通知が届くようになります。
• **受信者が設定されていることを確認する。**複数のインシデントで、DCIは異常を検知していたのに誰にも伝わっていませんでした。通知先が設定されていなかったのです。

EnhancedおよびEnterpriseプランでは、AWS向けリアルタイム異常検知を有効にしてください。CloudTrailをもとに動作し、およそ1時間以内に通知します。現時点でカバーするのはBedrockではなくEC2とRDSですが、モデルの不正利用と並行して行われることの多いGPUやインスタンス側の攻撃は捕捉できます。AIアロケーション自体に対して異常検知を有効にすることもできます(アロケーション監視)。

AIワークロードをAttributeで計装している場合、DoiTはトークンレベルの使用量異常検知も早期アクセスで提供しています。請求データよりも早く、暴走するワークロードを検出できます。ただし、見えるのは自社で計装したホストからのトラフィックのみのため、攻撃者のマシンから使われた盗難キーは捕捉できません。

4. CloudFlowで初動対応を自動化する

CloudFlowはDCIのアラート、予算しきい値、コスト異常をトリガーにでき、通知をアクションに変えます:

• **アラート → Slack → 承認 → 封じ込め。**Bedrockアラートが発火したら、アカウントと金額をインシデントチャンネルに投稿します。その後、人間が承認してから、AWSアクションを実行します。疑わしいアクセスキーの無効化、またはbedrock:InvokeModel*とbedrock:Converse*への明示的な拒否ポリシーのアタッチです。承認ゲートがあれば、誤検知で本番環境を止めてしまうことを防げます。
• **初回利用サービスの検知。**スケジュール実行のフローテンプレートが、どのAWSサービスやSKUであっても初めての支出を検出します。先述した新モデルのギャップをカバーします。
• **AIプロバイダーのAPIキーを失効させる。**承認を組み込んだWebhook駆動のテンプレートが、長期のBedrock認証情報(およびOpenAI、Anthropic、Geminiのキー)を削除します。EventBridge、SIEM、GuardDutyの検出結果から呼び出せます(チュートリアル)。

封じ込めアクションを実行するには、対象アカウントのCloudFlowロールに対応するIAM権限が必要です。その権限は、インシデントが起きる前に決めておいてください。

5. 攻撃者より先にギャップを塞ぐ

Security Insightsは、AWS Security HubとTrusted Advisorの検出結果を取り込みます。ローテーションされていないアクセスキー、MFAのないルートアカウント、GuardDutyやCloudTrailのないアカウントなどが含まれます。上で説明したインシデントのほぼすべてが、これらの問題のいずれかから始まっていました。

これらの検出結果はAWSの汎用ルールに基づきます。Composerを使えば、EnhancedおよびEnterpriseプランで独自のルールを作成できます。ComposerはDCIのポリシーエンジンです。接続された各アカウントのリソースをスキャンし、レシピ(コード不要で作成できるルール)と照合します。DoiTのレシピを複製して編集することも、チェックしたい内容をAIアシスタントに説明することもできます。一致した項目はSecurity insightsとして表示されます。

今年のインシデントの背後にあったギャップと、今日作成できるレシピの対応関係は次のとおりです:

最後の行は、Composerが不正利用の検出に最も近づけるポイントです。サンドボックスアカウントで最後にBedrockに使われたキーは、まだ支出が動いていなくても確認する価値があります。

検出結果に対してアクションを起こすには、Composer Insightsノードを通じて未解決のSecurity検出結果を読み取るCloudFlowをスケジュールします。毎朝Slackに投稿するか、チケットを起票します。古いキーについては、所有者が未使用であることを確認したらキーを無効化する承認ステップを追加します。

Composerは定期スキャンで動作するため、攻撃警報ではなく衛生管理のための制御です。GuardDutyやSecurity Hubのステータス、Bedrock呼び出しログ、Bedrock APIキー、SCPの内容はチェックしません。それらはSecurity InsightsとAWS Configがカバーします。今年攻撃者が通り抜けたドアを塞ぐにはComposerを、支出そのものには上記のしきい値アラートを使いましょう。

それでも起きてしまったら

侵害の疑いが生じた時点で、すぐに封じ込めを開始してください。異常アラートや最終的な請求額を待ってはいけません。

1. **まず封じ込める。**侵害されたアクセスキーを無効化し、その後削除します。aws:TokenIssueTimeを条件とした拒否ポリシーでアクティブなロールセッションを失効させ、疑わしいBedrock APIキーを無効化します。強硬手段が必要なら、影響を受けたアカウントでbedrock:*を拒否する緊急SCPで被害の拡大を止められます(正当なBedrock利用も止まります)。キーを無効化した後も、数分間は呼び出しが届き続けることを想定してください。
2. **永続化の痕跡を探す。*新しいIAMユーザー、アクセスキー、ロールと信頼ポリシーの変更、Marketplace契約、SESのID、Capacity Block、そしてすべての*リージョンのインスタンスを確認します。AWSがフラグを立てたキーだけでなく、露出した可能性のあるすべてのキーをローテーションしてください。対応中のインシデントの6日目に、誰もローテーションしなかったキーを通じて第2波が到来した例もあります。
3. **証拠を保全する。**CloudTrail(イベント履歴の保持期間は90日のみ)、呼び出しログ、リソースインベントリ、サービス別のコストエクスポートを出力します。
4. **期限内にAWSに回答する。**AWSのセキュリティ通知では通常、サービス停止まで5日間の猶予しかありません。制限はインシデントの数日後に適用されることがあり、Lambda、ECS、EC2などの本番サービスに影響する場合があります。
5. **請求調整を明示的に依頼する。**私たちが見てきたケースでは、AWSはAWS BudgetsやCost Anomaly Detectionなど、少なくとも2つのコスト監視の仕組みを求めています。加えて、ルートMFA、GuardDuty、またはSecurity Hubも求められます。これらは影響を受けたアカウント側で確認されます。攻撃者が作成したMarketplace契約はキャンセルが必要です。結果は全額クレジットから一部クレジット、却下までさまざまでした。プロセスには2〜12週間かかっています。明確なタイムライン、迅速な封じ込め、完全な証拠が結果を左右します。AWSはまた、これらの対策が整備されていない場合、将来の請求については審査しない可能性があると述べています。

AWSアカウントをDoiT経由でご契約いただいている場合は、侵害が疑われた時点ですぐにDoiTのサポートチケットを起票してください。私たちのチームがセキュリティ案件と請求調整の申請についてAWSと連携し、AWSが求める証拠の整理をお手伝いします。

LLMjackingチェックリスト

AWS側

• 人にもワークロードにも長期のIAMユーザーキーを使っていない。古いキーは監査のうえ削除済み。
• ルート:ハードウェアMFA、アクセスキーなし、自社所有ドメイン上の監視されたメールアドレス。
• すべてのアカウントにSECURITYとOPERATIONSの代替連絡先を設定済み。
• 不要な場所でBedrockを拒否し、Marketplaceサブスクリプションを制限し、GetFederationTokenをブロックするSCP。
• Bedrockの1分あたりトークン数クォータを必要量に調整済み。
• Organization CloudTrail、Bedrock呼び出しログ、すべてのアカウントとリージョンでのGuardDuty。

DoiT Cloud Intelligence側

• Bedrockと「(Amazon Bedrock Edition)」Marketplace支出をカバーするアロケーション。
• そのアロケーションに対するアカウントごとの日次しきい値アラート(「ゼロであるべき」アカウントも含む)。
• 休眠アカウントも含め、すべてのAWSアカウントに予算を設定。
• 異常通知をWarning以上に設定し、再通知を有効化し、実在する受信者を設定済み。
• AWSのリアルタイム異常検知(EnhancedおよびEnterpriseプラン)。
• 古いキーと管理者キー、ルートの状態、セキュリティ連絡先、証跡のカバレッジ、AIアカウント外でのBedrockキー使用に関するComposerレシピ。
• CloudFlow:アラートから承認を経た封じ込めと、初回利用サービスの検知。

攻撃者はLLMjackingで利益を得ているため、誰も監視していないアカウントを今後も探し続けます。完璧な検知は現実的ではありません。それでも、自社のアカウントを、攻撃者にとって「割に合わず、すぐに気づかれ、長居できない標的」にすることはできます。そして万一突破されても、請求書からではなく、数時間以内のアラートで知ることができます。

AWSのガードレールの見直しや、AIワークロード向けのDCIアラート、予算、CloudFlowの設定でサポートが必要ですか? DoiTに相談する。