AWSの漏洩したアクセスキーを悪用しAmazon Bedrockを不正利用　AIモデル料金を被害者負担にする「LLMjacking」

FortiGuard Labsは2026年9月3日、漏えいしたAmazon Web Services（AWS）のIAMアクセスキーを悪用し、Amazon Bedrock上の有料AIモデルを第三者が不正利用した「LLMjacking」の事例を公表しました。

調査されたAWSアカウントでは、長期間有効なIAMアクセスキーに「AdministratorAccess」が付与されていました。攻撃者はこの認証情報を使って新しいIAMユーザーを作成し、AWS Marketplace経由で1つ以上の基盤モデルを契約した後、モデルを呼び出して推論処理を実行しました。利用料金は侵害されたAWSアカウント側へ課金されます。

本件はAWSやAmazon Bedrockの脆弱性を悪用した事案ではありません。漏えいした正規のAWS認証情報に広範な権限が付与されていたことが侵害の起点です。

FortiGuard Labsは、LLMjackingでは有効な認証情報と正規のクラウドAPIが使われるため、単純な不正アクセス検知だけでは発見しにくいと指摘しています。AWSも長期アクセスキーよりIAMロールなどによる一時的な認証情報を優先するよう推奨しています。

AWSを悪用したLLMjacking事案のサマリー

• 【確認済み】FortiGuard Labsは2026年9月3日、Amazon Bedrockを不正利用したLLMjacking事案を公表しました。
• 【確認済み】侵害の起点は、漏えいした長期AWS IAMアクセスキーです。
• 【確認済み】漏えいしたアクセスキーにはAdministratorAccess権限が付与されていました。
• 【確認済み】攻撃者は侵害した権限を使って新しいIAMユーザーを作成しました。
• 【確認済み】攻撃者はAWS Marketplace経由で1つ以上の基盤モデルを契約しました。
• 【確認済み】契約したAIモデルを呼び出して推論処理を実行し、料金を被害者のAWSアカウントに発生させました。
• 【未確認】今回の個別事案でBedrockのサービス固有認証情報が新たに作成されたかは確認されていません。
• 【確認できず】被害を受けた組織名は公表されていません。
• 【確認できず】IAMアクセスキーがどのような経路で漏えいしたかは公表されていません。
• 【確認できず】実際に不正利用されたAIモデルの名称は公表されていません。
• 【確認できず】今回の事案で発生した具体的な請求額は公表されていません。
• 【確認できず】情報窃取やデータ破壊が行われたとの事実は、今回のFortiGuard Labsの公表では確認できません。
• 【重要】AWSやAmazon Bedrock自体の脆弱性を悪用した事案ではなく、有効なIAM認証情報の悪用です。
• 【確認済み】Amazon Bedrockのmodel invocation loggingはデフォルトで無効です。
• 【確認済み】AWSは長期アクセスキーより、一時認証情報とIAMロールの利用を推奨しています。
• 【確認済み】「LLMjacking」という名称はSysdig Threat Research Teamが2024年に公表した攻撃手法に由来します。

項目	内容
公表日	2026年9月3日
調査主体	FortiGuard Labs / FortiCNAPP
対象	AWS、Amazon Bedrock
攻撃分類	LLMjacking、クラウド認証情報の窃取・悪用
初期アクセス	漏えいした長期IAMアクセスキー
IAM権限	AdministratorAccess
攻撃後の操作	新規IAMユーザー作成、基盤モデル契約、モデル呼び出し
課金	被害者AWSアカウントへ推論料金が発生
Bedrockサービス固有認証情報	今回事案での作成は未確認
被害組織	非公表
認証情報の漏えい経路	非公表
不正利用モデル	非公表
被害額	非公表
AWS脆弱性	確認されていません
情報流出	今回の公表では確認できませんでした
主な対策	一時認証情報、最小権限、CloudTrail、Bedrock invocation logging、コスト異常監視

漏えいしたAdministratorAccess付きIAMキーを悪用

FortiGuard Labsが調査したAWSアカウントでは、長期間有効なIAMアクセスキーが外部へ漏えいしていました。

さらに、このアクセスキーにはAWS管理ポリシー「AdministratorAccess」に相当する広範な権限が付与されていました。

攻撃者はこの認証情報を利用して新しいIAMユーザーを作成し、その後AWS Marketplaceで1つ以上の基盤モデルを契約しました。続いて、契約したモデルをAmazon Bedrockから呼び出し、推論処理を実行しています。

発生したモデル利用料金は、攻撃者ではなく侵害されたAWSアカウントの所有者へ課金されます。

ここで重要なのは、Amazon BedrockやAWS Marketplaceに未知の脆弱性が存在したという話ではないことです。

AWSから見れば有効な認証情報と許可された権限を使った正規API操作であり、攻撃者はその権限を本来の利用者とは異なる目的で悪用しました。

Bedrockサービス固有認証情報の作成は今回事案では未確認

FortiGuard Labsは、LLMjackingでは新規に作成したIAMアイデンティティに対し、Bedrockのサービス固有認証情報を発行する工程が追加されることがあると説明しています。

ただし、これは同種攻撃で一般的に見られる追加工程として紹介されたもので、今回分析した個別事案で実際にその認証情報が作成されたとは記載されていません。

Hackreadも、この点についてFortinetが今回の事案で実行を確認したものではないと整理しています。

したがって、本件の確認済み攻撃チェーンは「漏えいした管理者権限付きアクセスキーの利用」「新規IAMユーザー作成」「基盤モデルの契約」「モデル呼び出し」までです。

「LLMjacking」とは　盗んだクラウド認証情報でAIを不正利用

「LLMjacking」は、クラウド上で提供される大規模言語モデルや基盤モデルへのアクセス権を、盗んだクラウド認証情報などを利用して不正に消費する攻撃を指します。

この名称はSysdig Threat Research Teamが2024年5月に公表しました。

Sysdigが当時確認した事案では、脆弱なLaravel環境からクラウド認証情報が取得され、攻撃者がAnthropic Claudeなど複数のクラウドAIサービスへのアクセス可否を調査していました。

Sysdigは、攻撃者が不正に取得したLLMアクセスをリバースプロキシ経由で第三者へ再販売している証拠も確認しています。

つまり、LLMjackingの目的はAIモデルそのものを盗むこととは異なります。

被害者のクラウドアカウントで高額なAI推論を実行し、その計算能力を攻撃者自身が利用したり、第三者へ販売したりすることで収益化します。

FortiGuard Labsも、生成AIが漏えいしたクラウド認証情報を収益化する新たな手段になっていると指摘しています。

正規APIと有効な認証情報を使うため検知しにくい

LLMjackingの特徴は、攻撃時にクラウド事業者の正規APIが使われる点です。

FortiGuard Labsは、侵害されたものの有効なIAMアイデンティティから実行されるAmazon Bedrockのモデル呼び出しは、APIレベルでは正規利用と見分けにくいと説明しています。

認証自体は成功し、対象アイデンティティにも操作権限があります。

そのため、認証失敗の急増や既知の攻撃ペイロードだけを監視していても、異常を把握できない可能性があります。

確認すべきなのは、新規IAMユーザー作成、アクセスキー変更、AWS Marketplaceでの新規契約、普段利用していないAmazon Bedrockの突然の利用、不審な送信元IP、権限変更などを時系列で関連付けることです。

FortiGuard Labsも、「初めてBedrockを利用した」というイベントだけで悪性と判断するのではなく、新しいアイデンティティ、不審なIP、列挙行動、AccessDeniedの発生など複数のシグナルと組み合わせるよう推奨しています。

Amazon Bedrockのモデル呼び出しログはデフォルトで無効

Amazon Bedrockには、CloudTrailによるAPI操作の監査と、モデル呼び出しに特化した「model invocation logging」があります。

AWS公式ドキュメントによると、CloudTrailはAmazon BedrockのAPI呼び出しをイベントとして記録できます。InvokeModel、Converseなど一部のランタイム操作についても記録対象です。

一方、model invocation loggingでは、モデルID、呼び出したIAMまたはSTSアイデンティティ、リクエスト・レスポンスデータ、トークン数など、モデル利用に関する詳細情報をCloudWatch LogsやAmazon S3へ保存できます。

AWSによると、このmodel invocation loggingはデフォルトで無効です。

FortiGuard Labsも、CloudTrailに加えて、可能な環境ではBedrock invocation loggingを有効化するよう推奨しています。

ただし、リクエストやレスポンスをログへ記録する設定では、プロンプトや生成結果に含まれる機密情報がログへ保存される可能性があります。

ログを有効にする場合は、ログ自体のIAM権限、暗号化、保存期間、閲覧者もあわせて管理する必要があります。

AWSは長期アクセスキーより一時認証情報を推奨

今回の事案では、侵害されたIAMアクセスキーが長期間有効な認証情報だったことも重要です。

AWSはIAMのセキュリティベストプラクティスとして、人間の利用者にはフェデレーション、ワークロードにはIAMロールなどを使い、可能な限り一時的な認証情報を利用するよう推奨しています。

AWS Customer Incident Response Team（CIRT）も2025年、露出した長期認証情報やアクセスキーが、同チームの観測するセキュリティインシデントで主要な初期侵入経路であり続けていると説明しています。

長期アクセスキーは、利用者側で失効させない限り利用可能な状態が続きます。

一方、一時認証情報であれば有効期間を限定できます。

ただし、認証情報を短命化するだけでは十分ではありません。今回のようにAdministratorAccess相当の広範な権限が付与されていれば、短時間でも大きな操作が可能です。

IAMロール、一時認証情報、最小権限を組み合わせる必要があります。

「AIを使っていないAWS環境」でもLLMjackingは起こり得る

今回の事案から読み取れるもう一つのポイントは、被害組織がもともとAmazon Bedrockを利用していたかどうかだけでリスクを判断できないことです。

広範な権限を持つAWS認証情報を攻撃者が取得すれば、侵害後に新しいIAMユーザーを作成し、これまで利用していなかったAWS Marketplace上のサービスを契約できる場合があります。

つまり、「自社では生成AIを使っていないからLLMjackingとは無関係」とは限りません。

クラウドセキュリティでは、現在利用しているサービスだけでなく、「侵害された権限で新しく有効化・契約できるサービス」まで攻撃面として把握する必要があります。

Organizations環境では、Service Control Policies（SCP）などを使い、不要なサービスやリージョン、操作を組織単位で制限することも検討対象になります。

不正なAI推論は高額請求につながる

FortiGuard Labsは今回の事案で実際に発生した請求額を公表していません。

そのため、「今回の被害額は○万ドル」と断定することはできません。

一方、Sysdigが2024年に公開したLLMjackingの初期研究では、当時の高性能モデルを最大クォータで不正利用した場合、1日4万6,000ドルを超える費用が発生する可能性があると試算していました。

FortiGuard Labsは、その後さらに高性能なモデルでは1日10万ドルを超える潜在的コストになり得ると、Sysdigの研究を引用しています。

これらは過去研究上の試算であり、今回確認された被害額ではありません。

モデルの種類、トークン量、リージョン、利用クォータ、料金体系によって実際の費用は変わります。

ただし、従量課金型の生成AIサービスが、仮想マシンやGPU、メール送信基盤などと同様に「盗まれたクラウド認証情報で金銭的に悪用できるリソース」になっていることは明確です。

コスト異常もセキュリティシグナルとして監視

LLMjackingでは、不正なAI利用が直接クラウド料金として表れます。

AWSは「AWS Cost Anomaly Detection」を提供しており、機械学習を使って通常とは異なる支出パターンを検知し、メールやAmazon SNS経由で通知できます。

利用していなかったAmazon Bedrockで突然課金が始まる、特定リージョンのAI推論費用が急増するなどの事象は、単なるFinOps上の異常ではなくセキュリティインシデントの兆候である可能性があります。

情報システム部門、セキュリティ部門、クラウドコスト管理部門が別々に監視するのではなく、異常課金をSOCやCSIRTへ連携できる仕組みを整備することが重要です。

公開AWSアクセスキーの長期残存も課題

今回のLLMjackingは「漏えいした長期アクセスキー」が起点でした。

セキュリティ対策Labでは2026年8月、Truffle Securityによる公開AWSアクセスキーの調査も取り上げています。

同社は過去4年間に公開環境で検出したAWS認証情報を再検証し、2026年8月時点でも9,308件がAWSへ認証可能だったと公表しました。

企業関連と判定されたキーの中には、rootアクセスキーやAdministratorAccessを持つIAMユーザーのキーも含まれていました。

関連記事：公開AWSアクセスキー9,308件がなお有効　企業関連768キーはアカウントを全面制御可能

今回のFortiGuard Labs事案と合わせると、アクセスキーの漏えいを「情報が公開された」だけの問題として扱わず、AIを含むクラウドサービスの不正利用へ即座につながる可能性を考慮する必要があります。

国内でもAWS認証情報悪用による実被害

日本でも、盗まれたAWS認証情報によって正規クラウドサービスが不正利用された事案があります。

セキュリティ対策Labでは2026年3月、つくるAI株式会社が利用していたAWS環境へ第三者が不正アクセスし、Amazon SESを悪用して約17万6,000通の迷惑メールが送信された事案を取り上げています。

同社は、不正に入手されたとみられる認証情報が攻撃に利用されたと説明しています。

関連記事：つくるAI、AWSアカウントへの不正アクセスで迷惑メール17.6万通を配信

AI推論とメール配信で悪用されたサービスは異なりますが、「漏えいしたクラウド認証情報を使い、被害者契約の正規サービスを攻撃者が消費する」という構造は共通しています。

情報システム・クラウド管理者への示唆

今回の事案ではAmazon Bedrock固有の脆弱性よりも、IAM認証情報の管理、最小権限、ログ監視、コスト監視が中心的な対策になります。

まず、AdministratorAccessなど広範な権限を持つ長期アクセスキーが存在していないか棚卸しする必要があります。

ワークロードでIAMロールへ移行できるものは長期アクセスキーを廃止し、一時認証情報へ切り替えます。長期キーを残す必要がある場合も、最小権限化、不要キーの削除、利用履歴の確認を継続する必要があります。

次に、IAMユーザー作成、アクセスキー発行、権限変更、AWS Marketplace契約、Amazon Bedrockの初回利用、モデル呼び出し急増などをCloudTrailで監視します。

Amazon Bedrockを利用している、または利用可能な環境ではmodel invocation loggingの有効化も検討します。

さらに、AWS Cost Anomaly Detectionなどを利用して異常課金を監視し、FinOpsアラートをセキュリティインシデント対応へ接続しておくことが重要です。

AIサービスの普及によって、漏えいしたクラウド認証情報の価値は高まっています。

従来は仮想マシン、ストレージ、メール送信、暗号資産マイニングなどが主な悪用先でしたが、現在は高性能な生成AIモデルへのアクセスそのものが第三者へ販売可能なリソースになっています。

クラウドIAMを守ることは、データ漏えい防止だけでなく、AI利用料金やクラウド資源を攻撃者に転用されないための対策でもあります。

出典

• Someone Else Is Using Your AI – FortiGuard Labs
• LLMjacking: Stolen Cloud Credentials Used in New AI Attack – Sysdig Threat Research Team
• Security best practices in IAM – Amazon Web Services
• Practical steps to minimize key exposure using AWS Security Services – AWS Security Blog
• Monitor Amazon Bedrock API calls using CloudTrail – Amazon Web Services
• Monitor model invocation using CloudWatch Logs and Amazon S3 – Amazon Web Services
• Detecting unusual spend with AWS Cost Anomaly Detection – Amazon Web Services
• Hackers Hijack AWS Account to Run Paid AI Models in LLMjacking Attack – Hackread
• 公開AWSアクセスキー9,308件がなお有効　企業関連768キーはアカウントを全面制御可能 – セキュリティ対策Lab
• つくるAI、AWSアカウントへの不正アクセスで迷惑メール17.6万通を配信 – セキュリティ対策Lab