Wizは2026年10月19日、実際のAI駆動クラウド攻撃の調査結果を公表しました。同社によると、最近の複数の侵入では、自律的に処理を進めるAIエージェントが攻撃全体を実行していました。認証基盤、クラウド、開発基盤に痕跡が分かれるため、一つのサービスのログだけでなく、複数の記録を突き合わせることが確認の焦点です。
失敗を修正し、複数の基盤で攻撃を継続
Wizの顧客インシデント対応チームは、過去数週間の調査でAI駆動攻撃の増加を観測しました。活動量は1時間に数百～数千の操作に達する場合があります。AIエージェントは複数の基盤を同時に操作し、失敗するとエラーを読んでスクリプトを修正し、数分以内に再試行していました。
詳しく分析した事例の標的は、大規模なマルチクラウド環境、つまり複数のクラウドを使う組織でした。侵入経路の一つは、外部公開されたKafka UIにある、Javaのコードを遠隔から実行できる脆弱性です。侵入後も別の入口を探すスキャンは続いていました。同じ送信元IPは、同時期に他の600超の顧客環境もスキャンしていたといいます。この数は、侵害された組織の数を示すものではありません。
今回の公表は攻撃の調査結果です。日本でのサービス提供については、発表には書かれていません。
認証情報を集め、クラウドと開発基盤へ展開
攻撃者は、コンテナを管理するKubernetesのサービスアカウントトークンや環境変数から秘密情報を収集しました。その後、被害組織のGCPとAWSの両環境で活動しています。
GCPではトークン作成権限を悪用し、数十のIDの認証情報を連続生成しました。AWSではSystems Managerを使い、複数のインスタンスでコマンドを実行しています。
認証を担うIdPの管理者APIキーも悪用されました。攻撃者はユーザーを作成して管理者グループに追加し、そのIDはグループ変更から数分以内に、シングルサインオン(SSO)でAWSへサインインしました。ユーザー作成、権限変更、クラウドへのサインインを一連の動きとして調べる必要があります。
また、ソフトウェアのテストや配布を自動化するCI/CDが、攻撃の主要な実行基盤に使われました。処理を実行するランナーの出力ログは、秘密情報やデータの持ち出し経路にもなっていました。開発基盤は侵入後の操作場所だけでなく、情報を外へ出す経路としても確認対象になります。
影響する会社・しない会社
- 影響する: Kafka UIを外部公開している会社です。分析事例では、そのJava遠隔コード実行脆弱性が侵入経路の一つでした。ただし、対象バージョンや修正版は発表には書かれていません。
- 影響する: AWSやGCP、Kubernetes、IdP、CI/CDを組み合わせて運用する会社です。分析事例では、各基盤の認証情報や権限を使った攻撃が確認されています。
- 影響しない: 上記の基盤を使っていない会社には、該当する製品・機能の確認作業は当てはまりません。ただし、AI駆動攻撃の対象外と判断できる条件は、発表には書かれていません。
情シスが今日やること
以下は、この事例を踏まえた確認手順です。発表に一律の対応期限は示されていないため、まず本日中に担当者と確認範囲を決めます。
- 外部公開サービスの担当者にKafka UIの有無を確認します。 利用していれば、公開設定と利用バージョンを記録します。修正版の情報は今回の発表だけでは判断せず、製品の公式情報で確認してください。
- IdP管理者とAWS担当者に、認証の記録を突き合わせてもらいます。 ユーザー作成、管理者グループへの追加、SSOでのAWSサインインを、時刻とIDでつなげて確認します。個別の操作だけで判断しないことがポイントです。
- GCPとAWSの操作ログを各担当者に確認してもらいます。 GCPではトークン作成、AWSではSystems Managerによるコマンド実行を調べ、承認された作業と照合します。発表には具体的な管理画面の名称やメニューの場所は書かれていません。
- 開発担当者にCI/CDの実行履歴とランナーの出力ログの確認を依頼します。 覚えのない処理や秘密情報の出力がないかを調べます。不審な記録があれば、認証・クラウド担当者にも共有し、同じ時刻の操作を確認します。
