Tanium Threat ResponseでEmotet（エモテット）の挙動を追う
2023年３月頃からEmotetの感染手段として、OneNoteドキュメントを悪用する手法が確認されています。新しい手法は、従来のEmotetの感染に悪用されたOfficeドキュメントのマクロ機能を利用したものではなく、またウイルススキャンなどの検知から逃れるためファイルサイズを500MB以上にするなど、これまでの手法とは異なるものとなっています。本ブログではThreat Response（THR）の各機能を使って調査したEmotetの挙動を紹介します。THRのRecorder機能が多くの情報を記録しているため長文となっておりますが、最後までお付き合いいただけましたら幸いです。
Emotetは、もともとオンラインバンクの認証情報を盗むバンキングトロジャンとして、2014年頃に初確認されたと言われています。主になりすましメールの添付ファイル経由で感染が広がり、日本では2019年後半から2020年11月頃に猛威をふるった結果、感染組織は数百社を超えたと報告されていました。世界でも被害が広がっていた中、2021年の１月末にEUROPOLによってEmotetの活動を止めるためのOperation LadyBirdが実施され、テイクダウンされました。この活動によりEmotetが利用するボットネットを制御することに成功し、すでにEmotetに感染していた端末もリモートから無害化する処置が2021年の4月末に実施され、感染端末はほとんど観測されなくなりました[1, 2]。
Emotetとは
根絶されたはずのEmotetでしたが、テイクダウンから1年も経たない2021年11月頃に、Emotetの感染を狙うメール攻撃の活動が再確認されはじめました。2022年3月頃には日本でまた感染が爆発的に広がり、Emotetというマルウェアの認知度もかなり上がったのではないでしょうか[3]。 活動再開後も非常に高い感染力を保ちながら、これまで活動の休止と再開を繰り返すと同時に、Emotetマルウェアも進化し続けています。 感染後はメールやブラウザの認証情報を盗んだり、TrickBotやCobaltStrikeなどの別のマルウェアをダウンロードさせたり、最終的にはランサムウェアの感染まで至ったケースも過去には報告されています。
これまでのEmotet感染のパターン
これまでに観測されてきた主な感染パターンは、なりすましメールに添付されたZIPファイルに含まれるOffice系のドキュメントファイル（WordやExcelなど）を展開し、それらのファイルを開いてマクロを実行すると感染の挙動が開始するというものです。添付のZIPファイルはパスワード付きで暗号化されている場合もあるため、メールセキュリティなどで中身を確認することができず、すり抜けるケースがあります。また、あまり多くは観測されていないですが、過去にはメール本文に記載されているリンクからOfficeドキュメントをダウンロードさせるものや、偽アプリのインストーラ経由（CVE-2021-43890を悪用）でEmotetに感染させるケースもありました[5]。
Officeドキュメントのマクロ機能を悪用するケースは、主にWordとExcelのドキュメントで、ファイルの拡張子は .doc, .docm, .xls, .xlsmとなっています。これは .docxや.xlsxのファイルではマクロ機能が利用できないためです。これらのOfficeドキュメントを開いただけでは感染しませんが、コンテンツの有効化の警告ボタンをクリックして承諾すると、悪意のあるマクロが実行され感染します。初期の感染パターンでは、マクロが実行されると難読化されたPowerShellのスクリプトが実行され、Emotet本体のEXEファイルがダウンロードされて実行・感染していましたが、活動が再開された2021年の11月以降はPowerShellの他、MSHTAなどによっても不審なスクリプトが実行され、Emotet本体がEXEファイルでなくDLLファイルとしてダウンロードされはじめました。 2022年4月頃からは、マクロ機能を利用しない手法として、LNKファイル（ショートカットファイル）やXLLファイル（Excelアドイン用DLL）を悪用してEmotetに感染させるパターンも観測されていました。XLLを悪用するケースはマクロの場合と同様に、実行時にアドイン利用に対する警告が表示され承諾しない限り感染しませんが、LNKファイルを悪用したケースは警告が表示されず、すぐに悪意のあるスクリプトが実行されEmotetに感染するものでした。
最新版やパッチ適用されたOfficeでは、インターネット等からダウンロードされたOfficeファイルはマクロが無効化されるようになりましたが、2022年の11月頃にはこの無効化を回避させるためにドキュメントファイルを信頼できるフォルダに移動させて、マクロを実行させようとするパターンもありました。ドキュメントファイルを信頼できるフォルダに移動させるためには管理者権限が必要なため、警告ウインドウが表示されます。
いずれのケースも、ダウンロードされたEmotet本体のDLLファイルはrundll32.exeやregsvr32.exeなどのWindows標準のプログラムで読み込まれて起動され、Emotetに感染するパターンが主流となっています。またEmotetに感染すると、自分自身の常駐化を図るため、レジストリのRUNキーにEmotet本体のDLLを読み込んで起動させるエントリが追加されています。
OneNoteドキュメントを悪用した感染パターン
2023年３月からは、これまでの手法と違ったマクロ機能を利用しないOneNoteファイルを悪用するパターンや、ファイルサイズの大きさで検知を逃れようとする感染パターンが観測され、各機関から注意喚起がなされています[3, 6]。 Emotetへ感染させる手口として、OneNote形式のファイル(.one)がなりすましメール等に添付されています。このOneNoteファイルを開いただけでは感染しません。OneNoteファイルを開くと、ドキュメントの画像内のボタンをダブルクリックするように促すメッセージが表示され、ダブルクリックすると警告画面が表示されます。この警告画面でOKボタンをクリックすることで、Emotetに感染させるための悪意のあるスクリプトが実行される仕組みになっています。実際に検体[7]を使って、OneNote経由でのEmotet感染の挙動をTHRの機能を使って追ってみました。
ではこの警告ウインドウのOKボタンを押して悪意のあるスクリプト（output1.js)が実行された後の挙動を、Tanium THRのRecorderに記録されたイベントから追ってみたいと思います。
1. まず、OneNoteのプロセスがoutput1.jsスクリプトファイルを作成し、このスクリプトを実行させるために、Windowsのスクリプトエンジン（wscript.exe）が子プロセスとして起動されます。
作成されたoutput1.jsファイルはwscript.exeで実行後、OneNoteのプロセスによってすぐに削除されています。JSファイルの中身は、難読化されたJavaScriptが記述されていました。このスクリプトには、Emotetをどこからダウンロードするのか定義されています。
2. 次に、このwscript.exeプロセスの挙動を追ってみます。このプロセスがEmotetをダウンロードするためのさまざまなイベントを発生させているのが確認できます。Emotetの多くは侵害されたウェブサイト等にホストされていることが多く、スクリプトの実行によってそれらのサイトからのダウンロード試みます。プロセスの挙動としては、Emotetがホストされているウェブサイトに対してHTTPのGETリクエストを送ります。その際、ウェブサイトのドメイン名に対してDNSの名前解決を行い、解決されたIPアドレスに対して通信を行ってZIPファイルをダウンロードし、そのファイルを展開してEmotet本体のDLLファイルがディスク上に作成されます。Recorderに記録されたイベントを一つひとつ見ていきましょう。
Output1.js内の難読化されたスクリプトが実行された結果、wsciprt.exeプロセスによって実行されたDNSイベントとネットワークイベントを確認しました。今回の例では、5つのドメイン名に対して名前解決されたIPアドレスに対して、ポート80による通信が成功していました。
Emotet本体のマルウェアはウェブサイトにホストされていることが多く、今回のケースでもポート80に対してHTTP通信を行っていることが予想されました。Recorderには、このポート80に対するHTTP通信のリクエストとレスポンスヘッダを記録する機能があります。例えば、DNSイベントで名前解決が行われていたドメイン（sipo[.]ru）に対するHTTP通信を、Recorderから確認してみます。
今回のケースでは、Emotet本体のDLLはそのままダウンロードされるのではなく、ZIPファイル形式でダウンロードされることが確認できます。これには理由があり、後ほど説明いたします。発生していたHTTPリクエストの通信先は、５つのドメインでした。同様に確認したところ、すべてZIPファイルがダウンロードされていました。
ダウンロードされたZIPファイルをさらに確認するために、今度はwscript.exeプロセスのファイルイベントに着目します。これらのダウンロードされたZIPファイルは、INetCache（Temporary Internet Files）フォルダに作成されているのが確認できます。このフォルダにダウンロードされたZIPファイルは削除されずに残っていたので、一つずつ中身を確認したところ、すべてDLLファイルが含まれていました。最後にダウンロードされたnvaADQEs6q.zipファイルに含まれているDLLのファイル名が、 %LOCALAPPDATA%¥Temp¥配下に作成されたDLLのファイル名と同一でした。
この作成されたDLLファイルが、Emotet本体のファイルです。今回のEmotetで特徴的なのは、この展開されたEmotet本体のDLLのファイルサイズが500MBを超えているという点です。ダウンロードされたZIPファイルのサイズはどれもおよそ960KB前後でしたが、展開してみるとすべて500MBを超えるサイズのDLLファイルでした。システムへの負荷の観点から、あるサイズ以上の大きいファイルはウイルススキャンやファイルのハッシュ値計算を行わない設定になっているケースがあります。Emotetはファイルサイズを大きくすることで、スキャンやハッシュ値による検知から逃れようとしている、もしくはセキュリティ製品のサンドボックス実行対象からの回避を試みていると思われます。今年の3月以降この手法での攻撃が観測されてから、実際にEmotet感染数の増加が報告されています[3]。今回のパターンでは500MBのファイルをダウンロードさせることが困難なため、まずは数百KB程度のZIPファイルでダウンロードさせているのではないかと推測できます。
3. そしてZIPファイルから展開されたDLLファイルがどのように悪用されているのか、さらにプロセスの挙動をRecorderで追っていきます。DLLファイルは、何かのプロセスによって読み込まれて機能するものです。そのためwscript.exeプロセスは、このEmotet本体のDLLをWindows標準のプログラムであるregsvr32を使って読み込み、Emotetのプロセスを起動させます。この時点でEmotetに感染した状態となります。
Emotetとして動き出したregsvr32.exeプロセス（PID=7968）の挙動を確認します。EmotetはC2サーバと思われるIPアドレス（209.126.85[.]32）に対して、通信を継続的に行い始めました。また起動直後には自分自身の常駐化を図るため、レジストリのRUNキーに自動起動の登録を行っています。その後、ランダムな名前のEXEファイルを %LOCALAPPDATA%¥Temp¥配下に３つ作成し、すぐに削除しています。
レジストリのRUNキーに、regsvr32コマンドを使って %LOCALAPPDATA%¥Temp¥ 配下のDLLを読み込ませて起動するようなエントリーが存在している場合は、Emotetへの感染が疑われます。
4. Emotetとして起動しているregsvr32.exeプロセスが作成した３つのEXEは、子プロセスとしても起動しています。これらのEXEファイルはEmotet自身によってすぐに削除されていましたが、３つのうち２つはRecorderにハッシュ値（MD5: 3d7dd220a1794c286670757dbb0be57c）が記録されていました。調べてみるとこのハッシュ値は、Windowsの正規のプログラムであるcertutil.exeと同一のものでした。
Emotetはこれらのプログラムで何を行っているのでしょうか？これまでに観測された過去の感染パターンにおいても、Emotet感染後にcertutil.exeファイルと同一のハッシュ値を持つランダムなファイル名のEXEが実行されているのを確認しています。
今回のケースも含めていずれのケースでも、これらランダムな名前のEXEプロセス起動時に /scomma というコマンドラインが利用されていたり、プロセス起動時に読み込まれたライブラリにOfficeやOutlook関連のDLLが含まれていたり、さらに作成されるファイルにOutlookの文字列が含まれることが、Recorderに記録されたイベントから確認できました。MBSD社の過去の調査によると、EmotetにはWindows正規のプログラムを利用した隠蔽テクニックとして、プロセスハウリングという手法が使われていると報告されていました。同報告では /scomma というコマンドラインは、Nirsoftというパスワード抽出プログラムをインジェクションによって置き換え、悪用している可能性を示唆していました[8]。プロセスハウリングは、正規のプロセスを一時停止させ、悪意のあるコードに置き換えるプロセスインジェクションの手法の一つです。Threat Responseではバージョン3.8以降、Windows OSにおけるプロセスインジェクションの監視とアラート検知の機能が追加されています。実際にこれらのプログラムがEmotetのregsvr32.exeプロセスによってインジェクションされているのが、複数回アラート検知されていました。Emotetの子プロセスがWindowsの正規のプログラムに隠蔽されていたとしても、プロセスインジェクションの監視によって検知可能ということが、今回の検証で確認できました。
Threat Responseでは、プロセスインジェクションによるアラート検知の他に、Signalsの振る舞いによる検知も確認しております。
WordやExcelドキュメントを悪性した感染パターン
ここまでOneNoteドキュメントを起点とした感染パターンの挙動を紹介いたしましたが、従来どおりのWordやExcelドキュメントのマクロ機能を悪用した攻撃も観測されています。ただこれまでと違う点は、OneNoteの場合と同様に、ファイルサイズが500MBを超えるファイルを利用している点です。さらにEmotet本体のDLLファイルだけではなく、WordやExcelドキュメントのファイルサイズも、メールに添付されているZIPファイルを展開すると500MBを超えるサイズとなり、検知を逃れようと試みています。ファイルサイズの他に、引き続きWordやExcelドキュメントのマクロ機能の悪用についても注意が必要です。
Emotetハンティングで感染の疑いのある端末を探す
Recorderに記録された情報を元に、OneNoteドキュメントを悪用したEmotet感染パターンの挙動が確認できました。同様にいくつかの検体を使って検証してみましたが、以下の点は大きな違いがなく、Emotet感染時の共通の挙動として、ハンティングや振る舞い検知のカスタムルール作成に利用できそうです。
- Emotet本体のDLLファイルは、最終的に以下の場所（%LOCALAPPDATA%）に作成される
- C:¥Users¥<user>¥AppData¥Local¥(Temp)¥ランダムフォルダ名¥ランダムなファイル名のDLL
- Emotet本体は、regsvr32経由で%LOCALAPPDATA%配下のDLLを読み込んで起動する
- Emotet本体のDLLファイルサイズは、500MBを超える
- Regsvr32.exeのプロセスで永続化のため、上記のDLLをregsvr32経由で自動起動するようにユーザハイブのRUNキーに登録する
- Emotetを読み込んで起動したregsvr32.exeは、C2とネットワーク通信を行う
- 起動したEmotetは 、C:¥Users¥<user>¥Appdata¥Local¥Temp¥ 配下にEXEファイルを作成して情報収集を行う
TaniumのQuestionを使って、上記の条件に合う端末やイベントを、全台に対して迅速に検索（ハンティング）することができます。検索のために使ったQuestionを保存済みQuestionとして作成し、Taniumのコンソール上のダッシュボードに登録することも可能です。例えばハンティング用ダッシュボードの例として、以下のようなものを作成できます。
またEmotet共通の挙動を活用して、振る舞い検知のルールをカスタムで作成することも可能です。以下は、Emotetとして起動したregsvr32.exeの振る舞いを定義してアラート検知させた例の一つです。
さらにJPCERTから提供されているEmoCheck[9]を、Taniumの機能を使って端末へ全台配布し、感染の有無のチェックのためEmoCheckの実行を定期的に行い、その結果をTaniumのQuestionを使って確認するということも可能です。LAC社からも、Taniumを使ったEmoCheck活用法が紹介されています[10]。
まとめ
本ブログでは、Emotetのこれまでの感染のパターンから、最近観測された新しい感染手法について紹介しました。調査にあたっては、検体からEmotetに感染させた環境でTanium Threat Response（THR）のRecorder機能を使って、詳しく挙動を追ってみました。Emotetはこれまで何度も更新されてきており、今回確認した挙動はあくまで一例に過ぎませんが、THRを使ったインシデント調査やEmotetの挙動を理解するにあたって、参考になれば幸いです。
References
[2] https://blogs.jpcert.or.jp/ja/2021/02/emotet-notice.html
[3] https://www.jpcert.or.jp/at/2022/at220006.html
[4] https://jsac.jpcert.or.jp/archive/2022/pdf/JSAC2022_5_tani-kino-sajo_jp.pdf
[5] https://www.jpcert.or.jp/at/2021/at210051.html
[6] https://www.ipa.go.jp/security/announce/20191202.html#L24
[7] https://tria.ge/230321-2syjdade86
[8] https://www.mbsd.jp/blog/20181225_2.html
[9] https://github.com/JPCERTCC/EmoCheck/releases
[10] https://www.lac.co.jp/lacwatch/service/20221024_003151.html
タニウム合同会社 野崎 喜裕
Sr.Director Technical Account Management
