乐胖代购免代理版

初めに
BloodAlchemy の解析
Deed RAT とコードの類似性
最後に
Appendix

This post is also available in: English

初めに

本記事では弊社が観測した攻撃キャンペーンにて使用されていた BloodAlchemy と命名されているマルウェアの解析結果を解説します。
BloodAlchemy は2023年10月に Elastic Security Lab によって調査結果の公開とともに命名された新しい RAT です。¹ しかし、私たちは調査の結果、BloodAlchemy は完全に新種のマルウェアではなく、ShadowPad の後継である DeedRAT のさらなる進化版であることを発見しました。

まず、ShadowPad について確認します。 ShadowPad は APT キャンペーンで使用されるマルウェアの中でもとりわけ悪名高いファミリーの一つで、2017年7月に発生したソフトウェアのサプライチェーン攻撃で初めて利用が観測されました。この攻撃キャンペーンでは、NetSarang 社が提供する企業ネットワーク向けサーバー管理ソフトウェアのコードライブラリの一つに ShadowPad が埋め込まれており、当該ソフトウェアを利用する幅広い企業が被害者となりました。²
2019年初期は APT41 のみが ShadowPad を使用していると考えられていましたが、2020年以降はさまざまな APT グループによって利用された可能性があると多くのセキュリティベンダーが報告しています。³

次に、Deed RAT について確認します。Deed RAT はその実装から少なくとも2017年から活動している脅威グループ Space Pirates によって使用された RAT と推定されています。また、positive technologies 社のセキュリティチームによると Deed RAT は ShadowPad とコードの類似性が高いことから、 ShadowPad の進化版ではないかと示唆されています。⁴

そして今回取り上げる BloodAlchemy ですが、Elastic Security Lab 社の分析によるとこのマルウェアは正規のバイナリを使用して悪意のある DLL をロードする仕組みや複数の実行モード、永続化メカニズム、C2 と通信する際に通信プロトコル毎に対応した関数をインポートする等の特徴をもち、現在も攻撃者によって継続して開発されている新種のマルウェアとされています。

ここまで紹介した、ShadowPad、Deed RAT、BloodAlchemyに関する公開情報を時系列で確認すると以下の通りとなります。

図1. ShadowPad、Deed RAT、BloodAlchemy に関する公開情報と変遷

図1の出典

[1] ShadowPad in corporate networks

[2] Operation ShadowHammer: a high-profile supply chain attack

[3] Cyber Espionage Tradecraft in the Real World Adversaries targeting Japan in the second half of 2019

[4] Space Pirates: analyzing the tools and connections of a new hacker group

[5] ShadowPad: the Masterpiece of Privately Sold Malware in Chinese Espionage

[6] Operation StealthyTrident: corporate software under attack

[7] APT Threat Landscape in Japan 2020

[8] RedHotel: A Prolific, Chinese State-Sponsored Group Operating at a Global Scale

[9] Chinese State-Sponsored Activity Group TAG-22 Targets Nepal, the Philippines, and Taiwan Using Winnti and Other Tooling

[10] Attacks on industrial control systems using ShadowPad

[11] Redfly: Espionage Actors Continue to Target Critical Infrastructure

[12] Space Pirates: a look into the group's unconventional techniques, new attack vectors, and tools

[13] Introducing the ref5961 intrusion set

BloodAlchemy の解析

感染経路と感染フロー

我々が分析をした事案では、攻撃者は BloodAlchemy の感染経路として、VPN 機器にある保守ベンダー専用アカウントを乗っ取った上で BloodAlchemy に感染させるためのファイルセットを使用していました。図2に感染フローを示します。

感染ファイルセットにはBrDifxapi.exe, BrLogAPI.dll, DIFXといった３つのファイルが含まれており、C:\windows\ 配下に設置されていました。また、当該ファイルを配置後に、スケジュールタスク（C:\Windows\System32\Tasks\Dell\BrDifxapi）を作成し、永続化を実施していることがわかります。（以下図参照）

悪性 DLL の解析

永続化処理によって感染ホスト上でBrDifxapi.exeが実行されると、DLL side-loading を悪用し、同じフォルダ内の悪性 DLL ファイルであるBrLogAPI.dllが読み込まれます。その後、この悪性 DLL は同じフォルダ内のDIFXを読み込み、読み込んだデータから Shellcode を復号し、メモリ内でこの Shellcode を実行します。Shellcode の復号に使われているアルゴリズムは AES128(CBC モード)であり、鍵はDIFXファイルの先頭16バイトであることが解析結果からわかりました。

Shellcode の解析

DIFXから復号された Shellcode には、BloodAlchemy が暗号化され、かつ圧縮されて埋め込まれています。この処理は FNV-1a ハッシュアルゴリズムを用いた独自アルゴリズムと lznt1 という圧縮アルゴリズムを併用して実装されています。

FNV-1a ハッシュアルゴリズムとは

1991年に Glenn Fowler と Phong Vo によって IEEE POSIX P1003.2 委員会に審査者コメントとして送信されたアイデアに基づき、そののちに Noll によって改良されたハッシュアルゴリズム。FNV は作成者の名前を連ねた Fowler-Noll-Vo の略称である。

DNS サーバー、X(旧Twitter)サービス、データベースのインデックスハッシュ、主要なウェブ検索/インデックスエンジン、netnews の履歴ファイルの Message-ID 検索機能、スパム対策フィルターなど様々な用途で広く使用されている。

The FNV Non-Cryptographic Hash Algorithm

LZNT1 圧縮アルゴリズムとは

RtlDecompressBuffer という Windows API を呼び出すことで手軽に使用できる圧縮アルゴリズム。

LZNT1 Algorithm Details | Microsoft Learn

復元された BloodAlchemy 本体には、PE フォーマットによく似ているものの PE とは異なる独自フォーマットが採用されていることがわかりました。以下、独自フォーマットのデータ構造を示します。

offset	Descriptions	Data
0x00	magic number	45 AB 45 AB
0x04	plugin id	0x10
0x08	entry point	0x698c
0x0c	original base	0x400000
0x10	absolute offset	0
0x14	size of virtualalloc	0x17000
0x18	size of raw data	0x16fab
0x1c	size of unknown	0x163bc
0x20	base of code?	0x1000
0x24	section1: virtual address	0x0
0x28	section1: raw data address	0x50
0x2c	section1: size of raw data	0x10fa0
0x30	section2: virtual address	0x11000
0x34	etc..

Shellcode は BloodAlchemy 本体を復元したのち、最終的な Payload としてメモリ内に展開するためにこの独自フォーマットを解釈し、EntryPoint へ処理を進める機能が実装されています(図８)。

図8. 独自フォーマットを解釈して Payload である BloodAlchemy を展開するコード

Payload (BloodAlchemy) の解析

仕組み

BloodAlchemy は他のマルウェアにはあまり見られない特徴がいくつかあります。そのうちの1つが run mode の値です。前述した Shellcode から Payload の EntryPoint へ処理を移す際に、6つの引数が指定された上で呼び出されます。そのうち第1引数には run mode の値が設定されています。

BloodAlchemy の挙動はこの run mode に設定される値で大きく異なります。各 run mode の値とそれぞれの挙動は以下の通りです。

run mode	run mode に対応する挙動
0	C2 との通信および Backdoor 機能の呼び出し、指定プロセスの作成とコードインジェクション、指定プロセスへコードインジェクション、耐 debug、耐 Sandbox、永続化、
1	C2 との通信および Backdoor 機能の呼び出し
2	C2 との通信および Backdoor 機能のためのスレッド作成
3	C2 との通信および Backdoor 機能、指定プロセスへコードインジェクション、耐 Debug、耐 Sandbox、永続化
4	指定プロセスの作成とコードインジェクション
5	名前付きパイプの作成
6	マルウェアのインストール

また、BloodAlchemy では malware configuration を読み込むことがわかりました。この malware configuration は前述した Shellcode 内に暗号化された状態で埋め込まれており、BloodAlchemy の処理を進める中で、別途復号され使用されます(図9)。さらに、C:\ProgramData\Storeのディレクトリ配下に｛a-zA-Z｝の15文字のファイル名をもつファイルが存在する場合には、そのファイルを malware configuration として読み込みます。復号アルゴリズムは前述した Payload と同じものが使われていました。

読み込まれた malware configuration は run mode で設定されている挙動を操作するための値やC2サーバーの URL、コードインジェクションをする際に指定されているプロセス名等、マルウェアにとって重要なデータが暗号化された状態で格納されています。また、ShadowPad の malware configuration のように、一部 configuration 内に埋め込まれているデータの位置を示す為のオフセット値も含まれていました。

図10. malware configuration 内の暗号化されたデータとその位置を示すオフセット値

MUTEX 値や、 C2 といったマルウェアにとって特に重要なデータは基本暗号化されて malware configuration 内に格納されています。それぞれ、暗号化されたデータのサイズ、1バイトの鍵、暗号化されたデータの順で以下のようなデータ構造で格納されています。

offset	descriptions	data
0x00	size of data	0x25
0x01	a byte key	0x41
0x02	encrypted data	1E 9D 09 19 7A D0 9D 9D …

復号は格納されている1バイトの鍵を使用して独自のアルゴリズムで復号します。復号処理を Python で実装するとこのようなコードになります。

import struct


def dec_cmt(offset):
    s = struct.unpack("B", ida_bytes.get_bytes(offset, 1))[0]
    data = ida_bytes.get_bytes(offset, s + 2)
    iv = data[1]
    enc = data[2:]
    dec = ""
    for i in range(s):
        dec += chr(iv ^ enc[i] & 0xFF)
        ku0 = iv << (i % 5 + 1) & 0xFF
        ku1 = iv >> (7 - i % 5) & 0xFF
        iv = (iv + (ku0 | ku1)) & 0xFF
    return dec[:-1]

上記 Python スクリプトで復号し、復号データをコメントすると以下のようになります。

図11. malware configuration のオフセットの解決と復号例

また、malware configuration 以外のデータ、例えば特定のフォルダ等といったマルウェアにとって重要なデータに対しても同様の暗号が使用されており、前述したスクリプトを用いることで復号が可能です。

機能

前述したとおり、BloodAlchemy は run mode によって挙動がかわり、malware configuration の値によって一部の機能の制御も行うというかなり特殊な検体です。BloodAlchemy のメイン機能は、C2 サーバーと通信を行い、実装されている backdoor コマンドによって RAT として動作します。

BloodAlchemy に実装されている各機能についていくつか掘り下げて説明します。

Persistence

Payload には永続化機能も含まれています。run_mode が0または3かつ、実行ファイルパスが永続化用のパスではなく、さらに malware configuration の0x34の値が0ではない場合、以下 persistence_flag の値（1~4）に応じて永続化に向けた設定を作成します。

1: service + startup + taskschd (COM obj)
2: service
3: startup
4: taskschd (COM obj)

上記の永続化の仕組みではマルウェアセットである test.exe, BrLogAPI.dll, DIFX を感染環境によって、以下いずれかの対応するディレクトリ内に作成するように設計されています。

%AUTOPATH%\Test\
%LocalAppData%\Programs\Test\
%ProgramFiles%\Test\
%ProgramFiles(x86)%\Test\

Anti Sandbox

Payload にはサンドボックスへの耐解析機能（Anti Sandbox）も含まれています。この機能は run_mode が0で、実行ファイルパスが永続化用のパスではなく、さらに malware configuration の0x1cの値が1の場合にのみ機能します。process_name やファイル、DNS の結果を確認します。確認しているプロセス名から、Trellix 社のサンドボックス機能を避けるためと推測しています。

Process Injection

ペイロードには Process Injection の機能が含まれています。

run_mode が0または3かつ、malware configuration の0x54の値が1の場合、configuration の0x58から0x64に設定されている以下プロセスに対して、前述した Shellcode を注入しようとします。

%windir%\system32\SearchIndexer.exe
%windir%\system32\wininit.exe
%windir%\system32\taskhost.exe
%windir%\system32\svchost.exe

このとき、注入された Shellcode を非同期プロシージャコール（APC）のキューとして設定するためにQueueUserAPC() 関数が使用されます。これは Early Bard Injection といわれる手法です。

非同期プロシージャコール（Asynchronous Procedure Call : APC）とは

特定のスレッドのコンテキストで非同期的に実行される関数。各スレッドには独自の APC キューがあり、アプリケーションは QueueUserAPC() 関数を呼び出してAPCをキューに登録する。そうすると、次回のスケジュールされたスレッドで APC 関数の実行およびソフトウェア割込みが発生する。

非同期プロシージャ呼び出し | Microsoft Learn

図15. ペイロード内のプロセス注入の機能と QueueUserAPC() 関数の呼び出し

また、run_mode が0または4かつ、malware configuration の0x68の値が1の場合、0x6cから0x74に設定されている以下のプロセスを作成した上で、shellcode をそのプロセスへ注入しようとします。

%windir%\system32\wininit.exe
%windir%\system32\taskeng.exe
%windir%\system32\taskhost.exe
%windir%\system32\svchost.exe

各通信プロトコルに紐づく VFT の作成

BloodAlchemy マルウェアの通信先は、malware configuration 内に10個まで設定できるように設計されていました。しかし、興味深いことに我々が観測した検体では検体毎に1つしか設定されていませんでした。

C2を復号後、通信プロトコルを抽出し、マルウェア内で使用する Protocol id を設定します。この Protocol id に応じて仮想関数テーブル（VFT）が作成されます。

仮想関数テーブル（Virtual Function Tables : VFT）

クラス内の仮想関数へのポインターを格納するテーブル。クラスが1つ以上の仮想関数を持つ場合、コンパイラはそのクラスに対して仮想関数テーブルを作成する。そして、各クラスのインスタンスは、このテーブルへのポインターをもつ。

仮想関数テーブル | Microsoft Learn

図16. Protocol id によって対応したプロトコルをマルウェア内で扱うための VFT が作成される

Backdoor commands

ペイロードには15個の backdoor command が含まれていました。各 command id と行われる操作は以下の通りです。

command id	descriptions
0x1101	update config
0x1102	get current config
0x1201	update test.exe
0x1202	update BrLogAPI.dll
0x1203	update DIFX
0x1204	uninstall and terminated
0x1205	launch persistence_dir\test.exe
0x1301	unknown
0x1302	load received payload and store it into registry value
0x1303	delete registry value
0x1304	unknown
0x1401	get proxy info
0x1402	update proxy info
0x1501	gather victim info
0x1502	echo 0x1502

Deed RAT とコードの類似性

BloodAlchemy の解析結果をもとに、当社では BloodAlchemy と Deed RAT 間で複数の類似性を発見しました。その中でも特にコードの類似性が高いと判断した例をいくつか示します。

BloodAlchemy と Deed RAT のヘッダーの独自データ構造が酷似していたことを確認しています。magic number や plugin id をはじめとして値による違いはあるものの、どちらも PE ヘッダーをもとにデザインされた構造がうかがえ、それぞれの値をもとに、ペイロードをメモリ内にマッピングしたのち、エントリーポイントを算出し、ペイロードを呼び出す仕組みです。