NoiseHound

Punteggio dei percorsi di attacco in Active Directory basato sulla consapevolezza del rilevamento. DreadHost Research | complementare a OffsetInspect (PowerShell) e OffsetScan (Rust)

BloodHound (e PlumHound sopra di esso) trova un percorso verso l'obiettivo. NoiseHound acquisisce gli stessi dati del grafo e riordina i percorsi in base al costo di rilevamento atteso anziché al numero di hop, così un operatore può chiedersi "qual è il modo più silenzioso per arrivare a Domain Admin" invece di limitarsi a "qual è un modo".

Nuovo qui? La Operator Walkthrough è il modo più rapido per vedere cosa fa questo strumento - un tour pratico e guidato da screenshot, dall'installazione a una proof of concept live con BloodHound CE (punteggi riscritti nell'interfaccia), al motore DeadAir e al report sulle lacune di rilevamento per il blue team.

Stato del progetto (v1.2.0): stabile e testato su dati BloodHound reali su più domini. 37 delle 77 edge del corpus sono misurate in laboratorio attraverso cinque livelli di rilevamento on-prem (Windows audit, Defender for Endpoint, Elastic SIEM, alert runtime di Defender for Identity e WDAC audit) più un livello Azure/Entra misurato

• distribuite come sei profili pronti all'uso in profiles/, con prova a ciclo chiuso che modificano la classificazione dei percorsi (docs/VALIDATION.md). Il corpus include 13 edge Azure/Entra (docs/AZURE.md), acquisibili direttamente dall'output di AzureHound. Le edge on-prem non misurate e tutte le edge Azure riportano stime esperte; l'harness di calibrazione (noisehound-calibrate) è il modo in cui esse, e il tuo ambiente, vengono misurate. Tratta le classificazioni non calibrate come indicazioni ben fondate, non come verità assoluta.

Solo per ingaggi autorizzati. Questo strumento assegna un punteggio ai percorsi di attacco per la pianificazione OPSEC contro sistemi per cui hai esplicita autorizzazione a eseguire test.

NoiseHound è un progetto comunitario indipendente. Non è affiliato, approvato o associato a SpecterOps o al progetto BloodHound; consuma il formato dati aperto di BloodHound.

---

Come funziona

1. Acquisire un'esportazione di BloodHound CE (.zip), un file JSON grezzo o una directory di esportazioni in un grafo interno. È inoltre accettato un formato JSON normalizzato {nodes, edges} per l'analisi offline e i test. Gli archi di escalation AD CS ESC1-8 vengono sintetizzati al momento del caricamento dai fatti relativi ai template di certificato e alle CA raccolti da BloodHound (vedi sotto).
2. Annotare ogni arco dal corpus di telemetria degli archi, associando un effective_noise_score (0-100). Quando più diritti collegano la stessa coppia di nodi, viene scelto il più silenzioso. I tipi di arco assenti dal corpus ricevono un punteggio conservativo predefinito (60), così le lacune falliscono in modo sicuro anziché sottostimare. Un profilo di ambiente opzionale adatta i punteggi alla postura di rilevamento dichiarata del target (vedi sotto).
3. Risolvere i percorsi più silenziosi. Poiché il punteggio del percorso è un collo di bottiglia più la media (non una semplice somma), non può essere ottimizzato direttamente con Dijkstra. Il solver combina una scansione per soglia (per ogni livello di rumore distinto, il percorso più silenzioso che rimane al di sotto di esso) con una passata limitata k-shortest-by-weight, quindi riordina l'unione secondo il punteggio reale del percorso. La scansione per soglia è il meccanismo di garanzia della correttezza: fa emergere un percorso lungo ma uniformemente silenzioso che una ricerca basata puramente sulla somma dei pesi classificherebbe sotto uno corto ma rumoroso.
4. Riportare come testo, JSON (interoperabile con lo schema dei risultati di OffsetInspect) o un report HTML autonomo con uno stile coerente con il toolset.

Punteggio dei percorsi

Il rumore del percorso deliberatamente non è una semplice somma. Attivare due volte la stessa rilevazione non equivale a un rumore doppio (triage del SOC, non conteggio grezzo degli eventi). NoiseHound usa:

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

Questo pesa verso il singolo passo più rumoroso (un passo sbagliato spesso compromette l'intera operazione) pur tenendo conto dell'esposizione cumulativa. I pesi sono configurabili (--max-weight / --mean-weight) così da poter essere regolati empiricamente una volta disponibili dati di rilevamento reali da un laboratorio APT29/Caldera.

Ogni percorso riporta anche una probabilità di rilevamento - la probabilità che faccia scattare un avviso correlato - combinando l'arco più rumoroso con il noisy-OR cumulativo di tutti gli archi (regolato tramite --correlation). Risponde a una domanda diversa rispetto al punteggio di rumore: un percorso breve ma rumoroso può avere una probabilità complessiva di essere individuato inferiore rispetto a uno lungo ma silenzioso. Ordinali in base a essa con --rank-by probability.

Motore a due livelli (DeadAir)

Per grafi di grandi dimensioni la risoluzione viene delegata a DeadAir, un motore Rust complementare (il livello OffsetScan-to-OffsetInspect). NoiseHound rimane il frontend ricco di funzionalità - ingestion, corpus, ambiente/Sigma, vincoli, reporting - e passa il grafo preparato al motore che lo risolve, così i risultati sono identici in entrambi i casi.

• --engine auto (predefinito): DeadAir quando il suo binario viene trovato e il grafo è grande (>= 5000 nodi); altrimenti il solver Python integrato.
• --engine python: forza il solver integrato (nessun binario necessario).
• --engine rust: forza DeadAir (genera un errore se il binario è assente).

DeadAir viene individuato tramite $NOISEHOUND_DEADAIR, poi PATH, poi la build adiacente ../deadair/target/{release,debug}/. È da 10 a 100 volte più veloce su grafi di grandi dimensioni (un grafo da 250k nodi si risolve in ~2s contro ~30s in Python) producendo classifiche identiche byte per byte. L'output registra quale motore è stato eseguito.

Pathing multi-obiettivo e vincolato