日本を標的としたChromElevatorベースのインフォスティーラー配布事例を追う

サイバーディフェンス研究所のスレットインテリジェンスアナリスト、川上です。

弊社は2026年6月、日本語の請求書通知を装ったメールを起点に、Google Sites、短縮URL、Google Driveを経て悪意のあるVHDファイルが配布された事例を解析しました。

VHD内の実行ファイル起動後、正規PDFビューワーを悪用したDLLサイドローディングと複数段のローダーを経て、最終的に公開版ChromElevatorをベースに改変されたインフォスティーラーが実行されることを確認しました。

また、日本向け配布検体のローダーと、インフォスティーラーの販売をうたうTelegramチャンネル「PWN Shop」に掲載された検体のローダーを比較したところ、関数構成と独自のローダー処理が一致しました。この結果から、両者は同一または極めて近いコードベースに由来する可能性が高いと判断しています。

地域・言語の観点では、日本向け配布検体とPWN Shop関連情報の双方で、ベトナムとの接点を示唆する痕跡を確認しました。

さらに、日本向けランディングページを手がかりにVHD配布前段を追跡したところ、複数言語で作成された類似のGoogle Sitesページが見つかりました。いずれも文書のダウンロードを促す内容で、ページ構成や誘導先にも共通点がありました。

本稿では、検体の配布経路と実行チェーン、ChromElevatorを基にした改変版インフォスティーラーの動作、PWN Shop掲載検体とのコード比較、地域・言語に関する痕跡、多言語ランディングページの調査結果を解説します。

1. 配布経路と実行チェーン

1.1 メールからVHDまで

2026年6月1日、日本語の請求書通知を装ったメールについて、リサーチャーの@tdatwja氏がX上で報告しました。メール内のリンク先には、文書のダウンロードを促すGoogle Sites上のランディングページが置かれていました。

ページ上の「今すぐドキュメントをダウンロード」ボタンをクリックすると、短縮URLiffii[.]com/japan3105とGoogle Driveを経由して、Invoice-6172.vhdへ到達することを確認しました。

日本語の請求書通知を装ったメール内リンク
  → sites.google[.]com/view/seikyu-6172
  → iffii[.]com/japan3105
  → drive.google[.]com/uc?export=download&id=1bD42RH3Lq9LK0cR3u95uF4QhT4fVyT-y
  → drive.usercontent.google[.]com
  → Invoice-6172.vhd

iffii[.]comは、URL短縮・リンク管理サービスShortenWorldで使用される短縮URL用ドメインです。本事例では、同ドメインがGoogle Sites上のリンク先に設定され、最終的にGoogle Driveへリダイレクトしていました。

1.2 VHD以降の実行チェーン

VHDのダウンロード後に続く実行チェーンの全体像を、以下の図に示します。

VHD内では、Invoice.pdf.exeへリネームされたPDFescape Desktopの正規PDFビューワーが、同一ディレクトリの悪性icudt63.dllを読み込みます。

icudt63.dllはpayload.encからStage 1ローダーを復号し、explorer.exeプロセスへインジェクションします。Stage 1ローダーはStage 2ローダーを実行可能な形式にメモリ内で動的に再構成します。Stage 2ローダーはchromelevator.exeを復号・展開し、explorer.exeプロセスへ手動マッピングします。

続いて、chromelevator.exeがペイロードDLLchrome_decrypt.dllをブラウザプロセスへインジェクションし、Telegram Bot APIを使用して収集物の送信を試行します。

2. ローダー解析

2.1 VHDの内容とDLLサイドローディング

Invoice-6172.vhdには、Invoice.pdf.exe、icudt63.dll、payload.encのほか、正規PDFビューワーの動作に必要なDLLが同梱されていました。

NTFSメタデータには、VHDの作成時刻として2026年5月30日 04:00 UTC頃、同梱ファイルの配置時刻として04:01 UTC頃が記録されていました。これは、メール経由の配布が報告された6月1日の約2日前に当たります。

Invoice.pdf.exeは、PDFescape Desktopの正規PDFビューワーをリネームしたものです。利用者がInvoice.pdf.exeを起動すると、同一ディレクトリの悪性icudt63.dllがDLLサイドローディングによって実行されます。

2.2 payload.encの復号とStage 1ローダーのインジェクション

icudt63.dllはDLL_PROCESS_ATTACHで処理を開始し、ホストEXEと同じディレクトリからpayload.encを読み込みます。payload.encは、ヘッダーとUUID形式のASCIIデータで構成されます。ヘッダーには、1バイトのマーカー値、4バイトのUUIDレコード数、16バイトのRC4鍵シードが格納されています。

次の16進表示では、マーカー値、UUIDレコード数、RC4鍵シードに続き、UUID形式のASCIIデータが連続して配置されている様子を確認できます。

UUIDレコード数は90,890です。UUID文字列を各16バイトのデータへ復元すると、合計1,454,240バイトの暗号化データが得られます。

変換時、icudt63.dllはハイフンを読み飛ばし、エンディアン変換を行わず、文字列内の16進数2桁を左から順に1バイトへ変換します。その後、1バイトのマーカー値と16バイトのRC4鍵シードから導出した鍵を使い、Stage 1ローダーを復号します。

icudt63.dllは通常のAPI呼び出しを用いず、ntdll.dll内のAPI名をハッシュで解決します。続いて、Stage 1ローダーをexplorer.exeプロセスへ書き込み、リモートスレッドを開始します。次のデコンパイル結果で、load_payloadの戻り値をリモートプロセスへ書き込み、スレッドを作成する処理が確認できます。

API解決とシステムコールの呼び出し方式には、GitHub上で公開されているDoomSyscallsと共通する処理が含まれていました。GET_NTDLL、GET_NTDLL_FUN、INIT_NTDLL_API、GET_PROC_IDなどは、DWARF情報から取得したバイナリ内部の関数名です。これら関数名やその処理内容もDoomSyscallsの実装と対応します。

一方、payload.encの読み込み、UUID文字列の変換、RC4復号を担うload_payloadは、本分析で参照した公開版DoomSyscallsには存在しません。このため、開発者により別途追加された処理と評価しています。

2.3 Stage 2ローダーの再構成と後段PEの手動マッピング

explorer.exeプロセスへインジェクションされたStage 1ローダーは、独自形式のデータからStage 2ローダーを動的に組み立てます。再構成されたStage 2ローダーは、暗号化されたchromelevator.exeのPEを復号・展開し、explorer.exeのプロセスメモリへ手動マッピングします。以下では、Stage 1ローダー内の各データ領域を便宜上「Stage 2 Loader Object」「Encoded Stealer Object」「Decoded Stealer Object」と呼びます。

Stage 1ローダーからchromelevator.exeの実行までの流れを、次の図に5段階で示します。

Stage 2 Loader Objectは、複数の要素を連続して格納した独自形式の構造です。格納されるのは、実行コード、PEのベース再配置に使うデータ、再配置用テーブル、メモリ・スレッド管理領域の位置、パッチ先情報、モジュール名、APIハッシュ、復号鍵です。Stage 1ローダーは、ヘッダーに従って各要素を読み出し、確保したメモリへ配置します。

配置後、Stage 1ローダーはベース再配置用データとエンコードされたモジュール名をXOR復号し、パッチ先情報に従ってStage 2ローダーへパッチを適用します。処理前のコードでcall $+5となっている箇所は、再構成後には実際の関数アドレスやAPIを参照する呼び出しに置き換わります。

呼び出し先が実行時にパッチされるため、再構成前のコードを静的に確認するだけでは実際の制御フローを追えません。次の図では、再構成前のコードを左側、再構成後のコードを右側に示します。

再構成されたStage 2ローダーは、Encoded Stealer Objectの復号・展開とPEの手動マッピングを担います。まず、ヘッダーから圧縮フラグ、復元後のサイズ、暗号化データのサイズを取得します。次に、暗号化データの後ろに格納された鍵を読み出します。

続いて、データ全体をXOR復号します。圧縮されていなければ、復号したデータをそのままコピーします。圧縮フラグが設定されていれば、LZNT1で展開します。本事例では、LZNT1による展開経路が使われていました。

LZNT1展開後のDecoded Stealer Objectは、長さ付きのコマンドラインデータと、PEファイル形式のchromelevator.exe本体で構成されます。コマンドラインデータにはASCII文字列chromelevator.exe が格納されていました。このデータは、手動マッピングしたPEを通常のEXEに近い形で初期化するためのargc/argv相当の起動コンテキストの構築に使われます。

コマンドラインデータの直後には、PEサイズとMZヘッダーから始まるchromelevator.exeのPEが続きます。

Stage 2ローダーは起動コンテキストを用意し、chromelevator.exeをexplorer.exeのプロセスメモリへ手動マッピングします。その後、新しいスレッドからエントリーポイントを実行します。デコンパイル結果には、圧縮フラグとサイズの読み込み、XOR復号、コピーまたはLZNT1展開、後続PEの手動マッピングまでの処理が一続きで確認できます。

3. ChromElevatorベースのインフォスティーラー

Stage 2ローダーが実行するchromelevator.exeと、同コンポーネントがブラウザプロセスへインジェクションするchrome_decrypt.dllは、GitHub上で公開されているChromElevatorのコードベースに由来すると評価しています。

公開版の構成にならい、本稿ではchrome_decrypt.dllを「ペイロードDLL」と呼びます。chromelevator.exeは公開版のInjectorに相当しますが、本事例では機能が拡張されているため、以下では「コントローラー」と表記します。

本節では、両コンポーネントによるABE鍵の取得、認証情報の収集、外部送信までの実行チェーンを説明し、最後に公開版との差分を整理します。

3.1 対象ブラウザとペイロードDLLのインジェクション

コントローラーchromelevator.exeには、Chrome、Chrome Beta、Edge、Brave、Avast Secure Browser、Cốc Cốc、Naver Whaleの実行ファイル名が保持されています。対象ブラウザがインストールされている場合、CreateProcessWの作成フラグにCREATE_SUSPENDEDを指定し、新しいブラウザプロセスをサスペンド状態で起動します。

続いて、内部に格納されたchrome_decrypt.dllを、固定の鍵とノンスを用いたChaCha20で復号します。復号したDLL本体（PE形式）と名前付きパイプのパスをサスペンド状態のブラウザプロセスへ書き込んだ後、chrome_decrypt.dllのエクスポート関数Bootstrapを開始アドレスとしてリモートスレッドを作成します。

Bootstrapは、ブラウザプロセス内に書き込まれたPEを別のメモリ領域へリフレクティブにマッピングします。続いて、再配置、インポート解決、セクション保護の設定を行い、DllMainを呼び出します。

DllMainから起動されたワーカースレッドは、指定された名前付きパイプへクライアントとして接続し、以降の鍵取得とブラウザデータ処理を担います。

3.2 ブラウザプロセス内でのABE鍵取得

Googleによる解説によると、App-Bound Encryption（ABE）は、暗号化データをブラウザの識別情報に結び付けることで、別プロセスからの復号を困難にする仕組みです。

ChromElevatorリポジトリ内のドキュメントには、ペイロードDLLをブラウザプロセスへインジェクションし、ブラウザと同じ実行コンテキストからCOMサーバーを呼び出してABE鍵を取得する手法が記載されています。

本事例のchrome_decrypt.dllも同様に、ブラウザプロセス内からABE鍵の復号に用いられるCOMサーバーへアクセスします。取得した鍵は、v20プレフィックス付きのクッキーやパスワードなどをAES-GCMで復号するために使用されます。

3.3 認証情報の収集とローカル保存

復号した認証情報は、%LOCALAPPDATA%配下に作成した、ランダムな英数字6文字からなるサブディレクトリへ保存されます。主な収集元と出力ファイルの対応は次のとおりです。

ペイロードDLLとコントローラーは、名前付きパイプを介して連携します。コントローラーがペイロードDLLへ実行設定を送り、ペイロードDLLからは復号鍵、収集件数、処理状態、完了通知などが返されます。

一方、認証情報そのものは名前付きパイプを経由しません。ペイロードDLLがローカルへ保存したファイルを、コントローラーが回収する構成です。

3.4 圧縮・Telegram送信と後処理

収集完了後、コントローラーはip-api.comから国コードとパブリックIPを取得します。続いて、出力ディレクトリ全体を、パスワードtestで保護されたAES-256暗号化ZIPファイルにまとめます。ZIPにはmoixd-という接頭辞が使われ、次の規則で命名されます。

%LOCALAPPDATA%\moixd-<countryCode>-<publicIP>.zip

送信先となるTelegramチャットIDは、C:\Users\Public\@atony83866というマーカーパスの有無に応じて切り替わります。

マーカーパスが存在しない初回実行時には、初回用のチャットIDが選択され、情報収集と圧縮の完了後に同じパスが作成されます。すでに存在する場合は別のチャットIDが選択されるため、初回実行時と2回目以降では送信先が異なります。

コントローラーはWinINetを使用し、api.telegram.orgのTelegram Bot APIエンドポイントsendDocumentへ、ZIPをmultipart/form-data形式でPOSTして送信を試みます。デコンパイル結果からは、api.telegram.org、/bot、/sendDocumentを連結し、エンドポイントを組み立てる処理を確認できます。

送信処理後は、Telegram Bot APIを介した送信試行の成否にかかわらず、収集ファイルを格納したディレクトリとZIPを削除します。

抽出したchromelevator.exeを隔離環境で単体実行したところ、対象ブラウザ、ABE鍵、プロファイルごとの収集件数、保存先、生成したZIP、Telegramへの送信試行結果がコンソールへ出力されました。実際の実行チェーンではローダーから起動されるため、単体実行時に確認したコンソール出力が被害者に明示されるわけではありません。

以上の解析範囲では、認証情報の収集、外部送信の試行、収集物の削除までの挙動が確認された一方、レジストリ、サービス、タスクスケジューラ、スタートアップフォルダなどを利用した永続化処理は見つかりませんでした。

3.5 公開版ChromElevatorとの差分

本事例と公開版に共通するのは、ブラウザプロセスのサスペンド起動、ペイロードDLLのインジェクション、名前付きパイプによるコンポーネント間の連携、COMサーバーを介したABE鍵の取得です。実行ファイル側がペイロードDLLをブラウザプロセス内で動作させ、ペイロードDLL側がABE鍵の取得とブラウザデータ処理を担う役割分担も、公開版のInjectorとPayload DLLの構成に対応しています。

差分は主にコントローラー側にあります。公開版のInjectorが、主にペイロードDLLのインジェクションと復号済みデータの回収を担うのに対し、本事例のchromelevator.exeは、収集物の圧縮、Telegram Bot APIを介した外部送信、送信先の切り替え、生成物の削除まで制御します。これにより、Injectorとしての機能に加え、情報の収集から外部送信、後処理までを統括するコントローラーとしての役割を備えています。

確認した主な差分は次のとおりです。

4. PWN Shop掲載検体とのコード比較

chromelevator.exeは、Telegram送信先の切り替えに、前節で示したマーカーパスC:\Users\Public\@atony83866を使用します。次の画面には、このマーカーパスを参照する処理が現れています。

このマーカーパスに含まれる@atony83866を起点に公開情報を調査したところ、インフォスティーラーの販売をうたうTelegramチャンネル「PWN Shop」（t[.]me/boost/pwn_shop）の購入問い合わせ先として、同じ@atony83866が案内されていました。

この一致を調査上の手掛かりとしてPWN Shopの投稿を調べたところ、投稿時点の検知数が0件であることをうたい、VirusTotalへのリンクとともに掲載された検体が5件ありました。次の画面は、このうち2026年5月24日に掲載された検体の投稿です。

以下では、2026年5月24日に掲載されたこの検体を「PWN Shop比較検体」と呼び、日本向け配布検体に同梱されたicudt63.dllと比較します。

4.1 Diaphoraが対応付けた82関数と独自ローダー処理

比較対象は次のとおりです。

両検体をDiaphoraで比較した結果、IDAが各検体で認識した82関数は、すべて対応付けられました。対象には、ユーザー定義関数、ライブラリ関数、転送用の小関数であるthunkが含まれます。

対応付けは、命令バイト列ハッシュ、サイズ、基本ブロック構成などの一致に基づきます。いずれの関数も、最高類似度のRatio 1.0000000、100% equalと判定されました。判断上重要なload_payloadも同じ判定です。次の画面は、主要な結果を抜粋したものです。

ただし、この判定の対象は関数本体であり、参照先データやファイル全体のバイト列の一致を示すものではありません。実際、load_payloadの処理実装は一致する一方、参照する文字列は、日本向け配布検体ではpayload.enc、PWN Shop比較検体ではupdate.datと異なっていました。

load_payloadを含む全82関数が一致したことから、2つのローダーは同一または極めて近い実装に由来する可能性が高いと判断しています。また、@atony83866の一致は、日本向け配布検体セットとPWN Shopの接点を示します。一方、これらの一致だけでは、この日本向け攻撃をPWN Shopの運営者自身が行ったのか、PWN Shopから検体を入手した別の主体が行ったのかを切り分けられない点に注意が必要です。

5. 配布検体と外部サービスにみられる地域・言語の痕跡

本節では、日本向け配布検体に残された言語上の痕跡と、PWN Shopのチャンネルおよび掲載検体について外部サービス上に表示された地域情報を、それぞれ整理します。

5.1 バイナリ内のベトナム語文字列

日本向け配布検体のchromelevator.exeには、Kết quả（結果）、Thành công（成功）、Thất bại（失敗）などのベトナム語文字列が残っていました。

5.2 Telemetr上のチャンネル情報

Telemetrは、Telegramチャンネルの検索機能や統計情報を提供するWebサービスです。同サービス上のPWN Shopページには、購入に関する問い合わせ先@atony83866と、Vietnamタグが表示されていました。次の画面は2026年6月に確認した記録で、両方の表示が確認できます。

5.3 GTI上の国・都市表示

日本向け配布検体とのコード比較に使用したPWN Shop掲載検体をGoogle Threat Intelligence（GTI）で確認したところ、File OverviewにはFirst seenとともに国情報Viet Namが表示されていました。

同チャンネルの掲載検体計5件についてGTI上の表示を整理したところ、国・都市情報はいずれもViet Nam, Haiphongでした。結果を次の表に示します。

表中のeditedは、Telegram投稿が編集されたことを示します。該当する投稿の正確な初回投稿日時は不明です。

5.4 観測結果の整理と限界

日本向け配布検体に残されたベトナム語文字列は、開発時の言語環境やコードベースの由来と、ベトナム語圏との接点を示唆する痕跡です。一方、TelemetrのVietnamタグは、PWN Shopチャンネルに対して外部サービス上で付与された分類情報であり、バイナリ自体から得られた情報ではありません。

GTIのViet Nam, Haiphong表示は、PWN Shop掲載検体に付随する地域情報です。ただし、この情報が検体の開発者、PWN Shopの運営者、あるいは検体を入手してGTIへ提出した第三者のいずれに由来するのかは特定できません。

このように、3つの観測はいずれもベトナムとの何らかの接点を示唆するものの、それぞれ情報の対象と由来が異なり、開発、販売、流通・提出といった異なる段階にひも付く可能性があります。したがって、これらを同一の人物や組織に帰属させることや、開発者、PWN Shopの運営者、日本向け配布を行った主体のいずれに結び付く情報であるかを切り分けることは、現段階では困難です。

6. 類似する多言語ランディングページ

本節では、日本向けページを起点に追跡した、複数言語の類似Google Sitesページについて整理します。

日本語ページが単独の事例であるかを確認するため、HTMLの構造的特徴を表すVirusTotal独自の類似性ハッシュvhashを軸に、ページタイトル、表示名、レイアウト、リンク先を追跡しました。検索に使用したvhashは38d68d9664a94bdf8353b79982b51735です。

追跡の結果、7言語で作成された類似のGoogle Sitesページ10件が見つかりました。GTIのFirst Submissionは、いずれも2026年5月27日から7月14日までの期間に記録されています。ダウンロードボタンのリンク先は、9件がiffii[.]com、残る1件がformat[.]asiaでした。

以下の図は、その代表例として、ポーランド語、ドイツ語、イタリア語、韓国語のページを並べたものです。いずれもVespera Financial Groupを名乗り、文書ダウンロードポータルを装っています。表示言語は異なるものの、ページの構成やデザインはよく似ています。

このほか、Vireon Financialを名乗るクロアチア語ページ、Velora Digitalを名乗るデンマーク語ページ、Vora Groupを名乗るポーランド語ページなども確認しました。表示名には、Vespera Financial Group、Velora Digital、Velta Group、Vireon Financial、Vora Groupのように、先頭が「V」の名称が共通して使われています。ページタイトル、vhash、レイアウトにも類似点がみられました。

確認したランディングページについて、GTIへの初回提出日時、使用言語、ページURL、ダウンロードボタンのリンク先を次の表に示します。

これらのページは、日本向けVHD配布前段で使われたGoogle Sitesと同様のページ構成や、ダウンロードボタン内に短縮URLを含む点が共通していました。ただし、各ページの後段で同一または類似のペイロードが配布されていたことや、すべてが単一のキャンペーンに属していたことまでは確認できていません。

7. まとめ

本分析では、日本向け配布事例の攻撃フローを明らかにするとともに、ローダーのコード一致や共通する識別子などから、PWN Shop掲載検体との強い技術的接点を確認しました。

また、VHD配布前段のランディングページでは、多言語で作成された類似のGoogle Sitesページを確認しました。これらの存在は、本事例が複数地域を対象とした配布活動の一部であった可能性を示唆しています。

請求書や税務関連の通知など、業務上の連絡を装う日本語メールは、マルウェア配布やフィッシングの起点として継続的に悪用されており、今後も十分な警戒が求められます。

8. IoCと参考データ

8.1 ネットワークIoC

8.2 ファイルIoC

8.3 VHD内に記録されたSID

初回マウント前のVHDをAutopsyで確認したところ、$RECYCLE.BIN配下に、SID S-1-5-21-2812598216-504917342-412829475-1001を名称とするディレクトリが残されていました。

このSIDは、VHDの準備または操作に使用された環境に由来すると考えられます。