クラウドコンピューティングが必要ですか? 今すぐ始める

Google Tag Manager に偽装した Magecart 攻撃

Roman Lvovsky

執筆者

Roman Lvovsky

February 15, 2023

Roman Lvovsky

執筆者

Roman Lvovsky

Roman Lvovsky は、クライアント側の脅威、ブラウザー内部、JavaScript 攻撃ベクトルに関する豊富な経験を持つセキュリティ研究者です。Akamai の In-Browser Protection Research Team のメンバーであり、ウェブスキミングや Magecart 攻撃など、さまざまなクライアント側の脅威に関する研究に力を入れています。ソフトウェアエンジニアリングの分野で確固たる経歴を持ち、JavaScript と Web 開発を専門としています。

最近の攻撃は、精算のページやフォームでサイト訪問者の機微な情報を盗みとろうとするものでした。

いくつかの EC サイトで、巧妙な Magecart Web スキミングキャンペーンが新たに発見されました。Magecart 攻撃とは、サイバー犯罪の一種で、特にオンライン小売企業を標的としています。このタイプの攻撃は、悪性の JavaScript コードを Web サイトの決済ページに挿入し、顧客の機微な情報が入力されるとそれをすぐに取得して攻撃者のサーバーに送信します。こうした情報には、クレジットカード番号や個人を特定できる情報が含まれる可能性があります。

最近の攻撃は、精算のページやフォームでサイト訪問者の機微な情報を盗みとろうとするものでした。攻撃者は、脆弱性を悪用することによって、標的とする Web サイトに悪性のインライン JavaScript コードを挿入することに成功しています。このスキマーには、Google Tag Manager のような正当なサードパーティーベンダーになりすます手口が使われ、さらに悪性コードを隠すために Base64 エンコーディングも使用されていました。 

この攻撃は、一部の Web サイトを継続的に狙い、 カナダの最大手酒類小売企業に対する最近の攻撃と類似しています。

攻撃の概要

既知のベンダーコードへのなりすまし

このスキマーは、Google Tag Manager のコードスニペットに似たインラインスクリプト(HTML 内に埋め込まれ、外部ファイルから読み込まれないスクリプト)として悪性コードを挿入します(図 1)。この手法により、攻撃者は悪性コードを既知のベンダーの背後に隠し、正当なスクリプトであるかのように偽装できます。私たちはこれまでも、この回避手法を使用して検知を困難にしている Magecart キャンペーンに何度か遭遇したことがあります。

このスキマーはさらに、Base64 エンコーディングを使用して、悪性コードであることを示す可能性のある URL やキーワードを難読化します。これにより、スキマーの存在はさらに見つけにくくなります。

図 1:Google Tag Manager スニペットへのなりすましの例 図 1:Google Tag Manager スニペットへのなりすまし

WebSocket と eval 関数の使用

この例では、インラインスニペットはローダーとしてのみ機能し、実際の攻撃コードとしては機能しません。ローダーには、精算のページでのみ攻撃をトリガーするという条件が含まれているため、スキマーは目立たないように動作し、攻撃に関連する機密性の高い標的ページのみに完全な悪性コードを読み込むことができます。

ローダーコードの Base64 エンコーディングが復号化されると、短くてシンプルな JavaScript コードが現れます。このコードが実行するのは、2 つのステップだけです。まず攻撃者のコマンド&コントロール(C2)サーバーとの新たな WebSocket 接続を作成し、そして、「eval」関数を使用して、C2 から受信したコードを実行するリスナー関数を設定します(図 2)。

図 2:エンコードされて、図 1 の Google Tag Manager スニペット内に隠されていたコード。 図 2:Google Tag Manager スニペット内に隠されていたコード。

Magecart 攻撃で WebSocket と「eval」関数を使用するのは、悪性コードがそのページのコンテキスト内でファーストパーティースクリプトとして実行されるようにして、標的 Web サイトのリサーチャーやセキュリティサービス、スキャナーによる検知を困難にするためであり、高度なテクニックと考えられます(図 3)。この手法は、従来の XHR リクエストや HTML タグよりもアクティビティを検知されにくくし、攻撃者がひそかに活動を継続するために役立ちます。

図 3:同じスキマーのローダーで、WebSocket を使用する別のバリエーション。 図 3:同じスキマーのローダーで、WebSocket を使用する別のバリエーション。

コードチェックの実行

ソケット接続を開始すれば、ブラウザーと C2 サーバーはいつでもデータを交換できます。攻撃者の C2 サーバーからページに送信された最初のメッセージ(図 4)には、ローダーコードで指定されたリスナー関数によってただちに実行される JavaScript コードが含まれています。

このコードは 2 つのチェックを実行します。

  1. ローダーコードで定義されたグローバル変数を介して WebSocket 接続が確立されているかどうかを確認します。
  2. そのページが送信ボタンを含む精算ページかどうかを判断します。

これらのチェックに通ると、攻撃者のコードは現在のページの URL を含むメッセージを C2 サーバーに送信します。これへの応答として、C2 サーバーはその特定の標的ページに応じた適切な悪性コードを返します。

つまり、C2 サーバーはページ URL を待ち、これを受信してから攻撃コードを返します。これは、このキャンペーンが多数の Web サイトやページに同時に対応できるような動的なフレームワークを使用していることを意味しています。

図 4:スキマーの C2 サーバーとの WebSocket 接続の例です。 図 4:WebSocket とスキマーの C2 サーバーの通信

コードの難読化

図 5 は、URL の検証後に C2 サーバーから取得された実際の攻撃コードを示しています。コードは難読化され、基本的なロジックや攻撃の進行がわかりにくくなっています。Magecart のスキマーにはよく難読化のテクニックが使用されます。セキュリティ担当者が攻撃コードを解読し、攻撃フロー全体を把握するのを難しくするためです。

図 5:WebSocket 接続を介して C2 サーバーから送信される難読化攻撃コード。 図 5:WebSocket 接続を介して C2 サーバーから送信される難読化攻撃コード。

コードの解読

難読化解除ツールを使用すると、状況が明確になり、攻撃の背後にある意図がわかります。図 6 に示されているとおり、このコード内には多数のキーワードが並んでいます。これらは、標的ページの機微なフィールドを特定し、攻撃者の制御下で偽の決済フォームを作成するように設計されています。 

攻撃者の最終目的は、何も知らない訪問者が感染ページとやりとりし、攻撃者のコードによって挿入された偽造フォームに個人情報を入力するように仕向けて盗むことです。

図 6 の 1 枚目:難読化解除後の攻撃コード。
図 6 の 2 枚目:難読化解除後の攻撃コード。 図 6:難読化解除後の攻撃コード

サードパーティープロバイダーの偽フォームの挿入

標的とされる店舗が決済プロセスをサードパーティープロバイダーに委託していることもあります。その場合、顧客は個人情報の提供後にサードパーティーベンダーにリダイレクトされ、そこでクレジットカード情報を入力して取引が完了します。スキマーはサードパーティーベンダーにはアクセスできず、エンドユーザーのクレジットカード情報を取得することはできません。

そのため、スキマーは 偽のクレジットカードフォームを作成し、 顧客がサードパーティーベンダーにリダイレクトされる前のページに挿入します(図 7)。ユーザーが偽の「精算」ボタンまたは[決済送信]ボタンをクリックすると、スキマーは収集したすべてのデータを C2 サーバーに送信するとともに、ユーザーを本物のサードパーティーベンダーの決済ページにリダイレクトし、正当な決済フローを続行できるようにします。

図 7:スキマーが生成した偽フォームの例。 図 7:スキマーが生成した偽フォーム

標的 Web サイトでサードパーティー決済ページへのリダイレクトが生じない場合には、スキマーは新しいフォームを作成しません。代わりに、精算ページと決済フォームに機微な個人情報が入力されるのを待ち受ける JavaScript リスナーを追加します。ユーザーが情報を送信すると、スキマーはデータを抽出し、WebSockets メッセージを使用して C2 サーバーに送信します。

いずれの場合も、スキマーは抽出したデータを暗号化するので、スキマーが開始した異常なネットワークアクティビティをリサーチャーやセキュリティサービスが検知するのは困難です(図 8)。

 

図 8 :WebSocket 接続を介してスキマーが送信する暗号化メッセージの例。 図 8:WebSocket 接続を介してスキマーが送信する暗号化メッセージの例。

攻撃の類似点

調査を行ったところ、攻撃被害にあった Web サイトがいくつか見つかりました。それらのすべてが同じキャンペーンに関連しているかどうかは確認できませんが、これらのケースには、同じ Magecart フレームワークを使用していると示唆される類似点がありました。たとえば、攻撃のインラインローダーが偽の Google Tag Manager に偽装され、パラメーターのエンコーディングによってスキマーの兆候が隠されるといった指標が、被害に遭った複数の Web サイトで発見されました。 

攻撃者が使用するドメインは Web サイトごとに異なり、ほとんどの場合、実際の攻撃コードは当該ページのローダーコードによって取得されるため、攻撃は目立たず検知しにくくなっています。

攻撃者のテクニックと機能のまとめ

  • Google Tag Manager のような既知のベンダーコードのスニペットになりすまします

  • Base64 エンコーディングを使用して、URL やドメインなど、攻撃者の指標を隠します

  • ブラウザーと C2 間のすべての通信に WebSocket を使用し、攻撃コードの取得やデータの抽出を行います 

  • 「eval」を使用して攻撃コードを実行するため、スクリプトがあたかもファーストパーティースクリプトであるかのように見えます

  • 難読化手法を使用して、リサーチャーによるコードの把握を難しくしています

  • 偽のフォームを挿入し、正当なサードパーティーの決済サービスページにリダイレクトされる前にデータを収集します

Akamai の Page Integrity Manager による防御

当社のチームが、最近の Magecart 攻撃を Akamai Page Integrity Manager でテストしたところ、攻撃はすぐに認識され緩和されて、トラブルシューティングに関する詳細情報が提供されました(図 9)。 

Page Integrity Manager は、Web スキミング、フォームジャッキング、 Magecart 攻撃に対処できます。Web ページのスクリプト実行のふるまいを可視化し、そのページで実行されるさまざまなスクリプトに関する情報(アクションや他のスクリプトとの関係など)を収集します。 

また、Page Integrity Manager は、こうしたデータをマルチレイヤー検知アプローチ(ヒューリスティック、リスクスコアリング、人工知能など)と組み合わせることで、クライアント側の脅威をすばやく検知し、防御できます。

図 9:Akamai Page Integrity Manager の詳細なトラブルシューティング情報。 図 9:Akamai Page Integrity Manager の詳細なトラブルシューティング情報

結論

Magecart のスキマーは絶えず進化し、ますます巧妙になっています。この投稿では、スキマーが使用している高度な回避と難読化の手法について取り上げました。これらは、このタイプの攻撃の検知を難しくしている要因となっています。 

攻撃者とのいたちごっこに終止符を打つためには、攻撃を検知して防御できる包括的なセキュリティソリューションが求められています。このようなソリューションを導入しないと、プライバシーの侵害によって顧客に深刻な被害をもたらし、会社の評判が大きく損なわれ、多額の罰金が科せられる可能性があります。 

最新の Payment Card Industry Data Security Standard(PCI DSS v4.0)に新たな要件が追加されたことで、ブラウザー内セキュリティは、オンラインでカード決済処理を行う組織にとって絶対に不可欠なものとなりました。 

詳細はこちら

Akamai Page Integrity Manager は、こうした新しい要件に対応するために役立ちます。 サイトで実行されているすべてのスクリプトのインベントリを提供し、スクリプトのふるまいを可視化して、最も巧妙なスクリプトベースの攻撃をも防御できます。

IOC

以下の脅威の痕跡情報(indicators of compromise、IOC)は、このブログで取り上げた悪性のアクティビティやスキマーを検知するうえで役立ちます。

  • yachtbars[.]fun

  • app-stat[.]com

  • Magento-cdn[.]net

  • nebiltech[.]shop

  • Rithdigit[.]cyou

  • Antohub[.]shop

  • Okqtfc1[.]org

  • jquery-node[.]com


こちらのページ で、スクリプトのふるまいを可視化し、クライアントサイドへの攻撃を防御する Akamai Page Integrity Manager の詳細をご覧ください。



Roman Lvovsky

執筆者

Roman Lvovsky

February 15, 2023

Roman Lvovsky

執筆者

Roman Lvovsky

Roman Lvovsky は、クライアント側の脅威、ブラウザー内部、JavaScript 攻撃ベクトルに関する豊富な経験を持つセキュリティ研究者です。Akamai の In-Browser Protection Research Team のメンバーであり、ウェブスキミングや Magecart 攻撃など、さまざまなクライアント側の脅威に関する研究に力を入れています。ソフトウェアエンジニアリングの分野で確固たる経歴を持ち、JavaScript と Web 開発を専門としています。