2025年11月28日、クラウドセキュリティの歴史に刻まれるべき極めて特異なインシデントが発生した。Sysdig Threat Research Team（TRT）が観測したこの攻撃において、攻撃者はAWS環境への初期侵入から、わずか8分という驚異的な速さでフル管理権限（AdministratorAccess）を手中に収めたのだ。
この事案がこれまでのサイバー攻撃と一線を画すのは、その速度だけではない。偵察、悪意のあるコードの生成、リアルタイムの意思決定、そして攻撃の実行に至るサイバー攻撃のライフサイクルのほぼ全工程に「大規模言語モデル（LLM）」が深く関与していた点にある。AIはハッカーにとっての「ブースター」となり、従来は数時間から数日を要した高度な侵入プロセスを、コーヒーを一杯飲むほどの短時間へと圧縮してしまった。
始まりは「AI開発データ」の不備：初期侵入のトリガー
皮肉なことに、このAI主導の攻撃の入り口となったのは、被害組織が自社のAIモデルのために用意していた「Retrieval-Augmented Generation（RAG）」データを保存するためのAmazon S3バケットだった。
攻撃者は、公開設定が誤っていたこのS3バケットから、有効なAWSアクセスキーを発見した。このキーは、AWS Lambdaの読み書き権限とAmazon Bedrockへの制限付きアクセス権を持つ、テスト用のIdentity and Access Management（IAM）ユーザーのものだった。
近年のAI開発ブームにおいて、開発効率を優先するあまりセキュリティ設定が疎かになるケースが散見される。今回、攻撃者が「AIツール」に関連する一般的な名称を持つバケットを標的に偵察を行っていた事実は、AI開発環境そのものが攻撃者にとっての「新たな鉱脈」となっている現状を改めて浮き彫りにした形だ。
偵察と特権昇格：AIが書いた「セルビア語」のコード
初期侵入に成功した攻撃者は、即座にAWS環境全体の広範な偵察を開始した。Secrets Manager、Systems Manager（SSM）、EC2、RDS、CloudWatchなど、主要なサービスを網羅的に調査し、さらなる攻撃の足掛かりを探った。
特筆すべきは、その後の特権昇格の手法である。攻撃者は、盗んだユーザーがLambda関数のコードを更新する権限（UpdateFunctionCodeおよびUpdateFunctionConfiguration）を持っていることに着目した。手作業でコードを書く代わりに、AIを用いて既存の「EC2-init」というLambda関数に悪意のあるスクリプトを注入したのである。
このスクリプトには、AIによる生成を示唆する決定的な証拠がいくつか残されていた。
- セルビア語のコメント: コード内には「Kreiraj admin access key（管理用アクセスキーを作成する）」といったセルビア語のコメントが記述されていた。これは攻撃者の出自を示唆すると同時に、LLMが対話の結果として生成したコードをそのまま利用した可能性が高いことを示している。
- 高度なエラー処理と設定変更: スクリプトには包括的な例外処理が組み込まれており、さらに処理時間を確保するためにLambdaの実行タイムアウトをデフォルトの3秒から30秒へ引き上げる設定変更まで含まれていた。
- 高速な試行錯誤: 攻撃者は3回にわたってコードを更新し、最終的に「frick」という名前の管理ユーザーに対するアクセスキーの作成に成功した。
初期侵入から、このLambda経由での管理権限奪取までにかかった時間はわずか8分である。人間が手動で行う場合、環境の理解とデバッグを含めれば数十分から数時間はかかる作業だ。
AIの「幻覚」が残した足跡：機械的な効率性と精度の限界
攻撃の過程では、AI特有の挙動である「ハルシネーション（幻覚）」も観測された。これが、攻撃者がAIを全面的に活用していたことを裏付けるもう一つの証拠となっている。
攻撃者は、被害組織のAWS Organizations内の別アカウントへ横展開（ラテラルムーブメント）を試みた際、存在しない、あるいは数字が昇順・降順に並んでいるだけの架空のアカウントID（例：123456789012、210987654321）に対して役割の引き受け（assume-role）を試行した。さらに、実際には存在しないAnthropic社のGitHubリポジトリ（training-scripts.git）からコードをクローンしようとする挙動も見られた。
人間のハッカーであれば、偵察結果に基づいて正確なIDを狙う。しかし、AIエージェントによる自動化された攻撃では、確率的に「ありそうな名前」や「構造」を生成して試行錯誤を繰り返すため、このような不自然なエラーが発生する。
LLMjackingとリソースの強奪：攻撃の真の目的
管理権限を手に入れた攻撃者が次に向かったのは、Amazon Bedrockを通じたAIモデルの悪用、いわゆる「LLMジャッキング」である。
彼らは、まずモデルの実行ログが有効になっているかどうかを確認した（GetModelInvocationLoggingConfiguration）。ログが無効であることを確認した上で、Claude、DeepSeek、Llama、Amazon Nova、Titan Image Generatorなど、多種多様な基盤モデルを呼び出し始めた。
LLMジャッキングの主な動機は「計算資源の横取り」である。Sysdigの過去のレポートによれば、このような攻撃によって被害組織が支払うLLMの使用料は、1日あたり最大46,000ドル（約700万円）に達する可能性がある。攻撃者は、他人のコストで高度なAIを動かし、そのアクセス権をブラックマーケットで転売するか、独自のモデル訓練に利用しようとする。
実際に、今回の攻撃者は「stevan-gpu-monster」と名付けた超高性能なGPUインスタンス（p5.48xlarge）の起動を試みている。容量不足により失敗したものの、最終的にはp4d.24xlargeインスタンスの起動に成功した。このインスタンスの利用料は1時間あたり32.77ドル、月額に換算すると約23,600ドル（約350万円）に上る莫大なコストだ。
防御 evasion と持続性の確保：19のアイデンティティを使い分ける老獪さ
攻撃者は、検知を逃れるために極めて狡猾な手段を講じていた。
- IPローテーターの使用: リクエストごとにソースIPアドレスを変更するツールを使用し、単一IPからの大量アクセスに基づく検知を回避した。
- アイデンティティの分散: 最終的に、6つのIAMロールと5つのIAMユーザーを含む計19のAWSプリンシパルを侵害し、操作を分散させた。これにより、一つのアカウントの不審な挙動を特定しても、攻撃の全貌を掴むことを困難にした。
- バックドアの設置: 侵害したインスタンス上で、AWSの認証情報を必要としないJupyterLabサーバーをポート8888で起動した。これは、たとえAWSのアクセスキーが無効化されても、Webブラウザ経由でサーバーへ継続的にアクセスするための裏口である。
AWSの公式見解と、我々が直面する教訓
この衝撃的な報告に対し、AWSは公式に「AWSのサービスとインフラ自体に脆弱性はなく、設計通りに動作していた」とのコメントを出している。今回の事案はあくまで、ユーザー側の「S3バケットの設定ミス」が起点となったものであり、AWS側の欠陥ではないという立場だ。
しかし、これは防御側にとってより深刻な事実を突きつけている。クラウド側の脆弱性を突かなくても、設定の一つの綻びさえあれば、AIを味方につけた攻撃者は瞬く間にシステム全体を制圧できるということだ。
防御側が取るべき具体的な対策
Sysdig TRTおよび各報道は、同様の被害を防ぐために以下の対策を強く推奨している。
- S3バケットの厳格な保護: 公開設定の定期的チェックに加え、RAGデータなどの機密情報を扱うバケットには「Public Access Block」を確実に適用する。
- IAMロールへの移行: 長期利用のアクセスキーを持つIAMユーザーの使用を避け、一時的な認証情報を使用するIAMロールを優先する。
- Lambda権限の制限:
UpdateFunctionCodeやUpdateFunctionConfigurationの権限は、必要なIDに対してのみ、特定の関数に限定して付与する。 - ガードレールの設置: Service Control Policies (SCP) を利用し、組織内で許可されていないEC2インスタンスタイプ（高額なGPUインスタンスなど）の起動や、未使用のBedrockモデルの呼び出しを禁止する。
- モニタリングの強化: Amazon GuardDutyなどのモニタリングサービスを有効化し、異常なリソース列挙やAPI呼び出しをリアルタイムで検知できる体制を整える。
AI時代のセキュリティ・パラダイム
もはや、サイバー攻撃は「人間の思考スピード」で行われるものではなくなった。攻撃者がLLMという強力な「コード生成エンジン」と「意思決定支援システム」を手に入れた今、防御側もまた、AIを活用した検知と自動応答を取り入れなければ、この圧倒的な速度差を埋めることは不可能である。
「侵入されてから対応を検討する」という従来の姿勢では、8分間で全てが終わってしまう。AIによって圧縮された攻撃サイクルに対抗するためには、最小権限の原則（Least Privilege）の徹底という基本に立ち返ると同時に、ランタイムでの異常検知という「動的な防御」をシステムに組み込むことが、現代のクラウド運用における絶対条件となるだろう。
Sources
