目次 |
原文のブログはこちらからご覧いただけます。
こうした状況では、弊社が「インシデント対応における 13 の大罪」と名付けた過ち、すなわち有事の際にインシデント対応担当者が犯しがちな重大な過ちのいくつかが生じやすくなります。これらの過ちはインシデント対応の取り組みをいたずらに妨げ、攻撃者に優位をもたらす恐れがあります。
このシリーズの第 1 部では、データ侵害への準備の際に犯されがちな最初の 4 つの「大罪」に焦点を当てていました。第 2 部となる今回は、準備後の段階、すなわち侵害がまさに進行している段階を扱いますが、ここでもさらなる過ちが生じる可能性があります。この見解は、合計 100 年分を超えるインシデント対応（IR）経験を持つ BlackBerry® サイバーセキュリティサービスのインシデント対応チームの知見に基づいています。
インシデント対応における第 5 の大罪：パニック、外部接続の切断、または時期尚早なシステム消去
この項目は IR における「罪」のリストの 5 番目に位置していますが、インシデント対応時には常に「パニックにならない」ことを第一に考える必要があります。しかし多くの場合、これは口で言うほど簡単ではありません。
「ハッキングされた」という言葉はしばしば恐怖感を引き起こし、その結果、今すぐにでも事態を収拾したいという思いが反射的に生じます。このような衝動に駆られることなく、次の行動を慎重に考える必要があります。
インシデント対応チームと CISO が下すべき大きな決定事項の 1 つは、接続性に関連しています。データ侵害が発生した際には、組織全体の接続を切断すべきでしょうか。時にはこれが必要な方策になることもありますが、大きな過ちにつながる場合もあります。どのような場合でも、この決定には細心の注意を払う必要があります。
考慮すべき重要ポイント：
- 組織全体の接続を切断すると、インシデント対応担当者は即座に大きなプレッシャーにさらされます。インターネットに安全に再接続するにあたっては、それらの担当者が a）環境内で影響を受けたすべてのシステムを把握し、b）アクティビティを分析し、c）マルウェアの動作を理解（およびブロック）し、d）初期侵入経路を特定していることが期待されますが、これらはすべて攻撃者を排除するための修復措置を講じながら実施する必要があります。
また、脅威アクターが組織の環境内で収集していた内部情報を用いて容易に再侵害することがないように、予防措置を講じる必要もあります。これは極めて難しい課題です。
- インシデントの規模、組織の環境、組織が投入できるリソースにもよりますが、接続切断から再接続までの作業には 24 時間体制で数週間を要する可能性があります。外部に面したアプリケーションが初期侵入経路となっている場合は、攻撃者がすぐに戻ってくることがないように、脆弱性に対処する修正を開発し、それをテストする作業も必要です。
- 組織はこのような潜在的なダウンタイムに耐えられるのでしょうか。また、会社として許容できるのでしょうか。売上、顧客、従業員、利益への影響は計り知れません。さらに、組織は風評リスクを考慮し、社内外のコミュニケーションを慎重に管理する必要もあります。
接続の遮断がこれほど大きな影響力を持つのであれば、組織がこの選択肢を取ることがあるのはなぜなのでしょうか。主な利点としては、接続を完全に遮断すると、外部の脅威アクターのアクセスを効果的に排除し、さらなるデータ窃取や破壊行為を予防できることが挙げられます。
- 攻撃者の行動を可視化し、その最終目標の可能性についての情報を十分に把握すれば、情報に基づいた決定を下せるようになります。インシデントを予防できなかった場合は、水平展開が行われる前に「ペイシェントゼロ」（初期侵入地点）でインシデントを正確に封じ込めるのが理想的な対応となりますが、脅威アクターが水平展開して追加のバックドアをドロップすると、この対応は途端に難しくなります。バックドアが複数ある場合、それは持続的標的型攻撃（APT）または国家的な攻撃を示唆している可能性があります。このとき、調査担当者が国家的な攻撃に精通しているなら、脅威アクターを発見したことを相手に知らせるような行動を取る前に、インシデントを体系的かつ完全に調査する必要があります。
一方、組織が人手によるランサムウェア攻撃に対処している場合は時間が最も重要となるため、迅速な行動が求められます。
社内チームが能力や経験に乏しく、各種の要因を考慮してこれらの厳しい判断を下せない場合には、なるべく早く（できれば侵害の発生前か、少なくとも発見された時点で）インシデント対応リテーナーを契約しましょう。こうすることで、サービスプロバイダがサービス水準合意（SLA）契約の範囲内で組織を支援し、初期対応の指針を示すことが保証されます。
インシデント対応中のシステム消去
他にパニックから行われがちなのが、影響を受けたシステムを即座に再イメージ化または消去することです。こうした対応はしばしば、「対象システム」上で何らかのコモディティマルウェアが検知された際のデフォルトポリシーとなっています。状況によっては、やはりこれも大きな過ちとなり得ます。たとえば、APT 攻撃が関与する重大インシデントの場合、感染ホストが再インストールまたは再イメージ化されると、貴重な証拠が失われてしまいます。
BlackBerry の IR チームは、IT チームが良かれと思ってフォレンジックエビデンスの取得前に再インストールを実施したがために、最終的に調査が行き詰まった事例を何度も目にしてきました。
侵害が判明したばかりの状況では、インシデント対応担当者は通常、特定のホストが初期侵入地点となったのかどうかや、攻撃者がどのように侵入したのか、あるいはそのホストが他のシステムへのピボット目的で利用されたのかどうかを判断できません。
ただし、このように「ペイシェントゼロ」と思われるホストを誤って時期尚早に再インストールしてしまった場合でも、幸いにも NetFlow ログが残っていれば、影響を受けた可能性のある他のシステムについての「最善の推測」を行うことは可能です。
インシデント対応アプローチの標準化
セキュリティチームは、IT チームが取るべき対応のアプローチを標準化する必要があります。多くの場合、これは特定のキーワードを定義することから始まります。「Mimikatz」、「Cobalt Strike」、「トロイの木馬」などがその例で、これらは検知の重大性を判断する上で役立ちます。
もう 1 つのベストプラクティスは、侵害されたサーバーの種類をキーワードと組み合わせて考えることです。たとえば、「トロイの木馬」がドメインコントローラとワークステーションの両方で検知された場合、これらの組み合わせのいずれかを優先します。
また、予備的なフォレンジックエビデンスをいつ取得し、運用をいつ再開するのかを明確に理解しておくことも必要です。確信が持てない場合は、システムを再イメージ化する前に常にフォレンジックエビデンスを取得しましょう。
アンチウイルスの検知結果を関連手法に紐付けるための非常に優れた方法として、Nextron 社のアンチウイルスイベントの分析チートシートが挙げられます。
最終的には、内部的な作業方法は導入中のセキュリティソフトウェアに依存します。
このチートシートは、あるイベントがインシデント対応活動を必要とするほど重大性が高いのかどうかや、マシンにインストールされているエンドポイント保護プラットフォーム（EPP）のアンチウイルス隔離で問題を十分緩和できるのかどうかをセキュリティチームが判断する上で、特に優れた概要を提示します。
たとえば、ドメインコントローラや環境内のサーバーで Mimikatz が検知された場合は、インシデント対応活動を即座に開始する必要があります。通常、このツールは組織に「無造作に転がっている」ものではないためです。ただし、ユーザーが管理者権限を持つクライアントシステム上で潜在的に望ましくないプログラムが検知された場合には、別の方法で問題を解決する必要があるかもしれません。
インシデント対応における第 6 の大罪：コミュニケーションチャネルに対する誤信
セキュリティインシデントに関するコミュニケーションは、通常は極めて機密性が高く、慎重に扱う必要があります。組織の対応計画を誤って攻撃者自身に開示することは、何としても避けなければなりません（ありえないことのようですが、これは実際に起こっています）。場合によっては、インシデントがインサイダー脅威に関連しているか、あるいは攻撃者が社内メールや Slack などのオンラインコラボレーションツールにアクセスできることもあります。この第 6 の「大罪」、すなわち通常のコミュニケーションチャネルが安全であると思い込むことは避けましょう。
その上で、インシデント対応時のチーム間のコミュニケーションには、帯域外の、暗号化された、信頼できる手段を採用する必要があることを意識してください。
また、弊社のインシデント対応チームは、インシデント中に管理者が認証情報などの機密情報を平文のメールで送信している様子を何度も目にしてきました。多くの場合、APT アクターはメールサーバーを完全に制御下に置き、ネットワークを監視して平文のトラフィックから認証情報を抽出しています。ある事例では、インシデント対応チームの復旧作業のために生成された認証情報が脅威アクターに再利用されていたこともあります。
重要なのは、暗号化されていないトラフィックが（それが内部トラフィックだったとしても）いかに脆弱であるかを理解することです。弊社の経験上、一部の高度な脅威アクターは、管理者や経営幹部などの重要な人材からのメールを監視したり、telnet などの安全でないプロトコルを介したファイアウォールログオンを監視したりしています。
インシデント対応では、詳細事項を必要最小限の範囲だけに知らせることも重要です。緊急連絡網を整備し、主にセキュリティ担当者、主要な管理者、法務担当者と情報を共有することを検討しましょう。インシデント中にできるだけ多くの支援を即座に求めたくなるのは自然な反応ですが、脅威アクターを警戒させないように日常業務を継続することを推奨します。また、インサイダー脅威がいつ発生するかを知ることはできないため、インシデントの対応は専門チームに任せるようにしましょう。
インシデント対応における第 7 の大罪：オンラインサービスへのサンプルのアップロード
特に APT に対処している場合、インシデント対応中に any.run や VirusTotal などの公開解析プラットフォームに未知のマルウェアサンプルをアップロードすることはリスクを伴います。これは重要なポイントです。というのも、マルウェアサンプルをアップロードする時点では、APT に対処していることがわかっていない場合があるためです。
以下の理由から、アップロードする内容には十分注意する必要があります。
APT は解析サイトにアップロードされたファイルのハッシュを監視しています。これは、攻撃者がキャンペーンごと、あるいは被害者ごとに一意のハッシュを生成することが多いためです。これらのグループから流出したメールによると、攻撃者は VirusTotal を積極的に監視し、ファイルがサイト上に存在するかどうかを調べることにより、自前のインプラント（システムに密かに埋め込まれるマルウェア）がいつアップロードされたかを把握しています。
マルウェアの構成情報には、ハードコードされたプロキシ認証情報やマシンのホスト名など、被害者の詳細情報が含まれていることがよくあります。また、マルウェアが使用するコマンドアンドコントロール（C2）サーバーから被害者自身へのつながりが見出せる場合もあります。たとえば、攻撃者が使用するドメインが、被害者のドメイン名をわずかに変えた名前になっていることがあります。
実行可能ファイルのハッシュが VirusTotal などのサイトに存在しないという事実は、そのファイルが一般的ではないことを示しているため、さらなる注意が必要となる場合があります。多くの場合、APT は運用上の予防措置の一環として、キャンペーンやクライアントごとに一意となるようにツールのハッシュを生成しています。
脅威グループが自前のツールのハッシュを VirusTotal で追跡していることは、WikiLeaks に掲載された Hacking Team 社の流出メールにはっきりと表れています。このサイトには、匿名の情報源からリークされたニュースや機密メディアが掲載されています。また報道によると、この Hacking Team という会社はイタリアの情報セキュリティ企業で、攻撃的な侵入・監視機能を販売していたとされています。
参考までに、当該の WikiLeaks ページを以下の図 1 に示します。ここでは「vt@hackingteam.com」というユーザーが、監視対象のハッシュが提供されたことを知らせる VirusTotal の通知を受信しています。
さらに、これが最新バージョンのインプラントかどうかを Hacking Team の他の関係者に尋ねている転送メールも確認できています。その一部を以下に示します。
“Questo e' roba nostra, fortunatamente solo Eset lo rileva come spyware generico (non come Davinci) e, se non vado errato, il submit viene proprio da loro. Guido puoi verificare da che cliente arriva? Domani comincia a lavorare sulla firma di eset e vediamo come si evolve la situazione: se rimane una signature isolata rilasciamo un minor upgrade, se la firma si propaga seguiamo il caso di "leak scout" gia' ben documentato sul documento ‘crisis procedure.’”
上記の翻訳：
“これは我々の製品ですが、幸い、スパイウェア一般として検知しているのは Eset だけです（Davinci とは異なり）。また、私の理解が正しければ、これは Eset から直接提供されています。
Guido さん、これがどの顧客からのものか調べられますか ?
明日から Eset のシグネチャに取り組み、様子を見ましょう。シグネチャが単独で残り続ける場合はマイナーアップグレードを公開し、シグネチャが増えた場合は、「危機管理手順」の文書にまとめられている「リークスカウト」のケースに従いましょう。”
このチームは、「スカウト」（偵察者）の存在が確認された場合に対応する危機管理手順を用意しているようです。また、どの「顧客」（つまり、自社の侵入ツールを使用しているクライアント）が VirusTotal にこのサンプルを提供したかを知りたがっています。これは、高度な脅威グループが積極的にオンライン投稿サイトを監視し、自前のインプラントを追跡しているという証拠です。インプラントを検知されたことがわかった場合、脅威アクターはそれを無効化してキャンペーンを停止するか、あるいはアップデートを配信し、インプラントができるだけ長い間「見過ごされる」ようにする可能性があります。
WikiLeaks に寄せられた情報の中でもう 1 つ興味深いのは、サポートチケットへの返信として外部の「顧客」に送信されたメールです。ここでは Marco Valleri という人物が、特定のインプラントが VirusTotal にアップロードされた経緯を説明した上で、当面は「標的」への攻撃を停止するよう次のように推奨しています。
“Vi preghiamo pertanto di non effettuare piu' alcun tentativo di infezione su questo target, di non utilizzare piu' il server FTP in questione e di dismettere l'anonymizer non appena tutti gli agenti ‘legittimi’ abbiano scaricato la nuova configurazione.”
上記の翻訳：
“したがって、今後はこの標的への感染は控えてください。また、問題の FTP は利用を停止し、すべての「正規」エージェントが新しい構成をダウンロードしたら、すぐにアノニマイザーを無効化してください。”
やはりこの例も、「ネットワーク防御の担当者と脅威アクターはいずれもオンラインのマルウェアデータベースを参照している」という重要な事実を明らかにしています。
ただし、信頼できる公開サービスでファイルのハッシュを調べ、その存在の有無を確認することは良い習慣です。弊社でも、通常は新たな調査の開始時に VirusTotal でハッシュを確認しています。このとき、初回のアップロード日がわずか数日前となっていることがよくあります。これは、お客様のセキュリティチームのメンバーがインシデントの調査中にファイルをアップロードした結果であることも少なくありません。
結論として、VirusTotal やその他のサービスにファイルをアップロードすると、特にインシデント中には以下のような望ましくない結果につながる場合があります。
- APT の事例では、脅威アクターが積極的な手段によって身を隠そうとする可能性があります。より深刻な場合には、さらなる破壊をもたらすか、抜き出しをエスカレートさせるか、あるいは未知のバックドアを一定期間密かに設置しようとする可能性もあります。
- 一部の脅威アクターは、マルウェアサンプルが公開リポジトリに提供された後、短期間でバックドアをまったく別の種類のものに変更し、TTP（戦術、技法、手順）を変えることで潜伏を続けようとしていました。また、検知されたことを悟った APT が身を隠すために休止状態に入り、のちに活動を再開することも多々あります。
- 組織がアップロードしたハッシュを研究者が発見した場合（ベンダーや研究者は、新規のサンプルや興味深いサンプルを探して VirusTotal を頻繁に調査しています）、組織のインシデントが公開ブログやニュースレポートのテーマとして取り上げられる可能性があります。情報が公開された時点で組織が侵害を把握できていなければ、準備不足のまま公式声明を発表することになる場合があります。
- 組織がアップロードしたマルウェアには、公開すべきではない「パーソナライズされた」構成までもが含まれている場合があります。ある事例では、企業のプロキシ用に構成されたユーザーアカウントがバックドアにハードコードされていました。また別の事例では、被害者のホスト名の文字列を付加することで感染チェーンを変化させるポリモーフィック型マルウェアも確認されています。
このように、オンラインポータルにマルウェアをアップロードする際には十分な注意を払い、適切な判断を下す必要があります。ただし、サンプルに特定の詳細情報が含まれておらず、また攻撃が完全に緩和されたことが確認できた後であれば、オンラインポータルにファイルをアップロードしてマルウェアを提供することを強く推奨します。これは脅威に関する私たちの集合知を強化し、コミュニティ全体を保護することにつながります。
インシデント対応における第 8 の大罪：コマンドアンドコントロールシステムに対する積極的介入
発生中の攻撃の種類にもよりますが、C2 サーバーに対して ping を実行したり、悪意のあるドメイン名を解決したりするといった積極的介入は、しばしばリスクを伴います。また、サーバーに対して攻撃的なツールを実行することは、それがインシデントの後であっても、組織やサーバーが位置している地域の規制に違反する可能性があります。さらに、脅威アクターは無実の第三者が所有するサーバーを侵害して悪用していることが多いため、C2 サーバーに対する攻撃的な行為は、正確には加害者ではなく別の被害者を罰することになる場合があります。
「nslookup」や「dig」などのツールで「evilsubdomain[.]evil[.]domain」を照会すると、適切な応答を返すために、その際のクエリは evil[.]domain ネームサーバーを管理している DNS サーバーへとリダイレクトされます。このとき、脅威グループがこのようなクエリを監視している可能性があります。そのため、脅威アクターが管理している可能性のある DNS サーバーに進んで接触することは避け、利用可能な DNS ログから解決先の IP を取得することを推奨します。あるいは、アクティビティがあった時点でログを記録していなかった場合は、パッシブ DNS サービスを利用しましょう。
APT はまた、リバースエンジニアやセキュリティアナリストに対し、脅威グループの情報を示唆するヒントを意図的に残すことでも知られています。たとえば、DNS Canary はバイナリサンプルの文字列に残された偽のドメインであり、不用心なアナリストがドメインを解決して IP を確認しようとすることを狙って、意図的にマルウェアに埋め込まれています。こうした例を踏まえると、特に高度な攻撃者が関与するインシデントに対処する際には、やはり C2 サーバーの情報はできる限り常に受動的な手段で調査する必要があります。
インシデント対応における第 9 の大罪：対応タイムラインに対する理解の欠如
高度な攻撃への対応では、タイミングが極めて重要です。水平展開を行う国家的な攻撃の場合はチームが対応に時間をかける必要がありますが、ランサムウェア攻撃の場合などには迅速な行動が求められます。組織がどれだけ速く対応できるかは、対処している状況や、チームの経験と専門知識に依存します。
サイバーセキュリティの「キルチェーン」を示した以下の図は、典型的な攻撃のタイムラインにおける主要なマイルストーンを表しています。この一連のイベントを理解すれば、攻撃者の活動や次に起こり得る行動をリアルタイムで把握できるようになるでしょう。攻撃者がどの段階に関与しており、また何を最終目標としているのかを把握することで、リスクに基づいたビジネス上の意思決定を適切に下すことが可能となります。
このモデルは、攻撃者が目標達成に向けて行うことが多い手順を示しているだけでなく、インシデント対応担当者がその時点で最適な方策を決定するために活用できる洞察も提供します。攻撃者が攻撃ライフサイクルの初期段階（キルチェーンのステージ 1 ～ 4）にある場合は、できる限り迅速な介入を試みるべきです。
検知の時点で攻撃者がすでにキルチェーンの後期の段階（水平展開の後）にある場合は、効果的な修復計画を策定・実行するために、インシデントの範囲を完全に把握する必要があります。また、APT に対処する場合は、あらかじめすべての介入行為を慎重に検討しておくことも必要です。
弊社の経験上、APT アクターは単一のアクセス手段には依拠しておらず、常に複数のバックドアを用意しています。 そのため、インシデント対応担当者は、インシデントの識別や範囲決定の段階ですべてのアクセス手段を特定するよう努め、その後で封じ込め措置を講じる必要があります。
これは経験がものを言うポイントです。経験豊富で信頼できる上級インシデント対応担当者を確保し、同一または類似のグループに対する過去の経験に基づくアドバイスを得ることは、組織にとって大きな強みとなります。こうした人材は、攻撃者が攻撃ライフサイクルのどの段階にあるかを把握し、キルチェーンのその段階に最適な方策を立てることができます。
修復段階の前に攻撃者のアクセス範囲を完全に把握できなければ、結果的にインシデント対応が失敗する恐れがあります。その場合、高度な脅威アクターはしばしば、検知されたことを悟った時点で一定期間身を隠します。この活動停止（あるいはステルス性の強化）期間は数日から数か月にわたることもあり、多くの場合はのちに第 2 または第 3 のバックドアによってアクセスが再確立され、活動が再開されます。この対策としては、まず可視性の向上を検討しましょう。これはインシデントの発見前に事前準備の一環として行っておくことが望ましいですが、インシデントの発生中に実施することもできます。これにより、高度な脅威アクターの活動をほぼリアルタイムで検知・追跡できるようになります。可視性を向上させる一般的な対策としては、たとえば以下が挙げられます。
環境全体での PowerShell ログ記録の有効化
影響を受けたシステムからのネットワークトラフィックのキャプチャ
AI 駆動型のエンドポイント検知/対処（EDR）の導入
まとめ
インシデント対応の初期段階は、組織にとってリスクの高い時期となります。また、これまでに述べた「大罪」、すなわち状況を悪化させ、場合によってはインシデントの被害を増大させる恐れのある過ちを避ける上で、極めて重要な時期でもあります。このシリーズの第 3 部では、インシデント対応における最後の 4 つの「大罪」として、インシデント後の復旧段階で起こり得る過ちに焦点を当てます。復旧時には何が忘れられがちなのか、そしてこれらの「罪深い」過失が時に、攻撃者と防御側のいたちごっこという悩ましい状況をどのように作り出すのか。そこには驚きの事実があるかもしれません。
次回の記事もぜひご期待ください。
BlackBerry のインシデント対応サービスについて
BlackBerry のインシデント対応サービスは、お客様があらゆる侵害の影響を軽減し、ベストプラクティスに従った復旧を保証しながら、将来に備えて IT 環境を保護できるよう支援します。弊社のサイバーセキュリティの専門家がお客様の疑問にお答えするため、お客様は、発生中の攻撃から IT 環境を保護するだけでなく、将来のサイバー攻撃をも防御することが可能です。
.png)
