
Erkennungsbewusste BloodHound-Angriffspfad-Bewertung – die unauffälligste Route zu Ihrem Ziel, kalibriert über fünf Erkennungsstufen (Audit/EDR/Elastic/MDI/WDAC) plus Azure.

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 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/, mit Closed-Loop-Nachweis, dass sie die Pfad-Rankings verändern (docs/VALIDATION.md). Der Korpus enthält 13 Azure/Entra-Kanten (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.
.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).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).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.
Bei großen Graphen wird die Lösung an 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.