「貴組織にマルウエアに感染したホストがあるようです」とメールを受け取ったら？：セキュリティ事故対応の鉄則

日本を狙っていることが明確な「Emdivi」

　Emdiviによる標的型攻撃は、過去に発生した標的型攻撃と手法はほぼ同様だ。関係者を装ったり、業務に関係あるように見せた添付ファイル付きのメールを送信したりしてマルウエアに感染させる。そのホストを足掛かりにして、ファイルサーバーやドメインコントローラーなどネットワーク内部で横の感染を広げ、重要な情報を見つけ出すと外部に送信するという流れだ。

Emdiviの挙動（JPCERT/CC 久保啓司氏の発表資料より）

　カスペルスキーの前田典彦氏は、Emdiviの特徴として、一連の攻撃がほぼ日本を標的にしていることを挙げた。同社はEmdiviを用いた一連の攻撃を「Blue Termite」と名付けている。

カスペルスキーの調査によると、EmdiviのC2サーバーの設置場所のうち93％はJPドメインだった

　「過去にも『Icefog』『DarkHotel』といった標的型攻撃があったが、これらは他国も標的にしていて日本もその一つ、という形だったのに対し、BlueTermiteはほぼ日本を標的にしている」（前田氏）。カスペルスキーの観測によると、Emdiviに感染したホストにさまざまな命令を下すC＆Cサーバー（C2サーバー）の設置場所を確認したところ、93％がJPドメインで占められていた。またC＆Cサーバーに対する通信元も73％がJPドメインからだった。この中には観測用・テスト用の通信も含まれているため、実質的に日本の端末が占める割合はさらに高くなるはずだという。「これだけきれいに日本を狙っていることが明らかな攻撃はあまりないのではないか」（同氏）。

　被害に遭った組織の業種・業態を見ると、話題になった政府関連組織以外に、防衛産業や製造業、航空、エネルギー、金融、マスコミ、情報通信など、業種を問わず幅広く感染している。特に「情報通信での感染ケースを見ると、日本で事業をしている、とあるクラウドサービス事業者が被害に遭っている。しかも、正規のWebサーバーが侵害されて、攻撃に使われている」（前田氏）という。

　前田氏はこのようにEmdiviの特徴を説明した上で、「今やどのような組織・企業でも攻撃を受けないわけがない。攻撃を受け、被害を受けることは恥ではないと捉えた上で、次にいかに防げるかを考えるべきだ。そのためには、被害に遭った事実や情報を、必要なところと共有したり、交換したりしていくことが重要だ」と述べている。

Whois情報、正確ですか？

　JPCERTコーディネーションセンター（JPCERT/CC）では、マルウエア感染やWeb改ざん、フィッシングサイトといったさまざまなセキュリティインシデントの対応支援を行っている。寄せられた報告や分析結果などに基づいて当事者に連絡し、必要に応じて再発防止を支援するという取り組みだ。

　JPCERT/CCの久保啓司氏によると、2015年4月から6月にかけて調整を行ったセキュリティインシデントは2479件に上る。うち61組織は標的型攻撃に関するもので、さらにそのうち34組織はEmdiviに関するものだった（6月30日時点で、それぞれ66組織、44組織に増加しているという）。

　「連絡したときには既にことが終わっていることも多い。おそらく、まだまだ他にも（感染している組織が）あると思う」（久保氏）。

　JPCERT/CCでは、Emdiviを含む標的型攻撃に利用されるメールの内容を共有するとともに、マルウエアに感染した端末の通信先を分析し、感染元と通信先、双方に連絡して被害の最小化に取り組んでいる。

　「Emdiviでは、組織ごとに別のマルウエアが用いられ、しかも通信先（C＆Cサーバー）は複数ある。これらを解析し、少しずつ通信先を把握して被害組織に連絡しては、次の被害者を見つけるために調査協力を依頼しているが、マルウエアとC＆Cサーバーの関係を図にしても一枚では収まらない規模だ」（久保氏）。

　久保氏はこのように述べた上で、JPCERT/CCから連絡を受けた際に組織や企業に取ってもらいたい行動として、次の項目を挙げた。

連絡先の確保

　JPCERT/CCでは、Whoisデータベースの情報に基づいて電子メールで連絡を取っている。従って、Whoisに登録されている情報が最新のものになっているか、確認しておいてほしいという。ただ、ホスティングサービス、クラウドサービスを利用している場合は課題が残る。「事業者に連絡できても、その先の顧客にまでコンタクトすることは難しい」（久保氏）。

事実の確認と被害範囲の特定

　JPCERT/CCから提供された情報を参照しながらログを確認し、どの端末がC＆Cサーバーと通信しているかを特定する。必ずしもJPCERT/CCが把握している情報が全てではないため、感染端末を特定した上で、他のPCやサーバーも被害を受けていないかどうか、類似したパターンの通信ログを頼りに特定作業を進める。「今回の標的型攻撃に特有の動きとして、内部の横展開のために社内のActive Directoryサーバーやファイルサーバーへの侵入を試みることが挙げられる。このため、タスクスケジューラーにatコマンドなどのタスクが登録されることも多いので、そこもチェックしてほしい」（久保氏）。

一次対応

　被害拡大防止を第一に考えればインターネットへの接続を遮断すべきだが、「事業継続も大事。普段から通信状況を確認した上で、何を遮断するかを考えておくことが重要だ。インターネット接続全てを遮断しなくても、C＆Cサーバーとの通信さえ遮断できればいいのだが、それには、何がC＆Cサーバーとの通信かが分からなくてはいけない」（久保氏）。合わせて関連組織への連絡やエスカレーションを行い、必要に応じてセキュリティ事業者に協力をあおぐことになる。

復旧に向けた本格対応

　現実的には、監視を強化しながら順次復旧を進めていくことになるだろうが、場合によっては、イチからのシステム再構築も含めて検討すべきという。

　久保氏によると、JPCERT/CCからの連絡は「非常にクールな文面で、客観的な事実のみを記しているだけ」なので、もし不明な点があれば、遠慮なく問い合わせてほしいとしている。「今回のEmdiviのように深刻な被害が想定される場合では、一生懸命コンタクトを試みているし、先方にも対応してもらっている」（久保氏）。またJPCERT/CCが公開している「インシデントハンドリングマニュアル」も参考になるだろう。

「水際で防ぐ」だけでなく、事後対応の検討も

　ラックの西本逸郎氏も、標的型攻撃を水際で防ぐことは困難であると述べ、インシデント対応時の考慮事項として以下の5項目を挙げた。

遮断方法

　誰がどういった判断で遮断すべきかを決定し、連絡するかを考慮しておく必要がある。全ての通信を止めてしまうとまではいかなくとも、外に出て行くものだけを止めるといった、いくつかのモードを想定しておく。

対応時の連絡方法

　標的型攻撃を受けた組織では、おそらくメールの内容も攻撃者によって盗み見られているものと考える方がいい。それを前提にして連絡方法を検討する。

ITリテラシーの前提

　セキュリティ専門家にとっては当たり前の言葉が通じないことも多い。実行ファイルとはどんなものか、データファイルとの違いは何かを知らない相手に、「不審なファイルを開かないように」と呼び掛けるのが適切かどうか、考慮する必要がある。

調査方法

　慌てて対応しようとすると、ログなど重要な証拠が消されてしまうこともある。「何かあると、よく分からないからとにかくウイルススキャンをしたくなるが、実はそれは証拠を消し去ってしまう行為。スキャンしたいだろうけれど、してはいけない」（西本氏）。

POC（インシデント連絡窓口）

　外部からの問い合わせ窓口を明確にするとともに、その問い合わせを内部のしかるべき部署につなげる体制を整えておく。JPCERT/CCによる情報共有はもちろん、日本シーサート協議会、あるいは警察庁などの情報共有フレームワークが存在している。

インシデントレスポンスと情報共有に立ちふさがる課題

　ただ「幅広く被害を受ける攻撃に関する情報共有は比較的簡単なのに対して、標的型攻撃では情報共有が難しくなっているのも事実だ。攻撃メール一つとっても、内容に機密性の高い情報が含まれていて公表しづらいこともある。深くなればなるほど連携が困難だ」と、日本マイクロソフトの高橋正和氏は指摘した。

　加えて「今の時点では、緊急対処のオペレーションは「感染したか」「していないか」と、0か1かしかない状態だ。レベル分けを行い、それぞれのオペレーションを定義して上げ下げしていくことが大事だと思う」（高橋氏）と言う。

　また前田氏は「全てを公表するというのも違うだろう。公表と共有は異なる」と述べ、見えている被害の適切な共有を通じて「見えていない被害」を明らかにしていくことが重要だとした。