MagecartスキマーがStripeを「完璧な変装」のC2サーバーに変える新手法

3段階で侵入する「Stripeマゲカート」の手口

キャンペーンは以下の3段階で構成され、各段階で正規サービスを巧みに「隠れ蓑」として利用します 。

第1段階：Googleタグマネージャー(GTM)経由で読み込み装置を仕込む

まず攻撃者は、標的ストアのGoogleタグマネージャー(GTM)コンテナを侵害し、全ページで動作する悪意あるタグを注入します。このスクリプトの出どころは googletagmanager.com です。アクセス解析の定番ドメインであるため、コンテンツセキュリティポリシー(CSP)も広告ブロッカーもこれを阻止できず、「検知不能な配信装置」と化します 。

第2段階：StripeのAPIからスキマー本体を取得する

GTMのタグが起動すると、次にスキマーのJavaScript本体を取得しようとします。しかし、接続先は攻撃者のサーバーではなく api.stripe.com です。攻撃者は自分たちが管理するStripeアカウントのテストモード秘密鍵（sk_test_...）を使い、「顧客(Customer)」レコードのメタデータ欄にスキマーコードを保存しているのです 。

店舗側の通信ログには「api.stripe.com へのAPIリクエスト」としか残らず、それが正規の支払い処理なのか、マルウェアのダウンロードなのか、判別は不可能に近いです 。

第3段階：奪った情報を同じStripeアカウントに送り返す

購入者がチェックアウト画面にクレジットカード情報や住所を入力すると、注入されたスキマーがそれらを捕捉し、即座に攻撃者のStripeアカウントへ書き戻します。情報は偽の「顧客」データやメタデータとして格納されるため、送信先は再び api.stripe.com です 。

ファイアウォールから見れば、カード情報の窃取通信も、すべて「Stripeへの普通のAPI通信」にしか見えません。この完全な「擬態」により、従来の異常検知は完全に無力化されます 。
Sansecの調査によると、この手口は少なくとも2025年12月24日以降、稼働が確認されています 。

なぜ「テスト用キー」がそこまで危険なのか

Stripeのテストモード秘密鍵（sk_test_...）はサンドボックス環境内で全アクセス権を持ち、費用も一切かからずに、顧客データやメタデータを無制限に作成できます 。

実課金を伴わないテストキーは「リスクが低い」と見なされがちで、多くの組織が本番キーほどの厳格さでサンドボックスを監査していません。今回の攻撃は、まさにこの管理体制の隙を突いています 。

なお、本番用秘密鍵（sk_live_...）の漏洩は、実際の取引データの読み取りや、払い戻し・送金という直接的な金銭被害に直結します 。本キャンペーン自体はテストキーを使いますが、いずれのキーもクライアントサイドのコードやGTMに絶対に埋め込んではならないという大原則は変わりません 。

同時多発：Everest Forms Proの深刻な脆弱性（CVE-2026-3300）

Eコマースの「フロント（支払い画面）」がStripeキャンペーンで狙われる一方、サイトを支えるWordPressの「バックエンド基盤」も深刻な危機に晒されています。

CVE-2026-3300は、プラグイン「Everest Forms Pro」における未認証のリモートコード実行(RCE)脆弱性で、CVSSスコアは最大深刻度の9.8です。バージョン1.9.12以前の全ソフトが影響を受けます 。

この脆弱性は、プラグインの「計算アドオン」内の process_filter() 関数に起因します。「複雑な計算」機能が有効な場合、ユーザーがフォームに入力した文字列が、適切なエスケープ処理を経ずにPHPコードの一部として連結され、eval() 関数に渡されてしまうのです 。

セキュリティ企業Wordfenceは、2026年4月13日以降、この脆弱性を突く攻撃を29,300回以上ブロックしたと報告しています。攻撃者は不正な管理者アカウントを作成し、サーバーを完全に乗っ取ろうとします 。

今すぐ取るべき防御策

Stripeマゲカート攻撃への対策

• GTMをロックダウンする：GTMコンテナには、承認・監査済みのタグのみを許可し、公開前の変更管理を厳格化してください 。
• コンテンツセキュリティポリシー(CSP)を厳格化：api.stripe.com を script-src に指定するのは、真に必要な場合のみに留め、可能ならばサブリソース整合性（SRI）ハッシュを併用します。インラインスクリプトのブロックも有効です 。
• Stripeサンドボックスを定常監査：テストモード下で不自然な量の「顧客」作成やメタデータ書き込みがないか、Stripeダッシュボードを定期確認してください。
• APIキーの管理とローテーション：テスト用・本番用を問わず、Stripe秘密鍵をクライアントサイドJavaScriptやGTM変数、公開リポジトリに絶対に埋め込まないでください 。漏洩の疑いがあれば直ちにキーをローテーションします 。
• クライアントサイド監視の導入：チェックアウトページで権限のないスクリプトによるDOM改ざんを検知するブラウザ側の監視が、最終防衛線として機能します 。

Everest Forms Pro 脆弱性への対策

• 至急アップデート：Everest Forms Proを修正済みのバージョン1.9.13以降に直ちに更新してください 。
• 回避策の実施：即時更新が難しい場合は、プラグイン設定で「複雑な計算」機能を無効化し、攻撃の入口を塞いでください 。
• 侵害痕跡の調査：不審な管理者アカウントや見慣れないファイル、不自然な eval() 呼び出し、外部への不審な通信がないか徹底調査してください。修復後は、WordPress本体、テーマ、プラグインの全ファイルで完全性チェックを実行する必要があります 。