2018.12.25
コンサルティングサービス事業本部
サイバーインテリジェンスグループ
吉川 孝志、菅原 圭
EMOTETというマルウェアは2014年にはじめて確認されて以来、様々な変化を遂げてきました。当初はオンライン銀行の認証情報窃取を主な目的としたオンラインバンキングマルウェアとして認知されていましたが、その後、様々な変更が加えられ、現在においては2014年出現当時とは全く異なる挙動や目的を持ったマルウェアとなっています。
2018年末現在、EMOTETは世界中で積極的に拡散され被害拡大が懸念されており、日本国内も例外ではなく、様々な企業へEMOTETの感染を狙った不正メールが届いている状況にあります。
そうした状況にもかかわらず、少なくとも国内においては、今のところ現在のEMOTETに関する感染から挙動に至るまでのまとまった情報が見当たりません。
そのため、今年11月~12月に実際の国内企業への攻撃で使用されたEMOTETの不正メールを元に、我々が調査した結果と現在のEMOTETの全体像をここで解説します。
EMOTETは今のところ、企業やその組織の社員や関係者を装ったメールを利用して拡散されています。
以下の画像は、実際の攻撃で使用されたメールの様子です。
(図中の黒塗りしている箇所には実在する社員の名前が記載されています)
届いたメールには「DOC-V6737.doc」というMicrosoft Word文書ファイルが添付されていました。
「DOC-V6737.doc」を開いた様子が以下となります。
本文には、「この文書を読むには上部に表示された黄色いバーの[コンテンツの有効化]ボタンをクリックしてください」といった旨の英文が記載されています。
この文書ファイルには不正なマクロが埋め込まれていますが、Wordのデフォルト設定でマクロの実行は無効にされている為、上部にWordの警告バーが表示されています。そのため、この時点でまだ感染はしていません。
警告バーの「コンテンツの有効化」ボタンをクリックすることで初めて不正なマクロが動作し感染が始まります。
Word文書ファイルに埋め込まれたマクロは特殊な解析ツールを使用しなくても、Wordの本体の機能だけでマクロのコードを閲覧することが可能です。(注意:感染する恐れがありますので、マルウェアの扱いに慣れていない一般の方が不正な文書ファイルで下記の操作は行わないでください)
まず、デフォルトでは表示されていない「開発」タブをWordのオプションから有効にし、その後、表示された「開発」タブの「マクロ」から、該当の文書ファイルに埋め込まれたマクロのコードを閲覧することが可能です。
その結果、難読化されたマクロのコードがWord文書ファイルに埋め込まれていることを確認できました。
この難読されたマクロが実行されると、複数のコマンドプロンプトやPowerShellが実行され複数の不正サーバへの接続が発生、最終的にEMOTET本体であるEXEファイルがダウンロード・実行されEMOTETに感染します。
その流れを表したものが以下となります。
これらのコマンドプロンプト(Cmd)やPowerShellには難読化されたコードが引数として渡され、引き継がれます。
以下は、Wordのマクロから最初に呼び出されるコマンドプロンプトの引数を表示させた様子です。
2つ目のコマンドプロンプトに難読化されたコマンドを引き渡していることがわかります。
続いて以下は2つ目のコマンドプロンプトの引数を表示させた様子です。
次はPowerShellに対し難読化されたコマンドを引き渡しています。
こうして最後にPowerShellが呼び出され、引数に渡されたコマンドが実行されます。
不正マクロがこうして複数のプロセスを介しているのは、容易に処理を分析されないようにするためと考えられます。
PowerShellに渡されたコマンドの時点でほぼ難読化がとけた状態となっているため、上の図の状態でも十分に処理が目視で判断できますが、より分かりやすく文字を置き換えて整形すると以下のようになります。
つまり、不正マクロが最終的に実施するPowerShellのコードは、複数のURLへ順に接続させ、その応答情報が80KB(80,000byte)以上であった場合のみ、そのデータを以下のファイルとして保存して実行させる、という処理であることがわかります。
PowerShellによりダウンロードされる該当のEXEファイルがEMOTET本体となります。
次の図は、実際にWord文書を開きPowerShellが動作した直後までの通信の流れを示した様子です。
上から順に複数のURLに接続しますが、はじめの3つのURLからは小さい応答サイズが返ってきており、4つ目のURLからは168KBの比較的大きい応答サイズが返ってきていることがわかります。先に説明したPowerShellのコードの処理を考慮すると、168KBは80KBより大きいため、この応答情報が918.exeとして保存されることになります。実際に%temp%フォルダの中に「918.exe」が作成され、プロセスとして実行されていることがわかります。
ダウンロードされたEXEファイルがEMOTET本体であり、この時点でEMOTETに感染したことになります。
ここまで不正なWord文書ファイルからEMOTETへ感染するに至るまでの流れをご紹介しました。
ここからは、本題となるEMOTETに感染してからの流れを以降で解説します。
まず、実行されたEMOTETは、以下の場所に自身をコピーして実行し、元の自身を削除します。
EMOTET本体には、複数のC&Cサーバの接続先情報が暗号化された状態でハードコードされており、それらのC&Cサーバへ順に接続を開始します。
以下は、Word文書ファイルを開いた後、EMOTETが動作を開始し、複数のC&Cサーバへ接続を行っている際の通信の様子を表した図です。
EMOTETは、接続した複数のC&Cサーバのうち、応答がある接続先が見つかるまで接続試行します。
応答があるC&Cサーバが一度見つかると、次はそのC&Cサーバだけに接続を15分おきに繰り返すようになります。しかし自動解析システムや解析環境下では、この接続が延々と繰り返されるだけで、C&Cサーバからは常に184バイト程度の応答しか返りません。
この際に繰り返される接続におけるリクエスト情報の中身を確認すると、EMOTETがCookieヘッダーを利用してC&Cサーバへ謎の文字列を送信していることがわかりました。
EMOTETがCookieとして送信していた謎の文字列の暗号化前の内容を解析から割り出した様子が以下の図です。
Cookieとして送られていた暗号化された文字列の中には、感染環境の以下のデータが含まれていることがわかりました。
より正確には以下の図に表した各情報がC&Cサーバへ送信されます。
プロセスリストを送信しているということは、いわゆる解析妨害の目的である可能性があります。
試しに、解析ツールを起動させていない(ように見せかけた)別の環境で、EMOTETを動かした際の通信の様子が以下の図となります。
上の図の通り、解析ツールを起動させていない環境ではC&Cサーバから明らかに異なる応答情報が確認できました。
つまりこの結果から、EMOTETは感染環境のプロセスリストやコンピュータ名等をC&Cサーバへ送信し、C&Cサーバで解析環境かどうかの判断を行い、応答情報に差異を持たせることでEMOTETの動作を制御していることがわかります。
一般的なマルウェアは、プロセスチェックなどの解析環境の判断ロジックを自分自身の中に持っています。そのため、マルウェア本体を解析することでそのロジックを明らかにすることができます。しかし、EMOTETはその仕組みをクラウド側(C&Cサーバ側)に置くことで判断ロジックをそもそも自身で持たず解析できないようにするServerSideAntiAnalysis(サーバ側での耐解析機能)とでもいえる仕組みを採用しており、自動解析システムなどを欺くのに非常に効果な方法であるといえるでしょう。
では解析環境ではないと判断した際にC&Cサーバから応答されてきた受信データは何なのでしょうか。
解析の結果、EMOTETは以下の動作を持つことがわかりました。
つまり、解析環境ではないと判断された場合にC&Cサーバから応答されるデータは、自身のアップデートまたは部品(モジュール)となります。
このようにEMOTETは、自身を常に最新の状態に置き換えアップデートされる前提の作りとなっており、常に最新のEMOTETを感染PCに配置することができます。
また、本体には目立った不正な処理のコードを置かず、不正な処理を行うコードを含む部品(モジュール)をダウンロードして使用し、さらにダウンロードしたその部品をファイルとして保存せずメモリ上で利用するファイルレスな仕組みを取り入れていることもわかりました。
これらの特徴は、攻撃者側に以下のようなメリットをもたらします。
そしてこれらの2つの仕組みは一般的なマルウェアではそれほど頻繁に見られることではないため、EMOTETの大きな特徴ともいえるでしょう。
また、解析環境ではないと判断した場合、PCの起動時に自身が自動起動するように以下のレジストリを設定します。
上記のRunキー自体は頻繁にマルウェアに利用される自動起動エントリーですが、一般的なマルウェアのように感染後すぐに設定しない点もまたEMOTETの巧妙な動作の一つといえます。
なお、通常のEMOTETの初期感染経路はメールの添付ファイルを開いて感染する流れであり、ユーザ権限で動作する前提ですが、管理者権限で実行された場合も考慮した作りとなっていることが解析の結果判明しています。
この挙動から、例えば管理者権限の認証情報を利用した横展開や脆弱性を悪用した権限昇格等も想定し、効果的に感染を継続できるようにしている攻撃者側の意図が垣間見えます。現に図17において、C&Cサーバに送信する情報内に自身のセッションIDを含めていることから、セッションID が0かどうかをチェックすることで感染環境のEMOTETがサービスとして動作しているかどうかを攻撃者が把握でき、権限状況によってその後にダウンロードするファイルレスモジュールを変えるといったシナリオも想定できます。
EMOTETの挙動調査を行う中で、感染PCが64bit環境の場合のみ見られる不審な動作を確認しました。
感染環境が64bitの場合、EMOTET自身と同一フォルダ内に、自身のファイル名「euladmi.exe」の末尾へ「a」をつけた実行ファイル「euladmia.exe」を保存し、子プロセスとして一瞬だけ実行し終了させ、すぐにその実行ファイルを削除していました。
削除される前に該当の実行ファイル「euladmia.exe」を取得し、ハッシュ値をVirusTotalで検索してみると正規ファイルであることがわかりました。
少し踏み込んで調査を行った結果、EMOTETによって一瞬作成された実行ファイル「euladmia.exe」は、感染環境のSystem32フォルダ内にある正規プログラム「alg.exe」のコピーであることが判明しました。
以下は実際に作成された「euladmia.exe」とSystem32フォルダにあった「alg.exe」のハッシュ値を比較した様子ですが、全く同じハッシュ値であることがわかります。
では、これら一連の挙動はいったい何なのでしょうか。
なぜEMOTETは、正規ファイルである「alg.exe」をコピーして起動、終了後すぐに削除という不審な挙動を行っていたのでしょうか。
結論からいうと、この一連の動きには「プロセスハロウイング(Process Hollowing)」と呼ばれる隠蔽テクニックが利用されていました。(※プロセスハロウイングの詳細については過去記事「https://www.mbsd.jp/blog/20171214.html」をご覧ください)
「プロセスハロウイング(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関連情報の窃取に関する動作の詳細については別途後述します。)
このプロセスハロウイング(Process Hollowing)がマルウェアの隠蔽手法として効果的なのは、プロセスの実体(実行ファイル)をファイルとして取得しても正規ファイルのままである点です。あくまでプロセスの中身が入れ替えられているだけなので、ファイル自体には一切変化がなく、上で示した通りハッシュ値も正規ファイルのままとなるため、それらを知らずに調査した場合、混乱や不正挙動の見逃しが発生したり、または正規ファイルを延々と解析することになり、調査側に多くの手間と無駄な時間を発生させることができるという攻撃者側のメリットが生まれます。
以下はEMOTETが自身の子プロセスに対しプロセスハロウイング(Process Hollowing)を行う際の処理を抜粋した図です。ZwUnmapViewOfSectionによりプロセスを空洞化させる処理や、64bitの場合の処理分岐が実際のコードとして確認できます。
加えて以下は、子プロセスをサスペンド状態で起動させ、Process Hollowingを実施したのち、プロセスをレジュームする一連の処理の様子です。
EMOTETは感染PC内に保存された様々な認証情報を窃取しますが、その際、フリーツールのNirSoftを悪用していることを確認しました。
NirSoftとは古くからWindowsの様々なフリーツールを公開している個人サイトおよびそのツール群ですが、公開されているそれらのツールの中には、パスワードを抽出するツールも数多く掲載されています。
EMOTETは、自身を子プロセスとして起動させたあと、先で説明したプロセスハロウイング(Process Hollowing)を使用し、NirSoftのパスワード抽出ツールとしてプロセスの中身を置き換え、NirSoftの機能をそのまま利用して様々なパスワードを窃取していました。
その際、プロセスハロウイング(Process Hollowing)でNirSoftのパスワード抽出ツールに入れ替えた自身の子プロセスに対し、「/scomma <一時ファイルのフルパス>」というオプションを実行引数として付与します。
この特徴的な「/scomma」というオプションはNirSoftの各ツールに組み込まれた出力オプションであり、カンマで区切られたテキスト形式(つまりCSV形式)で出力させることを意味します。
以下は、実際にNirSoftのサイトで掲載されている各ツールのコマンドラインオプションですが、「/scomma」という同一のオプション文字列が存在することがわかります。
また、以下はNirSoftのブラウザのパスワードを抽出させるツール「WebBrowserPassView」と、EMOTETが出力した一時ファイルに記載された文字列を比較した様子ですが、カラムの文字列が一致していることがわかります。
なお、NirSoftのサイトで公開されている最新の各ツールではコマンドラインオプションが排除されていることや、以下カラムの文字列のごく一部が異なることから、EMOTETがプロセスハロウイング(Process Hollowing)で利用しているのは、コマンドラインオプションが利用できる古いバージョン等の可能性が考えられます。
同様に、以下はEMOTETがプロセスハロウイング(Process Hollowing)した別の子プロセスのAPI呼び出しの一部ですが、NirSoftのMailPassViewとして内部動作(引数を処理している動作)している様子がわかります。
EMOTETの代表的な不正挙動の一つが「Outlook情報の窃取」です。
メールやブラウザなどの認証情報の窃取はNirSoftの各ツールを利用していましたが、Outlook情報の窃取はオリジナルであるように見えます。
我々の調査時にロードされたEMOTETのモジュールは以下の挙動を行うことを確認しました。
以下のレジストリキーにある値を参照し、値が存在する場合のみ、Outlook情報の窃取に関する挙動を行います。
このOLMAPI32.DLLはOutlookがインストールされている環境に存在するOutlookのDLLであり、MAPI(Messaging Application Programming Interface)と呼ばれるOutlookに関連した各種操作を行うことが可能な専用のAPIを提供するDLLです。EMOTETはこのMAPIを利用してアクセス可能なOutlookに関するあらゆる情報を窃取することが可能です。なお前述のとおり、64bitのOutlookがインストールされている場合は64bitのOLMAPI32.DLLが上記レジストリ値に登録されているため、32bitプログラムであるEMOTETは正規の64bitプログラムを宿主としてプロセスハロウイングし一時利用します。
以下は、EMOTETが実際に上記のレジストリを参照し、OLMAPI32.DLLのフルパスをメモリに読みこんだのち、DLLとしてロードする際の処理のコードです。
また以下の図は、EMOTETのOutlook情報窃取に関わる挙動を解析している際の様子ですが、OLMAPI32.DLLが提供するMAPIの各種APIを利用して、Outlookから得られるメールアドレスを抜き取っていることがわかります。
EMOTETは、Outlook情報を抜き出す際、実行引数に出力先として一時ファイルのパスを渡し、%Temp%内へそれぞれ出力します。
まず次に該当するメールアドレスと表示名のリストを抜き出し一時ファイルに保存します。
以下は実際に出力されたファイルをバイナリエディタで開いた様子ですが、Outlookから複数のメールアドレス(下記画像では一部のみ)と表示名が抜き取られていることがわかります。
また、メールアドレスと表示名だけでなく、以下に示すようにOutlookに設定されたあらゆる設定情報についても窃取します。
これらの一連の処理を終えたEMOTETは、盗み取った全ての情報をC&Cサーバへ送信します。
つまり、EMOTETはこうして窃取したOutlookのメールアドレスや名前、認証情報を利用して、(不正マクロを含んだWord文書ファイルを添付した)スパムメールを送り、自身の拡散に利用しているものと考えられます。
盗まれるメールアドレスと名前は感染した本人のものだけでなく、Outlookで送受信されたメールに含まれるメールアドレスが抜き取られるため、知らずに自身の連絡先がEMOTETに既に取得されている可能性もあり得ます。
これに関連する調査結果として、感染PCから盗み取られたメールアカウントに対し日本国外から不正アクセスが行われたことを確認しています。(※本記事で使用した解析環境ではGmailアカウントをOutlookの設定に使用)
このことから、EMOTETに盗み取られたログイン認証情報は間もなくに攻撃者に利用されているという状況が判明しました。なお、不正アクセスをしてきた該当IPアドレスはその他にも多数のメールサーバ等へ不正ログインしている情報を確認しています。
以上で、我々が現時点で把握しているEMOTETの本体とそのモジュールの解析結果を解説しました。
本記事で解説したEMOTETの各動作を含む全体像を一つの図で表したものが以下となります。
また、以上の解析から見えた現時点のEMOTETの目的と特徴を以下の図にまとめました。
上で解説した通り、EMOTETは常にアップデートとモジュールの組み換えを行い続けます。そのため、本記事で解説した内容はあくまで調査時点で受信した一モジュールの動作となります。我々が調査したモジュールでは確認されなかったため現時点で詳細をお伝えすることができませんが、ランサムウェアのダウンロードやネットワークでの横展開を行うモジュール、未読メールの本文やタイトルを盗むEMOTETのモジュールの出現も国外では報告されています。EMOTETが添付されたこれまでのメールは英語の本文であったため、不審に思う日本人が多かった可能性がありますが、今後、実際にやりとりされた日本語の本文やタイトルを流用したEMOTETが拡散される可能性もありえるため十分に注意が必要です。
少なくとも現時点のEMOTETを各個人が防ぐには、自身の環境でマクロが無効されていることを今一度確認し、文書ファイルのマクロは有効にしないという対策がまずは有効です。可能であればPowerShellを無効にするのも有効でしょう。また、解析ツールが起動していると判断した場合不正挙動を行わないマルウェアは少なくありませんので、ユニークな個人対策としては、普段お使いのPCに何か一つでも解析ツールを常時起動させておくのもいいかもしれません。(おすすめはSysinternalsの「ProcessMonitor」や「ProcessExplorer」、フリーツールの「ProcessHacker」や「OllyDbg」等です。ProcessMonitorなどは動かしてしまうと負荷が大きい為、単にプロセスとして起動させておくだけで良いかと思います。単純にプロセス名だけをチェックするマルウェア以外にもウインドウタイトルやクラス名などで細かく判断するタイプもいるため、できるだけ本物のツールを使用することをお勧めします。)企業ネットワークの監視の観点からもドメインではなく直のIPアドレスで外に出ようとしている通信にはより一層注意する必要があるでしょう。ただし、もちろんそうした攻撃の特徴や通信の特徴についても今度いつアップデートで大きく変化するかわからないため、絶対に有効であると言い切れる対策はなく、油断は禁物です。
EMOTETについては引き続き動向を監視し、新しい解析結果が判明した場合また追ってご報告いたします。
※調査に使用した検体のハッシュ値
ここでは付録として、図16の(Cookieとして送信される)暗号化された文字列がどのように構成されているかを、次の図に示したCookieの値を例に解説します。
まず、この暗号化された文字列は、英数字で構成されており末尾に「=」が付加されていることから、Base64形式でエンコードされているものと推察できます。
これをBase64でデコードすると、以下のようなバイナリデータになります。
しかし上図の通り、まだこの時点ではプロセス名の文字列などが見当たらず、図17で示した送信データの構造ではありません。
あらためて、このBase64エンコードされたデータがメモリ上で作成される過程を紐解き、Base64エンコード前のデータ作成の処理をたどると、CryptEncrypt APIを利用して暗号化していることがわかりました。
その処理の過程では、CryptExportKeyによりエクスポートされたセッション鍵と、CryptGetHashParamにより取得されたハッシュ値(CryptEncrypt時に取得した暗号化元データのSHA1)が、CryptEncryptにより暗号化されたデータと近接する形でメモリ上に配置されることが確認できます(図46参照)。
またCryptExportKeyによりエクスポートされるセッション鍵は、より具体的にはEMOTET本体に保持している公開鍵を利用してエクスポートされ、バイナリデータが反転された状態で格納されます。
ここまでの結果から、Cookieに設定されているBase64エンコードされたデータは、デコードすると上から順に以下の形式になっていることがわかります。
(1) 暗号化セッション鍵(公開鍵で暗号化され、かつバイナリデータが反転された状態)
(2) 暗号化前のデータのSHA1
(3) 暗号化後のデータ
では、(3) の暗号化されたデータをさらに解析していきます。
該当データが暗号化される前の状態は、 CryptEncrypt の処理が行われる前のメモリを見ることで確認することができます。
CryptEncryptによる暗号化時に使用されるセッション鍵(1)は、セッション鍵作成時のCryptGenKeyの呼び出し時に設定される引数から、AES 128bitのCBCモード(デフォルト)であることがわかります。
図47の通り、メモリ上で確認できるCryptEncryptにより暗号化される前のデータ(以下、(4)とする)についても、依然図17で示したような構造ではありません。
さらに処理を辿った結果、暗号化前のデータ(4)は以下のような構造になっていることがわかりました。
さらに図49におけるデータ部(以下、(5)とする)を見ていきます。
データ部(5)は、先頭が0x78, 0x01で始まっており、これは「zlib」形式で使用されるマジックヘッダであると想定でいます。
よってこのデータ部(5)をファイルに書き出し、zlib形式のファイルとして展開してみた様子が以下です。
この結果、図17と同様の構造を持ったデータが現れました。
このことから図17のデータは zlib で圧縮され、さらに AES による暗号化が行われたデータであったことが判明しました。
なお、Cookieの直後には暗号化された文字列の先頭に数字が付与されています。
この数字は、GetTickCountにより取得した「システムを起動した後の経過時間」を0xFFFFで割った余りを10進数に変換した値が割り当てられます。
最後に、以上で確認できた状況を整理すると以下の図の流れとなります。
これによりEMOTETが送信するリクエストヘッダに含まれる暗号化文字列の内容および暗号化処理を紐解くことができました。