ぼくのかんがえたさいきょうのマルウェア感染対策（EmotetのVBAを覗いて、VBAマクロに対する防御を考える）

副題：VBAマクロでInitial Access payloadばっか作ってるヤツが一番相手にしたくないと思う設定

Emotetが（何故か）再流行したみたいですね。

本当になぜ再流行したかイマイチわからず、「そもそもどんな感じで書かれているのか」「検知はそんなに難しいのか」「止める方法ってマクロ無効化とかファイル開かない、みたいなのしかないの？」とかちょっと考えてみたくなったので、知ってる範囲でEmotetを止めるための設定を書いてみました。他にこんな方法もあるよ、とかあればコメントいただけると嬉しいです。コマンド一発でグループポリシーに適用させられるやつだとより大勢の管理者の方が幸せになれる気がします。「この設定ファイルイカしてるからグループポリシーにインポートしてみなよ！」みたいのでも可（血涙）DoDのSTIG良いですよねえ...

以下、TOC

最近のマルウェアについてコメント

オンメモリでpowershellが実行されるーとかダウンローダを何回も重ねてるーとか、攻撃に使われているマルウェアにはいくつも特徴がありますが、まあ冷静に考えてオンメモリでpayloadを展開＆実行していても結局やってるのはプロセス生成のためのコマンド実行なわけです。要は「最悪このプロセス生成を止めりゃいいんでないの？」という発想です。

Emotetに関して細かいことを言うと、観測範囲内においては以前から最近のものまで全てVBA内にどうにかこうにかpayloadを隠し持たせ、（見づらくしただけっぽい）難読化コードからpowershellを実行するものが多い印象です。ちなみにいくつかのEmotet解析ブログを見たり自分でもEmotetのVBAコードを見たりしましたが、powershell実行時に使用されているのはたいていWin32_Process.Create()のようでした（下記リンクのうち下二つはその辺書いてない）。直近のEmotetについては以下すぐに触れますが、やっぱりWin32_Process.Create()でpowershellを叩くようになってました。

• Emotet (Part 1/3) : PCにどのように感染するか | Bromiumブログ
• [PDF] EMOTET: A TECHNICAL ANALYSIS OF THE DESTRUCTIVE, POLYMORPHIC MALWARE - Bromium
• A Deep Dive into the Emotet Malware
• 流行マルウェア「EMOTET」の内部構造を紐解く | MBSD Blog
• Emotetについて(参考情報) | FireEye Inc
• 10/5, 2020にあったイエラエ勉強会で話されてた内容知りたい...

比較的最近のEmotet VBA（2検体）について

※専門家の知見のもと安全に十分配慮して（ry

細かいところは省略して、重要だと思ったところだけ載せます。難読化している箇所なんていくらでも変えられるから変えているのであって、そこに注目するのは時間の無駄です。想定している動作をさせる上で変えようがないところを見ていきます。

• 9c6f98f54b5f8b43d3ced2c547a09d7ea30578c696263ad60666ea9e75a22daa

Private Sub _
Document_open()
F5rwxzbfuowsqkbdt.Xbq37kxh8w2e
End Sub

Function Xbq37kxh8w2e()
   On Error Resume Next

'(snip)

Jpfgivlyicd99r9 = Array(Y6gqr6abanqlu + "Wyvln5tc5eq37uvul1 Pdetuctodf7fClhqmwed17ab_10rrr Se951ebi5pq", CreateObject(Bqqta6d91epi).Create(Bqf_3mrtgx7xegw45i, Z_qxvnehzwd7iesunu, Whewr2ng_0nf6zf), Qy4p7grrmlokyk0cbt + "Jenkodabwww Wks5jgvvqe737k Lwkcqakg5joom D6615tagrz7r0wjiv")

'(snip)

End Function

'(snip)

• 9140dd246193f4397044dce4c62930cb81b729b3900b10c5e9ecf6778a077648

Private Sub Document_open()
Rt055d5md2s7_.Tv2ghyjqs9ofp1
End Sub

'(snip)

Function Tv2ghyjqs9ofp1()
On Error Resume Next

'(snip)

S_widwqm3orw6j3ur.Create CVar(Fq4_elcsi9j), Uc3rl8girme, Qtx_okh1te1i98

'(snip)

End Function

'(snip)

どちらの検体もみて分かる通り、マクロ有効時（Document_open）に、プロセスを生成する（.Create）ことがわかります。 その後、メモリ上に展開されたpowershellがダウンローダとして機能して、exeを4-5 URLから取ってこれるか確認して、ダウンロードできたら実行して〜みたいな流れになりますが（メールでの感染拡大はexeでやってる）、このブログでは「そこまで行ったら負け」という考えでいきます。

アンチウイルスソフトについてコメント

で、Anti-Virus software（以降、AV）関連の話に移ると、（細かいところは省きますが）最近のWindows Defenderさん（以降、Defender）は大変にやっか...優秀になっていて、初弾にあたるVBAマクロに「コマンド実行をするための関数」（Wscript.ShellのRunとかExecとかWin32_ProcessのCreateとかCreateRemoteThreadだとか）が含まれていると、「Defenderが有効」かつ「Defenderのクラウド保護機能が有効」な場合（デフォルト設定ではどちらも有効）に、実行前のOfficeファイルごと削除するようになってたりします。

上記のようなEmotetのマクロには見た通り.Create()が入っているので、上記を満たす端末においては、ファイルを開く前にDefenderがそのファイルを削除してくれるはずです（ブログ執筆時は消されてるものの今後はわからない）。

そんなわけで、現時点における個人の印象としては（Defenderに頼っているので）「Emotetなぞ恐るるに足らず。なんでざわざわしてるのかよくわからん」という感じですが、まあEmotetに限らず攻撃者は手を変え品を変え、検知されないようバレないようにやってくるものです。どうやったら作れるんですかねぇ...最近は開発方針が今一つ（ry。そんなわけでAV以外の設定でなんとか止められないかをみてみます。

• 採用する設定：Windows Defender（クラウド保護有効）

Office 365 webでのファイルオープンについて

いつぞやにTwitterで呟いた気もしますが、Office 365を利用している場合、Webベース（ブラウザ）でWordやExcelを使用することができます。またそこでdoc等のファイルを開こうとすると互換性エラーが発生して、強制的にdocx等に変換、その後マクロがないファイルを開くことになります。そのため、Webベースでファイルを開くように徹底することでマクロを一切排除できることから、WebベースでOfficeファイルを扱うことは、VBAマルウェアに対して有効な手段と考えられます（あれ？ローカルのOfficeソフトウェアをなくしてしまえば。。。）。

ただし個人でOffice 365買うの？とか、企業でもすぐにOffice 365へ移行できないよ、、、みたいな話は往々にあることだと思います。なので今回はそれ以外の方法で止められないか、というところを引き続きみます。

• 不採用：Office 365 WebでOfficeファイルを開くポリシーにする

マクロの自動実行無効化について

では、マクロを業務で利用することがない場合。そんな時はマクロを止めちゃうのが手っ取り早いでしょう。一番声高に推奨されている方法だと思います。

OfficeTrustCenter

• 参考：Emotet（エモテット）対策の手順をご紹介！－LanScope Catを活用して対策をやってみた－ | wizLanScope ※MOTEX社の製品を推奨しているわけではありません。「emotet マクロ 無効化」でGoogle検索した際に、Topに出てきたため採用しています。
• 採用：マクロの自動実行完全無効化（レジストリ）

ただし、上記のリンク中にもある通り、自動実行を止めたとしてもユーザがマクロを有効にする可能性は大いにあります。というか、感染するケースはユーザが実行する方が多いと思います。なのでpowershellが実行されることを想定して、そこでブロックできないかを考えてみます。

Powershellの実行制限について

Powershellなど不要ら！という前提で考えてみます。その場合、Powershellのプログラムが実行されること自体を止めることが可能です。具体的には、Active Directoryのグループポリシー、ローカルの場合はローカルセキュリティポリシーからPowershellの実行を禁止します。

• ローカルセキュリティポリシーの設定例

以下のようにフルパスで設定したとしましょう。

securitypolicy

その後再起動などをしてコンピュータに反映すれば、以下のような形でpowershellの実行を止めることができます。これで、powershell -enc ...のようなプロセス生成は止めることができます。

psblocked

しかしこの場合、Powershellのバイナリを%temp%とかにコピーした上でrenameされたら？とかUnmanaged powershellをダウンロードされて実行される場合は？cmdで頑張ってexe実行までいくケースもあるよね？って話になります。そもそも私はPowershellは日常的に使うので止めたくないです。

それならもうWord.exeからのプロセス生成止められない？Wordで子プロセス生成するケースってどんな場合よ、っていう話があります。

• 不採用：セキュリティポリシーでのPowershell実行禁止

※なお、バイナリファイルの実行をホワイトリストレベルで制限をかける運用を考えている場合、セキュリティポリシーでのブロックは非常に有効な手段になると思います。AppLockerとかAppLocker bypassだとかその辺の話です。興味がある方は調べてみてください。

Officeプログラムからの子プロセス生成を止める

ようやく言いたいところにたどり着きました。Officeから子プロセスを生成する処理というのは、よほどマクロで変態的なことをしない限りないはずです。

以下はWord/Excelに関して、ドキュメントおよびワークブックを複数開いた際に生成されるプロセスおよびそのプロセスツリーを確認した画面です。通常時、子プロセスを生成することはなさそうに思えます（あったら完全に調査不足ですごめんなさい指摘してください）。（→ありました。下部の追記２）

OfficeProcesses

Windows 10からはWindows Defenderへの追加機能として、Exploit Guardというものが実装されています。どんな機能があるのか、という点は以下の記事を参照するのが一番良いと思うので適宜見ていただくとして、ここではそのうち一つの機能である「子プロセスを許可しない」設定に注目します。

攻撃を軽減するために exploit protection を有効にする - Windows security | Microsoft Docs

Exploit Protection のカスタマイズ - Windows security | Microsoft Docs

いろいろggったり資料を見たりするとMS ATPとの組み合わせの記事も多く、「ATPお高いんでしょう？」みたいな印象を持たれがちがもしれませんが、実は（知ってる人は多いかもしれないですけど）Exploit protection自体はATPを導入しなくても普通の市販PCで設定することが可能です。実際に設定して、どう動くのか確認してみます。

Windows セキュリティ > アプリ＆ブラウザコントロール > Exploit protection settings（最下部）

EndpointProtection1

プログラム設定 > プログラム名を追加

EndpointProtection2

タスクマネージャ（とかtasklist）からWordやExcel等Officeソフトの正式プログラム名を確認しておきます（なぜ統一感がないのか）。

• excel.exe
• winword.exe

それぞれに対し、以下のような感じで「子プロセスの生成を許可しない」設定にし、適用します。設定後、Word、Excelは再起動します（not コンピュータ）。

winword-Disallowchildprocesses

それでは以下のようなサンプルマクロを書いて、実行してみます。

※ここでは動作確認のためWordにブロック設定、Excelにはブロックしない設定にしています。

Private Sub Test()
    'On Error Resume Next
    CreateObject("WScript.Shell").Run "cmd.exe"
    CreateObject("WScript.Shell").Exec "powershell.exe"
    e = GetObject("winmgmts:\\.\root\cimv2:Win32_Process").Create("notepad.exe", null, null, intProcessID)
End Function

Excelで実行、cmd, powershell, notepadが動いていることが確認できます。

execviaexcel

Wordで実行

• Runがめでたく死亡

ErrorInRun

• Execも同様に死亡

ErrorInExec

※.Createの部分はOn Error Resume Nextをなくした状態でエラー出力なし、ただしプロセスも起動しないため画面キャプチャはなし。気になった方は試してみてください。

• 採用：Exploit ProtectionによるOfficeファイルからの子プロセス生成停止

その他のファイルについて

攻撃者は他にもWSH（.js, .vbs）やらexeやらを送ることでどうにかこうにか端末を感染させようと試みたりしますが、その辺に関してはまた別のポリシー設定であったり、外から送られてきたexe実行するの？みたいな話があったりしてまた長くなるので以下省略

採用した項目一覧

上記の内容から以下の項目を採用しました。これでEmotetのようなVBAマルウェアは、プロセス生成までの流れのどこかしらでシステム的にも止められるはずです。

• Windows Defender（クラウド保護有効）によるプロセス生成系マクロを含むOfficeファイルの削除
• マクロの自動実行完全無効化（レジストリ）
• Exploit ProtectionによるOfficeファイルからの子プロセス生成停止

今回不採用だったけど手としてはアリだと思う項目

• Office 365 WebでOfficeファイルを開くポリシーにする
• セキュリティポリシーでのPowershell実行禁止

所感

• これで取り合えずマクロを開いて即感染！みたいなことは防げると思われ
• 正直最後のExploit protectionだけ有効にすればいいんじゃないかな、みたいな話はありますが、Officeファイル以外からの攻撃手法もあるので複合的に守っていきましょう
• あれ？Windows Defenderここまで強くなってたの？
• 侵入後の話でZerologonとかありますけど、どうやって打ち込むところまで辿り着くんでしょうね

追記１：Exploit protection bypass

Twitterで以下のコメントをいただきました。

今のEmotetドロッパーにはExploit Guardが有効なんですねー
ただDCOM使うパターン使われるとこんな感じにバイパスされる気はします(explorer.exeの子プロセスになるため) https://t.co/nwGa3x7KdZ pic.twitter.com/y5M0r7dZpN

— しゅーと (@shutingrz) 2020年10月8日

全くその通りで、特定のプログラムからのプロセス生成が止められるなら、それ以外のプログラムから実行すりゃええやんって話です。これでExploit protection bypassは可能です（ババーン）

ただし今回の設定においては以下が有効であるため、残念ながらこの.shellexecute入りのマクロ付きOfficeファイルは、クラウド保護機能によって消される、もしくはAMSIによってマクロの実行が止められる結果になります。

• Windows Defender（クラウド保護有効）によるプロセス生成系マクロを含むOfficeファイルの削除

AMSIによってマクロの実行が止められる場合、AMSI bypassテクニックを使うことで検知回避が部分的に可能ですが、bypassテクニックのほとんどはamsiScanBufferに対してアクションを起こすもので、クラウド保護もまるごと回避できるものは寡聞にして知りません。

ここらへんいじくってbypassできれば楽なんだけど誰かブログに書いてくれたりしないかな。日本じゃ無理なのか？

GitHub - med0x2e/GadgetToJScript: A tool for generating .NET serialized gadgets that can trigger .NET assembly load/execution when deserialized using BinaryFormatter from JS/VBS/VBA based scripts.

そんなわけで今コメントいただいている方法では、まだ上記の設定でプロセス生成までの流れの中で止めることが可能です。

追記２：通常操作時のオブジェクト生成について

Twitterで通常使用時に関して以下の指摘をいただきました。

なるほどなぁ。
ところで。例えばWordにEXCELのオブジェクト埋め込んで、ダブルクリックで編集する時って、チャイルドプロセス起こしてる気がします。
良く知らないけど。 https://t.co/mBRsVrMOsU

— 渡来　夢吉 (@try_ymk) 2020年10月8日

あー、これは確かにそうかも、と思ったので簡単に調べてみました。 結論としては、「すでにExcelが起動している場合には新規オブジェクトの埋め込みも既存オブジェクトの編集もできる、Excelが起動していない場合はExcelの起動に失敗してオブジェクトの埋め込み・編集ができない」です。

オブジェクト埋め込み時の挙動をProcess Monitorで見てみるとこんな感じです。

• Excelが起動しておらず、プロセス生成に失敗したパターン、ここで止まる（厳密にはレジストリ操作に関するログが続くけど細かすぎるので省略）

FailedToRunExcel

• Excelが起動しており、オブジェクト埋め込みに成功したパターン、上記のログののち、Threadに関するログが出てくる

起動しているオブジェクトと通信してなんやかんやうまくやってるんだろうなーと推測。

うーん、これは普段使いとしてどうなんだろうか。Excelをバックグラウンドプロセスとして常時動かすようにしておけば特に意識しなくてよさそうだけど、メモリ食われて操作性が悪くなる気がする。

追記３：印刷オプションが利用できない問題について

ブログの下部にてコメントいただきました。

VM上かつ「Microsoft Print to PDF」で検証したときには問題なくPDFを作成できていたため、完全に見落としていました。実端末で確認したところ、プリンタオプションを使用する際に以下のように「splwow64.exe」を生成して、印刷系の操作を行うようでした。プリンタドライバが追加されたら実行されるようにでもなってるんでしょうか。

図は実端末上でProcess Hackerを使用してプロセスツリーを確認した際のものです。

コメントでも返しましたが、ファイル＞印刷オプションのすべてが使えなくなるようで、印刷の代替案としては「エクスポート」機能を利用してPDFを作成し、PDFビューアから印刷を行うしかなさそうでした。

Wordでの印刷を前提にしたレイアウトの場合はレイアウト崩れが気になるケースがありそう、かつ正直めんどくさいのでExploit Protection優先は微妙かもしれませんね。

Exploit Protection bypass（追記１）をDefenderのクラウド保護で止めた時点で、クラウド保護有効だけでいいのでは、ということに気が付いた人がいるかもしれませんが、まあ次善策ということで引き続き検討したいと思います（善？）

---

• 10/8 AM, 2020: 誤字脱字修正, 「今回不採用だったけど手としてはアリだと思う項目」を追加
• 10/8 PM, 2020: 追記１
• 10/9 AM, 2020: 追記２
• 10/9 PM, 2020: 追記３

---

以上