Windowsパッカーpkr_mtsi、複数のマルウェアを用いた大規模マルバタイジングキャンペーンを支援

新たな調査によると、 pkr_mtsi と呼ばれるカスタムWindowsパッカーが、大規模なマルバタイジングおよびSEOポイズニング(検索汚染)キャンペーンを後押ししており、情報窃取型やリモートアクセス型など幅広いマルウェアを配布しているという。

このパッカーは2025年4月24日に野外で初めて確認されて以降も活動を続け、過去8か月の間に継続的に進化している一方で、堅牢な検知に適した安定した行動コアを維持している。

脅威アクターはpkr_mtsiを用いて、正規ソフトウェアのトロイの木馬化されたインストーラーを包み込み、人気ツールに対するユーザーの信頼を悪用して初期侵入を得ている。

確認された誘導手口には、 PuTTY、Rufus、Microsoft Teamsなどのユーティリティを装った偽版が含まれ、これらは有料のマルバタイジングと攻撃的なSEOポイズニングによって検索結果で上位に表示される 偽のダウンロードポータル 経由で配布されている。

これらのキャンペーンは正規の配布フローを模倣しているものの、正規ベンダーのサプライチェーン侵害を示す証拠はなく、脅威の本質は欺瞞的なWebインフラと汚染された検索可視性にある。

研究者は次のように指摘している。pkr_mtsiは単一ペイロードのラッパーではなく 汎用ローダー として機能する。キャンペーン全体を通じて、Oyster、Vidar、Vanguard Stealer、Supperなど、複数のマルウェアファミリーの配布に使用されてきた。

Windowsパッカーpkr_mtsi

この柔軟性により、オペレーターは配布インフラをほとんど変更せずにペイロードを入れ替えたり組み合わせたりでき、同一のマルバタイジング導線を、犯罪エコシステム内で変化する収益化目標や提携関係に合わせて運用できる。

挙動の観点では、このパッカーの初期段階の活動はメモリ割り当てが支配的で、その後、単一の連続領域に対する集中的なメモリ書き込みが続く。

Image
旧サンプルと最近のサンプルにおけるmain内の最初の関数群( pkr_mtsi)。

防御の観点では、pkr_mtsiはいくつかの信頼できる指紋を残す。純粋に汎用的ではないアンチウイルス検知では、 「oyster」 や 「shellcoderunner」 といった部分文字列が含まれることが多く、また 「TextShell」 という名称の公開YARAルールが1つ存在するが、対象はサンプルの一部に限られる。

最近の研究では、より広範な構造的・行動的特徴を統合し、既知のpkr_mtsi亜種すべてに一致するよう設計された 包括的なYARAルール を提示している。これは、レトロハンティング結果により「oyster」および「shellcoderunner」系の脅威として一貫して分類されることに裏付けられている。

技術的には、pkr_mtsiは特徴的なアンパックモデルを示す。観測されたすべての亜種で、 main から呼び出される最初のカスタム関数が次段階用のメモリを割り当て、その段階を、即値として埋め込まれた 1〜8バイトの多数のチャンク から再構成する。

初期のサンプルは直接 VirtualAlloc を呼び出すが、新しいビルドでは難読化された ZwAllocateVirtualMemory 呼び出しに切り替わり、パラメータが分散され、ジャンク命令と交互に挿入されている。

Image
次段階用のメモリを割り当てる関数( VirtualAllocを使用)。

続いて、割り当てられた領域を埋める「書き込み専用」のヘルパー関数が高密度に連なり、意味のある制御フローがほとんどないまま 小さなメモリ書き込みが集中的に行われる という識別しやすいパターンが形成される。

DLL形態では、pkr_mtsiは複数の実行パスをサポートしており、ロード時の実行や、 DllRegisterServer などのエクスポート関数経由の実行が含まれる。これにより regsvr32ベースの実行と永続化 が可能になる。

緩和策

中間段階は 改変されたUPXモジュール で、主要なマーカーが意図的に削除されている。攻撃者は、実行可能性が保たれる限り、DOS/PEヘッダー、UPXマジック値、テキストリソースを選択的に除去し、静的シグネチャベースの検知や自動アンパックを困難にしている。

後期世代のパッカーでは追加の難読化が導入されている。平文のAPI名やDLL名から、PEBトラバーサルによる ハッシュベースの解決 へ移行し、静的・動的解析を妨げるために GDI APIへのジャンク呼び出し を広範に挿入し、モジュールリストを走査してエクスポートを解決するカスタムルーチンも備える。

Image
DLLハンドルの取得を試み、失敗時にロードする。

こうした回避策にもかかわらず、全体アーキテクチャは安定している。すなわち、最初のpkr_mtsi層、劣化させたUPX中間層、そして最終的なマルウェアペイロードである。

研究者は、防御側が活用できるいくつかの 解析妨害および実装上の癖 も強調している。

このパッカーは、 IsDebuggerPresent や CheckRemoteDebuggerPresent といったデバッガ検知APIを常用し、検知時には自己参照的な無限ループへ実行を流し込むことがある。これはコードと挙動の両面で信頼性高くハンティング可能なパターンである。

さらに注目すべき点として、 NtProtectVirtualMemory の繰り返し呼び出しで 無効な保護フラグ が使用され、常にエラー STATUS_INVALID_PAGE_PROTECTION (0xC0000045) が発生する。

このバグは、特にパッカー特有の「メモリ割り当て+高密度書き込み」パターンと相関させた場合、EDRテレメトリにおいてシグナルの強い行動指標となる。

運用面では、これらの特徴は具体的な防御機会へとつながる。セキュリティチームには、決定論的な初期段階の割り当ての後に、単一領域へ即値による微小書き込みが連続して発生すること、そして難読化された ZwAllocateVirtualMemory 解決に焦点を当てた 行動ベース検知 を優先することが推奨される。

インシデント対応者にとっては、pkr_mtsiの段階的設計と、regsvr32駆動のロードを含むDLLベースの実行パスに精通しておくことで、トリアージ、アンパック、そしてパッカー挙動と基盤となるペイロードの切り分けを迅速化できる。

最新の研究は主としてパッカー自体に焦点を当てているが、アナリストは、下流のUPX段階および関連するペイロードファミリーについて、より深いカバレッジが今後のレポートで続くと示している。pkr_mtsiは引き続き、Windowsエコシステム全体にわたる マルバタイジング起点の侵入チェーンの広範な基盤 となっているためだ。

翻訳元: https://gbhackers.com/windows-packer-pkr_mtsi/

ソース: gbhackers.com