攻撃者はAmazon Web Servicesのクラウド環境への侵入に成功し、わずか10分で完全な管理者権限へと権限を昇格させた。脅威研究者によれば、この迅速な侵害は人工知能によって加速され、侵入のほぼすべての段階がAIによって支援されていた。
Sysdig脅威研究チームは11月28日、このインシデントを記録し、攻撃の前例のない速度だけでなく、自動化の痕跡が広範に見られたことも指摘した。分析担当者は、犯人が偵察、権限昇格、ラテラルムーブメント、有害なコードの生成に大規模言語モデル（LLM）を武器化したと結論づけた。さらに「LLMハイジャック」の事例も観測され、侵害されたアカウントがクラウドベースのモデルおよびそれに付随する計算リソースへアクセスするために利用されていた。
調査により、敵対者は10分未満で管理者権限を掌握し、生成モデルサービスとGPUクラスターを悪用しながら19のクラウドIDを侵害したことが明らかになった。悪性コードにはセルビア語のコメント、架空のアカウント識別子、存在しないソースコードリポジトリへの参照が含まれており、こうした不整合はコードがAIによって合成されたことを強く示唆している。
侵入の初期地点は、公開されているAmazon S3バケット内で見つかった露出したテスト用認証情報だった。これらの認証情報は、クラウド関数に対する読み書き権限と、LLMサービスへの制限付きアクセスを持つIdentity and Access Management（IAM）ユーザーに属していた。同じリポジトリにはモデルのファインチューニング用データセットも含まれており、後にキャンペーン中に武器化された。専門家は、アクセスキーを公開リポジトリに置いてはならないと強調する。永続的な認証情報よりも一時的な認証情報の方が堅牢なセキュリティ態勢を提供し、後者が必要な場合でも厳格な頻度でローテーションしなければならない。
当初、侵入者は一般的な管理者エイリアスを通じて権限の引き上げを試みたが、成功しなかった。その後、クラウド関数内でコードインジェクションを実行し、コードと設定を変更できる権限を悪用した。関数のロジックは、特権IDを引き受けようとする試みの中で反復的に書き換えられ、最終的に完全な管理者アカウントの侵害に至った。
悪性スクリプトは、ユーザーとアクセスキーを体系的に列挙し、新しい認証情報を生成し、複数のストレージバケットの内容を精査した。高度なエラーハンドリングと延長された実行タイムアウトの存在は、生成モデルの使用をさらに裏付けている。認証情報の窃取から関数の呼び出しまでの遅延は驚くほど短かった。
攻撃が進むにつれ、攻撃者はアカウント識別子を収集し、発見されたすべての環境でロールの引き受けを試みた。この段階では、プレースホルダーの数字を含む余計な識別子が現れたが、これはモデルがもっともらしいが事実に反するデータを生成するAIの「ハルシネーション」の典型的な特徴である。
広範なアクセスを獲得すると、犯人はSecrets Managerからのシークレット、システム設定パラメータ、イベントログ、ソースコード、ストレージデータを流出させた。その後、焦点はAmazon Bedrockサービスへ移り、攻撃者はアカウント所有者の通常利用とは異なる複数のモデルを呼び出した。専門家は、このような異常な呼び出しを重大な「レッドフラグ」と分類し、厳格なサービスコントロールポリシーによって許可するモデルを制限するよう組織に助言している。
攻撃者はさらに機械学習用仮想マシンを利用し、スクリプトのホスティングにクラウドストレージを使用し、モデル学習環境の立ち上げを試みた。あるスクリプトは存在しないリポジトリを参照しており、以前の生成上の異常を反映していたほか、ポート8888で公開コンピュートサーバーを立ち上げて秘密のバックドアとして機能させようとした。しかし、このインスタンスは作成から5分以内に終了させられた。
Sysdigは、AI主導の攻勢がますます一般化しており、クラウド侵入の完全自動化が間近に迫っている可能性が高いと強調する。主要な防御策は、IDと権限の厳格なガバナンスにある。最小権限の原則に従い、クラウド関数コードの改変とロール委任を制限し、機微なストレージへの公開アクセスを排除し、すべてのモデル相互作用に対して包括的なログを実装することが推奨される。
Amazonは、基盤となるサービスインフラは安全で、意図どおりに動作していたと説明した。このインシデントは、顧客側の公開ストレージの設定ミスに起因するものだった。同社は、ストレージ設定を非公開に保ち、最小限の権限を適用し、認証情報を保護し、不正な活動のリスクを軽減するために監視サービスを利用するようユーザーに促している。
