前回、超尻切れトンボになった、特徴のある情報・痕跡の続きです。
感染の判定、マルウェアの通信先の求め方とそれによる追跡のための判定情報、感染予防のアイディアの種になりそうなネタでも展開できればいいなぁと。
データがダラダラになりそうなのはご勘弁を！
マルウェア本体部の特徴のある情報・痕跡の詳細
インジェクションしているsvchost.exeのプロセスツリーがおかしい
これは、前回記事でもライブのプロセスツリーで表示したのでそちらを参照していただければOKです。
メモリは、ライブでProcess ExplorerやProcess Hackerで参照する方法のほか、メモリのスナップショットが取れるなら、メモリフォレンジックツールを用いて参照できます。
無償で使うなら、コマンドラインベースになりますがVolatility FrameworkやRekallが良いでしょう。
ツールはLinuxやWindowsにインストールして使うほか、SANS SIFTなら無償公開しており、その中にインストールされています（もしプロファイルが古いなら、SANS SIFTのVolatilityの更新記事参照）。
SANS SIFTは、ユーザ登録（無償）すればダウンロードできます。
VMware Playerで使うとスムーズに使えます。
使い方は・・・詳しい解説は、多分誰かがもう書いていると思います（＾＾；
Volatilityを使う場合、以下のコマンドでツリーが見れるはずです。
vol.py -f (イメージファイル名) --profile=(プロファイル名) pstree
なお、今回はマルウェアのリバースエンジニアリングによって、プロセスツリーがおかしくなる原因となる動作を解析で得ましたが。
そういったノウハウをSANSがポスターにして公開しています。
仮に今回の検体をマルウェア解析していなくても、これに則ってメモリを調査して発見できていたのでは、と思います。
SANS DFIR Hunt Evil poster
https://digital-forensics.sans.org/media/DFPS_FOR508_v4.6_4-19.pdf
流石のSANSで、解説付きで非常によい出来のポスターです。
詳しく学びたい場合は、トレーニングを受けたいですね（なかなかいい値段のため、個人だと難しいですが）。
バージョン、サーバのIPアドレスのリストを含むxml
この情報が取れるなら欲しい！という人は多いのではないでしょうか。
特にC&Cサーバのアドレス。これが速やかに分かるのであれば、ブラックリストへの反映による遮断や、通信した痕跡がないかを通信ログからチェックする場合重要な情報になるでしょう。
この情報は、マルウェアの内部データでAES256 CBCモードで暗号化されて格納されていました。
暗号鍵と初期化ベクトルは、特定の値をSHA256でハッシュ演算、結合を繰り返すことで計算できるようになっています。
一応、IPアドレスは一部マスクしました。
いや、とっくにOSINTでブラックリストに出ていそうではあるんだけど。
一方、ちょっと古い検体なので、とっくに解決してもう問題ない状態になっているかもしれないので。
あくまで、私が入手した検体では、以上のようなxml形式でIPアドレスとポート番号が入っていました、というサンプルです。よく見ると、ポート番号449なんてのが混じっています。
このxmlからとれる情報は以下のとおり。
- バージョン番号
- 1000497
- gtag(タグ情報？)
- mor84
- サーバのIPアドレス
- 5.182.xxx.xxx:443
- 5.182.xxx.xxx:443
- 82.146.xx.xx:443
- 198.8.xx.xx:443
- 195.123.xxx.xx:443
- 51.89.xxx.xxx:443
- （中略）
- 190.214.xx.x:449
- 181.140.xxx.xxx:449
- （以下略）
- autorunモジュール名
- module name="pwgrab"
xmlを解凍するためのAES256鍵
このサーバ等の情報が入ったAES256の暗号鍵と初期化ベクトルは以下の通り。
xmlデータを展開したリストオブジェクト
xmlデータは、分解されて自身のリストに格納されます。
xmlデータはリストに展開後、消去してメモリを解放してしまうので、メモリ上に残るのはこちらの情報となります。
データとして目立つのは、joaatハッシュ値と展開された要素データのIPアドレスおよびポート番号でしょう。
joaatハッシュ値はxmlの要素名をそのままハッシュ化しているので、「srv」は「0x8289E8C4」とすぐに求めることができます。
この値でメモリを検索すれば、すぐにこのマップを見つけることができるんじゃないでしょうか。
これらのデータは、自分の解析中ではconnect直前ではまだメモリに残存しています。
このため、展開されたxmlデータは、このリストの状態でメモリに残されている可能性が高いと思われます。
この解析結果から、展開されたxmlデータを取得する方法を考えると、マルウェアが動作しているメモリをキャプチャし、ツリーで浮いているsvchost.exeを特定してプロセスIDを取得し、Volatilityのmemdumpで当該プロセスのデータを抽出し、joaatハッシュ値を検索したり、単純にストリング検索をするだけ（ただし、Unicodeであることだけは注意）でC&CサーバのIPアドレスとポートが抜けるのではないか、ということが分かります。
（ただし、検証まではしていないので、あくまで分析の結果で考えられるというレベルですが。）
そういった手順を見つけるために、マルウェア解析結果を活用できるのではないか、という例です。
楕円曲線暗号公開鍵
現在の解析段階では一度インポートしてエラーにならないかチェックしているだけですが、この先暗号化で用いるであろう楕円曲線暗号公開鍵を見つけたので以下に示します。
こちらも、通常は暗号化されているのでIoCには向かないと思います。
また、共通鍵の交換のために使うと思われますが、公開鍵で暗号化されたデータは秘密鍵がなければ復号できないので、この鍵情報だけあってもすぐに役に立つことはないかなと。
容疑者を逮捕した際、この公開鍵と対になる秘密鍵をフォレンジック調査などで発見できれば証拠になる！？とかいう妄想くらいですかねー・・・。
他に活用方法がありそうなら、意見が欲しいところ。
C:\Users\（ユーザ名）\AppData\Roaming\windirectフォルダ
C:\Users\（ユーザ名）\AppData\Roaming\配下にある.txtファイルや.iniファイルから抽出したデータや、マルウェア本体が永続化するためのコピー先がこのフォルダになります。
ただし、私が解析している検体がここである、というだけで、恐らく容易に変更可能だと思われます。
いくつかの検体ではこのフォルダを探すことが有効かもしれませんが、そのナレッジが広まればフォルダを変えてくることが予想されます。
なお、マルウェア本体のコピーをする際、ファイル名を変更する処理を行っています。
タスクスケジューラに登録するためのxml
この検体では、自身の永続化のためにタスクスケジューラを使用しています。
タスクスケジューラに登録する際、XMLデータを用いています。
そのXMLデータは、実行ファイルのパス等の一部のパラメータ以外は暗号化されて格納されています。
データの復号とパラメータの文字列の結合を繰り返し、タスクスケジューラへ登録するXMLを生成していきます。
XMLの生成処理が終わったところでデータを抽出することで、どのようなパラメータでタスクスケジューラを登録するかを知ることができます。
ただし、このパラメータもタスクマネージャ登録時に一時的に作られるだけのため、デバッガによる解析でしか拾うのは困難だと考えられます。
どのようにタスクマネージャに登録されるかを知ることができる一方で、一時的なデータのため、検知用のIoCには向かないパラメータといえます。
タスクスケジューラへ登録しようとするXML文は以下のとおり。
まずは高い権限での登録を試み、それで失敗するとユーザの権限で登録を試みます。
登録されたタスクスケジュール
実際にタスクスケジューラに登録された画面です。
XMLの値に沿って登録されていることが分かります。
この検体と同じマルウェアが実行されたかどうかの指標にはなると思います。
しかし、名前等のパラメータは変更される可能性が高いため、長期的にはそれだけでIoCにするのは難しいと思われます。
タスクマネージャを新たに登録されているものをチェックする、というのが現実的な検知方法になりそうです。
Mutexオブジェクト名
自身の多重起動防止のための排他処理を行うために、Mutexオブジェクトを使用しています。
このMutexオブジェクトの名前ですが、「Global\xxxxxxxxxxxxxxx」（xは再現性のある値）になるようになっています。
xの値ですが、 GetVolumeInformationW で得られた値に少々計算をして作成しています。
計算結果を元に、sprintfで「Global\%08lX%04lX%lu」でパラメータを設定して文字列として出力しています。
このため、端末によってMutexオブジェクト名が変わってしまいます。
もし仮に、Mutex文字列が固定の文字列だった場合、OS起動時にマルウェアよりも速くその文字列でCreateMutexをしておけば、仮にこのマルウェアに感染したとしても、自身の排他処理によって終了してしまう、というキルスイッチが可能になります。
攻撃者も、それを見越してそう単純ではない値でMutexオブジェクト名を作り、マルウェア感染回避策を自ら作りこむようなことはしない工夫をしている、というわけです。
まあ、今回は利用できませんが、解析によってマルウェア自身の機能によって感染抑止をできる方法が見つかるなら、一時的な対処として利用できる可能性もでてくるのではないかと思います。
以上、解析で見つけたパラメータの垂れ流しでした。
セキュリティ対策に利用できたり、解析の役にたったりする情報があれば幸いです。
前にも書きましたが、この本体はロジック自体は特に目立ったヒネリはないので、パッカーを超えることができた人にはただのボーナスステージです。
じゃんじゃん解析して、パラメータの抽出なり弱点探しなりしていければいいんじゃないかと思います。
まあ、こまごまと書きましたが、これまだ解析の途中なので、また何か見つかったら追加で書くかもです。
ていうか、中途半端な解析で記事書くなって怒られそうｗ