たった8分で攻撃は完了しました。露出したクラウド資産からAWSの完全な管理権限まで、ある攻撃はSysdigによって文書化されており、自動化、IDの不正使用、そして許容的なクラウド制御が重なると、クラウド環境がいかに急速に侵害される可能性があるかを示しています。
ゼロデイ攻撃は一切関与しておらず、マルウェアや新たなエクスプロイトチェーンも存在しませんでした。攻撃者は、有効な認証情報、ネイティブAWSサービス、そして自動化された意思決定のみ使い、初期アクセスから管理者権限へのマシンスピードでの移行を実現しました。
過去数週間にわたって、私たちは初期の自律型 AI エージェントの振る舞い、それらが共有環境内で相互作用し、影響を与え始める様子、そして人間が介入することなく調整が迅速に形成される様子を見てきました。
このインシデントは、そうした力学が実際のクラウド環境に適用された場合に何が起こるかを示しています。
私たちが予測したことは、現在では観測可能です。偵察が加速し、攻撃者がアイデンティティを制御すると、環境を効果的に制御します。その結果、新しい種類の攻撃が生まれるわけではありませんが、攻撃速度は劇的に速くなります。
この分析では、侵入を段階的に説明し、攻撃が加速した場所、防御側が現実的に介入できた可能性のある場所、そして AI の速度で移動するクラウド侵害を阻止する唯一の実行可能な方法として、アイデンティティ中心の振る舞い検知がなぜ今や唯一の実行可能な方法なのかを強調します。
自動化が攻撃タイムラインを崩壊させる時
このインシデントが際立ったのは、AI によって摩擦が排除された点です。攻撃者は慎重に調査したり、脆弱性を連鎖させたりしませんでした。自動化によって、サービスの列挙、権限パスの評価、エスカレーションの実行が、人間のオペレーターが手動で行うよりも迅速に実行できました。
防御側にとって、関連するアクションのほとんどは、単独では正当に見えます。API 呼び出しは認証され、サービスは承認されたメカニズムを通じてアクセスされ、権限はバイパスされたのではなく、悪用されました。
唯一信頼できるシグナルは振る舞いでした。 誰がアクターで、どのくらい速く動いたか、そしてサービス全体でどのような一連のアクションが展開されたか。
高レベル攻撃フロー
大まかに言えば、侵入は5つの段階で展開した。
- 公開された資産を介した初期アクセス
- サービス横断的な偵察
- ラムダ関数の乱用
- 特権の昇格
- 持続と拡大
- リソースの乱用とデータの外部化
シーケンス全体には多くの個別のステップが含まれますが、成功に重要となるのはサブセットのみです。これらのステップが検知されるか停止されると、攻撃は完全に失敗します。
フェーズ1：公開されたクラウド資産を通じた初期アクセス
何が起きたのか：
攻撃はAWSアカウントの外で始まり、特定の組織を標的としたものではありませんでした。
攻撃者は、AIツールやクラウドオートメーションで一般的に使用される命名規則を用いて、公開アクセス可能なS3バケットを検索しました。これらの規則に従うAWS環境はすべて、潜在的な侵入ポイントとなる可能性があります。
攻撃者はあるバケット内に、IAMアクセスキーを含むファイルを発見しました。これらの有効な認証情報を使用して、攻撃者は被害者のAWSアカウントに直接認証しました。
AWSの観点では、有効なIDが正常にログインしました。
なぜこれが重要なのか：
多くのクラウドインシデントはここから静かに始まります。クラウド セキュリティ態勢の問題によって攻撃の糸口が作られることがよくありますが、ID の悪用によって攻撃者がどこまで攻撃できるかが決まります。
認証が完了すると、攻撃者は直ちに攻撃の次の段階に移行しました。
フェーズ2：マシン速度でのクロスサービス偵察
何が起きたのか：
認証後、攻撃者はS3、Lambda、EC2、IAM、Bedrock、CloudTrailを含む複数のAWSサービスに対して広範な偵察活動を実施しました。
この作業は迅速かつ体系的かつ自動化されていました。APIレスポンスはリアルタイムで取り込まれ、評価され、実行可能なエスカレーションパスが特定されました。
なぜこれが重要なのか：
偵察はその後のすべてを可能にします。サービス、役割、そして信頼関係の可視性がなければ、エスカレーションパスは見えなくなります。
ここで、自動化によって状況が変わります。AI 支援ツールを使用すると、攻撃者は数秒で API 応答を取り込み、権限を評価し、実行可能なパスを特定できます。
SOCチームにとって、このフェーズは介入できる現実的な最も早い機会となります。権限昇格が始まると、対応できる時間は劇的に短くなります。
この振る舞いは、有効なアカウントの不正利用とクラウドサービスの検知に関するMITRE ATLAS で文書化された手法と密接に一致しています。攻撃者は新しい手法を考案するのではなく、自動化を利用して既知の振る舞いを加速させました。
フェーズ3：主要なボトルネックとしてのラムダ乱用
何が起きたのか：
攻撃者は既存の AWS Lambda 関数に注目し、それを権限昇格のメカニズムとして使用しました。
まず、関数のコードを変更し、実行タイムアウトを長くしました。このLambda関数には、IAMユーザーとアクセスキーを作成するのに十分な権限を持つ実行ロールが付与されていました。
次に、修正した関数を呼び出しました。関数が実行されると、管理者権限を持つ新しいIAMアクセスキーが作成されました。
各ステップは単独では正当なものでしたが、これらを総合すると、日常的な自動化コンポーネントがエスカレーション パスに変わりました。
なぜこれが重要なのか：
この一連の出来事が、攻撃が取り返しのつかないものとなった瞬間だった。
いずれかの部分が失敗すると、チェーンは切断されます。関数が変更不可能であれば、悪用されることはありません。関数が実行されなければ、新しい認証情報は作成されません。関数は実行されても管理者アクセスキーを作成できない場合、攻撃者は攻撃を遅らせます。
Lambda関数は、他のサービスではほとんど見られない方法で自動化と権限を集中化しています。実行ロールは意図したよりも広範囲に及ぶことがよくあります。コード変更はまれで、精査も容易です。呼び出しは想定されており、頻繁に行われます。
このシーケンスにはAWSポリシー違反や明確な制御エラーを引き起こすものは何もありません。関数の動作がどのように変化し、その直後に何が有効になったかを確認した場合にのみ、リスクが明らかになります。
これは現代のクラウド攻撃で頻繁に見られるパターンです。攻撃者はインフラストラクチャを悪用する必要はありません。彼らはそれを再利用します。
フェーズ4：プログラムによる特権昇格
何が起きたのか：
攻撃者は、変更された Lambda 関数を使用して、管理者権限を持つ新しい IAM アクセス キーを作成しました。
これは脆弱性の悪用を伴わない特権昇格でした。
攻撃者は単に実行ロールを使用して、許可された操作を実行したに過ぎません。ただし、その作成者が意図した方法ではありませんでした。
その瞬間から、攻撃者が事実上アカウントを所有することになります
なぜこれが重要なのか：
防御側にとって、これは従来のセキュリティ対策がしばしば機能しない点です。アイデンティティおよびアクセス管理システムは、意図ではなくポリシーを強制します。
管理者権限が存在すると、ほとんどの制御は機能しなくなります。管理者アクセスが存在すると、対応範囲が狭まり、修復作業は大幅に複雑になります。
フェーズ5：持続と拡大
何が起きたのか：
管理者権限の取得に成功した攻撃者は、次に永続化に注力した。
具体的には、新しいIAMユーザーを作成し、それに 管理者アクセス ポリシーを適用し、既存のユーザーの追加アクセス キーを生成し、Secrets Manager と SSM パラメータ ストアからシークレットを取得しました。
それぞれの行動は攻撃者の足場を広げ、修復の効果を低下させました。たとえ1つの認証情報が取り消されたとしても、他の認証情報はそのまま残ります。
なぜこれが重要なのか：
このフェーズは、アクセスから保証への移行を反映しています。攻撃者は防御側が対応した場合でも、制御を継続することを保証していました。
繰り返しになりますが、これらのアクションは正当な権限を持つ正当なAPIを通じて実行されました。メンテナンスと侵害の違いは、完全に動作とタイミングにあります。
フェーズ6：リソースの乱用とデータの外部化
何が起きたのか：
攻撃者は衝突するために移動しました。
彼らは、オープン セキュリティ グループと公開された JupyterLab インターフェースを備えたハイエンド GPU インスタンスを起動しました。
彼らは Bedrock モデルを呼び出し、EBS スナップショットを外部で共有しました。
なぜこれが重要なのか：
この時点で、侵害は既に成功していました。これらの行動は、リソースの不正利用、潜在的なデータ窃取、そして金銭の搾取という、攻撃者の明確な意図を示しています。
この段階は、LLM ジャッキング、コストの不正使用、クラウド ID が侵害された後のデータ漏洩など、攻撃者が AWS Bedrock をターゲットにする方法に関するポッドキャストのエピソードで説明されているパターンと一致しています。
もしも…？
記録された攻撃がそこで停止したのは、攻撃者が選択肢を使い果たしたからではなく、それが観察されたからでした。
持続的な管理者アクセス権があれば、攻撃者は以下を行うことができた可能性があります。
- 信頼ポリシーとクロスアカウントロールを通じて長期的な持続性を確立
- CI/CD パイプラインを変更して悪意のあるコードを本番環境に挿入する
- 正当なワークロードをミラーリングするシャドーインフラストラクチャを作成した
- スナップショットとレプリケーションを使用して、サイレントかつ増分的なデータ流出を実行しました
- AIサービスを継続的に使用し、通常の使用にコストの浪費を混ぜ込んでいた
- 接続されたAWSアカウントまたはSaaSプラットフォームへ移行
これらのアクションはいずれも追加のエクスプロイトを必要としません。時間が必要です。 8 分は単なるエントリポイントです。
侵害後の検知の緊急性
衝撃が起きる頃には、予防はすでに失敗しています。
防御の価値は、特権の昇格と永続化によって攻撃者の制御が固定される前に、攻撃チェーンの早い段階で変化します。
攻撃チェーン全体が長い間、防御側は攻撃フローに沿った重要なステップの削減に集中できます。
- 広範かつ迅速なサービス横断型偵察
- 既存のラムダ関数の変更
- 管理者アクセスのプログラムによる作成
- 永続的なIAMアイデンティティの確立
- クラウドネイティブ機構によるデータの外部化
これらは、連続して見ると通常の使用パターンから大きく逸脱する動作です。
課題は相関関係です。
ほとんどのクラウド セキュリティ制御は設計上静的であり、意図と矛盾しています。
このインシデントでは、
- 認証情報は有効でした
- APIは設計通りに使用された
- 権限は正当に存在していた
唯一の異常は、時間の経過に伴う行動でした。
これは、動きの速い AI 支援攻撃が悪用する検知ギャップです。
アイデンティティ中心の振る舞い検知が必要な理由
攻撃がマシンスピードで進む場合、検知も同じレベルで動作する必要があります。
これは理解を必要とします。
- 人間、機械、および能動的アイデンティティが通常どのように振る舞うか
- サービスが通常どのように利用されるか
- どのような行動の連鎖が典型的または珍しいのか
- 制御が攻撃者に移ったとき、振る舞いがどのように変化するか
アイデンティティ中心の検知は、クラウド上のアイデンティティ (人間、非人間、エージェント) を主要なシグナルとして扱います。振る舞いAIは、これらのアイデンティティがサービスや環境全体でどのように機能するかをモデル化します。
偵察が加速したり、Lambda の動作が変化したり、予期せず権限が付与されたりすると、それらの変化がリアルタイムで検知されます。
これは、権限の昇格が取り返しのつかなくなる前に攻撃を阻止する唯一の実用的な方法です。
Vectra AI
Vectra AI プラットフォーム は、まさにこの問題領域向けに設計されています。
Vectra AI は、クラウド コントロール プレーン、ネットワーク トラフィック、SaaS アクティビティ、クラウド ワークロード全体の ID 動作を分析することで、有効なアクセスと自動化に依存する攻撃の初期段階を検出します。
影響が出るまで待つのではなく、次の点に焦点を当てます。
- 偵察パターン
- 特権の乱用
- 横方向の動き
- データの不正利用
管理者アクセスが数分で侵害される可能性がある場合、自動対応は必須です。アクセスからエスカレーションまでの時間が短くなる中で、対応できる唯一の手段です。
この事件により期待がリセットされるはずです。
8分はもはや例外ではありません。アイデンティティが悪用され、防御が静的な仮定に依存している場合、自動化によってそれが可能になります。教訓はAIを恐れることではなく、攻撃者が既にAIを利用してタイムラインを短縮し、躊躇を排除し、意思決定をスケール化していることを認識することです。
防御側は、次のように対応する必要があります。検出は振る舞いに基づいて行う必要があります、カバレッジはアイデンティティ中心でなければなりません、対応は自動化する必要があります。
クラウド管理者のアクセスが AI の速度で低下すると、事後にアラートをまとめる時間がなくなるからです。