NoiseHound

Notation des chemins d'attaque Active Directory tenant compte de la détection. DreadHost Research | compagnon d'OffsetInspect (PowerShell) et OffsetScan (Rust)

BloodHound (et PlumHound par-dessus) trouve un chemin vers l'objectif. NoiseHound ingère les mêmes données de graphe et reclasse les chemins selon le coût de détection attendu plutôt que selon le nombre de sauts, afin qu'un opérateur puisse se demander « quel est le moyen le plus discret d'atteindre Domain Admin » plutôt que simplement « quel est un moyen d'y parvenir ».

Nouveau ici ? Le Operator Walkthrough est le moyen le plus rapide de voir ce que fait cet outil - une visite pratique, guidée par captures d'écran, de l'installation à une preuve de concept BloodHound CE en conditions réelles (scores réécrits dans l'interface), le moteur DeadAir, et le rapport de lacunes de détection pour la blue team.

État du projet (v1.2.0) : stable et testé sur des données BloodHound réelles sur plusieurs domaines. 37 des 77 arêtes du corpus sont mesurées en laboratoire sur cinq niveaux de détection on-prem (audit Windows, Defender for Endpoint, Elastic SIEM, alertes d'exécution Defender for Identity, et audit WDAC) plus un niveau Azure/Entra mesuré - livrés sous forme de six profils prêts à l'emploi dans profiles/, avec une preuve en boucle fermée qu'ils modifient le classement des chemins (docs/VALIDATION.md). Le corpus inclut 13 arêtes Azure/Entra (docs/AZURE.md), ingérables directement depuis la sortie d'AzureHound. Les arêtes on-prem non mesurées et toutes les arêtes Azure portent des estimations d'experts ; le harnais de calibration (noisehound-calibrate) est le moyen de les mesurer, ainsi que votre propre environnement. Considérez les classements non calibrés comme des indications bien raisonnées, et non comme une vérité terrain.

Pour les engagements autorisés uniquement. Cet outil note les chemins d'attaque pour la planification OPSEC contre des systèmes pour lesquels vous disposez d'une autorisation écrite de test.

NoiseHound est un projet communautaire indépendant. Il n'est ni affilié à, ni approuvé par, ni associé à SpecterOps ou au projet BloodHound ; il consomme le format de données ouvert de BloodHound.

---

Fonctionnement

1. Ingérer un export BloodHound CE (.zip), un fichier JSON brut ou un répertoire d'exports dans un graphe interne. Un format JSON normalisé {nodes, edges} est également accepté pour l'analyse hors ligne et les tests. Les arêtes d'escalade AD CS ESC1-8 sont synthétisées au chargement à partir des faits sur les modèles de certificats et les CA collectés par BloodHound (voir ci-dessous).
2. Annoter chaque arête à partir du corpus de télémétrie d'arêtes, en attachant un effective_noise_score (0-100). Lorsque plusieurs droits relient la même paire de nœuds, le plus discret est choisi. Les types d'arêtes absents du corpus reçoivent par défaut un score conservateur (60) afin que les lacunes échouent en sécurité plutôt que de sous-estimer. Un profil d'environnement optionnel ajuste les scores selon la posture de détection déclarée de la cible (voir ci-dessous).
3. Résoudre les chemins les plus discrets. Comme le score de chemin est un goulot d'étranglement plus une moyenne (et non une simple somme), il ne peut pas être optimisé directement par Dijkstra. Le solveur combine un balayage de seuils (pour chaque niveau de bruit distinct, la route la plus discrète qui reste en dessous) avec une passe bornée des k-plus-courts-par-poids, puis reclasse l'union selon le score de chemin réel. Le balayage de seuils est le filet de sécurité de correction : il fait émerger un chemin long mais uniformément discret qu'une recherche pure sur le poids cumulé classerait en dessous d'un chemin court mais bruyant.
4. Rapporter en texte, JSON (interopérable avec le schéma de résultat OffsetInspect) ou un rapport HTML autonome stylisé pour correspondre à la boîte à outils.

Notation des chemins

Le bruit d'un chemin n'est délibérément pas une simple somme. Déclencher la même détection deux fois n'est pas deux fois plus bruyant (triage SOC, pas un comptage brut d'événements). NoiseHound utilise :

path_score = max(edge_scores) * 0.6 + mean(edge_scores) * 0.4

Ceci pondère vers l'étape unique la plus bruyante (une mauvaise étape consume souvent toute l'opération) tout en tenant compte de l'exposition cumulée. Les poids sont configurables (--max-weight / --mean-weight) afin de pouvoir être ajustés empiriquement une fois de vraies données de détection disponibles à partir d'un labo APT29/Caldera.

Chaque chemin rapporte également une probabilité de détection - la chance qu'il déclenche une alerte corrélée - en combinant l'arête la plus bruyante avec le noisy-OR cumulé de toutes les arêtes (ajusté par --correlation). Elle répond à une question différente du score de bruit : un chemin court mais bruyant peut avoir une probabilité globale d'être détecté plus faible qu'un chemin long mais discret. Classez selon celle-ci avec --rank-by probability.

Moteur à deux niveaux (DeadAir)

Pour les grands graphes, la résolution est déléguée à DeadAir, un moteur Rust compagnon (le niveau OffsetScan-to-OffsetInspect). NoiseHound reste le frontend riche en fonctionnalités - ingestion, corpus, environnement/Sigma, contraintes, rapports - et transmet le graphe préparé au moteur qui le résout, de sorte que les résultats sont identiques dans les deux cas.

• --engine auto (par défaut) : DeadAir lorsque son binaire est trouvé et que le graphe est grand (>= 5000 nœuds) ; sinon le solveur Python intégré.
• --engine python : force le solveur intégré (aucun binaire nécessaire).
• --engine rust : force DeadAir (erreur si le binaire est absent).

DeadAir est trouvé via $NOISEHOUND_DEADAIR, puis PATH, puis le build voisin ../deadair/target/{release,debug}/. Il est 10 à 100 fois plus rapide sur les grands graphes (un graphe de 250k nœuds se résout en ~2s contre ~30s en Python) tout en produisant des classements identiques octet pour octet. La sortie enregistre quel moteur a été exécuté.

Cheminement multi-objectif et contraint