AIサイバー攻撃の実例｜AIエージェントがクラウド・K8s・CI/CDを渡り歩いた侵入と、防御側の見つけ方

AIサイバー攻撃が「AIで作ったフィッシング文」の段階を越えて、侵入の全工程を回す段階に入った実例が公表されました。クラウドのインシデント対応を行う Wiz CIRT（Customer Incident Response Team）が2026年10月19日に公開した「Loud, Fast, and Everywhere: Anatomy of a Real AI-Driven Cloud Attack」です。

原文によると、ここ数週間の複数の調査で、AI エージェントが入口を探し、認証情報を集め、基盤をまたいで移り、自分のスクリプトをその場で直しながら最後まで回していました。

まずやること

・クラウドと Kubernetes の運用者：CloudTrail（GCP なら Cloud Audit Logs）、Kubernetes の監査ログ、IdP のログを同じ場所・同じ保持期間で検索できるかを確かめ、後半の確認コマンドを手元のログで流す
・外部公開の担当：Kafka UI のような開発者向けの管理画面がインターネットから開けないかを棚卸しする
・侵入の疑いがある資源の担当：その資源から読めた秘密は、読まれた証拠が無くてもすべて差し替える前提で動く

セキュリティ全体の地図は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 にまとめています。本記事は攻撃の再現手順を書かず、各段で「何が起き、どのログに何が残り、どう切るか」を防御側から整理します。Wiz は観測した当事者で、事実の出典はすべて同社のブログです。

AIサイバー攻撃の8つの特徴：人の操作ともスクリプトとも違う

原文は、スクリプトは決めた手順をそのまま流し、人は遅く順番に進めるのに対し、AI エージェントは機械の速さと状況に応じた判断を併せ持つと整理しています。

| 特徴 | 原文の観測 | 防御側の着眼点 | |—|—|—| | 速度 | 毎時数百〜数千の操作。休止や勤務時間の偏りが無いまま長く続く | 主体ごとの操作数を分単位で数える | | 複数の基盤を同時に | 同じ送信元・同じ時間帯に、クラウドの列挙、K8s へのデプロイ、CI/CD のパイプライン作成、DB の照会 | 別々のログを時刻と送信元 IP で突き合わせる | | 各基盤の API を使いこなす | クラウド、コンテナ、CI/CD、DB、IdP、メッセージキューの純正の API とツールを使う | 見慣れないツールより、見慣れない主体による純正 API の呼び出しを見る | | 認証情報の連鎖 | K8s の SA トークン → クラウドの SA → CI/CD → 管理者権限 | 1つの秘密の漏れを、その先の全基盤の問題として扱う | | 素早い試行錯誤 | 失敗するとエラーを読み、スクリプトを書き直して数分で再試行 | 同じ主体の拒否の直後に続く成功 | | 検査風の命名 | pentest・probe・recon・redteam・exfil。原文は、正規の検査に見せて AI モデルの安全装置をすり抜ける狙いだろうと推測している | 名前で拾えるが、攻撃者は変えられる | | 数字のタスク ID | 関連する資源・ユーザー・ファイルに同じ数字。失敗した試行は -b・-c・-d の接尾辞で再試行 | 同じ数字で関連する痕跡をまとめる | | 生成コードの癖 | 説明的なヘッダー、番号つきの手順コメント、同じ補助関数を数十のペイロードで再利用 | 回収したスクリプトどうしを比べる |

AIサイバー攻撃の実例：Kafka UI から Kubernetes まで認証情報を乗り継いだ流れ

原文が述べる順に、段ごとの出来事と、防御側に残る記録を並べます。各段の「切る手」は一般的な対策で、この件の原因の説明ではありません。

入口：公開されたサービスを片端から試した

既知の脆弱性、クラウドストレージへの匿名アクセス、公開されていた社内向け開発者ツールの API（管理者の作成、パスワードの再設定、パストラバーサル）を試しました。確認された入口の1つは、公開されていた Kafka UI の Java のリモートコード実行の脆弱性です。Java プロセスからシェルが起動し、マルウェアの設置と C2（遠隔操作の通信路）が続きました。同じ送信元 IP は同じ期間に600を超える他の Wiz 顧客の環境も走査していました。

ワークロード：SA トークン・環境変数・IMDS

複数のクラスタのポッドにバックドアと C2 のエージェントを置き、マウントされた Kubernetes の SA（サービスアカウント）トークンを取り出しました。環境変数から token・secret・key・pass を含む値を探し、IMDS（インスタンスのメタデータサービス）からノードに付いたクラウドの SA の認証情報を取得しています。さらに社内のメッセージブローカー、スキーマレジストリ、DB を走査しました。

ここで動くのはポッドの中のプロセスと通信なので、クラウドの制御面のログには出ません。IMDS を外から読ませる型の攻撃（SSRF）の仕組みは SSRFとは｜サーバーに内側を叩かせる攻撃の仕組みと、素朴なブロックリストが破られる理由・正しいSSRF対策 で扱いました。

クラウドの制御面：GCP のトークン発行と AWS の OrganizationAccountAccessRole

GCP では、トークン作成の権限を持つ SA を使い、数十の ID の認証情報を次々に発行しました。コンテナレジストリを繰り返し取得し、DB の重要なレコードの持ち出しを試み、pentest- で始まる一般公開の Cloud Run サービスを置いています。

AWS では、Systems Manager（SSM）で複数のインスタンスにコマンドを実行し、奪った認証情報で DB への接続を試み、SSH で横に移りました。持ち出しの準備に pentest-<task_id> という名前のバケットを使っています。アカウントをまたいで居座るために probe で始まる IAM ユーザーを作り、そのユーザーで OrganizationAccountAccessRole を引き受けて、AWS Organizations のメンバーアカウントの管理者権限を得ました。残る記録は CloudTrail と Cloud Audit Logs です。

IdP：管理者 API キーで「内部の人」になった

奪った IdP の管理者 API キーで、pentest で始まるユーザーを作って有効化し、管理者グループと、AWS IAM Identity Center のロールに対応するグループに入れました。最後のグループ変更から数分で、この ID は SSO で AWS にサインインし、アカウントが停止されるまでセッションを保ちました。残る記録は IdP のシステムログと、AWS 側のサインインの記録です。

CI/CD と GitOps：ランナーの出力ログを持ち出しに使った

CI/CD では、秘密の収集、到達範囲の調査、認証情報の総当たり、サービスの悪用、計算資源の拡大の5つを並行させ、新しい認証情報は既知のすべての標的で試しました。奪った SA でパイプラインを作り、既存のランナーが届くクラスタ・クラウドアカウント・VPC を利用しています。ランナー自身の出力ログが秘密とデータの持ち出し経路になりました。

GitOps では、奪ったデプロイ用の SA が悪意のある Kubernetes マニフェストを push し、GitOps コントローラが本番クラスタに同期しました。最初のマニフェストで cluster-admin に昇格しています。のちに GitOps コントローラを直接操作して稼働中のワークロードを変え、Git の履歴には跡が残りませんでした。この改変はリポジトリを見ても分からないので、Kubernetes の監査ログとコントローラのログで追います。

Kubernetes：secrets が拒否されると ConfigMap へ

CI/CD のランナー、GitOps のデプロイ、IdP に作った裏口の ID という3つの経路で Kubernetes の API に届きました。クラスタをまたいで secrets（DB の接続文字列、OAuth のクライアント認証情報、TLS 証明書、クラウドの SA の鍵）を取得し、RBAC に拒まれると ConfigMap に移って、ハードコードされた既定のパスワードや平文の認証情報、暗号鍵を拾っています。ポッドに exec して環境変数を読み、IMDS でポッドの ID をクラウドの認証情報に変えました。

cluster-admin を得たあとは SA トークンを発行して正規のアプリになりすまし、シークレットの保管庫への認証を試みました。C2 は消されても戻るワークロードとして常駐させています。

持ち出し：webhook.site・自社のソース管理・ConfigMap

経路は、リクエストを受け取って表示する外部サービス webhook.site（原文の表記は webhook[.]site）、組織自身のソース管理のリポジトリへのコミット、ConfigMap への一時置きです。pentest-<task-id>-<objective> という名前のバケットの作成は拒否され、経路が失敗したりサイズの上限に当たったりすると次に移っています。回収されたスクリプトの1つは、DB の列名から機微な語を探し、結果をポッド自身の SA トークンと一緒に webhook.site へ送っていました。トークンは「後で足場に再利用するため」だと原文は書いています。

防御側の対策：IMDSv2・トークン発行権限・OrganizationAccountAccessRole で環境間の信頼を絞る

原文の推奨は5つです。原文は推奨の多くに自社製品を添えていますが、本記事では製品名を省き、どの製品でも実行できる形に直しました。

・クラウド・Kubernetes・IdP・CI/CD・SaaS の監査ログと実行時のイベントを1か所に集め、同じ保持期間で検索できるようにする
・侵害された資源の秘密は、どれが読まれたかを辿るより全部差し替え、秘密ごとの ID について侵害の時刻以降の使われ方を洗う
・制御面のログに出ない、ランナー・VM・コンテナの中のプロセス・通信・ファイルアクセスを見る
・環境間の信頼を絞り、ステージングから本番の認証情報に届かない、パイプラインが全環境への常設のアクセスを持たない、1つの SA が任意の ID のトークンを作れない形にする
・開発者向けツール、管理画面、社内アプリが外から開けないかを継続して調べる

差し替えの初動は アクセスキー漏洩を防ぐ｜開発用クラウドの長期キーをやめ、漏れても使えず気づける形にする手順と、漏れた最初の1時間 にまとめています。

攻撃者が得たものごとに、一般的に効く手を並べます。設定名は公式ドキュメントで確かめた範囲で、この件で各設定がどうだったかは原文にありません。

IMDSv2 はトークンを PUT で取ってからでないとメタデータを読めない方式です。外から URL を読ませる攻撃には効きますが、ポッドの中でコードを実行できる攻撃者は自分でトークンを取れます。PUT 応答のホップ数の上限は既定で1で、AWS はコンテナから使うために引き上げが要る場合があると説明しています。ポッドから IMDS を使わない構成なら、引き上げていないかを確かめてください。

OrganizationAccountAccessRole は、組織の中で作ったメンバーアカウントに AWS Organizations が自動で作るロールで、管理アカウントの利用者に管理者の権限を与えます。招待で参加したアカウントには自動では作られません。Kubernetes の監査ログについては、公式ドキュメントの監査ポリシーの例が secrets と ConfigMap を Metadata レベルで記録しています。中身を残さずに、誰がいつ読んだかを残す設定です。

自システム確認コマンド：CloudTrail・K8s監査ログ・プロキシで痕跡を拾う

読み取りだけの確認です。原文が挙げた命名と操作の痕跡を、手元のログから拾います。jq 1.7 と自作のダミーログ（CloudTrail 形式6件、Kubernetes 監査ログ108行、プロキシと DNS のログ）で、拾うべき行を拾うこと（陽性対照）と無関係な行を拾わないこと（陰性対照）を確かめました。

まず CloudTrail です。S3 から落とした .json.gz を展開し、そのディレクトリで実行します。

# 1) 検査風の名前で始まる IAM ユーザー・ロール・アクセスキー・バケットの作成（拒否された試行も出す）
cat ./*.json | jq -r '
  .Records[]
  | select(.eventName == "CreateUser" or .eventName == "CreateRole"
           or .eventName == "CreateAccessKey" or .eventName == "CreateBucket")
  | (.requestParameters.userName // .requestParameters.roleName
     // .requestParameters.bucketName // "") as $n
  | select($n | test("^(pentest|probe|recon|redteam|exfil)"; "i"))
  | [.eventTime, .recipientAccountId, .eventName, $n, .userIdentity.arn,
     .sourceIPAddress, (.errorCode // "OK")] | @tsv'

# 2) OrganizationAccountAccessRole の引き受け（誰が、どのメンバーアカウントへ）
cat ./*.json | jq -r '
  .Records[]
  | select(.eventName == "AssumeRole"
           and ((.requestParameters.roleArn // "") | endswith(":role/OrganizationAccountAccessRole")))
  | [.eventTime, .recipientAccountId, .userIdentity.arn, .sourceIPAddress,
     (.errorCode // "OK")] | @tsv'

陽性対照では probe-4821 の作成とアクセスキーの発行、拒否された pentest-4821-b-dump の作成、OrganizationAccountAccessRole の引き受けが出ました。陰性対照（途中に語を含む ci-reprobe、pentest で始まるバケットの読み出し、別のロールの引き受け）は何も出ませんでした。

次に Kubernetes の監査ログ（JSON lines）です。パスは自分の環境に置き換えます。

AUDIT="/var/log/kubernetes/audit/audit.log"

# 1) secrets・configmaps の読み出しを「分 × 主体 × 種類」で数える（多い順）
jq -r 'select(.stage == "ResponseComplete"
         and (.objectRef.resource == "secrets" or .objectRef.resource == "configmaps")
         and (.verb == "get" or .verb == "list" or .verb == "watch"))
       | [.requestReceivedTimestamp[0:16], .user.username, .objectRef.resource] | @tsv' "$AUDIT" \
  | sort | uniq -c | sort -rn | head -20

# 2) pods/exec と、ClusterRoleBinding の作成・変更
jq -r 'select(.stage == "ResponseComplete"
         and ((.objectRef.resource == "pods" and .objectRef.subresource == "exec")
              or (.objectRef.resource == "clusterrolebindings"
                  and (.verb == "create" or .verb == "update" or .verb == "patch"))))
       | [.requestReceivedTimestamp, .user.username, .verb, .objectRef.resource,
          (.objectRef.subresource // "-"), (.objectRef.namespace // "-"),
          (.objectRef.name // "-"), (.responseStatus.code | tostring)] | @tsv' "$AUDIT"

陽性対照では、1分間に40件の secrets 読み出しと25件の ConfigMap 一覧を行った CI ランナーの SA が上位に出て、ポッドへの exec と ClusterRoleBinding の作成も出ました。stage を絞っているので、同じ要求の受付時の行は二重に数えません。陰性対照（人が3分に分けて1件ずつ読んだ、ポッドのログを取得した）では、1は1分あたり1件の行が並ぶだけで、2は何も出ませんでした。

最後に、外への送信と、クラスタ上の命名です。

# 1) プロキシ・DNS のログから webhook.site への通信（サブドメインを含む）。パスは自分の環境に置き換える
grep -rhiE '(^|[^a-z0-9-])webhook\.site' /var/log/squid/ /var/log/dns-query/

# 2) 検査風の名前で始まるワークロードと ConfigMap（読み取り権限のある kubeconfig で実行）
kubectl get pods,deployments,daemonsets,cronjobs,configmaps -A \
  -o jsonpath='{range .items[*]}{.kind}{"\t"}{.metadata.namespace}{"\t"}{.metadata.name}{"\n"}{end}' \
  | awk -F'\t' 'tolower($3) ~ /^(pentest|probe|recon|redteam|exfil|harvest|foothold)/'

grep は Squid 形式の CONNECT webhook.site:443 と、DNS クエリログの "query_name":"webhook.site." を拾い、mywebhook.site や URL の中の webhook-site は拾いませんでした。kubectl の行は実際のクラスタでは動かしておらず、未検証です。awk の絞り込みだけを、種類・名前空間・名前をタブで区切った模擬の出力で確かめました。

結果の読み方には限界があります。

・出ても侵入とは限らない。社内の検査チームが同じ命名を使うことがあり、管理アカウントの管理者が OrganizationAccountAccessRole を正規に使うこともある。誰の操作かを、許可した作業の記録と突き合わせる
・出なくても安全とは限らない。名前は攻撃者が変えられる。ログの保持期間より前の操作、記録していない監査レベル、webhook.site 以外の受け取りサービスは見ていない
・GKE の監査ログは Cloud Logging の形式で、上の jq はそのままでは使えない（未検証）。EKS などで別の場所に送っている場合も、1行1イベントの JSON に戻してから使う

影響範囲：この観測報告から言えること・言えないこと

時系列

・ここ数週間：Wiz CIRT が複数の調査で、AI 主導の侵入が増えている傾向を観測（原文）
・公表日 2026年10月19日：Wiz がブログで事案の分解と防御側の推奨を公開
・2026年10月20日：本記事の確認日

影響を受ける条件

特定の製品の脆弱性ではなく、侵入の進め方の報告です。原文から読める条件は、外から開ける開発者向けツールがあること、ワークロードから届く認証情報が別の基盤への足場になること、トークン作成・アカウント横断のロール・GitOps のデプロイ用 SA のような環境をまたぐ強い信頼があることです。Kafka UI の脆弱性の識別番号や影響版は原文に書かれていません。

原文が書いていないこと

被害組織の名前・業種、攻撃者の正体、使われた AI モデルやツールの名前、被害の規模は書かれていません。AI による攻撃の別の報告としては ARTEXとは｜AI自律型ペネトレーションテストツールの悪用と、Shodanから消える偽装ゲート で CrowdStrike の報告を扱いましたが、本件と同じものかどうかは原文からは分かりません。

参照ソース

• Wiz CIRT「Loud, Fast, and Everywhere: Anatomy of a Real AI-Driven Cloud Attack」（2026-10-19）（事案の流れ・特徴・推奨の出典）
• Amazon EC2「Modify instance metadata options for existing instances」
• Amazon EC2「How Instance Metadata Service Version 2 works」
• AWS Organizations「Accessing a member account that has OrganizationAccountAccessRole」
• AWS Organizations「Creating OrganizationAccountAccessRole for an invited account」
• Google Cloud IAM「Roles for service account authentication」
• Kubernetes「Configure Service Accounts for Pods」
• Kubernetes「Auditing」