AIエージェントが通販サイト数百社を攻撃 カード情報60万件超、情シスの点検

米国のセキュリティ会社 Gambit Security が、金銭目的の攻撃者がオープンソースのAIエージェントを使い、数百の通販事業者を攻撃しているという報告を公開しました。確認できた被害は、2社からの60万件超のカード情報の窃取、5社へのスキマーの設置、データの消失です。この記事は、報告の原文の数字を確かめたうえで、国内で通販サイトを持つ会社の情シスが何を点検するかを整理します。

何が報告されたのか

報告の筆者は同社の脅威インテリジェンス責任者の Eyal Sela 氏です。日付は、本文に「2026年9月22日」、ページのメタ情報に公開日・更新日とも「2026年10月8日」と出ています。どちらが最初の公開日かは、ページからは分かりません。

原文が述べている主な事実は次のとおりです。

• 金銭目的の攻撃者が、3つのオープンソースのAI道具(原文では harness)を、数百の通販事業者に対してほぼ無人で動かしている。
• 同社は攻撃者の作業用サーバーを回収し、そこから攻撃の経過を組み立てた。
• 9月10日から15日だけで105件の攻撃プロジェクトが始まり、少なくとも27社が程度の差はあれ侵入された。活動は2026年7月から続いていて、報告の時点でも動いている。
• 確認できた被害は、2社から有効期限が切れていないカード情報60万件超、5社へのカード情報を盗むスキマーの設置、米国の大手ホテル企業・大手航空会社・産業資材の販売会社・ファッション通販などの資産への何らかの接続。
• 侵入できた場合、たいてい1日未満、多くは数時間だった。
• 攻撃者の手順書には、データの削除や片付けの手順が入っていて、実際に一部の侵入先でデータが消えた。

使われた道具は Strix(脆弱性の探索)、Cairn(目標の達成までの自動の攻撃)、Hermes(全体の指揮)です。AIの利用はOpenRouter というサービス経由で、原文は、使われたモデルとして Anthropic の opus-4.6(新しいモデルに断られた後)、GLM 5.2、DeepSeek v4 Pro、DeepSeek v4.1 Flash を挙げています。この記事では、モデルの優劣や製品の紹介には立ち入りません。

費用:1社あたり平均25.46ドル

原文の費用の数字は次のとおりです。

原文は「標的にする費用が数十ドルなら、経済的な理由で狙われない会社はなくなる」という趣旨を述べています。

手口の段階

原文は、1件の完了した攻撃の連なりを例に挙げています。ログイン画面のSQLインジェクションから始まり、ワンタイムパスワードの平文での読み取り、管理画面への入室、画像欄からの任意ファイルのアップロード、サーバー上でのコード実行、管理者権限への昇格、内部のファイル共有からのWordPressの認証情報の取得、AWS Secrets Manager の全件取得を経て、Magento のデータベースにたどり着き、カード番号の暗号化の鍵を取り出して復号を確かめる、という流れです。

原文は、攻撃の道筋は目標ごとにその場で選ばれ、多くが異なる手口になった、と書いています。人が打ち込んだ指示は、全体で1,951件(260セッション)で、1目標あたりは数件だったとのことです。

目標の選び方

原文によると、あるやり方は、サイトの訪問数の順位を出すサービスで買い物の分野を選び、主要なホスト型やオープンソースの通販基盤で動いている店を外して、独自のプログラムの店を残す、というものでした。攻撃者は、そうした店のほうが脆弱だと考えていた、と書かれています。ほかに、管理者のパスワードを手に入れた状態のニュージーランドの小売店や米国の写真印刷会社を、手作業で選んだ例も挙げられています。

カード情報の内訳と、データの消失

60万件超のカード情報について、原文は、不正対策を専門とする Overwatch Data と組んで、カード会社への通知を進めたと書いています。発行国の内訳は、米国が488,372件(79.0%)、アラブ首長国連邦が13,559件(2.2%)、サウジアラビアが6,785件(1.1%)などで、上位12か国と、残りの196か国(64,025件・10.4%)に分けられています。日本は上位12か国に入っておらず、残りの196か国の内訳は原文にありません。

データの消失については、2つの形が書かれています。1つは、攻撃者の手順書に「抜き取りの後にデータベースの該当の欄を消す」という項目があったことです。もう1つは、自転車の小売店で、AIが作業用に「ZQ」で始まる名前の表を作り、片付けの際に「ZQ」か「Backup」を含む名前の表180個を消して、管理者が作っていたバックアップの表も巻き込んだことです。

スキマーはどこに仕込まれたか

スキマーとは、決済ページに仕込まれ、入力されたカード情報を攻撃者に送るスクリプトです。原文は、スキマーの設置を指示した相手が少なくとも27の名前のある被害者で、うち19社で設置を確認し、さらに研究者 Varys の協力で、この活動に関連するスキマーに感染した別のサイトを100超見つけた、と書いています。冒頭の「5社」と後段の「19社」の違いについて、原文は説明していません。この記事では、どちらも原文のまま示します。

仕込み方として原文が挙げているものは、次のとおりです。

• 最も多い方法は、サイトがすでに配っているJavaScriptの末尾に1行足す方法です。jQuery や Bootstrap の本体のファイルに足し、ファイルの更新日時は元に戻されていました。
• 決済ページに、外部のスクリプトの読み込みを足す方法です。米国の収納用品の小売店、米国の販促品の店のほか、「日本の旅行予約サイト」が同じ配信元から別のファイルを配っていた、と書かれています。
• Google タグ(gtag)の記述の間に、タブ文字を約100個入れて画面の右端の外に隠して書く方法です。
• 店のCDNの裏にある S3 バケットに書き込める AWS のアクセスキーを使って、書き換える方法です。
• 商品説明のデータベースの欄に書き込む方法、Kubernetes の initContainer に足す方法、サーバー側のページのキャッシュを書き換える方法もあります。
• 米国のワイン小売店では、再デプロイで元に戻されても、2分ごとにファイルの大きさを確かめてスキマーを足し直す定期実行が置かれていました。

報告の確かさについての、同社の断り書き

原文は、侵入と被害の主張を3つの根拠に基づく、と書いています。攻撃者のサーバーで見つけた直接の証拠(盗まれたデータや道具)、実際のサイトで確認した侵入(いまも残るスキマーや、削除済みでも各種の検査に記録が残るもの)、そして攻撃者のサーバーにあったログとAIの主張です。そして、次のように断っています。

While AI claims and reporting may turn out to be inaccurate, we rely on them in this report because we could verify substantial parts of the claims by the first two methods, which showed them to be accurate.

つまり、AIの主張には誤りがありうるが、大部分は最初の2つの方法で確かめられたので使った、という説明です。原文はさらに、規模が大きく、データが不完全で、分析の初期段階にあるため、いくつかの誤りや不正確さがありうること、そして実際の規模と影響は報告より大きいと見ていることを書いています。この記事の数字も、そのつもりで読んでください。また、これは中間報告であり、攻撃は続いている、と原文に書かれています。

影響する会社・しない会社

• 影響する: 自社でECサイトを持ち、カード決済の入力を自社のページで受けている会社。管理画面がインターネットから見え、更新が遅れているカートやプラグインを使っている会社。
• 影響する: 制作会社が作った独自のカートや、WordPress・Magento などを自社のサーバーで動かしている会社。原文の目標選びは「独自のプログラムの店」を残す形でした。
• 影響する: 決済ページに、広告・解析・チャットなど、外部のスクリプトを複数入れている会社。1行足されても気づきにくいためです。
• 影響しにくい: カートや決済のページ全体を事業者に預け、自社の管理画面だけを触るASP型の会社。ただし、管理画面のIDとパスワード、委託先とのやり取りが破られれば別の話です。
• 影響しにくい: ECサイトがなく、通販や決済のページを持たない会社。

編集部の整理です。「影響しにくい」と書いたのは、原文の説明からの推測を含みます。原文は、日本の被害の有無や、日本の特定の通販基盤が狙われたかについて、(旅行予約サイトの1件を除いて)記載がありません。

情シスが今日やること

編集部の整理として、次の順で進めます。

1. 自社のECの形を一覧にする。ASPのカート、オープンソースのEC、制作会社の独自のプログラムのどれか、更新を担当するのは誰か、管理画面のURLは外から開くか、をA4で1枚にまとめます。
2. 更新と管理画面を確かめる。カート本体・プラグイン・OSの更新の日付を確認し、管理画面は接続元の制限と、二要素認証の有無を見ます。IPA の「ECサイト構築・運用セキュリティガイドライン」は、ウェブアプリのセキュリティ対策、ソフトウェアの最新化、管理画面へのアクセス制限、ログインの二要素認証などを要件に挙げています。付録のチェックリスト(Excel)が使えます。
3. 決済ページを見張る。決済ページの読み込みスクリプトを一覧にし、使っていない外部ドメインがないかを確認します。原文の例にあるように、jQuery などの既存のファイルの末尾、gtag の記述の周辺、商品説明の欄が書き換えられることがあります。配布元のファイルと比べて差分を見る、更新日時だけで安心しない、決済のページが読める外部スクリプトの配信元を絞る設定(Content-Security-Policy など)を検討する、が打つ手です。原文の末尾には、同社が見つけたスキマーの配信元のドメインの一覧(IOC)があるので、ログと照合するのも手です。
4. 契約先に聞く。カード会社(加盟店契約先)や決済代行に、自社が非保持化の対象か、PCI DSS の対象か、カード情報を保持する場合の範囲を確認します。
5. 気づいたときの連絡の順番を、先に決めて紙にしておく。次の章を参考にしてください。

日本の決まりと、見るべき資料

クレジットカード・セキュリティガイドライン

日本クレジット協会の加盟店向けのページによると、2018年6月1日に施行された割賦販売法で、加盟店にカード番号などの適切な管理と不正利用対策が義務づけられました。その実務上の指針が、クレジット取引セキュリティ対策協議会の「クレジットカード・セキュリティガイドライン」で、同ページは6.0版(2025年3月4日改訂)に触れています。

EC加盟店に求められる対策として、同ページは次の2点を挙げています。

• カード情報を保持しない非保持化、またはカード情報を保持する場合は PCI DSS に準拠する。
• ECのシステムとWebサイトの「脆弱性対策」を講じる(6.0版での追加・変更事項)。

同ページは、非保持化したEC加盟店でもWebサイトの脆弱性等を原因とするカード情報の窃取が起きているため、保持か非保持かにかかわらず、自社のシステムとWebサイトの定期的な点検と、その結果に基づく追加の対策が求められる、と書いています。今回の報告は、まさにその「非保持でも決済ページが書き換えられる」場面にあたります。

IPA のガイドライン

IPA の「ECサイト構築・運用セキュリティガイドライン」(2023年3月16日公開)は、ECサイトからの個人情報とカード情報の流出が多数起きており、被害の大半を中小企業の自社構築サイトが占めている、と説明しています。経営者編と実践編に分かれ、SaaS型サービスを使う会社も対象に入っています。

経済産業省の資料について

編集部は、経済産業省のECサイトの脆弱性対策の資料を、この記事の執筆時点で確かめていません。そのため、この記事では引用していません。

被害に気づいたとき、どこに連絡するか

原文は「侵入が1日未満」と書いているため、気づいたときにはすでに時間が経っている前提で、連絡の順番を決めておきます。

個人情報保護委員会のページには、次のことが書かれています。

• 不正な目的で行われたおそれがある場合、発覚した日から60日以内に報告する。まずは速やかに報告する。
• 報告が必要になる場合の1つに、「不正に利用されることにより財産的被害が生じるおそれがある個人データの漏えい等」があり、例として、ECサイトからカード番号を含む個人データが漏えいした場合が出ている。
• 「ウェブサイトが改ざんされ、ユーザーが入力した個人情報が第三者に送信された場合」も、不正の目的で行われたおそれがある例に出ている。スキマーはこれにあたります。
• クレジットカード番号の下4桁のみと有効期限の組合せの漏えいなら、直ちに報告対象には該当しない、と書かれている。

実際に報告が必要かどうか、期限をどう数えるかは、事案ごとに変わります。迷ったら同委員会のページと、契約先のカード会社の案内を確かめてください。

今日からできること

• ECの形(ASP・オープンソース・独自)と、更新の担当者を1枚にまとめる。
• カート・プラグインの更新の日付と、管理画面の接続元の制限・二要素認証を確認する。
• 決済ページの外部スクリプトの一覧を作り、不要なものを外す。
• 契約先のカード会社に、非保持化とPCI DSSの状況を確認する。
• 漏えいに気づいたときの連絡先と順番を紙にして、担当者の間で共有する。

関連する記事: 漏えい続出の背景に攻撃側のAI活用? 公式資料で分かること・分からないこと、JPCERT/CCが国内の不正アクセスに注意喚起、API管理の点検を