ページの先頭です

ページ内移動用のリンクです
  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review（IIR）
  5. Vol.34
  6. 1.インフラストラクチャセキュリティ

Internet Infrastructure Review（IIR）Vol.34
2017年3月15日発行RSS

目次

1.4 フォーカスリサーチ

インターネット上で発生するインシデントは、その種類や規模が時々刻々と変化しています。このため、IIJでは、流行したインシデントについて独自の調査や解析を続けることで対策につなげています。ここでは、これまでに実施した調査のうち、Ursnif（gozi）の解析妨害とその回避手法について紹介します。

1.4.1 Ursnif（gozi）の解析妨害とその回避手法

Ursnif（別名gozi、snifula、ISFB、Papras、Dreambot）は、Banking Trojanに分類される、金融機関などのアカウント情報をWebブラウザから盗み出し、その情報を不正に利用することで金銭を窃取するマルウェアです。近年、Ursnifを使う攻撃者は日本の金融機関のアカウント情報を標的にしていることが確認されています（※67）。感染源は複数確認されており、Exploit Kit経由でのWeb感染、SPAMメールやURLZone（別名 BEBLOH、Shiotob）が追加ダウンロードする場合が報告されています（※68）。そのため、このマルウェアの名前はITセキュリティに関するニュースでも頻繁に取り上げられています。

Ursnifは複数の手法を使って解析を妨害しており、解析環境上では正常に解析結果が得られないことがあります。そこで、本稿ではUrsnifが使う解析妨害手法を紹介すると共に、それをどのように回避してC&Cサーバへの通信を出力させ、インシデント対応に有効な情報を得るかを解説します。なお、本稿で紹介している手法は、必ず仮想マシンなど、解析が終わったらすぐに戻せる環境で行い、ネットワークからも隔離した状態で行ってください。

概要

図-18はUrsnifの感染時の挙動を示したものです。図のとおり、Ursnifは複数回にわたってコードインジェクション（※69）を行い、その中で解析妨害を行っています。First Loaderの実行ファイル内にはメモリ上にしか展開されないSecond Loaderや、Ursnif本体がエンコードされて入っています。図-18中の赤文字で書かれた部分が、今回主に解説を行う妨害手法です。

図-18 Ursnifの感染時の挙動

CreateFile APIによるデバッグ（※70）妨害

表-1 解析対象のファイルハンドルのクローズの有無

UrsnifのFirst Loaderは「CreateFileA」（※71）というAPIを使用してファイルを開き、自分自身を読み込みます。その際、「dwShareMode」を0にして呼び出すため、排他モードで読み込もうとします。一方で、デバッガも解析対象をCreateFile APIを使用して開きます。しかし、多くのデバッガは開いた際に生成されるファイルハンドル（※72）を閉じないため、UrsnifのCreateFile APIが排他モードでファイルを読み込もうとした際、既にデバッガによってファイルが開かれており、同一ファイルをオープンしようとして失敗します。筆者がよく使うデバッガを調査したところ、表-1のような結果でした。

表-1中で×となったデバッガでこの妨害を回避するには、デバッガ上に読み込み終えた後にファイルハンドルを手動で閉じます。例として、x32dbg（※73）（x64dbgの32bit版）を用いた解析例を記載します。

図-19 デバッカ内の解析対象のファイルハンドルのクローズ

  1. x32dbgにUrsnifをロードする（x32dbgを起動後、Ursnifをドラッグ＆ドロップすることで可能）。
  2. Process Hacker（※74）を起動し、x32dbg.exeプロセス上で右クリックし（図-19（1））、「Properties」を選択する。
  3. 「Handles」タブをクリックし（図-19（2））、Nameが解析対象のファイル名で、かつTypeが「File」となっているものを選択し（図-19（3））、右クリックして「Close」を選択する（図-19（4））。

図-20 CreateFileAの結果

図-20は、この対策を行わなかった場合（図-20上）と行った場合（図-20下）のUrsnifによるCreateFile APIの実行直後の状態を示したものです。対策済み（図-20下）の場合はEAX（※75）が0x74という値で正常にファイルハンドルが作られているのに対し、未対策の場合（図-20上）はEAXが0xFFFFFFFF（INVALID_FILE_HANDLE）になっています。つまりこれはファイルのオープンに失敗したことを意味します。よって、その後の処理が正常に行われず、Ursnifは途中で存在しないメモリ領域（正常であればSecond Loaderが格納されるはずの領域）を読み込もうとして異常終了します。

Process Hollowing

Process Hollowingはコードインジェクション手法の一種で、インジェクション対象のプロセスを新規で立ち上げ、対象プロセスに関連するコードやデータをメモリ上から削除し、その場所に悪意のあるコードやデータをインジェクションして実行する手法です。近年のマルウェアは、この手法や類似のインジェクション手法を多用しています。

この手法は、Personal FirewallやHost型IDSなどをすり抜けるために使われています。例えば、IEなどのWebブラウザにインジェクションすると、Webブラウザは通信が許可されているため、C&Cサーバへのアクセスが可能になります。また、例えばタスクマネージャ上でプロセス一覧を見た場合、正規なプロセスが動作しているようにしか見えないため、インシデント対応者にマルウェアの存在を一目で認識させないようにするという効果もあります。

Process Hollowingは以下のような流れで実行されます。

  1. 新規にプロセス（例えばsvchost.exeやiexplore.exeなどのWindowsの正規プロセスが多い（※76））をサスペンド状態で生成する（以下プロセスB）。これは、CreateProcess APIの引数にCREATE_SUSPENDEDが使われる（図-21）。
  2. プロセスBの実行ファイルに関わる領域をZwUnmapViewOfSection APIを用いて削除する（図-21）。
  3. マルウェアのコードやデータをプロセスBの領域にコピーする（図-22）。これにはZwCreateSection及びZwMapViewOfSectionAPI、もしくはVirtualAllocEx及びWriteProcessMemory APIが使われることが多い。
  4. プロセスBのエントリポイント（※77）をマルウェアのものに書き換える。これにはGetThreadContext及びSetThreadContext APIが用いられる。
  5. ResumeThread APIを用いて、サスペンドされたプロセスBの実行を再開することで、コピー先で悪意のあるコードが実行される。

図-21 Process Hollowing（サスペンド状態での起動）

図-22 Process Hollowing続き（悪意のあるコードやデータのコピー）

CreateProcess APIが実行された後、すぐにデバッガで生成されたプロセスをアタッチ（※78）すればよいのではないかと考える方もいるかもしれませんが、実はWindowsの仕様により、プロセスBの実行が項番5で再開されるまで解析者はデバッガなどで対象プロセスをアタッチすることができません。これはCREATE_SUSPENDEDで起動された場合、この実行ファイルのエントリポイントのはるか手前でコード実行が一時停止しているからです。そのため、OSが様々な準備処理を実行してからでないとアタッチできません。そこで、解析者は項番5に至る前までに何らかの手法を使い、デバッガでアタッチが可能になるまで対象プロセスの実行を進め、かつ悪意のあるコードが実行される前にコード実行を一時停止させることが要求されます。

筆者はこのような場合、以下の手法を用いて回避します。

  1. SetThreadContext API（前述の項番4）まで実行を進め、悪意のあるコードのエントリポイントのアドレスを確認する。
  2. 悪意のあるコードのエントリポイントを無限ループに書き換える。
  3. ResumeThread APIを実行させ、プロセスBの実行を開始させる。
  4. 無限ループしているプロセスBをデバッガでアタッチし、無限ループを元のコードに書き戻して解析を行う。

これにより、悪意のあるコードのエントリポイントまでは実行されますが（OSが行う準備処理のコードで、悪性コードではない）、その時点で無限ループするため、悪意のあるコードはまだ実行されていません。またエントリポイントまで到達していればデバッガでのアタッチが可能になるため、前述の要件を満たすことができます。

例として、x32dbgとProcess Hackerを併用したProcess Hollowingの対処法を紹介します。Ursnifにおいては、前述のCreateFile APIによる妨害を回避したものとして話を進めます。

図-23 CreateProcessAへのブレークポイントの設定

  • 1.x32dbgの画面左上の逆アセンブル領域をクリックし、「Ctrl+G」を押します。
  • 2.出てきたポップアップウィンドウに「CreateProcessA」と入力（図-23（1））し、OKをクリックします（図-23（2））。
  • 3.「CreateProcessA」に移動したことが確認できたら（図-23（3））、ファンクションキーの「F2」を押してブレークポイント（※79）を設定します。設定されると、アドレス部分が赤く反転します（図-23（4））。

図-24 CREATE_SUSPENDEDでUrsnif自身を生成することを確認

  • 4.F9でコードを実行するとブレークポイントによって、「CreateProcessA」の先頭コードでコード実行が一時停止し、EIP（※80）が「CreateProcessA」をポイントします。ブレークポイントで停止した際、アドレス部が黒地でかつ、文字列が赤くなります（図-24（1））。スタック領域（図-24右下）を見ると、CreateProcess APIの第6引数「dwCreationFlags」にあたる部分（※81）に「4」が入っており（図-24（2））、これは「CREATE_SUSPENDED」を意味します。これがProcess Hollowingのサインであると言えます。

図-25 SetThreadContextで停止させて状態を確認

  • 5.次に、同じ要領で「SetThreadContext」にブレークポイントを設定し、実行します。「SetThreadContext」で停止したことを確認したら（図-25（1））、第2引数「lpContext」の部分をクリックし（図-25（2））、右クリックメニューから「Follow DWORD in Dump」を選択します。
  • 6.「Dump 1」タブのAddress部分がスタック領域の「lpContext」にあたるアドレスと一致していることを確認します（図-25（3））。このアドレスはCONTEXT構造体の先頭を指しています。そこから「+0xb0」の位置にある4バイトはEAXにセットする値です。CREATE_SUSPENDEDで起動した場合、最終的にEAXに格納されているアドレスがエントリポイントとして扱われます（※82）。今回の検体は、「0x4010E7」という値であることが分かります（図-25（4））（※83）。この値を書き留めてください。このアドレスにある命令を無限ループに書き換えてしまえば、Ursnifの悪意のあるコードが実行される前にプログラムを一時停止できます。

図-26 エントリポイントを無限ループに変更

  • 7.Process Hackerを起動し、子プロセス側のUrsnifをダブルクリックします（図-26（1））。「Properties」ウィンドウが開くので、「Memory」タブに切り替え（図-26（2））、先程書き留めたアドレスが属する領域を見つけます。今回のアドレスは「0x4010e7」であり、「0x400000」から396KBの領域内にあるため、「0x400000」をダブルクリックして開きます（図-26（3））。「0x400000」のダンプウィンドウが開くため、「Go to...」（図-26（4））をクリックし、残りの「0x10e7」を入力し、「OK」をクリックします。0x10e7にジャンプするので、その2バイトを書き留めたあと、「eb fe」に書き換え、「Write」をクリックし、「Close」をクリックします。これで、エントリポイントを無限ループに書き換えられました（「eb fe」はx86のマシン語で無限ループの意味）。

図-27 無限ループ中のUrsnifのプロセスをアタッチ

  • 8.x32dbgに戻り、F9を押してプログラムを最後まで実行させます。すると、親プロセスは終了しますが、子プロセスはエントリポイントで無限ループになるため、Process Hackerを確認するとCPUを高い割合で消費したまま残っているのが確認できます（図-27（1））。このプロセスのPIDの値を控えたら、x32dbgで「Alt+A」を押し、PIDが一致するものをアタッチします。このとき、Process Hacker側は10進数でPIDが表示されているのに対し、x32dbgは16進数で表示されている点に留意してください。

図-28 オリジナルのバイト列への書き戻し

  • 9.子プロセスをアタッチできたら、F9を押して実行し、F12で一時停止してください。すると、EIPが以前に書き留めた0x4010e7で停止していることが分かります（図-28上）。そこで、このアドレスをクリックした後、「Ctrl+E」を押して、「eb fe」を元の2バイト（本例では「56 33」）に書き戻します（図-28下）。これで、インジェクション先のコードを解析する準備ができたことになります。Ursnifの場合、ここがSecond Loaderのエントリポイントになります。

マウス入力座標チェックによるサンドボックス回避

図-29 マウス座標監視によるサンドボックス回避

Second Loaderは、「.bss」セクション内にある重要な文字列をデコードして使いますが、デコードのための復号キーの一部にマウスカーソルの座標から生成した値を使います。図-29は該当するコードの付近です。ループ内でGetCursorInfo APIを繰り返し呼び出し、座標XとYを足し合わせたものと前回実行時の座標の差分を計算した上で、それを引数に「.bss」セクションをデコードするルーチンを呼び出します。デコードが終わった後、デコードの成否を判定するマーカーの値と比較し、一致しなければ、このループが終わりません。頻繁にマウスを動かして使用する一般ユーザの環境であれば繰り返しチェックしているうちに値が一致するので短時間のうちにこのループを抜けますが、サンドボックス環境の場合、マウスを自動でランダムに動かすような設定がされていないと、処理がこれ以上進まず、この検体が悪性であることを判定できません。最近のサンドボックスにはランダムでマウスカーソルを動かす機能がついているので問題ないと思われますが、設定により無効化されている場合は誤判定する可能性があるため、設定を見直したほうが良いでしょう。

HDDデバイス名によるVM検知（※84）

次はHDDデバイス名によるVM検知です。Ursnifは「SetupDiGetDeviceRegistryPropertyA」というAPIを特定のパラメータと共に使って行います。まずこのAPIにブレークポイントを設定して実行し、上記APIで一時停止させてください。実行後、マウスを小刻みに動かして、前述の「マウス座標チェックによるサンドボックス回避」を抜けなければこのAPIで停止しないことに注意してください。またこのAPIは、ほとんどの場合、2回1セットで呼び出されます。1回目の呼び出しでは、バッファ（第5引数、PropertyBuffer）をNULL（0）にして呼び出すことによって必要な文字長を取得します。その結果をもとに必要なバッファをHeapなどに確保してから第5引数にそのバッファのポインタをセットし、2度目の呼び出しを行います。よって、このAPIの2度目の呼び出しが終わった後にバッファに結果が格納されるため、２度目の呼び出しで一時停止させるためにもう一度F9を押し、かつCtrl+F9でこの関数の終了まで実行してください。すると、スタック領域のPropertyBuffer（図-30（1））にあたる部分に取得したHDDのデバイス名が入ります。ここを右クリック（図-30（1））し、「Follow DWORD in Dump」をクリックすると、「Dump 1」タブにバッファが表示されるため、デバイス名の文字列部分をドラッグで選択し（図-30（2））、「Ctrl+E」を押すと、「Edit data」ウィンドウが現れます。「Keep Size」にチェックをつけ（図-30（3））、製品名やVirtualなど、検出されそうな文字列をすべて任意の文字列で潰してしまいます（図-30（4））。これで、マルウェアに検知されることなく、動作させることができます。ちなみに、F7を一度押してステップ実行し、APIから悪意のあるコードに戻ると、マルウェアが検知する文字列を確認することができます（図-31）。

図-30 2度目のSetupDiGetDeviceRegistryPropertyAの実行後

図-31 HDDデバイス名での検知キーワード

C&Cサーバとの通信

このVM検知が終わると、Second Loaderは「%AppData%」以下にフォルダを作り、そこにFirst Loaderをコピー（以下、これをThird Loaderと呼ぶ）します（図-32）。また、Third Loaderをレジストリ（HKCUのRunキー）に登録し、次回マシンを起動時に自動起動するようにした上で、バッチファイルを生成して、Third Loaderを実行します。Third Loaderは、First Loaderと同一であり、Fourth LoaderもSecond Loaderと同一で、挙動が途中まで同じであるため、C&Cサーバと通信をさせるためには、Third Loader、Fourth Loaderの解析妨害も再度突破する必要があります。そこで、Second Loaderを最後まで実行させた後、生成されたThird Loaderをデバッガで読み込み、ここで記載したような解析妨害を再度回避します。これに成功すると、Fourth Loaderのプロセスは終了してしまいますが、数分後にExplorer.exe内にインジェクションされた悪性コードから、図-33のようにC&Cサーバへの通信が出るようになります（※85）。パス部に「/images/」や、長いパス部の文字列、「.gif」、「.bmp」、「.jpeg」など画像フォーマットの拡張子で終わっているといった特徴的な文字列があるため、パターンマッチングで検出できることが分かるかと思います。

図-32 %AppData%以下にコピーされたUrsnif

図-33 UrsnifによるC&Cサーバへの通信

また32bit環境では、Fourth LoaderからExplorerやIE、Firefox、Chrome、Operaに対してインジェクションを行います。その際、ZwCreateSection API、ZwMapViewOfSection APIを利用します。この付近までコードを進め、Explorerプロセスに新しいセクションが作られたらアタッチし、Memory breakpoint（※86）をその領域に設定することで、C&Cサーバとの通信を含む、Explorer内にインジェクションされた悪意のあるコードの挙動を更に追うことができます。64bit環境では、svchost.exe（64bit）をCREATE_SUSPENDEDで生成し、Heaven's Gate（※87）という手法を多用してFourth Loader（32bitコード）から64bitプロセスにUrsnif本体をコードインジェクションした後、Explorerにインジェクションを行います。

今回はUrsnifを例に、このマルウェアが持つ解析妨害手法を紹介し、それらを回避する方法を紹介しました。見てのとおり、ほとんどの解析妨害はWindows APIを通して行われます。マルウェアの使う手法を事前に調べておくことで、解析妨害を突破し、多くの挙動を把握することができるでしょう。また、妨害手法は有限であるため、多くのマルウェアで似通った手法を使っています。例えば今回紹介したHDDデバイス名をチェックすることによる検知手法はURLZoneや、いくつかのアドウェアでも使われていることを確認しています。予め情報収集をしておけば、多くの場合で対処することが可能です。

ここで紹介した手法が適用可能であることを、以下sha-256のハッシュ値を持つ検体で確認しています。

5feeee23ecd310ed552b56c1992d5e7f6dbf4e656224a9f3073b83770768e994
  1. （※67）2016年以降は特に日本国内でのUrsnifの感染事案が多く、各ベンダーや組織から注意喚起がなされている。「インターネットバンキングマルウェア「Gozi」による被害に注意」（https://www.jc3.or.jp/topics/gozi.htmlblank）。「Ursnif（別名：Gozi他）が3月以降猛威を振るっています。」（http://www.lac.co.jp/blog/category/security/20160615.htmlblank）。トレンドマイクロセキュリティブログ「国内ネットバンキングを狙う「URSNIF」が新たに拡散中」（http://blog.trendmicro.co.jp/archives/13471blank）。トレンドマイクロセキュリティブログ「2017年もマルウェアスパムの攻撃は継続中、新たな「火曜日朝」の拡散を確認」（http://blog.trendmicro.co.jp/archives/14296blank）。"2017-01-24 - ONGOING JAPANESE MALSPAM CAMPAIGN SPREADING URSNIF VARIANT" （http://www.malware-traffic-analysis.net/2017/01/24/index3.htmlblank）。中でもDreambotと呼ばれる亜種は頻繁に更新がなされており、Tor上に存在するC&Cサーバにアクセスを行う場合がある。"Nightmare on Tor Street: Ursnif variant Dreambot adds Tor functionality"（https://www.proofpoint.com/us/threat-insight/post/ursnif-variant-dreambot-adds-tor-functionalityblank）。このレポートの中では2016年7月の日本国内の事案が紹介されている。更に2017年1月末にもDreambotによる不正送金事案が発生していることをJC3が報告している（https://www.jc3.or.jp/info/malware.html#pl05blank）。また、次のレポートでは2016年8月から9月のDreambotの事案も紹介されている（https://www.cyber.nj.gov/threat-profiles/trojan-variants/dreambotblank）。
  2. （※68）Exploit kit経由では、Angler Exploit kitやNeutrino Exploit kit、Rig Exploit kitからドライブバイダウンロードされていたことをIIJでは確認している。また、メールに関しては2017年1月現在、添付ファイルとして「.svg」や「.js」などが添付され、これを実行することでUrsnifがダウンロードされ、実行されることが多い。またメールの文章は日本語である。特に「.svg」は画像ファイルであるにも関わらず、その実態はXML形式であり、かつJavaScriptが動作することから、メールゲートウェイやサンドボックスをすり抜けるために悪用された。「.svg」の事例は次のレポートが詳しい。「さまざまな件名でマルウェア（ウイルス）付き日本語メール拡散中 [ウィルス/不正アクセス]」（http://security-t.blog.so-net.ne.jp/2017-01-23blank）。また、URLZone経由での感染は次のレポートが詳しい。「バンキングマルウェア「URSNIF」 解析レポート」（https://www.nttsecurity.com/-/media/nttsecurity/files/resource-center/what-we-think/ursnif_20161215.pdfPDF）。「2016年をサイバー攻撃で振り返る--「ばらまき型」「40ドル汎用マルウェア」」（https://japan.zdnet.com/article/35093731/blank）。
  3. （※69）コードインジェクションとは、実行中のプロセスとは異なるプロセスにコードを挿入し、実行させる手法。
  4. （※70）デバッグとは、一般的にソフトウェアのバグを発見し、そのバグを除去することをいい、その際に使うツールのことをデバッガという。マルウェア解析においてはバグの発見が目的ではなく、デバッガ上でマルウェアを動作させつつ、解析者が一時停止させたい部分でピンポイントで一時停止させ、その周辺のコードやメモリの状態を調査するために利用する。
  5. （※71）本稿では、CreateFile APIと記述した個所と、「CreateFileA」と記述した箇所がある。これには明確な理由がある。Windowsでは、引数や戻り値に文字列へのポインタが含まれる場合、ほとんどのAPIの末尾にANSI形式を扱うA、もしくはWindowsの内部表記であるUNICODE形式を扱うWがつく。例えば、CreateFile APIはCreateFileA（ANSI）とCreateFileW（UNICODE）の2つのAPIが存在する。CreateFile APIと表現した場合、その両方を指す。コードを書くときは単純に「CreateFile」と記述しておけば、コンパイル時にコンパイラが設定に応じて適切なAPIを自動で選択するため、プログラマはこの点を気にする必要はない。しかし、厳密に言えばWindows内部に「CreateFile」というAPIは存在せず、存在するのはCreateFileA、もしくはCreateFileWであり、解析者はこれらを区別して扱わなければならない。例えば、ブレークポイントの設定時、「CreateFile」にはブレークポイントを設定できない。あくまでAとWのいずれか、もしくは両方に設定しなければならない。一方で、マルウェアがどちらを使っているかはマルウェア作者の開発環境に依存するか、単に作者の好みであり、解析開始時点では不明であるため、筆者はとりあえずAにまず設定して停止するかを確認し、停止できなかった場合はWを試すようにしている。そのため、本稿では、CreateFile APIと表現した場合はCreateFileAとCreateFileWの両方を指し、「CreateFileA」とカギ括弧付きで記述した場合は、API名を厳密に指し示すものとする。ちなみに、Windowsには、CreateFile APIの低レイヤー版である「ZwCreateFile」というAPIが存在する。CreateFileAやWは、最終的にKernelに渡される前に「ZwCreateFile」が実行されるようになっており、一部のマルウェアはこのAPIを直接使用する場合もある。これも作者の好みで異なるため、状況に応じて解析者もブレークポイントを設定するAPIを使い分ける必要がある。
  6. （※72）ファイルハンドルとは、読み書きなどのファイル操作を行う際、事前にOSから取得しておく許可証のようなもの。現実世界でハンドルというと、車のハンドルを思い浮かべる人も多いと思うが、車のハンドルは車を操作するためのものであるのと同様に、ファイルのハンドルはファイルを操作（読み書きなど）するためのものである。
  7. （※73）x32dbg は、x64dbgに同梱される32 bitの実行ファイル用のデバッガで、長らく解析者の間でデファクトスタンダードであった、OllyDbgとほぼ同様の操作感を持つ。OllyDbgとの差異として、64 bit用の実行ファイル（PE32+フォーマット）をデバッグすることが可能である点と、Memory Breakpoint on Executionを設定できる点が優れている。また、数日に一度のペースで改良が行われている点も魅力である。次のURLから入手可能（http://x64dbg.com/blank）。
  8. （※74）Process Hackerは、高機能版のタスクマネージャと言えるもので、SysinternalsのProcess Explorerと類似する機能を持つ。Process Explorerと比較して、今回紹介するような任意のメモリ領域の書き換え機能などを持つ。次のURLから入手可能（http://processhacker.sourceforge.net/blank）。
  9. （※75）EAXとは、x86アーキテクチャにおける、汎用レジスタ（CPU専用の変数のようなもの）の1つで、Windowsの実装では関数の実行後、戻り値が格納されている。CreateFileでは戻り値にファイルハンドルが入るため、ここをチェックすることで、ファイルハンドルの取得の成否が分かる。
  10. （※76）ただしUrsnifのFirst Loaderは、First Loader自身を子プロセスとして生成し、その子プロセスに対してProcess Hollowingを行う。よってパーソナルファイアウォールをすり抜けるためではなく、一種のデバッグ妨害として使用していると筆者は考えている。
  11. （※77）エントリポイントとは、実行ファイルにおいて最初に実行されるコードのアドレスのこと。
  12. （※78）アタッチとは、デバッガで既存のプロセスをデバッグすること。
  13. （※79）ブレークポイントとは、デバッグ対象プロセスのコード実行を一時停止し、デバッガに処理を戻すための仕組みで、停止させたいコードの先頭バイトをデバッガ内部でint 3（0xcc）命令に変更し、例外を発生させて停止させるソフトウェアブレークポイントと、CPUのデバッグレジスタを使って停止させるハードウェアブレークポイント及び後述のメモリブレークポイントが存在する。今回設定しているのはソフトウェアブレークポイントである。どれも一長一短あるので、状況に応じて使い分ける。
  14. （※80）EIPはx86アーキテクチャにおける専用レジスタで、次に実行されるコードのアドレスを常にポイントしている。
  15. （※81）MSDNのCreateProcess APIのWebペ ー ジ（https://msdn.microsoft.com/ja-jp/library/windows/desktop/ms682425blank（v=vs.85）.aspx）を参照すると、第６引数がdwCreationFlagsであることが分かる。一方、図-24は、「CreateProcessA」の先頭アドレスで実行を一時停止させている。その時のスタックの状態は、一番上（ESPレジスタが指している値）がリターンアドレス（CreateProcessAの呼び出し元に復帰するためのコードのアドレスが格納されている）で、その次から4バイト単位で引数が格納されている（今回は32 bitのWindows上で解析しているため、1つの引数が4バイト（= 32 bit）になる）。例えば図-24において、ESPは0x2af4f0であり、第1引数（lpApplicationName）は0x2af4f4、第2引数（lpCommandLine）は0x2af4f8となっている。つまり、第６引数はESP+6*4 = 0x2af4f0 + 24 （0x18） = 0x2af508と計算することができる。
  16. （※82）CONTEXT構造体内のEIPの部分を書き換えることも原理的には可能だが、CREATE_SUSPENDEDで起動したプロセスにコードインジェクションを行う場合、対象プロセスは実行するための準備ができていないため、EIPに直接悪意のあるコードのアドレスを渡しても正常には動かないことが多い。そのため、基本的にはEAXが使われる。ただし、既存のプロセスにインジェクションするケースはこの限りではないため、EIPも合わせてチェックする必要がある。また、SetThreadContext APIはGetThreadContext APIとセットで使われることが多い。もしどの部位を書き換えたのかが不明瞭である場合は、その差分をチェックすることで、マルウェアが書き換えた箇所が分かる。
  17. （※83）x86アーキテクチャはバイトオーダがリトルエンディアンであるため、int型の整数値として扱う場合、バイト単位で逆から読む必要がある。
  18. （※84）VM検知とは、VMwareやVirtualBoxなどの仮想マシンを検知する手法の総称。特殊な命令を発行することで検知するものや、特定のファイルやレジストリの値をチェックするもの、CPUの数をチェックするものなど、様々な手法が存在する。
  19. （※85）図-33はFakenet-NGと呼ばれるインターネットエミュレータを用いている。これを用いることで、クローズドな環境であってもマルウェアの通信をこのソフトウェアに転送し、観測することが可能。次のURLから入手可能（https://github.com/fireeye/flare-fakenet-ngblank）。
  20. （※86）Memory breakpointとは、ブレークポイントの一種である。ソフトウェアブレークポイントは任意の各命令の先頭アドレスに、ハードウェアブレークポイントは任意の1バイト、2バイト、4バイト単位でそれぞれ設定するのに対し、メモリブレークポイントはメモリ上の任意の領域全体に対して設定することが可能。また、ソフトウェアやハードウェアブレークポイントはアーキテクチャレベルで実装されているのに対し、このブレークポイントは各デバッガで独自実装されている。今回使用しているx32dbgや、OllyDbgなどはこの種のブレークポイント実装している。
  21. （※87）Heaven's Gateとは、32 bitコードから64 bitコードを実行するための手法。通常利用の範囲内の場合、Windowsは64 bit環境において32 bitの実行ファイルを実行すると、WOW64（Windows on Windows）環境内で実行され、WOW64が32 bitと64 bitの橋渡しを行っているため、ユーザは特に意識せずに実行できる。しかし、Ursnifは32 bitコードから直接64 bitコードを64 bitプロセスにインジェクションするため、WOW64相当の処理を自分自身で担当することで解決しており、それがHeaven's Gateと名付けられている。"Heaven's Gate: 64-bit code in 32-bit file"（http://vxheaven.org/lib/vrg02.htmlblank）。"Knockin’ on Heaven’s Gate - Dynamic Processor Mode Switching"（http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode-switching/blank）。
1.インフラストラクチャセキュリティ

ページの終わりです

ページの先頭へ戻る