脅威ハンティング（Threat Hunting）とは？プロアクティブな脅威検出の手法と中小企業での始め方

「EDRを導入したのに、本当に侵入されていないか確信が持てない」「ログを見ても、何が正常で何が異常なのか判断できない」——そんな悩みを抱えている情シスの方は多いはずです。

セキュリティ製品は「検知できる脅威」を自動でブロックしてくれますが、熟練した攻撃者はその検知ロジックを意図的に回避し、数週間から数か月にわたって社内ネットワークに潜伏します。こうした「すり抜けた脅威」を能動的に探し出す活動が脅威ハンティング（Threat Hunting）です。

この記事では、脅威ハンティングの基本概念と従来のSOC対応との違い、MITRE ATT&CKを使った実践的な手順、そして情シス1人体制の中小企業でも今日から始められる最初の一歩まで、現場目線で解説します。

脅威ハンティングとは？受動的な監視との決定的な違い

脅威ハンティングとは、アラートが発生するのを待つのではなく、攻撃者がすでに侵入しているという仮説を出発点に、能動的に証拠を探す活動のことです。

従来のSOC（セキュリティオペレーションセンター）は、SIEMやEDRが発するアラートに対応する「反応型」のアプローチをとります。これは効率的ですが、アラートを出さない攻撃には対応できません。

脅威ハンティングは、その盲点を補うために登場しました。具体的には次のような考え方に基づいています。

・侵害前提（Assume Breach）: 「すでに攻撃者が侵入している可能性がある」という前提で調査する
・仮説駆動型: 攻撃者の行動パターン（TTPs）から仮説を立て、その証拠をデータの中から探す
・反復的なプロセス: 1回やって終わりではなく、定期的に繰り返すことで精度を高める

脅威ハンティングの成果は2種類あります。脅威を「発見する」ことと、脅威が「いない」と確認することです。どちらの結果も、自社のセキュリティ態勢を正確に把握するうえで価値があります。

なぜ今、脅威ハンティングが必要なのか

攻撃の高度化が進む中で、従来の検知ベースのセキュリティだけでは限界が見えてきています。その理由は大きく3つです。

1. 検知回避技術の進化

攻撃者は今や、Windowsに標準搭載されているツール（PowerShell、WMI、certutil など）を使って攻撃します。こうした「正規ツールの悪用（LOLBins）」は、多くのEDRやアンチウイルスからは正常な動作に見えてしまいます。

2. 潜伏期間の長期化

世界的なセキュリティレポートによると、攻撃者が侵入から発覚までにかかる平均時間（Dwell Time）は数十日から数か月に及びます。この間に攻撃者は内部偵察を行い、ラテラルムーブメント（横移動）で権限を拡大していきます。アラートが出ない状態でこの長期潜伏を発見できるのは、脅威ハンティングだけです。

3. ゼロデイ・未知の脅威への対応

シグネチャベースの検知は、既知の攻撃パターンにしか対応できません。新しい攻撃手法や組み合わせには、ルールベースの自動検知が追いつかないことがあります。脅威ハンティングは、こうした「未知の未知（Unknown Unknown）」を探るためにも有効なアプローチです。

攻撃者はどうやって「潜伏」するのか

脅威ハンティングを始める前に、攻撃者がどのような手口で潜伏するかを理解しておく必要があります。主な手法を整理します。

・初期侵入後の「棲み着き（Persistence）」: レジストリの自動起動エントリ、スケジュールタスク、サービスへのバックドア仕込みなど、再起動後も生き残る仕掛けを作る
・防御回避（Defense Evasion）: ログの削除・改ざん、正規プロセスへのコードインジェクション、タイムスタンプ操作でツールの痕跡を消す
・認証情報の収集（Credential Access）: メモリ上の認証情報（LSASSプロセス）やブラウザの保存パスワードを窃取し、他のアカウントに成りすます
・内部偵察（Discovery）: ネットワーク構成の調査、ADユーザー一覧の取得、共有フォルダの探索で次の標的を見定める
・横移動（Lateral Movement）: 窃取した認証情報や脆弱性を使って他のサーバーへ移動し、権限を段階的に拡大する

これらの行動パターンはMITRE ATT&CKフレームワークに体系化されており、脅威ハンティングの仮説立案に直接活用できます。

脅威ハンティングの実践ステップ

脅威ハンティングは「アラート対応」とは別の知的作業です。以下の3ステップで進めます。

1. 仮説を立てる（Hypothesis設定）

最初のステップは、「どのような攻撃が行われている可能性があるか」という仮説を設定することです。仮説なしにデータをやみくもに見ても、異常を見つけ出すことは困難です。

仮説の出発点にはMITRE ATT&CKが最適です。例えば、次のような形で仮説を立てます。

・「攻撃者がスケジュールタスク（T1053）を使ってPersistenceを確立しているかもしれない」
・「PowerShellのダウンロードコマンドが実行されているかもしれない（T1059.001）」
・「LSASSプロセスのメモリダンプが行われたかもしれない（T1003.001）」

仮説はシンプルなものから始めて問題ありません。自社環境でよく使われるツールやプロセスを軸に考えると取り組みやすくなります。また、脅威インテリジェンス（最新の攻撃グループの手口情報）を組み合わせると、業種や地域に合った的を絞った仮説を立てることができます。

2. データを収集・分析する

仮説が立ったら、それを検証するためのデータを集めます。主なデータソースは以下の通りです。

・EDRのテレメトリ: プロセスの親子関係、コマンドライン引数、ファイル操作ログ、ネットワーク接続先
・Windowsイベントログ: ログオン/ログオフ（4624/4625）、特権使用（4672）、サービス作成（7045）、スケジュールタスク作成（4698）
・ネットワークログ: 通常とは異なる通信先、非標準ポートの使用、業務時間外の大量データ転送
・PowerShellログ: スクリプトブロックログ（4104）でコマンド実行内容を確認

SIEMがあれば複数ソースのログを横断して検索できます。SIEMがない場合は、Windows Defenderのログを直接確認したり、EDRのタイムライン表示を活用したりします。

例えば「スケジュールタスク作成」の仮説を検証するなら、PowerShellで次のようにWindowsイベントを確認します。

# EventID 4698: スケジュールタスクの作成を確認
Get-WinEvent -LogName Security | Where-Object { $_.Id -eq 4698 } | Select-Object TimeCreated, Message | Format-List

# EventID 4702: スケジュールタスクの更新を確認（既存タスクの改ざん検知）
Get-WinEvent -LogName Security | Where-Object { $_.Id -eq 4702 } | Select-Object TimeCreated, Message | Format-List

# 直近7日間に絞る場合
$startDate = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4698; StartTime=$startDate}

分析のポイントは「ベースラインからの逸脱」を見つけることです。通常の業務で使われるスケジュールタスクが3件あるなら、それ以外のタスクが仮説を裏付ける証拠候補になります。

3. 発見した脅威を対処・記録する

仮説を裏付ける証拠が見つかった場合、インシデント対応手順書に従って封じ込め・根絶・復旧を進めます。迷ったときは「封じ込めを優先し、証拠を保全してから詳細調査」が基本の順序です。

脅威が「いない」と確認できた場合も、必ず記録しておきます。「どのデータを使って何を確認したか」を残しておくことで、次回のハンティングで同じ作業を省き、より高度な仮説に時間を使えるようになります。記録のフォーマット例を示します。

・仮説: 攻撃者がスケジュールタスクを使ってPersistenceを確立しているかもしれない
・確認したデータ: セキュリティイベントログ（EventID 4698/4702）、直近30日分
・結果: 業務で使用する既知のタスク3件を確認。不審なタスクは見つからなかった
・次のアクション: 既知タスクをホワイトリストに登録し、次回からの差分確認を自動化する

中小企業の情シスが今日から始められること

「脅威ハンティングはSOCチームがいる大企業向け」というイメージがあるかもしれません。しかし実際には、スモールスタートで十分な効果が得られます。まずは以下の3つから始めてみてください。

1. ログの保持期間を延ばす

脅威ハンティングの前提は、過去のログが残っていることです。Windowsのデフォルト設定ではイベントログが上書きされてしまうため、まずはセキュリティログの最大サイズを増やして、最低でも90日分を保持できる環境を整えましょう。

# セキュリティログの最大サイズを512MBに変更（管理者権限で実行）
wevtutil sl Security /ms:536870912

# アプリケーションログも同様に拡大
wevtutil sl Application /ms:536870912

# 現在の設定を確認
wevtutil gl Security

2. 異常な親子プロセス関係を週次で確認する

攻撃者がLOLBinsを使う場合、通常とは異なる「親プロセス → 子プロセス」の関係が生まれます。例えば「Word → PowerShell」「Excel → cmd.exe」「ブラウザ → certutil.exe」のような組み合わせは、マクロ悪用やドライブバイダウンロードの典型的な痕跡です。

EDRのプロセスツリー表示や、SIEMのログ検索で、こうした不審な組み合わせを週1回チェックするだけでも、脅威ハンティングの実質的な入り口になります。

3. 社外への通信量を週次でチェックする

攻撃者がデータを持ち出す（Exfiltration）フェーズでは、通常より大量のデータが社外へ転送されます。ファイアウォールのログで送信バイト数が多い通信先を週次で確認し、ビジネス上の理由が説明できないものを洗い出す習慣をつけましょう。深夜・早朝の通信や、普段接続しない国・地域への通信は特に注意が必要です。

よくある誤解と注意点

【誤解1】「脅威ハンティングは毎日やらなければならない」

始めたばかりの段階では、月1回や四半期に1回から始めて問題ありません。重要なのは「やり続けること」と「毎回記録を残すこと」です。継続することで自社の「正常な状態」のベースラインが明確になり、異常の検出精度が上がっていきます。

【誤解2】「高価なツールがないとできない」

Windowsの標準イベントログ、無料のSysmon（詳細なプロセス監視を追加するMicrosoftのツール）、Linux環境ならFalcoなど、コストをかけずに始められるツールはあります。まずは手元のデータでできることから着手しましょう。

【誤解3】「脅威が見つからなかったら意味がない」

「確認して問題がなかった」という事実も重要な知見です。次回のハンティングの基準線（ベースライン）になりますし、確認したデータをホワイトリスト化することで、将来の異常検知の精度が上がります。「いないことを確認できた」は、セキュリティ態勢の改善そのものです。

【注意】実環境でのコマンド実行は慎重に

調査のために実行するコマンドが、意図せずシステムに影響を与える場合があります。変更を加えるコマンドは必ず権限を確認し、本番環境では読み取り専用の操作にとどめるのが原則です。また、調査内容は必ず記録し、後から「何をしたか」を説明できる状態にしておきましょう。

本記事のまとめ

脅威ハンティングは、自社のセキュリティ態勢を「守っているつもり」から「正しく知って守っている」状態へと引き上げるための重要なプロセスです。最初は月1回、MITRE ATT&CKのひとつの戦術を選んでログを確認するだけで十分です。その小さな積み重ねが、将来の大きな被害を防ぐ礎になります。

姉妹サイトLinuxMaster.JPでは、Linuxサーバーのログ管理やセキュリティ設定についても詳しく解説しています。Linux環境の脅威ハンティングに取り組む際はあわせて参照してみてください。