AI支援で8分、AWS管理者権限まで到達——公開S3の資格情報から始まる連鎖侵害の現実

今日の深掘りポイント

• 生成AIは「新しい攻撃」を生んだのではなく、既存のクラウド攻撃ワークフローを分単位に圧縮し、誤設定×資格情報露出を「時間との戦い」に変換した事例です。
• 19プリンシパル/14セッション/6ロールという広がりは、ロール連鎖と信頼ポリシーの甘さを自動探索・自動実行した可能性を示唆します。個別の最小権限だけでは止まらない層（SCP、Permission boundary、条件付きアクセス）の整備が要諦です。
• 8分のキルチェーンは、人手の初動やチケット駆動運用を置き去りにします。検知から隔離・無効化までを自動化し、分単位SLAで“燃え広がり前”に踏み消す設計が必要です。
• 振る舞い検知の肝は「短時間・多ロールAssumeRole」「GetCallerIdentity/権限列挙のスパイク」「SimulatePrincipalPolicyの濫用」などの連続性です。単発のS3やIAMイベントでは見抜けません。
• 攻撃者の裾野拡大は避けられず、地政学的リスクの土台にもなります。いま求められるのは、“踏まれても伸びない”クラウド地形（組織SCP、条件付き信頼、キー無効化の自動修復）です。

はじめに

クラウドの守りは「発見→分析→対応」の順番で動きがちですが、攻撃は順番を待ちません。公開S3から拾った“たまたま生きていた”テスト用資格情報を起点に、AIで各工程を自動化し、8分で管理者権限に到達——この圧縮率は、境界の在り方そのものを問い直す出来事です。問題はAIそのものよりも、誤設定と過剰な信頼関係が可視化され、誰でも高速でなぞれる時代に入ったことにあります。今日のPickUpでは、この事例の骨格を押さえたうえで、組織が今すぐ変えるべき“設計”に絞って掘り下げます。

深掘り詳細

事実関係の整理（報道ベース）

• 2026年2月4日、Sysdigの脅威研究チームが、AWS環境への侵入がAI支援により約8分で管理者権限獲得に至った事例を報告しました。起点は「公開S3バケット内の有効なテスト用認証情報」でした。攻撃者はこの後、19のAWSプリンシパルを侵害し、14のセッション（うち6つはIAMロール）を実行したとされています。The Registerの報道がこれらの数値を伝えています。
• Sysdigは対策として、IAMの最小権限原則の徹底とS3公開アクセスの制限を推奨しています。同報道は、工程の自動化に生成AI（LLM）が利用された点を強調しています。
• 本稿は現時点で公開報道に基づく整理であり、一次資料の技術詳細（具体的なAPIコール系列やポリシー内容）は未確認のため、以降の技術推論は仮説として明示します。

出典： The Register

インサイト：スピードの正体は「権限グラフの自動走査」

• 速さは偶然ではなく構造です。公開S3からの資格情報流出という“古典”に、権限・信頼関係（AssumeRoleや信頼ポリシー、外部ID、組織条件など）をグラフとして探索し、昇格・横展開の最短路を自動選択するAI/スクリプトが噛み合うと、探索と実行の往復が人手の思考速度を上回ります。
• 19プリンシパル/14セッション/6ロールという広がりは、次のような自動化を示唆します（仮説）：
  • 初動でGetCallerIdentityやList*系を用いて足場の特性を素早く把握。
  • SimulatePrincipalPolicy/Policy Evaluationで“今できること”を評価し、AssumeRoleで到達可能な頂点を探索。
  • 役割切替を連鎖させることで、最短で管理者相当権限に到達。
• つまり「AIが新しい侵入口を発明した」のではなく、「人手だと数十分〜数時間かかる権限探索と意思決定」を分単位に圧縮した結果だと読み解けます。守る側は“露出×信頼×自動化”の三点セットを前提に設計を変える必要があります。

現場への示唆：検知も対応も“分単位SLA”で設計する

• メトリクス上、本件は新規性・即時性・実装可能性がいずれも高いタイプで、同種事案の再現性も高いと見ます。対策は「導入しやすさ」より「発火後の拡散をどこで切るか」を優先すべきです。
• 実務上のボトルネックは、CloudTrail/データイベントの量と相関解析にあります。攻撃は「短時間・多セッション・多ロール」という特徴を持つため、単一イベントの閾値ではなく、時系列・関係性の異常（例：短時間に多回のAssumeRoleとGetCallerIdentity、直後の権限評価APIの集中）でトリガーし、自動でキー無効化/ロール信頼の一時遮断/セッション失効まで持っていく必要があります。
• 「最小権限」だけでは足りません。ロール連鎖を前提にした“昇格不能の地形”づくり（SCP/Permission boundary/信頼ポリシーの条件化）と、“踏まれても自動で閉じる機構”の両輪が要ります。

脅威シナリオと影響

以下は、報道情報を土台にした一般化シナリオの仮説です。MITRE ATT&CK（Enterprise/Cloud）に沿って整理します。

• 初期侵入（Initial Access）
  • 公開S3からの資格情報取得（Credential Access/Unsecured Credentials）
  • 既存の有効アカウントの悪用（Valid Accounts/Cloud Accounts）
• 実行・偵察（Execution/Discovery）
  • AWS CLI/SDKでの即時実行、GetCallerIdentityや各種List*でクラウド資産・権限の列挙（Cloud Service Discovery）
• 権限昇格・防御回避（Privilege Escalation/Defense Evasion）
  • sts:AssumeRoleの連鎖、信頼ポリシーの甘さ（条件なし/外部ID未使用/組織条件なし）の悪用
  • 必要に応じたポリシー付与/バージョン操作や、ログ設定の変更（Disable/Modify Cloud Logging）
• 横移動（Lateral Movement）
  • 複数ロール/アカウント間のピボット（Trusted Relationshipの悪用）
• 永続化（Persistence）
  • 追加のアクセスキー発行、ロール/ユーザーの作成・信頼設定変更（Account/Role Manipulation, Create Cloud Account）
• 収集・流出（Collection/Exfiltration）
  • S3/DB/Secretsの読み出し、外部送信（正規チャネルの利用）
• 影響（Impact）
  • データ窃取、CI/CD・アカウント乗っ取り、サプライチェーンへの波及、費用リスク（リソース悪用）など

ポイントは、AssumeRoleと信頼ポリシー設計に依存する「権限グラフ」の地形です。AIはこの地形を高速になぞる“移動力”を与えます。よって、被害規模は“最初の鍵の強さ”より“地形の登りやすさ”で決まることを前提に、影響評価を行うべきです。

セキュリティ担当者のアクション

“いま変えられる設計”を優先順位で並べます。可能な限り、自動化と組織スコープを絡めてください。

• ただちに（今週中）

  • S3公開の全面棚卸しと強制ブロック
    • アカウント/組織レベルのパブリックアクセスブロックを有効化し、例外は明示的承認フローにします。
    • バケットポリシーは原則「aws:PrincipalOrgIDで組織内限定」「明示denyでパブリック禁止」を徹底します。
  • 露出資格情報の駆除
    • S3/コード/イメージ/CIログのシークレット走査を回し、発見即ローテーションと失効を自動化します。
  • 分単位の自動隔離パスを用意
    • 短時間に多回のAssumeRoleやGetCallerIdentity、SimulatePrincipalPolicyなどの連続検知で、該当アクセスキーの無効化、該当ロールの信頼ポリシー一時封鎖、セッション失効を自動実行します。
  • 信頼ポリシーの“穴”塞ぎ
    • sts:AssumeRoleは原則、外部ID/ソースVPCエンドポイント/PrincipalOrgIDなどの条件で限定します。相互信頼や無条件信頼は即廃止します。

• 近々（今四半期内）

  • 組織の最上位で昇格不能の地形を作る
    • SCPで過剰権限の自己付与（iam:CreatePolicyVersion/iam:PutUserPolicy/iam:PassRoleの野放図化など）をブロックします。
    • Permission boundaryを必須化し、「どれだけ踏まれても管理者相当権限に到達しない」上限を設計します。
  • 長期キーの撲滅とセッションの可視化
    • 人にはSSO（短命トークン/MFA必須）を強制、残るアクセスキーには使用制限（条件付きアクセス、時間/IP/タグ条件）を付与します。
    • sts:TagSessionで人物・用途タグを強制し、無タグ/異常タグのロール切替を遮断します。
  • ふるまい相関の検知整備
    • 「短時間・多セッション・多ロール」「権限列挙→AssumeRole→権限評価→設定変更」の時系列相関をルール化し、コンソール/CLI双方を対象にします。

• 中期（恒久対策）

  • ITDR（Identity Threat Detection & Response）の導入
    • IAMイベントを一次級の脅威テレメトリとして扱い、事前のリスクスコアリング（信頼ポリシー健全性、横展開可能性）と事後の自動封じ込めを統合します。
  • セキュリティ・バイ・デザインの実装
    • IaCにポリシー・アズ・コードを組み込み、S3公開や信頼条件の逸脱をパイプラインで強制不許可にします。
  • ハニートークンで“初動”の可視化
    • ダミーのAWSキー/ロールや蜜壺S3を配置し、触られた瞬間に高優先度アラート＋自動封鎖が動く仕組みを組み込みます。
  • 演習：8分シナリオの赤青対抗
    • 「公開S3→資格情報取得→AssumeRole連鎖」の模擬演習を定期化し、検知〜自動隔離までのSLAを5分未満に収める運用を検証します。

最後に。AIは攻撃の“発明家”ではなく“高速運転手”です。守りが問われるのは、速度に追いつくことではなく、スピード違反ができない道路を敷くことです。公開の是非、信頼の設計、そして自動で閉じる仕組み——この3点を、今日から変えることができます。

参考情報

• The Register: AWS cloud break-in reportedly took under 10 minutes with AI assist（2026-02-04） https://go.theregister.com/feed/www.theregister.com/2026/02/04/aws_cloud_breakin_ai_assist/