2016年上半期 tokyo soc 情報分析レポート

IBM Security Services Ahead of the Threat. ®

2016年上半期 Tokyo SOC 情報分析レポート

2

2016 年上半期 Tokyo SOC 情報分析レポート

目次

エグゼクティブ・サマリー ...................................................................... 3

1 2016年上半期の脅威動向概況 ............................................................ 4

1.1 高危険度のセキュリティー・インシデントの推移 ................................................... 4

1.2 Tokyo SOCにおけるセキュリティー・インシデントの動向 ..................................... 5

[Column1] Watson for Cyber Security .................................................................... 8

2 クライアント PCを狙った攻撃 .......................................................... 10

2.1 ドライブ・バイ・ダウンロード攻撃 .................................................................. 10

2.2 メールを悪用する攻撃 ................................................................................... 15

2.2.1 今期確認されたメールを用いた攻撃活動の概況 ................................................. 15

[Column2] 2016年上半期におけるメールを利用した攻撃の変遷 .................................. 22

2.3 感染するマルウェアの動向 .............................................................................. 28

2.3.1 ランサムウェア ......................................................................................... 29

2.3.2 金融マルウェア ......................................................................................... 36

2.4 クライアント PCを狙った攻撃の対策 ................................................................ 41

2.5 クライアント PCを狙った攻撃動向のまとめ ....................................................... 42

[Column3] 戦略的な Computer Security Incident Response Team(CSIRT)構築のために 43

3 公開サーバーに対する攻撃の動向 ....................................................... 45

3.1 JBossに対する攻撃 ...................................................................................... 45

3.2 Joomlaに対する攻撃 .................................................................................... 47

3.3 Apache Commons Collectionsライブラリーに対する攻撃 .................................... 48

3.4 Apache Struts2に対する攻撃 ......................................................................... 49

3.5 今期話題になったその他の脆弱性と攻撃検知状況 ................................................. 51

3.6 攻撃送信元 IPアドレスの分析 ......................................................................... 53

3.7 公開サーバーに対する攻撃動向のまとめ ............................................................ 56

[Column4] WordPressサイトの改ざん事例紹介 (2016年上半期の Emergency Response Service(ERS)活動から) ........................................................................................ 57

[Column5] IBM社内にて Capture The Flag開催 ..................................................... 61

4 おわりに ...................................................................................... 63

エグゼクティブ・サマリー

3


エグゼクティブ・サマリー本レポートは、IBMが全世界 10拠点のセキュリティー・オペレーション・センター（SOC）にて観

測したセキュリティー・イベント情報に基づき、主として日本国内の企業環境で観測された脅威動向を、Tokyo SOCが独自の視点で分析・解説したものです。

IBM では、世界 10 拠点の SOC で 15 年以上蓄積されてきたセキュリティー・インテリジェンスを相関分析エンジン(X-Force Protection System)へ実装し、1日あたり 200億件以上の膨大なデータをリアルタイムで相関分析しています。

2016年上半期に Tokyo SOCで観測された攻撃を分析した結果、以下の実態が浮かび上がりました。

メールを利用した不正な添付ファイルによる攻撃が前期比 16.4倍に増加

今期はメールによる攻撃が活発に行われ、Tokyo SOCで検知した不正メールの件数は 2015年下半期と比較し 16.4 倍に急増しました。また、不正な添付ファイルは ZIP で圧縮された JavaScript

形式のファイルが大半を占め、感染するマルウェアも多くはランサムウェアまたは金融マルウェアとなっていました。一方で、ドライブ・バイ・ダウンロード攻撃の検知件数は前期の 6 分の 1 以下と大幅に減少しています。企業側の脆弱性対策が進んだことなど複数の要因が影響し、攻撃者側が脆弱性を悪用しないメールによる攻撃手法へ移行していると考えられます。

日本語を利用したメールによる攻撃では正規のメールや公開情報を流用

メールを利用した攻撃において日本語を利用しているケースでは、以前のような不自然な日本語で記載された文面だけではなく、正規のメールや公開情報を流用したと考えられる自然な日本語の文面が利用されており、文面のみでは不正なメールかどうかの判断をすることが困難な状況が浮かび上がりました。また、日本語の文面を利用した不正なメールによって感染するマルウェアのほとんどは金融マルウェアであることも判明しました。

公開サーバーに対する攻撃の送信元 IPアドレスの 18.4%が 30日以上継続的に活動

今期 Tokyo SOCで検知した公開サーバーに対する攻撃の送信元 IPアドレスの活動期間を分析したところ、1 日未満の活動期間のものが 66.8%と多くを占めるものの、30 日以上継続的に活動しているものも 18.4%確認されました。攻撃者は攻撃の検知を逃れるために送信元 IPアドレスを頻繁に変更していると一般的には考えられていますが、分析の結果より、攻撃者の多くは利用できる攻撃ホストが使える限り使い続けるという戦略をとっていると推測されます。そのため、一定期間以上観測される送信元 IPアドレスのブラックリスト方式による検知・防御は一定の効果があると考えられます。

また、本レポートでは、実際に発生したWebサイト改ざんの事例や、不正なメールに添付されるファイルを開いてしまった際の接続先ドメインに関する調査結果をご紹介いたします。

日々セキュリティー対策を行っている ITエンジニアの方々には、情報セキュリティーに関する知識向上の一助として、また、経営上の課題解決のためにポリシー策定や情報セキュリティー対策に携わっている方々には、その活動の一助として、本レポートをご活用いただければ幸いです。

2016 年上半期の脅威動向概況

4


1 2016 年上半期の脅威動向概況

2016年上半期は、2015年に引き続きクライアント PCをマルウェアに感染させ、ファイルの暗号化を行うランサムウェア(身代金要求型マルウェア)や、クレジットカード情報やオンライン・バンキングの口座情報などを窃取する金融マルウェアが話題になりました。

ここでは、全世界 10拠点の IBM SOCで発生したセキュリティー・アラートをもとに今期に発生した攻撃の概要について解説します。

1.1 高危険度のセキュリティ

ー・インシデントの推移IBM SOCでは、セキュリティー機器から収集した

1 日あたり 200 億件以上のセキュリティー・イベントを相関分析エンジンで分析した結果、アナリストが調査すべきと判断したものをセキュリティー・アラートと位置付けています。

セキュリティー・アラートをアナリストが調査した結果、お客様に影響がある可能性のあるものをセ

キュリティー・インシデントとして通知しています。今期、Tokyo SOCのアナリストが調査を行ったセキュリティー・アラートのうち、高危険度(攻撃によって具体的な影響が確認されているもの)のセキュリティー・インシデントとして、お客様へ通知を行った件数の推移を図 1に示します。

図 1 Tokyo SOCで高危険度と判断し通知した件数の推移 (Tokyo SOC調べ 2015年 7月 1日～2016年 6月 30日件数表記無し）

2015

年7月

2015

年8月

2015

年9月

2015

年10

月

2015

年11

月

2015

年12

月

2016

年1月

2016

年2月

2016

年3月

2016

年4月

2016

年5月

2016

年6月


5


Tokyo SOCにおける高危険度のセキュリティー・

インシデントは、2015年 9月より急増している点を2015 年下半期の本レポートでご紹介しましたが、2016年1月になってさらに増加の傾向が確認されました。2016年上半期のインシデントの主な内容は金融マルウェアへの感染を示す通信、およびランサムウェアへの感染を示す通信となっており、すべてク

ライアント PC のマルウェア感染に関連するものでした。詳細については、「2.3 感染するマルウェアの動向」にて解説します。なお、サーバーに対する攻撃については高危険度での通知は発生していません。

1.2 Tokyo SOCにおけるセキュ

リティー・インシデントの

動向

図 2は 2016年上半期の Tokyo SOCで発生したセキュリティー・インシデント全体のうち、サーバーに対する攻撃とクライアント PCに対する攻撃の割合を示したものです。

全体の 66.4%がサーバーに対する攻撃となっていますが、前述のとおり高危険度のものは発生していません。

図 2 セキュリティー・インシデントの発生箇所 (Tokyo SOC調べ 2016年 1月 1日～2016年 6月 30日)

33.6%

66.4%

クライアント

サーバー


6


サーバーに対する攻撃の内訳は、図 3のとおり、Web

アプリケーション全般に対する攻撃が 61.2%を占めています。次いで、ユーザーID・パスワードを特定

するための総当り攻撃(ブルートフォース攻撃)が19.8%、特定の製品の脆弱性を狙う攻撃が 14.7%となっています。

Webアプリケーション全般に対する攻撃は主にコマンドインジェクションおよび SQLインジェクションとなっており、これらのWebアプリケーション全般に対する攻撃がセキュリティー・インシデントとしてはもっとも多くの割合を占めています。

また、OpenSSLの脆弱性(Heartbleed)や Joomla

の脆弱性に対する攻撃等、特定の製品の脆弱性を狙う攻撃も確認されています。これら特定の製品の脆弱性を狙う攻撃の動向については「3. 公開サーバーに対する攻撃の動向」にて解説します。

クライアントPCに対する攻撃は2016年上半期のセキュリティー・インシデントの 33.6%となっていますが、前述のとおり高危険度のセキュリティー・インシデントはすべてクライアント PCに対する攻撃となっています。

図 3 サーバーに対する攻撃の内訳 (Tokyo SOC調べ 2016年 1月 1日～2016年 6月 30日)

61.2%19.8%

14.7%

4.3%

Webアプリケーション全般に対する攻撃

総当り攻撃

特定の製品の脆弱性を狙う攻撃

その他


7


クライアント PCを対象とした攻撃は、主にWeb

サイトやメール経由でクライアント PCをマルウェアに感染させるものです。

図 4のとおり、2016年上半期はメール経由での攻撃がクライアント PCに対する攻撃の 93.4%を占めており、今期発生したクライアント PCのセキュリティー・インシデントの多くはメールを経由して攻撃が行われたことを示しています。

一方で、Webサイトを経由した攻撃はわずか 1.7%

となっています。これは、Webサイト経由の攻撃(ドライブ・バイ・ダウンロード攻撃)が、2015年下半期と比較すると 6分の 1以下と大幅に減少していることが要因と考えられます。

これらクライアント PC を対象とした攻撃については「2. クライアント PCを狙った攻撃」で解説します。

93.4%

1.7%4.9%

メール経由での攻撃

Webサイト経由での攻撃

不明

図 4 クライアント PCに対する攻撃の経由元 (Tokyo SOC調べ 2016年 1月 1日～2016年 6月 30日)

8


[Column1] Watson for Cyber Security

セキュリティー専門家が処理しなければならないデータは膨大です。セキュリティー・イベントデータは 1日あたり 20万件を超え、既知のソフトウェア脆弱性は 75,000件以上あり、セキュリティー関係の研究論文は毎年 10,000 本以上発表されており、セキュリティーに関するブログは毎月 60,000 件以上投稿されています。セキュリティーのデータ量とデータが増す速さは、サイバー犯罪への取り組みにおいて最も大きな課題のうちの 1 つです。そのため、セキュリティー・オペレーション・センターでは慢性的な人材不足とスキル不足に悩まされています。特に新たに発生する脅威とそれらの防止方法などの重要な情報は、自然言語で記述されたデータに格納されており、従来のセキュリティーツールでは処理できません。

Tokyo SOCのセキュリティー・アナリストも毎日かなりの時間を費やして、複数の有名なセキュリティー技術者のブログや Twitterや主要セキュリティー・ベンダーが発信する情報を確認しています。同じような内容が書かれている多くの文書の中に様々な脅威のバリエーションが報告されているため、それらを総合的に判断し情報を取捨選択する必要があります。新たに発見された脆弱性については、技術者が発信する自然言語による情報が貴重な手がかりとなります。極めて深刻な影響を与えることが予想されるゼロデイ脆弱性が発見された時、このような情報があれば迅速に分析を行うことができます。

こうした状況に対応するため、IBM セキュリティーは 1 年にわたる研究の結果として、2016 年５月 10

日、クラウドベースの IBMコグニティブ・テクノロジーである「Watson for Cyber Security」を発表しました。Watsonは、セキュリティーの研究結果に含まれるニュアンスを学習し、ともすれば見逃されてしまう、隠れたサイバー攻撃やサイバー脅威のパターンと根拠を発見します。例えば、オンラインのセキュリティー速報に掲載される新種のマルウェアに関するデータや、セキュリティー・アナリストのブログで発表される修復計画に関するデータを見つけられるようになります。

Watsonは文字列として記録された情報をコンピューターが理解できる形式に変換し、その上で分析や予測を行います。その過程では単語の抽出や文の構造の抽出などに加え、特定の分野で暗黙のうちに利用されている単語や言い回しなどを理解し、文脈や意味を抽出する必要があります。例えば、何も学習させていないWatsonは「マルウェア」が何を指すのか理解できません。そのため、「マルウェアが動作する」がセキュリティー・インシデントと関連することも理解できません。こうした知識を与えて初めて Watson

はセキュリティーの分野の自然言語を処理できるようになります。Watsonにこうしたセキュリティーに関連した知識を学習させるため、IBM は 8 つの大学と提携してワトソンの訓練を行う計画です。これらの大学の学生は IBMセキュリティーの専門家と共に作業を行い、システム・セキュリティーのレポートやデータに注釈を付け、Watson の知識コーパスを構築する作業をします。このデータには 800 万件のスパム攻撃やフィッシング攻撃と、10 万件の報告された脆弱性に関する詳細が含まれており、1 カ月あたり最高15,000のセキュリティー・ドキュメントを処理する計画です。

9


図 5 Watsonの訓練を行う学生

Watsonを用いることにより、これまでより多くの情報をより短時間で処理することができるようになり、これまで確認していなかった情報源についても対象に含めることができるようになります。セキュリティー・アナリストは、こうした情報を基にしてより迅速で正確な意思決定を行い、より適切な対策を施すことができるようになります。また Watson を活用すれば、新人のアナリストの不足するスキルを補完することができます。このように Watson はセキュリティー関連の情報量の増加に対して取り組んでいます。しかし、情報システムの複雑さの増加と攻撃の高度化などの根本的な原因がある限り、今後ますます情報量は増加していきます。こうした課題に既存の技術で対応することはますます困難になりつつあり、セキュリティーに対して数理科学や人工知能の技術を活用しようという試みは活発になっています。

参考文献 1. IBM: "Cognitive Security" (portal web site)

http://www.ibm.com/security/cognitive/ 2. IBM: "Watson to Tackle Cybercrime" (press release)

http://www.ibm.com/press/us/en/pressrelease/49683.wss https://www.ibm.com/press/jp/ja/pressrelease/49726.wss (日本語)

3. IBM: "Cognitive security white paper" (white paper) http://cognitivesecuritywhitepaper.mybluemix.net/?cm_mc_uid=50687788457814664783602&cm_mc_sid_50200000=1469087449 http://www.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=SEW03134JPJA (日本語)

4. IBM: ”Step up to the Cognitive Era with Watson for Cyber Security” (Video) https://youtu.be/mnKq9l4Sjro published on 2016/05/10

5. IBM: “Teaching Watson the Language of Security” (Video) https://youtu.be/kao05ArIiok published on 2016/05/10

6. IBM: “Watson for Cyber Security in Action” (Video) https://youtu.be/MYZOIdK4o1M published on 2016/06/27

クライアント PC を狙った攻撃

10


2 クライアント PC を狙った攻撃

クライアント PCを狙った攻撃では、攻撃者は主にWebサイトやメールを悪用して侵入します。その後、クライアント PC 内の認証情報の窃取やファイルを暗号化して身代金の要求を行ったり、侵入したクライアント PCを踏み台にして組織内の奥深くにあるシステムへのアクセスを試みたりします。本章では、2016 年上半期に Tokyo SOC で確認したこれらの攻撃について、攻撃手法および感染するマルウェアの動向や対策について解説します。

2.1 ドライブ・バイ・ダウンロード

攻撃ドライブ・バイ・ダウンロード攻撃は、Webサイト

の閲覧を通じてクライアント PC へマルウェアを感染させる攻撃手法です。攻撃の仕組みについては 2015

年下半期の本レポート 1にて解説していますので、合わせてご確認下さい。

ドライブ・バイ・ダウンロード攻撃の検知傾向

図 6は、Tokyo SOCにおけるドライブ・バイ・ダウンロード攻撃の検知数の推移です。2016年上半期の検知数は 584 件と、2015 年下半期の 3,812 件と比較して 84.7%の減少となっています。特に、2015 年下半

期に多く見られていた特定の攻撃ツール (Angler

Exploit Kit)による検知が 2016 年 4 月以降大幅に減少しています。一方で、昨年 10 月ごろより観測され始めた、東アジアのサーバーに設置された特定の攻撃ツール(CK Vip Exploit Kit)に誘導させられる攻撃は引き続き観測されています。

1 IBM: 2015 年下半期 Tokyo SOC レポート「2.2 ドライブ・バイ・ダウンロード攻撃」P.11 http://www.ibm.com/services/jp/ja/it-services/soc-report/


11


図 6 ドライブ・バイ・ダウンロード攻撃の月別検知数推移(日本国内) (Tokyo SOC調べ 2012年 7月 1日～2016年 6月 30日)

0

200

400

600

800

1,000

1,200

1,400

1,600

2012

年7月

2012

年9月

2012

年11

月

2013

年1月

2013

年3月

2013

年5月

2013

年7月

2013

年9月

2013

年11

月

2014

年1月

2014

年3月

2014

年5月

2014

年7月

2014

年9月

2014

年11

月

2015

年1月

2015

年3月

2015

年5月

2015

年7月

2015

年9 月

2015

年11

月

2016

年1月

2016

年3月

2016

年5月

検知数


12


悪用される脆弱性と対策

図 7 は、2013 年上半期から 2016 年上半期までのTokyo SOCで検知されたドライブ・バイ・ダウンロード攻撃で悪用された脆弱性の割合の推移です。 2013

年上半期から 2014年下半期までは JREの脆弱性が占める割合が多くなっていましたが、2015年上半期からはAdobe Flash Playerの脆弱性が悪用されるケースが大半を占めています。 2016 年上半期については、引

き続きAdobe Flash Playerの脆弱性が悪用されていますが、この脆弱性を主に悪用する攻撃ツール(Angler

Exploit Kit)の検知数が減少したため、他の攻撃ツール(CK Vip Exploit Kit)で主に悪用される Oracle Java

Runtime Environment(JRE)の割合が相対的に増加しています。

今期のドライブ・バイ・ダウンロード攻撃の検知数の減少は、これまで非常に検知数の多かった特定の攻撃ツール(Angler Exploit Kit)による攻撃が大幅に減少したことによるところが大きいですが、その背景として、Adobe Flash Playerの脆弱性を悪用した攻撃の成功率が低くなってきたことが要因となっていると考えられます。

Adobe Flash Playerの脆弱性は引き続き多く発見・修正されていますが、成功率が低くなったと考えられる要因として、以下があげられます。

これまで多くのメディアやセキュリティー・ベンダーが、Adobe Flash Playerの脆弱性が悪用されている実態や注意喚起を行ってきたため

多くの利用組織がバージョンアップや無効化等の対策を行ってきたと考えられるため

Adobe 社が Flash Player のセキュリティー対策を実施し、以前より攻撃者に悪用されにくい製品になってきたため

ブラウザー側でプラグインをデフォルトで無効化するなどの対策が進んだため

図 7 ドライブ・バイ・ダウンロード攻撃で悪用された脆弱性の割合(日本国内) (Tokyo SOC調べ 2013年 1月 1日～2016年 6月 30日)

0 1,000 2,000 3,000 4,000

2013年上半期

2013年下半期

2014年上半期

2014年下半期

2015年上半期

2015年下半期

2016年上半期

Adobe Flash Playerの脆弱性 JREの脆弱性

Internet Explorerの脆弱性 Adobe Readerの脆弱性

その他


13


このような状況から攻撃者は Web サイトを経由した攻撃からメールを悪用した攻撃に移行していったのではないかと推測されます。

しかしながら、件数が減少したとはいえ、攻撃は引き続き確認されており、脆弱性の存在する古いバージョンを利用し続けた場合、攻撃の影響を受けてしまう可能性があります。2015年下半期の本レポートで紹介した対策(最新版へのアップデート、ブラウザ・プラグインの無効化)及び「2.4 クライアント PCを狙った攻

撃の対策」にて紹介している対策を実施することを推奨します。

攻撃が検知された組織の割合

ドライブ・バイ・ダウンロード攻撃は図 8のような複数のステップを経て、マルウェア感染およびその後の被害に至ります。Tokyo SOCでは黄色い矢印で示した各ポイントを監視することで、ドライブ・バイ・ダウンロード攻撃に対応しています。

図 8ドライブ・バイ・ダウンロード攻撃のステップ


14


図 9は、Tokyo SOCでクライアント PCによる通信を監視している組織のうち、ドライブ・バイ・ダウン

ロード攻撃が検知された組織の割合の 2014 年下半期から 2016年上半期までの推移です。

2016年上半期は、ドライブ・バイ・ダウンロード攻撃が検知された組織(図 8 の Step 2 以降が確認された組織)の割合は 48.7%であり、2015年下半期の 74.3%

から減少しています。

攻撃が検知された組織の割合の減少は、特定の攻撃ツール(Angler Exploit Kit)を使用した攻撃が減少したことが主な要因ですが、Webゲートウェイ型のマルウェア対策等、組織側での対策が進んだことも減少に影響を与えていると考えられます。

また、Step 3以降の攻撃は、攻撃サーバーへアクセスした時点でクライアント PC が脆弱性を持つアプリケーションを利用していた場合にのみ行われます。Step 3以降の攻撃が検知された組織の割合は 13.4%であり、2015 年下半期の 20.2%からこちらも減少しています。 Step 3 以降の攻撃が検知された組織の割合の減少は、Adobe Flash Playerなどのクライアント PC

の脆弱性への対応が適切に行われている組織の割合が以前と比較して増加したとも考えられます。

その結果、クライアント PC の脆弱性を悪用しようとする攻撃の成功率が下がり、攻撃者にとっては非効率的な攻撃手法となったとも言えます。そのため攻撃者は Web サイトを経由した攻撃からメールを悪用した攻撃に移行したと推測されます。

しかしながら、引き続きクライアント PC の脆弱性への対策が適切に行われていない組織が存在していることも事実です。今期は検知数が減少しましたが、ドライブ・バイ・ダウンロード攻撃はこれまでも増加と減少を繰り返してきており、今後新たなクライアントPC の脆弱性が発見され再び攻撃が活発になることも考えられます。引き続き管理するクライアント PC の適切な脆弱性対策を推奨します。

図 9 ドライブ・バイ・ダウンロード攻撃発生状況(日本国内) (Tokyo SOC調べ 2014年 7月 1日～2016年 6月 30日)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

2014年下半期

2015年上半期

2015年下半期

2016年上半期

脆弱性を悪用する攻撃が検知された組織

（Step3以降の検知あり）

攻撃サーバーへの誘導を検知した組織

（Step2の検知にとどまる）

攻撃サーバーへの誘導が検知されなかった組織


15


2.2 メールを悪用する攻撃

メールを悪用する攻撃は、ドライブ・バイ・ダウンロード攻撃と並んでクライアント PC に対する主要な攻撃手段です。攻撃者は、不正な添付ファイルやリンクを含むメールを送信し、ファイルを開かせたり、リンクをクリックさせたりすることでマルウェアに感染させようとします。

Tokyo SOCでは、送受信されるメールを IDS/IPSやサンドボックス型のセキュリティー製品にて監視しています。今期、Tokyo SOCで検知したメールを悪用する攻撃では、以下のような特徴が確認されました。

● 悪意あるファイルを添付したメールの検知数が前期比 16.4倍に増加

● ZIP圧縮したスクリプト・ファイルを添付する攻撃が主流

● 正規のメールや公開情報を流用する攻撃が増加

なお、本章で取り扱う不正メールは全て、不特定多数に対して送信される「バラマキ型攻撃」に分類される攻撃メールであり、特定の個人や組織のみを狙った「標的型攻撃」に分類される攻撃メールではありません。

2.2.1 今期確認されたメールを用いた

攻撃活動の概況

悪意あるファイルを添付したメールの検知数

が前期比 16.4 倍に増加

今期はメールによる攻撃が活発に行われ、Tokyo

SOCで検知した不正メールの件数は 2015年下半期と比較し 16.4倍に急増しました。その多くは悪意あるファイルを添付したものであり、特に 2016 年 3 月以降に検知数の顕著な増加を確認しています。

図 10に、Tokyo SOCが監視するサンドボックス製品で検知した悪意あるファイルが添付された不正メールの検知数の推移を示します。検知数急増の主な要因は、ランサムウェア感染を目的とするメールが大量にばらまかれたことです。ランサムウェア感染を狙う不正メールは 2015年 12月頃から目立つようになり、今期は大規模な攻撃活動が確認されるなど検知数が増加しました。また、以前から確認されている金融マルウェア感染を狙う攻撃も引き続き行われています。

感染するマルウェアの詳細や動向の変化は「2.3 感染するマルウェアの動向」で解説します。

図 10 悪意あるファイルが添付された不正メールの検知数推移（Tokyo SOC調べ 2015年 7月 1日～2016年 6月 30日）


16


今期はメールによる攻撃の検知数が増加しただけでなく、攻撃手法にも変化が見られました。Tokyo SOC

で検知した不正メールによる攻撃を分析したところ、1 度の攻撃で送られたメールに添付されたファイルのハッシュ値がそれぞれ異なっている傾向が見られました。図 11 は 1 度の攻撃に使用された異なるハッシュ

値をもつファイルの数を月別に集計し、その中央値の推移を表したものになります。2015 年 12 月からは徐々にメールを起点とした攻撃が活発化しており、2016 年 3 月以降は Locky などの出現にともなって 1

度の攻撃で利用されるハッシュ値の数は急激に増加しました。

このようにハッシュ値を変更しているのは、パターンマッチング手法による検知を回避しようとしているためだと考えられます。図 12は Tokyo SOCで観測された添付ファイルを主要アンチウィルスベンダー59

社で検知したかを調査し、その検知率をグラフで表したものになります。検知率は平均で 55.6%となっており、多くの攻撃用添付ファイルがアンチウィルス・ソ

フトでは検知できていないことを示しています。最も検知率の高かった A社でも 98.2%となっており、全体の 1%以上は検知できていません。さらにこの検知率は攻撃に使われた添付ファイルが初めて観測された当日のものではなく、後日になってから検知率を調査したものとなっており、当日の検知率はさらに低下します。

図 11 1度の攻撃に利用されたハッシュ値の異なるファイル数の月別中央値の推移（Tokyo SOC 調べ 2015年 7月 1日～2016年 6月 30日）

0

2

4

6

8

10

12

14

2015

年7月

2015

年8月

2015

年9月

2015

年10

月

2015

年11

月

2015

年12

月

2016

年1月

2016

年2月

2016

年3月

2016

年4月

2016

年5月

2016

年6月


17


発生頻度が低い攻撃に対してであれば十分な防御率であるといえますが、悪意のある添付ファイルを起点とした攻撃は増加の傾向にありユーザーは常に危険に晒される状況となっています。

このような脅威からの被害をなくす、あるいはインシデントが発生しても被害を拡大させないためには、多層的な防御やインシデントの発生を見越した回復や被害軽減策がより一層重要になってきていると言えます。

図 12: Tokyo SOCで観測された添付ファイルに対する主要アンチウィルスベンダー59社による検知率分布（Tokyo SOC 調べ 2015年 7月 1日～2016年 6月 30日、VirusTotalのデータを利用）

0.0%

10.0%

20.0%

30.0%

40.0%

50.0%

60.0%

70.0%

80.0%

90.0%

100.0%

A社 B社 C社 D社 E社 F社 G社 H社 I社 J社 K社 L社 M社

N社

O社 P社 Q社 R社 S社 T社 U社 V社 W社 X社 Y社 Z社 a社 b社 c社 d社 e 社 f社 g社 h社 i社 j社 k社 l社 m社 n社 o社 p社 q社 r社 s社 t社 u社 v社 w社 x社 y社 z社 1社 2社 3社 4社 5社 6社 7社


18


91.3%

5.0%

3.0% 0.7%

ZIP形式

Microsoft Word形式(doc/docx/docm)

その他の圧縮形式(rar/7z/lzh/gz)

その他

ZIP圧縮したスクリプト・ファイルを添付する攻

撃が主流

図 13、図 14 は、今期検知された添付ファイルの形式別の割合です。この図について、ファイルの形式の観点から紹介します。

検知された添付ファイルの形式

今期も圧縮形式のファイルが添付されたメールを多数検知しました。特に ZIP 形式(.zip)の割合が 91.3%と高く、2015 年下半期の 64.0%

から増加しています。その他の圧縮形式として、RAR(.rar)、7zip(.7z)、LZH(.lzh)、gzip(.tgz)の利用を確認しています。

非圧縮のファイルでは、主に Microsoft Word

形式(.doc/.docm)のドキュメントファイルが利用されています。Microsoft Word形式の割合は5.0%と 2015 年下半期の 27.5%から減少していますが、これは圧縮形式の検知数が非常に多かったため相対的に割合が減少しているものであり、引き続き攻撃に悪用される主要なファイル形式である点に変わりはありません。Microsoft Word 形式のファイルにはマクロが組み込まれており、マクロを実行することでマルウェア感染が行われます。Microsoft Office

製品の脆弱性を悪用するものではないため、最新のパッチが適用されている環境においてもマルウェア感染の可能性があります。

圧縮形式ファイル展開後のファイル形式

圧縮形式ファイル展開後のファイル形式では95.0%が JavaScript 形式(.js/.jse)となりました。JavaScript ファイルはダウンローダーとして動作し、実行されると外部のサーバーからマルウェアをダウンロードし、感染を試みます。1

年前（2015 年上半期）に行った同様の集計では圧縮形式展開後のファイルは 99%以上が実行形式（.exe/.scr）という結果でしたが、今期の実行形式の割合は 3.9%に留まっており、傾向が大きく変わりました。圧縮形式展開後のファイルに JavaScriptが利用される攻撃は 2015

年 12月に発生した TeslaCrypt 2.2.0（通称「vvv

ウィルス」）への感染を狙う攻撃で注目され、今期はメール経由の攻撃の主流になったと言えます。また、JavaScript以外のスクリプト・ファイル（.wsf/.vbs）や HTMLアプリケーション（.hta）の利用も確認しています。

図 13 検知された添付ファイルの形式別検知数割合

(Tokyo SOC調べ 2016年 1月 1日～2016年 6月 30日)


19


正規のメールや公開情報を流用する攻撃が

増加

今期、Tokyo SOCでは実在の企業を騙ったメールが多数、かつ広範囲に送信されたことを確認しています。2015年下半期の本レポートにおいて、そのような事例を 3件立て続けに確認したことを紹介しましたが、今期については同様の事例が毎月確認されるようになり、多い月には約 50 通のメールが確認されました。メールの件名については、銀行振込みの完了通知、郵便物の集荷・配送通知など多岐に渡り、日常で実際に発生するようなメールを装うものや、件名のないメールも

多く見られる結果となりました。また、本文については、Web上で公開されているサンプル文面や、実際のメールを流用したと見られるものを検知しており、今期の特徴の一つであると言えるでしょう。そして、メールに添付されていたファイルについては、上記の図14 で述べたメール全体での傾向とは異なり、「.exe」などの実行形式ファイルが過半数を占める形となりました。それらファイルを実行するとランサムウェアや、金融マルウェアへの感染に至ります。

図 15、図 16 に Tokyo SOC で確認した実際のメールの一部を紹介します。

図 14 検知された圧縮形式ファイル展開後の形式別検知数割合 (Tokyo SOC調べ 2016年 1月 1日～2016年 6月 30日)

図 15 不正メールサンプル(抜粋) 図 16 正規メールサンプル(抜粋)

95.0%

3.9%

0.6% 0.5%

JavaScript (js/jse)

実行形式 (exe/scr)

その他のスクリプト(wsf/vbs)その他


20


両図の赤枠で囲われた部分について、罫線など多少のレイアウト相違は見受けられるものの、文章の内容や句読点の位置が一言一句違わぬ点から、攻撃者は正規メールを何かしらの方法で入手し、攻撃に流用したものと推測されます。さらに、送信元アドレスについても、実在する金融機関のドメインに偽装するなど、巧妙なものでした。

また、2月中旬から 3月上旬にかけて、EMS(国際スピード郵便)のサンプル画面を攻撃の一部に流用したメールを確認しました。このメールは、国外のフリーメールのアドレスを送信元としており、件名の記載はありませんでしたが、郵便局を装った本文、及びファイルが添付されていました。添付されていたファイルの中身は、「.scr」(実行形式ファイル)となっており、このファイルを実行した場合、EMSの送り状が表示されます。表面上の動作としては送り状が表示されるだけですが、バックグラウンドで「Rovnix」と呼ばれる金融マルウェアに最終的に感染します。

このように、正規のメールやインターネット上に広く公開されている情報が攻撃の一部に流用されている点から、攻撃者はその手口をより洗練させてきています。特に、実際のメールを流用したケースと思われるものについて、文面をぱっと見ただけではメールの真贋を判別することは難しいでしょう。


21


87.1%

3.3%9.6%

金融マルウェア

ランサムウェア

その他

件名や添付ファイル名に日本語を利用する不正メールで感染するマルウェアの特徴

前述の通り、今期は件名や添付ファイル名に日本語を利用したり正規のメールを流用したりする攻撃メールが増加しましたが、このようなメールは主に金融マルウェアへの感染を狙って利用されています。図 17

は 2015年 7月 1日～2016年 6月 30日の間に検知した、件名または添付ファイル名に日本語を利用するメールで感染するマルウェアのタイプ別の割合です。金融マルウェアの感染を目的にしたメールが 87.1%と多数を占めていることがわかります。一方、Tokyo SOC

においてランサムウェア感染を目的としたメールで日本語の利用が確認された事例は、2016 年 4 月前半の限られた期間に検知された「CRYPTOLDESH」への感染を目的とした攻撃のみでした。本章で紹介したように、メールを悪用する攻撃全体ではランサムウェア感染を狙う攻撃が目立ちましたが、日本語を利用するメールに限った場合の検知数は全体の 3.3%に留まりました。

金融マルウェアおよびランサムウェアはいずれも、攻撃者の真の目的はマルウェア感染そのものではなく、マルウェア感染を通じて個人や企業から金銭を得ることにあります。この点において、日本国内における

不正送金額が増加傾向にあることが報告されていることからも、金融マルウェアは日本を狙う攻撃者にとってある程度成功しているマルウェアであると考えることができます 2。そのような攻撃を継続して行う中で、添付ファイル名や文面が徐々に進化していることが今期の攻撃メールの傾向にも現れているものと考えられます。

一方、ランサムウェアも感染時の影響が大きいこともあり注目され、感染事例も数多く報告されています。また、身代金要求画面に日本語を表示するものも存在しており、攻撃対象として日本も意識されていると言えます。しかし、日本のユーザーや企業が身代金を支払ったという報告はあまり多くありません。そのため、攻撃者から見た場合、他の地域と比較して日本に対する攻撃が特別に成功しているとは言えない状況にあるのではないかと推測されます。

金融マルウェアとランサムウェアに関するこのような違いが、図 17 のような検知傾向の違いとして現れているものと考えられます。 2 警察庁：平成 27 年中のインターネットバンキングに係る不正送金事犯の発生状況等について https://www.npa.go.jp/cyber/pdf/H280303_banking.pdf

図 17 件名または添付ファイル名に日本語を利用するメールで感染するマルウェアのタイプ別割合（Tokyo SOC調べ 2015年 7月 1日～2016年 6月 30日）

22


[Column2] 2016年上半期におけるメールを利用した攻撃の変遷

クライアント PCを狙った攻撃の動向の章でもお伝えしたように、2016年の上半期は悪意のあるファイルを添付したメールによる攻撃が多く観測されました。観測された悪意のあるファイルはそれ自身だけで被害を及ぼすものは少なく、大多数は外部のサーバーに対して通信することで被害を及ぼすものでした。本コラムでは添付されたファイルが実行された際にみられるドメイン名や HTTPリクエストのパス名の調査結果から攻撃に使われているシステムの全体像に迫りたいと思います。

◆ 添付されるファイルと接続先の関係

攻撃に使われるファイル名は攻撃対象となるユーザーに開かせるため、様々なものが使われます。2015

年下半期の本レポートでは同じファイル名の添付ファイルを用いたバラマキ型メール攻撃についてとりあげ、攻撃に使われているファイルが短期間に使い捨てられていることや、攻撃成功後に感染するマルウェアの種類によって攻撃を実施しているグループが異なる点などについて解説しました。今期のレポートでは添付ファイルのファイル名やハッシュ値で複数の種類のものが観測されているものに注目し、攻撃の傾向について解説します。

図 18は Tokyo SOCで観測された攻撃メールに添付されていたファイルと実行時に接続する先のサーバーの関係の例を示しています。この図は同じ攻撃者が複数種類の添付ファイルと複数のドメイン名を使って攻撃している様子を表しています。図では赤いノードが添付ファイルのファイル名、黄色いノードがその添付ファイルのハッシュ値、緑のノードがファイル実行時に接続を試みるサーバーのドメイン名、そして青いノードが接続した際に送信する HTTPリクエストのパス名になります。それぞれ関係するノードを線で結んでいます。

この例では同じファイル名の添付ファイルが異なるハッシュ値を持つケースや、異なるハッシュ値をもつファイルを実行した際にも共通のドメイン名を利用しているケースを表しています。しかし、最終的に送信される HTTPリクエストのパス名は共通しており、かつ一般的なWebサイトなどではあまり見られないパス名を利用しています。このことから、この図にでてくる添付ファイルやドメイン名はそれぞれに繋がりがなかったとしても、同じ攻撃者によって利用されているファイルやドメイン名なのではないかという推測が成り立ちます。

図 18 攻撃における添付ファイル名、ハッシュ値、実行時に通信する宛先のドメイン名、HTTPリクエストのパス名の関係例

23


◆ より複雑な構造をもった攻撃

図 18では解説のためにシンプルな例を紹介しましたが、より多数のファイルやドメイン名を使った攻撃も発生しています。図 19は図 18に比べてより多くの添付ファイル名、ハッシュ値、ドメイン名を持つ攻撃の例になります。この攻撃は日本時間の 2016年 3月 30日 18時 03分から同日 21時 28分までに検知されたイベントの関係性から同一の攻撃とみなしており、図 19 ではその関係性を描画しています。この例では図 18のように同じファイル名で異なるハッシュ値を持つような添付ファイルはなく、1つ

のファイル名が 1つのハッシュ値をもつ形式でした。さらにファイル名は使われる単語や記号がバラバラになっており、表向きのファイルの情報を見ただけでは互いに関連するファイルであると気づくのは難しくなっています。

しかし、これらの添付ファイルを動作させた時に通信する宛先を見た時、異なるハッシュ値を持ついくつかのファイルが同じドメイン名に通信をしているのがわかります。1度攻撃に利用されたドメイン名が長い期間を経てからもう 1度利用された場合は、異なる 2人以上の悪意ある人物が時間をおいて利用

図 19 より多くの添付ファイル名、ハッシュ値、ドメイン名を持つ例

24


した可能性もあります。しかし、今回の攻撃では約 3時間のあいだに同じドメイン名を利用する攻撃が観測されており、これは同一人物による攻撃であると考えることができます。

さらにこれらのドメイン名を束ねるのが HTTPリクエストのパス名です。この例では 19種類のドメイン名が登場していますが、どのドメイン名と通信をした時も/34f345gh4というパス名が利用されています。短いパス名ではありますが、一般的に HTTPのサービスなどに使われる名前ではなく、攻撃のために用意されたものだと考えられます。このようなパス名が短期間に重複されて利用されるというのは考えづらいため、この例に登場した添付ファイルは全て同じ攻撃者による一連の攻撃だとわかります。

◆ 2016年 5月から 6月にかけて発生した大規模なランサムウェア感染を狙った攻撃

図 20 2016年 5月から 6月にかけて発生した一連の攻撃において出現した添付ファイル名、ハッシュ値、ドメイン名、パス名の関係図

25


ここまでで紹介した例のような規模の攻撃はこれまで散発的に発生してきましたが、2016年 5月から6月にかけてより規模の大きい攻撃が発生していました。この攻撃で出現した添付ファイル名、ハッシュ値、ドメイン名、パス名の関係を図 20に示しています。これまで紹介した例ではファイルのハッシュ値やドメイン名、パス名は散発的かつ短時間で発生した攻撃で使い捨てられてきました。しかし、図 20で示した攻撃は約 2ヶ月間継続し、その間にドメイン名やパス名が使いまわされていました。ドメイン名やパス名が使いまわされることによって関係のある要素が増え、このような複雑な関係図が描画されるまでになりました。

ドメイン名が使いまわされているということは攻撃者側にとって攻撃後に通信する接続先の選択肢が増えるということであり、より円滑に攻撃が実施されてしまう可能性があります。

ファイル名、ハッシュ値、ドメイン名やパス名の関係にも多様なものが含まれていました。同じファイル名でもファイルごとのハッシュ値が違うようなもの（図 21）や、同じハッシュ値のファイルが複数のドメイン名に接続するようなもの（図 22）も見られています。このようなファイル名、ハッシュ値、ドメイン名の関係をもつ攻撃は 2016年 4月以前にもありましたが、ここまで規模の大きいものが Tokyo

SOCで観測されたのはこの攻撃が初めてでした。ここで登場する不正な添付ファイルはほとんどがランサムウェアに感染させるためのものであることを確認しています。

図 21 同じファイル名でもファイルごとのハッシュ値が違う例

26


図 23 2016年 5月から 6月にかけて発生した大規模攻撃に関連したイベントの件数推移

図 22 同じハッシュ値のファイルが複数のドメイン名に接続する例

0

100

200

300

400

500

600

700

800

900

1,000

2016

/5/1

2016

/5/4

2016

/5/7

2016

/5/1

0

2016

/5/1

3

2016

/5/1

6

2016

/5/1

9

2016

/5/2

2

2016

/5/2

5

2016

/5/2

8

2016

/5/3

1

2016

/6/3

2016

/6/6

2016

/6/9

2016

/6/1

2

2016

/6/1

5

2016

/6/1

8

2016

/6/2

1

2016

/6/2

4

2016

/6/2

7

27


図 23では図 20で紹介した攻撃に関連したイベントの発生件数推移を表しています。この攻撃に関連する不正な添付ファイルは 5月 5日にはじめて観測されました。この時は件数もごく少ないものですぐ攻撃も収束しましたが、同じドメイン名およびパス名が使われた攻撃が 5月 9日に再び発生しました。その後は 5月 31日に 1度休止状態になります。しかしさらに 6月 20日には活動を再開し、大規模な攻撃となりました。

2016年 4月以前は散発的であったメールを起点とする攻撃がここまでの規模になったのは、攻撃者が自身の使う攻撃のためのプラットフォームを成長させていったのではないかと考えられます。攻撃システムの構築・運用の視点から考えると、1つの攻撃で利用するファイルの種類やドメイン名・パス名などが限定されており、さらに 1度の攻撃だけで使うのをやめることを前提としたほうがシステムを単純化できるため、構築が容易になります。運用の観点からも、攻撃者も攻撃システムの管理者だと考えると単純なシステムの方が不整合が発生しにくく、障害やトラブルがおきてもそれに関連したサーバーなどの利用をやめて、次のサーバーに乗り換えればよいと言えます。2016年 4月以前はこのような構成を利用した攻撃が多く見られていましたが、次々とサーバーやドメイン名をのりかえるという戦略では、攻撃に利用できる新しいサーバーを探しだして攻撃し、確保し続けなければなりません。そうなると攻撃者が攻撃の規模を拡大させるのも難しくなってしまうため、攻撃者が持つ資源をうまく再利用できるようにシステムを進化させたのではないかと推察されます。

このような攻撃手法やシステムの進化はメールを起点とした攻撃以外でも継続的に発生していると予想されるため、防御側も守るための手段やシステム、運用をより発展させていくことが重要だと考えられます。防御側のシステムも自動化などによって運用の効率化を図るとともに、攻撃に関する情報の共有をより一層進めていくなどの対策によって、攻撃者に対抗していくことが重要であると言えます。


28


2.3 感染するマルウェアの動向

2016年上半期も引き続き、感染端末上のファイルを暗号化し復号のためと称して金銭の要求を行うランサムウェアや、オンライン・バンキングのアカウント情報を窃取する目的をもつ金融マルウェアへの感染を示す通信を多く確認しています。

Tokyo SOCにおいて高危険度のセキュリティー・インシデントとしてお客様へご連絡差し上げた件数を各月で集計し、原因別に「ランサムウェア」、「金融マルウェア」、「その他」と区分したものを図 24 に示しま

す。金融マルウェアへの感染を示す通信は年間を通して継続的に検知しています。またランサムウェアへの感染を示す通信は 2015年 10月より増加し始めており、2016 年上半期は 1 月をピークとして継続的に検知している状況です。

クライアントPCを狙って金銭を窃取する事を目的とした攻撃は今後も続くと考えます。

本節では、これらのランサムウェアと金融マルウェアの特徴と概要についてご紹介します。

図 24 インシデント発生原因の推移 (TokyoSOC調べ 2015年 8月 1日～2016年 7月 31日)


29


2.3.1 ランサムウェア

ランサムウェア概要

ランサムウェアとは、感染端末内や接続しているネットワークドライブ内のファイルを暗号化し、復号のためと称して金銭の支払いを要求するマルウェアです。2016年上半期は、日本国内にて感染事例が報告され話題となったものとして CryptoWall、TeslaCrypt、Locky

等がありました。他にも特定の国や組織のみを狙ったランサムウェアの活動が報告されたり、被害者の心理につけこみ 1時間ごとに 1つのファイルを削除したりOS 再起動により 1,000 個のファイルを削除してしまうなど悪質なタイプのものも登場し、日々新しい種類や亜種が確認される状況が続きました。

今期 Tokyo SOCにて確認されたランサムウェアは、その種類やバージョンごとに、暗号化アルゴリズムのタイプ、暗号化後のファイルの拡張子、また攻撃指令サーバーとの通信パターンが異なる傾向があった一方で、共通して暗号化後の支払い方法に仮想通貨であるビットコインが指定される傾向がありました。

今期話題となった主なランサムウェアをいくつか取り上げ、その特徴をご紹介します。

CryptoWall

2014 年頃から存在が確認されていたランサムウェアであり、Tokyo SOC では昨年末から 2016 年 2 月

まで本ランサムウェアによる感染事例が確認されていました。

昨年確認されていた検体では、暗号化後のファイルにランダムな文字列が付加されていました。2016年 1

月末の検体では、本ランサムウェアの感染後に感染端末上のファイルが暗号化され、ファイル名がランダムな英数字 (例：暗号化前：memo.txt、暗号化後：er53sm.mq43w)に書き換えられていました。このことから、2016 年に入って CryptoWall の新しいバージョンのものが登場していたことが分かります。またファイルの暗号化完了後は、INSTRUCTIONS_[ランダムな英数字]というファイルが.txt、.png、.htmlの 3つの形式で各ディレクトリーに生成され、被害者にビットコインでの支払いを要求するという特徴がありました。

本ランサムウェアへの感染直後、POST メソッドにて攻撃指令サーバーへの通信を行います。図 25 にTokyo SOC で検証を行った際に確認した攻撃指令サーバーとの通信の例を示します。図 25に示した通り、POST 通信時にランダムな英数字(0-9 および a-f までの小文字)を値として攻撃指令サーバーに送信しているという特徴がありました。

また、CryptoWallは攻撃指令サーバーへの通信を遮断することで感染端末上での暗号化を止めることが可能なことから、万が一感染した場合でも IPSなどのネットワーク機器で本通信を遮断することで進行を止めることが可能と言えます。

図 25 CryptoWall感染時の攻撃指令サーバーへの通信例


30


TeslaCrypt

昨年 12 月 6 日、クライアント PC のファイルを暗号化し.vvvを付加した名前に変更する「vvvウィルス」として TeslaCrypt が話題になりました。Tokyo SOC

では 2015年 12月 9日にメールで送られてきた不審なファイルを展開したことで、この TeslaCryptへ感染する攻撃を確認しています。

2016 年 1 月の検体では、本ランサムウェアへの感染後に暗号化されたファイル名に.xxxが付加されていました。また時期ごとに暗号化後にファイルに付加する文字列が.vvv /.xxx/ .ttt/ .mp3/ .macro等と変化していたことから、2016 年上半期も引き続き TeslaCrypt

の新たなバージョンが登場していたことが分かります。図 26に Tokyo SOCにて検証を行った際に確認した

攻撃指令サーバーとの通信の例を示します。図 26 に

示した通り攻撃指令サーバーとの通信では、リクエストとして data=の後ろにランダムな英数字(0-9 およびA-Zまでの大文字)を値として含む内容を送信し、レスポンスとして文字列「---!!!INSERTED!!!---」を受け取っていることが判明しました。

TeslaCryptは、CryptoWallとは異なり、攻撃指令サーバーとの通信を遮断しても引き続き感染端末上での暗号化を継続するという特徴があります。このため攻撃指令サーバーとの通信を遮断することによって、暗号化を止めることはできませんが、クライアント PC

から攻撃指令サーバーに送信されるクライアント情報を遮断できるという点ではネットワーク機器などによって通信を遮断するメリットは少なからずあると言えます。

図 26 TeslaCrypt感染時の攻撃指令サーバーへの通信例


31


Locky

2016 年 2 月頃に存在が確認され、Tokyo SOCでは2 月 16 日に本ランサムウェアによる攻撃を確認しています。

2016 年 2 月の検体では、他のランサムウェアと同じく感染端末上のファイルが暗号化され、ファイル名が[ランダムな英数字].lockyという形式に書き換えられました。Tokyo SOCで検証した際の感染端末上のデスクトップ例を図 27に示します。図 27から分かる通り、英語だけではなく多言語対応ができているという点も本ランサムウェアの特徴と言えます。また、Lock

yへの感染後は攻撃指令サーバーとPOST通信を行うことを確認していますが、送信される通信内容が暗号化されているため攻撃指令サーバーに送られている情

報を確認するのが困難であるという特徴があります。また、日を追うごとに攻撃指令サーバーとの通信パターンが更新されたり、サンドボックス製品による検知を回避するような機能を強化してきていることから、ネットワーク監視機器による検知の回避を試みていると考えられます。

Tokyo SOCで 2016年 3月末時点で確認した結果では、Lockyが感染時に攻撃指令サーバーと行う通信を遮断することで感染端末上のファイルの暗号化も停止することが判明しています。このため万が一感染した場合でもIPSなどのネットワーク機器で本通信を遮断することにより暗号化を止めることが可能と言えます。

図 27 Lockyに感染した端末上に表示される脅迫文の例


32


CryptXXX

2016 年 3 月頃に初めて存在が確認された新しいランサムウェアです。Tokyo SOCではTeslaCryptの活動終了と交代する形で、本年 5月中旬以降本ランサムウェアによる攻撃を継続して検知しています。

CryptXXXは他のランサムウェアと同じく感染端末上のファイルを暗号化し、暗号化したファイル名に「.

crypt」を付加します。また暗号化開始を意図的に遅延させたり仮想環境を検知する仕組みを備えていることが知られており、サンドボックス機器などのネットワーク監視機器をすり抜け、攻撃対象ネットワーク内に侵入しようとする機能を強化していると考えられます。

Petya

2016 年 3 月頃よりその存在が確認されているランサムウェアです。Petyaはドイツの特定の機関を狙った攻撃に使用されているという情報があります。

Tokyo SOCでは本マルウェアによる実際の感染は確認されていません。今期は感染端末上の個々のファイルの暗号化を行うランサムウェアが多く確認されましたが、本ランサムウェアはOS起動時のプログラムを書き換えてハードディスク全体を暗号化してしまうという点が特徴的です。

SamSam

2016 年 3 月頃よりその存在が確認されている新しいランサムウェアです。SamSamはヘルスケア業界をターゲットとしているという情報があります。Tokyo

SOCでは本ランサムウェアによる実際の感染は確認されていません。他のランサムウェアとは異なりサーバーの脆弱性を悪用し攻撃対象ネットワーク内に侵入するという特徴が知られています。Cisco社により報告されている感染事例では 3、まずJBossの脆弱性(CVE-

2010-0738)を悪用し遠隔操作の機能を持つマルウェアを攻撃対象ネットワーク内に侵入させます。その後、攻撃対象のホスト上でSamSamと呼ばれるランサムウェアを外部サーバーからダウンロードし感染に至るという情報があります。このように他のランサムウェアと異なり、感染経路としてWebサイト閲覧やメール経由ではなく、サーバーの脆弱性を悪用して侵入し感染させる点が特徴的でした。

CRYPTOLDESH

2015 年頃より存在が知られていたランサムウェアでしたが、本年 4 月 6 日～7 日にかけて一時的に本マルウェアへの感染を狙うメールをTokyo SOCにて検知しました。

本マルウェアへの感染を狙う攻撃は以前より確認されていましたが、図 28 のようにメールには日本語が利用されており、日本のユーザーを意識した攻撃であると考えられます。Tokyo SOCにおいてランサムウェア感染を目的としたメールは非常に多く確認されていますが、このように日本のユーザーを狙って感染させようとする攻撃を検知したのはこのケースが初めてでした。

Tokyo SOCで実際に確認した本マルウェアへの感染を狙うメールでは、添付されているZIP形式の圧縮ファイルにはダウンローダーとなるJavaScriptファイル(.js)やスクリーンセーバーファイル(.scr)が含まれていました。ユーザーがこの圧縮ファイルを展開し、ダウンローダーのファイルをダブルクリック等で実行することで外部サイトからマルウェア本体のダウンロードが行われ感染に至るケースが確認されました。

Tokyo SOCで確認したマルウェア本体のダウンロードに使われたURLにはアクセス先ホストがWordPress

であることを示すパスが含まれていたことから、通常運用しているサーバーにおいてWordPressの脆弱性を悪用され、マルウェアのダウンロード先として利用された可能性が考えられます。

3 Cisco: Cisco Talos Blog: SamSam: The Doctor Will See You, After He Pays The Ransom http://blog.talosintel.com/2016/03/samsam-ransomware.html

図 28 CRYPTOLDESHへの感染を狙う不審なメールの例


33


ランサムウェア別検知状況の推移

2.3節冒頭でご紹介した通り、Tokyo SOCにおいて2015年 10月以降ランサムウェアによる被害を継続して確認しています。ここでは、Tokyo SOCでの検知状況をもとに被害の原因となったランサムウェアを種類別に集計し、月ごとの検知数の推移を解説します。

Tokyo SOC においてランサムウェアへ感染している事をセキュリティー・インシデントとしてお客様へご連絡差し上げたもののうち、ランサムウェアの種類別に集計した結果を図 29に示します。

2015 年 10 月～2016 年 2 月までは、CryptoWall による被害を継続して検知していたことが分かります。2016 年 1 月には、被害者となったユーザーが改ざんされた Web サイトの閲覧を行った結果、ドライブ・バイ・ダウンロード攻撃によって CryptoWallに感染するという事例が Tokyo SOC で複数件確認されていました。 Tokyo SOCで確認された事例では、いずれも改ざんされたサイトは Joomla が使用されており、またMicrosoft Internet Explorerを使用した場合のみ攻撃サーバーへ誘導される流れとなっていたことが分かりました。

また 2015 年 12 月～2016 年 4 月までは TeslaCrypt

による被害を継続して検知しており、2016年 2月～4

月において主流になっていたランサムウェアであることが分かります。TeslaCryptの活動が 4月を境に突如収束した理由としては、2016 年 4 月下旬に本ランサムウェアの開発元がTeslaCryptに関する全ての活動を終了するというアナウンスを行い、5 月には暗号化さ

れたファイルを復号するためのマスターキーが公開されたことが原因として考えられます。

2016年 5月からは、TeslaCryptの活動終了と交代する形で CryptXXX による被害が増加しました。Tokyo

SOCで確認したCryptXXXへの感染を狙う経路としては、当初ドライブ・バイ・ダウンロード攻撃によるものが多く確認されていました。しかしその後は、不正なメールに添付されたファイルを展開し、展開後のファイルに含まれているダウンローダーを実行してしまうことで、CryptXXX に感染する経路も確認されている状況です。この傾向の変化は 2.1 節にて解説している Angler Exploit Kitによる攻撃の検知が減少したことが要因となっていると考えられます。

また Locky は 2016 年 3 月～5 月に流行していましたが、その後 6月中旬までは Lockyによる感染被害は報告されていませんでした。しかし、6 月下旬からサンドボックス製品の検知回避機能を備えた Lockyへの

図 29 ランサムウェア別の検知比率推移 (TokyoSOC調べ 2015年 10月 1日～2016年 7月 31日)

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

2015

年10

月

2015

年11

月

2015

年12

月

2016

年1月

2016

年2月

2016

年3月

2016

年4月

2016

年5月

2016

年6月

2016

年7月

CryptoWall

TeslaCrypt

Locky

CryptXXX


34


感染を狙う活動が活発化しており、Locky の活動は2016年下半期も続くと考えられます。

このように攻撃に使われるランサムウェアは、様々な要因により変化していき、時期によっても特徴があることが分かります。


35


ランサムウェア感染端末の通信先概要

Tokyo SOCで確認した実例をもとに、感染端末がアクセスした通信先(攻撃指令サーバー)を国別に集計したものを図 30に示します。

国別の傾向として、CryptoWallと TeslaCryptは送信先の国が分散する傾向にありましたが、一方で Locky

と CryptXXX は送信先が特定の国に偏る傾向があることが分かりました。

CryptoWall, TeslaCrypt, Lockyともにアメリカへの通信が多く発生しており、その多くがホスティング事業者所有のものでした。

特に注目する点としては、CryptoWallでは検知数は少ないものの日本のホストが攻撃指令サーバーとして使用されているケースを確認しました。その所有者を

確認したところ、いずれもホスティング事業者所有のものとなっていることが判明しました。

また CryptXXX では他のランサムウェアとは送信先国別の傾向が異なり、ドイツへの通信が 85%以上を占めていることが分かりました。世間一般の脅威情報から、ドライブ・バイ・ダウンロードによってダウンロードされるCryptXXXの通信先としてドイツの IPアドレスが多い傾向があることから、Tokyo SOCにおける検知傾向を裏付ける結果となりました。

ドイツ85.7%

モルドバ共和国

14.3%

CryptXXX

アメリカ30.0%

ロシア30.0%

フランス20.0%

エストニア10.0%

ウクライナ10.0%

Locky

アメリカ28%

不明12%

フランス10%オランダ

5%

ロシア6%

トルコ5%

ドイツ4%

カザフスタン3%

イギリス5%

カナダ2%

デンマーク2%

ポーランド2%

ブラジル2%

中国2%

インド2%

イタリア2%

日本2%

ルーマニア2%

ベラルーシ1%

チェコ1%

インドネシア1%

リトアニア1%

モルドバ共和国1%

シンガポール1%

ウクライナ1%

CryptoWall

アメリカ50.0%

不明15.6%

ドイツ6.3%

トルコ6.3%

イギリス6.3%

ベルギー3.1%

カナダ3.1%

フランス3.1%

イタリア3.1%

タイ3.1%

TeslaCrypt

図 30 ランサムウェア別通信先比率 (Tokyo SOC調べ 2015年 10月 1日～2016年 7月 31日)


36


2.3.2 金融マルウェア

金融マルウェア概要

金融マルウェアとは、感染したホスト上でクレジットカード情報やオンライン・バンキングの口座情報などを窃取することを目的とした、悪意のあるプログラムの総称です。ユーザーが端末上で入力した情報を窃取するキー・ロギングの機能やユーザーが攻撃対象銀行へアクセスをした場合に、ブラウザー上に本物そっくりの偽サイトを表示しユーザーに金融情報を入力させる Web インジェクションの機能を持つものが存在します。感染端末のファイルを暗号化して復号と引き換えに金銭を要求するランサムウェアとは異なり、金融マルウェアは感染端末の収集した情報をバックグラウンドで外部の攻撃指令サーバーへ送信する挙動をとるため、被害者が感染したことに気が付きにくいという特徴があります。

2015 年 3 月には日本の金融機関を標的とする「Tsukuba」の存在が IBM Security Trusteerの研究者から報告され 4、Tokyo SOC でも 2015 年 3 月に

Tsukuba への感染事例を確認しています。また 2015

年 9 月には、金融マルウェア「Shifu」が日本の銀行14 行を含む金融機関を標的としていることが IBM

X-Forceより公表 5されています。

2016年も引き続きこの傾向は続いており、情報処理推進機構(IPA)が発表した「情報セキュリティー10 大脅威 2016」の中でも、金融マルウェアによるオンライン・バンキングやクレジットカード情報の不正利用が、個人を対象とした脅威の第 1 位になっています。2016年 1月には、「Rovnix」と呼ばれる金融マルウェアが日本の銀行 14 行を標的とした活動を開始したことが IBM X-Forceより公表 6されました。

その他にも今期 Tokyo SOC では、日本の金融機関をターゲットとした攻撃を複数確認しています。

本節では今期話題となった主な金融マルウェアをいくつか取り上げ、その特徴をご紹介します。

Zeus/Zbot

2007 年頃からその存在が確認されているマルウェアであり、Tokyo SOCにおいても本マルウェアによる感染を多く確認しています。Zeus は不審なメールや

Webサイト経由でクライアント PCに感染します。感染端末上では、システム・プロセスに自身をコピーすることで感染端末を操作しているユーザーに気付かせないようにしたり、アンチウィルス・ソフトによる検出を回避することが知られています。また、感染した端末同士でボットネットを構成し、攻撃対象とする組織をリストアップする機能があることも知られています。

IBM X-Force では Panda Banker と呼ばれる Zeus

の亜種の存在を確認・公表 7しています。2016年初旬にはヨーロッパやアメリカの金融機関を標的とした攻撃を確認しており、リオデジャネイロ・オリンピックの開催前には、ブラジルに対して攻撃を開始していたことを確認していました。

VAWTRAK

2013 年頃から確認されている金融マルウェアであり、Tokyo SOCにおいても今期 1～2月を中心に本マルウェアへの感染を狙う攻撃を確認していました。

Proofpoint社によると 8、同時期に日本の特定の金融機関を標的とする攻撃が確認されていたことが報告されています。

VAWTRAKの特徴として、感染端末上での不正送金中に画面上にプログレスバーを表示する点や、必要に応じてユーザーに追加情報を入力するよう促すという点があります。

URLZone

2009 年頃から確認されており、「Bebloh」や「Shiotob」という名前でも知られています。URLZone

は他の金融マルウェアと同じく、感染端末から金融情報を窃取する機能があります。本マルウェアは、オンライン・バンキングの対象アカウントから金銭を盗み出した後、残高を書き替え、窃取した痕跡を隠蔽する機能を備えています。また攻撃指令サーバーとの通信を暗号化することで、ネットワーク監視機器での検知を困難なものとしていると考えられます。これまでは主にドイツの銀行を標的として攻撃が行われていたことが知られていました。しかし、IBM Security Trusteer

が公開した情報によると 92016年 2月時点では標的を変え、スペインや日本の銀行を標的としていることが


37


報告されました(図 31)。これは Tokyo SOCで 2016年2 月に本マルウェアの感染を狙った攻撃を集中的に検知していた事実を裏付ける結果となりました。また、Tokyo SOC では運輸業者等の実在する企業を騙るメールを使用して本マルウェアに感染させようとする攻撃を多く確認しており、添付ファイルとして二重拡張子付きのファイル(例: .pdf.exe)が使用している傾向がありました。

4 IBM: Tsukuba: Banking Trojan Phishing in Japanese Waters https://securityintelligence.com/tsukuba-banking-trojan-phishin

g-in-japanese-waters/#.VP2s6_msW-4 5 IBM: Shifu：日本の 14 銀行が標的に。新トロイの木馬https://asmarterplanet.com/jp-security/blog/2015/09/96.html

6 IBM: Rovnix | 日本の銀行を狙うマルウェア

http://asmarterplanet.com/jp-security/blog/2016/01/rovnix-malware-hits-japanese-banks.html 7 IBM: Panda is One Hungry Bear! A Heavyweight Banking Trojan

Rolls Into Brazil https://securityintelligence.com/panda-is-one-hungry-bear-a-heavyweight-banking-trojan-rolls-into-brazil/ 8 Proofpoint: Vawtrak and UrlZone Banking Trojans Target Japan https://www.proofpoint.com/us/threat-insight/post/Vawtrak-UrlZone-Banking-Trojans-Target-Japan 9 IBM: URLZone、日本で増加する組織的サイバー犯罪http://asmarterplanet.com/jp-security/blog/2016/02/the-urlzone-attacks-japan-banks.html

図 31 URLZoneの標的地域


38


Ursnif

2007年頃から存在しているWindowsシステムを対象としたマルウェアであり、「Gozi」という名前でも知られています。Ursnif は、当初英語圏の銀行を攻撃対象としていましたが、現在では多言語化しており2015 年にはブルガリア等他の国への攻撃も報告されています。他のマルウェアと同様クレジットカード情報やオンライン・バンキングの口座情報などを窃取したり、キーロギングを行いユーザーが端末上で入力した金融情報を窃取する機能を持つことで知られていま

す。Tokyo SOCでは、今期 2月から本マルウェアへの感染を狙う攻撃を多く検知しており、金融マルウェアの中では現在主流となっています。

下記に、Ursnif が攻撃指令サーバーと通信を行う際のリクエスト例を示します。Tokyo SOCで確認した攻撃では、攻撃指令サーバーへのリクエストに"/images/"

を含み、最後が[ランダムな英数字].bmpで終わる形式の通信を使用していることを確認しました。

Dyre

2014 年頃から確認されているマルウェアで、"I am

Dyreza"という文字列がコード内に含まれていることからその名が付けられました。Dyreは遠隔操作機能を持ち、アンチウィルス製品やセキュリティー監視機器の検知を回避する機能を持つことで知られています。Tokyo SOC では昨年本マルウェアによる攻撃を検知していましたが、今期は本マルウェアによる検知はなく活動が停止していると考えられます。他の金融マルウェアと異なる点として、標的が個人ユーザーではなく、大企業内の法人取引を利用する際のオンライン・バンキング情報を標的としている点があります。このため、万が一感染してしまった場合には被害額が非常に高額となってしまいます。また「Dyre Wolf」と呼ばれる攻撃手法も確認されており 10、ソーシャルエンジニアリングを用いて攻撃を成功させる実例が確認されている点も本マルウェアの特徴といえます。

10 IBM: 数百万ドルを盗み出した Dyre Wolf―満足を知らないサイバー攻撃者

https://asmarterplanet.com/jp-security/blog/2015/04/blg_30.html

例：

example.org/images/SdoINNoT9A4nBnB/svfvL4_2Fb01REBMR7Sdd6f/3rG5KL8_2F/q4_2BUNV

4nzwifnUI/pE6Qw97RCevu/76iYhKoF/_2BNbiByPoWLhE/XvI5st6feA11jzc987K8G/iAJ71tegThyl

2Po2/WiSU5102BHViTt/5vHYVDGJ7XU17nNvzD/ VU54I3EvT/igSoHm6/d3o[.]bmp


39


金融マルウェア別検知状況の推移

2.3節冒頭でご紹介した通り、Tokyo SOCでは 2015

年 8月以降金融マルウェアによる感染を継続して検知しています。そこで本節では、Tokyo SOCでの検知状況をもとに感染の原因となった金融マルウェアを種類別に集計し、月ごとの検知数の推移を解説します。

Tokyo SOC において金融マルウェアへ感染した事をセキュリティー・インシデントとしてお客様へご連絡差し上げたものを、金融マルウェアの種類別に集計した結果を図 32に示します。

増減はありますが前年より引き続き、Zeusによる感染を継続して検知していたことが分かります。また、2016年 1月～2月にかけては VAWTRAK、2月以降はUrsnifによる感染が確認されています。

金融マルウェアを利用した攻撃は、各金融マルウェアの攻撃者グループがどの時期にどの国の金融機関を標的として攻撃を展開しているかという点に依存する傾向にあります。

既にご紹介している通り、今期 1 月～2 月にかけては VAWTRAKや URLZoneの犯罪者グループが日本の特定の銀行を標的として攻撃を開始した事が各セキュリティー・ベンダーにおいて確認されています。Tokyo

SOC で確認した各金融マルウェアにおける検知数の推移もこの公開情報と同様の傾向となっていました。

このように攻撃に使われる金融マルウェアは日々変化していることが分かります。また、今期確認された金融マルウェアでは、既存のマルウェアやその亜種を繰り返し利用する傾向が見えてきました。

図 32 金融マルウェア別の検知比率推移 (Tokyo SOC調べ 2015年 8月 1日～2016年 7月 31日)

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

2015

年8月

2015

年9月

2015

年10

月

2015

年11

月

2015

年12

月

2016

年1月

2016

年2月

2016

年3月

2016

年4月

2016

年5月

2016

年6月

2016

年7月

Zeus

Dyre

URLzone

Ursnif

VAWTRAK


40


金融マルウェア感染端末の通信先概要

Tokyo SOCで確認した実例をもとに、感染端末がアクセスした通信先(攻撃指令サーバー)を国別に集計したものを図 33に示します。

Zeus や VAWTRAK については、ロシアが通信先の上位を占めていることが分かりました。これはマルウェア作成ツールの配信元としてロシアを拠点とする組織が多く確認されていることに、合致していると考え

られます。一方で Ursnifは、アメリカやウクライナが通信先の大半を占める結果となりました。

また、送信先の業種はいずれもレンタルサーバー等のホスティング事業者が保持しているアドレスとなっており、他の攻撃と同様金融マルウェアにおいても攻撃指令サーバーとしてホスティング・サービスが利用される傾向にあることが分かりました。

図 33 金融マルウェア別通信先比率 (Tokyo SOC調べ 2015年 8月 1日～2016年 7月 31日)

ロシア47.9%

アメリカ33.3%

オランダ4.2%

不明4.2%

ドイツ2.1%

日本2.1%

ヨルダン2.1%

韓国2.1%

ナイジェリア2.1%

Zeus

アメリカ79.1%

ウクライナ14.0%

フランス2.3%

日本2.3%

オランダ2.3%

Ursnif

ロシア66.7%

アメリカ22.2%

ブラジル11.1%

VAWTRAK


41


2.4 クライアント PC を狙った攻

撃の対策

本節ではクライアント PC を狙った攻撃への対策について記載します。

今期確認されたクライアント PC を狙った攻撃では、ランサムウェアや金融マルウェアへの感染を狙うものが多く確認されました。

特にランサムウェアに感染してしまったケースでは、基本的には暗号化されてしまったファイルは復号不能と考える必要があります。このためランサムウェア感染後の基本的な復旧方法は、あらかじめ取得しておいたシステム・バックアップからのリストアとなります。定期的にバックアップを取得し、万が一感染した場合でもファイルを復元できる状態にしておくことが重要となってきます。

また感染経路は、ドライブ・バイ・ダウンロード経由とメール経由の 2つに分けられます。

ドライブ・バイ・ダウンロードによる感染では、引き続きAdobe Flash Playerの脆弱性が悪用される傾向があります。このため万が一不審なサイトへ誘導されてしまったとしても、既知の脆弱性を悪用されないようAdobe Flash Playerを常に最新のバージョンに維持すること、また意図せず実行されないようブラウザーでプラグインを無効化する、Click-to-Play 機能を有効化する等の対策を推奨します。

メールによる感染では、添付ファイルとして実行形式のマルウェア本体や、圧縮された JavaScriptファイルやWindows Scriptファイルが利用され、このファイルをユーザーが実行することで感染します。また今期確認されている実在の企業を騙るメールでは、二重拡張子付きのファイルが添付される傾向があります。特に Windows では、フォルダー・オプションの「登録されている拡張子は表示しない」という表示設定が標準で有効になっているため、添付ファイルが不審であることに気づきにくいという点があります。このため本オプションを無効にし 11、全ての拡張子を表示する設定とすることが不審な添付ファイルの実行を防ぐ対策の一つと言えます。

また Windows の標準設定では JavaScript ファイルや Windows Script ファイルをダブルクリックするこ

とで、スクリプトが自動実行されます。感染防止策の一つとして、ユーザーが誤ってダブルクリックしてもマルウェアへ感染しないよう、事前に Windows のレジストリー設定を変更し Microsoft Windows Script

Host を無効化する 12、スクリプト・ファイルの関連付けを Microsoft Windows Script Hostから悪意のないプログラム(メモ帳等)へ変更しておく 13という対策も有効となります。

不審なメールに添付されてくるファイルは開かないという基本的な対策ももちろん重要ですが、本章でご紹介した通り自然な日本語でメールが送られてくるものが多く確認されており不審かどうかの判断を行うのがより難しい状況となっています。このため、業務上必要のない拡張子のファイル(.js/.vsf/.vba など)が添付されているメールは受け取らないといった踏み込んだ対策を行うことも推奨されます。

まとめると、今期確認されたクライアント PC を狙った攻撃への感染防止策は以下の通りです。

1. システム・バックアップの定期的な取得

2. 不審な拡張子のファイルは受け取らない

3. ブラウザーのプラグイン無効化や、

Click-to-Play 機能の有効化

4. Windows における拡張子の表示変更や、スクリプト・ファイルの関連付けを標準設定から変更

5. OS やブラウザー、Microsoft Office、Adobe Flash

Player 、 Adobe Reader 、 Java Runtime

Environment などの修正プログラム適用

6. アンチウィルス・ソフトの最新定義ファイルへの更新

11 Microsoft: ファイルの拡張子を表示するhttps://www.microsoft.com/ja-jp/atlife/tips/archive/windows/tips/252.aspx

12 Microsoft: Disabling Windows Script Host https://technet.microsoft.com/en-us/library/ee198684.aspx

13 Microsoft: 拡張子に関連付けられているアプリケーションを変更するには

https://support.microsoft.com/ja-jp/kb/880086


42


2.5 クライアントPCを狙った

攻撃動向のまとめ

今期のクライアントPCを狙った攻撃では、攻撃手法、感染するマルウェアに以下のような傾向の変化が見られました。

ドライブ・バイ・ダウンロード攻撃が減少し、メールを悪用する攻撃が急増

感染するマルウェアとしてランサムウェアが増加

今期のドライブ・バイ・ダウンロード攻撃の検知数は 584 件と、2015 年下半期の 3,812 件から 84.7%減少しました。また、攻撃が確認された組織も 48.7%と、2015 年下半期の 74.3%から減少しています。ドライブ・バイ・ダウンロード攻撃で狙われる脆弱性では、Adobe Flash Playerが引き続き多くの割合を占めています。攻撃減少の背景には、各組織においてAdob

e Flash Playerのバージョンアップやプラグイン無効化等の対策が進んだことや、 Adobe Flash Player自体のセキュリティー機能が強化されたことなどにより脆弱性を狙う攻撃の成功率が低くなってきたことが要因として考えられます。しかしながら、13.4%の組織では攻撃の影響が確認されており、引き続きクライアントPCへの対策が適切に行われていない組織も存在しています。

ドライブ・バイ・ダウンロード攻撃が減少した一方、悪意あるファイルを添付したメールの検知数は 2015

年下半期と比較し 16.4 倍に増加しました。特に 2016

年 3月以降の増加が顕著であり、これはランサムウェア感染を狙うメールが大量にばらまかれたことが要因です。メールを悪用する攻撃では 1度の攻撃で同様の

メールが多数送信されますが、今期は 1度の攻撃の中でもハッシュ値の異なるファイルが添付される傾向が見られました。これは、攻撃者がより検知を回避しやすくなるよう攻撃方法を工夫しているためと考えられます。また、メールの件名や添付ファイル名等に日本語を利用したり、正規のメールを流用して攻撃を行うケースが増加しました。このようなメールは主に金融マルウェアへの感染を狙うものであり、金融マルウェアを利用する攻撃者は日本のユーザーを意識した攻撃を引き続き行っていることが伺えます。

これらの攻撃の結果感染するマルウェアでは、ランサムウェアの増加が特徴的でした。今期Tokyo SOCにおいて感染を確認したランサムウェアは「CryptoWall」「TeslaCrypt」「Locky」「CryptXXX」であり、時期によってバージョンや種類、感染手法を変えながら感染活動が行われました。このような状況は今後も継続すると考えられます。また、金融マルウェアへの感染を狙う攻撃も継続して確認しています。

このような脅威に対して、攻撃の影響を緩和するようなポリシーや教育、技術的な対策の実施は必須です。悪用される脆弱性の種類や詳細な攻撃手法、感染するマルウェアは変化していくものの、侵入経路や感染手法そのものに大きな変化はありません。この点を踏まえ、基本的な対策を網羅的に行うことが重要となります。一方で、マルウェア感染の被害をゼロにすることが難しい点も受け入れる必要があります。万一マルウェア感染が発生した場合にはその事実にいち早く気づき、適切な対処が行える体制を構築していくことが重要です。

43


[Column3] 戦略的な Computer Security Incident Response Team(CSIRT)構築のために

情報セキュリティー事故が頻繁にメディアで取り上げられる昨今、情報セキュリティーに関する横断的な組織として Computer Security Incident Response Team (CSIRT)の構築が各社で進んでいます。

しかしながら、自社における CSIRT の必要性を十分に検討せずに組織化したがために実態は CSIRT としての十分な機能を果たせていないケースがあるのも事実です。アルフレッド・D・チャンドラーの「組織は戦略に従う」（“Strategy and Structure” 1962）という著名な言葉にもあるように、果たすべき目的やその必要性が明確でない組織は、企業全体としての戦略に準ずることのない意義をなさないものになりかねません。

本コラムでは、IBM が CSIRT 構築の支援を行った経験を参考に CSIRT を戦略的かつ成熟度の高い組織となるためのポイントを示します。

CSIRTを構築する際は下記の５つの枠組みに関して検討し、戦略に沿った組織となるよう定義していきます。

1. ミッションステートメントの定義

自社の CSIRTに期待されることを明確にする。

組織としての将来ビジョンや目的、目標など、自社における CSIRT のあるべき姿をしっかりと関係者間で認識を合わせましょう。

ここがおろそかになると、持つべき機能や役割、必要なリソースなどについて、整合が取れていない組織となってしまいます。

2. サービスを提供する対象および範囲の定義

サービスを提供する対象および範囲を定義する。

利害関係者を明確にした上で、CSIRTがサービスを提供する対象ならびに範囲を明確にしましょう。

特に、CSIRTの立ち上げ当初から広範囲でサービスの提供をすることは困難です。ミッションステートメントとして定義した内容を踏まえ、対象とする情報、システム、会社や部署などの優先度をつけた上で、サービス提供範囲を定義し、スモールスタートでサービスを提供していくことも検討しましょう。

3. 提供するサービスの定義

平常時および有事において、CSIRTが提供するサービスや運用を定義する。

CSIRTが提供するサービスならびに必要な機能を定義し、実際の運用を検討しましょう。

特に有事の際には効率的な対応が求められるため、対応フローや報告書などの関連帳票はもちろん、判断基準や決定責任者についても定める必要があります。

サービスを提供する際に連携する組織を明確にする。

どのような CSIRTを組織するのかにも依存しますが、CSIRTが提供するサービスは様々であり、例えば、「情報セキュリティー・インシデント発生時の対応」はもちろん、「システムログの定常監視」や「情報セキュリティー教育」、「情報セキュリティー監査」、「情報セキュリティ

44


ーに関する IR 活動」なども考えられます。しかし、CSIRTが組織内のリソースで全てのサービスを提供するのは困難です。そのため、迅速かつ適切に CSIRT がサービスを提供するために、連携すべき組織を予め明確に定めておきましょう。

4. 必要なリソースの定義

組織が活動するために必要なリソース（人、物、金、情報）を確保する。

CSIRTが充実したサービス内容を提供するために必要なリソースを確保しましょう。

特に、CSIRT が提供するサービスに必要なスキルをメンバーが保持しているとは限りません。そのため、CSIRTメンバーのスキルアップ計画はもちろん、外部ベンダーなどの社外リソースの活用、また、それらに必要な予算についても検討しましょう。

5. 自社内およびサービス提供範囲における CSIRTの位置付けや権限の定義

CSIRTの存在意義や役割、必要な権限および適切な組織内の位置付けを周知する。

１～４で定めた内容を踏まえ、CSIRTがサービスを提供するために最適な組織内の位置付けや権限、責任などを定め、関係者に周知徹底を図りましょう。

特に、CSIRTは企業がビジネスを行う上で目立つ組織ではないものの、重要な役割を担う組織です。

自社内含めた関係者にCSIRTの存在意義や役割、責任などをしっかりと周知しておくことで、有事の際には関係者が協力的かつ能動的に対応するようになることが期待できます。

これら５つの枠組みは相互関係にあるため、網羅的かつ整合性を持って検討することが重要です。特に、「CSIRT」が保持するべき機能や提供サービスなどは明確には定義されておらず、また、その役割についてもまだまだ認知されていないのが実状です。そのため、５つの枠組みを検討する際にも細かな点で認識の相違が生じやすくなります。

以下に、CSIRTを構築するにあたって、認識に乖離が生じやすい例を示します。

CSIRT の役割は、「事故発生時」に限るのか、もしくは、事故が発生していない「平常時」も含むのか。また、「事故発生時」は、具体的にどの時点からを言うのか。

サービスを提供する先は、自社のみなのか、グループ会社までを含むのか。グループ会社は、どの範囲（例えば持ち株比率など）までなのか。

また、SOC(Security Operation Center)は、システムログなどを定常監視し、インシデント発生の兆候をいち早く把握する機能は有しますが、インシデントの原因調査や具体的対応などについては各社各様です。そのため、役割および責任範囲を明確にする必要があります。

昨今の情報セキュリティーにおける脅威やリスクに対しては、組織およびグループ企業横断での CSIRT

を構築することが有用ですが、企業によっては企業文化や業種の特性から全社横断での組織化が困難な場合もあります。そのため、CSIRTの必要性や目的、役割などについてしっかりと関係者間で認識を合わせ、「企業におけるビジネス活動と整合性を図った上での戦略的な CSIRT」の構築を図っていくことが重要なのです。

公開サーバーに対する攻撃の動向

45


3 公開サーバーに対する攻撃の動向

2016 年上半期も公開サーバーが影響を受ける新たな脆弱性が多数公開されました。Joomlaなどのコンテンツ・マネージメント・システム(CMS)の脆弱性に対する攻撃や、Apache Commons Collectionsライブラリーの脆弱性に対する攻撃は、脆弱性や攻撃手法が公開された直後より確認されている状況であることを 2015 年下半期のレポートで報告しましたが、2016 年上半期も攻撃が継続している状況です。 Apache Struts2 については新たな脆弱性が公開され、この脆弱性への攻撃も公開直後より確認しています。

ここでは、2016 年上半期に Tokyo SOC で確認した公開サーバーに対する攻撃の動向につい

て解説します。

3.1 JBoss に対する攻撃

2016 年 3 月に Cisco 社の脅威研究部門であるTalos がランサムウェア「SamSam」の拡散が行われていることを報告しました 14。ランサムウェア「SamSam」の詳細については、「2.3.1 ランサムウェア」にて説明していますが、Cisco 社の報告によると、「SamSam」は主にヘルスケア業界をターゲットして行われており、拡散の足がかりとして、JBoss

の脆弱性(CVE-2010-0738)を悪用しているとされています。

JBoss の脆弱性 (CVE-2010-0738)は、Red Hat

JBoss Enterprise Application Platformの特定のバージョンに存在するセキュリティーの制限を回避可能な脆弱性で、2010年に公開・修正されています。こ

の脆弱性を悪用可能な攻撃コードが公開されており、脆弱性の存在する JBossに対して利用することで悪意あるコードが実行可能です。

Tokyo SOC ではこの JBoss の脆弱性(CVE-2010-0738)の悪用を試みる通信を継続して検知しています。図 34は、IBM SOCにおける JBoss

の脆弱性(CVE-2010-0738)に対する攻撃の検知状況です。

14 Cisco: Cisco Talos Blog: SamSam: The Doctor Will See You,

After He Pays The Ransom http://blog.talosintel.com/2016/03/samsam-ransomware.html


46


2016年 1月はほぼ検知がなかったものの、3月にやや検知が増加し、5 月 7 日と 5 月 21 日にそれぞれ 1

日で約 1,500 件の検知が Tokyo SOC で確認されています。通信内容の多くはサーバー情報を取得しようとする調査行為となっていますが、中には不正なファイルをサーバー上に配置しようとする試みも含まれています。

「SamSam」に関しては、主にヘルスケア業界をターゲットとして行われていたと報告されているため、インターネット全体で攻撃行為が行われていたものではないと考えられます。そのため、IBM SOCで検知のあった攻撃がランサムウェア「SamSam」の拡散を意図したものかどうかは不明ですが、2010年の比較的古

い脆弱性が 2016 年になって再び検知が増加しており、また特に Cisco社が「SamSam」に関する情報を公開した前後に件数が増加していることから、公開情報を元にJBossの脆弱性を調査する行為が増加したのではないかと推測されます。攻撃の送信元の多くは、Amazon Web Service等のクラウドのホストからとなっています。

Red Hat JBoss Enterprise Application Platformで公開サーバーを運用している環境においては、本脆弱性が修正された最新のバージョンを利用しているか確認いただくことを推奨します。

図 34 JBossの脆弱性(CVE-2010-0738)に対する攻撃の検知状況 (IBM SOC調べ 2015年 6月 1日～2016年 6月 30日検知総数:26,914)

0

500

1,000

1,500

2,000

2,500

3,000

2015

年6月

2015

年6月

2015

年7月

2015

年8月

2015

年8月

2015

年9月

2015

年10

月

2015

年10

月

2015

年11

月

2015

年12

月

2015

年12

月

2016

年1月

2016

年2月

2016

年2月

2016

年3月

2016

年4月

2016

年5月

2016

年5月

2016

年6月

IBM SOC全体 Tokyo SOC


47


3.2 Joomla に対する攻撃

Joomlaの脆弱性(CVE-2015-8562)は、2015年 12月15日に公開され、その翌日に最初の攻撃が検知されていたことを 2015 年下半期の本レポート 15で取り上げました。また、本脆弱性は攻撃者がサーバーをコントロールできる可能性がある脆弱性であるため、散発的に多くの攻撃者が次々と攻撃を実施している状況である点をお伝えしました。

その後 2016 年上半期もこの傾向は継続し、攻撃の件数は増加しています。図 35 は 2016 年上半期の

Tokyo SOC における Joomla の脆弱性(CVE-2015-8562)に対する攻撃の検知状況です。

15 IBM: 2015 年下半期 Tokyo SOC レポート「Joomla に対する攻撃」 P.41 http://www.ibm.com/services/jp/ja/it-services/soc-report/

2016年 1月より徐々に増加し、2016年 5月には多い日で 1日に約 4,500件の攻撃を検知しています。検知の多くは脆弱性の有無を調査するための探索行為と考えられます。コラム 4 でもご紹介しているとおり、

CMS の脆弱性は近年攻撃者に狙われやすい傾向にあり、Joomlaについても積極的に狙われている状況であると考えられます。

図 35 Joomlaの脆弱性(CVE-2015-8562)に対する攻撃の検知状況 (Tokyo SOC調べ 2016年 1月 1日～2016年 6月 30日検知総数: 140,368)

0

500

1,000

1,500

2,000

2,500

3,000

3,500

4,000

4,500

5,000

2016

/1/1

2016

/1/1

1

2016

/1/2

1

2016

/1/3

1

2016

/2/1

0

2016

/2/2

0

2016

/3/1

2016

/3/1

1

2016

/3/2

1

2016

/3/3

1

2016

/4/1

0

2016

/4/2

0

2016

/4/3

0

2016

/5/1

0

2016

/5/2

0

2016

/5/3

0

2016

/6/9

2016

/6/1

9

2016

/6/2

9


48


3.3 Apache Commons

Collectionsライブラリーに対

する攻撃

2015年 11月に Apache Commons Collectionsライブラリーのデシリアライズ(deserialize)処理において任意のコードを実行できる可能性のある脆弱性 16が公開されました。

2015 年下半期の本レポートにて IBM SOC 全体での検知状況を紹介しました。その中で、2015年末時点では日本国内の組織に対する攻撃の検知はほぼない状況であることを記載していますが、2016年上半期には

主に中国等の東アジアの国の IP アドレスを送信元とする日本国内の組織に対する攻撃が複数観測されています。図 36は Tokyo SOCにおける Apache Commons

Collections ライブラリーの脆弱性に対する攻撃の検知状況です。

16 JVN: JVNVU#94276522: Apache Commons Collections ライブラリのデシリアライズ処理に脆弱性https://jvn.jp/vu/JVNVU94276522/

本脆弱性については脆弱性公開当初より攻撃可能な実証コードが公開されており、現在でも件数は多くないものの攻撃を意図した通信が発生している状況となっています。

本脆弱性に対する攻撃を行うためには、通常インターネットには公開することのない管理用ポートを利用しなければいけないことや、管理者ユーザーなどの

認証後の URLにアクセスが必要であることから、実際の影響範囲は限定的であると考えられますが、意図せずこのような管理用ポートがインターネットに公開されていないか、また、管理者ユーザーに推測が容易なパスワードが使用されていないか、今一度確認していただくことを推奨いたします。

図 36 Apache Commons Collectionsライブラリーの脆弱性に対する攻撃の検知状況 (Tokyo SOC調べ 2015年 11月 18日～2016年 6月 30日検知総数: 218)

0

5

10

15

20

25

30

35

40

45

2015

/11/

19

2015

/11/

29

2015

/12/

9

2015

/12/

19

2015

/12/

29

2016

/1/8

2016

/1/1

8

2016

/1/2

8

2016

/2/7

2016

/2/1

7

2016

/2/2

7

2016

/3/8

2016

/3/1

8

2016

/3/2

8

2016

/4/7

2016

/4/1

7

2016

/4/2

7

2016

/5/7

2016

/5/1

7

2016

/5/2

7

2016

/6/6

2016

/6/1

6

2016

/6/2

6


49


3.4 Apache Struts2 に対する

攻撃

Tokyo SOC Report 17でもお知らせしたとおり、Tokyo SOC では国内の複数の環境において、Apache

Struts2 の脆弱性(CVE-2016-3081/S2-032)を悪用する攻撃と考えられる通信が発生していることを確認しています。

本脆弱性は、Dynamic Method Invocation(DMI)が有効となっている Apache Struts2 において、"method:"

プレフィックスに指定されたパラメータを OGNL 式として処理する際のチェックに不備があり、サーバー上で任意のコードが実行される可能性があるものです。18 19 20

攻撃検証コードが既に公開されており、脆弱性を悪用する不正なリクエストが送られた場合にはシステム上で悪意あるコードが実行されたり、アプリケーションがクラッシュしたりする可能性があります。

Tokyo SOC における Apache Struts2 の脆弱性(CVE-2016-3081/S2-032)に対する攻撃検知数の推移を図 37に示します。

17IBM: Tokyo SOC Report https://www.ibm.com/blogs/tokyo-soc/struts2_cve-2016-3081 18S2-032 Apache Struts 2 Documentation Apache Software Foundation https://cwiki.apache.org/confluence/display/WW/S2-032 19IBM: Apache Struts Dynamic Method Invocation code execution Vulnerability Report https://exchange.xforce.ibmcloud.com/vulnerabilities/112528 20IBM: Apache Struts2 Remote Code Execution https://exchange.xforce.ibmcloud.com/collection/Apache-Struts2-Remote-Code-Execution-0901b4d5c6b43c368d5023ea66021

dc4

0

50

100

150

200

250

300

350

400

2016

/4/2

6

2016

/4/2

9

2016

/5/2

2016

/5/5

2016

/5/8

2016

/5/1

1

2016

/5/1

4

2016

/5/1

7

2016

/5/2

0

2016

/5/2

3

2016

/5/2

6

2016

/5/2

9

2016

/6/1

2016

/6/4

2016

/6/7

2016

/6/1

0

2016

/6/1

3

2016

/6/1

6

2016

/6/1

9

2016

/6/2

2

2016

/6/2

5

2016

/6/2

8

図 37 Apache Struts2の脆弱性(CVE-2016-3081/S2-032)に対する攻撃の検知状況 (Tokyo SOC調べ 2016年 4月 26日～2016年 6月 30日検知総数: 1,169)


50


4 月 26 日より本脆弱性を狙ったと考えられる通信を検知し、5 月下旬から 6 月初頭にかけて比較的多くの攻撃を検知しています。主な攻撃の送信元 IPアドレスの国としては、中国、韓国等の東アジアの国となっていました。

本脆弱性の影響を受けるバージョン上で DMI が有効になっているシステムを利用している場合は、修正済みのバージョンへアップデートするか、DMIを使用していない場合は無効にする 21等の対策を実施してください。

また、Apache Struts2 に関しては、2016 年 6 月にREST Pluginを使用している場合に影響を受ける新た

な脆弱性(CVE-2016-4438/S2-037) 22も公開されています。該当の製品を使用している場合は、あわせて修正バージョンへのアップデート等を検討してください。

21Action Configuration https://struts.apache.org/docs/action-configuration.html#ActionConfiguration-DynamicMethodInvocation 22S2-037 - Apache Struts 2 Documentation - Apache Software Foundation https://cwiki.apache.org/confluence/display/WW/S2-037


51


3.5 今期話題になったその他の

脆弱性と攻撃検知状況

2016 年上半期に話題となったその他の脆弱性について、以下に脆弱性の概要と Tokyo SOC での検知状況をお知らせします。

Cisco ASA の脆弱性(CVE-2016-1287)

2016年 2月に Cisco ASA の IKEv1 および IKEv2

の処理においてバッファオーバーフローを引き起こす脆弱性 23が公開されました。特殊に細工された UDP

パケットを脆弱性のあるCisco ASAに送信することで、Cisco ASA が再起動したり、システム上で悪意あるコードが実行される可能性があります。本脆弱性の公開を受け、IBM のセキュリティー研究開発部門 X-Force

は脅威に対する警戒レベルを示す AlertCon を 2 に引き上げ、注意喚起を行っていました。

Tokyo SOC では本脆弱性を悪用する攻撃の検知は確認されていませんが、脆弱性の詳細に関する情報が公開されているため、該当の製品を使用している場合はアップデートの実施を推奨します。

GNU C ライブラリー (glibc) の脆弱性

(CVE-2015-7547)

2016 年 2 月に GNU C ライブラリー (glibc) の

getaddrinfo 関数においてDNS問い合わせの際にスタックベースのオーバーフローを引き起こす脆弱性 24が公開されました。glibc 2.9 以降の全てのバージョンが影響を受けるもので、脆弱性を持つシステムにおいて、アプリケーションが不正な DNS サーバーから特殊な形式なレスポンスを受け取った場合、システム上で悪意あるコードが実行されたり、アプリケーションがクラッシュしたりする可能性があります。また、脆弱性を利用してアプリケーションをクラッシュする攻撃検証コードが公開されていますが、任意のコードを実行する攻撃検証コードは確認されていません。

Tokyo SOC では本脆弱性を悪用する攻撃の検知は確認されていません。

OpenSSL 1.0.1 および 1.0.2 の脆弱性

(CVE-2016-0800)

本脆弱性は「DROWN」25という名称がつけられており、SSLv2 を有効にしているサーバーと SSL/TLS

通信を行っている場合に、セッションが復号され、秘匿された通信内容が盗聴される可能性があります。[3]

脆弱性の存在する OpenSSL のバージョンおよび影響を受ける条件は以下の通りです。

【脆弱性の存在するバージョン】

OpenSSL 1.0.1r、およびそれ以前

OpenSSL 1.0.2f、およびそれ以前

【影響を受ける条件】

1. SSL/TLS通信を行っているクライアントと

サーバー間の通信を、攻撃者が中継できる状態にあること

2. サーバーが SSLv2を有効にしていること。

または、SSLv2を有効にしている別のサーバーと秘密鍵を共有していること

Tokyo SOC では本脆弱性を悪用する攻撃の検知は確認されていませんが、1995 年 2 月以来、非推奨のプロトコルとされている SSLv2 で強度の弱い暗号方式を利用しているサーバーが複数存在していることが確認されています。図 38は、鍵長が 56bit未満の暗号を使用する SSLv2 を利用したセッションの検知数の推移です。

23Cisco: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability https://tools.cisco.com/security/center/content/CiscoSecurity

Advisory/cisco-sa-20160210-asa-ike 24Google: Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow

https://googleonlinesecurity.blogspot.jp/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html 25DROWN Attack

https://drownattack.com/


52


このように、より多くのユーザーがサービスを確実に使用できるようにするなどの理由で、現在でもSSLv2 は多くのサーバー上でサポートされている状況です。しかし、SSLv2は「DROWN」以外にも多くの脆弱性が報告されており、既に非推奨の技術となっています。自社のサーバーで SSLv2をサポートしている場合は、IPAからリリースされている「SSL/TLS暗号設定ガイドライン～安全なウェブサイトのために（暗号設定対策編）～26」等を参照し、適切な方式を選択することを推奨します。

ImageMagick の脆弱性(CVE-2016-3714)

2016年 5月に、画像処理ツール ImageMagickにおいて、不正なファイルを ImageMagickが処理する際に任意のコマンドが実行可能な脆弱性 27 28が公開されました。脆弱性の存在する ImageMagickを使用している

Webサイトでは、悪意あるコンテンツのアップロード等によって、システム上で悪意あるコードが実行されたり、アプリケーションがクラッシュしたりする可能性があります。本脆弱性は「ImageTragick」という名称がつけられており、発見者によって攻撃検証コードが既に公開されています。

Tokyo SOC では本脆弱性を悪用する攻撃の検知は確認されていません。

26情報処理推進機構: SSL/TLS暗号設定ガイドライン～安全なウ

ェブサイトのために（暗号設定対策編）～ https://www.ipa.go.jp/security/vuln/ssl_crypt_config.html 27ImageTragick

https://imagetragick.com/ 28JPCERT コーディネーションセンター: ImageMagick の脆弱性 (CVE-2016-3714) に関する注意喚起

http://www.jpcert.or.jp/at/2016/at160021.html

図 38 鍵長が 56bit未満の暗号を使用する SSLv2を利用したセッションの検知数の推移 (Tokyo SOC調べ 2016年 3月 10日～2016年 6月 30日)

0

500

1,000

1,500

2,000

2,500

2016

/3/1

0

2016

/3/1

5

2016

/3/2

0

2016

/3/2

5

2016

/3/3

0

2016

/4/4

2016

/4/9

2016

/4/1

4

2016

/4/1

9

2016

/4/2

4

2016

/4/2

9

2016

/5/4

2016

/5/9

2016

/5/1

4

2016

/5/1

9

2016

/5/2

4

2016

/5/2

9

2016

/6/3

2016

/6/8

2016

/6/1

3

2016

/6/1

8

2016

/6/2

3

2016

/6/2

8


53


0

100,000

200,000

300,000

400,000

500,000

600,000

700,000

1分未満 1分以上1日未満 1日以上30日未満 30日以上

3.6 攻撃送信元 IP アドレスの

分析

攻撃者は公開サーバーに対して攻撃をするとき、自分が直接操作するホストではなく踏み台となる第三者のホストを利用するのが一般的とされています。このような踏み台となるホストはボットネットのような仕組みによって攻撃者が容易に確保・破棄できると言われていますが、踏み台となるホストも有限だと考えられるため、可能な限り継続的に利用されるのではとも考えられます。本節では Tokyo SOC で検知した公開サーバーに対する攻撃のイベントをもとに、攻撃の送信元となる IP アドレスについてどのような傾向があるのかについて解説します。

同じ IP アドレスが観測される期間

2016年上半期に Tokyo SOCで検知した公開サーバーに対する攻撃のイベントから、誤検知などのイベントを除外した結果、1,285,685件の送信元 IPアドレスが確認できました。イベントの除外では脆弱性診断などの通信を検知してしまったイベントやコンテンツ・デリバリー・ネットワークを経由してアクセスされた時に発生したイベント、さらに監視対象の内部ネットワークで発生した業務通信などと考えられるイベントを対象としました。

同じ送信元 IP アドレスからは複数回イベントを検知している場合が多いため、検知された最初のイベントと最後のイベントの時間の差をその IP アドレスの活動期間としました。1 分未満・1 分以上 1 日未満・1

日以上 30日未満・30日以上と活動期間に応じて 4つのグループにわけて、それぞれのグループの IPアドレスの数を図 39にグラフで示しています。

図では 1日未満のグループ、特に 1分未満の件数が多く出ていることがわかります。この 1分未満のグループと 1 分以上 1 日未満のグループの 2 つで全体の66.8%を占めており、半分以上の IPアドレスは調査した期間の 6ヶ月のうち 1日未満しか観測されていなかったことがわかりました。しかし一方で 1日以上観測されている IPアドレスも全体の 33.2%となっており、30 日以上活動している IP アドレスも全体の 18.4%ありました。長期間にわたって活動している IPアドレスは動的なアドレス割り当てによって別のホストに切り替わっている可能性もありますが、検知している環境やイベントの種類を分析した結果、少なくとも 70%以上の IP アドレスは同じホストが継続して使われていると推定されました。このことから、短期的にしか活動しないホストが多いものの、長期的に攻撃を継続するホストも一定数存在していることが明らかになりました。

図 39 同じ送信元 IPアドレスからイベントが観測された期間の内訳

(Tokyo SOC調べ 2016年 1月 1日～2016年 6月 30日)


54


活動期間別に検知されるイベント種別の違い

図 40では図 39と同じように活動期間別にグループをわけた時、あるイベントが検知された IPアドレスの割合を示しています。検知したイベントの種類は以下の 6種類に分類しました。

サーバーに対する一般的な攻撃

◆ スキャン: サーバーやサービスの応答を確認する行為を検知したイベント。ポートスキャンや Pingスイープなど。

◆ サーバーへの攻撃(Web 以外): 各種サーバーのミドルウェア(Web, DB)やWeb以外のサービス(メール、リモートアクセスなど)に対する攻撃を検知したイベント。

Webアプリケーションに対する攻撃

◆ SQL Injection: SQL インジェクション全般を検知したイベント。

◆ XSS: クロスサイトスクリプティング全般を検知したイベント。

◆ RFI: リモート・ファイル・インククードに関連するイベント。

◆ その他の攻撃: 上記以外でWeb アプリケーションに関連する攻撃を検知したイベント。Web アプリケーション・フレームワークの脆弱性を狙った攻撃など。

図を見るとイベントの種類によって検知しているIPアドレスの割合が異なり、さらに活動期間別にわけたグループによって検知している割合が異なることがわかります。しかし、それぞれの期間別で極端な差がでているわけではなく、基本的な傾向はどの期間でもあまり変化がないことが分かります。このことから攻撃者が踏み台のホストを利用する際、事前に利用期間を考慮せずに、どのホストでも同じように攻撃に利用しているのではないかということが推察されます。

図 40 活動期間別の IPアドレスから送信されたイベントの種類 (Tokyo SOC調べ 2016年 1月 1日～2016年 6月 30日)

0%

10%

20%

30%

40%

50%

60%

70%

スキャンサーバへの攻撃

(Web以外)SQL Injection XSS RFI その他の攻撃(Web)

1分未満 1分以上1日未満 1日以上30日未満 30日以上


55


考察

ボットネットのような被害ホストの管理システムが使われるようになったことで、踏み台となるホストはほとんどが使い捨てのように利用されると考えられてきました。しかし、今回の調査では 1日以上利用され続けるホストも全体の 30%以上あり、特に 30 日以上活動している IP アドレスも全体の 18%存在しています。また、活動期間の長さにかかわらず踏み台となるホストの活動傾向は大きく変わらないということがわかりました。

これらの結果から、使い始めた踏み台ホストは攻撃者の制御下にある限り同じように使い続ける、という戦略なのではないかと推察できます。これまで攻撃者は攻撃用の踏み台ホストを意図的に切り替えながら防御側を撹乱しているという可能性が考えられてきましたが、図 40で示したように活動期間によって攻撃の傾向が変化がほとんど見られなかったことから、異なるグループに属しているホストも同じような振る舞いをしていると考えられます。そのため、活動期間が短かったホストは DHCPなどの動的なアドレス割り当てによって IPアドレスが変化しやすいPCなどが多く、活動期間が長かったホストはサーバーや 24時間電源を切らずに動作する共用 PCなどが多かったと考えられます。それぞれ攻撃者が意図して活動期間を制御したわけではなく、踏み台としているホストの性質によって同じ IPアドレスで活動する期間が変わったのではないか、と推察されます。

以上のような推察にもとづいて IP アドレスのブラックリスト方式による防御方法の戦略を考えることができます。ブラックリスト方式による防御方法とは、IDS/IPS をはじめとするセキュリティー製品から発されるイベントに含まれる IP アドレスを登録して遮断・監視する方法を指します。この場合、本節で示したデータから考えると、初めて観測された IPアドレスの半分以上は再度出現しないため、早急に IPアドレスを登録して遮断・監視する効果は少ないと言えます。しかし一方で、1日以上観測された IPアドレスの 55%

は 30日以降にも観測されていました。このことから、一定期間以上観測される攻撃の送信元 IP アドレスについては、ブラックリスト方式で対応する意味があると考えられます。


56


3.7 公開サーバーに対する

攻撃動向のまとめ

2016 年上半期は、2015 年に公開された Apache

Commons Collections ライブラリーや Joomla の脆弱性に対する攻撃が日本国内でも引き続き確認されていることに加え、Apache Struts2の新たな脆弱性に対する攻撃も確認されています。脆弱性公開から実際の攻撃発生までの期間が短期間になっているという状況に変わりはありません。一方、ランサムウェア「SamSam」の事例では６年前に公表された脆弱性が悪用されました。「SamSam」は主にヘルスケア業界を狙う攻撃でしたが、このように特定のターゲットを意識した攻撃では、新しい脆弱性だけでなく、古い脆弱性が狙われる場合もあります。今回取り上げたこれらの脆弱性に対する攻撃は IDS/IPSで検知・防御することが可能です。脆弱性公開後のパッチ適用や修正バージョンへのバージョンアップを行うまでの暫定対策として、さらに、「SamSam」の事例のように公開から時間がたった脆弱性が、修正されないまま放置され

てしまう可能性を考慮した対策としても、IDS/IPS によって検知・防御を行うことは有効な対策と言えます。また、自組織のシステムのアセット管理や定期的な

脆弱性診断によって最新の状況を把握し、脆弱性公開時の迅速な対応が行える体制となっていることが重要です。

公開サーバーへの攻撃元の IP アドレスを分析した結果、同一の IPアドレスからの攻撃が継続する期間が1日未満であるものが全体の約 66%である一方で、30

日以上も同一の IP アドレスから攻撃が継続的に行われているものが約 18%あることも判明しました。1日以上攻撃が継続した IP アドレスのうちの半分以上は30 日を超えて攻撃が継続していることもわかっています。このことから、ブラックリスト方式で攻撃の送信元 IP アドレスをフィルタリングすることも一定の効果が見込めることがわかりました。

57


[Column4] WordPress サイトの改ざん事例紹介 (2016 年上半期の Emergency Response Service(ERS)活動から)

IBM Emergency Response Service(ERS)はさまざまな種類のセキュリティー・インシデントのための緊急対応サービスです。本コラムでは、2016年上半期に IBM ERSチームが対応したWordPressで構築されたサイトの改ざん事例を紹介します。WordPressを使ったWebサイト構築は非常に一般的になっています。その普及と比例して、攻撃を受ける可能性も上がってきています。WordPress、Drupal、Joomlaなどを代表とする Content Management System(CMS)は脆弱性が多く報告される傾向にあり、またアップデートが容易ではないため古いバージョンが使われていることが多いなどの理由により、攻撃対象として狙われやすい傾向にあります。本コラムでは代表的な CMSである WordPress が実際に攻撃された例を紹介し、その攻撃経路と対策についてご紹介いたします。

◆ 有効なユーザーIDの流出

一般に攻撃者はまず標的の脆弱性や設定の不備を入念に調査し、攻撃の足がかりを探します。この事例では、有効なユーザーIDが流出するというWordPress の設定の不備があり、その機能が悪用されました。設定に不備のあるWordPressでは、URLに"?author="とその後ろに数字を加えて対象のサイトにアクセスすると、その数字に対応した有効なユーザーIDが表示されます。さらに数字を一つずつ増やして順にアクセスすることで簡単に大量の有効なユーザーIDを取り出すことが可能になります。攻撃者はこうしてユーザーIDのリストを作成しました。

◆ リバースブルートフォース攻撃

次に攻撃者は、その有効なユーザーIDのうち簡単に推測できるパスワードを設定しているユーザーIDを特定することに成功し、有効な IDとそのパスワードの組み合わせを入手しました。すなわち、攻撃者が自由にコンテンツを編集できる状態になってしまいました。

一般に、有効な IDが流出しても辞書攻撃などでパスワードを入手することは困難です。ほとんどの認証

システムがアカウントロック機能を有しており、複数回のログイン失敗を検出するとアカウントがロック

や認証結果の返信に時間をかけるようなモードに切り替わり、それ以上辞書攻撃を続けることができない

からです。しかし大量のユーザーID が流出した場合、リバースブルートフォース攻撃が可能になります。

この攻撃では同じパスワードを複数のユーザーIDに順に試みることで、アカウントロック機能を回避する

ことができます。これにより安易なパスワードを設定しているユーザーが一人でもいれば、簡単にログイ

ン可能な IDとパスワードの組を見つけることができます。実際の攻撃では両方の方法が組み合わされるこ

とが多いようです。すなわち、攻撃者はアカウントがロックされる試行回数を特定したのち、ロックされ

る寸前までログイン試行を繰り返す処理を複数のユーザーIDに順に行います。

58


◆ バックドアの設置

次に攻撃者は、バックドア付きのファイル wp-control.php をアップロードしました。このようなバック

ドア付きのコンテンツは、よく利用される手法です。このバックドアにより、攻撃者はログオンをするこ

となくコンテンツを簡単に更新できるようになりました。つまり、この時点で該当のユーザーIDがロック

されても攻撃者は別の経路で侵入できます。

◆ Web閲覧者をマルウェア配布サイトに誘導

バックドアの設置が終われば、侵入は完了です。攻撃者は目的に応じて様々なことができるようになり

ました。この事例では、攻撃者の目的はマルウェアを閲覧者のコンピューターにインストールする事だっ

たようです。そのために、攻撃者はマルウェア配布サイトへの転送を行う JavaScript をページに埋め込み

ました。図 41に実際に用いられたマルウェア転送サイトの画面イメージを示しました。転送先にはセキュ

リティー修復ツールと称するプログラムのダウンロードページが存在していました。ただこのページでは

脆弱性を使った強制ダウンロードや自動インストールは実施されていなかったため、閲覧者が意図的にリ

ンクをクリックし、ダウンロード、インストールを実施しなければインストールされないものでした。

図 41 確認したリダイレクト先のサイト

59


◆ スパムメール中継サーバーの作成

攻撃者のもう一つの目的はスパムメールの中継サーバーの作成でした。攻撃者は WordPress の Plugin

ディレクトリー配下に、既存のメール送信プラグインの phpファイルを元に作成した phpページを組み込んでいました。このページに対してスパム送信先リストをアップロードすると、自動的にスパムメールを送信する機能を備えていました。攻撃者がスパム送信サービス用の URLとして別の攻撃者（スパムメール送信業者）に利用させていたと考えられます。調査の結果、ロシア、マケドニア、ウクライナ、ポーランド、リトアニア、ハンガリー、ブラジル、ベトナム、インドネシア、タイからアクセスされていたことが確認できました。

図 42に回収できたスパムメールを一部示しました。これはメールのスプールディレクトリーに保存されていたものです。この文面を見れば分かるように、海外向けのスパムメールでした。送信者のメールアドレスは、侵入されたWebサイトのドメイン名を使い、自動的に生成したと推測される欧米系の名前を使っていました。Fromに実在のメールアドレスは含まれていませんでした。

◆ 対策 1: ユーザーIDの不正取得防止

この一連の改ざん事例の再発を防ぐための対策を紹介します。まず、攻撃のきっかけとなった/?author=xx

による有効なユーザーID の取得を回避することが重要です。これは author.php テンプレートファイルに、

図 43 の php コードを追加することで容易に対策できます。author.php ファイルが存在しない場合はこの

内容だけのファイルを新規作成します。これにより要求に/?author=xxが含まれていた場合、トップページ

にリダイレクトされることで有効なユーザーIDの確認ができなくなります。

To: ●●●997@■■■■■■■■■■.com Subject: Do you hear me calling, sweetie Date: Fri, 10 Jun 2016 03:37:39 +0900 From: Stacy Miller <stacy_miller@●●●●●●●●●●●.jp > Message-ID: <0c1c82515ffdab389852fb25be6a1c25@www.●●●●●●●●●●●.jp> Leave your salty (um on my lips!) I think I gonna achieve climax very fast! I know great warmup secrets! [http://▲▲▲▲▲▲▲▲▲▲.com/list.php?j=▼▼▼▼▼▼▼▼▼▼] Who can compare with this? Plz do it as soon as possible!

図 42 攻撃者が送信したメールの抜粋

<?php wp_redirect(home_url()); exit(); ?>

図 43 該当 webサイトへのアクセスをトップページに転送する phpコード

60


◆ 対策 2: パスワードの複雑化

今回の事例でわかったように、安易なパスワードは簡単に突破されてしまいます。有効な対策は複雑なパスワードをユーザーに設定させることです。WordPress はプラグインを用いて機能を増強することができ、パスワード管理を強化するプラグインも幾つか存在します。例えば、「Login Security Solution」はパスワードの最小の長さ設定、使用不可能な単語の設定に加えて、ブログの内容やユーザーデータに類似するパスワードを禁止することができます。

パスワードの複雑さに関する設定はパスワードポリシーと呼ばれます。「パスワードの最小の長さ」や「最小文字種類数」はブルートフォース攻撃に対しては効果的です。大量のユーザーIDが流出した場合のリバースブルートフォース攻撃に対しては「使用不可能な単語」が効果的です。例えば「password」や地名や俳優の名前やアカウント名などを禁止します。

一方、パスワードポリシーを厳しくするとむしろセキュリティレベルが下がることもあります。Bill

Pattersonが報告した有名な例では、毎月のパスワード変更の強制と直近に使った幾つかのパスワードを禁

止した結果、ユーザーはパスワード変更を繰り返して履歴を溢れさせて、自分の好みの安易なパスワード

を連続して使うようになってしまいました。このようにパスワードの複雑さと利便性はトレードオフの関

係にあり、適切に設定するには想定する攻撃の他にユーザーの振る舞いも考慮する必要があります。

◆ 対策 3: インシデントの早期発見方法

攻撃者に改ざんされた場合、それを早期に発見できれば被害を最小限に留めることができます。簡単な方法としてはログの監視があげられます。インシデント対応専門家ではなくとも、サーバーのログから不審な行為を比較的簡単に発見することができます。

表 1 に、この webサイトのサーバーでの 1日ごとの各ログファイルのサイズをまとめました。一見すれ

ばすぐに 3日目に突然ログのファイルサイズが非常に大きくなったことが分かります。

通常、いわゆる本番環境では、日常の作業はそれほど大きな違いが見られないことがほとんどです。つ

まりログファイルサイズも大きな変化はありません。このケースでは、攻撃者がコンテンツのアップロー

ドなどを実施することでログファイルサイズが突然大きくなっています。つまり、ログファイルサイズが

大きく変わった場合は何かが行われた、と推測することができます。

表 1. ログサイズの比較

61


[Column5] IBM社内にて Capture The Flag開催

IBM Security事業部主催の社内イベントとして、2016年5月24日～6月30日の期間、Capture The Flag（CTF）

を開催しました。CTFとはセキュリティー技術を競うイベントで、世界中で毎週のようにオンライン大会が

開催されています。近年、CTFはセキュリティー人材教育の一環としても注目されています。今回のイベン

トは IBM社内の人材交流やセキュリティーへの関心を高めることを目的とし、IBM及びグループ会社の技術

職社員を中心に965名が参加した大会となりました。

◆ CTFイベント概要

参加者はWeb / Network / Binary / Miscの 4つのカテゴリーに分類された 49問の問題に挑戦し、問題に正解することにより得られる Flag（答えとなる文字列）を専用ポータル・サイトから提出することで得点を得ることができます。大会期間中は 24時間オンラインで参加することが可能でしたので、業務の空き時間を利用しての参加や、休日に自宅から参戦する参加者もいました。それぞれのカテゴリーの概要は下記のとおりです。

問題カテゴリー

1. Network

パケット・キャプチャー・ファイルを解析して Flagを探し出す問題

2. Web

SQLインジェクションなどのWebアプリケーションの脆弱性を利用して隠された Flagを取得する問題

3. Binary

Binary ファイルを解析して Flag を得る、もしくは脆弱性を発見し、リモート・サーバーに侵入して Flagを取得する問題

4. Misc

上記に当てはまらないセキュリティーに関連する様々な問題

図 44 専用ポータル・サイトにて掲示された問題一覧

62


◆ CTFイベントにおける反響

大会期間中コミュニティー・サイトをオープンし、初級者向けに問題に取り組むためのツールをインストールした OS イメージの提供やチュートリアルの配信もおこないました。また大会終了後は、参加者同士による答え合わせや教え合える場を提供しました。主体的に自部署内にて CTF勉強会を開催する参加者も現れ、大会終了後も約１ヶ月大会システムを継続的に稼働させるほどの大反響でした。

アンケート結果より、参加者の 98.2%は今回の社内イベントで初めて CTF を経験し、60.7%の参加者が再度同じようなイベントがあれば参加したいと回答しています。「攻撃手法を学ぶことで、脆弱性がどれほど深刻か理解を深めることができた」、「人と競争ができることと、調べて試して正解に辿りつくプロセスが楽しめ、自然と勉強になった」など、CTF における教育効果に対してポジティブな意見や、「大学 1 年生のときにインテル 8086・モトローラ 68020 のアセンブラを学んで以来の記憶がよみがえり、懐かしさを感じさせてくれました。」、「定年退職までもう間もなくなので、次回に参加できるかどうかわかりませんが、楽しみにしています。」など、弊社内のシニア技術者層にも好評でした。

当初の目的だった IBM 社内の人材交流やセキュリティーへの関心を高めることに関して、一定の成果を挙げることができたと感じています。昨今セキュリティー人材の不足がしきりに言われていますが、こういったイベントを通して得られたことは、セキュリティーに関する教育や人材育成に予想以上の効果があるということです。CTFのオンライン大会の多くは費用がかからず、無料で参加可能です。社内で CTF大会を企画して実行するにはある程度のコストがかかるため、まずはこのような大会から参加してみてはいかがでしょうか。

図 45 Binaryカテゴリーの問題

63


4 おわりに

今期は高危険度のセキュリティー・インシデントの通知のほとんどが「クライアント PC に対する攻撃」という結果となりました。緊急対応サービス（ERS）を要請いただくケースも続いており、Webサイトやメールを経由した攻撃の被害に遭っている企業が少なくないことを実感します。

発端はクライアント PC の感染であっても、それが大きなセキュリティー・インシデントに発展した場合、情報資産の漏洩・棄損や金銭的損失などの直接的な被害だけでなく、同時に加害リスクの発生についても考慮する必要があり、企業価値に与えるインパクトは相当なものになります。このような背景から、セキュリティーが経営上の課題であるという考え方はもはや当たり前のものとなったと言えるでしょう。

では、経営課題としてセキュリティー・リスクに向き合うとはどういうことでしょうか。ここでは「直面しているセキュリティー・リスクを認識しているか」、「認識したセキュリティー・リスクを適切にコントロールしているか」、そして「セキュリティーという経営課題に関して社会やステークホルダーへの説明責任を果たしているか」の三点を挙げたいと思います。この「Tokyo SOC情報分析レポート」は前者二点の一助となるよう、マクロ的な視点に軸を置きつつ、攻撃の動向の「今」をお伝えしています。認識したリスクをコントロールするために資源を適切に配置することは経営上の判断になりますが、ではその対応について必要な情報を開示し、説明責任を果たすという点についてはどうでしょうか。

経済産業省から公開された「サイバーセキュリティ経営ガイドライン（2016）」や NISC 策定の「サイバーセキュリティ 2015」、「同 2016」において、セキュリティー・リスクやその対策、またインシデントの可能性について開示していくべきという動きが出ています。2015年 3月に公開された NISCの「企業の情報セキュリティリスク開示に関する調査」によると、日経

225 社の有価証券報告書「事業等のリスク」においてサイバーセキュリティー・リスクについての開示項目があった企業は 136社（約 60%）に達しています。具体的な記載内容を確認するため 2015 年度について更に調べてみたところ、開示企業数は 139社で微増である一方、全く言及していない企業は 48 社（約 20%）、言及していてもリスクについて「予期せぬ事態」と記載するにとどまっている企業が 14 社（約 10%）という状況でした。開示内容について特徴的であったのが、サイバーセキュリティー・リスクについて言及している企業の約 70%が想定被害として「個人情報漏洩」を挙げているものの、「技術情報流出」に触れている企業は約 15%、自社のセキュリティー事件・事故についてまで言及しているケースは記載内容から推察できるものも含めると 4社という点でした。もちろん、記載がないからと言って情報開示をしていないと判断するのは早計ですし、開示によってリスクを高める情報に言及すべきでないことは言うまでもありませんが、業種によって内容にかなりの違いがあることからも、サイバーセキュリティー・リスクの捉え方にはまだまだ温度差があることがわかります。

セキュリティー・リスクの開示については、統一の指針がないため企業側はどのような内容を開示すべきか判断しかねている状況かもしれません。一方、情報の利用者から見ると、開示内容に幅があったり企業固有の問題に触れていなかったりで、経営への影響を判断するには十分ではないと言えるのが現状です。今後は、規定やガイドがより具体的になっている米国の例などを参考にしつつ議論が深まるものと考えられます。「セキュリティーは経営課題」と言っても、「リスク

の認識」、「コントロール」、「説明責任」と複数の層において対応が必要です。企業としての取り組みを明らかにし、セキュリティー・インシデント発生時の説明責任を果たすためにも、上記三点を経営主導で実施していくことが必要であると言えるでしょう。

セキュリティー・リスクを開示しないことが将来のリスクにならないよう、開示に対する姿勢を明確にしていくことも経営層の重要なミッションであると考えます。

64


執筆者

鳥谷部彰則（エグゼクティブ・サマリー、おわりに）

猪股秀樹（1章、2章、3章）

窪田豪史、柳優、茂木大輔、岡邦彦（2章）

水谷正慶（3章、コラム 2）

野ヶ山尊秀（コラム 1）

古澤宏宜（コラム 3）

遠藤暁（コラム 4）

菅賢太郎（コラム 5）

協力

鈴木貴

2016年 9月 8日発行

日本アイ・ビー・エム株式会社

マネージド・セキュリティー・サービス

©Copyright IBM Japan, Ltd. 2016

IBM、IBMロゴ、ibm.com、Ahead of the Threatは、世界の多くの国で登録された International Business Machines Corporationの商標です。他

の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、

www.ibm.com/legal/copytrade.shtmlをご覧ください。

MicrosoftおよびWindowsは Microsoft Corporation の米国およびその他の国における商標です。

Javaおよびすべての Java関連の商標およびロゴは Oracleやその関連会社の米国およびその他の国における商標または登録商標です。

その他、本レポートに記載されている商品・サービス名は、各社の商標または登録商標です。

【注意】

●本レポートの情報は 2016年 9月 8日時点のものです。内容は事前の予告なしに変更する場合があります。

●本レポートで紹介した対策は、利用環境によって他のシステムへ影響を及ぼす恐れがあります。また、攻撃は日々変化して

おり、必要となる対策もそれに応じて変化するため、記載内容の対策が将来にわたって効果があるとは限りません。対策を

行う際には十分注意の上、自己責任で行ってください。なお、IBMはこれらの対策の効果を保証するものではありません

BrusselsTokyo

Brisbane

Atlanta

Hortolândia

Boulder

Toronto

Bangalore

IBM Security Operation Center (SOC)

Wrocław

Heredia

2016年上半期 tokyo soc 情報分析レポート

Documents