マルウェアファミリー「OpenSUpdater」の攻撃者は、再コンパイルした7-Zip自己展開（SFX）アーカイブのコンポーネント内にリフレクティブローダーを隠しています。これにより、悪意あるコードは一見正規のインストーラーに紛れ込み、従来のトリアージをすり抜けます。
攻撃者は、悪意ある実行ファイルを埋め込むだけにとどまりません。展開スタブそのものに手を加えています。展開スタブとは、埋め込まれたアーカイブを展開し、ファイルをディスクに書き込み、設定されたプログラムを起動するコードです。
この手口によって、悪意ある実行経路は、アナリストが日常的に信頼できる標準の7-Zipコンポーネントとみなしがちな領域へ移ります。
分析対象となったOpenSUpdaterのサンプルは、setup.exeという名前の正規のfoobar2000インストーラーを7-Zip SFXアーカイブに格納していました。
これらのファイルには、ゲームアプリ開発元とされるAnimated Productions, LLCの署名があるとのことです。
署名自体は有効ですが、無関係な発行元が正規のオーディオプレーヤーのインストーラーを配布している点で、出所に明らかな不一致があります。
サンプルには、同じバイトパターンが繰り返される、異常に肥大化した証明書データも含まれていました。
ComputerScience
証明書にパディングを施すと、署名を無効にすることなく、ビルドごとにファイルのハッシュ値を変えられます。これはハッシュベースの検出を難しくし、攻撃者が見た目の異なるマルウェアを量産することにもつながります。
証明書データがファイルに占める割合は約2.6%にすぎないと報告されています。このため、パディングの目的が、自動化されたサンドボックスのファイルサイズ制限を回避することだけとは考えにくいでしょう。
通常の7-Zip SFXパッケージでは、アナリストはまず2か所を調べます。平文のSFX設定と、アーカイブされたペイロードです。
設定には、インストーラーのウィンドウタイトルや表示テキスト、埋め込みファイルの実行に使うRunProgramディレクティブなどが記述されています。
通常はsetup.exeが主な実行対象です。そのため、静的解析でも最初に注目しやすいファイルとなります。
OpenSUpdaterは、この思い込みを突きます。正規に見えるペイロードと通常どおりのSFX設定によって、実際にローダーが潜む展開スタブから注意をそらしているのです。
研究者は、7-Zip SFXのExtractArchiveルーチン内で、プログレスバーの初期化の直前に悪意あるコードが挿入されていることを突き止めました。
分析したサンプルの一つでは、ローダーの呼び出しがアドレス0x421400にありました。これに対応する正規の7-Zipのソースロジックは、CPP/7zip/Bundles/SFXSetup/ExtractEngine.cppにあります。
GDatasoftwareがGBhackersに共有したレポートによると、このマルウェアの手口は、開発者が簡易インストーラーの配布によく使う7-Zip SFX（自己展開アーカイブ）の仕組みを悪用するものです。
OpenSUpdaterマルウェア
挿入位置は意図的に選ばれています。インポートや文字列、エントリポイント、主要な制御フローを簡単に確認しただけでは、スタブが正規のSFXモジュールと変わらないように見えるためです。
攻撃者は、目立つ新規の実行可能セクションや不審なエントリポイントを作らず、本来の展開関数の途中にローダーを挿入しています。その結果、アナリストが迅速な検査の段階で改ざんされたコードに気づく可能性は低くなります。
埋め込まれたローダーには、3つの中核機能があります。C2ビーコン、コンポーネントのダウンロード、そしてメモリ上でのペイロード実行です。
ローダーは難読化されたルーチンでコマンド＆コントロール（C2）のURLを取得し、固有のマジックバイト列を使ってサーバーに登録します。このバイト列は、クライアントの識別マーカーとして機能している可能性があります。
続いて、静的にコンパイルされたcURLの機能で、2つのDLLと暗号化されたブロブをダウンロードします。まず1つ目のDLLのエクスポートcx1を呼び出します。その後、2つ目のDLLのcx2エクスポートを呼び出し、ブロブを復号します。
復号されるのは別のDLLで、メモリ上にリフレクティブにマッピングされます。ローダーはそのエクスポートcx3を実行します。従来のようなディスク上の実行ファイルを使わずに、最終的なペイロードを起動しているとみられます。
この活動は7-Zipに限りません。ほかにも、NSISインストーラーが使うオープンソースライブラリ（EmbedHtmlプラグインなど）を改変した亜種が確認されているとのことです。
この亜種では、ローダーはEmbedHtml::GetUrl()に挿入されており、関数が空文字列の引数を受け取ったときだけ動作します。C2アドレスは、NSISスクリプト内の圧縮ブロブから復元されます。
こうした手口は、OpenSUpdaterに関連する従来のパターンを踏襲しています。
GoogleのThreat Analysis Groupは2021年に、このマルウェアが不正な形式のコード署名構造を使っていたと報告しました。Windowsはこの構造を受け入れる一方、OpenSSLベースの解析では拒否されます。そのため、サンプルは一見有効な署名を保ったまま、一部のセキュリティツールによる解析を妨げていました。
SecurityProducts & Services
防御側は、インストーラーの中のインストーラー、発行元とペイロードの不一致、異常なバージョンメタデータ、パディングされた証明書構造を、トリアージで重視すべき指標として扱う必要があります。
セキュリティチームは、SFXスタブを信頼できるアップストリームのビルドと比較し、展開モジュールの制御フローに改変がないかを確認すべきです。あわせて、インストーラーのプロセスによる想定外の外部通信も監視してください。
OpenSUpdaterのキャンペーンは、信頼されたオープンソースのコードも、攻撃者が再コンパイルして巧妙にパッチを当てれば、有効な隠れ蓑になり得ることを示しています。
今回、最も危険なコードは、目に見えるインストーラーのペイロードではありません。見過ごされがちな展開コンポーネントです。インストールが始まったように見える前に、すでに起動しています。
SOCのアラート調査を1件あたり21分短縮。即座に対応できるよう、IOCのコンテキストをSOCに取り込みましょう： SOCにTI Lookupを導入
翻訳元: https://gbhackers.com/opensupdater-malware/
