engineering-detections

検知エンジニアリング

検知とは、攻撃者の振る舞いに関する仮説をクエリとして表現したもので、人間にアラートを通知します。導入する価値があるかどうかは、次の2つの特性で決まります。その振る舞いを検知するか、そしてそれ以外の場合は静かなままでいるかです。ほとんどのルールは後者のテストに失敗し、そのコストを負担するのはオンコール担当者です。

使用する場面

• TTP、サンプル、またはインシデントをもとに新しい検知ルールを作成する
• ノイズが多い、または反応しない既存のルールをレビューまたは調整する
• 脅威インテリジェンスを導入可能な検知コンテンツに変換する
• ATT&CK に対する検知カバレッジを評価する
• 検知のコード化（リポジトリの構成、テスト、CI、デプロイ）を設定する

使用しない場面

• 未知の侵害を今すぐ探す — hunting-threats を使用してください
• 進行中のインシデントに対応する — responding-to-incidents を使用してください
• 検知対象のサンプルを分析する — analyzing-malware を使用してください
• ファイル／メモリシグネチャを作成する — writing-yara-rules を使用してください。ログ／SIEM ルールの場合は writing-sigma-rules を使用してください
• 予防的な制御とハードニング — ハードニングは検知ではありません。ルールは攻撃経路を塞ぐ代わりにはなりません

詳細スキルへの案内

注目点	スキル
ポータブルな Sigma ルールの作成に特化 — フィールド分類、修飾子、バックエンド変換、SigmaHQ 標準	writing-sigma-rules

このスキルでは、Sigma、YARA、Suricata にわたる検知ライフサイクル全体を扱います。Sigma ルールそのものと、対象 SIEM への変換が作業の中心である場合は、writing-sigma-rules を使用してください。

アーティファクトではなく振る舞いを検知する

攻撃者が変更するために要するコストを基準に、作成するルールに優先順位を付けます。

Hash              trivial to change      → block, don't alert
IP / domain       days                   → block + low-severity alert
Filename / path   trivial                → weak signal, combine only
Tooling artifact  weeks (recompile)      → good, decays
Behaviour / TTP   expensive              → this is the target

ペイン・オブ・ペインの考え方が、この分野の根幹です。mimikatz.exe を対象にしたルールには価値がありません。一方、PROCESS_VM_READ を使って LSASS のハンドルを開くプロセスを対象にしたルールなら、同じ動作をするあらゆるツールを検知できます。

ルール開発のサイクル

1. Hypothesis   → what behaviour, by whom, visible where?
2. Data check   → is the required telemetry actually collected and retained?
3. Draft        → write the logic against real data
4. FP analysis  → run over 30+ days of production data, characterize every hit
5. Tune         → narrow with attacker-independent conditions only
6. Test         → prove it fires on an emulated true positive
7. Document     → triage steps, response, and known limits
8. Deploy       → with a severity that matches the actual response
9. Review       → re-test after telemetry, environment, or tooling changes

ステップ2で、ほかのどの段階よりも多くのルールが失敗します。ロジックを書く前に、そのフィールドが存在すること、対象とするプラットフォームで値が記録されること、そして有効な期間にわたって保持されることを確認してください。エージェントが送信しないフィールドを使ったルールは、カバレッジがあるように見せかけるだけです。マップ上に表示されるため、ルールがないよりも悪い結果になります。

Sigma の作成

Sigma はポータブルな形式です。1回書けば、バックエンドごとに変換できます。

title: LSASS Memory Access from Unusual Process
id: 9f2b1c4e-0000-4000-8000-000000000001
status: experimental
description: >
  Detects a process obtaining a handle to lsass.exe with read/clone access,
  the common precondition for credential dumping regardless of tooling.
references:
  - https://attack.mitre.org/techniques/T1003/001/
author: secskills
date: 2026-07-26
logsource:
  product: windows
  category: process_access
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      # QUERY_LIMITED_INFORMATION 0x1000 | QUERY_INFORMATION 0x0400
      # VM_READ 0x0010 | VM_WRITE 0x0020 | VM_OPERATION 0x0008
      - '0x1010'   # QUERY_LIMITED | VM_READ        — minimum to read lsass
      - '0x1410'   # QUERY_LIMITED | QUERY_INFO | VM_READ
      - '0x1438'   # the classic mimikatz mask: adds VM_WRITE | VM_OPERATION
  filter_legitimate:
    SourceImage|startswith:
      - 'C:\Program Files\<your EDR>\'
      - 'C:\Windows\System32\wbem\WmiPrvSE.exe'
  condition: selection and not filter_legitimate
falsepositives:
  - EDR and backup agents; enumerate yours and filter by full path
  - Windows Error Reporting on crash
level: high
tags:
  - attack.credential-access
  - attack.t1003.001

変換：

sigma convert -t splunk -p sysmon rules/lsass_access.yml
sigma convert -t esql -p ecs_windows rules/lsass_access.yml     # Elastic
sigma convert -t kusto -p microsoft_xdr rules/lsass_access.yml  # Defender/Sentinel

誠実さを保つルールの調整： 攻撃者が選べない要素でフィルタリングしてください。署名済みベンダーバイナリの完全なパス、特定のサービス SID、親子プロセスの組み合わせは適切です。攻撃者が制御できるファイル名、ユーザー名の文字列、コマンドラインの一部でフィルタリングするのは調整ではありません。ルールに回避策を組み込むことになります。

ネットワーク検知の作成

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"Beacon: HTTP POST, no User-Agent, fixed small body";
    flow:established,to_server;
    http.method; content:"POST";
    http.header_names; content:!"User-Agent";
    threshold:type both, track by_src, count 10, seconds 600;
    classtype:trojan-activity;
    metadata:attack_target Client_Endpoint, mitre_technique_id T1071;
    sid:1000101; rev:1;
)

暗号化されたトラフィックは、コンテンツではなくメタデータを対象に検知します。JA3／JA4 フィンガープリント、証明書の異常、SNI／DNS パターン、そして最も持続性の高いビーコンのタイミングが対象です。ジッターを伴う規則的な間隔は、信頼性を損なわずに攻撃者が手放すのが困難です。

-- Beacon candidate: low variance in connection interval, sustained
SELECT src_ip, dst_ip, count(*) AS n,
       stddev(delta_seconds) AS jitter, avg(delta_seconds) AS interval
FROM connection_deltas
WHERE ts > now() - interval '7 days'
GROUP BY src_ip, dst_ip
HAVING count(*) > 50 AND stddev(delta_seconds) < 0.15 * avg(delta_seconds)
ORDER BY n DESC;

大規模な検知に向けた YARA の作成

すべてのエンドポイントにあるすべてのファイルに対して実行されるルールは、分析用ルールとはコストの特性が異なります。まず、コストの低い条件で対象を絞り込んでください。

rule Suspicious_Loader_Pattern
{
    meta:
        author = "secskills"
        date   = "2026-07-26"
        scope  = "endpoint scanning"      // vs. hunting/triage
    condition:
        // Cheap gates before expensive string matching
        uint16(0) == 0x5A4D and filesize < 500KB and
        pe.imports("kernel32.dll", "VirtualAlloc") and
        pe.imports("kernel32.dll", "CreateThread") and
        math.entropy(0, filesize) > 7.0
}

デプロイ前に、必ずクリーンなファイルのコーパスに対してテストしてください。100万ファイルの環境全体で誤検知率が 0.1% の YARA ルールは、アラートを1,000件発生させます。

誤検知分析こそが仕事です

「正しそうに見えた」という理由だけでデプロイしてはいけません。必要な証拠は次のとおりです。

確認項目	基準
30日以上の本番データに対する過去データでの実行	ヒットを数えるだけでなく、すべてのヒットを分類する
アラート件数の予測	受信するチームのトリアージ能力に収まる
無害な原因の列挙	それぞれを falsepositives に記録し、フィルターまたはトリアージ時の注記を添える
真陽性テスト	振る舞いをエミュレートした実行で検知する

# Emulate the behaviour to prove the rule fires
atomic-red-team -T T1003.001              # Atomic Red Team
caldera / prelude operator                 # adversary emulation frameworks
# Then confirm: alert fired, fields populated, triage steps sufficient

エミュレートすることが危険なためルールをテストできない場合は、その旨をドキュメントに記載し、未検証のルールとして明示してください。テスト済みのカバレッジとして、何も記載せずに通過させてはいけません。

カバレッジ測定

ルールをATT&CKにマッピングします。ただし、マップは正しく読み取ってください。

# Generate a layer for the ATT&CK Navigator from your rule set
python3 scripts/rules_to_navigator.py rules/ > coverage.json

誠実なカバレッジの集計：

• ルールがその手法のエミュレーションに対してテストされ、必要なテレメトリがフリート全体で収集されている場合にのみ、その手法はカバー済みです。
• 手法ごとにルールが1つあるだけでは、カバレッジとは言えません。手法には多くの手順があります。T1055（プロセスインジェクション）には、実質的に異なる実装が12種類ほどあります。
• カバレッジは単一のパーセンテージではなく、テスト済み／未テスト／テレメトリなしとして報告してください。未テストのルールから作られた緑色のNavigatorレイヤーは、セキュリティチームが自分たちを欺く最もよくある方法です。

Detection as Code

detections/
├── rules/            # Sigma source of truth, one file per rule
├── tests/            # unit tests: sample events → expected match/no-match
├── filters/          # environment-specific allowlists, kept OUT of the rules
├── deployed/         # generated backend queries (build artifact, never edited)
└── .github/workflows/ci.yml

CIでは、すべてのルールをリントおよびスキーマ検証し、すべてのルールに一意のidと空でないfalsepositivesがあることを確認し、ユニットテストを実行し、各ターゲットバックエンド向けに変換し、変換エラーがあれば失敗させます。ルールをバージョン管理し、プルリクエストでレビューします。また、環境フィルターを検出ロジックから分離して、環境情報を漏らすことなくルールを共有したり、アップストリームに提供したりできるようにします。

拒否すべき合理化

• 「デプロイ後に調整します。」 未調整のルールは、アナリストにアラートを読まずに閉じる習慣をつけさせます。それは検出できないことよりも悪い結果を招きます。
• 「ノイズは多いですが、アナリストが対処できます。」 アラート疲れは、被害を伴うセキュリティ制御の失敗です。まず量を測定してください。
• 「その手法にはルールがあります。」 どの手順ですか？どのようにテストしましたか？どのプラットフォームでテレメトリを利用できますか？
• 「ベンダーのルールでカバーされています。」 読んでください。ベンダーのデフォルト設定は平均的な顧客向けに調整されており、あなたの環境向けではありません。
• 「ハッシュをルールに追加しましょう。」 そうすれば、次のビルドでそのルールは役に立たなくなります。
• 「ノイズの多いホストを除外しましょう。」 その除外対象に攻撃者が到達できるなら、バイパスを公開したも同然です。攻撃者が前提にできないプロパティでフィルターしてください。
• 「アラートがないので、問題はありません。」 アラートがないということは、アラートがないというだけです。エミュレーションで検証してください。

ATT&CKカバレッジ

secskills-core/ttp-index.jsonから生成されています。このファイルを編集してから、python3 scripts/sync_attack.py --writeを実行してください。レポートで引用する前に、現在のATT&CKリリースに照らしてIDを再確認してください。

認証情報アクセス（TA0006）

• T1003.001 LSASSメモリ — attacking-active-directoryも参照してください

コマンド＆コントロール（TA0011）

• T1071 アプリケーション層プロトコル — analyzing-malware、analyzing-network-trafficも参照してください
• T1071.004 DNS — hunting-threats、analyzing-network-trafficも参照してください
• T1573 暗号化チャネル — analyzing-malware、analyzing-network-trafficも参照してください

これらのいずれかに対する検出コンテンツ：engineering-detections。プロアクティブな検索：hunting-threats。侵害後の対応：responding-to-incidents。

外部ソースを読む

公開アドバイザリ、仕様書、ベンダーレポートをMarkdownとして取得します。

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

これによりページの定型部分が取り除かれ、文章主体のページではトークン数が約78%削減されます。また、要約ではなく全文が返されるため、grepで検索でき、見つからなかった場合の結果も信頼できます。

この用途には適さないケースが3つあります。JSONやAPIレスポンスは、可読性抽出によって構造化データが損なわれるため、加工せずに取得してください。認証が必要なページやJavaScriptでレンダリングされるページは、匿名で取得されるため、直接取得してください。また、敵対者のインフラ（フィッシングリンク、C2、マルウェアホスティング）、クライアント所有のホスト、エンゲージメントURLは、決してこの経路で取得しないでください。リクエストはあなたのマシンから第三者に送信され、稼働中の敵対者インフラの場合は運用者に気づかれることにもなります。

一部のサイトでは抽出ツールがブロックされ、ページではなくエラーの内容が返されます。たとえば、freedesktop.orgからは{"error":"Failed to fetch: 418 I'm a teapot"}が返されることがあります。これは取得が拒否されたということであり、ソースがその情報の存在を否定しているわけではありません。結論を出す前に、URLを直接再取得してください。

参考資料

• hunting-threats — 検知ルールへと発展するハンティング
• analyzing-malware — ルールのロジックの基盤となる機能分析
• responding-to-incidents — 検知のギャップを明らかにするインシデント
• MITRE ATT&CK、Sigma（SigmaHQ）、Atomic Red Team、MITRE CAR、Elastic の検知ルール
• ルールのドキュメント化のための Alerting and Detection Strategy（ADS）フレームワーク