川口、官房長官就任
皆さんこんにちは、川口です。先月からセキュリティ監視センターJSOC(Japan Security Operation Center)のセキュリティアナリストのリーダーの座を後進に譲り、JSOCの官房長官として、JSOCセンター長を補佐するお仕事に就くことになりました。
今回は、そんな私が対応することになった標的型メール攻撃の顛末(てんまつ)を取り上げます。厳密にいうと今回届いたメールは、JSOCにとっては、脅威となり得る「標的型」ではありません。しかし受け取る組織によっては十分標的型メール攻撃となり得る内容ですので、紹介したいと思います。
ある日JSOCに届いた1通の標的型メール
5月のある日、JSOCで仕事をしていたところ、1人のセキュリティアナリストが話しかけてきました。
「サポート窓口に変なメールが来ているぞ。ヤバイと思うので見てほしい」
すぐに確認したところ、JSOCのお客様のサポート窓口のメールアドレスに、以下のようなメールが届いていました。
このメールは、ある官公庁の内部連絡のメールを装っています。
ラックのお客様サポート窓口のメールアドレスは、JSOCのサービスを契約しているお客様のみに知らされており、一般には公開されていません。JSOCのお客様の中には官公庁もいますが、通常このような文面をやり取りすることはありません。それで、メールをチェックしていたセキュリティアナリストが不審に思い、エスカレーションを行ってきたのです。
添付されているファイルは、一見まともなzipファイルを装っていますが、zipファイルを展開するとexeファイルが出てきます。この時点では、exeファイルに対しウイルス対策ソフトは反応しませんでしたが、明らかに怪しいファイルおよびメールであることが分かります。すぐに私は、JSOCに対する標的型メール攻撃と認識して対応を開始しました。
JSOCメンバーへの警告作業は意外とアナログ?
まず、現在業務に携わっているJSOCのメンバーがこのメールを開かないように、全員に「メールの添付ファイルを開かないこと」「メールを削除すること」を口頭で呼びかけました。メールを受信したのはJSOCの中にいるメンバーだけだったので、声をかけて回ることはそれほど大変な作業ではありませんでした。
次に、JSOCのセンター長に連絡。メールを確認したとき、センター長は会議中だったため、電話で「不審なメールが来ていること」「JSOC内での対応を開始すること」を報告しました。これ以降、複数のメンバーに指示を出しつつ、関係各所に連絡を取る作業を同時並行で進めました。
この時点で、JSOC内部にいないメンバーへも警告を行いました。JSOCへ入室する扉に届いたメールを印刷し、注意書きを加えて貼り付けました。インパクトがあるので、こういう時は手書きの文字がお勧めです。
こうして対応を行っているその最中にも次々と、他の標的型メールが届きました。結局この日は合計4通のメールがJSOCに届きました。そのたびにメンバーへの注意喚起を行っていたので、扉にはたくさん紙が貼りつけられることになりました。
社内の危機管理委員会にも「標的型メール攻撃を確認したこと」「JSOC内での被害はないこと」「その他の調査を継続していること」を報告しました。その後、危機管理委員会から全社員に対して、メールおよび社内ポータルで注意喚起を行いました。同時に、ラック社内のサイバー救急センター、サイバーセキュリティ研究所にも連絡し、送付されたマルウェアの解析を依頼しました。
添付ファイルの正体は? 通信先はどこ?
サイバーセキュリティ研究所での解析と並行して、セキュリティアナリストもマルウェアの解析に取り掛かりました。
サイバーセキュリティ研究所で行う詳細な解析とは異なり、セキュリティアナリストによる解析の焦点は「そのマルウェアがどのような通信を行うか?」という一点にあります。この解析結果を、アクセス制御機器でのフィルタリングや通信を行った端末の特定に活用するためです。
解析の結果、この実行ファイルは、ある中国のサーバの80/tcpに対し特殊なプロトコルを使って通信することが分かりました。早速JSOCのファイアウォールのログを確認したところ、そのサーバへの通信は発生していないことが判明し、ほっと一安心です。こんな事態に備えて、社内に疑似的なメール攻撃を仕掛け、一人一人が巧妙な嘘メールを判別できるようにするトレーニング「ITセキュリティ予防接種」を何度も行ってきた甲斐がありました。
次に、JSOCのお客様全体のログを調査し、同じサーバに通信しているパソコンがないか調査を行いました。
すると、何とラック社内からの通信があったではありませんか。JSOCではラックホールディングスグループの社内の通信も監視しているのです。一瞬ドキッとしながら確認してみると、マルウェアの解析を依頼している研究所のメンバーのIPアドレスでした。研究所が調査してくれていたのですね。セキュリティ企業ということもあり、このような紛らわしい通信を発生させる場合もありますが、それもご愛嬌(あいきょう)です(笑)。
社内での対応が落ち着いてきたころに、ISOG-J(日本セキュリティオペレーション事業者協議会、Information Security Operation providers Group Japan)へ情報共有のために連絡し、IPAやJPCERT/CCへの届け出も行いました。
標的型メールについては事例が集まりにくいこともあり、決定的な対策を打つのは非常に難しいのが現状です。少しでも情報を共有し、事例を蓄積していくことが日本全体の対応能力向上のために必要でしょう。
【関連リンク】
ISOG-J
http://www.jnsa.org/isog-j/index.html
情報窃取を目的として特定の組織に送られる不審なメール「標的型攻撃メール」(IPA)
http://www.ipa.go.jp/security/virus/fushin110.html
実例に見る標的型メールの特徴
今回は3日間で計6通の標的型メールを受信しました。これら標的型メールの特徴を整理してみます。
まず、メールの文面には以下のような内容が記載されていました。
- 予算関係
- 大臣の行動予定
- 原子力発電所のニュース
- 異動の挨拶
メールの差出人として、ある官公庁の人物とメールアドレスが記載されています。そしてメール本文は、おそらく、実際にある組織間でやり取りされている本当の文面をコピーしたのではないかと推測しています。
つまり、ある組織のパソコンに感染したマルウェアがメールの本文や添付ファイルを盗み出し、それを悪用してメールを送信している可能性が高いと考えられます。実在する人物を名乗って、本物の文面で送られてくるメールを、それに関係する組織が受信してしまえば、添付ファイルを開く確率はぐっと高くなるでしょう。
JSOCのファイアウォールとメールサーバのログを確認したところ、6通のメールはすべて異なるIPアドレスから送られていることが分かりました。そのうちの1つは韓国のIPアドレス、残りの5つは日本のIPアドレスです。この送信元IPアドレスがどのような素性のものかは不明ですが、おそらくはマルウェアに感染したパソコンが操られているのでしょう。
添付ファイルは、いずれもzip化されたexeファイルでした。受信した時点では、ウイルス対策ソフトではこれらのファイルはまったく検知できませんでした。わざわざウイルス対策ソフトで検知されないマルウェアを作り、送信しているとしか考えられません。今回は運よくexeファイルだったこともあり、実害はありませんでしたが、何らかのソフトウェアの脆弱性を狙ったものであったらと思うとぞっとします。
6つの添付ファイルのうち3つは、パスワード付きzipファイルでした。パスワード付きzipの添付ファイルは、途中のメールサーバのウイルスチェックを抜けてユーザーの手元に届いてしまいます。ウイルス対策の多層防御の壁が、パスワード付きzipで次々に破られてしまったのです。
また、exeファイルは実行時にVMWare Toolsの有無を確認しており、VMwareで構築したいくつかの検証環境ではマルウェアが動作せず、解析に手間取りました。
見事(?)実行されたマルウェアは、前述の通り中国のサーバと通信を行います。この通信は80/tcpを使いますが、HTTPプロトコルでの通信ではありません。サーバとの通信は特殊なプロトコルで行われており、どのような内容がやり取りされているかをネットワーク通信から読み取ることはできませんでした。
標的型メール攻撃の注意喚起はどうあるべきか
今回は、届いた標的型メールの本文がJSOCの業務と関係ないものだったため、幸いなことに問題はありませんでした。しかし、通常の業務を装ったメールの場合、例えばセキュリティインシデントに関するメールを装ったものだった場合、被害を受ける可能性が高くなることを心配しています。
また、今回は紙やメールを使って社内に警告を行いましたが、同様の標的型メールが継続して行われた場合、その警告の効果が薄れてしまわないかも危惧しています。パッチマネジメントやウイルス対策ソフト、ファイアウォールなどを活用したシステム的な対策とともに、普段からのトレーニングを通して、人の耐性を高めていかなければならないと考えています。
今回の標的型メール攻撃の対応を通して一番悩んだことは、「どの範囲まで情報共有や注意喚起をすればいいのか?」ということでした。
今回の標的型メールは、JSOCと直接契約関係にあるお客様から送られたものではありませんから、契約上はメールの中身についての保護義務はありません。とはいえ、メールの本文や送信者名を騙られた方にとっては、保護すべき情報が含まれています。「このような文面でメールが来ているから気を付けてください」と注意喚起を行うことは、その組織の機密情報を外部に公開してしまうことになります。
特に、インターネットに対し公に情報発信を行う場合は、今回のコラムのように、該当の組織が分からないようにするしかありません。さらにいうと、注意喚起を行うことそれ自体が、攻撃者に対し「攻撃には対応している」と宣言しているようなものです。そもそも、情報公開を行うべきか否かという根本的なところについても検討が必要です。
ちょうど、セキュリティ業界全体での動きも始まりました。経済産業省主催の「サイバーセキュリティと経済 研究会」で、「標的型サイバー攻撃対策」の方向性に関する議論が行われたようです。ラックも加入しているISOG-Jの取り組みに関する発表も行われました。まだまだ手探り状態ではありますが、日本全体での取り組みとなりそうです。興味のある方は以下の配布資料を参照してください。
【関連リンク】
サイバーセキュリティと経済 研究会(第5回)‐配付資料
http://www.meti.go.jp/committee/kenkyukai/shoujo/cyber_security/005_haifu.html
資料4 標的型攻撃へのISOG-Jの取り組み
http://www.meti.go.jp/committee/kenkyukai/shoujo/cyber_security/005_04_00.pdf
日本全体のことを考えた場合、業界団体やセキュリティ関係者との情報共有が欠かせません。しかも、対応にはスピードが求められるため、こまめに共有を行わないとスムーズにはいかないでしょう。そのためには技術的な課題や政治的な課題もありますが、最も重要なことは「誰となら共有できるか、誰なら信頼できるか」ということです。大事な人と人との繋がりを作るために、今日も飲みに行くのでした。
Profile
川口 洋(かわぐち ひろし)
株式会社ラック
チーフエバンジェリスト兼シニアセキュリティアナリスト
CISSP
ラック入社後、IDSやファイアウォールなどの運用・管理業務をへて、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。
アナリストリーダとして、セキュリティイベントの分析とともに、IDS/IPSに適用するJSOCオリジナルシグネチャ(JSIG)の作成、チューニングを実施し、監視サービスの技術面のコントロールを行う。
現在、JSOCチーフエバンジェリストとしてJSOC全体の技術面をコントロールし、監視報告会、セミナー講師など対外的な活動も行う。また、YouTubeのlaccotvにて、「川口洋のつぶやき」に出演中。
- 「DNS通信」記録していますか?――万一に備えたDNSクエリログの保存方法
- Web広告からのマルウエア感染「Malvertising」にどう対処すべきか
- 中の人が振り返る「Hardening 10 ValueChain」――学びにつながった「トラブルの数々」とは
- 無慈悲な専門家チーム「kuromame6」の暗躍に負けず勝利をつかんだチームは?
- 外部リソースの活用もポイントに、「Hardening 10 MarketPlace」開催
- Hardening Projectから派生した「MINI Hardening Project」に行ってみた!
- 「これさえしておけば助かったのに……」を避けるため、今すぐ確認すべき7項目
- アップデート機能を悪用した攻撃に対抗セヨ!
- 工夫、工夫そして工夫――Hardening 10 APAC“運営”レポート
- ウイルスとは言い切れない“悪意のあるソフトウェア”
- 2013年のセキュリティインシデントを振り返る
- ここが変だよ、そのWeb改ざん対応
- きっかけは不正侵入――私がセキュリティ業界に足を踏み入れたワケ
- CMSが狙われる3つの理由
- FacebookやApple、MSまで……Javaの脆弱性を狙う攻撃の手口
- Hardening One、8時間に渡る戦いの結果は?
- そのときStarBEDが動いた――「Hardening One」の夜明け前
- ロシアでわしも考えた
- 実録、「Hardening Zero」の舞台裏
- ちょっと変わったSQLインジェクション
- 官民連携の情報共有を真面目に考える
- アプリケーションサーバの脆弱性にご注意を
- IPv6、6つの悩み事
- スパムが吹けば薬局がもうかる
- JSOCに飛び込んできた不審なメール――これが標的型攻撃の実態だ
- 東日本大震災、そのときJSOCは
- ペニーオークションのセキュリティを斬る
- 2010年、5つの思い出――Gumblarからキャンプまで
- 9・18事件にみる7つの誤解
- 曇りのち晴れとなるか? クラウド環境のセキュリティ
- Webを見るだけで――ここまできたiPhoneの脅威
- 不安が残る、アドビの「脆弱性直しました」
- ともだち373人できるかな――インターネットメッセンジャーセキュリティ定点観測
- 実録・4大データベースへの直接攻撃
- Gumblar、いま注目すべきは名前ではなく“事象”
- Gumblarがあぶり出す 「空虚なセキュリティ対策」
- 新春早々の「Gumblar一問一答」
- 実はBlasterやNetsky並み?静かにはびこる“Gumblar”
- ECサイトソフトウェアはなぜ更新されないのか
- 狙われるphpMyAdmin、攻撃のきっかけは?
- 学生の未来に期待する夏
- 米韓へのDoS攻撃に見る、検知と防御の考え方
- 分かっちゃいるけど難しい、アカウント情報盗用ボット対策
- 狙われる甘〜いTomcat
- 表裏一体、あっちのリアルとこっちのサイバー
- 世間の認識と脅威レベルのギャップ――XSSは本当に危ないか?
- 急増したSQLインジェクション、McColo遮断の影響は
- ○×表の真実:「検知できる」ってどういうこと?
- ところで、パッケージアプリのセキュリティは?
- レッツ、登壇――アウトプットのひとつのかたち
Copyright © ITmedia, Inc. All Rights Reserved.