帰ってきたバンキングトロイCitadel(2016-01-05)
こんにちは、中津留です。私が2014年2月にCODE BLUEで「Fight Against Citadel in Japan」と題して、日本における当時のバンキングトロイの現状やCitadelの詳細な分析結果を発表してから、早くも2年近くが経過しました。（当時の資料や動画については、参考情報[1]をご参照ください。）その間に、関係者による様々な取組みがなされ、CitadelがJPCERT/CCに寄せられるインシデント報告の中で登場する機会は減少し、2014年上半期を最後に見られなくなっていました。しかしながら、2015年11月末にDrive-by-Download経由でバージョンアップしたCitadelに感染させようとする事例を確認しました。
今回は、その事例で見られたCitadel（バージョンが0.0.1.1と設定されていたため、以後仮称として「Citadel 101」といいます）が、CODE BLUEで発表した当時のCitadelバージョン1.3.5.1（以後「Citadel 1.3.5.1」といいます）からどのように変化していたのかという点と、そしてCitadel 101に対応した復号ツールについて紹介します。
Brian Krebs氏を騙るメッセージ表示機能の削除
Citadel 1.3.5.1は、本来の動作とは関係のない機能をもつことが広く知られていました。引数に「-z」を指定して実行すると図1のダイアログボックスを表示する機能です。
これはKrebs on Securityを運営するBrian Krebs氏を騙ったメッセージで、参考情報[2]のとおり本人も紹介記事を書いています。Citadel 101では、このメッセージ表示機能が削除されました。
構造体の変化
両Citadelが内部で使用している様々な構造体には、ほんの少し変更が加えられました。例えば、設定ファイルのデータ形式として使用しているBinStrageという名の構造体では、ヘッダの先頭に存在するランダムなデータのサイズが図2のとおり20バイトから32バイトに変更されていました。
暗号処理に付け加えられたXOR演算
CODE BLUEで私が紹介したように、Citadel 1.3.5.1は、表1のようにファイルやレジストリ、通信データを暗号化していました。
表1: Citadel 1.3.5.1が暗号化する対象と暗号方式の一覧
| 暗号化対象 | データ形式 | 暗号方式 | |
| レポート | 暗号化 BinStrage | RC4+ | |
| 通信データ | Dynamic Config | 暗号化 BinStrage | AES+ |
| 追加モジュール | 実行ファイル | RC4+ * 2 | |
| ファイル | レポートファイル | StrageArray | Installed Dataを用いたAES+ |
| モジュールのバックアップ | StrageArray | Installed Dataを用いたAES+ | |
| レジストリ | Dynamic Config のバックアップ | 暗号化 BinStrage | Installed Dataを用いたAES+ |
Citadel 101は、Citadel 1.3.5.1と同じ対象・暗号化手法を用いていますが、暗号化処理の最初と復号処理の最後にXOR演算を行う処理が追加されました。Citadel 1.3.5.1と同じ復号処理で取り出したデータには、XOR鍵（key2）とエンコードされたデータ（data）が含まれており、それらを用いて図3に示すXORによるデコードを行います。
この中で使用されているXOR鍵の一つであるkey1の初期値は、Citadel本体にハードコードされています。インシデント対応においてCitadelが暗号化したデータを復号するためには、新たにこの値を取得しなければなりません。
バージョンアップしたCitadel Decryptorの公開
Citadel Decryptorは、私が作成しCODE BLUEで発表した、Citadelが暗号化したデータを復号するためのツールです。これを、Citadel 101が暗号化したデータの復号もできるように拡張し、GitHub上で公開しました。
aa-tools/citadel_decryptor at master - JPCERTCC/aa-tools
https://github.com/JPCERTCC/aa-tools/tree/master/citadel_decryptor
主な変更点は次のとおりです。
- Citadel 101の内部にハードコードされている暗号鍵などを取得する処理を追加
- 復号処理の最後にXORによるデコード処理を追加
⇒ XOR鍵の取得に失敗した場合は、Citadel 1.3.5.1と判断し、XORによるデコードを行わない - Citadel 1.3.5.1と Citadel 101の間の各種構造体の違いに対応
使用方法は変わりません。Citadel 101がC&Cサーバから受信する設定ファイルを復号するために使用した例を次に示します。
> citadel_decryptor.py -v -d root.xml citadel_main.bin
[*] start to decrypt root.xml
[*] get base config & several params
[*] found base config at RVA:0x000047f0, RA:0x000047f0
[*] found login key: D8F3A28A92E53179A3EC2100B314A5CB
[*] use RC4 key at (base config + 0x000001fd)
[*] found following xor key for AES plus:
[40, 40, 84, 92, 146, 121, 93, 197, 4, 73, 90, 178, 167, 220, 62, 44]
[*] found RC4 salt: 0x5198A7FE
[*] found xor key using after Visual Decrypt: 0x5198A7FE
[*] try to unpack
[*] decrypt data using following key:
[58, 225, (snip.) 50, 247, 122, 107, 114, 177, 190, 29, 60, 230, 186, 94]
[*] try to AES+ decryption
[*] use following AES key:
[181, 55, (snip.) , 252, 170, 168, 99, 231, 208, 131, 229, 244, 121]
[*] parse decrypted data... OK
[*] decompress decrypted data
[*] wrote decrypted data to root_decrypted.bin
おわりに
JPCERT/CCで確認したCitadel 101は未だ数が少なく、Citadel Decryptorの十分な検証を行えていないため、今回紹介した更新内容だけでは対応しきれていない変更点が存在している可能性があります。Citadel Decryptorで復号できないCitadelの情報など、皆様からのフィードバックをいただいて改良していきたいと考えています。もちろん、プルリクエストを送っていただいても構いません。
分析センター 中津留 勇
参考情報
[1] 過去の講演 || ARCHIVE || 世界トップクラスの専門家による情報セキュリティ国際会議「CODE BLUE（コードブルー）」
http://codeblue.jp/2015/archive/2013/#speaker-you
[2] Krebs, KrebsOnSecurity, As Malware Memes - Krebs on Security
http://krebsonsecurity.com/2013/05/krebs-krebsonsecurity-as-malware-memes/
