アラート待ちから抜け出す脅威ハンティングの始め方

セキュリティ運用の多くは、機器が上げてきたアラートを受け取るところから始まります。EDRが警告を出す、SIEMの相関ルールが発火する、WAFが遮断した通信を通知する。この形は、既知の悪性と判定できるものについてはよく働きます。ただし、判定できなかったものについては何も起きません。アラートが来ないという事実は、何も起きていないことの証明にはならないためです。

脅威ハンティングは、この空白を埋めるための運用です。何かが検知されるのを待つのではなく、「自社の環境でこういう振る舞いが起きていたとしたら、ログのここに痕跡が残るはずだ」という仮説を先に立て、その痕跡を手元のデータから探しに行きます。想定読者は、アラート対応の運用は回っているものの、そこから一歩進めたい情報システム担当とSOC担当です。

この記事は、ログの取り方そのものや、ATT&CKの用語解説、侵害後のフォレンジック手順ではなく、仮説を立ててから結論を出すまでの探索プロセスに軸足を置きます。重なる領域は関連記事へ誘導します。記述はMITREの公開資料、ATT&CK公式サイト、CISAとASD's ACSCほかの共同ガイダンス、NISTの文書、JPCERT/CCの資料、個人情報保護委員会のガイドラインで確認できた範囲に限り、確認できなかった事項は書きません。

先に、アラート対応と脅威ハンティングが何によって分かれるのかを一覧にします。

脅威ハンティングがアラート対応と分かれる地点#

MITREはUSCYBERCOM向けに作成したテクニカルレポート「TTP-Based Hunting」(文書番号MTR180158、公開許可番号19-3892)で、ハンティングを「ネットワーク内の悪性活動を能動的に検知し調査すること」と定義しています。定義そのものは短いのですが、「能動的に」という語が運用上の分かれ目を作ります。アラート対応では、どのデータを見るかを機器が先に決めます。ハンティングでは、どのデータをどの角度から見るかを分析担当が先に決めます。

同レポートは検知の方法を3つに分けて比較しています。1つ目は侵害指標を探す方法で、ファイルハッシュやIPアドレス、ドメイン名、ファイル名といった静的な特徴を照合します。2つ目は異常検知で、統計処理や機械学習で普段と違う事象を浮かせます。3つ目がTTPベースの検知で、攻撃者が目的を達するために使わざるを得ない技術そのものを特徴づけて探します。同レポートはこの3つを相互排他ではなく補完的なものだと明記しており、どれか1つに寄せる話ではありません。

TTPベースの検知が効く理由も機構として説明されています。攻撃者が動く土台となる技術が、侵入後に使える技術の数と種類を制約するためです。同レポートは、攻撃者は既知の技術を使うか、新しい技術の開発に多大な資源を投じるかのどちらかを選ぶしかないと述べています。一方で指標ベースの照合については、攻撃側が文字列を変えるだけでハッシュが変わるため、脆く、すぐ古くなると評価しています。

異常検知についても限界が挙げられています。誤検知率が高くなりがちで、大規模なデータ収集と処理への投資を要し、何が疑わしいと判定されたのかという文脈を十分に返さない場合があるため、分析ロジックの改善が難しいという指摘です。同レポートはさらに踏み込んで、企業ネットワークではソフトウェアと管理者と開発者と利用者の正常な活動が時間と利用者と場所をまたいで大きく変動するため、正常を定義する作業自体が徒労に終わることが多いと書いています。

ここから読み取れる進め方は素直です。指標の照合と異常検知は自動化に任せたうえで、判定ロジックを持てていない領域については、技術単位の仮説を人が立てて探しに行くという役割分担になります。

MITREはこの方法論をATT&CK公式サイトの無償トレーニング「TTP-Based Threat Hunting and Detection Engineering」として公開しています。構成は6モジュールで、Threat Hunting Fundamentals、Developing Hypotheses & Abstract Analysis、Determining Data Requirements、Identify and Mitigate Data Collection Gaps、Implement and Test Analytics、Hunt and Investigationという順に並んでいます。この並びがそのまま探索プロセスの骨格です。

ATT&CKの技術から仮説を組み立てる#

仮説は思いつきではなく、攻撃者が使う技術の一覧から機械的に引き出せます。ATT&CKはその一覧として使えます。執筆時点のATT&CKはv19.2で、Enterpriseドメインには222個の技術と475個のサブ技術が登録されています。2026年4月28日公開のv19では、Defense Evasion戦術がStealth(TA0005)とDefense Impairment(TA0112)の2つに分割され、Enterpriseの戦術は15個になりました。

MITREのレポートが示す仮説の作り方は、技術を1つ選び、それを検知するための抽象アナリティクの形で仮説を書く、というものです。同レポートの例は次のとおりです。攻撃者がSMBでファイルをシステム間に移し、そのファイルをスケジュールタスクで実行することがあると知っているなら、抽象アナリティクは「SMBセッションを通じて移されたファイルが、schtasksの実行によって起動される事象を検知する」となります。

ここで同レポートが釘を刺しているのが、特定のツールによる特定の実装に寄せすぎないことです。仮説とアナリティクは、技術としての不変部分に基づいて書くのが理想だとしています。ツール名やコマンドの完全一致で書くと、攻撃側が引数の別表記や環境変数を挟むだけで素通りします。

どの技術から手を付けるかの優先順位についても、同レポートは複数の考え方を並べています。どれが最良かは研究上まだ決着していないと明記したうえで、攻撃グループやソフトウェアの記載件数から頻度の高い技術を取る方法、いま手元にあるデータ種別で取れる技術に絞る方法、初期アクセスから実行や探索といった早い段階を優先する方法、認証情報の窃取や遠隔システムの探索のようにほとんどの攻撃者が通らざるを得ない箇所を狙う方法、そして自社の利用者や管理者がまず使わないと分かっている技術を選ぶ方法を挙げています。最後の切り口は誤検知が少なくなるため、最初の1本としては扱いやすい選択になります。

ATT&CKの用語や戦術と技術の関係そのものは、別記事で整理しています。ここでは仮説の材料としての使い方に絞ります。

あわせて読みたい

MITRE ATT&CKで攻撃を体系的に理解する。戦術と技術のマトリクスを検知・防御にどう活かすか

v19以降のATT&CKには、仮説から実装へ橋を渡す層が追加されました。Detection Strategyです。公式サイトの説明では、Detection Strategyは特定の技術を検知するための高水準の方法を定義するもので、複数のプラットフォーム別Analyticを1つの検知方法論としてまとめる入れ物だとされています。執筆時点でEnterpriseとMobileとICSの3ドメイン合わせて918件が登録されています。

具体例で見ると使い方が分かります。T1018 Remote System Discoveryは、攻撃者がIPアドレスやホスト名で他のシステムを洗い出す技術で、戦術はDiscovery(TA0007)です。この技術にはDET0574というDetection Strategyがぶら下がり、その下に複数のAnalyticが並びます。AN1583は「net.exeやping.exeやtracert.exeといったネットワーク列挙ユーティリティが短時間に連続して実行され、横展開の道具やシステム列挙コマンドと連鎖することが多い」という内容です。AN1584はbashスクリプトや対話シェルからpingやarpやtracerouteを順に発行してリモートホストを地図化する動きを扱います。

自社の仮説をこの粒度まで具体化できれば、あとはSIEMのクエリに落とすだけになります。

ATT&CK公式サイトのDetection Strategies一覧は、Detection Strategyを「特定の攻撃技術を検知するための高水準のアプローチを定義するもの」「複数のプラットフォーム別アナリティクを1つのまとまった検知方法論として組織化するコンテナ」と説明しています。IDはDET形式で、執筆時点で918件が3ドメインにわたって掲載されています。

指標ベースの探索と振る舞いベースの探索#

何を探すかによって、探索の寿命が変わります。この差を最初に図示したのがDavid J. Bianco氏の「The Pyramid of Pain」です。出典は同氏の個人ブログ「Enterprise Detection & Response」の2013年3月1日の記事(2014年1月17日更新)であり、標準化団体の文書ではありません。引用する場合はその性質を添えるのが正確です。

同記事のピラミッドは、下から順にハッシュ値、IPアドレス、ドメイン名、ネットワークとホストのアーティファクト、ツール、そして頂点にTTPを置きます。下に行くほど攻撃側が変更しやすく、上に行くほど変更が苦痛になるという構成です。同記事は頂点について、この水準で検知して対応するとき防御側は攻撃者の道具ではなく振る舞いそのものに働きかけることになり、攻撃者に最も時間のかかること、つまり新しい振る舞いを学び直すことを強いる、と述べています。

MITREのレポートも、悪性活動を特徴づける段階で「David Bianco氏のPyramid of Painの上部に集中せよ」と明示的に参照しています。攻撃者の振る舞いのうち、どの部分が一時的で変えやすく、どの部分が変えにくいかを見極めることが特徴づけの要点だという整理です。

個人ブログを出発点とする概念であるため、そのまま実務の採点基準にするには粒度が粗いという課題がありました。ここを埋めているのが、MITRE Center for Threat-Informed Defenseの「Summiting the Pyramid」です。これは検知ロジックを設計して攻撃者による回避を難しくすることを目的とした研究プロジェクトで、執筆時点のバージョンは4.0.0です。アナリティクの堅牢性を1から5の段階で、観測事象の堅牢性をApplication(A)、User-Mode(U)、Kernel-Mode(K)などの列で採点します。段階の上位は技術やサブ技術の中核に触れる検知、下位は一時的な値に依存する検知という位置づけです。

この採点の考え方は、Sigmaのルール記述にも取り込まれています。Sigmaのタグ仕様にはstpという名前空間があり、Summiting the Pyramidの方式に沿ってルールの堅牢性を採点できるようになっています。

Summiting the Pyramidは、MITRE Center for Threat-Informed Defenseが公開する研究プロジェクトで、「攻撃者による回避を難しくするようサイバーアナリティクを設計すること」を目的として掲げています。アナリティクの堅牢性を5段階、観測事象の堅牢性を列で表す採点方式を定義しています。

探索に必要なデータをそろえる#

探索は、データがなければ成立しません。仮説を立てても、その痕跡が残る場所にログがなければ、結論は「見つからなかった」ではなく「わからなかった」になります。この2つを取り違えると、探索の記録が意味を持たなくなります。

MITREのレポートは、継続的な監視から得られるデータのほうが、事後のフォレンジック採取よりも探索には向くと述べています。理由は時間軸です。悪性の振る舞いを探す作業は大きくて未知の時間幅から始まる一方、フォレンジックの道具が覆えるのは時間軸のごく一部の断面であり、探している振る舞いがその外側に落ちる可能性のほうが高いためです。事後採取のデータは進行中の調査を補う材料としては有効でも、検知の主データ源としては弱いという整理になっています。

同レポートは、まず整えるべきホスト側の収集項目を具体的に挙げています。プロセスの生成と終了、ログオン事象(遠隔とローカルの両方)、ファイルの生成と変更とタイムスタンプ改変、ドライバとモジュールの読み込みと解放、レジストリの変更、サービスとスレッドの生成と削除、ネットワーク活動とそれに紐づくプロセス情報です。ネットワーク側の収集はホスト側を補うものとして位置づけられ、相関のために集中管理することが推奨されています。

もう1つの前提が保管期間です。共同ガイダンス「Best Practices for Event Logging and Threat Detection」は、既定の保管期間は不十分な場合が多いとしたうえで、侵害の発見までに最長18か月かかる事例があり、マルウェアが明確な被害を出す前に70日から200日ネットワーク内に潜伏する場合があると述べています。探索の時間幅は、この現実と自社のログ保管期間の短いほうで頭打ちになります。

仮説を書いたら、その仮説を検証するために何のデータが要るかを逆算します。MITREのレポートはこの作業を、収集要件とモデリング要件の2つに分けています。

収集要件は、作った抽象アナリティクの一覧から必要なデータとデータ源を書き出す作業です。先ほどのSMBとschtasksの例なら、SMBに関するネットワークトラフィックとホストのログ、そして各端末でschtasksが呼ばれたときの文脈データ、つまりどのファイルが実行されたか、実行日時はいつか、どの利用者に紐づくかが必要になります。

ここには量と文脈のせめぎ合いがあります。同レポートは、文脈が多いデータ源ほど生成される量も多くなるのが一般的で、ホストとネットワークの全内容を採り切ることは現実的ではないと述べています。だからこそ、先に技術と抽象アナリティクを決めておくことで、収集の対象を必要な範囲に絞れるという順序になります。

データの粒度についても注意があります。ネットワークのフローデータは、対応するアプリケーション層の情報を欠くと価値が限られます。ホスト側のセンサーも、親プロセスや実行パスやコマンドライン引数といった細かなプロセス情報を表現できないと後から不足が判明します。同レポートが挙げる最低条件は、関連する事象を因果でつなげて攻撃者の各段階を特定できることです。

センサーの選び方にも指針があります。継続的な活動や事象や内容を出すセンサーのほうが、シグネチャやアラートを出すセンサーよりも探索には向きます。ハンティングは、そもそも悪性と判定されなかった活動を調べる作業だからです。シグネチャ型の侵入検知システムは自動検知の道具としては有効でも、文脈を返さないため探索の主データ源としては役に立ちにくい、という評価になっています。

どのログを優先するかの現実的な並びは、共同ガイダンスが企業ネットワーク向けに16段階の優先順位として示しています。上位から、狙われやすい重要システムとデータ保有領域、遠隔アクセスを含むインターネットに面したサービスとその基盤OS、ID管理とドメイン管理のサーバ、その他の重要サーバ、境界ルータやファイアウォールなどのエッジ機器、管理作業用ワークステーションが並び、以降に高権限システム、データ保管領域、利用者の端末、Webプロキシ、DNSサービス、メールサーバ、DHCPサーバ、旧来のIT資産が続きます。

ログの取得対象と保管期間の決め方そのものは、別記事で扱っています。探索を始める前に、そちらで最低限の土台を確認しておくと、この記事の手順が空回りしません。

あわせて読みたい

ログ管理の基本。何を・どこまで・どれだけ残すか

共同ガイダンス「Best practices for event logging and threat detection」は、ASD's ACSCが主導し、CISA、FBI、NSA、NCSC-UK、CCCS、NCSC-NZとCERT NZ、日本のNISCとJPCERT/CC、韓国のNISとNCSC-Korea、シンガポールのCSA、オランダのAIVDとMIVDが協力して2024年8月21日に公開されました。企業ネットワーク向けの16段階のログ優先順位を示し、時刻はUTCとISO 8601形式(例: 2024-07-25T20:54:59.649Z)の採用を推奨しています。

探索の範囲を区切って少数の振る舞いを浮かせる#

データがそろっても、そのまま全体を眺めることはできません。MITREのレポートは分析空間を時間、地形(テレイン)、振る舞いの3次元で捉え、探索の開始時にこの3つで範囲を絞る手順を置いています。

時間の絞り方は単純です。攻撃者が特定の時期に活動していたという情報があるならその前後に幅を取り、そうでなければ現在から一定期間さかのぼります。同レポートは例として探索開始から2週間前という区切りを挙げ、実際には分析基盤の保管期間で自動的に上限が決まる場合が多いとしています。SIEMが30日分のローリング保管なら、時間軸はそこで頭打ちです。

地形の絞り方は、守る権限と責任がある範囲に限ることが前提になります。そのうえで、狙われやすい箇所、攻撃者が目的達成のために通らざるを得ない箇所(インターネット接続点やドメインコントローラなど)、そして壊されると防御側の対応能力が落ちる箇所(SOCの分析系、境界とホストのセンサー、ログ収集基盤)に重点を置くとされています。

振る舞いの絞り方には2つの入口があります。似た正常な振る舞いと比べて悪性と判別しやすい技術を選ぶ入口と、自社を狙うと分かっている攻撃グループが使う技術を選ぶ入口です。後者には注意が添えられています。1つの組織が単一のグループだけに狙われるとは限らないため、そのグループの既知の振る舞いだけに絞ると別の侵害を見落とす可能性があります。攻撃者は技術が知られると変えてくるため、この絞り方は優先順位付けには有効でも、探索対象から技術を外す根拠には使うべきでないとされています。

範囲を決めたら、集計に入ります。同レポートが挙げる方法は、地形の単位ごとに一定期間あたりの事象の出現回数を数え、時間と地形を軸にした熱地図として色で表す、というものです。1台の端末について1日あたりの回数を数えれば、特定の端末の特定の日が浮きます。軸を入れ替えて地形と振る舞いにすると、ネットワーク全体でどの振る舞いが増減しているかが見えます。同レポートは、攻撃の1日目にDiscovery戦術に関する振る舞いが急増し、2日目にLateral Movement、3日目にExfiltrationが続くというような流れが読み取れる場合があると説明しています。

集計の単位は固定しません。1日と1台から始めて1時間や1週間に変える、あるいはサブネット単位や利用者名単位でまとめると、背景の雑音から外れ値が分離しやすくなります。時間を短く取ると、広い範囲に一度に走る活動(大量感染や偵察や情報の持ち出し)が浮きます。地形を狭く取ると、長期間にわたる的を絞った活動が浮きます。

既知の正常を除外する順序も同レポートに沿うと迷いません。まず個々の誤検知率が低いと見込める仮説から着手し、次に自社で日常的に使われていることが分かっている道具を除外し(たとえばpsexecが業務で頻繁に使われる環境なら、探索対象のコマンド一覧から外す)、それでも量が多ければ探索する振る舞いの数自体を減らします。除外の判断は、公開情報の調査だけでなく、ネットワークやシステムの管理者に「この動きは正規のものか」と直接確認することでも行えます。同レポートは、何度か調整を回したうえで管理者に観測結果を見せ、正常と判定できるかを尋ねることが有効だと書いています。

手元のログでの具体的な探し方#

ここからは、実際に手元にあることが多いログでの探し方を挙げます。クエリは製品ごとに書き方が変わるため、擬似コードで書きます。

プロセス生成ログ#

Windowsのプロセス生成事象はセキュリティログのイベントID 4688に記録されます。Microsoftの公式ドキュメントは、このイベントが新しいプロセスの生成ごとに発生し、監査ポリシー「プロセス作成の監査」で有効化することを説明しています。既定の状態ではコマンドライン引数が記録されないため、引数を残す設定を追加で有効にする必要があります。Sysmonを導入している環境では、イベントID 1として親プロセスや実行ファイルのハッシュを含む形で同種の情報が取れます。

探索の切り口として使いやすいのが、MITREのCyber Analytics Repositoryに登録されているCAR-2013-04-002「Quick execution of a series of suspicious commands」です。2013年4月11日登録のアナリティクで、内容は「悪意ある行為者が頻繁に使い、通常の利用者はあまり使わないコマンドがある。これらのコマンドが短時間に実行されているかを見ることで、いつ侵入者がシステム上にいたかだけでなく、何をしていたかの手がかりも得られる」というものです。対象コマンドとして、arp.exe、at.exe、cscript.exe、dsquery.exe、hostname.exe、ipconfig.exe、net.exe、netsh.exe、nslookup.exe、ping.exe、quser.exe、reg.exe、sc.exe、schtasks.exe、systeminfo.exe、tracert.exe、wscript.exeなどが挙げられています。

これを擬似コードにすると次のような形になります。

# 仮説: 侵入後の初期探索では、列挙系コマンドが短時間に連続して実行される
入力: プロセス生成ログ(過去14日、全端末)
1. 対象コマンド一覧に一致する ProcessName を抽出
2. (端末, 利用者, 10分単位の時間枠) でグループ化し、
   一致した「異なるコマンドの種類数」を数える
3. 種類数が3以上のグループを抽出
4. 運用の定例作業(構成管理エージェント、資産棚卸スクリプト)に
   由来する親プロセスを除外条件として登録し、除外する
5. 残ったグループを、親プロセスと完全なコマンドラインつきで一覧化

ここで効くのが親プロセスです。ipconfigやnetが単独で走ること自体は珍しくありませんが、Officeアプリケーションやブラウザの配下から、あるいは一時フォルダに置かれたスクリプトから連続して走るのは説明が要ります。MITREのレポートも、共通のプロセス系統を持つ疑わしい振る舞いは、単独の検知よりも優先して追うべきだと述べています。

正規のOS標準ツールを使う攻撃の一般論と対策は別記事で扱っています。探索の対象を選ぶときの参考になります。

あわせて読みたい

環境寄生型攻撃(LOLBins)の仕組みと振る舞いで見つける検知設計

Webプロキシログ#

JPCERT/CCの「高度サイバー攻撃への対処におけるログの活用と分析方法」(1.2版、2022年5月10日)は、プロキシログから痕跡を見つけるための着眼点を、手順の形で具体的に示しています。同資料が挙げる定期的なログ分析の着眼点は、定期的に発生する通信、就業時間帯以外の外部への通信、そして外部へ異常に大量のデータを送出する通信の3つです。

定期的な通信を抽出する手順は次のとおりです。プロキシのアクセスログからURLを含む行を抽出し、URLからドメインを取り出し、検索サイトのように正規利用で常時アクセスするドメインを除去し、各ドメインへの日ごとのアクセス回数を集計し、複数日にわたって1日1回以上のアクセスが続いていて妥当性を説明できないドメインがあれば痕跡の可能性ありと判定します。

同資料は、この方法の限界も書いています。プロキシを経由せずに直接インターネットへ出られる経路があると検知漏れが生じます。一般的なブログサイトなどが指令サーバとして使われた場合は、ドメイン単位ではなくURL単位で集計するなどの工夫が要ります。複数の指令サーバを使い分けたり通信間隔を不定期にしたりするマルウェアは、この方法では検知できません。

就業時間外の通信については、メンテナンスなどの名目で従業員に端末を操作させない時間帯を意図的に作り、その時間帯に発生したアクセスを抽出して調べるという踏み込んだ手法も紹介されています。

# 仮説: 指令サーバへの定期通信は、ドメイン単位の日次アクセス数が安定して残る
入力: プロキシアクセスログ(過去30日)
1. URL からドメインを抽出
2. 全社の日次アクセス端末数が多い上位ドメイン(業務利用が明らか)を除外
3. (ドメイン, 端末) ごとに、アクセスのあった日数と 1 日あたりの回数を集計
4. 「アクセス日数が多い」かつ「アクセス元の端末数が1台か2台」の組を抽出
5. 残った組について、User-Agent、HTTPメソッド、送信バイト数の分布を確認

あわせて読みたい

正規のリモート管理ツール(RMM)が攻撃に悪用される手口と防御

DNSログと認証ログ#

同資料は、DNSサーバと認証サーバのログについて、記録される量が膨大になるため、プロキシやファイアウォールのログ分析で得た手がかりを使って調査範囲を絞り込むのが望ましいと述べています。この順序は実務上そのまま使えます。DNSログから探索を始めると量に押し流されるため、他のログで浮いた端末やドメインを軸に、時間を区切って掘るほうが進みます。

認証ログについては、同資料が異常事象の報告を受けた際の分析として、認証の失敗がないか、普段と異なるアカウントの利用がないかを確認する流れを示しています。Active Directoryを対象とした攻撃の検知については、JPCERT/CCが別途「ログを活用したActive Directoryに対する攻撃の検知と対策」を公開しています。

共同ガイダンスも、異常な振る舞いの例を一覧で挙げています。通常と異なる時間帯(業務時間外、休日、休暇中)のログイン、普段使わないサービスへのアクセス、地理的にあり得ない移動を伴う複数拠点からの同時サインイン、単一のIPアドレスから複数の利用者として認証を試みる動き、管理者権限を持つアカウントの新規作成や無効化済みアカウントの再有効化、普段通信しない内部機器同士の通信を示すフローデータ、予期しないログの消去、通常と異なるパスからのプロセス実行、そしてセキュリティソフトウェアやログ管理ソフトウェアの設定変更です。同ガイダンスは、これらが正当な振る舞いである可能性を明記し、防御側による追加調査が必要だと付け加えています。

見つかった手がかりを前後にたどる#

集計で浮いた事象は、そのままでは悪性だと言えません。MITREのレポートは、外れ値の集団に属する事象が必ずしも悪性ではないため、1件ずつ深く評価する必要があると書いています。

評価の第一歩は、視野を広げることです。1台で疑わしく見える振る舞いも、同じネットワークの全端末で長期間にわたって起きているなら正常である可能性が高くなります。逆に、既知の悪性事象と直接つながる線を引けたなら、その事象が悪性である確からしさは大きく上がります。同レポートの例では、コマンドプロンプトが珍しい実行ファイルを走らせているだけでは判断できませんが、その親プロセスが既に悪性と判定された実行ファイルであり、実行した利用者アカウントも既に悪性プログラムの実行者として特定されていたなら、当該事象も悪性と推論できるとしています。

追跡の方向は前後の両方です。同レポートは、まず原因側にさかのぼって初期侵入まで届くことを目指し、あわせて後続の活動を追って侵害の範囲と規模を判定することを推奨しています。因果の各リンクが埋まらない場合は要求を緩め、直近のネットワーク接続、同じ利用者や端末による近い時間帯の別の活動、同一の振る舞いを示す他の端末といった範囲まで広げて考えます。

判定の扱いにも指針があります。既知の悪性活動の直接の子孫は悪性とみなしてよい一方で、同じ親を共有するだけのプロセスは、文脈が得られるまでは疑わしいという扱いにとどめる、という切り分けです。

空振りに見える結果の解釈も同レポートは明示しています。アナリティクが有用な結果を返さないことは、必ずしもロジックが誤っていることや悪性活動が存在しないことを意味しません。絞り込みが具体的すぎた、期間が狭すぎた、攻撃者がまだその区画に到達していない、あるいはその技術を使っていないという可能性があります。この場合は3つの次元のいずれかを緩め、分析担当が処理しきれない量にならない範囲で段階的に広げます。

誤検知の原因もあらかじめ知っておくと調査が速くなります。同レポートが挙げるのは、システム管理者の作業(横展開に見える操作、アカウント操作、スクリプト実行、データ圧縮など)、開発者の作業、システムやサービスの設定不備、そしてハンティングチーム自身の活動です。最後の項目は見落としやすい落とし穴で、管理者権限のPowerShellスクリプトで端末からデータを集める作業や脆弱性スキャンは、探索の対象と同じ痕跡を残します。チーム内で誰が何をしているかを共有していないと、自分たちの足跡を追うことになります。

侵害が確からしいと判断できた段階から先は、初動対応の手順に切り替わります。隔離の単位や証拠の残し方は別記事で扱っているため、探索の結果をそのまま引き継げるように目を通しておくとつながりが良くなります。

あわせて読みたい

インシデント発生時の初動対応。最初の1時間で何をするか

端末を押さえたあとの調査手順も、探索とは別の作法になります。揮発性の高い情報から採る順序や完全性の証明については、こちらで整理しています。

あわせて読みたい

ログからの侵害調査（フォレンジック）の基本。証拠保全とタイムライン再構成

探索の結果を検知ルールへ引き継ぐ#

探索を1回ごとの作業で終わらせないために、結果を2種類の資産に変換します。1つは検知ルール、もう1つは記録です。

検知ルールへの昇格は、探索で使ったアナリティクのうち誤検知率が実運用に耐える水準まで下がったものを、常時監視に載せる作業です。MITREのレポートは、アナリティクの開発を設計と試験と調整と運用の連続した工程として捉えるよう述べたうえで、再現率と適合率の両方を試験することを求めています。再現率の試験は検証環境で行い、その技術が存在するときにアナリティクが確かに発火することを確かめます。適合率の試験には現実的な背景活動が要るため、本番に近い雑音の中で誤報率を測ります。加えて回避への頑健性も試験対象で、脅威エミュレーションやレッドチームに同じ技術を別の実装で実行してもらい、ルールが素通りしないかを確かめる流れが示されています。

ルールの記述形式としては、Sigmaが広く使われています。公式サイトはSigmaを「セキュリティ専門家のための共有可能な検知フォーマット」と表現し、汎用的で開かれた構造化された検知フォーマットだと説明しています。公式リポジトリのREADMEは「関連するログイベントを分かりやすい形で記述できる、汎用的で開かれたシグネチャフォーマット」と定義しています。ライセンスはDetection Rule License (DRL) 1.1です。

Sigmaが探索の受け皿として都合がよいのは、リポジトリが探索向けのルールを別ディレクトリに分けている点です。公式リポジトリにはrules(一般的な検知ルール)のほかにrules-threat-hunting(探索寄りの広めのルール)、rules-emerging-threats(時事的な脅威向け)、rules-compliance、rules-placeholderが置かれています。タグの仕様にもdetection名前空間があり、detection.threat-hunting、detection.emerging-threats、detection.dfirの3つが定義されています。誤検知が多くて常時アラートには向かないが探索には有効というルールを、そのまま位置づけられる構造になっています。

実際のルールは次のような形です。以下は公式リポジトリのrules-threat-huntingに収録されているルールから、構造が分かる部分を抜き出したものです。

title: File Download Via Curl.EXE
id: 9a517fca-4ba3-4629-9278-a68694697b81
status: test
description: Detects file download using curl.exe
author: Florian Roth (Nextron Systems)
date: 2022-07-05
tags:
    - attack.command-and-control
    - attack.t1105
    - detection.threat-hunting
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith: '\curl.exe'
        - Product: 'The curl executable'
    selection_remote:
        CommandLine|contains:
            - ' -O'
            - '--remote-name'
            - '--output'
    condition: all of selection_*
falsepositives:
    - Scripts created by developers and admins
    - Administrative activity
level: medium

注目したいのはfalsepositivesの欄です。誤検知の原因をルール自体に書き残す欄が仕様として用意されているため、探索で分かった「これは開発者の作業だった」という知見を、次に見る担当者へそのまま渡せます。探索の空振りが資産になるのは、こうした欄に事実が積み上がるからです。

もう1つの資産が記録です。MITREのレポートは、悪性と判定した事象を共有可能な形で残す方法として、時系列の一覧(観測した活動を時刻順に並べ、利用者と端末やIPアドレスの文脈を添えたもの)、関係するホストの一覧、関係する利用者の一覧、確認された悪性プログラムや悪用された標準ツールの一覧、そしてホスト間の活動の連鎖を表す図を挙げています。悪性が確認できなかった探索についても、どの範囲をどの時間幅でどの仮説について見たかを同じ形で残しておくと、次の探索の出発点になります。

SigmaHQの公式リポジトリは、Sigmaを「関連するログイベントを分かりやすい形で記述できる、汎用的で開かれたシグネチャフォーマット」と定義し、内容がDetection Rule License (DRL) 1.1で公開されていると記載しています。ルールは用途別にrules、rules-threat-hunting、rules-emerging-threats、rules-compliance、rules-placeholderの5つのディレクトリに分かれています。

少人数の体制で続けるための回し方#

脅威ハンティングは専任チームがなければ始められない、というものではありません。始め方を現実的な規模に落とすと、週に数時間の枠を確保して、1回につき1つの仮説を検証する形になります。

最初の数回の期待値は、あらかじめ下げておくのが正しい姿勢です。MITREのレポートは、公開されている他の方法論を比較する箇所で、組織の初期の探索の成果は、未検知の攻撃者を実際に見つけることよりも、環境をよりよく理解することに集中する傾向があると書いています。これは経験を積んだ実務者の間では共通の理解だとも述べられています。侵害が見つからないことを失敗と呼ぶ運用にすると、探索は続きません。

代わりに残すべきものは、可視性の穴の一覧です。同レポートは、望ましいデータ収集と実際の収集との間に大きな差が見つかった場合、その差をどう扱うかを判定するよう求めています。新しいセンサーを入れられるなら入れますが、その際も導入コストの差を考慮に入れます。Windowsの監査ログのように、既に機能があって設定変更だけで有効になるものと、EDRのように調達と展開と調整が要るものでは、着手のしやすさが違います。センサーを増やせない場合は、他のデータで低い確度や粒度で代替できないかを検討し、その対応関係を記録します。そして、どの技術がデータ不足で見えないのかを把握し、その影響をネットワークの管理者に伝えることが最低条件として挙げられています。

小規模な組織でログ基盤そのものから整える場合は、CISAが無償で公開しているLogging Made Easy (LME)が選択肢になります。CISAはこれを、中小規模の組織向けに基本的なログ管理を提供する無償のソリューションと説明しており、共同ガイダンスも参照先の1つとして挙げています。

継続の枠組みとしては、NIST SP 800-137「Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations」(2011年9月公開)の考え方が使えます。同文書はISCMを「情報セキュリティ、脆弱性、脅威に関する継続的な認識を維持し、組織のリスク管理上の意思決定を支えること」と定義し、実施の流れをISCM戦略の定義、プログラムの確立、プログラムの実装、データの分析と結果の報告、結果への対応、戦略とプログラムの見直しと更新という6段階で示しています。探索の回し方をこの6段階に重ねると、単発の作業ではなく更新され続ける運用として位置づけられます。

指標の置き方には注意が要ります。「月に何件の侵害を見つけたか」を目標にすると、見つからないことが減点になり、無理な判定を招きます。MITREのレポートは報告の際の姿勢として、攻撃者の意図や能力について過度に憶測せず、分析から明らかになった事実に集中するよう求めています。数える対象は、検証した仮説の数、探索でカバーした技術と戦術の範囲、新たに判明した可視性の穴の数と解消した数、探索から常時監視へ昇格させたルールの数、そして探索で見つかった設定不備の数といった、作業の実体に対応するものにするほうが、運用として素直です。

従業員のログを扱うときの法令上の配慮#

探索の対象になるログには、従業員の識別子が紐づきます。誰がいつどの端末でどのコマンドを実行し、どのサイトへアクセスしたかという記録は、業務の記録であると同時に個人に関する情報でもあります。

個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン(通則編)」(令和8年6月一部改正)は、個人情報データベース等に該当する事例として「インターネットサービスにおいて、ユーザーが利用したサービスに係るログ情報がユーザーIDによって整理され保管されている電子ファイル(ユーザーIDと個人情報を容易に照合することができる場合)」を挙げています。社内のログ基盤も、利用者IDで整理され、そのIDから人事情報などによって個人を容易に特定できる状態であれば、同様の整理になり得ます。

その場合にかかるのは、まず利用目的の特定です。同ガイドラインは法第17条第1項に基づき、利用目的をできる限り特定しなければならないとしています。次に法第18条第1項の利用目的による制限があり、あらかじめ本人の同意を得ないで、特定された利用目的の達成に必要な範囲を超えて取り扱ってはならないとされています。取得した際には法第21条第1項により、あらかじめ利用目的を公表している場合を除き、速やかに本人へ通知するか公表する必要があります。

一方で、セキュリティ目的のログ分析そのものは、同ガイドラインが想定している取り扱いです。法第23条の安全管理措置について定めた別添「講ずべき安全管理措置の内容」の技術的安全管理措置には、外部からの不正アクセス等の防止の手法例として「ログ等の定期的な分析により、不正アクセス等を検知する」が明記されています。ハンティングは、この例示に沿う活動として位置づけられます。

実務としては、次のような整理が現実的です。就業規則や社内規程、プライバシーポリシーの中で、業務システムの利用状況を記録しセキュリティの確保を目的として分析することを明記し、周知しておきます。探索で得た記録を人事評価や勤怠管理に流用しないことを規程上で明確にします。ログを閲覧できる担当を限定し、誰がいつどのログを参照したかを残します。探索の過程では業務と無関係な私的な行動が視野に入ることがあるため、目的外の内容には触れずに調査を進める運用ルールを決めておきます。

なお、内部不正の疑いに発展した場合の扱いは、通常の探索とは別の手続きになります。MITREのレポートも、内部脅威に関係する可能性がある場合には、法執行機関や組織内の該当部門を関与させる必要があり、技術的および管理的な対応は事案ごとに判断すべきだと述べています。個別の適用可否は事案と社内規程によって変わるため、判断が必要な場面では法務部門や弁護士へ確認してください。

個人情報保護委員会のガイドライン(通則編)は、利用目的の特定を法第17条第1項、利用目的による制限を法第18条第1項、利用目的の通知又は公表を法第21条第1項、安全管理措置を法第23条として整理しています。別添の技術的安全管理措置には「ログ等の定期的な分析により、不正アクセス等を検知する」が手法の例として掲載されています。

まとめ#

脅威ハンティングは、道具を増やす話ではなく、見る順序を変える話です。機器が判定した結果から入るのではなく、攻撃者が使わざるを得ない技術から仮説を引き、その痕跡が残るはずの場所を決め、時間と範囲を区切って集計し、残ったものを1件ずつ潰していきます。

最初に立てる仮説は1つで足ります。自社の管理者がまず使わないと分かっている技術を選び、プロセス生成ログかプロキシログで2週間分を見る。それだけでも、除外すべき正常な振る舞いの姿と、記録されていない項目の存在が分かります。侵害が見つからなくても、その2つは次の探索を確実に速くします。

進めるうえで押さえておきたい点を最後にまとめます。