【転載】既存機能を活用したマルウェア感染対策の考察～Windows Defender、レジストリのマクロ自動実行無効化、子プロセスの生成停止の3点がポイント～



こんな機能知らなかったので、とりあえず設定してみる https://t.co/b4gU74ehx0

Quoted tweet from @nknskn:

はてなブログに投稿しました
ぼくのかんがえたさいきょうのマルウェア感染対策（EmotetのVBAを覗いて、VBAマクロに対する防御を考える） - news-nknsknの日記 news-nknskn.hatenablog.com/entry/2020/10/…: こんな機能知らなかったので、とりあえず設定してみる https://t.co/b4gU74ehx0

はてなブログに投稿しました

ぼくのかんがえたさいきょうのマルウェア感染対策（EmotetのVBAを覗いて、VBAマクロに対する防御を考える） - news-nknsknの日記 news-nknskn.hatenablog.com/entry/2020/10/…



ーーーー

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

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

オンメモリでpowershellが実行されるーとかダウンローダを何回も重ねてるーとか、攻撃に使われているマルウェアにはいくつも特徴がありますが、まあ冷静に考えてオンメモリでpayloadを展開＆実行していても結局やってるのはプロセス生成のためのコマンド実行なわけです。要は「最悪このプロセス生成を止めりゃいいんでないの？」という発想です。
Emotetに関して細かいことを言うと、観測範囲内においては以前から最近のものまで全てVBA内にどうにかこうにかpayloadを隠し持たせ、（見づらくしただけっぽい）難読化コードからpowershellを実行するものが多い印象です。ちなみにいくつかのEmotet解析ブログを見たり自分でもEmotetのVBAコードを見たりしましたが、powershell実行時に使用されているのはたいていWin32_Process.Create()のようでした（下記リンクのうち下二つはその辺書いてない）。直近のEmotetについては以下すぐに触れますが、やっぱりWin32_Process.Create()でpowershellを叩くようになってました。

比較的最近の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以外の設定でなんとか止められないかをみてみます。

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

いつぞやにTwitterで呟いた気もしますが、Office 365を利用している場合、Webベース（ブラウザ）でWordやExcelを使用することができます。またそこでdoc等のファイルを開こうとすると互換性エラーが発生して、強制的にdocx等に変換、その後マクロがないファイルを開くことになります。そのため、Webベースでファイルを開くように徹底することでマクロを一切排除できることから、WebベースでOfficeファイルを扱うことは、VBAマルウェアに対して有効な手段と考えられます（あれ？ローカルのOfficeソフトウェアをなくしてしまえば。。。）。
ただし個人でOffice 365買うの？とか、企業でもすぐにOffice 365へ移行できないよ、、、みたいな話は往々にあることだと思います。なので今回はそれ以外の方法で止められないか、というところを引き続きみます。
不採用：Office 365 WebでOfficeファイルを開くポリシーにする

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

では、マクロを業務で利用することがない場合。そんな時はマクロを止めちゃうのが手っ取り早いでしょう。一番声高に推奨されている方法だと思います。
f:id:news-nknskn:20201007200032p:plain
OfficeTrustCenter
ただし、上記のリンク中にもある通り、自動実行を止めたとしてもユーザがマクロを有効にする可能性は大いにあります。というか、感染するケースはユーザが実行する方が多いと思います。なのでpowershellが実行されることを想定して、そこでブロックできないかを考えてみます。

Powershellの実行制限について

Powershellなど不要ら！という前提で考えてみます。その場合、Powershellのプログラムが実行されること自体を止めることが可能です。具体的には、Active Directoryのグループポリシー、ローカルの場合はローカルセキュリティポリシーからPowershellの実行を禁止します。
以下のようにフルパスで設定したとしましょう。
f:id:news-nknskn:20201007194031p:plain
securitypolicy
その後再起動などをしてコンピュータに反映すれば、以下のような形でpowershellの実行を止めることができます。これで、powershell -enc ...のようなプロセス生成は止めることができます。
f:id:news-nknskn:20201007194424p:plain
psblocked
しかしこの場合、Powershellのバイナリを%temp%とかにコピーした上でrenameされたら？とかUnmanaged powershellをダウンロードされて実行される場合は？cmdで頑張ってexe実行までいくケースもあるよね？って話になります。そもそも私はPowershellは日常的に使うので止めたくないです。

それならもうWord.exeからのプロセス生成止められない？Wordで子プロセス生成するケースってどんな場合よ、っていう話があります。
※なお、バイナリファイルの実行をホワイトリストレベルで制限をかける運用を考えている場合、セキュリティポリシーでのブロックは非常に有効な手段になると思います。AppLockerとかAppLocker bypassだとかその辺の話です。興味がある方は調べてみてください。

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

ようやく言いたいところにたどり着きました。Officeから子プロセスを生成する処理というのは、よほどマクロで変態的なことをしない限りないはずです。
以下はWord/Excelに関して、ドキュメントおよびワークブックを複数開いた際に生成されるプロセスおよびそのプロセスツリーを確認した画面です。通常時、子プロセスを生成することはなさそうに思えます（あったら完全に調査不足ですごめんなさい指摘してください）。
f:id:news-nknskn:20201007201155p:plain
OfficeProcesses
Windows 10からはWindows Defenderへの追加機能として、Exploit Guardというものが実装されています。どんな機能があるのか、という点は以下の記事を参照するのが一番良いと思うので適宜見ていただくとして、ここではそのうち一つの機能である「子プロセスを許可しない」設定に注目します。
いろいろggったり資料を見たりするとMS ATPとの組み合わせの記事も多く、「ATPお高いんでしょう？」みたいな印象を持たれがちがもしれませんが、実は（知ってる人は多いかもしれないですけど）Exploit protection自体はATPを導入しなくても普通の市販PCで設定することが可能です。実際に設定して、どう動くのか確認してみます。
Windows セキュリティ > アプリ＆ブラウザコントロール > Exploit protection settings（最下部）
f:id:news-nknskn:20201007201849p:plain
EndpointProtection1
プログラム設定 > プログラム名を追加
f:id:news-nknskn:20201007202017p:plain
EndpointProtection2
タスクマネージャ（とかtasklist）からWordやExcel等Officeソフトの正式プログラム名を確認しておきます（なぜ統一感がないのか）。
f:id:news-nknskn:20201007202308p:plain
f:id:news-nknskn:20201007202311p:plain
それぞれに対し、以下のような感じで「子プロセスの生成を許可しない」設定にし、適用します。設定後、Word、Excelは再起動します（not コンピュータ）。
f:id:news-nknskn:20201007202649p:plain
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が動いていることが確認できます。
f:id:news-nknskn:20201007204931p:plain
execviaexcel
Wordで実行
  • Runがめでたく死亡
f:id:news-nknskn:20201007205257p:plain
ErrorInRun
  • Execも同様に死亡
f:id:news-nknskn:20201007205351p:plain
ErrorInExec
※.Createの部分はOn Error Resume Nextをなくした状態でエラー出力なし、ただしプロセスも起動しないため画面キャプチャはなし。気になった方は試してみてください。
採用：Exploit ProtectionによるOfficeファイルからの子プロセス生成停止

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

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

採用した項目一覧

上記の内容から以下の項目を採用しました。これでEmotetのようなVBAマルウェアは、プロセス生成までの流れのどこかしらでシステム的にも止められるはずです。
  • Windows Defender（クラウド保護有効）によるプロセス生成系マクロを含むOfficeファイルの削除
  • マクロの自動実行完全無効化（レジストリ）
  • Exploit ProtectionによるOfficeファイルからの子プロセス生成停止

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

所感

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

追記１：Endpoint protection bypass

Twitterで以下のコメントをいただきました。
全くその通りで、特定のプログラムからのプロセス生成が止められるなら、それ以外のプログラムから実行すりゃええやんって話です。これでEndpoint protection bypassは可能です（ババーン）
ただし今回の設定においては以下が有効であるため、残念ながらこの.shellexecute入りのマクロ付きOfficeファイルは、クラウド保護機能によって消される、もしくはAMSIによってマクロの実行が止められる結果になります。
  • Windows Defender（クラウド保護有効）によるプロセス生成系マクロを含むOfficeファイルの削除
AMSIによってマクロの実行が止められる場合、AMSI bypassテクニックを使うことで検知回避が部分的に可能ですが、bypassテクニックのほとんどはamsiScanBufferに対してアクションを起こすもので、クラウド保護もまるごと回避できるものは寡聞にして知りません。
ここらへんいじくってbypassできれば楽なんだけど誰かブログに書いてくれたりしないかな。日本じゃ無理なのか？
そんなわけで今コメントいただいている方法では、まだ上記の設定でプロセス生成までの流れの中で止めることが可能です。
  • 10/8 AM, 2020: 誤字脱字修正, 「今回不採用だったけど手としてはアリだと思う項目」を追加
  • 10/8 PM, 2020: 追記１


以上
Labels: ,