脅威ハンティングとは何か
脅威ハンティング(Threat Hunting)とは、アラートやインシデントが発生する前に、攻撃者がすでにシステム内に潜伏している可能性を前提として、能動的に脅威を探索するセキュリティ活動です。
リアクティブ対応 vs プロアクティブ対応
【リアクティブ(従来のSOC対応)】 アラート発生 → インシデント検知 → 調査・対応 → 封じ込め 問題点: すでに被害が発生している。攻撃者の滞留時間が長くなりやすい。
【プロアクティブ(脅威ハンティング)】 仮説の設定 → データ収集・分析 → 異常の発見 → 調査・対応 特徴: アラートに頼らず、人間の分析能力で潜伏する攻撃者を発見する。
Mandiant(Google Cloud)の調査では、攻撃者が環境内に潜伏してから検出されるまでの中央値(Dwell Time)は年々改善されているものの、依然として数十日に及ぶケースが存在します。脅威ハンティングはこの滞留時間を短縮するための重要な手段です。
脅威ハンティングが必要な理由
既存のセキュリティ製品(SIEM・EDR・IDS)はシグネチャや既知のパターンに基づいて検出を行います。しかし、以下のような攻撃はアラートを発生させずに進行することがあります。
- Living-off-the-Land(LotL)攻撃: 正規のシステムツール(PowerShell・WMI・certutil)のみを使った攻撃
- ゼロデイ脆弱性の悪用: シグネチャが存在しない新規手法
- スローバーニング攻撃: 長期間にわたる低頻度の通信でゆっくりとデータを持ち出す手法
- 設定済みルールを意図的に回避した攻撃: SOC のアラートチューニングの隙間を狙う手法
ハンティングプロセスの3フェーズ
フェーズ 1: 仮説の設定
仮説駆動型アプローチでは、まず「攻撃者がこの環境でどのような行動を取るか」という仮説を立てます。仮説の源泉は次のとおりです。
仮説の情報源:
-
MITRE ATT&CK フレームワーク
- 業界・セクター別の攻撃グループ(APT)の TTP
- 例: 「金融セクターを狙う APT41 が使う手法は何か?」
-
脅威インテリジェンス
- ISAC(情報共有分析センター)からの情報
- 商用 CTI フィード(Recorded Future、Mandiant TI など)
- 例: 「先月公開された CVE を悪用した攻撃が増加している」
-
過去のインシデント
- 自社または同業他社の過去事例
- 例: 「前回の侵害でスパイウェアが admin$ 共有経由で展開された」
-
セキュリティリサーチ・レポート
- ベンダーのホワイトペーパー・ブログ
- 例: 「最近報告された新しいランサムウェアの TTP を自環境で確認する」
フェーズ 2: データ収集と調査
仮説を検証するために必要なデータソースを特定し、クエリを用いて調査します。
主なデータソース:
エンドポイント:
- プロセス実行ログ(EDR、Sysmon)
- ファイル作成・変更ログ
- レジストリ変更ログ
- ネットワーク接続ログ
ネットワーク:
- ファイアウォールログ
- DNS クエリログ
- NetFlow / IPFIX データ
- プロキシログ
認証・ID:
- Active Directory ログ(イベントビューア)
- Azure AD / Entra ID サインインログ
- VPN/ZTNA アクセスログ
フェーズ 3: 分析と対応
収集したデータを分析し、異常を特定します。異常が確認された場合はインシデントレスポンスプロセスに引き継ぎます。また、発見した検出パターンは SIEM や EDR のルールとして登録し、次回から自動検出できるようにします。
ハンティングで発見した内容は「ルール化」することが重要です。毎回手動で探すのではなく、繰り返し発生し得るパターンを自動検出ルールに変換することで、SOC 全体の検出能力が向上します。
IOC と TTP の違い
IOC(Indicators of Compromise)
IOC は攻撃の「証拠」となる観測可能な情報です。
IOC の例:
- IP アドレス: 203.0.113.45(C2サーバー)
- ドメイン: malicious-update.example.com
- ファイルハッシュ: SHA256: a1b2c3d4e5f6…(マルウェアのハッシュ値)
- URL: http://evil.example.com/payload.exe
- レジストリキー: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Updater
問題点: IOC は攻撃者にとって変更コストが低い。IPやドメインを変えるだけで回避できる。 IOC だけでのハンティングは「Pyramid of Pain」の最下層に相当し、効果が限定的。
TTP(Tactics, Techniques, and Procedures)
TTP は攻撃者の「行動パターン」です。変更コストが高く、IOC よりも長期的に有効な検出基準です。
TTP の例(MITRE ATT&CK より):
- T1059.001: PowerShell を使ったコマンド実行
- T1078: 正規アカウントの悪用
- T1003.001: LSASS メモリからの資格情報ダンプ
- T1486: データの暗号化(ランサムウェア)
TTP の優位性:
- 攻撃者がツールを変えても、行動パターンは変わりにくい
- 複数の攻撃キャンペーンを同じルールで検出できる
- 「Pyramid of Pain」の最上層 = 攻撃者への影響が最大
David Bianco の「Pyramid of Pain」モデルでは、ハッシュ値・IP・ドメインといった IOC は攻撃者が容易に変更できる(対応コストが低い)のに対し、TTP は変更コストが非常に高く、TTP レベルで検出・防御できれば攻撃者に最大のダメージを与えられます。
MITRE ATT&CK を活用したハンティング
ATT&CK Navigator でハンティング計画を可視化
MITRE ATT&CK Navigator(https://mitre-attack.github.io/attack-navigator/)を使うと、現在の検出カバレッジと優先的にハンティングすべき領域を可視化できます。
ATT&CK Navigator の活用方法:
- 自社環境で有効な検出ルールを緑色でマッピング
- ハンティングで調査済みの手法を黄色でマッピング
- 自業界に対して実績のある APT グループの手法をオレンジでマッピング
- 未カバーかつリスクが高い領域を優先的にハンティング計画に組み込む
ハンティングツール
Velociraptor
Velociraptor はオープンソースのエンドポイント調査・ハンティングプラットフォームです。
Velociraptor クエリ(VQL)でPSExecのアーティファクトを検索
SELECT Pid, Name, CommandLine, CreateTime FROM pslist() WHERE Name =~ “PSEXESVC” OR CommandLine =~ “psexec”
最近作成された実行ファイルを検索(過去24時間)
SELECT FullPath, Size, Mtime, Ctime FROM glob(globs=“C:/Windows/Temp/*.exe”) WHERE Ctime > now() - 86400
YARA ルール
YARA はファイルやメモリ内のマルウェアパターンを検出するためのルール言語です。
rule Detect_Mimikatz_Strings { meta: description = “Mimikatz に特徴的な文字列を検出” author = “Threat Hunter” strings: $s1 = “sekurlsa::logonpasswords” nocase $s2 = “lsadump::sam” nocase $s3 = “privilege::debug” nocase $s4 = “mimikatz” nocase wide ascii condition: 2 of ($s*) }
Sigma ルール
Sigma は SIEM に依存しない汎用的な検出ルール記述形式です。
title: PSExec Remote Execution Detection status: stable description: PSExec によるリモート実行の検出 logsource: product: windows service: system detection: selection: EventID: 7045 ServiceName: ‘PSEXESVC’ condition: selection falsepositives:
- Legitimate use by system administrators level: high tags:
- attack.lateral_movement
- attack.t1021.002
具体的なハンティング例
例 1: PSExec の検出
Splunk で PSExec の痕跡を調査するクエリ
index=windows EventID=7045 | where ServiceName=“PSEXESVC” | table _time, host, ServiceName, ImagePath, StartType, AccountName | sort -_time
Elastic / OpenSearch でのクエリ(EQL)
event.code: “7045” AND winlog.event_data.ServiceName: “PSEXESVC”
例 2: DLL Sideloading の検出
DLL Sideloading は、正規のアプリケーションに悪意のある DLL を読み込ませる手法です。
Sysmon イベント ID 7(ImageLoaded)を使った検出
正規の Windows ディレクトリ以外からの DLL ロードを検出
index=sysmon EventCode=7 | where NOT (ImageLoaded LIKE “C:\Windows\%” OR ImageLoaded LIKE “C:\Program Files\%”) | stats count by Image, ImageLoaded, host | where count < 5 | sort -count
PowerShell でのプロセスの DLL 一覧確認
Get-Process | ForEach-Object { $proc = $_ $proc.Modules | Where-Object { $.FileName -notlike “C:\Windows*” -and $.FileName -notlike “C:\Program Files*” } | Select-Object @{N=“Process”;E={$proc.Name}}, FileName }
ハンティングで偽陽性(False Positive)が多く発生すると、ハンターが「アラート疲れ」を起こし、本当の脅威を見逃すリスクが高まります。ハンティングルールは段階的に精度を上げ、本番の SIEM ルールに追加する前にベースラインの確認を行います。
「Pyramid of Pain」モデルにおいて、攻撃者に最も大きなダメージを与える検出基準はどれですか?
脅威ハンティングにおける仮説駆動型アプローチで最初に行うべきことはどれですか?