2020年9月に落ちてきたEmotetらしき検体の解析メモです。
プライベートの時間しかとれない＆割と忙しいため、まーだパッカー（と判断している部分）しか見ていません（遅い・・・遅すぎるよ・・・）。
ただ、このパッカーは、アンチウィルス回避のためのギミックの理屈は分かったのですが、その仕組みゆえに素読みがしづらく、動かしてみないと分かりづらいということが時間がかかっている理由の一つとしてあります。
また、時間がかかっているもう一つの理由として、パッカー部とみている箇所にも関わらず、通信を行おうとしており、そのためのPCからの情報収集、暗号鍵の作成、隠された公開鍵の復号化、暗号化処理とその通信データ化の処理を、わりと真面目に追ってしまっている、ということも理由の１つです。
現在解析している検体をIDAで解析したところ、IPアドレス指定で93IPとの通信を試みていることを確認しました。
うち、いくつかは2020年10月17日現在で通信できる可能性があります。
以下に確認できた結果をメモしておきます。
検体のハッシュ値：
MD5：
46A69F3FBCD669B05BD2FB2D82E85A57
SHA-1：
D101F7C5642F4BA5BBDDA2EE85979FF97B8CFD13
IDAの解析で、通信しようとしていることを確認できたIPアドレスは以下の通り。
うち、HttpSendRequestWで通信に成功していたIPアドレスには右側に「〇」を付与。
当該検体で通信を試みたIPアドレス一覧
（うち、HttpSendRequestWで通信に成功したものに〇を付与）
以下、私の小並感：
- このIPアドレスを全てIoCにすることは非推奨。
- 理由として、通信が確立していないIPは、ダミーか対応済みの可能性が考えられるため。
- 過去の通信ログから、可能性のある通信を広めに調査する場合に利用する程度。
- このIPアドレスのうち、〇が付いているものは、検知対象とすることは可能と考えられる。
- ただし、あくまでHttpSendRequestWの通信が1回成功したことまでしか確認していないため、これをもってC&Cサーバと断定して良いかは一考。
- 理由として、この先の通信処理が未解析のため、単に関係ないサーバがリクエストの受信は受け付けた、という可能性は残される。
- もっとも、マルウェアと判断されたプログラムと通信を確立してしまうのは気持ち悪いことは確かであるため、厳しめにみるなら〇が付いているIPアドレスの通信を遮断することも一考の余地あり。
- 攪乱・検知回避のため、Fast Fluxの可能性も考慮する必要がある。このため、今回通信できたIPも短時間一時的に成功していただけの可能性も考えられる。
- なお、この時のHttpSendRequestWのパラメータは、ユーザエージェントとAES暗号鍵を細工した上でhttpのストリームデータに変換したもの。
- 別の日に実行したところ、やはり繋がらなくなっているサイトもあり(2020/10/19追記)。
- 仮に繋がったとしても、HttpQueryInfoWでHTTPステータスを受け取った結果が「200」でなければエラーとこのマルウェアは判定しているため、HttpSendRequestWの通信が成功したからといってC&Cとは限らない模様(2020/10/19追記)。
- 75.127.14.170からは2020/10/18にInternetReadFileでデータを受信できたので、これは解析結果によってはガチかもしれない(2020/10/19追記)。
・・・そして、受信データをCryptDecryptで復号したら成功し、中身に実行プログラムが含まれている模様。
当たりを引いたっぽい。
復号結果は0x05432058～だが、0x05432070～がMZヘッダになっており、よく見る実行プログラムになっている。
つまり、このマルウェアはドロッパ。
新たなコードは、インターネットに繋がりさえすればダウンロードするようになっている（少なくとも私の解析では）。
なお、通信可能だったIPアドレスについてまとめると以下のとおり。
特に地理的、所属的な共通性は無いようにみられます。
また、単純にHTTPで繋がるだけで、C&Cではないサーバも含まれているようです(2020/10/19追記)。
- 190.85.46.52 （コロンビア）
- 113.160.248.110 （ベトナム）
- 223.17.215.76 （中国・香港）
- 75.127.14.170 （アメリカ）
- 126.126.139.26 （日本）
- 119.92.77.17 （フィリピン）
- 185.208.226.142 （ハンガリー）
- 103.93.220.182 （フィリピン）
- 36.91.44.183 （インドネシア）
- 91.75.75.46 （アラブ首長国連邦）
- 77.74.78.80 （ロシア）
- 120.51.34.254 （日本）
通信データは、ランダムに作られているパラメータと、予めマルウェア内に用意されていて、暗号化されているパラメータがあります。
特に、AES暗号鍵のほか、それをバイナリ化して送信データとするときのboundaryの文字列も毎回ランダムで作っています。
このため、これらは検知のためのIoCには向きません。
一方、ユーザエージェント等の文字列は、マルウェア内にある暗号化されたデータを復号化したものでした。
IoCにした場合、本物のブラウザ通信と混同して誤検知する可能性はありますが、一応このマルウェアから発見された復号化されたユーザエージェント等のパラメータを記しておきます。
このマルウェアがhttp通信する際の固定パラメータ
このパラメータのうち、「%s」の部分は置き換えられることに留意してください。
置き換えのルールは、Refererの前半部分は通信先のIPアドレス、後半はランダムな文字列、boundary=の部分もランダムに生成されるバイナリの識別用パラメータです。
一方、マルウェアが作成・収集しているパラメータは、Refererやboundaryで用いるランダムな文字列のほか、AES暗号鍵、コンピュータ名、プロセスのリストなどがあります。
AES暗号鍵はデータを前後逆転させた後に、マルウェア内に暗号化して隠されていた公開鍵で暗号化し、HttpSendRequestWで送信していることは確認しています。
また、コンピュータ名、プロセスのリストは、若干の細工をした後、AES鍵で暗号化していることは確認しています。
こちらは送信するものと予想されますが、まだ送信したところを確認したわけではないため、断定は控えます。
コンピュータ名、プロセスリストをC&Cに送っている場合、恐らくそれらの情報から、解析環境かどうかを判定する、使用しているセキュリティ製品を把握する、といった挙動をするのではないかと思われます。
パッカー部分の機能ですが、場合によってはC&Cから処理を中止する等のコマンドが送られてくるのかもしれません。
サーバ側の分析は難しいものの、そういったテクニックを使っていないかという観点を持って分析する必要があるでしょう。
以上が、分析時に見られた通信の状況（ただし序盤のみ）です。
Emotetの本体も分析してみたいところですが・・・C&Cサーバがまだ生きているなら、通信先が生きているうちに、通信関係の分析をしておいたほうがいいんでしょうねぇ。
ああ、時間が足りない足りない・・・。