最近、Sysdigのブログで見つけた記事がかなり衝撃的だったので勉強がてらメモしておきます。
AI-assisted cloud intrusion achieves admin access in 8 minutes
「AIがアシストするクラウド侵入、わずか8分で管理者権限を取得」
要するにAIを使った攻撃者がAWSの管理者権限を8分で取得したという話です。2025年11月に実際に起きたインシデントらしいです。
何が起きたのか
ざっくり言うと、こんな流れだったようです。
- 公開されていたS3バケットから認証情報を盗む
- そのIAMユーザーがLambdaとBedrockの権限を持っていた
- Lambdaのコードを書き換えて権限昇格
- 管理者ユーザーを作成
- Bedrockで遊ぶ（= LLMジャッキング, LLMjacking）
- GPUインスタンスを立てる
ここまで8分。早すぎ。
最初の侵入経路
S3バケットにAI/RAGのトレーニングデータが置いてあって、そこに認証情報も含まれていたっぽいです。AIの学習データを公開S3に置くというのは割とありがちな構成だと思うんですけど、そこに認証情報が混ざっていたのが致命的でした。
盗まれたIAMユーザーはBedrockのタスクを自動化するために作られたと推測されていて、LambdaとBedrockの権限を持っていました。たぶん開発用のユーザーだったんじゃないかなと思います。
Lambdaコードインジェクション
ここからが怖いです。
攻撃者はEC2-initというLambda関数のコードを3回書き換えて、最終的にfrickという管理者ユーザーのアクセスキーを作成しています。
で、そのLambdaに注入されたコードを見ると
- セルビア語のコメントが入っている
- 例外処理が妙に丁寧
- 漏れのないエラーハンドリングが実装されている
記事では、LLMが生成したコードっぽいと指摘しています。
ざっと見た感じ、言われると整いすぎている気がしますね。
気になる方はぜひ記事にコードが記載されているので読んでみてください。
LLMが使われた証拠っぽいもの
さらに記事の中でAIが使われた証拠として挙げられていたのが面白かったです。
- 存在しないAWSアカウントID
123456789012とか210987654321(1234…のミラー)とか、明らかにダミーっぽいIDがコードに含まれていました。 - 存在しないGitHubリポジトリ
セットアップスクリプトにgithub.com/anthropic/training-scripts.gitというURLがあったんですが、そんなリポジトリは存在しません - 実行速度
8分で管理者権限取得、19のプリンシパルを横断、14のVPNアドレスを使い分け…人間が手作業でやるには早すぎる
AccountID 123456789012?
123456789012はAWSのドキュメントやサンプルコードでよく使われるダミーIDなので、LLMがそのまま出力しちゃった可能性が高いと思います。
LLMjackingって何
攻撃者は管理者権限を取った後、Bedrockでいろいろやっていたようです。
- Claude（複数モデル）
- DeepSeek R1
- Llama 4 Scout
- 画像生成モデル
を呼び出していたらしいです。
しかも呼び出す前にログが無効になっているかを確認してから実行しています。
周到。
これがLLMjackingと呼ばれる攻撃で、他人のAWSアカウントのBedrock枠を勝手に使うというものです。GPUインスタンス（p4d.24xlarge、$32.77/時間）も立てていたので、被害者は相当な請求が来たんじゃないかと思います。
自分の環境は大丈夫か
読んでいてヒヤッとしたポイントをまとめておきます。
- S3に認証情報が混ざっていないか
- LambdaのIAMロールが過剰な権限を持っていないか
UpdateFunctionCodeとPassRoleの権限が適切に制限されているか- Bedrockのモデル呼び出しログが有効になっているか
特にBedrockのログはデフォルトで無効なので、有効にしていない環境は多いんじゃないでしょうか。記事を見てからすぐに見に行きました。
感想
正直、AIを使った攻撃がここまで洗練されているとは思っていませんでした。
8分で管理者権限というのはインパクトがありますが、冷静に考えると攻撃の各ステップ自体は特別新しいものではないです。S3からの認証情報漏洩、Lambda経由の権限昇格、IAMロールチェーン…どれも既知の手法です。
でも、それをAIで自動化・高速化されると、防御側が対応する時間がほとんどなくなります。8分じゃアラートに気づいても間に合わないですよね。
あと、LLMが生成したコードに存在しないアカウントIDが入っているのは、ある意味フォレンジックの手がかりになるのかもしれません。攻撃者にとっては諸刃の剣というか。
AI提供会社の対応を期待
もう一つ気になったのは、ここまでのやり取りをAI側が普通に受け取っちゃってる点です。
今回みたいに明らかに権限昇格をねらった指示とか、AWS環境を横展開しようとしている流れは人間が見ればすぐにおかしいと気づきます。
今後、AIが業務システムに深く入り込んでいくなら、AI提供会社でも何かしらのガードレールは必要になってくると思います。
危険な権限操作っぽいプロンプトを検知するとか、実行前に確認を挟むとか。
（矛盾するようですが攻撃とか詐欺の防止にだけ使えたらいいですね。見分けがつかないけど）
こうした攻撃の手法を学びつつ、襟を正してAI時代のセキュリティ手法を学んでいきたいと思います。
引用・参考
https://www.sysdig.com/blog/ai-assisted-cloud-intrusion-achieves-admin-access-in-8-minutes
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
