warpedatom/noisehound検知を考慮したBloodHound攻撃パスのスコアリング - 目的達成への最も静かな経路を、5つの検知ティア（audit/EDR/Elastic/MDI/WDAC）とAzureにわたって調整。
<p align="center"><img src="https://assets.kitploit.com/production/public/readmes/50019/502beed5defd8b7d32991f173f6339e3214eb604968886518cd026cc2e4d3ee5.png" alt="NoiseHound" width="600"></p>
<h1 align="center">NoiseHound</h1>
<p align="center">
<a href="https://pypi.org/project/noisehound/"><img src="https://img.shields.io/pypi/v/noisehound" alt="PyPI"></a>
<a href="https://github.com/warpedatom/NoiseHound/releases"><img src="https://img.shields.io/github/v/release/warpedatom/NoiseHound" alt="Release"></a>
<a href="https://github.com/warpedatom/noisehound/blob/main/LICENSE"><img src="https://img.shields.io/github/license/warpedatom/NoiseHound" alt="License"></a>
<img src="https://img.shields.io/badge/python-3.10+-3776AB?logo=python&logoColor=white" alt="Python 3.10+">
<a href="https://github.com/warpedatom/NoiseHound/actions/workflows/ci.yml"><img src="https://img.shields.io/github/actions/workflow/status/warpedatom/NoiseHound/ci.yml?branch=main&label=CI" alt="CI"></a>
<a href="https://github.com/warpedatom/noisehound/blob/main/SECURITY.md"><img src="https://img.shields.io/badge/Security-Policy-green" alt="Security policy"></a>
<a href="https://x.com/warped_atom"><img src="https://img.shields.io/badge/X-@warped__atom-000000?logo=x&logoColor=white" alt="X (Twitter): @warped_atom"></a>
</p>
**検知を考慮した Active Directory 攻撃パスのスコアリング。**
_DreadHost Research | OffsetInspect (PowerShell) および OffsetScan (Rust) のコンパニオン_
BloodHound（およびその上に構築された PlumHound）は、目的に到達するための*ある*パスを見つけ出します。
NoiseHound は同じグラフデータを取り込み、ホップ数ではなく**予想検知コスト**によってパスを再ランク付けします。これにより、オペレーターは単に「どうやって到達するか」ではなく、「Domain Admin へ最も静かに到達する方法は何か」を問うことができます。
> **初めての方へ？ [Operator Walkthrough](https://github.com/warpedatom/noisehound/blob/main/docs/WALKTHROUGH.md) が、このツールの動作を最も手早く確認できる方法です** - インストールから実際の BloodHound CE による概念実証（スコアを UI に書き戻す）、DeadAir エンジン、ブルーチーム向けの検知ギャップレポートまでを、スクリーンショットを交えて実践的に案内するツアーです。
> **プロジェクトステータス (v1.2.0):** 安定版であり、複数のドメインにわたる実際の BloodHound データでテスト済みです。**77 個のコーパスエッジのうち 37 個がラボで実測済み**であり、5 つのオンプレミス検知層（Windows 監査、Defender for Endpoint、Elastic SIEM、Defender for Identity ランタイムアラート、WDAC 監査）に加え、実測済みの Azure/Entra 層をカバーしています - これらは [`profiles/`](https://github.com/warpedatom/noisehound/blob/main/profiles) 内の 6 つのドロップインプロファイルとして提供され、パスのランキングを実際に変化させることをクローズドループで証明しています（[`docs/VALIDATION.md`](https://github.com/warpedatom/noisehound/blob/main/docs/VALIDATION.md)）。
> コーパスには 13 個の **Azure/Entra** エッジが含まれており（[`docs/AZURE.md`](https://github.com/warpedatom/noisehound/blob/main/docs/AZURE.md)）、AzureHound の出力からそのまま取り込むことができます。
> 未実測のオンプレミスエッジおよびすべての Azure エッジには**専門家による推定値**が付与されています。キャリブレーションハーネス（`noisehound-calibrate`）は、これらの値やお客様自身の環境を実測するための手段です。未キャリブレーションのランキングは、根拠のあるガイダンスとして扱い、絶対的な真実とはみなさないでください。
> 許可されたエンゲージメント専用です。このツールは、テストの書面による許可を得たシステムに対して、OPSEC 計画のための攻撃パスをスコアリングします。
> NoiseHound は独立したコミュニティプロジェクトです。SpecterOps や BloodHound プロジェクトとは提携、承認、または関連していません。BloodHound のオープンデータ形式を利用しています。
---
## 仕組み
1. **取り込む**: BloodHound CE エクスポート（`.zip`）、生の JSON ファイル、またはエクスポートのディレクトリを内部グラフに取り込みます。オフライン分析やテスト用に、正規化された `{nodes, edges}` JSON 形式も受け付けます。AD CS の **ESC1-8** 昇格エッジは、BloodHound が収集した証明書テンプレートと CA のファクトからロード時に合成されます（下記参照）。
2. **注釈を付ける**: エッジテレメトリコーパスからすべてのエッジに注釈を付け、`effective_noise_score`（0-100）を付与します。複数の権限が同じノードペアを接続している場合は、最も静かなものが選択されます。コーパスに存在しないエッジタイプは、保守的なスコア（60）にデフォルト設定されるため、ギャップは過小報告ではなく安全側に倒れます。オプションの**環境プロファイル**は、ターゲットの宣言された検出態勢に合わせてスコアを調整します（下記参照）。
3. **解く**: 最も静かなパスを求めます。パススコアはボトルネックと平均の組み合わせ（単純な合計ではない）であるため、Dijkstra で直接最適化することはできません。ソルバーは*しきい値スイープ*（各異なるノイズレベルについて、その下に収まる最も静かな経路）と、重みによる有界 k-shortest パスを組み合わせ、その後、実際のパススコアで和集合を再ランク付けします。しきい値スイープは正確性のバックストップです。純粋な合計重み探索では短くて騒がしいパスの下にランク付けされてしまう、長いが一様に静かなパスを浮かび上がらせます。
4. **報告する**: テキスト、JSON（OffsetInspect の結果スキーマと相互運用可能）、またはツールセットに合わせたスタイルの自己完結型 HTML レポートとして出力します。
### パススコアリング
パスのノイズは意図的に**単純な合計ではありません**。同じ検出に二度引っかかることは二倍の騒がしさではありません（SOC のトリアージであり、生のイベント数ではありません）。NoiseHound は次を使用します：
```
path_score = max(edge_scores) * 0.6 + mean(edge_scores) * 0.4
```
これは、累積的な露出を考慮しつつ、最も騒がしい単一ステップ（1つの悪いステップが作戦全体を台無しにすることが多い）に重みを置いています。重みは設定可能（`--max-weight` / `--mean-weight`）であり、APT29/Calderaラボから実際の検出データが得られれば、経験的に調整できます。
各パスは**検出確率**も報告します。これは相関アラートをトリガーする可能性であり、最も騒がしいエッジと全エッジの累積ノイズOR（`--correlation`で調整）をブレンドしたものです。これはノイズスコアとは異なる問いに答えます。短くても騒がしいパスは、長くても静かなパスよりも検出される全体的な確率が*低い*ことがあります。`--rank-by probability`でこれによるランク付けができます。
### 2層エンジン（DeadAir）
大規模グラフでは、求解はコンパニオンのRustエンジンである[DeadAir](https://github.com/warpedatom/DeadAir)（OffsetScan-to-OffsetInspect層）にディスパッチされます。NoiseHoundは機能豊富なフロントエンド（取り込み、コーパス、環境/Sigma、制約、レポート）として留まり、準備されたグラフを求解するエンジンに渡すため、どちらの場合も結果は同一です。
- `--engine auto`（デフォルト）：DeadAirのバイナリが見つかり*かつ*グラフが大規模（>= 5000ノード）な場合にDeadAirを使用し、それ以外は組み込みのPythonソルバーを使用します。
- `--engine python`：組み込みソルバーを強制します（バイナリ不要）。
- `--engine rust`：DeadAirを強制します（バイナリがない場合はエラー）。
DeadAirは`$NOISEHOUND_DEADAIR`、次に`PATH`、次に兄弟ディレクトリの`../deadair/target/{release,debug}/`ビルドの順で検索されます。大規模グラフでは10〜100倍高速（250kノードのグラフはPythonで約30秒に対し約2秒で求解）でありながら、バイト単位で同一のランキングを生成します。出力にはどのエンジンが実行されたかが記録されます。
### 多目的および制約付きパス探索
ノイズ、ホップ数、検出確率は異なる方向に引っ張り合うため、`--pareto`は単一の勝者を強制する代わりに**パレートフロンティア**（3つすべてにおいて他のどのパスにも同時に劣らないすべてのパス）を返します。また、実際の作戦には制約があります。`--avoid NODE`は特定のホスト（EDR監視下のジャンプボックス、ハニーポット）をパスから除外し、`--avoid-edge TYPE`は特定のテクニックを拒否します（例：`--avoid-edge DCSync`）。どちらも繰り返し指定可能で、その場で再求解されます。
```bash
python -m noisehound -i export.zip -s jdoe -o "Domain Admins" --pareto
python -m noisehound -i export.zip -s jdoe -o "Domain Admins" --avoid FILESERVER01 --avoid-edge HasSession
```
---
## NoiseHound の比較
重み付き BloodHound パスファインディングは目新しいものではないため、ここでは正直な位置づけを示します:
- **BloodHound / BloodHound CE** は、重みなしのホップ数によって*ある*パスを見つけます。ノイズモデルはありません。
- **GoodHound** はエッジにコストを割り当てて最安パスを見つけますが、そのコストモデルは検出ノイズではなく、悪用の難易度とビジネスリスクに基づいています。
- **PlumHound / ImproHound** はレポーティングとティア違反分析を行いますが、どちらも目的対象への最も静かなパスを再求解するものではありません。
- **検出マッピング** (Sigma、DeTT&CT、イベントIDからATT&CKへの参照) は豊富ですが、人間向けであり、BloodHound のエッジ種別に紐づけられていません。
NoiseHound の貢献はその組み合わせにあります: 機械可読な BloodHound エッジから検出テレメトリへのコーパス、オペレーターの OPSEC (「DA への最も静かな道」) として枠付けられたノイズ重み付き再求解、対象の宣言された態勢に適応する環境モデル、そしてラボでの検出を実測スコアに変換するキャリブレーションループです。グラフの数学はありふれたものですが、コーパスとその枠付けこそが要点です。その価値はコーパスの質にのみ依存するため、キャリブレーションとコミュニティからの貢献が第一級の扱いとなっています - 以下を参照してください。
## インストール
```bash
cd NoiseHound
python -m pip install -r requirements.txt # networkx>=3.0
# optional editable install to get the `noisehound` command on PATH:
python -m pip install -e .
```
Python 3.10+ が必要です。
## 使用方法
```bash
# Text summary (default)
python -m noisehound --input export.zip --objective "Domain Admins" --source jdoe
# JSON, for downstream tooling / correlation across the DreadHost suite
python -m noisehound -i export.zip -o "Domain Admins" -s jdoe -f json --out paths.json
# Self-contained HTML report
python -m noisehound -i export.zip -o "Domain Admins" -s jdoe -f html --out report.html
```
まず、エクスポートに対してパーサーのサニティチェックを行います（ヒストグラム + コーパスカバレッジ、パス処理なし）。これはNoiseHoundを実世界のデータで検証する最速の方法です：
```bash
noisehound-inspect -i export.zip
```
### 稼働中の BloodHound CE / Neo4j
zip の代わりに、`--input` を BloodHound CE がデータを格納する Neo4j データベースに向けると、NoiseHound は（すでに分析済みの）グラフを Bolt 経由で直接読み取ります:
```bash
pip install 'noisehound[neo4j]'
export NEO4J_PASSWORD=bloodhoundcommunityedition # match your BHCE compose
noisehound-inspect -i bolt://localhost:7687
python -m noisehound -i bolt://localhost:7687 -s jdoe -o "Domain Admins"
```
BloodHound CE（7687 番ポートで Neo4j をバンドル）を公式の compose で起動します:
`curl -L https://ghst.ly/getbhce | docker compose -f - up`。
バンドルされているサンプルに対して試してみてください:
```bash
python -m noisehound -i samples/sample_graph.json -s jdoe -o "Domain Admins" -d CONTOSO.LOCAL
python -m noisehound -i samples/sample_bloodhound_ce.zip -s jdoe -o "Domain Admins"
python -m noisehound -i samples/sample_adcs_ce.zip -s jdoe -o "Domain Admins" # ADCS ESC1
# Full-spectrum export exercising every edge family (sessions, delegation, DCSync, ADCS, trusts):
python -m noisehound -i samples/sample_fullspectrum_ce.zip -s ALICE -o "Domain Admins" -d CONTOSO.LOCAL -k 3
```
最後の例はこの主張を最も明確に示している。Domain Admins への最も静かな経路は 4 ホップのセッションパスであり、3 ホップの RDP パスや 1 ホップの ADCS ESC1 よりも*上位*にランクされる。ホップ数は最多で、ノイズは最小である。
このサンプルは核心的な価値を示している。最も静かな経路は 4 ホップのセッションパス（スコア 19.9）であり、2 ホップの ForceChangePassword ショートカット（36.4）よりも*上位*にランクされる。ホップ数が少ないことは、静かであることを意味しない。
### ブルーチーム向け検出ギャップモード
最も静かな経路は検出が最も弱い場所であるため、`--defensive` を追加すると防御側向けに出力が切り替わる。テレメトリがオフまたは存在しないために静かになっているエッジにフラグを立て、それぞれを捕捉できる制御にマッピングし、それらの制御を最も静かな経路のスコアをどれだけ引き上げるかでランク付けする。
```bash
python -m noisehound -i export.zip -s jdoe -o "Domain Admins" --defensive
```
フルスペクトラムのサンプルでは、Domain Admins への最も静かな経路が検知されない LSASS アクセス（`HasSession`、インストルメント化すると 20 -> 65）に依存していることを見出し、Sysmon Event 10 の導入を推奨しています。この一点のギャップを埋めることで、最も静かな経路が 19.9 から 48.4 に上昇します。この機能とモデルの残りの部分がどこへ向かうかについては [`docs/ROADMAP.md`](https://github.com/warpedatom/noisehound/blob/main/docs/ROADMAP.md) を参照してください。
### 主要なオプション
| オプション | 意味 |
|--------|---------|
| `--input, -i` | BloodHound の `.zip`、`.json`、またはエクスポートのディレクトリ |
| `--source, -s` | 開始プリンシパル（`jdoe` またはオブジェクト ID） |
| `--objective, -o` | ターゲットノード（`Domain Admins` またはオブジェクト ID） |
| `--paths, -k` | 返す最も静かな経路の数（デフォルト 5） |
| `--format, -f` | `text`（デフォルト）、`json`、または `html` |
| `--defensive` | ブルーチーム視点：最も静かな経路上の検知ギャップ + 修正策 |
| `--rank-by` | `noise`（デフォルト）または `probability`（相関アラートの確率 P） |
| `--correlation` | P(detected) に対する SOC 相関係数、0..1（デフォルト 0.5） |
| `--pareto` | noise/hops/P(detect) に関するパレートフロンティアを返す |
| `--engine` | `auto`（デフォルト）、`python`、または `rust`（DeadAir エンジン） |
| `--avoid NODE` | すべての経路からノードを除外する（繰り返し指定可能） |
| `--avoid-edge TYPE` | すべての経路からエッジタイプを除外する（繰り返し指定可能） |
| `--corpus` | エッジマッピングコーパスのディレクトリを上書きする |
| `--environment, -e` | オペレーターが宣言するターゲット環境の JSON（スコアを調整） |
| `--max-weight` / `--mean-weight` | スコアリングの重み（合計が 1.0 である必要あり） |
| `--default-noise` | コーパスに存在しないエッジタイプのスコア（デフォルト 60） |
---
## 環境プロファイル
静的なコーパススコアでは、特定のターゲットで 4662 オブジェクト監査が有効か、Sysmon が導入されているか、あるいは MDI のような ITDR が稼働しているかを知ることはできません。しかしこれらはエッジの実際のノイズを大きく左右します（DCSync は 4662 監査なしではほぼ無音であり、監査ありではほぼ確実に検知されます）。すべての環境に単一の数値が当てはまると見せかける代わりに、ターゲットの環境態勢を小さな JSON ファイルで宣言すると、NoiseHound はコーパス自身のテレメトリアノテーションに基づいてスコアを透過的に調整します：
```json
{
"name": "CONTOSO.LOCAL-prod",
"object_auditing_4662": true,
"ds_change_auditing_5136": false,
"edr": "MDI",
"sysmon": true,
"powershell_logging_4104": true,
"adjustments": { "HasSession": 65 }
}
```
調整は常にスコアを*引き上げ*、宣言された態勢によって示される検出フロアに向かって動かすだけです。`adjustments` はエッジごとのハードオーバーライドであり、独自のラボで較正した値を記録する場所です。これはオペレーターが提供するものであり、測定値ではありません。Phase 2 のライブ検証を置き換えるものではありませんが、静的コーパスを「すべての環境に対する単一の数値」から「実際に自分がいる環境に対する数値」へと変えます。バンドルされたサンプルでは、上記のプロファイルを宣言すると、最も静かなルートが LSASS ダンプのセッションパスからディレクトリ書き込みパスへと切り替わります。これは、ホストテレメトリが稼働した状態では正しい判断です。
```bash
python -m noisehound -i samples/sample_graph.json -s jdoe -o "Domain Admins" \
-e samples/env_profile.example.json
```
スコアの優先順位: `static -> environment-adjusted -> live (Phase 2)`。
---
## キャリブレーションハーネス
環境プロファイルは、そこに入れる数値が優れているかどうかでしか価値が決まりません。
`noisehound-calibrate` はこのループを閉じます。検出ラボで各手法を実行し、何が発火したかを記録すると、キャリブレーション済みの環境プロファイルを出力します。
**これはすでに実施済みです。** [`profiles/`](https://github.com/warpedatom/noisehound/blob/main/profiles) には、実際の Hyper-V Vulnerable-AD レンジとラボの Azure テナントから測定された6つのプロファイル（audit、EDR（Defender for Endpoint）、Elastic SIEM、Defender for Identity、WDAC の各ティア、および測定済みの Azure/Entra ティア、37 エッジ）が同梱されています。これらは自動ハーネス（`lab/`）と本ツールによって生成されました。そのまま使用することも、独自に測定することもできます:
```bash
# Use a shipped measured profile:
noisehound -i export.zip -s jdoe -o "Domain Admins" -e profiles/vulnad-hyperv-audit.json
# Or measure your own lab:
# 1. noisehound-calibrate --plan -o plan.json (per-edge detection events)
# 2. lab/Invoke-NoiseHoundCalibration.ps1 (run + auto-count -> lab_detections.json)
noisehound-calibrate -i lab_detections.json -o env.calibrated.json
noisehound -i export.zip -s jdoe -o "Domain Admins" -e env.calibrated.json
```
スコアモデルは縮小推定器であり、サンプルサイズに対して正直である：
```
p = detections / runs (detection probability)
lab_score = p * severity_loudness + (1 - p) * residual
w = runs / (runs + smoothing) (confidence in the lab)
calibrated = w * lab_score + (1 - w) * corpus_static
```
`lab_score` は期待される検出コストです。発火した場合は SOC の重大度、発火しなかった場合は小さな残差となります。重み `w` は、単一の実行がコーパスを上書きするのを防ぎつつ、十分にサンプリングされた結果が支配できるようにします。例では、HasSession は静的値の 20 から 52 に上昇し（ラボは 5 回中 4 回の実行で LSASS ダンプを捕捉）、Kerberoast は 60 から 34 に低下します（一度も発火しなかったため）。`--merge existing.json` を使用すると、プロファイルのポスチャーフラグを維持したまま新しいキャリブレーションを上書きでき、`--smoothing` / `--residual` でモデルを調整できます。
---
## デプロイ済みの検出に対するスコアリング（Sigma）
環境プロファイルとキャリブレーションは自己申告です。`noisehound-sigma` は、防御者が*実際に記述した*検出に対してスコアリングします。Sigma ルールセットを指定すると、各ルールがどのコーパスエッジで発火するかを（エッジのテレメトリイベント ID と ATT&CK テクニックを照合して）算出し、カバーされたエッジを引き上げる環境プロファイルを出力します。これは `--environment` にそのまま渡せます。
```bash
noisehound-sigma -r ./sigma-rules/ -o env.sigma.json
python -m noisehound -i export.zip -s jdoe -o "Domain Admins" -e env.sigma.json --defensive
```
アイデンティティ層では、**`noisehound-mdi`** が Microsoft Defender for Identity の組み込み検出に対して同じ処理を行います。MDI のランタイムアラート（および `--include-posture` 指定時は ISPM 評価）をコーパスのエッジにマッピングし、アイデンティティ層のプロファイルを出力します。MDI はツール非依存であるため、攻撃者がどのツールを使用していてもそのカバレッジは維持されます。
```bash
noisehound-mdi -o env.mdi.json # + coverage report (which edges MDI watches, and the gaps)
```
**Azure/Entra** のエッジについて、**`noisehound-entra`** はオンプレミス層を測定したのと同じ方法でクラウド層を測定します。ラボテナントで `AZ*` の悪用をトリガーし、Entra の `directoryAudits` トレイルをエクスポートして、キャリブレーション済みプロファイル（`docs/AZURE_CALIBRATION.md`）に実際に記録された内容をカウントします。
```bash
noisehound-entra -a directoryAudits.json -m entra_runs.json --profile-out profiles/lab-tenant-azure.json
```
マッチングは意図的に保守的に設計されており、ギャップを決して隠しません。ルールは、エッジが生成するイベントIDを参照し、*かつ*、そのルールにATT&CKタグが付与されている場合はそのテクニックが一致する場合にのみカウントされます。したがって、DS-Access（4662）のDCSyncルールが、単にイベントIDを共有するだけのLAPS読み取りをカバーしていると誤って見なされることはありません。レポートには、ルールがカバーしている内容と、より有用な情報として、どのルールもカバーしていない攻撃エッジの両方が記載されます。`--defensive`と組み合わせることで、「デプロイ済みの検知を前提に、最も静かな攻撃パスが依然として見えないのはどこか」という問いに答えます。
### ライブElastic Securityインベントリ
`noisehound-elastic`は、ディスク上のルールではなく、稼働中のElastic Securityスタックで**現在実際に有効化されている**検知に対して同じ問いに答えます。Kibanaの読み取り専用`_find` API（またはオフラインエクスポート）を介して検知エンジンを読み取り、有効化された各ルールのATT&CKテクニックとクエリ内のWindowsイベントコードをマッピングし、同じ`--environment`カバレッジプロファイルを出力します。
```bash
export KIBANA_URL=https://kibana:5601 KIBANA_API_KEY=<base64 ApiKey>
noisehound-elastic -o env.elastic.json # live, read-only
noisehound-elastic --rules-json rules_find.json -o env.elastic.json # offline export
python -m noisehound -i export.zip -s jdoe -o "Domain Admins" -e env.elastic.json --defensive
```
Sigmaマッチャーを再利用し、イベントコードを一切指定しない振る舞いベースのKQL/EQLルール向けに、テクニックのみの階層（`[technique]`とフラグ付けされ、スコアは低め）を追加します。無効化されたルールは無視されます。Splunk / Sentinel / MDIについても、同様の正規化してからスコアリングするパターンを次に適用します。
---
## AD CS ESC1-8
ロード時に、NoiseHoundはBloodHoundのADCS後処理を絞り込んだ形で実行し、保持されたテンプレート/CAの事実から昇格エッジを合成します。脆弱なテンプレートに対する`Enroll`権限は、プリンシパルからドメインのDomain Adminsグループ（RID 512）への直接的な`ADCSESCn`エッジとなり、証明書による昇格が他のエッジと同様に経路探索可能かつスコアリングされます:
| エッジ | 条件 |
|------|-----------|
| `ADCSESC1` | 登録者がサブジェクトを指定 + client-auth EKU、承認/RA署名なし |
| `ADCSESC2` | Any-Purpose / SubCA EKU、承認なし |
| `ADCSESC3` | 登録エージェントテンプレート + 同一CA上の認証テンプレート |
| `ADCSESC4` | 公開テンプレートに対する危険な書き込み制御 |
| `ADCSESC5` | CAオブジェクトまたはそのホストコンピュータの制御 |
| `ADCSESC6` | CAに`EDITF_ATTRIBUTESUBJECTALTNAME2`が設定されている |
| `ADCSESC7` | CAに対する`ManageCA` / `ManageCertificates` |
| `ADCSESC8` | 脆弱なHTTP Web登録エンドポイント（強制 + NTLMリレー） |
試すには: `python -m noisehound -i samples/sample_adcs_ce.zip -s jdoe -o "Domain Admins"`。
文書化された簡略化（より多くの経路を示す方向にフェイルセーフとなる）: CAレベルの登録制限はモデル化されていません（テンプレートの登録があれば十分とみなされます）。ESC5はCAオブジェクトとそのホストを対象とし、すべてのPKIコンテナを対象とするわけではありません。ESC9/10/13は対象外です。後処理済みエクスポートに既に存在する合成ESCエッジは保持されます。
---
## コーパス（`edge_mappings/`）
エッジテレメトリコーパスはこのツールの実質的な知的財産であり、コードはその上で動作する比較的単純なグラフ計算にすぎません。各`edge_mappings/<Edge>.json`は、BloodHoundのエッジタイプをその検出対象範囲にマッピングします:
- 想定されるテレメトリソース（WindowsセキュリティイベントID、SysmonイベントID、ネットワーク、EDR/ITDRヒューリスティクス）と、ソースごとの信頼性、および関連する監査がデフォルトで有効かどうか
- 静的なノイズスコア（0-100）
- MITREテクニック、前提となる権限、一般的な悪用プリミティブ、および注記
```json
{
"edge_type": "DCSync",
"static_noise_score": 85,
"telemetry": [
{"source": "windows_security", "event_id": 4662,
"detail": "Directory Service Access - requires object auditing (default OFF)",
"reliability": "high_if_auditing_enabled", "default_enabled": false},
{"source": "edr_heuristic", "product_class": "MDI",
"detail": "Non-DC hosts issuing DRSGetNCChanges - high fidelity",
"reliability": "high"}
],
"mitre_technique": "T1003.006",
"notes": "Assumes default audit policy (mostly OFF) but high EDR/MDI coverage."
}
```
継続的な取り組みの大部分は、コーパスの拡張に注ぐべきです。新しい JSON ファイルを追加し、スキーマを維持すれば（読み込み時に検証されます）、自動的に取り込まれます。v0.3 では、パス探索に重要な ACL 悪用、Kerberos、委任、ADCS ESC1-8、LAPS/gMSA、GPO、信頼、アクセス権のエッジをカバーする 43 種類のエッジタイプを提供しています。
スコアは、DreadHost Red Team Operator Playbook のノイズマトリクス（Windows/Sysmon イベントマッピング、テクニックのノイズ評価）と標準的な AD 検出ファクトからシードされています。これらは、自身のラボの検出データに基づいて調整してください。
---
## ロードマップ
- **Azure / Entra ID のカバレッジ（基盤は提供済み、拡大中）。** Entra ネイティブの検出テレメトリを備えた 13 個の `AZ*` 攻撃パスエッジを提供しています - [`docs/AZURE.md`](https://github.com/warpedatom/noisehound/blob/main/docs/AZURE.md) を参照してください。AzureHound 経由で Azure データを収集し BloodHound CE に投入したものは現在スコアリングされています（`noisehound -o "Global Administrator"`）。また、AzureHound ネイティブの取り込みと、実測された Azure/Entra キャリブレーション層（`noisehound-entra`、`profiles/lab-tenant-azure.json`）も提供されています。次は、Entra のポスチャプロファイル（MDCA / ID Protection / Sentinel）とハイブリッドエッジ（Entra Connect / PHS-PTA）により、**MDI** がオンプレミス/クラウドの境界を越えて貢献できるようにすることです。
- **キャリブレーションの完了 - 37/77 実測済み、継続中。** 残りの約 40 エッジ（強制/リレー、ADCS ESC2-13、ベアメタル上の CanRDP）、より深いマルチ環境キャリブレーション、マルチ EDR コーパス（MDE に加えて CrowdStrike/S1）、さらに `--tooling` 軸を広げるためのエッジごとのツールキャリブレーション。
- **ADCS ESC10a/10b/13 の合成**（ESC1-9 の合成は現在提供済み）。
提供済み: Rust エンジン（[DeadAir](https://github.com/warpedatom/DeadAir)、`--engine` ディスパッチ）、ライブ Neo4j Bolt 取り込み（`--input bolt://...`）、選択可能な **`--tooling`** 軸（ホスト上の既製ツール vs リモート/ネイティブ、`docs/TOOLING_AXIS.md`）、Phase 2 の **`--live-scores`** フック（実測スコアがコーパス/環境を上書き）、そして **`noisehound-mdi`**（Defender for Identity のカバレッジ -> アイデンティティ層プロファイル）。残りの MDI 作業は、ラボでゲートされた*ランタイムアラートキャリブレーション*（`docs/CALIBRATION.md`）です。
---
[Read more](https://github.com/warpedatom/noisehound)