Silent Push、新たなMagecartネットワークを解明：世界中のオンライン購入者を狙う攻撃を阻止

主な調査結果

• Silent Pushの先制的サイバー防御アナリストは最近、「Magecart」という総称で知られる、長期かつ継続中のWebスキマー（Webスキミング）キャンペーンに関連するドメインの広範なネットワークを発見しました。
• 現在、複数のグローバル決済ネットワークが標的となっており、American Express、Diners Club、Discover、Mastercardが含まれます。
• このWebスキミング・キャンペーンで最も被害を受けやすいのは、 オンライン購入者 、侵害される ECストア 、そして決済プロバイダーです。
• このキャンペーンは少なくとも2022年1月以降、活動しています。

エグゼクティブサマリー

当社に共有されたインテリジェンス、および当社のBulletproof Host Indicators Of Future Attack™（IOFA™）フィードでも確認された一連の指標を調査する中で、当社チームは、長期かつ継続中のクレジットカード・スキミング・キャンペーンに関連する膨大なドメインネットワークを発見しました。現時点の調査結果から、このキャンペーンは2022年初頭にさかのぼり、数年にわたり活動していることが示唆されます。

このキャンペーンは、少なくとも6つの主要決済ネットワーク提供事業者を標的とするスクリプトを利用しています：American Express、Diners Club、Discover（Capital Oneの子会社）、JCB Co., Ltd.、Mastercard、UnionPay。これら決済プロバイダーの顧客であるエンタープライズ組織が、最も影響を受ける可能性が高いと考えられます。

本ブログでは、オンラインのクレジットカード・スキミング（「Magecart」と呼ばれる行為）の概要と、当社技術がどのようにして本キャンペーンのインフラを発見したかを紹介します。運用セキュリティ（OpSec）の懸念から、本キャンペーンを追跡するために当社アナリストが開発した手法のすべてを開示することはできません。詳細をご希望の場合は、当社Salesチームまでお問い合わせください。

背景

Webスキマーとは？

Webスキミング攻撃（クレジットカード・スキマー攻撃とも呼ばれる）とは、多くの場合JavaScriptなどの悪意あるコードを正規のECサイトや決済ポータルに注入し、チェックアウト（決済）プロセス中に顧客のクレジットカード情報やその他の機微な個人データを密かに傍受して窃取するサイバー攻撃です。

これらの攻撃は通常クライアント側で動作します。つまりコードは被害者のブラウザ上で実行されるため、ユーザーにもサイト運営者にもほとんど見えません。脅威アクターの目的は、カード決済情報を収集して不正取引、なりすまし（ID）窃盗、またはダークウェブのマーケットプレイスでの転売に利用し、最終的に身元詐欺および／または銀行詐欺につなげることです。これは、脅威アクター自身が実際の不正利用（略奪）に関与しているのか、単にデータの転売に関心があるのかによっても左右されます。

前述のとおり、この種のオンライン上のクレジットカード窃取を指す一般的な用語は「Magecart」です。ただし当初、「Magecart」という用語は、ECソフトウェアMagentoを使用するWebショップを標的としていたサイバー犯罪グループの連合を指していました。時間の経過とともに、これらの攻撃が他のEC製品へも拡大・多様化するにつれ、「Magecart」という名称は、MagentoのECソフトウェアを狙う特定のアクターを示すものから、関与した脅威グループや技術に関係なく、ほぼすべてのWebベースのクレジットカード・スキミング、Webスキミング、フォームジャッキング攻撃を指す一般的なラベルへと変化しました。

現在では「Magecart」は、オンライン取引中にWebフォームから機微なユーザーデータを密かに持ち出すクライアントサイド攻撃のクラス全体を説明する用語として受け入れられており、この呼称の起源となった元のグループの活動と、その後に現れた模倣グループの活動の双方を包含します。

Webスキマー攻撃のプロセス：ステップ・バイ・ステップ

当社脅威チームは何を観測したか？

当社が起点とした指標の1つはcdn-cookie[.]comで、ASN 209847上のIPアドレスを指していました。これは、PQ.Hosting/Stark Industries（THE.Hosting/WorkTitans B.V.としても知られる）というごく最近取得された、EU制裁対象エンティティに紐づくものでした。

初期分析の段階で、当社チームは、このドメインが次のような高度に難読化されたスクリプトを読み込むURLをいくつかホストしていることを確認しました：

cdn-cookie[.]com/recorder.js

スクリプトおよび関連ドメインをさらに分析した結果、より広い全体像が明らかになりました。すなわち、2022年頃までさかのぼる複数の継続中の感染を伴う、長期的なWebスキミング・キャンペーンです。

当社は、現在のキャンペーンのインフラを超えて広がる追加の技術的フィンガープリントも特定しました。しかし、OpSec上の懸念と、脅威アクターが展開で犯しているミスを強調したくないという意図から、これらの詳細は当社のエンタープライズ顧客および法執行機関にのみ提供しています。繰り返しになりますが、アクセスをご希望の場合は当社Salesチームまでお問い合わせください。

悪性インフラの解明

Webスキミングのコードとその動作を検証する前に、まず当社がSilent Pushプラットフォームをどのように活用して、本キャンペーンに関連する追加の指標や侵害サイトを特定しているかを示します。

指標そのものを単純に検索するだけでなく、最初に実行されるクエリの1つは、特定の指標が当社データベース内の他のWebサイトのコンテキストで読み込まれているかどうかを確認するものです。これを実現するために、当社は独自のWeb Resourcesデータセットを利用します。これは、Silent PushがスキャンしたあらゆるWebサイトが読み込んだすべてのリソースに関するデータを含みます。

以下のクエリは、初期シードドメインであるcdn-cookie[.]comについてこれを示したものです。

Web Search resource_hostname + hostname クエリリンク

datasource = ["webresources"] AND resource_hostname = "cdn-cookie.com" AND hostname != "cdn-cookie.com" AND hostname != "www.cdn-cookie.com"

以下の結果では、「hostname」フィールドに、一見無関係に見える多数のドメインが含まれていることに注目してください。当社のWeb Scannerが、このドメインが複数の異なるWebサイト上でリソースとして読み込まれていることを捉えているのが分かります。この場合、返されたドメインは、実際にはこの特定のインジェクタードメインを埋め込んでいる侵害ドメインであることを意味します：

また注目すべき点として、このドメインからは次のファイルが読み込まれていました：

• /1-197056a9.js
• /763825
• /cplnfwtlrkb.js
• /tab-gtm.js

これらのファイルのいずれかを開くと、先の「recorder.js」ファイルと同様に、難読化されたコードが表示されます。

当社チームは、どのページがこれらの外部ファイルを読み込んでいるのかを調査しました。するとすぐに、cdn-cookie[.]comからコードを読み込んでいると記録した4ページのうち3ページが、明確にWebショップであることが分かりました。同時に、その3つのWebショップのうち1つは現在、最近の決済システムの問題について顧客に知らせる興味深いメッセージを訪問者に表示しており、当社が正しい方向に進んでいることをさらに裏付けるものでした。

Webショップはクレジットカード・スキミング攻撃に特に脆弱です。ここで見られるように、当社クエリで得られた4つのWebサイトは、異なるベンダーによるもので、さまざまなインフラ上にあり、国も異なりますが、いずれも既知のバレットプルーフホスト上でホストされたドメインから、奇妙で難読化されたコードを読み込んでいました。

継続中の感染の分析

次に当社の調査では、（執筆時点で）現在も侵害されているWebサイト、hxxps[:]//colunexshop[.]com/を検証しました。Web Resourcesデータでこれを抽出し、hostnameフィールドおよびresource_hostnameを用いて参照がないか確認したところ、このサイトが以下のファイルを介して、先に発見した悪性ドメインに接続していることが明らかになりました：
「1-97056a9[.]js」

hxxps[:]//cdn-cookie[.]com/1-197056a9.js

Web Resources Search クエリリンク

datasource = [“webresources”] AND resource_hostname = “*cdn-cookie[.]com*” AND hostname != “cdn-cookie[.]com”

安全な環境でWebブラウザからリンクを開くと、次のスクリプトが返されました：

このページには難読化されたJavaScriptコードが表示されており、スクリプトの分析は以下で示します。ただし、その前に、感染したWebサイトが問題のコードをどのように読み込んでいるのかをまず確認します。これは、Web Developer Consoleを用いてWebサイトを分析することで可能です。

前述のとおり、Webスキマーは正規のECサイトの決済プロセスを操作してクレジットカード情報を盗むことを目的とします。このため、多くのスキマーは、チェックアウトページにアクセスされ、決済プロセスが開始されたときにのみ、注入プロセスを開始します。

Webスキマーの起点がどこにあるかを特定するには、通常の購入手順を進めて「チェックアウト」ページに到達し、訪問者が個人情報と希望する支払い方法の入力を求められるところまで進めます。このプロセスの具体的なレイアウトはWebショップによって異なりますが、colunexshop[.]comのチェックアウトページを開くと、上記で言及した「1-97056a9[.]js」ファイルへの想定どおりのWebリクエストが確認できます：

「initiator」リンクをクリックすると、コンソール上でWebリクエストをトリガーしたファイルを確認できます。さらに、大きなファイルの中でリクエストを引き起こしたコード片にフォーカスされます。

colunexshop[.]comの場合、リクエストの開始は次のファイル内の小さなコード片によって行われています：

hxxps[:]//colunexshop[.]com/finalizar-compra/?doing_wp_cron=1757931326.231261049383544921875

このコードはFacebook関連のコード読み込みスクリプトを模倣しようとしています。しかし偽装は不十分で、既知のFacebookスクリプトで、長い文字列から文字の連結リストを使うものはありません。続いて難読化されたコード片が、3つの引数で呼び出される自己実行関数を生成します。引数は次のとおりです：

解析を進めると、この「e」引数はスクリプト全体で頻繁に使用されていることが分かります。これは、コードが文字列を導出するために用いるアルファベットとして機能します。たとえば、e[2] = a、e[8] = d、e[10] = E、などです。したがって、これを使って文字列を復号（難読化解除）し、次のコードを導出できます（分かりやすさのためコメントを追加し、最後の文字列は簡潔さのため短縮しています）：

このコードは実際のFacebookのfbevents[.]jsファイルを読み込みません。代わりに、base64で難読化されたURLへアクセスし、返されたコードを注入します。これは次の場所にあるスクリプトで確認できます：

hxxps[:]//cdn-cookie[.]com/1-197056a9.js

このコードは高度に難読化され、意図的に難読化されたJavaScript経由で読み込まれているため、ここでの危険信号（レッドフラッグ）だけでも、当社が正しい方向に進んでいることは十分に分かります。

このコードは、以下に示すように「wp_enqueue_scripts」機能を介しても読み込まれています。これはWordPressのアクションフック機構で、ブラウザでWebサイトをレンダリングする際に適切なタイミングでスクリプトとCSSを読み込ませることができます。

add_action('wp_enqueue_scripts', function () { echo '<code here>'; });

アクションフックは通常、ページ読み込み中の最適なタイミングで実行され、関連するスクリプトやスタイルが正しい順序で、適切な依存関係管理のもとに含まれるようにすることで、テーマやプラグイン間の競合を防ぐことを意図しています。

しかし、ここで行われているようにJavaScriptコードを直接echoする形で実装するのは一般的ではありません。攻撃者の不適切なコード使用により、感染サイト上で目に見える不具合が発生し、以下の赤枠で示すように、そのセグメントがページ下部に露出しています：

この不具合にもかかわらず、コード全体からは、攻撃者がWordPressの内部動作に関する高度な知識を持ち、あまり知られていない機能さえ攻撃チェーンに組み込んでいることが示唆されます。

スキマー分析

コードは高度に難読化されているだけでなく、文字列連結、配列ベースの文字列格納、自己実行の無名関数、その他のエンコーディングなど、複数の手法を用いています。

難読化を解除すると、想定どおり、クレジットカード・スキマーを実装する約600行のJavaScriptコードに行き当たります。その後、コードは複数の関数に分割され、それぞれがより大きな攻撃に関連する機能を担っています。

以下は、初期実行から最終目的である被害者の認証情報窃取に至るまでの、ステップ・バイ・ステップの解説です：

インジェクトは、まずMutationObserver（Document Object Model（DOM）ツリーに対する変更を検知できるJavaScript API）を設定し、WebページのDOMが変更されるたびに関数「a()」を実行するようにします。

DOMは、ブラウザがページを読み込む際に作成する、Webページ上のすべてのHTML要素のツリー状表現です。要するに、各HTMLタグがJavaScriptからアクセス・変更・監視可能な「ノード」になる、生きた対話的マップです。ユーザーがページを操作（クリック、入力、コンテンツの読み込みなど）すると、DOMはリアルタイムで変化します。

このMutationObserverにより、Webサイト上で何らかの変更が生じるたびに、Webスキマーが再実行を試みるようになります。

Observerを開始した後、「a()」関数は、独立した初回実行試行とも言える形で1回だけ実行されます。

コードは続いて、現在のDOM内に要素「wpadminbar」が存在するかを確認し、WordPressの管理バーを探します。管理バーは、ログイン中の管理者または適切な権限を持つユーザーがサイトを閲覧しているときにWordPressサイト上部に表示される水平ツールバーです。投稿の編集、ユーザー管理、ダッシュボードへのアクセス、サイト統計の閲覧など、標準的なWordPress機能へ素早くアクセスでき、管理画面へ移動する必要がありません。

DOM内でwpadminbar要素が定義されている場合、コードは現在のDOMから完全に自身を削除します。注入されたコードを除去し、MutationObserverを停止することで実現します。これはサイト管理者の目を回避し、マルウェアの生存確率を高めるためです。

以下の画像は、DOM変更のたび、および初回に1度呼び出される「a()」関数を示しています。

この関数は、Webサイトがスキマーを実行する準備ができているかどうかを確認するよう設計されています。まず、WooCommerceの「BlockUI」要素を探すことで、ページが完全に読み込まれたかをチェックします。BlockUI要素は、WooCommerceがチェックアウトデータの処理、支払い方法の読み込み、カート内容の更新などを行っている間に表示するネイティブのオーバーレイ（通常は「Please wait…」メッセージを含む半透明のdiv）です。ページが正常に完全読み込みされるまでユーザー操作をブロックすることを意図しています。

DOM内にクラスblockUIを持つ要素が存在することは、WooCommerceがバックグラウンド処理をまだ実行中であることを示します。その場合、スキマーコードは1000ms（1秒）待ってから再実行します。

blockUIチェックを正常に通過すると、コードはWebサイト上で「Stripe」決済方法が選択されているかを確認します。注目すべき点として、これはスキマーが注入先のWebショップ種別に合わせて特別に設計されていることを示唆します。というのも、すべてのWooCommerceサイトがStripeを利用しているわけではないためです。

Stripeが選択されている場合、スキマーは、これから作成する偽の決済フォームがすでに読み込まれていないかを確認します。これは、以前のスキマー実行がすでにページを変更していることを示します。また、WebサイトのlocalStorage内に「wc_cart_hash」要素が存在するかも確認します。

マルウェアは、localStorage変数「wc_cart_hash」を用いて、すでに被害者のスキミングに成功したかどうかを示します。クレジットカード情報の持ち出しに成功すると「true」に設定され、再実行防止策として機能します。

Stripeフォームがまだ注入されていない、訪問者がStripeを支払い方法として選んでいない、またはエラーが発生した場合、マルウェアは500msごとに「a()」を再実行します。

実際のWebスキマー実行は関数「i()」から始まります。この関数は500行を超えるため、いくつかのステップに分けて説明します。

「i」関数はまず、「wc-stripe-form」の存在をさらにもう一度チェックします。これが存在せず、「wc-stripe-upe-form」が存在する場合、正規のStripe「Universal Payment Elements」フォームが読み込まれていることを意味します。

この場合、スキマーが動作を開始します。正規のStripe決済フォームを隠すために、そのstyle.display変数を「none」に設定します。次に、正規らしく見える変数名、タイトル、スタイルなどを用いた偽のStripe決済フォームをレンダリングする悪性iframeを作成します。そのiframeは、Stripe決済方法の正規コンテナに追加されます。

コードは続いて、注入されたiframeがWebサイトのサイズ変更に追従するようにする機能を追加し、「正規」らしい見た目と操作感をさらに高めます。

次に、iframeを開き、完全な偽のStripe決済フォームを書き込みます。この決済フォームは、侵害されたWebサイトと同じ言語であるポルトガル語になっています。HTMLフォームには、「cardnumber-Input」「expiry-Input」「cvc-Input」というIDを持つ3つの入力フィールドが含まれます。

この時点でスキマーは、実際の決済フォームを自身の悪性決済フォームに事実上置き換えています。前のコードセクションが示しているとおり、このフォームのIDは「wc-stripe-form」です。以後、先の「a()」関数が再実行されても、偽フォームがすでに存在するため失敗します。

偽フォームの注入に成功すると、スキマーは決済フォームが機能しているように見せるためのロジックを定義します。これには、入力されたクレジットカード番号に対する「カードブランド」検出のスクリプトベースのチェックが含まれます。

スクリプトが明示的に認識するプロバイダーには次が含まれます：

• Mastercard
• American Express
• JCB Co., Ltd.
• Diners Club
• Discover
• UnionPay

注：ここに挙げた企業は決済取引ネットワーク提供事業者そのものです。つまり、このスキマーは、カード自体が地域の銀行やカード発行会社のブランドであっても、世界中で発行されているクレジットカードの大半をカバーしている可能性が高いということです（出典：The Motley Fool）

スキマーはこの情報を用いて、入力フォームに正しいカードブランドの画像を自動的に表示するよう適応させ、フォームをさらに正規に見せます。以下の画像は、MastercardとJCBカードの場合の変化を示しています。

正規性を高めるために追加された機能には次が含まれます：

• 入力された有効期限の自動フォーマット
• カードブランドに応じたクレジットカード番号の自動フォーマット
  • American Express：4-6-4、および4桁のCVC
  • Diners Club：4-6-4
  • その他の多くのカード：4-4-4-4
• フィールドからフォーカスが外れた際に、入力内容が無効であれば赤で自動的にエラー表示する機能
  • 認識されたブランドに紐づくこと（不明なブランドではないこと）と、長さが少なくとも13文字であることを確認して、クレジットカード番号の妥当性を検証する。
  • 年が過去でないこと、少なくとも5文字であること、「/」区切りがあること、月が1〜12であることを確認して、入力された日付の妥当性をチェックする。
  • CVCが少なくとも1文字以上であること

これらのチェックは、Luhnアルゴリズムのような、より高度なものと比べると比較的単純です。

スタイリングと検証機能は、EventListenerを介して3つの入力フィールドに追加されます。

このステップの後、Webスキマーはチェックアウトページ上のすべての入力フォームを監視します。2つの状態変数「w」と「h」を使用し、少なくとも2文字以上であれば部分的な入力データであっても保存します。

窃取されるデータはクレジットカード情報に限りません。氏名、住所、配送先住所フィールドを含め、Webサイト上のすべての入力要素が収集されます。

データはキーと値のペアとして保存され、入力フィールドのIDがキーとなり、入力された値が対応する値になります。

被害者がフォームに入力した後の「w」の正しいフォーマット例は次のようになります：

w = {
"billing_first_name": "John",
"billing_last_name": "Doe",
"billing_email": "[email protected]",
"billing_phone": "555-1234",
"billing_address_1": "123 Main St",
// ... etc
}

重複する内容は「h」の値にも入ります。

「w」の値は、作成されて各種値で埋められた後、二度と使用されません。その理由は不明ですが、「w」が以前のバージョンから残ったコードの痕跡（アーティファクト）である可能性があります。

一方で、「h」の値は持ち出し（エクスフィルトレーション）プロセスにとって重要です。被害者がフォーム入力を行う全期間にわたり動的に埋められます。被害者が支払いデータフォームに入力している間、スキマーは決済サイトの別の機能も乗っ取っています。それが「Place Order」ボタンです。

これに関するコードは次のように始まります：

このコードは、クリックイベントに反応するボタンにEventListenerを追加するよう設計されています。このイベントは、被害者がStripe決済情報を含むWebフォーム全体の入力を完了し、注文を送信しようとしていることに相当します。クリックされるとコードが実行され、各チェックアウトフォームの値を、新しい変数セットにフィールドごとに格納します。

まず、当該フィールドの値が、先に説明した動的データ保存機能（「w」および「h」変数にデータを保存する機能）によって以前に取得されているかを確認します。この場合、照会されたキーに対して「h」変数に保存されたデータが使用されます。

動的データパーサーが、照会された特定のキー・バリューペアの保存に失敗したと仮定します。その場合、コードはフィールドに現在格納されている値を直接使用するフォールバックに切り替え、「getElementById()」関数を介してアクセスします。

偽のStripe決済フォームに入力された支払いデータ値については、以下に示すように、より厳密なチェックが行われます：

このコードは、localStorage変数wc_cart_hashを確認することで、現在の被害者に対して過去にスキミングが実行されていないことを明示的にチェックします。

次に、乗っ取られたフォームのデフォルト動作を抑止し、3つのクレジットカード入力フィールドのいずれも空でないことを確認します。

いずれかのフィールドが空の場合、空のフィールドは、先のチェックでカードデータが値チェックを通過しなかった際に適用されたのと同じ赤いエラースタイルを表示するよう変更されます。これにより被害者は、先へ進む前に不足データの問題を修正するよう促されます。

これらのチェックを通過すると、スキミングコードは、これまでに収集したすべてのデータを含むデータオブジェクトを作成し、持ち出しの準備を行います。

その例は次のとおりです：

持ち出し前に、一部の収集データは再フォーマットされます。たとえば、請求先フォームの名と姓は、被害者の「フルネーム」におけるスペースを作るため、「 」を挟んで結合されます。

データ構造が作成されると、スキマーは実際の持ち出しへ移行します。

まず、先に作成したデータオブジェクトがJSON形式であることを確認し、ハードコードされたキー「777」を用いてXOR暗号化し、Base64エンコードします。

次にスキマーは、以下のURLを介して、持ち出しサーバーへHTTP POSTリクエストを送信します：

hxxps[:]//lasorie[.]com/api/add

このURLには、本文として「data=」が先頭に付いたBase64エンコード済みデータ文字列が送られます。

このリクエスト送信後、スキマーは現在のチェックアウトページから自身をクリーンアップし、先に作成した偽の決済フォームを削除します。

削除後、正規のStripe入力フォームを復元し、表示スタイルを「block」に戻します。最後に、localStorage変数「wc_cart_hash」を「true」に設定して、現在の被害者に対してスキマーが再実行されないようにします。そして、実際のチェックアウトボタンに対して「click」をシミュレートし、実際の決済プロセスを開始します。

重要な注記：被害者は、スキマーが最初に隠していた本物のStripe決済フォームではなく、偽フォームにクレジットカード情報を入力していたため、決済ページにはエラーが表示されます。これは、被害者が単に支払い情報を誤って入力したかのように見せかけます。

多くの場合、オンライン購入者は自分が被害に遭ったことに気づきません。代わりに、単なる入力ミスだと思い込み、認証情報を再入力して通常どおり進めます。2回目の決済試行は、元の無害な決済フォームとやり取りするため、正常に処理されます。

非技術的な被害者がこの攻撃を検知できる唯一の可能性は、支払い時にこのエラーに気づき、フォーム入力後に情報が消えていることを目にすることです。

この有効性は、セキュリティ研究者Mikhail Kasimovが共有した調査によっても補強されます。同氏は3年以上前に、これらの古いドメインのいくつかをMagecart活動に帰属させており、脅威アクターの持続力を示しています。

Indicators Of Future Attack™（IOFA）™

以下は、当社チームがMagecartネットワークについて収集した指標のごく一部です。

• cdn-cookie[.]com
• lasorie[.]com

緩和策

Webスキマー・キャンペーンに対する防御措置

ベンダーと消費者の双方が、Webスキマー・キャンペーンから身を守るために取れる防御措置はいくつかあります。

ベンダー向け防御措置

• Content Security Policy（CSP）を実装し、外部リソース、とりわけJavaScriptの読み込みを制限することで、悪性コード注入のリスクを低減します。
• Payment Card Industry Data Security Standard（PCI DSS）要件に準拠します。PCI DSS標準に従うことで、カード会員データおよび認証データの安全な保管・処理・送信を確保しやすくなります。
• システムを最新の状態に保つ。CMSプラットフォーム、プラグイン、セキュリティパッチなどのソフトウェアコンポーネントを定期的に保守し、脅威アクターが悪用し得る脆弱性を最小化します。
• 強力なアクセス制御を徹底する。管理者アカウントには複雑で一意の認証情報を使用し、多要素認証を有効化して不正アクセスを防止します。
• ユーザー視点でのテスト。Webサイト管理者は、ブラウザのシークレット／プライベートモードを使用するか、ブラウザのキャッシュと履歴を消去した後に、自サイトを定期的に確認すべきです。この実践は重要です。なぜなら、多くのWeb注入型脅威は、Cookieを通じて管理者ユーザーを識別する検知機構を用い、管理者の存在下では意図的に悪性コードを実行しないためです。管理者の認証情報やキャッシュデータなしでサイトを閲覧することで、隠れたままになり得る脅威を検知できます。

消費者向け防御措置

• 信頼できるプラットフォームで買い物をする：セキュリティ面で実績のある、確立された評判の良いECサイトを選びましょう。
• オファーを慎重に評価する：過度に割引されていたり非現実的に見える取引には注意してください。詐欺サイトや悪性ベンダーの兆候である可能性があります。うますぎる話に聞こえるなら、たいていはそのとおりです。
• 金融活動を監視する：銀行口座やクレジットカードの利用明細を定期的に確認し、不正取引を迅速に検知できるようにしましょう。
• チェックアウト時の異常に注意する：カード情報を入力した後に決済ページが予期せずエラーを表示した場合、取引を中止し、疑わしい事象として報告することを検討してください。
• セキュリティツールを活用する：既知の悪性ドメインやスクリプトをブロックするブラウザ／エンドポイントのセキュリティソリューションを使用し、オンラインの安全性を高めましょう。

Magecartキャンペーンの追跡を継続

当社チームは、2026年を通じて配信される難読化やスキマー亜種に関する理解を拡大しながら、Magecartキャンペーンの追跡を継続します。

Magecartは、世界中のオンラインストアとその顧客の双方にとって依然として活発な脅威であり、この複数年にわたるキャンペーンは今後も無期限に継続すると見込んでいます。

本レポートの調査結果に関して共有できる情報をお持ちの方（個人または組織）は、ぜひ当社までお知らせください。