こんな機能知らなかったので、とりあえず設定してみる 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が(何故か)再流行したみたいですね。
本当になぜ再流行したかイマイチわからず、「そもそもどんな感じで書かれているのか」「検知はそんなに難しいのか」「止める方法ってマクロ無効化とかファイル開かない、みたいなのしかないの?」とかちょっと考えてみたくなったので、知ってる範囲でEmotetを止めるための設定を書いてみました。他にこんな方法もあるよ、とかあればコメントいただけると嬉しいです。コマンド一発でグループポリシーに適用させられるやつだとより大勢の管理者の方が幸せになれる気がします。「この設定ファイル
イカ してるからグループポリシーにインポートしてみなよ!」みたいのでも可(血涙)
DoD のSTIG良いですよねえ...最近のマルウェア についてコメント オンメモリで
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 
Jpfgivlyicd99r9 =  Array ( Y6gqr6abanqlu +  "Wyvln5tc5eq37uvul1 Pdetuctodf7fClhqmwed17ab_10rrr Se951ebi5pq" ,  CreateObject ( Bqqta6d91epi). Create( Bqf_3mrtgx7xegw45i,  Z_qxvnehzwd7iesunu,  Whewr2ng_0nf6zf),  Qy4p7grrmlokyk0cbt +  "Jenkodabwww Wks5jgvvqe737k Lwkcqakg5joom D6615tagrz7r0wjiv" ) 
End  Function 
9140dd246193f4397044dce4c62930cb81b729b3900b10c5e9ecf6778a077648 
Private  Sub  Document_open() 
Rt055d5md2s7_. Tv2ghyjqs9ofp1
End  Sub 
Function  Tv2ghyjqs9ofp1() 
On  Error  Resume  Next 
S_widwqm3orw6j3ur. Create CVar ( Fq4_elcsi9j),  Uc3rl8girme,  Qtx_okh1te1i98
End  Function 
どちらの検体もみて分かる通り、マクロ有効時(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ファイルを開くポリシーにする
マクロの自動実行無効化について では、マクロを業務で利用することがない場合。そんな時はマクロを止めちゃうのが手っ取り早いでしょう。一番声高に推奨されている方法だと思います。
OfficeTrustCenter 
ただし、上記のリンク中にもある通り、自動実行を止めたとしてもユーザがマクロを有効にする可能性は大いにあります。というか、感染するケースはユーザが実行する方が多いと思います。なので
powershell が実行されることを想定して、そこでブロックできないかを考えてみます。
以下のようにフルパスで設定したとしましょう。
securitypolicy 
その後再起動などをしてコンピュータに反映すれば、以下のような形で
powershell の実行を止めることができます。これで、
powershell -enc ...のようなプロセス生成は止めることができます。
psblocked しかしこの場合、 Powershell のバイナリを%temp%とかにコピーした上でrenameされたら?とかUnmanaged  powershell をダウンロードされて実行される場合は?cmdで頑張ってexe実行までいくケースもあるよね?って話になります。そもそも私は Powershell は日常的に使うので止めたくないです。 
それならもうWord.exeからのプロセス生成止められない?Wordで子プロセス生成するケースってどんな場合よ、っていう話があります。
※なお、バイナリファイルの実行を
ホワイトリスト レベルで制限をかける運用を考えている場合、
セキュリティポリシー でのブロックは非常に有効な手段になると思います。AppLockerとかAppLocker bypassだとかその辺の話です。興味がある方は調べてみてください。
Officeプログラムからの子プロセス生成を止める ようやく言いたいところにたどり着きました。Officeから子プロセスを生成する処理というのは、よほどマクロで変態的なことをしない限りないはずです。
以下はWord/
Excel に関して、ドキュメントおよびワークブックを複数開いた際に生成されるプロセスおよびそのプロセスツリーを確認した画面です。通常時、子プロセスを生成することはなさそうに思えます(あったら完全に調査不足ですごめんなさい指摘してください)。
OfficeProcesses 
Windows  10からは
Windows  Defenderへの追加機能として、Exploit Guardというものが実装されています。どんな機能があるのか、という点は以下の記事を参照するのが一番良いと思うので適宜見ていただくとして、ここではそのうち一つの機能である「子プロセスを許可しない」設定に注目します。
いろいろggったり資料を見たりするとMS ATPとの組み合わせの記事も多く、「ATPお高いんでしょう?」みたいな印象を持たれがちがもしれませんが、実は(知ってる人は多いかもしれないですけど)Exploit protection自体はATPを導入しなくても普通の市販PCで設定することが可能です。実際に設定して、どう動くのか確認してみます。
EndpointProtection1 
プログラム設定 > プログラム名を追加
EndpointProtection2 
タスクマネージャ(とかtasklist)からWordや
Excel 等Officeソフトの正式プログラム名を確認しておきます(なぜ統一感がないのか)。
それぞれに対し、以下のような感じで「子プロセスの生成を許可しない」設定にし、適用します。設定後、Word、
Excel は再起動します(not コンピュータ)。
winword-Disallowchildprocesses 
それでは以下のようなサンプルマクロを書いて、実行してみます。
※ここでは動作確認のためWordにブロック設定、
Excel にはブロックしない設定にしています。
Private  Sub  Test() 
   
    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 
execviaexcel 
Wordで実行
ErrorInRun 
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とかありますけど、どうやって打ち込むところまで辿り着くんでしょうね 
追記1:Endpoint protection bypass 
全くその通りで、特定のプログラムからのプロセス生成が止められるなら、それ以外のプログラムから実行すりゃええやんって話です。これでEndpoint protection bypassは可能です(ババーン)
ただし今回の設定においては以下が有効であるため、残念ながらこの.shellexecute入りのマクロ付きOfficeファイルは、
クラウド 保護機能によって消される、もしくはAMSIによってマクロの実行が止められる結果になります。
Windows  Defender(クラウド 保護有効)によるプロセス生成系マクロを含むOfficeファイルの削除 
AMSIによってマクロの実行が止められる場合、AMSI bypassテクニックを使うことで検知回避が部分的に可能ですが、bypassテクニックのほとんどはamsiScanBufferに対してアクションを起こすもので、
クラウド 保護もまるごと回避できるものは寡聞にして知りません。
ここらへんいじくってbypassできれば楽なんだけど誰かブログに書いてくれたりしないかな。日本じゃ無理なのか? 
そんなわけで今コメントいただいている方法では、まだ上記の設定でプロセス生成までの流れの中で止めることが可能です。
10/8 AM, 2020: 誤字脱字修正, 「今回不採用だったけど手としてはアリだと思う項目」を追加 
10/8 PM, 2020: 追記1 
 
以上