2018.12.25

流行マルウェア「EMOTET」の内部構造を紐解く

マルウェア

EMOTETというマルウェアは2014年にはじめて確認されて以来、様々な変化を遂げてきました。当初はオンライン銀行の認証情報窃取を主な目的としたオンラインバンキングマルウェアとして認知されていましたが、その後、様々な変更が加えられ、現在においては2014年出現当時とは全く異なる挙動や目的を持ったマルウェアとなっています。

2018年末現在、EMOTETは世界中で積極的に拡散され被害拡大が懸念されており、日本国内も例外ではなく、様々な企業へEMOTETの感染を狙った不正メールが届いている状況にあります。

そうした状況にもかかわらず、少なくとも国内においては、今のところ現在のEMOTETに関する感染から挙動に至るまでのまとまった情報が見当たりません。

そのため、今年11月～12月に実際の国内企業への攻撃で使用されたEMOTETの不正メールを元に、我々が調査した結果と現在のEMOTETの全体像をここで解説します。

■感染の始まり

EMOTETは今のところ、企業やその組織の社員や関係者を装ったメールを利用して拡散されています。

以下の画像は、実際の攻撃で使用されたメールの様子です。

（図中の黒塗りしている箇所には実在する社員の名前が記載されています）

図 1　独自に入手した実際の攻撃で使用されたEMOTETの不正メール

届いたメールには「DOC-V6737.doc」というMicrosoft Word文書ファイルが添付されていました。

「DOC-V6737.doc」を開いた様子が以下となります。

本文には、「この文書を読むには上部に表示された黄色いバーの[コンテンツの有効化]ボタンをクリックしてください」といった旨の英文が記載されています。

図 2　メールに添付されていた不審な文書ファイル（※ファイル名は変更済）

この文書ファイルには不正なマクロが埋め込まれていますが、Wordのデフォルト設定でマクロの実行は無効にされている為、上部にWordの警告バーが表示されています。そのため、この時点でまだ感染はしていません。

警告バーの「コンテンツの有効化」ボタンをクリックすることで初めて不正なマクロが動作し感染が始まります。

Word文書ファイルに埋め込まれたマクロは特殊な解析ツールを使用しなくても、Wordの本体の機能だけでマクロのコードを閲覧することが可能です。（注意：感染する恐れがありますので、マルウェアの扱いに慣れていない一般の方が不正な文書ファイルで下記の操作は行わないでください）

まず、デフォルトでは表示されていない「開発」タブをWordのオプションから有効にし、その後、表示された「開発」タブの「マクロ」から、該当の文書ファイルに埋め込まれたマクロのコードを閲覧することが可能です。

図 3　Wordのオプション設定からデフォルトで無効になっている「開発」タブを有効にする

図 4　表示された開発タブのマクロボタンから埋め込まれたマクロを閲覧する手順

図 5　Word文書ファイルに埋め込まれている難読化された不正なマクロ

その結果、難読化されたマクロのコードがWord文書ファイルに埋め込まれていることを確認できました。

この難読されたマクロが実行されると、複数のコマンドプロンプトやPowerShellが実行され複数の不正サーバへの接続が発生、最終的にEMOTET本体であるEXEファイルがダウンロード・実行されEMOTETに感染します。

その流れを表したものが以下となります。

図 6　不正マクロ実行からEMOTET本体ダウンロードまでの流れ

これらのコマンドプロンプト（Cmd）やPowerShellには難読化されたコードが引数として渡され、引き継がれます。

以下は、Wordのマクロから最初に呼び出されるコマンドプロンプトの引数を表示させた様子です。

2つ目のコマンドプロンプトに難読化されたコマンドを引き渡していることがわかります。

図 7　不正マクロから呼び出された一つ目のコマンドの実行引数

続いて以下は2つ目のコマンドプロンプトの引数を表示させた様子です。

次はPowerShellに対し難読化されたコマンドを引き渡しています。

図 8　2つ目のコマンドプロンプトがPowerShellへ渡すコマンドの実行引数

こうして最後にPowerShellが呼び出され、引数に渡されたコマンドが実行されます。

不正マクロがこうして複数のプロセスを介しているのは、容易に処理を分析されないようにするためと考えられます。

図 9　PowerShellに渡される不正処理のコマンドライン引数

PowerShellに渡されたコマンドの時点でほぼ難読化がとけた状態となっているため、上の図の状態でも十分に処理が目視で判断できますが、より分かりやすく文字を置き換えて整形すると以下のようになります。

図 10　最終的に実行されるPowerShellのコマンド

つまり、不正マクロが最終的に実施するPowerShellのコードは、複数のURLへ順に接続させ、その応答情報が80KB(80,000byte)以上であった場合のみ、そのデータを以下のファイルとして保存して実行させる、という処理であることがわかります。

PowerShellによりダウンロードされる該当のEXEファイルがEMOTET本体となります。

不正マクロが最終的にダウンロードして保存する実行ファイル（EOTET本体）
%temp%\918.exe　（つまり C:\Users\＜ユーザ名＞\AppData\Local\Temp\918.exe ）

次の図は、実際にWord文書を開きPowerShellが動作した直後までの通信の流れを示した様子です。

上から順に複数のURLに接続しますが、はじめの３つのURLからは小さい応答サイズが返ってきており、4つ目のURLからは168KBの比較的大きい応答サイズが返ってきていることがわかります。先に説明したPowerShellのコードの処理を考慮すると、168KBは80KBより大きいため、この応答情報が918.exeとして保存されることになります。実際に%temp%フォルダの中に「918.exe」が作成され、プロセスとして実行されていることがわかります。

図 11　PowerShellが動作してEXEファイル（EMOTET本体）がダウンロードされ実行される様子

ダウンロードされたEXEファイルがEMOTET本体であり、この時点でEMOTETに感染したことになります。

■EMOTET本体の動作

ここまで不正なWord文書ファイルからEMOTETへ感染するに至るまでの流れをご紹介しました。

ここからは、本題となるEMOTETに感染してからの流れを以降で解説します。

まず、実行されたEMOTETは、以下の場所に自身をコピーして実行し、元の自身を削除します。

C:\Users\＜ユーザ名＞\AppData\Local\＜ランダム文字列＞\＜ランダム文字列＞.exe
（ファイル名は検体により異なります。本記事においては「euladmi.exe」というファイル名となっています）

図 12　ダウンロードされたEMOTETはコピーを作成して起動させ自身を削除する

EMOTET本体には、複数のC&Cサーバの接続先情報が暗号化された状態でハードコードされており、それらのC&Cサーバへ順に接続を開始します。

図 13　EMOTET本体にハードコードされたC&Cサーバの接続先情報

図 14　EMOTETのメモリ上の展開されたC&Cサーバのリスト

以下は、Word文書ファイルを開いた後、EMOTETが動作を開始し、複数のC&Cサーバへ接続を行っている際の通信の様子を表した図です。

EMOTETは、接続した複数のC&Cサーバのうち、応答がある接続先が見つかるまで接続試行します。

応答があるC&Cサーバが一度見つかると、次はそのC&Cサーバだけに接続を15分おきに繰り返すようになります。しかし自動解析システムや解析環境下では、この接続が延々と繰り返されるだけで、C&Cサーバからは常に184バイト程度の応答しか返りません。

図 15　文章ファイルを開いてからEMOTETのC&Cサーバへの接続までの通信の流れ

この際に繰り返される接続におけるリクエスト情報の中身を確認すると、EMOTETがCookieヘッダーを利用してC&Cサーバへ謎の文字列を送信していることがわかりました。

図 16　EMOTETの送信するリクエストヘッダに含まれる謎の文字列

EMOTETがCookieとして送信していた謎の文字列の暗号化前の内容を解析から割り出した様子が以下の図です。

Cookieとして送られていた暗号化された文字列の中には、感染環境の以下のデータが含まれていることがわかりました。

コンピュータ名
環境識別子
起動している全てのプロセスのリスト

より正確には以下の図に表した各情報がC&Cサーバへ送信されます。

図 17　EMOTETが送信する文字列の暗号化される前の情報

プロセスリストを送信しているということは、いわゆる解析妨害の目的である可能性があります。

試しに、解析ツールを起動させていない（ように見せかけた）別の環境で、EMOTETを動かした際の通信の様子が以下の図となります。

図 18　解析ツールを起動している環境と起動していない環境でのC&Cサーバの応答の差異

上の図の通り、解析ツールを起動させていない環境ではC&Cサーバから明らかに異なる応答情報が確認できました。

つまりこの結果から、EMOTETは感染環境のプロセスリストやコンピュータ名等をC&Cサーバへ送信し、C&Cサーバで解析環境かどうかの判断を行い、応答情報に差異を持たせることでEMOTETの動作を制御していることがわかります。

一般的なマルウェアは、プロセスチェックなどの解析環境の判断ロジックを自分自身の中に持っています。そのため、マルウェア本体を解析することでそのロジックを明らかにすることができます。しかし、EMOTETはその仕組みをクラウド側（C&Cサーバ側）に置くことで判断ロジックをそもそも自身で持たず解析できないようにするServerSideAntiAnalysis（サーバ側での耐解析機能）とでもいえる仕組みを採用しており、自動解析システムなどを欺くのに非常に効果な方法であるといえるでしょう。

図 19　一般的なマルウェアとEMOTETの耐解析機能の比較

では解析環境ではないと判断した際にC&Cサーバから応答されてきた受信データは何なのでしょうか。

解析の結果、EMOTETは以下の動作を持つことがわかりました。

自身が古いEMOTETの場合：最新のEMOTETをダウンロードしてアップデート
自身が最新のEMOTETの場合：主な目的となる機能を持った部品（モジュール）をダウンロード

つまり、解析環境ではないと判断された場合にC&Cサーバから応答されるデータは、自身のアップデートまたは部品（モジュール）となります。

このようにEMOTETは、自身を常に最新の状態に置き換えアップデートされる前提の作りとなっており、常に最新のEMOTETを感染PCに配置することができます。

図 20　常に最新の本体にアップデートできる仕組みを持つEMOTET

また、本体には目立った不正な処理のコードを置かず、不正な処理を行うコードを含む部品（モジュール）をダウンロードして使用し、さらにダウンロードしたその部品をファイルとして保存せずメモリ上で利用するファイルレスな仕組みを取り入れていることもわかりました。

これらの特徴は、攻撃者側に以下のようなメリットをもたらします。

目立った不正コードを本体に持たないため、ウイルス対策製品に検知されづらい
モジュールがファイルとして保存されないため、セキュリティ調査者から解析されづらい
主な不正機能を常に最新の内容に置き換えることができる

図 21　サーバ側から主な機能をダウンロードしてファイルレスで使用するEMOTET

そしてこれらの２つの仕組みは一般的なマルウェアではそれほど頻繁に見られることではないため、EMOTETの大きな特徴ともいえるでしょう。

また、解析環境ではないと判断した場合、PCの起動時に自身が自動起動するように以下のレジストリを設定します。

レジストリキー：HKCU￥Software\Microsoft\Windows\CurrentVersion\Run
レジストリ値：＜ランダムな文字列＞ = C:\Users\＜ユーザ名＞\AppData\Local\＜ランダムな文字列＞\＜ランダムな文字列＞.exe

図 22　解析環境ではないと判断した場合のみ設定されるEMOTETの自動起動エントリー

上記のRunキー自体は頻繁にマルウェアに利用される自動起動エントリーですが、一般的なマルウェアのように感染後すぐに設定しない点もまたEMOTETの巧妙な動作の一つといえます。

なお、通常のEMOTETの初期感染経路はメールの添付ファイルを開いて感染する流れであり、ユーザ権限で動作する前提ですが、管理者権限で実行された場合も考慮した作りとなっていることが解析の結果判明しています。

図 23　管理者権限で実行された場合のサービスエントリーとファイルパス

この挙動から、例えば管理者権限の認証情報を利用した横展開や脆弱性を悪用した権限昇格等も想定し、効果的に感染を継続できるようにしている攻撃者側の意図が垣間見えます。現に図17において、C&Cサーバに送信する情報内に自身のセッションIDを含めていることから、セッションID が０かどうかをチェックすることで感染環境のEMOTETがサービスとして動作しているかどうかを攻撃者が把握でき、権限状況によってその後にダウンロードするファイルレスモジュールを変えるといったシナリオも想定できます。

■正規プロセスを利用したEMOTETの隠蔽テクニック

EMOTETの挙動調査を行う中で、感染PCが64bit環境の場合のみ見られる不審な動作を確認しました。

感染環境が64bitの場合、EMOTET自身と同一フォルダ内に、自身のファイル名「euladmi.exe」の末尾へ「a」をつけた実行ファイル「euladmia.exe」を保存し、子プロセスとして一瞬だけ実行し終了させ、すぐにその実行ファイルを削除していました。

図 24　64bit環境のみに見られるEMOTETの不審な挙動

削除される前に該当の実行ファイル「euladmia.exe」を取得し、ハッシュ値をVirusTotalで検索してみると正規ファイルであることがわかりました。

図 25　EMOTETによって作成された謎の実行ファイルは正規ファイルだった

少し踏み込んで調査を行った結果、EMOTETによって一瞬作成された実行ファイル「euladmia.exe」は、感染環境のSystem32フォルダ内にある正規プログラム「alg.exe」のコピーであることが判明しました。

以下は実際に作成された「euladmia.exe」とSystem32フォルダにあった「alg.exe」のハッシュ値を比較した様子ですが、全く同じハッシュ値であることがわかります。

では、これら一連の挙動はいったい何なのでしょうか。

なぜEMOTETは、正規ファイルである「alg.exe」をコピーして起動、終了後すぐに削除という不審な挙動を行っていたのでしょうか。

図 26　EMOTETが作成した実行ファイルと正規ファイルの比較

結論からいうと、この一連の動きには「プロセスハロウイング（Process Hollowing）」と呼ばれる隠蔽テクニックが利用されていました。（※プロセスハロウイングの詳細については過去記事「https://www.mbsd.jp/research/20171214/downloader/index.html」をご覧ください）

「プロセスハロウイング（Process Hollowing）」とは、正規プロセスの中をくりぬき不正なプロセスのコードで入れ替えるプロセス隠蔽の手法です。

図 27　プロセスハロウイング（Process Hollowing）の概要

EMOTETは正規プログラムである「alg.exe」を「euladmia.exe」として一旦コピーしてプロセスとして起動させ、プロセスの内部を空洞化させたのち、Outlookの情報を窃取するための64bitの不正コードを埋め込んで利用していました。EMOTETがわざわざ「alg.exe」を利用した理由は、「alg.exe」は64bitプログラムであり、32bitプロセスであるEMOTETが64bit環境にインストールされたOutlookの64bit版DLL（MAPIモジュール）を利用するためには64bitプロセスとして動作する必要がある為、一時的な宿主として利用したのです。（MAPIモジュールを利用したOutlook関連情報の窃取に関する動作の詳細については別途後述します。）

図 28 EMOTETが行う正規プロセスへのプロセスハロウイング(Process Hollowing)

このプロセスハロウイング（Process Hollowing）がマルウェアの隠蔽手法として効果的なのは、プロセスの実体（実行ファイル）をファイルとして取得しても正規ファイルのままである点です。あくまでプロセスの中身が入れ替えられているだけなので、ファイル自体には一切変化がなく、上で示した通りハッシュ値も正規ファイルのままとなるため、それらを知らずに調査した場合、混乱や不正挙動の見逃しが発生したり、または正規ファイルを延々と解析することになり、調査側に多くの手間と無駄な時間を発生させることができるという攻撃者側のメリットが生まれます。

以下はEMOTETが自身の子プロセスに対しプロセスハロウイング（Process Hollowing）を行う際の処理を抜粋した図です。ZwUnmapViewOfSectionによりプロセスを空洞化させる処理や、64bitの場合の処理分岐が実際のコードとして確認できます。

図 29 EMOTETのProcess Hollowingに関する処理

加えて以下は、子プロセスをサスペンド状態で起動させ、Process Hollowingを実施したのち、プロセスをレジュームする一連の処理の様子です。

図 30 子プロセスをサスペンドで起動させ、Process Hollowingを行いレジュームさせる処理

■NirSoftを悪用するEMOTET

EMOTETは感染PC内に保存された様々な認証情報を窃取しますが、その際、フリーツールのNirSoftを悪用していることを確認しました。

NirSoftとは古くからWindowsの様々なフリーツールを公開している個人サイトおよびそのツール群ですが、公開されているそれらのツールの中には、パスワードを抽出するツールも数多く掲載されています。

図 31 NirSoftのホームページと公開されているパスワード抽出ツールの一例

EMOTETは、自身を子プロセスとして起動させたあと、先で説明したプロセスハロウイング（Process Hollowing）を使用し、NirSoftのパスワード抽出ツールとしてプロセスの中身を置き換え、NirSoftの機能をそのまま利用して様々なパスワードを窃取していました。

図 32 自身の子プロセスをNirSoftのパスワード抽出ツールとしてProcess HollowingするEMOTET

その際、プロセスハロウイング（Process Hollowing）でNirSoftのパスワード抽出ツールに入れ替えた自身の子プロセスに対し、「/scomma　＜一時ファイルのフルパス＞」というオプションを実行引数として付与します。

この特徴的な「/scomma」というオプションはNirSoftの各ツールに組み込まれた出力オプションであり、カンマで区切られたテキスト形式（つまりCSV形式）で出力させることを意味します。

以下は、実際にNirSoftのサイトで掲載されている各ツールのコマンドラインオプションですが、「/scomma」という同一のオプション文字列が存在することがわかります。

図 33 EMOTETの子プロセスの実行引数とNirSoftのサイトに掲載されたコマンドラインオプション

また、以下はNirSoftのブラウザのパスワードを抽出させるツール「WebBrowserPassView」と、EMOTETが出力した一時ファイルに記載された文字列を比較した様子ですが、カラムの文字列が一致していることがわかります。

なお、NirSoftのサイトで公開されている最新の各ツールではコマンドラインオプションが排除されていることや、以下カラムの文字列のごく一部が異なることから、EMOTETがプロセスハロウイング（Process Hollowing）で利用しているのは、コマンドラインオプションが利用できる古いバージョン等の可能性が考えられます。

図 34 WebBrowserPassViewのGUIとEMOTETの出力した一時ファイルの比較

同様に、以下はEMOTETがプロセスハロウイング（Process Hollowing）した別の子プロセスのAPI呼び出しの一部ですが、NirSoftのMailPassViewとして内部動作（引数を処理している動作）している様子がわかります。

図 35 EMOTETの子プロセスがMailPassViewとして動作している様子

■EMOTETによるOutlook関連情報の窃取

EMOTETの代表的な不正挙動の一つが「Outlook情報の窃取」です。

メールやブラウザなどの認証情報の窃取はNirSoftの各ツールを利用していましたが、Outlook情報の窃取はオリジナルであるように見えます。

我々の調査時にロードされたEMOTETのモジュールは以下の挙動を行うことを確認しました。

以下のレジストリキーにある値を参照し、値が存在する場合のみ、Outlook情報の窃取に関する挙動を行います。

レジストリキー：　HKLM\Software\Clients\Mail\Microsoft Outlook
レジストリ値：DLLPahEx = <OLMAPI32.DLLへのパス>

このOLMAPI32.DLLはOutlookがインストールされている環境に存在するOutlookのDLLであり、MAPI（Messaging Application Programming Interface）と呼ばれるOutlookに関連した各種操作を行うことが可能な専用のAPIを提供するDLLです。EMOTETはこのMAPIを利用してアクセス可能なOutlookに関するあらゆる情報を窃取することが可能です。なお前述のとおり、64bitのOutlookがインストールされている場合は64bitのOLMAPI32.DLLが上記レジストリ値に登録されているため、32bitプログラムであるEMOTETは正規の64bitプログラムを宿主としてプロセスハロウイングし一時利用します。

図 36　EMOTETが参照するMAPI DLLに関連するレジストリ場所

以下は、EMOTETが実際に上記のレジストリを参照し、OLMAPI32.DLLのフルパスをメモリに読みこんだのち、DLLとしてロードする際の処理のコードです。

図 37　EMOTETがOutlook情報の窃取のためにOLMAPI32.DLLをロードしている様子

また以下の図は、EMOTETのOutlook情報窃取に関わる挙動を解析している際の様子ですが、OLMAPI32.DLLが提供するMAPIの各種APIを利用して、Outlookから得られるメールアドレスを抜き取っていることがわかります。

図 38　EMOTETがMAPIを利用してOutLookのメールアドレスなどを窃取している様子

EMOTETは、Outlook情報を抜き出す際、実行引数に出力先として一時ファイルのパスを渡し、%Temp%内へそれぞれ出力します。

まず次に該当するメールアドレスと表示名のリストを抜き出し一時ファイルに保存します。

送信トレイおよび送信済みトレイにあるメールのメールアドレスと表示名
受信トレイにあるメールのメールアドレスと表示名

以下は実際に出力されたファイルをバイナリエディタで開いた様子ですが、Outlookから複数のメールアドレス（下記画像では一部のみ）と表示名が抜き取られていることがわかります。

図 39　Outlookから抽出された複数のメールアドレスと表示名が確認できる（画像は一部のみ）

また、メールアドレスと表示名だけでなく、以下に示すようにOutlookに設定されたあらゆる設定情報についても窃取します。

図 40　EMOTETによりOutlookから抽出されたOutlookに設定済みの各種設定情報

これらの一連の処理を終えたEMOTETは、盗み取った全ての情報をC&Cサーバへ送信します。

つまり、EMOTETはこうして窃取したOutlookのメールアドレスや名前、認証情報を利用して、（不正マクロを含んだWord文書ファイルを添付した）スパムメールを送り、自身の拡散に利用しているものと考えられます。

盗まれるメールアドレスと名前は感染した本人のものだけでなく、Outlookで送受信されたメールに含まれるメールアドレスが抜き取られるため、知らずに自身の連絡先がEMOTETに既に取得されている可能性もあり得ます。

これに関連する調査結果として、感染PCから盗み取られたメールアカウントに対し日本国外から不正アクセスが行われたことを確認しています。（※本記事で使用した解析環境ではGmailアカウントをOutlookの設定に使用）

このことから、EMOTETに盗み取られたログイン認証情報は間もなくに攻撃者に利用されているという状況が判明しました。なお、不正アクセスをしてきた該当IPアドレスはその他にも多数のメールサーバ等へ不正ログインしている情報を確認しています。

図 41　EMOTETに摂取されたメールアカウントに対し確認された不正ログイン

■まとめ

以上で、我々が現時点で把握しているEMOTETの本体とそのモジュールの解析結果を解説しました。

本記事で解説したEMOTETの各動作を含む全体像を一つの図で表したものが以下となります。

図 42　EMOTETの全体構造

また、以上の解析から見えた現時点のEMOTETの目的と特徴を以下の図にまとめました。

図 43　解析から見えた現時点のEMOTETの目的と特徴

上で解説した通り、EMOTETは常にアップデートとモジュールの組み換えを行い続けます。そのため、本記事で解説した内容はあくまで調査時点で受信した一モジュールの動作となります。我々が調査したモジュールでは確認されなかったため現時点で詳細をお伝えすることができませんが、ランサムウェアのダウンロードやネットワークでの横展開を行うモジュール、未読メールの本文やタイトルを盗むEMOTETのモジュールの出現も国外では報告されています。EMOTETが添付されたこれまでのメールは英語の本文であったため、不審に思う日本人が多かった可能性がありますが、今後、実際にやりとりされた日本語の本文やタイトルを流用したEMOTETが拡散される可能性もありえるため十分に注意が必要です。

少なくとも現時点のEMOTETを各個人が防ぐには、自身の環境でマクロが無効されていることを今一度確認し、文書ファイルのマクロは有効にしないという対策がまずは有効です。可能であればPowerShellを無効にするのも有効でしょう。また、解析ツールが起動していると判断した場合不正挙動を行わないマルウェアは少なくありませんので、ユニークな個人対策としては、普段お使いのPCに何か一つでも解析ツールを常時起動させておくのもいいかもしれません。（おすすめはSysinternalsの「ProcessMonitor」や「ProcessExplorer」、フリーツールの「ProcessHacker」や「OllyDbg」等です。ProcessMonitorなどは動かしてしまうと負荷が大きい為、単にプロセスとして起動させておくだけで良いかと思います。単純にプロセス名だけをチェックするマルウェア以外にもウインドウタイトルやクラス名などで細かく判断するタイプもいるため、できるだけ本物のツールを使用することをお勧めします。）企業ネットワークの監視の観点からもドメインではなく直のIPアドレスで外に出ようとしている通信にはより一層注意する必要があるでしょう。ただし、もちろんそうした攻撃の特徴や通信の特徴についても今度いつアップデートで大きく変化するかわからないため、絶対に有効であると言い切れる対策はなく、油断は禁物です。

EMOTETについては引き続き動向を監視し、新しい解析結果が判明した場合また追ってご報告いたします。

※調査に使用した検体のハッシュ値

EMOTET：a07e36cf67f68999e4b49d408a4df05ffef9d3ba
EMOTET：3767edc3ee48f85dd4303c9fd0e8309523580491
EMOTET：720775af35ea258d164154b7d18ed3de81ebb1e5
DOCファイル：e1bcf205a03ac926a451857c708c77d3aa63b6b6
DOCファイル：b7b73edcad8ba481413d12af8a14cbc5788aa468

■付録：リクエストヘッダに含まれるCookieの内容の解読

ここでは付録として、図16の（Cookieとして送信される）暗号化された文字列がどのように構成されているかを、次の図に示したCookieの値を例に解説します。

図 44　 EMOTETが送信するリクエスト情報に含まれる暗号化データの例

まず、この暗号化された文字列は、英数字で構成されており末尾に「=」が付加されていることから、Base64形式でエンコードされているものと推察できます。

これをBase64でデコードすると、以下のようなバイナリデータになります。

図 45　Base64エンコードされたリクエストデータをデコードした状態

しかし上図の通り、まだこの時点ではプロセス名の文字列などが見当たらず、図17で示した送信データの構造ではありません。

あらためて、このBase64エンコードされたデータがメモリ上で作成される過程を紐解き、Base64エンコード前のデータ作成の処理をたどると、CryptEncrypt APIを利用して暗号化していることがわかりました。

その処理の過程では、CryptExportKeyによりエクスポートされたセッション鍵と、CryptGetHashParamにより取得されたハッシュ値（CryptEncrypt時に取得した暗号化元データのSHA1）が、CryptEncryptにより暗号化されたデータと近接する形でメモリ上に配置されることが確認できます（図46参照）。

またCryptExportKeyによりエクスポートされるセッション鍵は、より具体的にはEMOTET本体に保持している公開鍵を利用してエクスポートされ、バイナリデータが反転された状態で格納されます。