「あっ！ やせいのEmotetがあらわれた！」　IIJ流インシデント検知ルールの作り方

趣味はTwitterで脅威情報を収集すること

古川智也氏（以下、古川）：IIJのSOCでアナリストを務めています古川です。僕からはIIJ C-SOCサービスで実際に使っている分析技術、いわゆる検知ルールがどのように作成されているかを発表します。

では改めまして自己紹介です。IIJには新卒で入社して、今年で社会人4年目となります。業務内容はインシデントを検知するための検知ルール、我々は「分析ルール」と呼んでいますが、その作成とかチューニングのルールの管理をメインにやっています。

その分析ルールを作成する上で、やはりその基となる情報が必要となってくるので、脅威情報の収集とか、あとはマルウェア解析なんかも付随してやっています。今年に入ってからアナリスト業務とは別にサーバの管理や運用などのインフラ関連も触り始めたという感じです。

趣味はTwitterで脅威情報を収集することです。わりと休日はずっとTwitterを眺めている感じです。その脅威情報の中におもしろそうな検体があったら、土日かけて解析するということをよくやっています。

本日はIIJ C-SOCサービスで利用している分析ルールがどのように作成されているかについて発表します。分析ルールにもいろいろありますが、今回は時間の都合上マルウェアの分析ルールに限った話をします。次に分析ルールを実際に作成する上で基となる情報をどうやって収集しているかについて、マルウェア解析と外部の情報収集という2つの側面から説明したいと思います。

分析ルールの目的は脅威の可視化

ではSOCの分析ルールについて説明します。まずそもそもなんですけど、分析ルールの目的は脅威の可視化です。イメージとしてはスライドの通り、某ゲームみたいな戦闘画面になるという感じですね。実際に分析ルールで脅威を見つけて、それに対してアナリストが調査したりとか、インシデントハンドリングをやっていくということになってきます。

某ゲームと違うのが、実際に見つけてもそれが必ずしも脅威であるかというのはここでは断定できないということですね。なので、本当にこれが脅威であるのかというのを含めてアナリスト側で調査をするというものになっています。

では分析ルールがどういったものを分析しているかといいますと、基本的にはIIJサービスのセキュリティログがメインになります。具体的にはファイアウォールであったり、IPSやWAFなんかのセキュリティ機器になっています。

対応可能であれば、お客さまが運用されている機器もSOCで分析しています。具体的に言うとWindowsのイベントログなんかは対応可能なので、お客さんから要望があれば対応しております。

次に基本的にこの分析ルールはログのフィールド内の値を分析ルールに定義された値と照合することで検知するようになっています。例えばプロキシログ内に入っている宛先ドメインが、マルウェアが実際に利用しているC＆Cサーバのドメインを合致した場合に脅威と検知したりとか、管理者端末でそのログイン試行したユーザというのが管理者アカウントではないとか、そういったイベントを脅威として検知するようにしています。

最後に、基本的にSOCの分析ルールはリアルタイムの分析を前提としています。分析の方法にもいろいろあって、例えばその1ヶ月間のログを丸々分析して外れ値を見つけてくるような統計的な分析方法もありますが、今回はリアルタイムに限った分析についてお話しします。

マルウェアが残す痕跡を事前に収集しておく

分析ルールにもいろいろあると最初に話しましたが、今回はこの中のマルウェアの分析ルールについてのお話になります。マルウェアの分析ルールで検知するものは何かというと、マルウェアが残した痕跡、俗に言うIoCと呼ばれているものです。

マルウェアが残した痕跡はそもそも何かという話になってくるので、分析ルールを作成する際には、マルウェアがどのような痕跡を残すかというのを事前にちゃんと収集しておかないと作れないことになります。そういった情報をマルウェア解析などで入手しています。

痕跡例としては先ほども出てきましたが、C＆Cサーバのドメインであったり、あとはマルウェアのハッシュ値が痕跡になってきます。次にこれはヒューリスティックなものですが、1つのマルウェアに対して1つだけのルールというよりは、複数の分析を作成しておくと検知漏れをできるだけ抑えることができます。

と言うのも、マルウェア自身も残す痕跡というものを毎度変えてくるんですね。攻撃者が一番恐れていることは自身が準備したマルウェアが検知されて攻撃が失敗することなので、攻撃者自身もそのマルウェアが検知されていないかをちゃんと情報収集して確認しています。1つのマルウェアに1つのルールだけですと、やはりその痕跡を変えられるともう検知できなくなってしまうので、複数の分析ルールがあったほうがベターかなと思います。

マルウェアもただ通信するだけとかではなくてファイルにアクセスしたり、ファイルに書き込んだりとかいろいろな動作をするので、複数の痕跡を絶対に残してくれます。ですから、情報の種別に違った分析ルールというものを作るといいかなと思います。

マルウェアがアップデートされてそういった痕跡が全部消えるのではないかという話もあるかと思いますが、僕が見ている限り一部は修正されていても他の痕跡はそのまま残るというマルウェアが多いので、複数分析ルールを作る意義はあると思います。

次にこちらは僕がマルウェアの分析ルールを作る際に、どういったところを注意しているかというものです。分析ルール自体は検知して終わりですが、そのあとにアナリストが調査の起点として分析ルールを利用するので、アナリストが分析ルールの意義をちゃんとわかっていないと、その分析のそもそもの意味とか効率に大きく影響してきます。

こういった情報をちゃんと明確にしたルールであれば、アナリストも非常に調査がしやすいと思います。ではここまでで分析ルールの概要についてお話したので、次に分析ルールの基となる情報をどうやって見つけているのか、Emotetの感染フローを例に説明します。

そもそもEmotet とはどんなものか

そもそもEmotetはどんなものかというと、情報窃取を目的としたマルウェアです。2014年頃ぐらいに出てきたマルウェアで、昔は単体で動いていたことが多かったのですが、近年は他のマルウェア、TrickBotだったりQakBotなど、そういった似たような情報窃取マルウェアのダウンローダとして利用されることが多いです。

この検体自体は去年の9月から2月頃にかけて活発に行動していて、それ以降活動を停止していましたが、残念なことに今年の7月頃から再び活動を再開しちゃいましたという検体です。去年けっこう感染被害も大きかったので、JPCERT/CCのほうからも注意喚起が出たマルウェアです。

Emotet自体は、わりと頻繁にアップデートされる検体で、今回説明するのは2020年7月に観測した検体です。もしかしたら見ている時点では検体の特徴が変わっているかもしれないので、そこはご容赦ください。

去年も今年も観測されているEmotetの特徴は、感染活動にメールを利用するというものです。メールにEmotetに感染させるためのファイル、WordとかExcelとかのOfficeファイルを実際に添付して送っていきます。そのOfficeファイルの中にマクロが仕込まれていて、そのマクロを実行すると最終的にEmotetに感染するというものになっています。

ここまでだとメールを利用して感染拡大する他のマルウェアとそんなに変わりはありません。Emotetは、実際に感染した端末からメール情報を取ってきて、そのメールボックスの中に入っているメールに対して、自身に感染させるためのメールを返信メールとして送って感染拡大するという特徴があります。ここが非常に厄介だと思います。

アナリスト側の視点から見るとEmotetの厄介な点はもう1つあって、改ざんされたWebサーバにそのEmotetの本体を置いていることが非常に多いです。実際にその改ざんしたWebサーバにWebShellが置かれていて、そこを使ってアップロードされると報告されています。

アナリストとして何が厄介なのかというと、改ざんされたWebサーバなので仮にこのドメインもしくはIPアドレスで検知してもたまたま顧客がアクセスしちゃったというパターン、つまり誤検知であるパターンが多いので非常に厄介です。

Emotetの感染フロー

Emotetの感染フローについて見ていきましょう。まずはボットネットからEmotetに感染させるための添付ファイルが付いたメールがユーザに対して送信されます。これは7月に感染されたものですね。実際に開くと何やら怪しい英文が書いていて、ちょっと見づらいんですけど上の「コンテンツの有効化」という部分を押しちゃうと、残念ながらマルウェアが起動しちゃうという動きになっています。

先ほどのWordのファイルの中を見てみると難読化されたマクロというものが含まれていまして、これは7月から確認されていることなんですけど、なぜかユーザーフォームを持っていて、その中に何か怪しい文字列を含んだような検体になっていました。

こいつが何をやっているかというと、このマクロはPowerShellを実行する目的に利用されています。先ほど出てきたここの怪しい文字列は、実は暗号化されたPowerShellのコマンドラインで、これを復号してVBAマクロの目的になっています。

スライドに書いているのが実際に起動されるコマンドの一部になっています。

これを実際にログで見てみるとどうなるか。こちらは監視ツールであるSysmonが出力したログになります。プロセス作成ログですね。ここのコマンドラインを見てみるとPowerShellが実行されているのがわかるんですけど、さらに何か-eオプションというものが付いています。

このオプションがBASE64エンコードされたPowerShellのスクリプトを実行するというオプションでして、普通のユーザだったらこれを実行するということはまずないと思うので、これは検知すべきイベントなんじゃないかなと考えています。もう少しSysmonのログを追って見ると、このPowerShellを実行した親プロセスというものがWMIになっているんですね。

WMI自身もPowerShellをその子プロセスとして生成するということは、普通のユーザだとまずありえないのでここの親子関係というのを検知するのもいいと思います。

次にそのPowerShellが実行されてEmotetがダウンロードされたタイミングですね。先ほどのPowerShellをちゃんと復号して綺麗に整形するとこんな感じのPowerShellスクリプトになっています。特にEmotetのダウンロード先URLを暗号化することなく埋め込んでいるので、もし解析がうまく行けばここのダウンロード先URLを検知するための要素として使うことができます。

次にEmotetが実際に実行されるとC＆Cサーバと通信を始めます。こちらはWiresharkで実際に通信の中身を見たものです。C＆Cサーバと通信するのでここの通信先を検知する要素の1つとしても使うことができます。

Emotetには、POSTメソッドで通信先URLと同じURLをRefererに含むという特徴があります。こちらは去年も今年も同じようにやっている特徴ですね。なので、こちらの特徴も検知の要素として使うことができます。

なぜかセキュリティの脅威情報はTwitterが最速

ここまではマルウェア解析の話だったので、次に外部の脅威情報の収集方法についてお話しします。そもそも外部から脅威情報を収集する必要があるのかという話ですが、先ほど出てきたダウンロード通信先とC＆C通信先については、Emotetは頻繁に変更を繰り返してきます。ですから定期的に最新のIoCというものを検知させるようにしないと検知漏れが発生しちゃうということになります。

参考程度ですが、実はマルウェアの情報を変更しづらい順に並べた痛みのピラミッドというものがあります。それに反比例するかたちでルールのメンテナンス負荷が上がってきます。一番下のハッシュ値は変更しやすいので、もしこれを検知する分析ルールを作ると定期的に情報収集しないと使えないルールになってしまいます。

IoC情報はいろいろな収集先がありますが、Emotetに限った話だと大きく3つに分けられるんじゃないかなと思います。1つ目は脅威情報サイトですね。EmotetでいうとCryptolaemus PastdumpとかURLhausなんかがあったりします。次にTwitterですね。なぜかセキュリティの脅威情報はこういった脅威情報サイトに上がるよりもTwitterのほうが最速で流れてくることが多いです。

日本に限ったメールを利用した脅威情報で言うと、ばらまきメール回収の会という方がリアルタイムで脅威情報というものを共有してくれているので、そちらの情報を参照するのが一番いいんじゃないかなと思います。

最後にオンラインサンドボックスですね。Emotetに関して言うとany.runと言われるオンラインサンドボックスにめちゃくちゃ検体が上がっていて、そのany.run自体がIoCをちゃんと収集するという機能を持っているので、そちらを見るのもいいのかなと思います。

ここまででいわゆる公開されている、ちゃんとIoCとわかっているものの収集方法についてお話しました。では、公開されていないIoCはどう収集されているのかという話になってきます。やはり未知のIoCに関しては検知できないので、ちゃんとその未知のものであっても我々は検知するようにしています。

大きく2つに分かれまして、次のセッションと次の次のセッションで出てくるんですけど、情報分析基盤というものとCHAGEというOSINTツールを使って未知のIoCというものを分析しています。情報分析基盤についてはビックデータの解析によって得たIoCというものを共有してもらったりとか、CHAGEについてはOSINTしてIoCの周辺情報というものを取ってきて、それを人でグルーピングして特徴を見出して新たなIoCを収集するというかたちにしています。

僕からの発表は以上です。ご清聴ありがとうございました。