セキュリティの相談を受けていると、ここ数年で確実に増えていると感じる被害があります。
それが、Webサイトの決済画面を通じてクレジットカード情報が抜き取られていた、というケースです。
調査の初期段階で話を聞くと、「サーバーは普通に動いていた」「不正ログインの形跡もない」と言われることがほとんどです。実際、管理画面やログを見ただけでは、異常が見つからないことも珍しくありません。
それでも詳しく追っていくと、決済ページに読み込まれている外部スクリプトの中に、利用者の入力情報を外部へ送信するコードが仕込まれていた、という事実に行き着きます。こうした攻撃の多くが、Webスキミングと呼ばれる手口です。
Webスキミングは、サイトを停止させることもなく、見た目も変えません。そのため被害に気づくのが遅れ、発覚した時にはすでに一定期間、情報が盗まれ続けていたという状況になりがちです。
しかも、原因は必ずしも自社システムの脆弱性とは限りません。広告タグや解析ツール、決済関連ライブラリなど、日常的に利用しているサードパーティコードが入口になるケースも多く見られます。
「自社は対策しているつもりだった」。そう話す企業ほど、この攻撃に盲点を突かれている印象があります。
TABLE OF CONTENTS
Webスキミングとは何か
Webスキミング（オンラインカードスキミングとも呼ばれます）は、ECサイトや予約サイトの決済画面で、利用者が入力したクレジットカード情報を盗み取る攻撃です。
この攻撃の特徴は、サーバーやデータベースを直接狙うのではなく、ユーザーが入力した瞬間の情報を横から抜き取る点にあります。管理画面に侵入された形跡がなくても被害が起きるのは、このためです。
以前は「フォームジャッキング」と呼ばれる手口が多く、入力フォーム自体を書き換えて情報を盗むケースが目立っていました。しかし現在は、第三者が提供しているJavaScriptやオープンソースライブラリを足がかりに、見た目では分からない形で不正なスクリプトを混入させる攻撃が主流になっています。
実際の調査で多く見かける侵入口は、次のようなものです。
- 脆弱性が放置されたサードパーティ製JavaScript
- 使い回されたAPIキーや管理者アカウント
- GitHubなどのリポジトリに誤って公開された秘密情報
- 公開直後で対策が間に合っていないゼロデイ脆弱性
こうした経路を使われると、「自社のサーバーには問題がない」という状態でも被害が発生します。
外部スクリプト経由で決済情報だけが抜き取られる。それが、Webスキミングが厄介で、発見が遅れやすい理由です。
Webスキミングはどう動くのか（攻撃の流れ）
ステップ1：侵入
Webスキミングの初動は、だいたい次の二つのどちらかです。
場合によっては、この両方が組み合わされることもあります。
- Webサーバーやインフラそのものへの侵入
- 利用しているサードパーティベンダーの脆弱性悪用
前者はいわゆる一般的な侵入で、サーバーやCMS、ミドルウェアの弱点を突かれるケースです。
一方で、最近特に多く、そして厄介なのが後者です。
サードパーティベンダーが侵害されると、そのスクリプトを読み込んでいるすべてのWebサイトが影響を受けます。攻撃者にとっては、1社を突破するだけで、同時に多数のサイトを汚染できる非常に効率の良い手口です。
実際の調査でも、「自社環境は問題なかったが、外部コード経由で侵入されていた」というケースは珍しくありません。しかも、そのスクリプトは日常的に使われている正規のものなので、異常として見逃されやすい。結果として、被害が広がるまで誰も気づかない、という状況が生まれます。
ステップ2：情報の収集
仕込まれるのは、ほぼ例外なくJavaScriptです。
HTMLを書き換えるような分かりやすい改ざんではなく、既存のコードに紛れ込む形で仕込まれます。
見た目はごく普通の処理にしか見えず、コードレビューをしても違和感がないことも珍しくありません。
このスクリプトは、決済画面で利用者が入力する内容を静かに監視しています。
カード番号や有効期限、氏名といった情報が入力されると、それを横取りするように取得し、外部に送信します。画面の挙動が変わることもなく、処理が遅くなることもほとんどありません。
重要なのは、この不正なコードが支払い直前のタイミングまで表に出てこない点です。トップページや商品一覧、管理画面をいくら確認しても、異常は見つかりません。実際、決済フローまで辿らない限り、問題に気づけないケースが大半です。
そのため、「日常的にサイトを見ていたのに、まったく気づかなかった」という状況が起こります。Webスキミングが長期間見逃されやすいのは、この仕組みによるところが大きいと感じています。
ステップ3：情報の持ち出し
収集されたカード番号や個人情報は、攻撃者が用意した外部サーバーへ送信されます。
多くの場合、海外のサーバーや一時的に用意された転送先が使われ、短期間で痕跡が消されます。
この時点で、被害はすでに企業の管理領域を超えています。盗まれた情報は、不正利用に使われたり、別の攻撃の材料として流通したりします。利用者側で不正利用が発覚して初めて、問題が表に出るケースも少なくありません。
結果として、影響を受けるのは利用者だけではありません。「どこから漏れたのか」「どれくらいの期間続いていたのか」を説明できない状態のまま、企業は問い合わせ対応や調査、再発防止に追われることになります。
Webスキミングが厄介なのは、被害が顕在化した時点では、すでに取り返しがつかない段階に入っていることです。技術的な問題だけでなく、信頼やブランドへの影響として返ってくる。現場では、そこが最も重く受け止められています。
Magecartとは何者か
Webスキミングの話をするうえで、どうしても外せない存在が Magecart です。
以前は特定のハッカー集団を指す名前でしたが、今では一つのグループというより、Webスキミングで使われるコードや攻撃手法そのものを指す言葉として使われることが増えています。
Magecartが広く知られるようになったきっかけの一つが、2018年にWIRED誌で「インターネット上で最も危険な存在」の一つとして取り上げられたことでした。注目された理由は難しい話ではありません。とにかく、影響範囲が異常なまでに広いのです。
Magecartの手法では、サードパーティを1社侵害するだけで済みます。そのスクリプトを利用しているWebサイトは、規模や業種に関係なく、まとめて影響を受ける。攻撃者から見れば、少ない手間で最大のリターンが得られる、非常に効率の良い攻撃です。
実際の被害事例を見ても、「なぜこんなに広がったのか」を辿っていくと、多くの場合、このサードパーティ経由の構造に行き着きます。個別の企業を一社ずつ狙うより、仕組みごと押さえたほうが早い。
Magecartは、その発想を徹底的に突き詰めた存在だと言えます。
実際に起きた被害事例
Webスキミングは、仕組みだけを聞くと少し分かりづらいかもしれません。
ですが、実際に起きた事件を見ていくと、「なぜ発見が遅れたのか」「なぜ被害が広がったのか」がはっきりします。
British Airwaysのケース
2018年、ブリティッシュ・エアウェイズでは、約38万件以上のクレジットカード情報が盗まれる被害が発生しました。侵害されていたのは、Webサイトとスマートフォンアプリの決済ページで、期間はおよそ3週間に及びます。
このケースで特徴的だったのは、使われたスキマーが決済画面の構造を正確に理解したうえで作られていた点です。汎用的なコードをばらまくような攻撃ではなく、「この画面なら、ここを取ればいい」という前提で設計された、非常に狙い撃ちの攻撃でした。
しかも、このスクリプトはPCだけでなく、モバイルアプリ側の決済にも影響していました。
結果として、カード番号だけでなく、氏名やメールアドレス、請求先住所といった情報も盗まれています。
Ticketmasterのケース
同じく2018年、チケット販売大手のTicketmasterでも、4万件以上の顧客情報が流出しました。
調査の結果、原因はTicketmaster本体ではなく、決済ページで利用していた第三者ベンダーのJavaScriptにありました。
このJavaScriptを提供していたのが、NLPソリューションを提供するInbentaです。
Ticketmaster向けにカスタマイズされたコードが、そのまま決済ページで使われており、そこに仕込まれたスキマーによって、利用者の支払い情報が取得されていました。
この事件が示しているのは、「自社のシステムが原因ではない」という説明が、利用者や社会に対してはほとんど意味を持たない、という現実です。被害を受けた側から見れば、「どこが原因か」よりも「なぜ防げなかったのか」が問われます。
Macy’sのケース
Macy’sの事例も、現場感覚としては非常に典型的です。
攻撃者は、ClientSideErrorLog.js というログ取得用のJavaScriptファイルを書き換え、決済ページで入力されたカード情報を盗み取っていました。
ログやエラー収集用のスクリプトは、多くのサイトで当たり前のように使われています。
しかも、「決済とは直接関係なさそう」に見えるため、セキュリティチェックの優先度が下がりやすいのが実情です。
その隙を突かれた結果、カード情報が静かに抜き取られていく。このパターンは、調査の現場でも何度も目にしています。
では、どう防ぐべきか
正直に言うと、Webスキミングを完全に防ぎ切る方法はありません。
どれだけ対策をしていても、新しい手口や想定外の侵入口は出てきます。
ただし、ここまで多くの調査に関わってきてはっきり言えるのは、被害に遭う確率を大きく下げることは十分に可能だということです。実際、被害に遭う企業とそうでない企業の間には、いくつか明確な違いがあります。
まず、最低限として必ず押さえておくべきポイントがあります。
基本として必ずやるべきこと
- 利用しているすべてのサードパーティ（決済・広告・解析ツールなど）を把握する
- Webサイト上で動作しているスクリプトを継続的に監視する
- ファイルやコードの変更を検知できる仕組みを入れる
- 脆弱性管理とパッチ適用を後回しにしない
- 管理者アカウントには必ず多要素認証（MFA）を導入する
調査の現場では、「ここができていれば防げた可能性が高い」と感じるケースも少なくありません。
特に、どんな外部コードが読み込まれているのかを把握していない状態は、Webスキミングに対してほぼ無防備に近いと言えます。
一方で、より被害を抑えたい、検知を早めたいのであれば、もう一段踏み込んだ対策も検討する価値があります。
さらに踏み込んだ対策
- サブリソース完全性（SRI）やCSPを適切に設定する
- クライアントサイド攻撃を前提にしたセキュリティ監視を行う
- 外部からの侵入を想定したペネトレーションテストを定期的に実施する
- ブラウザベースの不正挙動を抑止するためのボット管理ソリューションを導入する
ここまでやっている企業は、正直まだ多くありません。
ただ、Webスキミングのような攻撃が増えている今、「サーバーは守っているから大丈夫」という考え方だけでは足りなくなっています。
ブラウザ上で、どんなコードが動き、どんな情報が扱われているのか。そこを把握できていない限り、Webスキミングを完全に防ぐことは難しい。現場で強く感じているのは、その一点です。
最後に
Webスキミングは、DDoS攻撃のように目立つことはありません。
サイトが落ちるわけでも、警告画面が出るわけでもない。だからこそ、長いあいだ気づかれず、企業とユーザーの双方に静かなダメージを与えます。
予防の立場で診断やテストに関わっていると、「何も起きていない今の状態」を正しく把握できているかどうかが、その後を大きく分けると感じる場面が多くあります。
CyberCrewでは、攻撃者の視点に立った診断や、実際の侵入シナリオを再現するペネトレーションテストを通じて、表に出にくいリスクを事前に洗い出し、見える形にすることを重視しています。
「自社は大丈夫だろう」と思えている今こそ、一度立ち止まって、ブラウザ上で何が起きているのかを確認してみてください。問題が起きてからではなく、何も起きていない段階で向き合えるかどうかが重要です。
予防の現場にいるホワイトハッカーとして、この一点だけは、強く意識していただきたいと思います。
CyberCrewで安全を確保しましょう
Telegramの匿名性を悪用したサイバー犯罪は拡大の一途をたどっています。CyberCrewの監視・インテリジェンスソリューションは、これらの脅威にリアルタイムで対応し、不正アクセスの試みが本格的な侵害にエスカレートする前に防止することができます。
投稿者プロフィール
-
Offensive Security Engineer
15年以上の実績を持つ国際的なホワイトハッカーで、日本を拠点に活動しています。「レッドチーム」分野に精通し、脆弱性診断や模擬攻撃の設計を多数手がけてきました。現在はCyberCrewの主要メンバーとして、サイバー攻撃の対応やセキュリティ教育を通じ、企業の安全なIT環境構築を支援しています。
主な保有資格：
● Certified Red Team Specialist（CyberWarFare Labs / EC-Council）
● CEH Master（EC-Council）
● OffSec Penetration Tester（Offensive Security）
最新の投稿
Black Hat2026.01.23ランサムウェア交渉という仕事──混乱の中で「主導権」を取り戻すために
Black Hat2026.01.22北朝鮮IT人材は、どのようにしてリモート採用市場に入り込んでいるのか
リスクマネジメント2026.01.21エシカルハッキングサービスとは何をしているのか
Black Hat2026.01.20ディープウェブとダークネットを正しく理解する――安全に向き合うための現場感覚
