残された攻撃の痕跡を追え！　～スレットハンティングのススメ～

こんにちは。先端技術部 エバンジェリストの内山です。
 
過去3回にわたってスレットハンティングをテーマにお届けしたコラムですが、本コラムをもって最終回です。
前回のコラム(残された攻撃の痕跡を追え！　～Post-Exploitationで起きていること～)では、侵害後の攻撃者の活動の痕跡について、幾つか例を挙げてご案内いたしました。
 
今回のコラムでは、振り返りを兼ねた今までのまとめ的な位置づけになります。
主な内容ですが、11月11日に実施した弊社プライベートセミナー「サイバー攻撃からの対策強化！“守り”から“攻め”のセキュリティへ」の講演内容をベースにスレットハンティングが必要となる背景、スレットハンティングのプロセス、最初に取り組むべきこと等を改めて解説いたします。

近年の脅威と防御側の課題について

まずは、スレットハンティングが必要とされる背景をご理解いただくため、近年の脅威の傾向からご説明いたします。この近年の脅威の傾向ですが、主なものとして3点挙げられると思っています。

一つ目は、正規プログラムやツール、サービスの悪用です。
よく悪用されるものとして、システム管理ツールのPowerShellやPsExec、ペネトレーションテストツールのCobalt Straike、クラウドサービスのDropboxやOneDrive等がありますが、いずれもセキュリティ監視や調査・分析からの検知回避が目的です。
 
二つ目は、C2通信の隠蔽です。
これも先ほどと同様に検知回避が目的です。マルウェアの検知回避や解析妨害の挙動は様々ですが、ここでは代表的なものとしてC2通信の暗号化の占める割合が増加している状況にあることをお伝えいたします。最近のデータによると、マルウェアの外部通信の約46%がTLSで暗号化されています。[1]
 
三つ目は、攻撃ベクターの多様化です。
従来の攻撃ベクターの多くはメールやWeb経由でしたが、最近のインシデント事例をみると、VPN機器のような外部公開資産が狙われる傾向にあります。VPN機器の脆弱性を探索するスキャン通信は常時行われており、脆弱性を残したVPN機器を使い続けることは、セキュリティ侵害を時間の問題にしてしまうといっても過言ではないでしょう。
 
最後に1点、脅威の傾向として個人的に気になっているものがあります。
2020年12月中ごろから、ファイル転送用アプライアンスのAccellion FTA のゼロデイ脆弱性を悪用した攻撃が発生しました。[2]この攻撃に関与した攻撃グループはCLOPランサムウェアを展開することなく、窃取情報を「CL0P^_LEAKS」に掲載すると脅すメールを被害企業へ送り付けていました。ランサムウェアの展開は暗号化により攻撃に気付きやすいという側面がありますが、この事例の場合は逆に気づきにくい攻撃とも言えます。ランサムウェアを展開しない暴露型攻撃の戦術が、攻撃者にとって効果的と判断されれば非常に厄介ですね。
 
こういった近年の脅威に対し、セキュリティの実運用の中で検知・対応ができると言えるでしょうか。
私個人の見解としては、多くの組織において検知・対応が難しい状況になりつつあるのではないかと考えています。ウイルス対策ソフトやセキュリティ機器では、シグネチャのパターンマッチによる検知のみでは不十分と言えますし、最新の脅威情報やパターンファイル、セキュリティパッチを反映するまでの時間差をなくすことは難しいのが実情です。また、よく言われる攻防の非対称性を覆すことは、多くの組織において無理な注文です。
 
多くの組織ではセキュリティ機器のアラート検知やSOCからの連絡後に迅速な対応をとるスタンスだと思います。でも、近年の脅威の傾向を考えると、果たしてそれで良いのでしょうか。

自組織の守りは堅い、重要な資産をもっていないので攻撃者に狙われないといった都合の良い認識や考えではなく、すでに守りは突破されているという前提にたって、能動的に脅威を探す取組みを、今のセキュリティ対策や運用に取り入れることが、防御側の課題と言えるのではないでしょうか。
 
この能動的に脅威を探す取組み、すなわちスレットハンティングは組織にとって重要なセキュリティ施策です。

Cybersecurity Insiders による2021年の調査報告によると、88%の組織が脅威の早期発見やリスク低減のためにスレットハンティングを最重要施策と位置付けています。[3]
海外の調査報告のため、そのまま国内に適用するとやや無理がある話かもしれませんが、脅威の早期発見やリスク低減を実現する手段として有効な施策であることは頷ける話です。

スレットハンティングのススメ

ここでスレットハンティングの重要性をご理解いただくために、少し概念のお話になりますが定義やプロセスについてご説明いたします。
スレットハンティングとは何か。Sqrrl社（現在はAmazonに買収）の定義によれば、
 
「既存のセキュリティソリューションを回避する高度な脅威を検知・隔離するため、能動的かつ反復的にネットワークを探索するプロセス」としています。
 
言い方を変えてみますと、アラートのあがらない見逃した脅威を見つける取組みとも言えます。
 
スレットハンティングは、テクノロジーでもなくセキュリティソリューションでもありません。何かツールを導入すれば完結するものではなく、ツールの力は借りるが、あくまでも人間が主体的に実施するプロセスです。
 
では、スレットハンティングの能動的かつ反復的にネットワークを探索するプロセスとはどういうものか、Sqrrl社のThe Hunting Loop をもとにご説明いたします。
 
スレットハンティングは「仮説フェーズ」「調査フェーズ」「発見フェーズ」「分析フェーズ」の４つのフェーズを繰り返し行うプロセスから成り立っています。

それぞれのフェーズで行う作業の概要は以下のとおりです。
 
仮説フェーズ：侵入を前提に、攻撃者の目的や背景、組織のシステム構成等から侵入の仮説を立てる
調査フェーズ：立案した仮説に基づいて、潜伏するマルウェアを検出するための調査を行う
発見フェーズ：調査で確認した不審な点の解析を行い、攻撃者の戦術・技術・手順を特定する
分析フェーズ：特定した攻撃者の戦術・技術・手順をIOCとして定義し、今後のセキュリティ監視・対策等に反映する
 
調査を行っても仮説を立証できなかった場合、内部ネットワークの可視化の方式やスレットハンティングで利用しているツールのポリシーや検知条件を見直し、仮説の検証を繰り返し行うことが大切です。また、仮説が立証された場合、内部に潜伏する脅威を発見したことになりますので、その時点からインシデント対応のフェーズへ移行します。
 
スレットハンティングのおおよその一連の流れは、これでご理解いただけたかと思います。
 
ところで、ただでさえ繁忙なセキュリティ担当者（セキュリティ対応組織の管理者）としては、このスレットハンティングを新たな業務として取り組むべきか否かは迷うところでしょう。他セキュリティ業務と重複している部分がないか、どのような違いがあるかは、組織のリソースを有効活用するうえで気になる所だと思います。
 
図5は他セキュリティ業務との主な違いを整理したものです。

少し補足しますと、インシデント対応とスレットハンティングの大きな違いは、インシデント対応がアラート検知後の「事後の対応」であることに対して、スレットハンティングは能動的に潜伏する脅威を探索する「事前の対応」です。
また、ペネトレーションテストは、能動的に脅威を探すという観点はスレットハンティングと同じです。主な違いは対応内容にあり、ペネトレーションテストは、ソーシャルエンジニアリングを含めたあらゆる手法を用いて外部からの侵入を検証する業務である一方、スレットハンティングはネットワーク内部に侵入された前提に立って、重点的に守りたい領域や侵入リスクの高い箇所を重点的に調査する業務です。
 
さらにスレットハンティングに取り組むことで、潜在的な脅威の早期発見と自組織のリスク管理強化につながります。具体的なメリットを幾つか挙げてみます。
 
・既存のセキュリティ対策を突破した脅威の発見につながる
・定期的かつ反復的な探索プロセスにより、自組織の脅威検知能力の継続的な向上が図られる
・セキュリティインシデント発生時に使うツールの練習ができ、インシデント対応訓練にもなりうる
・経験のあるセキュリティアナリストと共に調査を進めることにより、人材育成の効果が高まる
・自組織の環境や攻撃対象領域に対する認識の向上が図られる
 
如何でしょう。アラート検知後に迅速な対応をとることは当然として、今のセキュリティ対策や運用にスレットハンティングを取り入れることは、組織のセキュリティ対策として重要な課題と言えるのではないでしょうか。

Let’s Hunt!!

スレットハンティングの重要性は理解できたので、ぜひ取り組んでみたい！という前に、おさえておくべきポイントが3つあります。
 
一つ目は、インシデント対応プロセスが整備されていること。
調査・分析の過程で脅威を発見した場合、その時点からインシデント対応のフェーズへ移行します。この時、インシデント対応プロセスが不完全だった場合、せっかく発見した未知の脅威に対して的確な対応ができないことになってしまいます。
 
二つ目は、ネットワーク機器やセキュリティ対策機器のログを取得していること。
組織のネットワークで「できるだけ何が起きているか分かるようにする」ことが大切です。そのためには、調査・分析対象となるデータソース（ログ）の種類と量を確保することが必要です。EDRやSIEM等のツールを活用されておりましたら、それらはエンドポイントやネットワークの可視性の確保に役立ちます。これを機会に、ツールの設定やポリシー、ログの収集範囲を見直すのも良いでしょう。
 
三つ目は、人材と体制、リソースが確保されていること。
スレットハンティングに取り組むには、エンドポイントやネットワークセキュリティに精通している、ログ・データ分析の経験がある等のスキルセットを持つ人材が必要です。こういった人材が内部にいない場合は、外部の専門家に依頼する手もありますが、組織にスキルやナレッジが蓄積されないといったデメリットがありますので、組織のセキュリティ戦略に即した判断が必要になってきます。
 
少し横道にそれますが、外部の専門家は必ずしも組織の内部事情やシステム構成に精通しているとは限りません。そのため、仮説の立案や調査・分析の範囲に制約がでてくる可能性があります。そういった点も鑑みると、全てを外部の専門家に任せるのではなく、何等かの形で自組織の人材をスレットハンティングの体制の中に組み込んだ方が良いと考えています。
 
話を元に戻します。人材と体制の目途がたちましたら、スレットハンティングの範囲と目標を設定すべきでしょう。組織の内部ネットワーク全体もしくは全システムが対象というのは現実的ではありません。これは仮説の立案にも関わってくる部分ですが、重点的に守りたい領域や侵入リスクの高い箇所といった調査・分析の範囲を絞ることが大切です。また、スレットハンティングを行うことによって、何を成し遂げたいか、組織のセキュリティ戦略と整合をとりながら決める必要があります。
 
以上の3点を満たしていましたら、ぜひスレットハンティングに取り組んでいただきたいと思います。
 
では、どこから取り組むべきかですが、まずはIOCの検索から始めることをお勧めいたします。
何より一番シンプルで簡単にスレットハンティングを始めることができます。IOCの検索を始めること自体に大きな準備をする必要はありませんので、スレットハンティングの体制やプロセスの整備と並行して取り組むことができると思います。
 
IOCは様々な組織や団体、個人から共有情報として公開されています。
（例）
JPCERT/CC
セキュリティ情報共有組織（ISAC：Information Sharing and. Analysis Center）
セキュリティベンダー
セキュリティサービスプロバイダー
セキュリティ専門家
 
情報の提供媒体は、Blog、メール、コラボレーションツール、セキュリティレポート、ホワイトペーパー等、様々ありますので、自組織にあったところから収集しご活用ください。
 
なお、IOC検索はSqrrl社のThe Hunting Maturity Modelの成熟度レベル1にあたります。

The Hunting Maturity Modelは、企業や組織がスレットハンティングを行う上での成熟度を示すモデルです。このモデルから見ても、IOC検索はスレットハンティングの最初の第一歩として適切だと思っています。
 
IOC検索に慣れてきましたら、ぜひ内部に侵入された前提の仮説を立ててみて下さい。
まずは仮説を立てる上で、「守るべき重要資産は何か」と「自組織を狙うのはどのような脅威の主体か」を考えてみましょう。

特に「守るべき重要資産は何か」は、セキュリティ対策で最も基礎になる部分で、皆様もよく聞く話だと思います。守るべき重要資産を決めておくことで、攻撃者の侵入経路の仮説が立てやすくなります。その結果、調査・分析を行なうデータソースの範囲も絞られますので、最初に守るべき重要資産を決めましょう。
 
次に「自組織を狙うのはどのような脅威の主体か」です。こちらは、日々のセキュリティ情報の収集を疎かにしていると、脅威の主体を考えるための手がかりがない状況に置かれてしまいます。これを機会にセキュリティ情報の収集を行い、自組織が属する業界を狙った攻撃や、よく狙われる脆弱性等の情報を確認してみましょう。とはいえ、自組織だけでの考えに行き詰ってしまう場合は、信頼のおけるパートナーに相談してみるのも解決の一つの手段です。
 
では、参考までに以下のような条件を設定して仮説の例を挙げてみます。
 
守るべき重要資産：特許情報と研究開発データ
脅威の主体：自組織が続する業界を標的にする脅威アクター
侵入の仮説：この脅威アクターが、本社ネットワークと比較して対策が手薄な関連企業を侵害し、本社ネットワークへの侵入を行っています。また、既に内部ネットワークを探索し、特許情報と研究開発データを見つけ、暗号化通信で外部へ持ち出しています。
 
このような仮説に基づいて、調査・分析を進めることになります。
上記の例の場合、関連企業とのネットワーク接続部分や特許情報と研究開発データが保管されているサーバやネットワークに的を絞って調査・分析を行ないます。
 
ここで重要なことは、立案した仮説は検証可能でなければならない、ということです。
仮説が検証可能というのは、十分なデータソースを確保しており、尚且つ脅威に関する情報を組織として収集しているということです。
 
先ほどの仮説になぞらえて理由をご説明しますと、関連企業とのネットワーク接続部分のログを取得していないと、侵入の調査ができませんし、脅威アクターに関する情報をもっていないと、どのような戦術や技術を使った攻撃か分からないため、調査・分析の足掛かりがない状況に陥ることになるからです。少し極端な話になってしまいましたが、それだけ仮説を検証可能にするための重要な要素だとご理解ください。
 
また、適切な分析ツールと、それを扱う技術が備わっていないと仮説の検証が難しくなります。
前々回のコラム(残された攻撃の痕跡を追え！　～初期侵入の痕跡が残るデータソース～)と前回のコラム(残された攻撃の痕跡を追え！　～Post-Exploitationで起きていること～)で攻撃の痕跡が残されるデータソースと確認方法をご案内しましたが、調査・分析を行なう箇所が多く、全てを人間が手動で確認するのは大きな労力と時間を要してしまいます。このため、EDRやSIEM等の分析ツールがあると調査・分析を効率かつ効果的に行うことが可能となります。エンドポイントのログ、ネットワークトラフィック、アプリケーションのログ等、それぞれに適した分析ツールを採用しご活用することをお勧めいたします。
 
さて、ここで少しだけ宣伝をさせて下さい。
11月2日、弊社はサイバー脅威遡及分析サービスをリリースしました。[5]
ネットワークトラフィックの分析が不安で任せたい、というお客様への弊社の新しいサービスです。

最後に