warpedatom/noisehoundErkennungsbewusste BloodHound-Angriffspfad-Bewertung – die unauffälligste Route zu Ihrem Ziel, kalibriert über fünf Erkennungsstufen (Audit/EDR/Elastic/MDI/WDAC) plus 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>
**Erkennungsbewusste Bewertung von Active-Directory-Angriffspfaden.**
_DreadHost Research | Begleiter zu OffsetInspect (PowerShell) und OffsetScan (Rust)_
BloodHound (und PlumHound darauf aufbauend) findet *einen* Pfad zum Ziel.
NoiseHound nimmt dieselben Graphdaten auf und ordnet Pfade nach **erwarteten
Erkennungskosten** statt nach der Anzahl der Hops neu, sodass ein Operator fragen
kann: „Was ist der leiseste Weg zu Domain Admin" statt nur „Was ist ein Weg".
> **Neu hier? Der [Operator Walkthrough](https://github.com/warpedatom/noisehound/blob/main/docs/WALKTHROUGH.md) ist der schnellste Weg zu
> sehen, was dieses Tool leistet** – eine praxisnahe, screenshot-gestützte Tour von der
> Installation bis zu einem Live-Proof-of-Concept mit BloodHound CE (Scores werden
> zurück in die UI geschrieben), der DeadAir-Engine und dem Detection-Gap-Report für
> Blue Teams.
> **Projektstatus (v1.2.0):** stabil und getestet mit echten BloodHound-Daten über
> mehrere Domänen hinweg. **37 der 77 Korpus-Kanten sind laborvermessen** über fünf
> On-Prem-Erkennungsstufen (Windows-Audit, Defender for Endpoint, Elastic SIEM,
> Defender for Identity Runtime-Alerts und WDAC-Audit) plus eine vermessene Azure/Entra-
> Stufe – ausgeliefert als sechs Drop-in-Profile in [`profiles/`](https://github.com/warpedatom/noisehound/blob/main/profiles), mit
> Closed-Loop-Nachweis, dass sie die Pfad-Rankings verändern ([`docs/VALIDATION.md`](https://github.com/warpedatom/noisehound/blob/main/docs/VALIDATION.md)).
> Der Korpus enthält 13 **Azure/Entra**-Kanten ([`docs/AZURE.md`](https://github.com/warpedatom/noisehound/blob/main/docs/AZURE.md)),
> die direkt aus AzureHound-Ausgaben eingelesen werden können.
> Nicht vermessene On-Prem- und alle Azure-Kanten tragen **Experten-Schätzungen**; die
> Kalibrierungs-Harness (`noisehound-calibrate`) ist der Weg, wie diese und deine eigene
> Umgebung vermessen werden. Behandle unkalibrierte Rankings als fundierte Empfehlung,
> nicht als Ground Truth.
> Nur für autorisierte Engagements. Dieses Tool bewertet Angriffspfade für die OPSEC-
> Planung gegen Systeme, für deren Testen du eine schriftliche Genehmigung hast.
> NoiseHound ist ein unabhängiges Community-Projekt. Es ist nicht mit SpecterOps oder
> dem BloodHound-Projekt verbunden, wird von diesen nicht unterstützt und steht in
> keiner Beziehung zu ihnen; es nutzt das offene Datenformat von BloodHound.
---
## Funktionsweise
1. **Ingest** einen BloodHound-CE-Export (`.zip`), eine rohe JSON-Datei oder ein Verzeichnis
von Exporten in einen internen Graphen. Ein normalisiertes `{nodes, edges}`-JSON-Format
wird ebenfalls für Offline-Analysen und Tests akzeptiert. AD-CS-**ESC1-8**-Eskalations-
Kanten werden zur Ladezeit aus den Zertifikatvorlagen- und CA-Fakten synthetisiert,
die BloodHound sammelt (siehe unten).
2. **Annotate** jede Kante aus dem Edge-Telemetrie-Korpus und weise einen
`effective_noise_score` (0-100) zu. Wenn mehrere Rechte dasselbe Knotenpaar
verbinden, wird das leiseste gewählt. Kantentypen, die im Korpus fehlen, erhalten
standardmäßig einen konservativen Score (60), damit Lücken sicher fehlschlagen statt
zu unterberichten. Ein optionales **Umgebungsprofil** passt die Scores an die
deklarierte Erkennungshaltung des Ziels an (siehe unten).
3. **Solve** nach den leisesten Pfaden. Da der Pfad-Score ein Bottleneck plus
Mittelwert ist (keine einfache Summe), kann er nicht direkt durch Dijkstra
optimiert werden. Der Solver kombiniert einen *Threshold-Sweep* (für jedes
unterschiedliche Rauschniveau die leiseste Route, die darunter bleibt) mit einem
begrenzten k-shortest-by-weight-Durchlauf und ordnet anschließend die Vereinigung
nach dem echten Pfad-Score neu. Der Threshold-Sweep ist die Korrektheits-Absicherung:
Er bringt einen langen, aber gleichmäßig leisen Pfad zum Vorschein, den eine reine
Summengewichtungssuche unter einem kurzen, aber lauten Pfad einordnen würde.
4. **Report** als Text, JSON (interoperabel mit dem OffsetInspect-Ergebnisschema) oder
als eigenständiger HTML-Bericht, der dem Stil des Toolsets entspricht.
### Pfad-Bewertung
Pfad-Rauschen ist bewusst **keine** einfache Summe. Dieselbe Erkennung zweimal
auszulösen ist nicht doppelt so laut (SOC-Triage, nicht rohe Ereigniszahl). NoiseHound verwendet:
```
path_score = max(edge_scores) * 0.6 + mean(edge_scores) * 0.4
```
Dies gewichtet den lautesten Einzelschritt (ein schlechter Schritt verbrennt oft die gesamte Operation) und berücksichtigt dennoch die kumulative Exposition. Die Gewichte sind konfigurierbar (`--max-weight` / `--mean-weight`), sodass sie empirisch abgestimmt werden können, sobald echte Erkennungsdaten aus einem APT29/Caldera-Lab vorliegen.
Jeder Pfad meldet außerdem eine **Erkennungswahrscheinlichkeit** – die Chance, einen korrelierten Alarm auszulösen –, die die lauteste Kante mit dem kumulativen Noisy-OR aller Kanten kombiniert (abgestimmt über `--correlation`). Sie beantwortet eine andere Frage als der Rausch-Score: Ein kurzer, aber lauter Pfad kann eine *geringere* Gesamtwahrscheinlichkeit haben, entdeckt zu werden, als ein langer, aber leiser. Sortiere danach mit `--rank-by probability`.
### Zweistufige Engine (DeadAir)
Bei großen Graphen wird die Lösung an [DeadAir](https://github.com/warpedatom/DeadAir) übergeben, eine begleitende Rust-Engine (die Stufe OffsetScan-zu-OffsetInspect). NoiseHound bleibt das funktionsreiche Frontend – Ingestion, Korpus, Umgebung/Sigma, Constraints, Reporting – und übergibt den vorbereiteten Graphen an die Engine, die ihn löst, sodass die Ergebnisse in beiden Fällen identisch sind.
- `--engine auto` (Standard): DeadAir, wenn dessen Binary gefunden wird *und* der Graph groß ist (>= 5000 Knoten); andernfalls der eingebaute Python-Solver.
- `--engine python`: erzwingt den eingebauten Solver (kein Binary erforderlich).
- `--engine rust`: erzwingt DeadAir (Fehler, wenn das Binary fehlt).
DeadAir wird über `$NOISEHOUND_DEADAIR`, dann `PATH`, dann den benachbarten Build `../deadair/target/{release,debug}/` gefunden. Es ist bei großen Graphen 10-100x schneller (ein Graph mit 250k Knoten wird in ~2s gelöst statt in ~30s in Python) und erzeugt dabei byte-identische Rankings. Die Ausgabe zeichnet auf, welche Engine gelaufen ist.
### Mehrziel- und eingeschränktes Pathing
Rauschen, Hop-Anzahl und Erkennungswahrscheinlichkeit ziehen in unterschiedliche Richtungen, daher liefert `--pareto` die **Pareto-Front** – jeden Pfad, der von keinem anderen in allen drei Kriterien gleichzeitig übertroffen wird –, statt einen einzelnen Gewinner zu erzwingen. Und reale Operationen haben Constraints: `--avoid NODE` hält einen Pfad von einem bestimmten Host fern (einer EDR-überwachten Jump-Box, einem Honeypot), und `--avoid-edge TYPE` verweigert eine Technik (z. B. `--avoid-edge DCSync`). Beide sind wiederholbar und lösen on the fly neu.
```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
```
---
## Wie NoiseHound im Vergleich abschneidet
Gewichtete BloodHound-Pfadsuche ist nicht neu, daher hier die ehrliche Einordnung:
- **BloodHound / BloodHound CE** finden *einen* Pfad anhand ungewichteter Hop-Anzahl. Kein Rauschmodell.
- **GoodHound** weist Kantenkosten zu und findet die günstigsten Pfade, aber sein Kostenmodell basiert auf Ausnutzungsschwierigkeit und Geschäftsrisiko, nicht auf Erkennungsrauschen.
- **PlumHound / ImproHound** erstellen Berichte und führen Tier-Verletzungsanalysen durch; keines von beiden löst erneut nach einem leisesten Pfad zum Ziel.
- **Erkennungszuordnungen** (Sigma, DeTT&CT, Event-ID-zu-ATT&CK-Referenzen) sind umfangreich, aber menschenorientiert und nicht auf BloodHound-Kantenarten abgestimmt.
Der Beitrag von NoiseHound ist die Kombination: ein maschinenlesbarer Korpus von BloodHound-Kanten-zu-Erkennungstelemetrie, eine rauschgewichtete Neulösung, formuliert als Operator-OPSEC („der leiseste Weg zu DA"), ein Umgebungsmodell, das sich an die deklarierte Haltung eines Ziels anpasst, und eine Kalibrierungsschleife, die Laborerkennungen in gemessene Scores umwandelt. Die Graphenmathematik ist Massenware; der Korpus und die Formulierung sind der Kern. Sein Wert ist nur so gut wie der Korpus, weshalb Kalibrierung und Community-Beiträge erstklassig sind – siehe unten.
## Installation
```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 .
```
Erfordert Python 3.10+.
## Verwendung
```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
```
Prüfe zunächst den Parser anhand deines Exports (Histogramme + Korpusabdeckung, kein Pathing) – der schnellste Weg, NoiseHound mit realen Daten zu validieren:
```bash
noisehound-inspect -i export.zip
```
### Live BloodHound CE / Neo4j
Anstatt eine Zip-Datei zu verwenden, richten Sie `--input` auf die Neo4j-Datenbank, die BloodHound CE befüllt,
und NoiseHound liest den (bereits analysierten) Graphen direkt über 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"
```
Richten Sie BloodHound CE ein (bündelt Neo4j auf 7687) mit seinem offiziellen Compose:
`curl -L https://ghst.ly/getbhce | docker compose -f - up`.
Testen Sie es mit den mitgelieferten Beispielen:
```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
```
Letzteres ist die klarste Demonstration der These: Der leiseste Weg zu
Domain-Admins ist der 4-Hop-Sitzungspfad, der *über* dem 3-Hop-RDP-Pfad und dem
1-Hop-ADCS-ESC1 eingestuft wird – die meisten Hops, das geringste Rauschen.
Das Beispiel demonstriert den Kernwert: Die leiseste Route ist ein 4-Hop-Sitzungspfad
(Score 19,9), der *über* einer 2-Hop-ForceChangePassword-Abkürzung (36,4) eingestuft wird.
Weniger Hops bedeuten nicht leiser.
### Blue-Team-Erkennungslücken-Modus
Der leiseste Pfad ist dort, wo die Erkennung am schwächsten ist. Fügen Sie daher `--defensive` hinzu, um die Ausgabe für Verteidiger umzukehren: Es markiert die Kanten, die nur deshalb leise sind, weil ihre Telemetrie deaktiviert oder nicht vorhanden ist, ordnet jeder die Kontrolle zu, die sie erfassen würde, und stuft diese Kontrollen danach ein, um wie viel sie den Score des leisesten Pfads erhöhen.
```bash
python -m noisehound -i export.zip -s jdoe -o "Domain Admins" --defensive
```
Beim Full-Spectrum-Sample stellt es fest, dass der leiseste Pfad zu Domain Admins
von unentdecktem LSASS-Zugriff abhängt (`HasSession`, 20 -> 65 bei Instrumentierung), und
empfiehlt die Bereitstellung von Sysmon Event 10 – das Schließen dieser einen Lücke hebt den leisesten
Pfad von 19,9 auf 48,4. Siehe [`docs/ROADMAP.md`](https://github.com/warpedatom/noisehound/blob/main/docs/ROADMAP.md) für die Richtung, in die dies
und der Rest des Modells gehen.
### Wichtige Optionen
| Option | Bedeutung |
|--------|---------|
| `--input, -i` | BloodHound `.zip`, `.json` oder Verzeichnis mit Exporten |
| `--source, -s` | Start-Prinzipal (`jdoe` oder eine Objekt-ID) |
| `--objective, -o` | Zielknoten (`Domain Admins` oder eine Objekt-ID) |
| `--paths, -k` | Anzahl der leisesten zurückzugebenden Pfade (Standard 5) |
| `--format, -f` | `text` (Standard), `json` oder `html` |
| `--defensive` | Blue-Team-Ansicht: Erkennungslücken auf den leisesten Pfaden + Behebungen |
| `--rank-by` | `noise` (Standard) oder `probability` (P eines korrelierten Alarms) |
| `--correlation` | SOC-Korrelationskoeffizient für P(detected), 0..1 (Standard 0,5) |
| `--pareto` | Gibt die Pareto-Front über Rauschen/Hops/P(detect) zurück |
| `--engine` | `auto` (Standard), `python` oder `rust` (die DeadAir-Engine) |
| `--avoid NODE` | Schließt einen Knoten aus allen Pfaden aus (wiederholbar) |
| `--avoid-edge TYPE` | Schließt einen Kantentyp aus allen Pfaden aus (wiederholbar) |
| `--corpus` | Überschreibt das Verzeichnis des Edge-Mapping-Korpus |
| `--environment, -e` | Vom Operator deklarierte Ziel-Posture als JSON (passt Bewertungen an) |
| `--max-weight` / `--mean-weight` | Bewertungsgewichte (müssen sich zu 1,0 summieren) |
| `--default-noise` | Bewertung für Kantentypen, die im Korpus fehlen (Standard 60) |
---
## Umgebungsprofile
Eine statische Korpus-Bewertung kann nicht wissen, ob ein bestimmtes Ziel 4662-Objekt-
Auditing aktiviert hat, Sysmon ausliefert oder ein ITDR wie MDI betreibt – doch diese verändern das
reale Rauschen einer Kante enorm (DCSync ist nahezu lautlos ohne 4662-Auditing und
nahezu sicher erkennbar mit ihm). Statt vorzugeben, dass eine Zahl für jede
Umgebung passt, deklarieren Sie die Posture des Ziels in einer kleinen JSON-Datei, und NoiseHound
passt Bewertungen transparent anhand der eigenen Telemetrie-Annotationen des Korpus an:
```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 }
}
```
Anpassungen *erhöhen* einen Score lediglich in Richtung einer Erkennungsuntergrenze, die durch die deklarierte Haltung impliziert wird. `adjustments` sind harte Overrides pro Kante – der Ort, um Werte zu erfassen, die Sie gegen Ihr eigenes Labor kalibriert haben. Dies ist operatorseitig bereitgestellt, nicht gemessen; es ersetzt nicht die Live-Validierung aus Phase 2, aber es verwandelt den statischen Korpus von „eine Zahl für alle Umgebungen“ in „die Zahl für die Umgebung, in der Sie sich tatsächlich befinden“. Im mitgelieferten Beispiel kehrt die Deklaration des obigen Profils die leiseste Route vom LSASS-Dump-Sitzungspfad zu einem Verzeichnis-Schreibpfad um – was die richtige Entscheidung ist, sobald die Host-Telemetrie live ist.
```bash
python -m noisehound -i samples/sample_graph.json -s jdoe -o "Domain Admins" \
-e samples/env_profile.example.json
```
Score-Präzedenz: `static -> environment-adjusted -> live (Phase 2)`.
---
## Kalibrierungs-Harness
Umgebungsprofile sind nur so gut wie die Zahlen, die man in sie hineinschreibt.
`noisehound-calibrate` schließt den Kreis: Führe die Techniken in einem Detection-Lab aus,
zeichne auf, was ausgelöst wurde, und es gibt ein kalibriertes Umgebungsprofil aus.
**Dies wurde bereits durchgeführt.** [`profiles/`](https://github.com/warpedatom/noisehound/blob/main/profiles) enthält sechs gemessene Profile aus einer
echten Hyper-V Vulnerable-AD-Umgebung und einem Lab-Azure-Tenant – Audit-, EDR- (Defender for
Endpoint), Elastic SIEM-, Defender for Identity- und WDAC-Stufen sowie eine gemessene
Azure/Entra-Stufe, 37 Kanten – erzeugt durch den automatisierten Harness (`lab/`) und dieses
Tool. Verwende sie direkt oder messe deine eigenen:
```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
```
Das Score-Modell ist ein Shrinkage-Schätzer, der ehrlich mit der Stichprobengröße umgeht:
```
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` sind die erwarteten Erkennungskosten – die SOC-Schwere, wenn sie auslöst, ein kleiner Restwert, wenn nicht. Die Gewichtung `w` verhindert, dass ein einzelner Lauf den Korpus überstimmt, während sie ein gut abgetastetes Ergebnis dominieren lässt. Im Beispiel steigt HasSession von einem statischen Wert von 20 auf 52 (das Lab hat den LSASS-Dump in 4 von 5 Läufen erkannt), während Kerberoast von 60 auf 34 fällt (es hat nie ausgelöst). Verwende `--merge existing.json`, um eine neue Kalibrierung über ein Profil zu legen, während dessen Posture-Flags erhalten bleiben, und `--smoothing` / `--residual`, um das Modell abzustimmen.
---
## Bewertung gegen eingesetzte Erkennungen (Sigma)
Umgebungsprofile und Kalibrierung sind selbst deklariert. `noisehound-sigma` bewertet gegen die Erkennungen, die ein Verteidiger *tatsächlich geschrieben hat*: Richte es auf ein Sigma-Regelset und es ermittelt, auf welche Korpus-Kanten jede Regel auslösen würde (Abgleich der Telemetrie-Event-IDs und der ATT&CK-Technik der Kante) und gibt dann ein Umgebungsprofil aus, das die abgedeckten Kanten anhebt – ein Drop-in für `--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
```
Für die Identity-Ebene macht **`noisehound-mdi`** dasselbe gegen die integrierten Erkennungen von Microsoft Defender for Identity – es bildet die Laufzeitwarnungen von MDI (und, mit `--include-posture`, dessen ISPM-Bewertungen) auf Korpus-Kanten ab und gibt ein Profil der Identity-Ebene aus. MDI ist werkzeugunabhängig, sodass seine Abdeckung unabhängig von den Werkzeugen des Angreifers gilt.
```bash
noisehound-mdi -o env.mdi.json # + coverage report (which edges MDI watches, and the gaps)
```
Für die **Azure/Entra**-Kanten misst **`noisehound-entra`** die Cloud-Ebene auf dieselbe Weise, wie die On-Prem-Ebenen gemessen wurden: die `AZ*`-Missbräuche in einem Lab-Tenant auslösen, den Entra-`directoryAudits`-Trail exportieren, und es zählt, was tatsächlich in ein kalibriertes Profil protokolliert wurde (`docs/AZURE_CALIBRATION.md`).
```bash
noisehound-entra -a directoryAudits.json -m entra_runs.json --profile-out profiles/lab-tenant-azure.json
```
Der Abgleich ist bewusst konservativ, damit niemals eine Lücke verdeckt wird: Eine Regel zählt nur, wenn sie eine Ereignis-ID referenziert, die die Kante erzeugt, *und*, wenn die Regel mit ATT&CK getaggt ist, ihre Technik übereinstimmt – sodass eine DS-Access-(4662)-DCSync-Regel nicht fälschlich als Abdeckung von LAPS-Lesevorgängen angerechnet wird, die lediglich dieselbe Ereignis-ID teilen. Der Bericht listet sowohl auf, was deine Regeln abdecken, als auch – nützlicher – die Angriffskanten, die keine Regel abdeckt. In Kombination mit `--defensive` beantwortet dies die Frage: „Wo ist angesichts der von mir eingesetzten Detektionen mein ruhigster Angriffspfad noch unsichtbar?“
### Live-Inventar von Elastic Security
`noisehound-elastic` beantwortet dieselbe Frage anhand von Detektionen, die **gerade jetzt tatsächlich aktiviert** sind in einem laufenden Elastic-Security-Stack, statt anhand von Regeln auf der Festplatte. Es liest die Detection Engine über Kibanas schreibgeschützte `_find`-API (oder einen Offline-Export), ordnet jeder aktivierten Regel ihre ATT&CK-Technik und etwaige Windows-Ereigniscodes in ihrer Abfrage zu und gibt dasselbe `--environment`-Abdeckungsprofil aus.
```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
```
Es verwendet den Sigma-Matcher wieder und fügt eine reine Technik-Ebene hinzu (markiert mit `[technique]`, niedriger bewertet) für die verhaltensbasierten KQL/EQL-Regeln, die niemals einen Ereigniscode nennen. Deaktivierte Regeln werden ignoriert. Dasselbe Muster aus Normalisieren und anschließendem Bewerten folgt als Nächstes für Splunk / Sentinel / MDI.
---
## AD CS ESC1-8
Beim Laden führt NoiseHound eine fokussierte Version der ADCS-Nachverarbeitung von BloodHound durch und synthetisiert Eskalationskanten aus den beibehaltenen Template-/CA-Fakten. Ein `Enroll`-Recht auf einem verwundbaren Template wird zu einer direkten `ADCSESCn`-Kante vom Prinzipal zur Domain-Admins-Gruppe der Domäne (RID 512), sodass die Zertifikatseskalation wie jede andere Kante pfadbar und bewertet wird:
| Kante | Bedingung |
|------|-----------|
| `ADCSESC1` | Enrollee-supplies-subject + Client-Auth-EKU, keine Genehmigungs-/RA-Signaturen |
| `ADCSESC2` | Any-Purpose-/SubCA-EKU, keine Genehmigung |
| `ADCSESC3` | Enrollment-Agent-Template + ein Auth-Template auf derselben CA |
| `ADCSESC4` | Gefährliche Schreibkontrolle über ein veröffentlichtes Template |
| `ADCSESC5` | Kontrolle über das CA-Objekt oder dessen Hosting-Computer |
| `ADCSESC6` | CA hat `EDITF_ATTRIBUTESUBJECTALTNAME2` gesetzt |
| `ADCSESC7` | `ManageCA` / `ManageCertificates` auf der CA |
| `ADCSESC8` | Verwundbarer HTTP-Web-Enrollment-Endpunkt (Coerce + NTLM-Relay) |
Ausprobieren: `python -m noisehound -i samples/sample_adcs_ce.zip -s jdoe -o "Domain Admins"`.
Dokumentierte Vereinfachungen (sie schlagen sicher fehl in Richtung der Anzeige von mehr Pfaden): Einschränkungen auf CA-Ebene für die Registrierung werden nicht modelliert (Template-Registrierung wird als ausreichend behandelt); ESC5 deckt das CA-Objekt und dessen Host ab, nicht jeden PKI-Container; ESC9/10/13 liegen außerhalb des Geltungsbereichs. Synthetische ESC-Kanten, die bereits in einem nachverarbeiteten Export vorhanden sind, bleiben erhalten.
---
## Der Korpus (`edge_mappings/`)
Der Edge-Telemetrie-Korpus ist das eigentliche geistige Eigentum dieses Tools; der Code ist vergleichsweise einfache Graphenmathematik darauf aufbauend. Jede `edge_mappings/<Edge>.json` ordnet einen BloodHound-Kantentyp seiner Erkennungsoberfläche zu:
- erwartete Telemetriequellen (Windows Security Event IDs, Sysmon Event IDs, Netzwerk, EDR/ITDR-Heuristiken) mit Zuverlässigkeit pro Quelle und der Angabe, ob das relevante Auditing standardmäßig aktiviert ist
- einen statischen Rausch-Score (0-100)
- MITRE-Technik, erforderliches Privileg, das übliche Missbrauchsprimitiv und Anmerkungen
```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."
}
```
Die Erweiterung des Korpus ist der Bereich, in den der größte laufende Aufwand fließen sollte. Fügen Sie eine neue JSON-Datei hinzu, behalten Sie das Schema bei (wird beim Laden validiert), und sie wird automatisch übernommen. v0.3 enthält 43 Kantentypen, die die ACL-Missbrauchs-, Kerberos-, Delegierungs-, ADCS ESC1-8-, LAPS/gMSA-, GPO-, Vertrauens- und Zugriffsrechts-Kanten abdecken, die für Path-Finding relevant sind.
Die Scores werden aus der Rauschmatrix des DreadHost Red Team Operator Playbook (Windows/Sysmon-Ereigniszuordnungen, Rauschbewertungen von Techniken) und standardmäßigen AD-Erkennungsfakten initialisiert. Stimmen Sie sie anhand Ihrer eigenen Lab-Erkennungsdaten ab.
---
## Roadmap
- **Azure-/Entra-ID-Abdeckung (Grundlage ausgeliefert, wird ausgebaut).** 13 `AZ*`-Angriffspfad-Kanten werden jetzt mit Entra-nativer Erkennungstelemetrie ausgeliefert – siehe [`docs/AZURE.md`](https://github.com/warpedatom/noisehound/blob/main/docs/AZURE.md). Azure-Daten, die über AzureHound in BloodHound CE gesammelt werden, werden heute bewertet (`noisehound -o "Global Administrator"`), und die native AzureHound-Ingestion sowie eine gemessene Azure/Entra-Kalibrierungsstufe (`noisehound-entra`, `profiles/lab-tenant-azure.json`) werden nun ebenfalls ausgeliefert. Als Nächstes: Entra-Posture-Profile (MDCA / ID Protection / Sentinel) und hybride Kanten (Entra Connect / PHS-PTA), damit **MDI** über die On-Prem-/Cloud-Grenze hinweg beiträgt.
- **Kalibrierung abschließen – 37/77 gemessen, laufend.** Verbleibende ~40 Kanten (Coercion/Relay, ADCS ESC2-13, CanRDP auf Bare Metal), tiefergehende Multi-Umgebungs-Kalibrierung und ein Multi-EDR-Korpus (CrowdStrike/S1 neben MDE), plus Tooling-Kalibrierung pro Kante, um die `--tooling`-Achse zu erweitern.
- **ADCS ESC10a/10b/13-Synthese** (ESC1-9-Synthese wird jetzt ausgeliefert).
Ausgeliefert: die Rust-Engine ([DeadAir](https://github.com/warpedatom/DeadAir), `--engine`-Dispatch), Live-Neo4j-Bolt-Ingestion (`--input bolt://...`), die wählbare **`--tooling`**-Achse (Off-the-Shelf-on-Host vs. Remote/Native; `docs/TOOLING_AXIS.md`), der Phase-2-**`--live-scores`**-Hook (gemessene Scores überschreiben Korpus/Umgebung) und **`noisehound-mdi`** (Defender for Identity-Abdeckung -> Identity-Tier-Profil). Die verbleibende MDI-Arbeit ist die lab-gesteuerte *Runtime-Alert-Kalibrierung* (`docs/CALIBRATION.md`).
## Mitwirken
Der Korpus ist gemeinschaftlich erweiterbar, und dort sind Beiträge am wichtigsten. Das Hinzufügen einer Kante ist eine JSON-Datei, die beim Laden und in CI validiert wird:
```bash
noisehound-validate # schema + consistency checks over the corpus
python -m pytest tests/ -q
```
Siehe [CONTRIBUTING.md](https://github.com/warpedatom/noisehound/blob/main/CONTRIBUTING.md) für das Schema, den Bewertungsleitfaden und die PR-Hinweise sowie [`docs/edge_schema.json`](https://github.com/warpedatom/noisehound/blob/main/docs/edge_schema.json) für das formale Edge-Schema.
## Kalibrierung anhand eines Labs
30 Edges sind gemessen (siehe [`profiles/`](https://github.com/warpedatom/noisehound/blob/main/profiles)); der Rest sind Schätzungen, bis du sie misst, und jede Umgebung ist anders. [`docs/CALIBRATION.md`](https://github.com/warpedatom/noisehound/blob/main/docs/CALIBRATION.md) ist ein vollständiges Playbook: Lab-Topologie, die exakte Windows-Audit-Richtlinie und Sysmon-Konfiguration, damit die Event-IDs des Korpus ausgelöst werden, ein Übungs-Runbook pro Edge, eine APT29-via-Caldera-Realismusschicht und wie man Ergebnisse in ein kalibriertes Profil kompiliert. Beginne mit `noisehound-calibrate --template -o lab_detections.json`.
Das [`lab/`](https://github.com/warpedatom/noisehound/blob/main/lab)-Kit automatisiert die Detektionsinstrumentierung: `Enable-Telemetry.ps1` aktiviert die Audit-Richtlinie, das Script-Block-Logging, die DCSync-SACL und Sysmon; `Collect-Detections.ps1` zählt, was in einem Zeitfenster ausgelöst wurde. Es stützt sich auf [GOAD](https://github.com/Orange-Cyberdefense/GOAD) oder [Vulnerable-AD](https://github.com/WazeHell/vulnerable-AD) (oder ein beliebiges bestehendes Trainings-Lab-AD) für die verwundbare Domäne selbst, anstatt sie neu zu implementieren.
## Verantwortungsvolle Nutzung
NoiseHound ist für autorisierte Sicherheitstests, Purple-Team-Übungen, Detection-Engineering und Forschung gedacht. Es liest BloodHound-Daten, die du bereits gesammelt hast, und berechnet Rankings; es führt nichts gegen ein Ziel aus. Verwende es nur dort, wo du eine ausdrückliche schriftliche Genehmigung hast. Beiträge dürfen keine zielspezifischen Daten oder Daten aus echten Engagements enthalten.
## Testing
```bash
python -m pytest tests/ # with pytest
python tests/test_noisehound.py # dependency-light smoke run
```
## Layout
```
noisehound/ engine: schema, corpus, ingest, adcs, annotate, environment,
solver, report, cli, calibrate
edge_mappings/ the telemetry corpus (one JSON per edge type) - the IP
samples/ sample_graph.json, sample_bloodhound_ce.zip, sample_adcs_ce.zip,
sample_fullspectrum_ce.zip, env_profile.example.json,
lab_detections.example.json, sample_report.html
tests/ unit + end-to-end tests
```