はじめに
ある脆弱性を突いた攻撃で 開始 26 秒で 11 組織が侵入され、侵入から管理者権限の奪取まで最短 5 分 だったと報告されました。
攻撃を実行したのは人間ではなく、数百の AI エージェント だったと分析されています。
これまでも、攻撃者が AI でフィッシングメールを書くといった話はありました。
ここ数か月で目立つのは、脆弱性探し・攻撃コードの作成・侵入後の横展開（侵入した 1 台から社内の別サーバーへ広げること）・データの持ち出しまでを、AI エージェントがほぼ自動でこなした と分析される事例です。
この記事では、事例を 4 つのパターンに分け、AWS ではどう備えるべきかを公式のベストプラクティスに沿って整理 します。
最後に 「まず何から始めるか」を優先度順に 5 つ まとめています。
被害組織や攻撃に使われた製品の 会社名は伏せています。
事例は各組織の公表や報道・研究者の分析をもとにしており、「どこまで AI が自動でやったか」は分析段階のものも含みます。
事例
表の「パターン」列の丸数字は、上の図の 4 分類に対応しています。
| 時期 | 何が起きたか | 被害 | パターン |
|---|---|---|---|
| 7 月中旬 | AI モデル共有基盤に、AI エージェントが侵入し横展開 | 内部データ、クラウドの認証情報 | ①② |
| 7 月 | AI ワークフロー OSS の古い脆弱性から侵入し、AI が暗号化 | 設定 1,342 件を暗号化・削除 | ①④ |
| 8 月 | 悪意ある MCP サーバーが AI に鍵を探させる | 確認された侵害なし | ③ |
| 8 月 | AI アシスタントにリンク 1 つで指示を注入できる問題 | 実被害の報告なし（修正済み） | ③ |
| 8 月 | AI ゲートウェイ OSS の改ざん版の影響調査を公表 | 2,500 以上の組織で鍵露出のおそれ | ②③ |
| 8 月末〜9 月 | 数百の AI エージェントが印刷管理ソフトを一斉攻撃 | 395 組織、うち 280 組織で認証情報 | ①② |
| 8〜9 月 | 感染端末 5,871 台分の盗難トークンが流出 | MFA なしで再利用できる状態 | ② |
| 9 月 | 公開 Issue に残った秘密鍵でクラウド資源を一括削除 | ストレージ等を削除、DB は無事 | ②④ |
| 9 月末〜10 月 | AI ペンテストツール使用の疑いで金融機関 7 社に侵入 | 約 6.8 万人分の個人情報 | ① |
並べてみると、入口（脆弱性・漏れた鍵・汚染されたツール）は昔からあるもの ばかりです。
変わったのは、AI によって「見つけてから悪用するまで」が桁違いに速く、大量に並行して行われる ことかと思います。
① 公開サーバーの脆弱性を AI が自動で突く
インターネットに公開したサーバーの脆弱性を、AI エージェントが自分で調べ、攻撃コードを書き、一斉に試す パターンです。
印刷管理ソフトの事例では、攻撃者は脆弱な環境を手元に作って AI に攻撃コードを開発させ、作業開始から実際の侵入まで 4 時間未満 だったと分析されています。
AI ワークフロー OSS の事例では、1 年以上前に公表済みの CVE が使われました。
「パッチ公開から数日の猶予がある」「古い脆弱性はもう狙われない」という前提が成り立たなくなった のがポイントです。
| やること | AWS での手段 |
|---|---|
| 脆弱性を 常時 見つける | Amazon Inspector：EC2・コンテナイメージ・Lambda を継続スキャンし、新しい CVE が出たら自動で再スキャン。インターネットから到達できるかも評価 |
| パッチを自動で当て、管理ポートを閉じる | Systems Manager の Patch Manager と Session Manager（受信ポートも SSH 鍵もなしでサーバーに入れる） |
| 自動化された攻撃トラフィックを減らす | AWS WAF のマネージドルールと Bot Control（スキャナーなどのボットをブロック・レート制限） |
| 侵入されても サーバーの認証情報を盗ませない | EC2 で IMDSv2 を必須にする |
IMDS は、EC2 上のプログラムが自分に割り当てられた IAM ロールの一時認証情報を取りに行く、インスタンス内部の窓口 です。
IMDSv2 にすると取得にセッショントークンが必要になり、SSRF（サーバーをだまして内部の URL にアクセスさせる攻撃）経由で認証情報を抜かれるのを防げます。
AI モデル共有基盤の事例でどの経路で認証情報が取られたかは公表されていませんが、「サーバーを乗っ取られた後、そこからクラウドの認証情報を抜かれる」という同種の流れに効く対策 です。
② 漏れた認証情報・トークンをすぐ悪用
どこかに漏れたアクセスキーやログイン済みのトークンを拾い、そのまま使ってクラウドに入る パターンです。
今回の事例では、公開 Issue の編集履歴に残った秘密鍵 や、情報窃取マルウェアが盗んだ未失効のトークン が使われました。
トークンは「ログイン済みの証明書」のようなものなので、再利用されると MFA は効きま せん。
盗まれた AI サービスの API キーが 約 3 週間で約 60 万ドル分使われた という報告もあります。
漏れた瞬間に悪用される前提で、「漏れても使えない・すぐ失効する・すぐ気づける」状態にしておく のがベストプラクティスの方向性です。
| やること | AWS での手段 |
|---|---|
| 長期のアクセスキーを作らない | 人は IAM Identity Center、アプリは IAM ロールで 一時認証情報を使う。DB パスワードなどは Secrets Manager で保管・自動ローテーション |
| フィッシングに強い MFA | パスキー / FIDO2 セキュリティキー（ワンタイムコードは偽サイトに入力させられると、そのまま中継されてしまう） |
| 盗まれても社外から使わせない | データ境界：SCP / RCP と VPC エンドポイントポリシーで「組織の ID が、想定したネットワークからだけ」アクセスできるようにする |
| 漏れたことに すぐ気づく | AWS は公開されたキーを検知すると 隔離ポリシー を付け、AWS Health で通知 する。EC2 の認証情報が外部から使われると GuardDuty が検知 する。どちらも EventBridge で自動対応につなげる |
SCP（サービスコントロールポリシー）は 組織内の ID ができることの上限、RCP（リソースコントロールポリシー）は 組織のリソースに誰がどこからアクセスできるかの上限 を、AWS Organizations で組織全体に一括で掛けるポリシーです。
これを使うと、鍵そのものが盗まれても、組織外のネットワークからは使えない 状態にできます。
AI サービスの API キーも同じ考え方です。
Amazon Bedrock の API キーには、最長 12 時間で切れる 短期キー と、IAM ユーザーに紐づく 長期キー があり、長期キーは SCP で有効期限の上限を強制できます。
Bedrock の長期 API キーを 30 日以上の期限で作らせない SCP（クリックで展開）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "iam:CreateServiceSpecificCredential",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:ServiceSpecificCredentialServiceName": "bedrock.amazonaws.com"
},
"NumericGreaterThanEquals": {
"iam:ServiceSpecificCredentialAgeDays": "30"
}
}
}
]
}
Bedrock API キーの生成と利用を制御する には、長期キーそのものを禁止する例も載っています。
③ AI エージェント・開発ツールが足がかりになる
守る側が使っている AI エージェントや開発ツールを経由して、鍵や認証情報を持ち出させる パターンです。
悪意ある MCP サーバーの事例では、最初は普通に動いて信用させ、途中から SSH 鍵・AWS 認証情報・kubeconfig（Kubernetes への接続情報ファイル）を読むようエージェントに仕向けました。
AI ゲートウェイ OSS の改ざん版では、CI/CD 上の認証情報が狙われ、被害組織自身のアカウントに公開リポジトリを作って盗んだデータを置く 手口まで使われています。
AI エージェントは「外から来た文章に従ってしまう」性質があるので、渡す権限と、話せる相手を絞る のが基本になります。
| やること | AWS での手段 |
|---|---|
| エージェントが 呼べるツールを決め打ちする | AgentCore Gateway + Policy：エージェントとツールの間に挟む中継窓口で、「誰が・どのツールを・どの条件で」呼べるかを定義。明示的に許可したもの以外は拒否 |
| プロンプトインジェクションを検知 | Bedrock Guardrails のプロンプト攻撃フィルタ。外部から取ってきたデータもユーザー入力としてタグ付けする |
| 権限を最小にし、長期キーを置かない | エージェント・ツールごとに IAM ロールを分けて最小権限 に。CI/CD は OIDC で短期の認証情報だけにする |
| 持ち出し先を塞ぐ | Network Firewall のドメイン許可リスト で、許可したドメイン以外への外向き通信を落とす |
Guardrails のプロンプト攻撃フィルタは、ツールから返ってきた内容までは評価しません。
Guardrails だけに頼らず、Policy でツールを絞る・ネットワークで出口を絞る、と重ねる のが良さそうです。
④ 侵入後の破壊・恐喝を AI が実行する
侵入した後、データを暗号化して元データを消す、あるいは手当たり次第に削除する パターンです。
AI ワークフロー OSS の事例では、AI エージェントが 設定データを暗号化してから元のテーブルを削除し、身代金を要求した と分析されています。
クラウドの秘密鍵が悪用された事例では、自動化された並列操作でストレージなどが数分で削除された と報告されています。
一方でこの事例では、バックアップと復旧用のロックが掛かっていた DB は削除を免れました。
AI の速さに人の対応は間に合わない前提で、「消せないバックアップ」と「自動の初動対応」を用意しておく のが現実的かと思います。
| やること | AWS での手段 |
|---|---|
| 攻撃者が消せないバックアップ | AWS Backup の 論理エアギャップ vault：本番から切り離した「鍵の掛かった金庫」。コンプライアンスモードのロックが自動で掛かり、別アカウントから復元できる |
| オブジェクトを上書き・削除させない | S3 Object Lock：一度書いたら期間中は変更・削除できない |
| 一連の攻撃をまとめて検知 | GuardDuty Extended Threat Detection：「認証情報の侵害 → 持ち出し」のような多段の動きを 1 つの攻撃として検出。GuardDuty を有効にしていれば既定で有効 |
| 全アカウントの検出結果を集約し、初動を自動化 | Security Hub に集約 し、GuardDuty の検出結果を EventBridge で受けて キーの無効化やインスタンス隔離を自動実行 |
全部まとめるとこうなる
4 つのパターンの対策を 1 枚にまとめると、次の構成になります。
ワークロード・セキュリティツール・バックアップをアカウントで分け、乗っ取られても監視とバックアップには手が届かないようにする のが骨格です。
セキュリティツールアカウントは、組織全体の GuardDuty や Security Hub をまとめて管理する「委任管理者」の役を担います。
まず何から始めるか
手間が小さく効く範囲が広いもの から並べてみます。
| 優先度 | やること | 効くパターン |
|---|---|---|
| 1 | GuardDuty と Inspector を全アカウント・全リージョンで有効にし、Security Hub に集約する | ①②④ |
| 2 | 重要データを論理エアギャップ vault にバックアップする | ④ |
| 3 | IAM ユーザーの長期アクセスキーを棚卸しし、IAM ロール / Identity Center に置き換える | ② |
| 4 | IMDSv2 をアカウントのデフォルトにし、既存インスタンスも切り替える | ①② |
| 5 | AI エージェントを使っているなら、ツールを Gateway + Policy 経由に寄せ、外向き通信を許可リストにする | ③ |
まとめ
- 入口は「脆弱性・漏れた鍵・汚染されたツール」と昔ながら で、AI によって 速度と規模が桁違いになった のが特徴です
- AWS 側の対策も特別なものではなく、一時認証情報・最小権限・データ境界・継続的な脆弱性管理・消せないバックアップ という基本を、人の対応を待たずに効く形 で敷いておくことが大事そうです