“Look, do you want to have a defensible network or not? (防御可能なネットワークを持ちたいとは思いませんか？)” という有名なツイートをご存知でしょうか。このフレーズは、何年経っても私の中で印象に残っています。140文字以内の文章でありながら、「適切な技術、見通し、プロセス、進行、トレーニング、役員の理解、人事構成、ポリシー、コントロール、ログなどを持っていて、攻撃から自身のネットワークを守ることができますか?」という問いを本質的に意味しています。
フィッシング攻撃の被害を軽減するためにできることはたくさんあります。しかし、どの情報セキュリティに関しても、リスクを完全に排除することはできません。したがって、フィッシングに引っかかってしまった時のための戦略を準備することが非常に重要です。それでは、企業を狙ったフィッシング攻撃をを受けた場合はどうすればよいのでしょうか? フィッシング攻撃が発生したときに対処すべき14のポイントを紹介します。
フィッシング攻撃を受けた時の対処法:14のポイント
1. インシデント対応手順書を作成する
フィッシング攻撃のインシデント対応手順を決めていますか? インシデントが起きた想定の訓練をして、どれだけスムーズに対処できるか検証したことはありますか? 実際のインシデントを確認した時、マニュアルがあれば即座に対応することができ、誰に、どのような、いつ、どこで、インシデントが起きたのかを把握する必要があります。
2. ヘッダー全文と添付ファイル付きのメールのコピーを入手する
フィッシング詐欺メールのインシデント対応の一環として、メールのルーティング情報などが記載されたヘッダー全文が表示されているかを確認する必要があります。Outlookの場合は、メールのルーティング情報を確認するために、メッセージのプロパティを見る必要があります。次に、メッセージの送信元のIPアドレスを確認してください。ほとんどの場合、メッセージの送信botとして機能しているエンドユーザーのデスクトップPC、または脆弱性のあるサーバなど、何らかの侵害されたコンピュータからのものである可能性が高いです。いずれにしても、これらすべての情報を把握しておくと役に立ちます。
3. 脅威情報を得るためにインターネットで検索する
脅威情報や検証サイトはたくさんあります。任意のURL、添付ファイルなどをwww.virustotal.comなどのサンドボックスや検証サイトに載せてください。個人的には、www.hybrid-analysis.comを推奨します。また、IPVoid.comのような情報サイトでドメイン、IPアドレス等を調査することができます。さらに、IPアドレス・ホスト名・URL・ファイルなど、あらゆる情報をブラウザで検索してください。
ただし、実際に悪質なサイトに接続しないよう注意が必要です。ブラウザにIPアドレスを直接貼り付けると、URLに代わってそのIPアドレスに接続してしまいます。やってしまいがちなミスですが、非常に危険です。これを避けるために、IPアドレスを引用符（””）で囲み、ブラウザではフレーズ検索にしてください。
4. メール受信者に状況を聞く
見落としがちになるシンプルなステップです。エンドユーザーを無視してはいけません。すべてのメール受信者に、何が起こったのか、何を見たのか、そしてフィッシング攻撃の前後で何か不審なことがあったかどうかをたずねてください。
5. メールフィルタを設定して類似のメッセージをブロックする
他のユーザーが同じ攻撃を受けることを防ぐために、フィルタリングできる属性をメールの中から探してください。場合によっては、メールの差出人(From)、件名(Subject)などの欄が変更される場合があります。ある程度変わらないであろう共通項を探してください。正規表現を使ったブラックリスト(単語一致を検証するフィルタ)は長期的な解決策ではありませんが、短期的には他のメッセージの侵入を防ぐことができます。
6. 社内システムの検索を始める
ファイアウォールのログにあるメール・URL・添付ファイルなどから、不審なIPアドレスなどをすべて検索して、社内ネットワークからこれらのIPアドレスに向かうトラフィックが出ていないかを確認してください。また、フィッシング攻撃者のドメインの中には、数分ごとにIPアドレスを変更するものがあることもあります。そのため、あらかじめすべてのDNSリクエストを記録しておき、DNSログから任意のホストがそれらを参照していないかを確認してください。
DNS検索が行われたときにどのワークステーションが、そのIPアドレスを持っていたかを確認するために、DHCPログを検索する必要があることを覚えておいてください。もしDHCPログがなければ、SplunkまたはElasticsearch/Logstash/Kibana (ELK) などを使うことを推奨します。
7. プロキシまたは外部へのwebログを確認する
BlueCoatやWebSenseなどのプロキシを使用している場合は、ログを検索して任意のユーザーが当該サイトや他の特徴的なURLにアクセスしたかどうかを確かめてください。あるいは、ファイアウォールのアウトバウンド通信をすべてログに記録している場合、そのサイトが実行されているサーバのIPアドレスをチェックしてください。
フィッシング攻撃の詳細については、弊社のフィッシング報告書をダウンロードしてください。
8. メールサーバのログを確認する
メールサーバのログを検索して、どのユーザーがメッセージを受信したかを確認してください。可能であれば、メッセージID・送信元IP・差出人(From)・件名(Subject)・添付ファイル名などで検索してください。
9. DNSログを確認する
DNSトラフィックを記録することや、BINDでDNSログを有効にすることは、決して難しいことではありません。有効にすることで、これらのログをSplunkにインポートして、どのホストが悪質なドメインを参照したかを確認するクエリを実行することができます。
10. ログが保管されていることを確認する
重要なログの欠損は、インシデント調査を大きく遅らせてしまいます。DNS・DHCP・ファイアウォール・プロキシ・その他のログが上書きされないようにしてください。状況によっては、ログを保存して法的措置を取る必要があるかもしれません。インシデント対応手順には、これらの処置を含む必要があります。
11. 社内で事例を共有する
元シカゴ市長のエマニュエル氏の言葉で、次のフレーズをご存知でしょうか。「深刻な危機を無駄にしてはならない。この言葉の意味するところは、今までできなかったことができるチャンスだということです。」今後フィッシングのインシデント対応に成功した暁には、この言葉を思い出し、管理者やユーザーのセキュリティ意識を高める機会として活用してください。
結局のところ、学校でわざわざスタントマンを用いた交通安全教室を行うには理由があります。その危険性を目の当たりにした人は、「あれは私だったかもしれない！」と思わずにはいられないでしょう。社内のユーザーがインシデントを報告することは、決して恥ずべきことではありません。
12. 認証情報を変更する
フィッシング攻撃を受けたユーザーのパスワードは必ず変更してください。深刻な影響を受けていないと確信していたとしても、同様です。なぜなら、被害者の情報が一切漏えいしなかったという保証は何をしても得られないからです。
ユーザーの認証情報 (特にリモートアクセスに使用される情報) が漏えいした場合、後に攻撃者がOWAやVPNなどの正当なアクセス方法を使用する可能性があります。パスワードを変更した後、影響を受けたユーザーアカウントの活動を、インシデントの前後で一定期間確認してください。
13. 影響を受けたユーザーのアクティブなセッションをチェックする
フィッシング攻撃の一般的な手法は、VPNやCitrixなどの正規のアクセス方法によって、ネットワーク内の接続を維持して、データを流出し続けることです。攻撃を受けた後は、影響を受けたユーザーのリストを収集し、本来アクティブではないはずの接続が有効になっていないことを確認してください。
リモートアクセス方法のリストは作成していますよね？
14. 個々人の情報セキュリティ・リテラシーを向上させる
担当者の積極的な行動が求められます。メールを受け取って、「何かおかしいな...」と思ったことはありませんか? セキュリティ業界では、このような人は「情報セキュリティ・リテラシー」を持っている人と言われています。しかし、これは一朝一夕に身についたものではなく、時間をかけて受動的に積み上げてきたスキルです。パブロフの犬のような反応で反射的に受信トレイを開くのではなく、社内のユーザーが500ミリ秒でも一時停止して、「ちょっと待って...これはフィッシングかもしれない」と思ってくれたら最高だと思いませんか? フィッシング攻撃テストとセキュリティ意識向上トレーニングを活用しましょう。
防御可能なネットワークは実現できます。弊社はサイバーセキュリティのプロフェッショナルです。
注：この記事はThreatSim®ブログの記事を元にしています。ThreatSimは2015年10月にWombat Securityに買収されました。
