Emotet（エモテット）対策は万全？最新の攻撃に対する自社セキュリティ対策の検証のススメ

2021年11月から再活動が確認されたEmotet（エモテット）ですが、多くの日本企業も標的となり、被害も拡大している状況です。特に2022年2月に入ってからはEmotet感染の被害が急速に拡大していることが観測*1され、様々なセキュリティ機関やベンダより注意喚起が行われています。
*1: https://www.jpcert.or.jp/at/2022/at220006.html

そのことを反映するかのように数多くの企業からEmotet感染に伴う不審メール送信のお詫びがプレスリリースとして出されており、その数は2月20日時点でも数十社以上分を確認することができます。また被害者属性を見てみると、大企業・中小企業などの企業規模や業種を問わず様々な企業が被害にあっている実態を確認することができます。

ここで1つの疑問が浮かびます。

被害にあった全ての企業はEmotetの感染を防ぐためのセキュリティ対策は実施していなかったのでしょうか？企業によってその充実度合いは異なるとは思いますが、何らかの対策は実施済みだったはずです。にも関わらず感染を引き起こしてしまったということは、以下の様な状況が推測できます。

　1. セキュリティ製品の導入・設定不備などで上手く機能していなかった。
　2. 導入していたセキュリティ製品はきちんと設定できていたが、製品がEmotetの変化に対応できず、検知漏れを起こしてしまった。

インシデント対応のなかで感染原因を紐解いていくと1の様なケースは珍しくありません。また、Emotetはセキュリティ製品への対策がかなり周到に行われており、検知逃れのテクニックが多数用いられていたり、その実装の変容も非常に早いサイクルで行われていきます。1にせよ2のケースにせよ、IT管理者としては自社でその様な事態が発生する事は避けたいところですが、Emotet含めた最新の攻撃手法に自社で導入している製品が対応できるか、実際に確認するのも技術的にも安全性の上でも困難なケースが多く、課題に感じている方は少なくないのではないでしょうか。また、新手の脅威情報をみた役員などからの"うちは大丈夫か"への対応も、悩ましいものと思います。

この様な課題への1つの解として、様々な最新の攻撃手法を比較的手軽かつ安全に検証を行うための製品としてBreach and Attack Simulation（以下BAS）と呼ばれるジャンルの製品があります。
今回はMandiant社のBAS製品であるMandiant Security Validation(MSV)というツールを使用して、各種セキュリティ製品におけるEmotetの検知状況を検証してみましたので、その様子をご紹介いたします。

検証方法

攻撃内容

MSVでは実際にEmotetが利用する攻撃手法を模した検証が複数シナリオで実行可能です。
今回は以下のフェーズにおける疑似攻撃を実施して検知状況を確認しました。
　1．不正なOffice添付ファイル(パスワード付きZIP)/URLを含むメールの配送
　2．悪性Officeファイルのマクロが有効化された際等のEmotet本体のダウンロード
　3．ダウンロードされたEmotetによるC&Cサーバ通信時のDNS名前解決

本疑似攻撃では、過去実際の攻撃で使用された検体などが使用されております。そのため今回は既に発見されている検体に関するシグネチャ検知が可能であるかに加え、セキュリティ製品側でシグネチャが配信されていない新種の検体への対応も想定し、Sandboxなどによる動的解析の検知が可能か否かにも着目しながら、Eメールセキュリティ、Next Generation Firewall及びSandboxの3製品での検知状況を確認いたしました。

検証構成

今回使用したMSVの検証では、Actorと呼ばれる攻撃を実行する端末を複数用意し、Actor間で攻撃パケットを通信させます。Actor間で行われる疑似攻撃の経路上にセキュリティ製品を設置することでセキュリティ製品による検知可否をチェックします。


実際の検証構成は以下となります。

【Eメール】
Actor1にて悪性メールを生成し、メールサーバを経てActor2へ送信します。今回Email Server(Dest)で受信するメールはCloud Email Security経由で通信されるような構成としました。


【ネットワーク】
社内に設置したActor1をClient端末と見立て、AWS上に構成したActor2へ通信を行うことで、Internetへのアクセスを再現しました。DNS名前解決時やInternetへのアクセス時のトラフィックをSandboxへミラーし、Internet手前にはNGFirewallを設置しています。

検証結果

MSVでは疑似攻撃を実施した結果から、各セキュリティ製品が検知やブロックを実施したかどうかの判定も自動的に行うことができます。今回の各項目の検証結果は以下となります。

1．実際の攻撃で使用された添付ファイル(パスワード付きZIP)/URLを含むメールの配送

こちらのシナリオではEメールセキュリティ製品による検知状況を確認しました。疑似攻撃実施後、MSV側のコンソールを確認すると以下図のような結果となっておりました。真ん中のグラフの数字が攻撃試行件数、Preventedがブロック成功件数、Detectedが検知成功件数となります。今回のケースでは8件中全て検知・ブロックできたことが確認できました。

Eメールセキュリティ製品側でも結果を確認してみましょう。Verdictsの「V」が赤くなっているものはシグネチャベースのAntivirus機能で検知できたもの、「AT」が赤くなっているものは動的解析により検知できたものです。
添付ファイルを含むメールは全てシグネチャベースで検知できておりました。同時に動的解析でも検知ができることが確認できました。添付ファイルは含まず悪性URLが記載されたメールは動的解析で検知できておりました。


2．悪性Officeファイルのマクロが有効化された際等のEmotet本体のダウンロード

こちらのシナリオではNG FirewallとSandboxによる検知状況を確認しました。12種類の検体ダウンロードを実施したところ、そのうちの10をNG Firewallによるシグネチャベースの検知でブロック、残り2つをSandboxによる動的解析にて検知できました。

以下はSandbox側の検知結果です。1行目と3行目の2つがダウンロード検体の動的解析結果です。2行目は1行目の検体ダウンロード前のリクエスト時に不正URLとして検知している状況です。今回Sandboxにてブロックを有効化していなかったため、ダウンロードまで至ってしまっていた状況が確認できました。


3．Emotetに関連する通信先のDNS名前解決

こちらのシナリオではSandboxによる検知状況を確認しました。9つの通信先の名前解決を実行したところ、全てSandboxで検知できました。今回Sandboxでは通信をブロックするモードでは使用しておりませんので、ブロックはされませんでした。

まとめ

今回の検証より以下の状況が確認できました。
・既知の攻撃については殆どシグネチャベースの検知が可能となっている
・シグネチャベースの検知が難しいものについても動的解析により検知ができている
※：なお、上記結果はあくまで今回の検証の結果であり、全てのEmotet攻撃に対して上記の結果となるわけではありません。

Eメールセキュリティ、NG Firewallにおいては検知機能だけでなくブロック機能も有効にしていたため、クライアント端末への配送を食い止める事ができました。これをすり抜けた場合も、Sandboxの動的解析により検知できました。しかしこれが実環境であった場合、Sandboxでの動的解析中はクライアントへの通信は継続されるため、クライアントへマルウェアが配送された状態となります。Sandboxでアラートが上がってからの対処が遅れるとマルウェア感染のリスクが高まるため、セキュリティ製品におけるアラート対応の重要性を改めて実感しました。また今回Sandboxでブロック機能を有効にしていればマルウェアダウンロードに至る前にブロック可能であった状況もみられ、セキュリティ製品のブロック機能の重要性も実感しました。

最新の攻撃手法に対して自社で導入するセキュリティ製品がどのように検知、対応できるのかについて、机上で評価するだけではなく実際に疑似攻撃を行い検証することで対策の充足度や抜けを可視化することができます。同BAS製品では他にも様々な手法を用いた疑似攻撃が可能となっており、Log4jの脆弱性検証も実施しておりますので、ご興味のある方はこちらも是非ご参照ください。

【Mandiant Security Validation(MSV)　お問い合わせ】