threat-detection

脅威検知

仮説に基づくハンティング、IOC 分析、振る舞いの異常検知を通じて、攻撃者の活動を先回りして発見するための脅威検知スキルです。これはインシデント対応（incident-response を参照）でもレッドチーム運用（red-team を参照）でもありません。自動化された制御をすり抜けた脅威を発見することを目的としています。

---

目次

• 概要
• 脅威シグナルアナライザー
• 脅威ハンティングの方法論
• IOC 分析
• 異常検知
• MITRE ATT&CK シグナルの優先順位付け
• デセプションとハニーポットの統合
• ワークフロー
• アンチパターン
• 相互参照

---

概要

このスキルでできること

このスキルでは、プロアクティブな脅威検知のための方法論とツールを提供します。アラートが発生する前に、体系的なハンティング仮説、IOC 分析、統計的な異常検知を通じて攻撃者の活動を発見します。

他のセキュリティスキルとの違い

スキル	対象	アプローチ
threat-detection（このスキル）	潜在する脅威の発見	プロアクティブ — アラートの前にハンティング
incident-response	進行中のインシデント	リアクティブ — 宣言されたインシデントを封じ込めて調査
red-team	攻撃シミュレーション	攻撃者の視点から防御をテスト
cloud-security	クラウドの設定ミス	セキュリティ態勢 — IAM、S3、ネットワークへの露出

前提条件

SIEM／EDR テレメトリ、エンドポイントログ、ネットワークフローデータへの読み取りアクセスが必要です。誤検知を避けるため、IOC フィードは30日以内に更新されたものを使用してください。ハンティング仮説は実行前に環境に合わせて範囲を定める必要があります。

---

脅威シグナルアナライザー

threat_signal_analyzer.py ツールは、hunt（仮説のスコアリング）、ioc（スイープの生成）、anomaly（統計的検知）の3つのモードに対応しています。

# Hunt mode: score a hypothesis against MITRE ATT&CK coverage
python3 scripts/threat_signal_analyzer.py --mode hunt \
  --hypothesis "Lateral movement via PtH using compromised service account" \
  --actor-relevance 3 --control-gap 2 --data-availability 2 --json

# IOC mode: generate sweep targets from an IOC feed file
python3 scripts/threat_signal_analyzer.py --mode ioc \
  --ioc-file iocs.json --json

# Anomaly mode: detect statistical outliers in telemetry events
python3 scripts/threat_signal_analyzer.py --mode anomaly \
  --events-file telemetry.json \
  --baseline-mean 100 --baseline-std 25 --json

# List all supported MITRE ATT&CK techniques
python3 scripts/threat_signal_analyzer.py --list-techniques

IOC ファイル形式

{
  "ips": ["1.2.3.4", "5.6.7.8"],
  "domains": ["malicious.example.com"],
  "hashes": ["abc123def456..."]
}

テレメトリイベントファイル形式

[
  {"timestamp": "2024-01-15T14:32:00Z", "entity": "host-01", "action": "dns_query", "volume": 450},
  {"timestamp": "2024-01-15T14:33:00Z", "entity": "host-02", "action": "dns_query", "volume": 95}
]

終了コード

コード	意味
0	優先度の高い検出結果なし
1	優先度が中程度のシグナルを検出
2	優先度の高い確定済みの検出結果

---

脅威ハンティングの方法論

体系的な脅威ハンティングは、仮説 → データソースの特定 → クエリの実行 → 検出結果のトリアージ → 検知エンジニアリングへのフィードバックという5段階のループで進めます。

仮説のスコアリング

要素	重み	説明
攻撃者との関連性	×3	この TTP は、あなたの業界で知られている脅威アクターにどの程度合致しますか？
制御のギャップ	×2	既存の制御のうち、この振る舞いを見逃すものはいくつありますか？
データの可用性	×1	この仮説を検証するために必要なテレメトリデータを利用できますか？

優先度スコア = (actor_relevance × 3) + (control_gap × 2) + (data_availability × 1)

戦術ごとの価値の高いハンティング仮説

仮説	MITRE ID	データソース	優先シグナル
リモート実行による WMI 横展開	T1047	WMI ログ、EDR プロセステレメトリ	WINRM から WMI プロセスが起動、通常とは異なる親子プロセスの連鎖
防御回避を目的とした LOLBin の実行	T1218	プロセス作成、コマンドライン引数	certutil.exe、regsvr32.exe、mshta.exe にネットワークアクティビティが伴う
ジッターの大きい間隔によるビーコン型 C2 通信	T1071.001	プロキシログ、DNS ログ	±10% のジッターを伴う、一定間隔での外向き接続
Pass-the-Hash による横展開	T1550.002	Windows セキュリティイベント 4624（種類 3）	予期しない送信元ホストから管理共有への NTLM 認証
LSASS メモリアクセス	T1003.001	EDR メモリアクセスイベント	システムプロセス以外から lsass.exe に対する OpenProcess
Kerberoasting	T1558.003	Windows イベント 4769	サービスアカウントに対する大量の TGS リクエスト
スケジュールタスクによる永続化	T1053.005	Sysmon イベント 1／11、Windows 4698	標準外のディレクトリにスケジュールタスクを作成

IOC 分析

IOC 分析では、インジケーターが最新かどうかを判断し、必要なスイープ対象に対応付けるとともに、誤検知の原因となる古いデータを除外します。

IOC の種類とスイープの優先度

IOC の種類	鮮度のしきい値	スイープ対象	MITRE のカバレッジ
IP アドレス	30 日	ファイアウォールログ、NetFlow、プロキシログ	T1071, T1105
ドメイン	30 日	DNS リゾルバーログ、プロキシログ	T1568, T1583
ファイルハッシュ	90 日	EDR のファイル作成ログ、AV スキャンログ	T1105, T1027
URL	14 日	プロキシアクセスログ、ブラウザー履歴	T1566.002
Mutex 名	180 日	EDR の実行時アーティファクト	T1055

IOC の鮮度管理

しきい値を超えて古くなった IOC は stale としてフラグ付けされ、スイープ対象の生成から除外されます。古い IOC に対してスイープを実行すると、誤検知率が上昇し、SOC の信頼性が低下します。ハントサイクルの前に毎回、脅威インテリジェンスプラットフォーム（MISP、OpenCTI、商用 TI）から IOC フィードを更新してください。

---

異常検知

統計的な異常検知では、既知の悪性シグネチャに頼らず、確立されたベースラインから逸脱する挙動を特定します。

Z スコアのしきい値

Z スコア	分類	対応
< 2.0	正常	対応不要
2.0–2.9	軽度の異常	ログに記録して監視 — サンプリングを増やす
≥ 3.0	重大な異常	ハントアナリストにエスカレーション — エンティティを調査する

ベースラインの要件

効果的な異常検知には、有効なベースラインを確立するために、過去 14 日以上のテレメトリが必要です。次の場合には、ベースラインを再計算する必要があります。

• セキュリティインシデント（インシデント後の挙動変化）
• 大規模なインフラ変更（クラウド移行、新たな SaaS の導入）
• 季節的な利用パターンの変化（四半期末、休暇期間）

優先度の高い異常検知対象

エンティティの種類	指標	異常の兆候
DNS リゾルバー	ホストあたりの 1 時間ごとのクエリ数	ビーコン通信、トンネリング、DGA
エンドポイント	1 日あたりの一意なプロセス実行数	マルウェアのインストール、LOLBin の悪用
サービスアカウント	1 時間ごとの認証イベント数	クレデンシャルスタッフィング、ラテラルムーブメント
メールゲートウェイ	1 時間ごとの添付ファイルの種類別件数	フィッシングキャンペーンの急増
クラウド IAM	ID あたりの 1 時間ごとの API 呼び出し数	クレデンシャルの侵害、情報の持ち出し

---

MITRE ATT&CK のシグナル優先順位付け

各ハンティング仮説は、1 つ以上の ATT&CK テクニックに対応付けられます。環境内で複数のシグナルが確認されているテクニックほど、優先度が高くなります。

戦術カバレッジマトリクス

| 戦術 | 主なテクニック | 主なデータソース | |--------|---------------|--------------------|-| | 初期アクセス | T1190, T1566, T1078 | Web アクセスログ、メールゲートウェイ、認証ログ | | 実行 | T1059, T1047, T1218 | プロセス作成、コマンドライン、スクリプト実行 | | 永続化 | T1053, T1543, T1098 | スケジュールされたタスク、サービス、アカウント変更 | | 防御回避 | T1027, T1562, T1070 | プロセスのハロウイング、ログ消去、エンコード | | 認証情報アクセス | T1003, T1558, T1110 | LSASS、Kerberos、認証失敗 | | ラテラルムーブメント | T1550, T1021, T1534 | NTLM 認証、リモートサービス、内部スピアフィッシング | | 収集 | T1074, T1560, T1114 | ステージングディレクトリ、アーカイブ作成、メールアクセス | | 持ち出し | T1048, T1041, T1567 | 通常と異なるアウトバウンド通信量、DNS トンネリング、クラウドストレージ | | コマンド＆コントロール | T1071, T1572, T1568 | ビーコン通信、プロトコルトンネリング、DNS C2 |

---

デセプションとハニーポットの統合

デセプション資産は高精度のアラートを生成します。ハニーポットへの接触は、調査が必要であることを明確に示すシグナルです。

デセプションアセットの種類と配置

アセットの種類	配置場所	シグナル	ATT&CK 手法
パスワード保管庫内のハニーポット認証情報	保管庫のシークレットストア	認証情報へのアクセス試行	T1555
ハニートークン（偽の AWS アクセスキー）	Git リポジトリ、S3 オブジェクト	偵察または情報流出	T1552.004
ハニーファイル（ファイル名：passwords.xlsx）	ファイル共有、エンドポイント	収集の準備	T1074
ハニーアカウント（休眠中の AD ユーザー）	Active Directory	ラテラルムーブメントの足掛かり	T1078.002
ハニーポットネットワークサービス	DMZ、フラットなネットワークセグメント	ネットワークスキャン、サービスの悪用	T1046, T1190

ハニーポットのアラートは標準のスコアリングパイプラインを迂回します。いずれかのヒットは、そうでないと証明されるまで自動的に SEV2 として扱われます。

---

ワークフロー

ワークフロー 1：クイックハント（30 分）

新しい脅威インテリジェンスレポートまたは CVE アラートへの対応に使用します。

# 1. Score hypothesis against environment context
python3 scripts/threat_signal_analyzer.py --mode hunt \
  --hypothesis "Exploitation of CVE-YYYY-NNNNN in Apache" \
  --actor-relevance 2 --control-gap 3 --data-availability 2 --json

# 2. Build IOC sweep list from threat intel
echo '{"ips": ["1.2.3.4"], "domains": ["malicious.tld"], "hashes": []}' > iocs.json
python3 scripts/threat_signal_analyzer.py --mode ioc --ioc-file iocs.json --json

# 3. Check for anomalies in web server telemetry from last 24h
python3 scripts/threat_signal_analyzer.py --mode anomaly \
  --events-file web_events_24h.json --baseline-mean 80 --baseline-std 20 --json

判断：ハント優先度が 7 以上の場合、またはいずれかの IOC スイープでヒットした場合は、フルハントにエスカレーションします。

ワークフロー 2：フル脅威ハント（複数日）

1 日目 — 仮説の生成：

1. 業界に関連する TTP について、脅威インテリジェンスフィードを確認します
2. 過去 30 日間のセキュリティアラートを ATT&CK の戦術にマッピングし、ギャップを特定します
3. threat_signal_analyzer.py のハントモードで、上位 5 件の仮説をスコアリングします
4. スコア順に優先順位を付け、最も高いものから着手します

2 日目 — データ収集とクエリ実行：

1. SIEM から関連するテレメトリを取得します（日付範囲：過去 14 日間）
2. エンティティのベースライン全体で異常検知を実行します
3. 30 日以内に更新されたすべてのフィードを対象に IOC スイープを実行します
4. references/hunt-playbooks.md のハントプレイブックを確認します

3 日目 — トリアージとレポート：

1. すべての異常検知結果をトリアージし、確認または却下します
2. 確認された活動をインシデント対応チームにエスカレーションします
3. ハントの結果から新たな検知ルールを文書化します
4. 誤検知の IOC を TI プロバイダーに返送します

ワークフロー 3：継続的な監視（自動化）

主要なエンティティのベースラインに対する定期的な異常検知を、6 時間間隔で実行するよう設定します。

# Run as cron job every 6 hours — auto-escalate on exit code 2
python3 scripts/threat_signal_analyzer.py --mode anomaly \
  --events-file /var/log/telemetry/events_6h.json \
  --baseline-mean "${BASELINE_MEAN}" \
  --baseline-std "${BASELINE_STD}" \
  --json > /var/log/threat-detection/$(date +%Y%m%d_%H%M%S).json

# Alert on exit code 2 (hard anomaly)
if [ $? -eq 2 ]; then
  send_alert "Hard anomaly detected — threat_signal_analyzer"
fi

---

アンチパターン

1. 仮説なしでハントする — 明確な問いを設定せず、すべてのテレメトリに対して広範なクエリを実行すると、シグナルではなくノイズが生まれます。すべてのハントは、1 つまたは 2 つの ATT&CK 手法に範囲を絞った、検証可能な仮説から始める必要があります。
2. 古い IOC を使用する — 30 日を超えた IOC は誤検知を生み、アナリストがアラートを無視するようになる原因となります。スイープの前に必ず IOC の鮮度を確認し、自動スイープから古いインジケーターを除外してください。
3. ベースラインの確立を省略する — 有効なベースラインなしで異常検知を行うと、通常の高トラフィック日にアラートが発生します。いずれのエンティティタイプでも統計的アラートを有効にする前に、14 日以上のベースラインデータを必須としてください。
4. 既知の手法だけをハントする — 文書化済みの ATT&CK 手法だけを対象にしたハントでは、新しい敵対者の振る舞いを見逃します。未知の TTP を発見できる、範囲を限定しない異常分析も定期的に取り入れてください。
5. 検知エンジニアリングへのフィードバックループを閉じない — 悪意のある振る舞いを確認したハント結果から、新たな検知ルールを作成する必要があります。検知範囲の改善につながらないハントには、長期的な価値がありません。
6. すべての異常を確定済みの脅威として扱う — 高い z スコアはベースラインからの逸脱を示すものであり、悪意が確認されたことを意味しません。すべての異常は、エスカレーションの前に人間がトリアージし、確認または却下する必要があります。
7. ハニーポットのアラートを無視する — デセプションアセットとのやり取りは、いずれも信頼性の高いシグナルです。ハニーポットのアラートをノイズとして扱うと、デセプションへの投資全体が無意味になります。

---

相互参照

スキル	関連性
incident-response	ハンティングで確認された脅威は、トリアージと封じ込めのために incident-response にエスカレーションされます
red-team	レッドチーム演習で生成された現実的な TTP が、ハント仮説の優先順位付けに役立ちます
cloud-security	クラウドのセキュリティ態勢に関する検出結果（公開状態の S3、IAM のワイルドカード）から、データ流出の TTP を対象としたハンティング対象が生まれます
security-pen-testing	ペネトレーションテストの検出結果から、脅威ハンティングで修正後に監視すべき攻撃対象領域を特定できます