BumbleCrypt

Bumblebee にインスパイアされた Crypter

背景

BumbleCrypt は Bumblebee の crypter にインスパイアされています。Bumblebee の場合、メインの Bumblebee DLL はメモリにロードされ、以下の方法で実行されます:

ペイロードを復号化してヒープに書き込む
3つの NtApi（NtOpenFile、NtCreateSection、NtMapViewOfSection）をフックする
LoadLibraryW("gdiplus.dll") を呼び出す。これにより、LoadLibrary() がライブラリをロードする際に上記の3つの API が使用されるため、インラインフックがトリガーされる
インラインフックと LoadLibrary 自体が、"gdiplus.dll" の代わりにメインの Bumblebee DLL をロードする
最後に、制御はメインの Bumblebee DLL のエクスポート関数 "SetPath" に渡される

BumbleCrypt の動作

BumbleBee の crypter を解析している際に、復号化された DLL は Bumblebee の Crypter で使用されている3つのインラインフックではなく、"NtMapViewOfSection" に対する1つのインラインフックだけでロードできることに気付きました。その結果、"BumbleCrypt" が開発されました。

BumbleCrypt の処理内容:

BumbleCrypt はまず .rsrc セクションから暗号化されたリソースをロードし、次に最終的な DLL ペイロードを復号化します: 暗号化された res -> Base64 デコード -> Rc4 復号 -> xor 復号
この Crypter は、Bumblebee の crypter と同様に、復号化された DLL ペイロードを格納するためにヒープを利用します
最終ペイロードが復号化されると、BumbleCrypt は NtApi "NtMapViewOfSection" をフックします。これは、セクションのビューを仮想アドレス空間にマップするために使用されます。
次に BumbleCrypt は LoadLibraryW("msimg32.dll") を呼び出します。ここで、インラインフックがどのようにトリガーされるかを理解しましょう:
- LoadLibraryW() はまず NtOpenFile を呼び出して、引数として渡されたモジュールのハンドルを取得します
- 次に、NtCreateSection を使用してモジュールのハンドルでセクションオブジェクトを作成します
- セクションが作成されると、LoadLibrary はセクションのビューをメモリにマップするために NtMapViewOfSection を呼び出します
- ここで、NtMapViewOfSection に対するフックがトリガーされ、プロキシ関数が次のアクションを実行します:
  - 最初に NtMapViewOfSection のフックを解除します
  - NtCreateSection() を使用して必要なサイズのセクションを作成します
  - 次に、以前にフックを解除した NtMapViewOfSection を使用して、作成したセクションのビューを仮想アドレス空間にマップします
  - 最後に、以前に復号化した最終 DLL をメモリマップされたセクションのベースアドレスに手動でマップし、NTSTATUS_SUCCESS を LoadLibraryW に返してプロキシ関数から終了します
- その後、LoadLibraryW は NtMapViewOfSection の応答として NTSTATUS_SUCCESS と、復号化された悪意のある DLL がメモリ内に存在するメモリマップされたセクションのベースアドレスを受け取ります。さらに LoadLibrary は戻り値に従って DLL をロードするため、結果として、msimg32.dll がロード済みモジュールに表示されますが、そのベースアドレスは復号化されたペイロードを指しています。さらに Crypter は、エクスポートされた関数 "CallPath" を実行して復号化された DLL に制御を渡します。
ここで、BumbleCrypt のロード済みモジュールのスクリーンショットを見ると、"msimg32.dll" が含まれていることがわかりますが、そのベースアドレスは復号化された悪意のあるペイロードを指しています。