| 脅威分析のために、攻撃全体を見通す「鳥の目」や過去からの流れを見極め行く末を予測する「魚の目」が重要なことはもはや強調するまでもありませんが、目の前の実体である攻撃コードが何を行うのかを正確に解析する「虫の目」は、脅威の適切な把握とその後の分析の基になる情報としてやはりその重要性に変わりはありません。リバースエンジニアリング手法を用いたマルウェア動作解析は、比較的他の人からも理解されやすい「鳥の目」や「魚の目」による分析とは違って、リバースエンジニア（リバースエンジニアリング手法を駆使して解析するエンジニア）だからこそ見えるものという意味でマルウェア解析の醍醐味と言えます。今回は原点に立ち返り、そんなマルウェア解析者の虫の目でどんなことが見えているのかを、最近解析した一つのマルウェアサンプルを通してご紹介します。 |
■「Th[u]s program cannot be run in DOS mode.」
「This program cannot be run in DOS mode.」
これを見てピンと来る方は、MS-DOS を使用したことがある昔からの PCユーザーの方か、リバースエンジニアの方でしょうか。リバースエンジニアであれば必ず知っているだろうこの有名な文字列は、Windows用実行ファイル（PEファイル）を誤って MS-DOS上で実行してしまった場合に表示されるメッセージです。PEファイルには（ほぼ）必ず含まれているので、拡張子が「EXE」などの PEファイルをテキストエディタで開くと、先頭付近で目にすることができるはずです。試しに Windows標準の電卓プログラム “calc.exe” をメモ帳で開くと次のように見えます（図１参照）。
 |
|
|
この文字列は、次のようなこのメッセージを表示して終了するだけの小さなプログラムで利用されています（図２参照）。
 |
|
|
ところが今回解析した「ダウンローダ」に分類できるマルウェア「TROJ_CUTWAIL.SML」がダウンロードした実行ファイルデータでは、この部分の文字列が次のようになっていました（図３参照）。
 |
|
|
違いがお分かりでしょうか。そう、「This」の「i」の部分が「u」になっているのです。これはなぜでしょうか？ この謎の答えはこのマルウェアのコードを見てみるとわかります（図４参照）。
 |
|
|
解説すると、このコードからは、このファンクション「FUNC_ExecuteDownloadedData」（解析ツール上で勝手に命名した名前です）で、ダウンロードした実行ファイルデータの 80（0x50）バイト目の文字が「i」以外であるか、ファイル中に「0x98899889」というデータを含む場合に、ダウンロードした実行ファイルデータを “svchost.exe” にインジェクションして実行する、そうでない場合はテンポラリフォルダにファイルとして作成してから実行する、ということがわかります。つまり、「This」の「i」の部分を、ダウンロードしたファイルの実行方法を示すフラグとして利用しているのです。結果として、先ほどお見せした実行ファイルデータでは、ダウンロードされたデータはファイルとしては作成されず、新たに作成された正規プロセス “svchost.exe” に直接インジェクションされて実行されることになります。
■「Thi[z] program cannot be run in DOS mode.」
このマルウェアは、この文字列を別のフラグとしても利用しています。次のコードを見てください（図５参照）。
 |
|
|
このコードでは、ダウンロードした実行ファイルデータの81（0x51）バイト目の文字が「z」であるかどうかを調べ、その結果をあるフラグにセットしています。そしてフラグが立っている場合（「z」であった場合）は、以前に実行したプロセスが実行中か（OpenProcess API でオープンできるか）を調べ、実行状態にない場合（オープンできない場合）はその実行ファイルデータを再度実行します。つまり、「This」の「s」の部分を、ダウンロードしたファイルの常時起動要否を示すフラグとして利用しているのです。
■だから、なに？
このように文字列の一部を改変してもプログラムの動作に影響はないのでしょうか？ 結論から述べると影響はありません。Windows上でPEファイルを実行しても MS-DOSスタブプログラムは利用される領域ではないので、本来のプログラムの動作への影響はありません。仮に MS-DOS環境で実行すると改変後の文字列が表示されますが、特にエラー発生するといった支障があるわけでもありません。ではこのように MS-DOSスタブ内の文字列を改変してフラグとして利用しているという事実から我々は何を学ぶことができるのでしょうか。これも結論から述べると、特に新しい学びはなさそうです。このことがすぐに新しいマルウェア検知手法の開発や解析の効率化に結びつくわけではありません。またこのような未使用領域など動作に影響のない部分を改変して意味を持たせる手法自体も、ファイル感染型ウイルスがマーカー（感染済みであることを示す印）として利用するなど、特別に新しいことではありません。現時点では「だから、なに？」と聞かれると、返す言葉は思いつきません。強いて言うなら、「なぜこのようにしたのか」というところから、マルウェア作者のプロファイリングにつながる可能性が考えられる程度でしょうか。
| リバースエンジニアの「虫の目」で見えている世界を感じていただけたでしょうか。このように何となく興味がそそられるけれど、わざわざ話しても「フーン」で終わってしまうような発見が、コードを眺めているとたくさんあります。そしてそのさほど重要ではないと思えた発見が、別々のマルウェア同士のつながりを感じさせたり、思わぬ大発見につながる…ことを期待して今日も丹念にコードを眺めています。エンジニアの脳というコンピュータにたくさんのデータをインプットしておけば、いつか「ひらめき」を生み出す、はず？ 脳内蓄積されたデータから生み出した大発見をブログで報告できる日が来ることを願っています。 |