Lab 7-1
Q1: 再起動したときにマルウェアが稼働してるかの確認はどうしてるか
起動時に実行といったら、レジストリの HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run とか、Serviceが思いつく。とりあえず最初は関数Importやstring情報を見てみるのが手っ取り早いので見てみると、
どうやらレジストリ操作系の関数はImportされてはいないが、OpenSCManagerがあることからServiceが使われていることがわかる。CreateServiceがあるので、どんな名前のServiceが作られてるのかをstringsとかに無いか見てみると、
明らかにそれっぽい MalService というものがあるので、Serviceを使うことによりマルウェアの起動時の実行を確認していることがわかる。
Q2: どういう意図でこのマルウェアはMutexを使ってるか
CreateMutex/OpenMutex/WaitForSingleObject等の関数があるので、Mutexが使われていることがわかるので、具体的にどういうふうに使われているのかをGhidraで解析していく。GhidraのImportのところからOpenMutexの関数の位置に飛び、OpenMutexのXREFに飛ぶ。以下XREFでとんだ先の関数のでコンパイル結果。
まずはじめに OpenMutex で HGL345 のMutexを開けようとしている。その次のif文でもしMutexのHANDLEが0x0でない、すなわちMutexがすでにあるなら、ExitProcessをしている。よって、一回だけのマルウェアが起動するようにMutexで調整してる。
Q3: host-based シグネチャとして有用な情報の探索
Mutexの名前はハードコードされてて絶対かぶらないので、 HGL345 は結構いいシグネチャ。あとはService名の MalService 。
Q4: network-based シグネチャとして有用な情報の探索
import関数を見ると、network系の InternetOpenUrl/InternetOpen などあるので、stringsでURL等が無いか見てみる。
URLがやはりあったので、これはシグネチャとして使える。他にも Internet Explorer 8.0 みたいな文字列もあり、これもシグネチャとして使えるらしい。
Q5: マルウェアの挙動/目的の解析
Mutexをどうこうしてる関数(FUN_00401040)はわかったが、そもそもmainの関数がまずみたい。それなので、FUN_00401040のXREFをたどっていく。FUN_00401040の呼び出しもとはFUN_00401000であり、FUN_00401000のXREFはentryとその他ようわからんものしかないので、これがmainっぽい。以下はFUN_00401000をmainに名前変更したもの。
やってることは単純で StartServiceCtrlDispatcher を呼んだあと、先程のFUN_00401040を呼び出している。StartServiceCtrlDispatcher はService使ってますよぐらいの情報源にしかならないので、結局FUN_00401040の中身がメインのマルウェアの挙動っぽい。またFUN_00401040を見てみると、
最後のCreateThreadの引数に取られてる LPTHREAD_START_ROUTINE のところが実際のスレッドが行う処理の中身らしいが、飛んでみると、解説とは全然違うアセンブラが出てくる...
InternetOpen等の関数のXREFが無く変だと思ったが、やはりGhidraがうまく解析できていない。というよりそもそも最初の自動解析時にエラーでてた... 使えねぇ...
しょうがないので 0x00401150 を IDA Free でみてみる。
どうやらやはり、先程のCreateThreadで作られたスレッド内で、InternetOpenやらを使っている。また、ここからどこかの関数に飛んでる等もなく、一番最後にjmpで無限ループしてることから、永遠に同じURLにアクセスさせているので、DoS攻撃系の類だとわかる。
ダウンローダー系だと思ったが、InternetOpen後、ファイル書き込み系の関数が一つも呼ばれてないので、ただアクセスしているだけだとわかる。
Q6: このプログラムはいつ終わるか (いつ攻撃開始するか)
Q5の通り終わらないのだが、それとは無関係にいつ実行されるかのところを見逃していたので、また FUN_00401040 に戻る。
まず、SystemTimeToFileTime で 0x834(=2100) 年、他の引数は0なので、2100/01/01 のSYSTEMTIME構造体を作っている。その後、WaitForSingleObjectが呼ばれているので、2100/01/01にDoS攻撃を永遠に一斉に行うということがわかる。
Lab 7-2
Q1: このマルウェアがどうやって永続性を保ってるか
とりあえず最初はImport見る。
少ないのでパッキングされてるかと思いPEiDで確かめたが Visual C++ ... とあったのでパッキングはされてない。よくみると、OleInitialize/CoCreateInstance などが使われているので、COMを使ってるからサイズが小さいのかもしれない。
レジストリでログイン時に自動起動させたり、Serviceは使われていないようなので、このマルウェアは永続性は無く、一回しかおそらく実行されてない。
Q2: マルウェアの挙動/目的の解析
動的解析もやりたい所だが環境違うので動かないので、そのままGhidraで見てみると、
このように関数が３つしかないので、全部みてくと、0x00401000 がmainっぽいことがわかったのでリネームする。
COMを使ってるなら、なんのCOMを使ってるか知りたく、それはCoCreateInstanceの引数である IID(Interface Identifier) や CLSID(class identifier) を確認すればよい。しかしGhidraだとIIDなどが見づらいので、ここから IDA Free に切り替えてみてみる。
どちらにせよ見にくいが、読み解くとこんな感じらしい。
- rclsid：0002df01-000-000-c000-000000000046
- riid ：d30c1661-cdaf-11d0-8a3e-00c04fc9e26e
対応するものを探すには両方ググったほうが早いかもしれないが、CLSIDに対応するインターフェースはレジストリ HKLM\SOFTWARE\Classes\CLSID で探せるらしいのでそこから探してみる。
CLSIDはどうやら Internet Explorer らしい。
インターフェースの方がぐぐると
IWebBrowser2 らしい。よってまとめると、
- CLSID：Internet Explorer
- IID：IWebBrowser2
これで何のCOMを使ってるのかわかったので、今度はどういうふうにこのCOMが使われてるのかを見ていく。
CoCreateInstanceのあと、Ordinal_8/Ordinal_2/Ordinal_6 を呼んでいる。Ordinal表記がめんどいが、これ IDA Free だと解釈してくれてる。
Ordinal_6が写真に収まらなかったが、これで、
- Ordinal_8：VariantInit
- Ordinal_2：SysAllocString
- Ordinal_6：SysFreeString
だとわかるので、EditFunctionSignatureでGhidraの方を整理すると、
だいぶ見やすくなる。VariantInitはよくわからんがinitと書いてあるので初期化処理なので無視して良さげ。SysAllocStringでurlをなんか確保していて、それを最後のIWebBrowser2のInternetExplorerのに引き渡してる。
IWebBrowser2+0x2c とあり、0x2c のオフセットの関数はなにかと思い解説を見てみると Navigate 関数っぽい。長くてURLが切れてるが、よく見ると/ad.htmlと書いてある。
よって、IEを開いて広告を表示するプログラムだとわかる。
Q3: このプログラムはいつ終わるか
Navigate関数を呼び出したあと、適当にクリーンアップして return 0 しているので、一回実行したらすぐ終わる。
Lab 7-3
Q1: このマルウェアがどうやって永続性を保っているか
.exeとDLLどっちもあるので、とりあえず両方のImportを見てみる。
上のDLLの方ではMutexやネットワーク関連、CreateProcess/Sleep などが入ってる。exeの方はファイル操作系の関数がめっちゃあるがそれだけで、メインで悪さする処理はDLLの方にあるっぽい。
レジストリ関連やServiceが無いので、永続性を保ってるのはなにか別の方法でやってるっぽい。とりあえず.exeからGhidraで解析してみる。
.exeの方の静的解析
関数を見てみると、
- FUN_004010a0
- FUN_004011e0
- FUN_00401440
の３つが主な関数っぽいが、FUN_00401440以外はなんか可読性低かったので、とりあえずFUN_00401440をmainとして読んでみる。
mainの冒頭は WARNING_THIS_WILL_DESTROY... と書いてあるので、このマルウェアを実行する時の注意文みたいな感じだと思われるので飛ばす。その下をみてみると、以下のようなコードがある。
まず CreateFile(kernel32.dll) でkernel32.dllを開いてるっぽい。その後、これを CreateFileMapping に渡してファイルを操作しやすいようにメモリ上にロードしている。次の MapViewOfFile がそのマッピングに対するベースアドレスを返して、それを pvVar6 に渡している。
次に、CreateFile で Lab07-03.dll を開いてる。こちらもまた後続する CreateFileMapping/MapViewOfFile でメモリにロードして、最終的に pvVar7 にそのハンドルが渡されている。それなので、
- pvVar6 => kernel32-dll
- pvVar7 => lab0703-dll
にリネームしておく。しかし、その後が全く何してるかわからない。
ちらほらリネームした値が見れるので、なんか２つのファイルにたいして計算かなにかをしてるっぽい。２つのファイルでどうこうしてるってるなるとなんとなくどっちかをどっちかに書き写したりしてる感じもするが、決定的なのは最後のほうの以下の部分。
どうやら CopyFile をしてるらしいが、解説によるとこれは kerne 1 32.dll になってるっぽい。そういうふうに kernel32.dll に似せてるということは、おそらく先程の長い計算は kerne32.dll の内容を Lab07-03.dll に書き写したりしていたのではと予想が付く。
次に気になるのはではこの kerne 1 32.dll がどのようにロードして使われているかということだが、見当たらなくて詰まったので、別のアプローチで見てみる。
PDFによると、FindFirstFile/FindNextFileはディレクトリ探索に使われるらしいので、この関数がどういうふうに使われているのか解析していく。XREFを見ると、FUN_00401204で使われている。見てみると、
最初に上記のように FindFirstFile したあと、めっちゃ長い計算のコードが続き、最後に以下のように FindNextFile がある。
また、 do ... while(true) があるので、ファイルを総当りで探していることがわかる。
ファイルを総当りで探していることはわかったが、どんなファイルを探しているのかが次に気になってくる。めっちゃ長い計算コード見るのはめんどいので、 DAT_ となっているものの中身を見てなんか重要そうな文字列が無いかみてみる。そうすると以下が見つかった。
- DAT_00403030：".exe"
- DAT_00403040：情報無し
- DAT_0040303c：情報無し
- DAT_00403038："*"
文字列を見る限り、.exeファイルを総当りで探していることがわかる。また、総当りしてる範囲をしりたいので、最初の FirstFindFile の引数でどのディレクトリから探しているのかを確認する。引数が param_1 となっているので、この関数を呼び出してる関数(main)でどんな引数をセットされて呼び出されているのかを見てみる。
この DAT_00403044 を見てみると、
よって、Cドライブ全体の.exeを総当りでスキャンしていることがわかる。
だが、それ以上のことは静的解析で見るのはだるい。とりあえずDLLの方も見てみて、つなぎ合わせてどういう挙動なのかがわかればと期待してDLLの方も見てみる。
DLLの静的解析
Ghidraで開いてみると、関数は３つあり、見ていくと FUN_10001010 がmainっぽいのでとりあえずこれをmainにリネームする。中身を上から見ていくと、まずはじめにMutexでの何回も実行するの防止のコードがある。
その次に、以下のようなソケット通信のコードがある。
WSAStartup はソケット通信の初期化関連の関数らしく、127.2.152.13 と通信していて、 hello と送っていることがわかる。ここでもう一つ注目すべきなのはポート番号で、ポート番号は param_1._2_2_ = ntohs(0x50) とある通り、 0x50(80) なのでhttp通信であることがわかる。では何をhttp通信で行っているかについてだが、所々 strncmp が見えるので、strncmpの比較している対象をみれば何が送られると期待されてるかがわかりそう。見てみると、
一つは "Sleep" を受け取ると Sleep が呼ばれることがわかるので、コマンドをやり取りしているのかなと思われる。また、次の strncmp は DAT_10026010 なので、中身を見てみると、
なんと exec が呼ばれている！ さらに、下を見てみると、
このように CreateProcess が次に呼ばれているので C2サーバーからコマンド受け取って実行する系のマルウェアだと思われる。
ここまでやったが、静的解析だけだとキツく、いまいちどうやって永続性を保っているのかがわからないので、答えを見てみると、どうやら .exeを総当りして不正に作ったDLLを読み込むように書き換えることによって永続性を保ってるらしい。
Q2: host-basedシグネチャとして使えそうなものを２つ見つけよ
まず固いのはMutexの名前で、確認してみると SADFHUHF だったのでこれが使える。また、kerne 1 32.dll も使える。
Q3: このマルウェアの挙動/目的の解析
Q1でみたとおり、C2サーバーとやり取りしてることから、バックドアだと思われる。
Q4: マルウェアに感染後、どうやったら取り除けるか
相当取り除くのむずいのでバックアップからリストアするとかしかない