わずか8分で完了した。Sysdigが記録した 攻撃は、クラウド資産の露出からAWSの完全な管理権限取得に至るまで、自動化、ID悪用、緩いクラウド制御が重なった際にクラウド環境がいかに迅速に侵害されるかを示している。
ゼロデイ攻撃は関与しておらず、 マルウェア や新規のエクスプロイトチェーンは存在しなかった。攻撃者は有効な認証情報、ネイティブのAWSサービス、自動化された意思決定に完全に依存し、マシン並みの速度で初期アクセスから管理者権限への移行を実現した。
ここ数週間、私たちは自律型AIエージェントの初期行動、共有環境内で相互に作用し影響し合うようになった過程、そして人間の介入なしに協調が急速に形成される様子を観察してきた。
この事例は、そうした力学が実際のクラウド環境に適用された場合に何が起こるかを示している。
我々が予測していたことが今や現実のものとなった：偵察活動が加速し、攻撃者が一度IDを掌握すれば、事実上その環境全体を支配する。その結果として 生まれたのは新たな攻撃手法ではなく、劇的に高速化した攻撃である。
この分析では侵入プロセスを段階的に追跡し、攻撃が加速した箇所、防御側が現実的に介入できた可能性のある箇所、そしてAIの速度で進行するクラウド侵害を阻止する唯一の有効な手段が、アイデンティティ中心の振る舞い である理由を明らかにする。
自動化が攻撃タイムラインを崩壊させる時
この事件が際立っているのは、AIが摩擦を除去したためである。攻撃者は慎重に探ることも、脆弱性を連鎖させることもなかった。自動化により、サービス列挙、権限パス評価、権限昇格の実行を、人間のオペレーターが手動で対応できる速度よりも速く行うことが可能となった。
防御側にとって、関連する行動の大半は単独で見れば正当に見えるだろう。API呼び出しは認証され、サービスは承認されたメカニズムを通じてアクセスされ、権限は悪用されたが、回避されたわけではない。
唯一の信頼できるシグナルは振る舞いだった：誰が行動し、どれだけ素早く動いたか、そしてサービス間でどのような行動の連鎖が展開されたか。
高レベル攻撃フロー
大まかに言えば、侵入は5つの段階で展開した：
- 公開された資産を介した初期アクセス
- サービス横断的な偵察
- Lambdaの悪用による特権昇格
- 持続と拡大
- リソースの乱用とデータの外部化
一連の完全な手順には多くの個別ステップが含まれていたが、成功に不可欠だったのはその一部に過ぎなかった。それらのステップが検知または阻止されれば、攻撃は完全に失敗する。
フェーズ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アクセスキーを作成しました。
各ステップは単独では正当なものだったが、それらを組み合わせることで、日常的な自動化コンポーネントがエスカレーション経路へと変貌した。
なぜこれが重要なのか：
この一連の出来事が、攻撃が不可逆的となった分岐点であった。
その一部が失敗すれば、連鎖は断たれる。関数が変更不可能であれば、悪用も不可能だ。実行されなければ、新たな認証情報は生成されない。実行されても管理者アクセスキーを作成できなければ、攻撃者は行き詰まる。
ラムダ関数は、他のサービスではほとんど見られないほど自動化と特権を集中させている。実行ロールは意図以上に広範な場合が多い。コード変更は頻度が低く、厳密な検証も受けない。呼び出しは想定内であり、頻繁に行われる。
この一連の操作は、AWSポリシーに違反するものでも、明らかな制御失敗を引き起こすものでもありません。リスクが明らかになるのは、関数の動作がどのように変化し、その直後に何が可能になったかを検証した時だけです。
これは現代のクラウド攻撃における繰り返し見られるパターンである。攻撃者はインフラを悪用する必要はない。彼らはそれを転用するのだ。
フェーズ4：プログラムによる特権昇格
何が起きたのか：
攻撃者は変更されたLambda関数を使用して、管理者権限を持つ新しいIAMアクセスキーを作成した。
これは脆弱性の悪用を伴わない特権昇格であった。
攻撃者は単に実行ロールを使用して、許可された操作を実行したに過ぎない。ただし、その作成者が意図した方法ではなかった。
その瞬間から、攻撃者は事実上そのアカウントを掌握した。
なぜこれが重要なのか：
防御側にとって、ここが従来のセキュリティ対策がしばしば失敗する点である。IDおよびアクセス管理システムは意図ではなくポリシーを強制する。
管理者権限が存在すると、ほとんどの制御は機能しなくなる。管理アクセスが存在すると、対応範囲は狭まり、修復は著しく複雑化する。
フェーズ5：持続と拡大
何が起きたのか：
管理者権限の取得に成功した攻撃者は、次に永続化に注力した。
具体的には、新しいIAMユーザーを作成し、それに 管理者アクセス ポリシーを適用し、既存ユーザー向けに追加のアクセスキーを生成し、Secrets ManagerおよびSSMパラメータストアからシークレットを取得しました。
各アクションは攻撃者の足場を拡大し、修復の効果を低下させた。たとえ1つの認証情報が無効化されても、他の認証情報は残存した。
なぜこれが重要なのか：
この段階は、アクセスから保証への移行を反映している。攻撃者は防御側が対応しても継続的な制御を確保していた。
繰り返すが、これらの操作は正当な権限を用いた正規のAPIを通じて実行された。保守と侵害の違いは、行動とタイミングに完全に依存する。
フェーズ6：リソースの乱用とデータの外部化
何が起きたのか：
攻撃者は衝撃を与えるために動いた。
彼らはセキュリティグループを開放した状態でハイエンドGPUインスタンスを起動し、JupyterLabインターフェースを公開した。
彼らは基盤モデルを呼び出し、EBSスナップショットを外部と共有した。
なぜこれが重要なのか：
この時点で、侵害は既に成功していた。これらの行動は攻撃者の明確な意図を示している：リソースの悪用、潜在的なデータ流出、そして金銭的利益の獲得である。
この段階は、攻撃者がAWS Bedrockを標的とする方法について議論したポッドキャストエピソードで取り上げたパターンと一致しています。 攻撃者がAWS Bedrockを標的とする方法、LLMジャック、コスト悪用、クラウドID侵害後のデータ漏洩といったパターンと一致しています。
「もしも…？」
記録された攻撃がそこで止まったのは、攻撃者が選択肢を使い果たしたからではなく、観察されたためである。
持続的な管理者アクセス権があれば、攻撃者は以下を行うことができた可能性があります：
- 信頼ポリシーとクロスアカウントロールを通じて確立された長期的な永続性
- CI/CDパイプラインを改変し、本番環境に悪意のあるコードを注入した
- 正当なワークロードを模倣したシャドーインフラストラクチャを構築した
- スナップショットとレプリケーションを用いた、静かで段階的なデータ漏洩を実行した
- AIサービスを継続的に利用し、コストの乱用を通常の使用に溶け込ませる
- 接続されたAWSアカウントまたはSaaSプラットフォームへ移行
これらの行動はいずれも追加の攻撃手法を必要としない。必要なのは時間だ。8分間は単なる入り口に過ぎなかった。
侵害後の検知の緊急性
衝撃が起きる頃には、予防はすでに失敗している。
防御価値は攻撃チェーンのより早い段階で移行する。特権昇格や永続化によって攻撃者の制御が固定される前に。
攻撃の完全な連鎖は長いものの、防御側は攻撃フローにおける重要なステップの縮小セットに集中できる：
- 広範かつ迅速なサービス横断型偵察
- 既存のラムダ関数の変更
- 管理者アクセスのプログラムによる作成
- 永続的なIAMアイデンティティの確立
- クラウドネイティブ機構によるデータの外部化
これらは、連続して見ると通常の使用パターンから著しく逸脱した行動である。
課題は相関である。
ほとんどのクラウドセキュリティ制御は設計上静的であり、意図の検知に苦労している。
この事件において：
- 認証情報は有効でした
- APIは設計通りに使用された
- 権限は正当に存在していた
唯一の異常は時間の経過に伴う行動であった。
これが、高速でAI支援された攻撃が利用する検知のギャップである。
なぜアイデンティティ中心の振る舞い が必要なのか
攻撃が機械の速度で動くとき、検知も同等のレベルで動作しなければならない。
これは理解を必要とします：
- 人間、機械、および能動的アイデンティティが通常どのように振る舞うか
- サービスが通常どのように利用されるか
- どのような行動の連鎖が典型的または珍しいのか
- 制御が攻撃者に移ったとき、行動がどのように変化するか
アイデンティティ中心の検知は、クラウド上のアイデンティティ（人間、非人間、エージェント）を主要なシグナルとして扱う。振る舞い 、それらのアイデンティティがサービスや環境を横断してどのように動作するかをモデル化する。
偵察が加速した時、ラムダ行動が変化した時、権限が予期せず付与された時、それらの変化はリアルタイムで検知される。
特権昇格が不可逆的になる前に攻撃を中断する唯一の実用的な方法である。
Vectra AIがこの種の攻撃に対処する方法
ベクトラ Vectra Platform は、まさにこの問題領域のために設計されています。
クラウド制御プレーン、ネットワークトラフィック、SaaSアクティビティ、クラウドワークロードにわたるアイデンティティ行動を分析することで、Vectra 有効なアクセスと自動化に依存する攻撃の初期段階を検知します。
衝撃を待つ代わりに、それは以下に焦点を当てる：
- 偵察パターン
- 特権の乱用
- 横方向の動き
- データの不正利用
管理者のアクセス権限が数分で侵害される可能性がある場合、自動応答は選択の余地がない。アクセスからエスカレーションまでの狭まる時間枠内で行動する唯一の手段である。
この事件は期待値をリセットすべきである。
8分という時間はもはや例外ではない。これは、アイデンティティが悪用され、防御が静的な前提に依存する状況下で、自動化がもたらす結果である。教訓はAIを恐れることではない。攻撃者が既にAIを活用し、タイムラインを圧縮し、躊躇を排除し、意思決定を拡大している事実を認識することだ。
防御側は同等の対応をしなければならない：検知は振る舞いでなければならず、防御範囲はアイデンティティ中心でなければならず、対応は自動化されなければならない。
クラウド管理者のアクセス権限がAIの速度で失われると、事後的にアラートを組み立てる時間すら残されていないからだ。