巧みな隠蔽：404 ページを悪用する新たな Magecart キャンペーン

バリエーション 1 のローダー：氷山の一角

スキマーは、 onerror 属性を持つ不正な形式の HTML image タグを、悪用された Web サイトに挿入することに成功しました（図 2）。この属性には、難読化され Base64 でエンコードされた悪性ローダー・コード・スニペットが含まれています。意図的に空にされた image タグの src 属性は、ネットワークリクエストを防止し、難読化された悪性 JavaScript コードスニペットを含むインラインの onerror コールバックの実行をトリガーするように設計されています。

JavaScript コードを実行する目的で image タグを使用することはあまり一般的ではなく、高度な手法です。この手法は、スキマーがセキュリティ対策（通常はネットワークトラフィックを分析する外部スキャナーなど）をバイパスするために役立ちます。このような場合、そのセキュリティ対策はトリガーされません。難読化されたコードは、ページ自体によって開始されたネイティブのファーストパーティースクリプトであるかのように、ページのコンテキスト内で実行されます。

デコードされたローダーコード — ランタイム

難読化され Base64 でエンコードされたコードがランタイムに実行されると、そのコードは単純な JavaScript に変換され、WebSocket チャネルを立ち上げる役割を担うようになります（図 3）。このチャネルは、ブラウザーと攻撃者の C2 サーバー間の双方向通信リンクとして機能します。

Magecart 攻撃での WebSockets の使用は、いくつかの最近のキャンペーンで確認されています。WebSocket は、より目立ちにくい柔軟性の高い通信方法であると考えられており、攻撃者は単一のネットワークチャネルをさまざまな目的で利用できます。これには、攻撃のさまざまな要素を C2 サーバーからブラウザーへ送信すること（およびその逆）や、特定のシナリオでのデータ窃取アクティビティを容易にすることが含まれます。

このコードのもう 1 つの注目すべき点は、ボット検知です。これにより、ユーザーエージェントが自動化制御を受けているかどうかをチェックします。そうであれば、コードの実行が終了します。これは、攻撃を検知する可能性のある外部セキュリティスキャナーとサンドボックスを回避することを目的とした、巧妙なアンチボット手法です。

WebSocket 通信フロー

WebSocket チャネルが確立されると、攻撃者の C2 サーバーからブラウザーに最初のメッセージが送信されます。このメッセージは、Base64 でエンコードされた文字列として送信されます。この文字列には、ページの現在の URL を返すようにブラウザーに指示する 1 行の JavaScript コマンドが含まれています。

このステップの目的は、現在のページがチェックアウト（機密）ページか、その他の非チェックアウトページかを、C2 サーバーが判断できるようにすることです。このようにして、攻撃者は次のステップを適宜調整できます。

このサーバー側の簡単な検証により、攻撃者は関連する標的ページのみで攻撃をアクティベートし、非機密ページで発覚するのを回避できます。これは、スキマーがセキュリティサービスと外部スキャナーによって検知を回避するために必要な作業を示すもう 1 つの例です。

C2 サーバーがチェックアウトページの URL を識別すると、フローは次の段階に進みます。このステップでは、別のメッセージがブラウザーに送信されます。これは Base64 でエンコードされた長い文字列であり、攻撃コード全体が含まれています。デコードされると、難読化された長い JavaScript コードが現れます（図 4）。

このコードは、ユーザーの機微な個人情報やクレジットカード情報を読み取ってスキマーの C2 サーバーに送信することを目的として、標的の機密ページでさまざまな悪性のアクティビティを実行する役割を担います。

その後、悪性コードによって収集され盗まれた機微な情報を含む、難読化されたデータ窃取メッセージが、ブラウザーから C2 サーバーに送信されます。前述のとおり、悪性コード全体のロードとデータ窃取に同じ WebSocket チャネルを使用することで、プロセスがより目立たなくなり、発生するネットワークリクエストが XHR、fetch、HTML リソースリクエストなどの従来の通信方法よりも少なくなります。

画像のリクエスト

偽の Meta Pixel コードスニペット内の疑わしい行を慎重に調べたところ、Web サイトのディレクトリーから PNG 画像が取得されたようでした。ネットワークリクエストは、Web サイトでホストされている無害な画像を求める通常のリクエストであるように見えます。しかし、この画像の実際の内容を調べたところ、見た目どおりに無害ではないことが明らかになりました（図 6）。

バリエーション 3 のローダー：同じに見えるが、まったく違う

一見すると、このローダーはバリエーション 2 のローダーと似ていますが、まったく異なるシナリオであることがわかります。場合によっては、このローダーはバリエーション 2 で見られたように Meta Pixel コードスニペットになりすまします（図 9）。しかし、その他の場合は、ページのランダム・インライン・スクリプト内に挿入されます（図 10）。

このローダーの注目すべき点の 1 つ目は、「icons」という相対パスへのフェッチリクエストです。

404 エラーが発生しましたか？本当ですか？

ローダーが実行されると、攻撃はフェッチリクエストを /iconsに送信します。これは、実際には存在しない相対パスです。このリクエストにより、「404 Not Found」エラーが発生します（図 11）。応答で返された HTML を分析すると、Web サイトのデフォルトの 404 ページのようでした（図 12）。これは紛らわしく、私たちが見つけた被害者 Web サイトでスキマーがアクティブではなくなったのかと疑問に思いました。

ローダーを過小評価してはなりません

一歩戻ってローダーを再分析したところ、欠けていたパズルのピースが見つかりました。ローダーに文字列「COOKIE_ANNOT」の regex マッチが含まれていたのです。この文字列は、icons リクエストの一部として返された 404 エラーページで実行されるものでした。

そこで、返された 404 HTML 内の文字列を調べたところ、「COOKIE_ANNOT」文字列を含むページの末尾に関する隠しコメントが見つかりました（図 14）。この文字列の横に、Base64 でエンコードされた長い文字列が連結されていました。このエンコードされた文字列は、難読化された JavaScript 攻撃コード全体を表します。ローダーはコメントからこの文字列を抽出し、デコードして、攻撃を実行します。この攻撃は、ユーザーが入力した個人情報を盗むように設計されています。

存在しないパスに対する追加のリクエストをシミュレートしたところ、すべてのリクエストで、エンコードされた悪性コードを伴うコメントを含む同じ 404 エラーページが返されました。 このチェックにより、攻撃者が Web サイト全体のデフォルトのエラーページを変更し、悪性コードを内部に隠したことが確認されます。

ユーザーが攻撃者の偽のフォームにデータを送信すると、エラーが表示され、偽のフォームが非表示になり、元の決済フォームが表示され、ユーザーは決済情報を再入力するよう求められます（図 16）。

盗まれたデータを含む画像リクエスト

偽のフォームが送信されると、攻撃者の C2 サーバーへの画像ネットワークリクエストが開始され、盗まれた個人情報とクレジットカード情報がすべて、クエリーパラメーター内の Base64 でエンコードされた文字列として転送されます（図 17）。この文字列をデコードすれば、リクエストの真の意図と攻撃フロー全体が明らかになります。

Akamai Client-Side Protection & Compliance 対スキマー

このキャンペーンの調査の一環として、このスキマー対 Akamai Client-Side Protection & Complianceのシミュレーションを実施しました。これは、ランタイム JavaScript 実行のふるまいを分析し、JavaScript の脅威を防ぎ、クライアントサイドの攻撃を緩和するソリューションです。

Client-Side Protection & Compliance は、高度なスキマーの検知に成功し、迅速な緩和のために重大度の高いイベントをトリガーしました。実際のシナリオでは、特定の Web ページで Client-Side Protection & Compliance が有効になっています。図 18 は、Web サイト所有者が受け取るアラートを示しています。このアラートにより、Web サイト所有者は脅威を迅速に調査し、さまざまな緩和オプションを使用してリアルタイムで対応することができます。