とあるマルウェアの解析メモ(その2) | reverse-eg-mal-memoのブログ

reverse-eg-mal-memoのブログ

サイバーセキュリティに関して、あれこれとメモするという、チラシの裏的存在。
medium(英語):https://sachiel-archangel.medium.com/

前回の続きです。

パッカーがsvchost.exeにインジェクションし、実行したコードをマルウェア本体と判断しています。

本体は、パッカー部と打って変わって複雑なアンチフォレンジックはしていません

(せいぜい、文字列の32ビットのjoaatハッシュ化くらい。)

ここまでたどり着ける猛者なら、そもそもこの記事の解説なんて無くても軽く解析できるボーナスステージじゃないかなぁと。

私は、期待外れてむくれてますけどね?

(楽しみにしていた私のワクワクを返して?)

 

検体のハッシュ値を再掲。

MD5:
545BFDC9B1976AE0003443FF4F90EB7E
SHA1:
92E8CE006BB3C4A1DDB8D8BA8DE3A90C0BBB6326

 

 

マルウェア本体部

マルウェア本体部は、2020年9月7日現在で、C&Cサーバに対してConnectする直前まで解析しています。その範囲での記事なので、後で追記するかもしれません。

すごいのんびりやってるように見えるでしょうけど、まったくその通り・・・。まあ、プライベートタイムでボチボチやってるとこんなもんです。

通信はどうするかな、フェイクをかます予定(Remnuxを使う or IDAで判定を強引に変える)だけど、万一C&Cが生きてたら面白いから、一回繋いでやってみるかね?

 

概要としては、今のところ特記するようなものは特にはなく

関数の暗号化等もされていないので、普通にコードが見れています。

通信後に何かが落ちてくると、もう少し違うのかもしれませんが、それならコイツはただのドロッパってことになっちゃいますね。

最初の通信の前に感染したユーザの環境情報参照して抽出している処理があったので、自動で環境情報を集めて送る機能があるのかもしれません。

あとは、タスクマネージャを利用して、自動起動するようになっている程度です。

 

そう、「フツー」なんです、コイツ。

 

他のRATほど違いがあるように思えないのだけど・・・。

私には、他と比べて騒がれている理由がよく分からない。単に利用が多いだけ??

まあ、情報収集と解析は進めてみます。

・・・論文進めないと・・・。

 

 

使われたていたテクニック

  • svchost.exe上で実行(ただし、インジェクションはパッカーの機能)
  • インポートテーブルにあたるものを自作
  • WinHttpOpenで通信のためのHTTPをオープンし、タイムアウト等を設定
  • OS、CPU情報等を収集
  • GetAdapterInfoで得た文字列をSHA-256でハッシュ化
  • バージョン、サーバのIPアドレスのリストを含むxmlをAES暗号化して保持しており、解凍する
  • xmlのデータをリストオブジェクトに展開する
  • C&Cサーバとの通信用の楕円曲線暗号公開鍵を暗号化しており、解凍する
  • C:\Users\(ユーザ名)\AppData\Roaming配下にあるini、txtファイルを検索、参照し、特定のルールに合致したものを抽出してC:\Users\(ユーザ名)\AppData\Roaming\windirectへ出力
  • マルウェアを自動起動するようにタスクスケジューラを利用
  • タスクスケジューラはPC起動時だけでなく、12分おきに起動するよう設定
  • Mutexオブジェクトを用いて多重起動を防止
  • スレッドを一つ起動(目的未解析)
  • ConnectでC&Cへ接続(この先未解析)

 

テクニックというよりは、やっていることで確認できたこと一覧みたいになってしまい、細かくなってしまいましたが。

まあ、そうじゃないと書くことほとんどないくらいなので。

 

 

svchost.exe上で実行しているのは、単に偽装が目的だと思います。

メモリフォレンジックで、あからさまにアヤシイ名前のプロセスがあれば目立ちますので。

 

ただし、コイツはメモリフォレンジックで比較的簡単に見分けがつきます。

最大の特徴は、プロセスリストのsvchost.exeの位置です。

svchost.exeは基本的にシステムが使うもので、services.exeの子プロセスとなります

しかし、タスクスケジューラによって起動されたマルウェアが起動したsvchost.exeにインジェクションした場合、そのマルウェアが終了してしまうため、親が不明の野良svchost.exeになります。

このため、親がservices.exeでなく、親プロセスが紐づかないsvchost.exeがいたら、それが当たりの可能性が高いということが分かります

以下に、ProcessHackerで参照した画像を提示します。

 

 

一応、私の環境で確認した結果では、予想通りに動いていました。

(もし環境によって違う例があったらゴメンナサイ。っていうかそういうケースの情報をチョウライ!!)

まあ、メモリフォレンジックのCTFの初歩レベルなんですがねー。

 

なお、この傾向は、タスクマネージャを永続化に利用している限り、OSの動作上こうなるため、当面判定には有効だと思います

タスクマネージャから起動したプログラムから更に別のプログラムを起動して元のプログラムが先に終了した場合、親プロセスが不明になってしまうのは構造上の話なので、マルウェア自身では回避できない、というわけです。

つまり、もし将来svchost.exeにProcess Hollowingするように改造されても、タスクスケジューラからの起動の仕組みを使っている限りこの現象は避けられない、ということにもなります。

 

 

インポートテーブルにあたるものを自作しているのは、メモリにインジェクションしたのち、EIPからインジェクションしているコードに強引に当該処理に飛ばしているため、通常のインポートテーブルが使えないか、単に解析させたくないかのどちらかだと思います。

読み込まれていないdllはLdrLoadDllで呼び出しています。利用したい関数名はハッシュ化されており、DLLの関数名のリストの関数名をハッシュ化して比較、合致したらそれに対応するアドレスを取得して格納する、という流れです。

この方法は、他のマルウェアでも見かけるので、それほど珍しい処理ではないでしょう。

 

 

OS、CPU情報等を収集は、被害端末の情報収集の一環だと思われます。

後の攻撃に使うツール等の参考にしているかもしれません。

 

 

GetAdapterInfoで得た文字列をSHA-256でハッシュ化も、被害端末のIDの代わりとして取得しているのかと思われましたが、この値と意味のあるデータでXOR処理をしている箇所があったため、暗号化の鍵にするといった意図もあったようです。

 

 

バージョン、サーバのIPアドレスのリストを含むxmlはAES256で暗号化されています。鍵自体は単純な格納ではなく、元になる値をSHA-256でハッシュ計算し、元になる値の末尾にその結果を結合してまたSHA-256でハッシュ計算し・・・ということを一定数繰り返して鍵を計算で得られるようにしています。まあ、生の鍵を格納しない工夫ですね。

これを見落とすと鍵は見つけれないのですが・・・あんまりこの鍵を見つける意味はないかも?

なお、解凍されたxmlは、タグで分解され自作のリストオブジェクトに展開されます。

この際、「srv」等のタグは32ビットのjoaatハッシュでハッシュ化されて格納されています。

まあ、タグ名が既知で、ソルトも用いていないので、事前に計算しておくことで値が分かるため、それをキーとしてメモリ内を検索すると割と簡単に見つけれると思いますけどね。

リストオブジェクトに展開した後、元のxmlはメモリを0クリアしてから解放しています。

このプログラム、それまでメモリ開放で全く0クリアしていないのに、ここだけやっているので、ここのコードはどこからかの流用かもしれないですね。

 

 

C&Cサーバとの通信用のRSA公開鍵も、もちろん暗号化されています。

こちらは任意のバイナリ列とはいかないため、復号可能な暗号化をされていますが、2つの領域をXORするだけという、割と単純な方法です。

鍵は楕円曲線暗号公開鍵で、WindowsのAPIで使えるECCPUBLICBLOBでした。

 

 

特定の領域にある.ini、.txtの検索は、C:\Users\(ユーザ名)\AppData\Roamingをターゲットとし、サブフォルダにあるファイルを参照します。そして、特定のルールにヒットしたデータを、マルウェア自身が作ったC:\Users\(ユーザ名)\AppData\Roaming\windirectへ出力しています。このときのファイル名は、読み込まれたファイル名と同じものを使用しています。

フォルダのパスから、アプリケーションが用いる環境情報を狙ったものとみられます。

 

 

永続化の方法として、タスクマネージャを利用しています。

タスクマネージャは、起動直後のほか、12分ごとに起動するようになっています。

これは、何らかの理由でプロセスがクラッシュしたり、Killされたとしても、再度プロセスを起動させる目的だと考えられます。

ただし、この方法では、既にマルウェアが起動しているにも関わらず、同じマルウェアが重複して起動してしまいます。そこで、Mutexオブジェクトを用いて排他処理をかけています。

具体的には、格納されているMutex名でCreateし、既に存在している場合は「起動済み」という判断をして自身を終了します。

こうすることで、最初に起動したプログラムは正常に実行され、2回目以降に起動するプロセスは、最初のプロセスが実行中であれば起動後すぐに終了するようになっているわけです。

 

 

スレッドを一つ起動している痕跡がありますが、いまのところこちらをまだ追えてません(すいません)。

 

 

C&Cサーバとの通信のためにHTTPを利用した通信も痕跡があり、分析ではHTTP通信の初期処理は把握しています。

現在のところ、Connect直前のところで作業を停止しているため、まだ解析できてません(時間がとれないんですよ)。

 

 

・・・そう、やっぱり「フツー」なんですよねコイツ。

技術的にはその辺のマルウェアと大して変わらず。

そのうち「スゲェ!」ってのが出てくるんですかね?

 

 

特徴のある情報・痕跡

  • インジェクションしているsvchost.exeのプロセスツリーがおかしい。
  • バージョン、サーバのIPアドレスのリストを含むxml
  • xmlを解凍するためのAES256鍵
  • xmlデータを展開したリストオブジェクト
  • 楕円曲線暗号公開鍵
  • C:\Users\(ユーザ名)\AppData\Roaming\windirectフォルダ
  • タスクスケジューラに登録するためのxml
  • 登録されたタスクスケジュール
  • Mutexオブジェクト名

 

大半は、メモリの中の情報となります。

また、メモリの中でも本当に一時的にしか存在しないものがあります。

このため、メモリフォレンジックに使おうにも、あまり役に立たないものも混じっています。

まあ、鍵が分かれば他のデータの復号に使えたり、犯人らしき人間が捕まった時、押収したマシンから見つかった秘密鍵がこの公開鍵とペアだと分かれば犯人の証拠になったりするかも・・・っていうのもありますが、暗号の鍵を抜くのは私の趣味です

(サイバー犯罪者に嫌がらせするというゲスい趣味w)

 

だって、我々が犯罪者を恐れるのはおかしいだろう?奴らが我々を恐れるべきなのだ。

 

怖いおぢちゃんに絡まれたくなければ、真面目におとなしくしとけって話。

「手の内を丸裸にして、身元に迫ってやるから首洗って待っておけw」と言えるくらいエグい解析が目標ですな。

 

 

さて、それぞれのパラメータですが・・・。

・・・おぢさん、この時間になるともう大変眠いのと、解析データひっくり返さなければいけなくて少々時間かかりそうなので、一旦ぶった切ります。

( ̄▽ ̄;)

 

パラメータの記事は、少々お待ちください!

(そしてまたグダりながら続くのぜ・・・)