要点
- 外部サービス Qubole のために作った AWS の「入口」が、Qubole 側の AWS アカウントの認証情報を手に入れた攻撃者に使われた。
- Wiz の報告では、入られた AWS 環境で、パスワードや API キーなどの秘密情報と S3（データ置き場）の中身が盗まれた。
- 使わなくなった連携の入口を残している組織ほど、気づかないまま入られるおそれがある。
何が起きたか
Wiz が 2026 年 11 月 9 日に報告した。The Register もこれを報じている。
話題の見出しには「部品に裏口」とあった。だが Wiz の報告にそういう話はない。部品が改ざんされたのではなく、Qubole（クラウドのデータ処理サービス）に関連する AWS アカウントの認証情報が悪用された、というのが Wiz の説明だ。
Qubole のような外部サービスは、利用者の AWS に「このサービスの AWS アカウントからなら入ってよい」という入口（IAM ロール）を作らせて連携する。長く使う鍵を渡さずに済む仕組みだ。攻撃者は、この信頼関係を逆に使った。
Wiz によると、攻撃者は 10 月 14 日から 26 日にかけて、複数の顧客の AWS 環境でこの入口に入った。中では、資源の一覧取得、秘密情報の収集、盗んだ鍵が生きているかの確認、S3 の読み出しをしていた。バケット（データの入れ物）をまるごと取った例もある。Wiz は、狙いを絞らない機会的な盗みと見ている。
秘密情報の中には、Microsoft Entra ID や Okta の認証情報も含まれていた。AWS の外にも被害が広がりうる。
分かっていないことも多い。Qubole 側の認証情報がどう盗まれたかは、報告に書かれていない。被害組織の数や名前も出ていない。攻撃者の正体も不明だ。The Register によると、AWS と Qubole は同誌の問い合わせに応じていない。
別に、10 月 8 日から 11 日には、Qubole 連携用に作られたとみられる顧客自身の AWS キーが一斉に試された。Wiz は、これを上の件と結びつけられていない。
日本の利用者への影響
日本の組織が被害を受けたかどうかは、一次情報（Wiz の報告）からは分からない。被害組織の国や数が明かされていないためだ。Qubole を使っていた、または過去に連携を試した AWS アカウントは、日本でも確認の対象になる。
今すぐやること
- 自社の AWS で、Qubole を含む外部サービスのために作った入口（ロール）が残っていないか、棚卸しをする。
- 使っていない連携の入口は消すか、外部アカウントを信頼する設定から外す。Wiz は、使われていない入口でも攻撃者が入れたと報告している。
- 10 月 1 日以降の操作記録（CloudTrail）で、Qubole 側アカウントからの入室に不審なものがないか調べる。AWS 以外のアドレスからの入室が怪しい。
- 入られた形跡があれば、そのロールで読めた秘密情報をすべて入れ替える。入れ替えただけでは、すでに発行された通行証は切れない。Wiz は、その通行証の取り消しも勧めている。
- 連携用の合言葉（External ID）は秘密ではないので、これに頼らない。接続元アドレスの制限を足すよう、Wiz は勧めている。
背景
外部サービスに自社のクラウドへの入口を渡す作りは、広く使われている。便利だが、相手のアカウントが破られれば、自社の入口がそのまま使われる。2025 年の tj-actions/changed-files の件など、信頼された連携先を経由して秘密情報を盗む攻撃は続いている。使わなくなった連携の入口は、閉め忘れやすい。
技術者向けの詳細
- 一次情報: Wiz「Qubole Cross-Account Access Abused in the Wild」。
- 悪用された AWS アカウント:
805246085872（正規の Qubole 通信にも使われる）。 - IAM ID:
AIDA3W7DIFLYOLTK63SFS（Wiz は、影響を受けた環境でこの IAM ユーザーを、この攻撃者に関する活動以外では観測していない）。AIDAJYRRH5Y3A7AAJM2HW（10 月 18 日から使用。正規通信にも出る）。 - セッション名:
quiam-*。 - 接続元 IP:
57.129.54[.]120、2001:41d0:70d[:]7800::、45.83.220[.]211、185.209.199[.]73、89.37.63[.]175。後ろ 3 つは Mullvad VPN 経由で、共有のため単独では決め手にならない。 - 確認する期間: 2026-10-01 以降の CloudTrail。
- 見る条件:
AssumeRoleでuserIdentity.accountIdが上のアカウント、かつ送信元が AWS 以外。principalIdが上の 2 つ。- IOC の IP からの操作。
- TruffleHog の User-Agent による
GetCallerIdentity。
- 入室後に見る対象: 見つけたロールセッションごとに、その後の操作を調べる。特に Secrets Manager、SSM Parameter Store、Lambda、S3（Wiz の勧め）。
- 対策（Wiz）: 信頼元を
:rootから特定の principal に絞る。aws:SourceIpまたはaws:SourceVpceを足す。External ID はロールごとに変える。組織全体の trail を有効にし、重要な S3 はデータイベントも記録する。 sso_agent.iso（SHA-25665f061281c9a712e9502793dc4c5035cae490b84da05f7d4223cefa65ad396e4）は、Wiz が配備を確認できていないファイル。
