warpedatom/noisehoundPunteggio dei percorsi di attacco BloodHound consapevole del rilevamento - la via più silenziosa verso il tuo obiettivo, calibrata su cinque livelli di rilevamento (audit/EDR/Elastic/MDI/WDAC) più 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>
**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](https://github.com/warpedatom/noisehound/blob/main/docs/WALKTHROUGH.md) è 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/`](https://github.com/warpedatom/noisehound/blob/main/profiles), con
> prova a ciclo chiuso che modificano la classificazione dei percorsi ([`docs/VALIDATION.md`](https://github.com/warpedatom/noisehound/blob/main/docs/VALIDATION.md)).
> Il corpus include 13 edge **Azure/Entra** ([`docs/AZURE.md`](https://github.com/warpedatom/noisehound/blob/main/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](https://github.com/warpedatom/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
Rumore, numero di hop e probabilità di rilevamento tirano in direzioni diverse, quindi `--pareto` restituisce la **frontiera di Pareto** - ogni percorso che nessun altro batte su tutti e tre contemporaneamente - invece di forzare un singolo vincitore. E le operazioni reali hanno vincoli: `--avoid NODE` tiene un percorso lontano da un host specifico (un jump box monitorato da EDR, un honeypot), e `--avoid-edge TYPE` rifiuta una tecnica (ad es. `--avoid-edge DCSync`). Entrambi sono ripetibili e risolvono nuovamente al volo.
```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
```
## Come si confronta NoiseHound
Il pathfinding pesato di BloodHound non è una novità, quindi ecco un posizionamento onesto:
- **BloodHound / BloodHound CE** trovano *un* percorso tramite conteggio dei salti non pesato. Nessun modello di rumore.
- **GoodHound** assegna costi agli edge e trova i percorsi meno costosi, ma il suo modello di costo è la difficoltà di sfruttamento e il rischio aziendale, non il rumore di rilevamento.
- **PlumHound / ImproHound** svolgono reporting e analisi delle violazioni di tier; nessuno dei due risolve nuovamente per un percorso più silenzioso verso l'obiettivo.
- **Le mappature di rilevamento** (Sigma, DeTT&CT, riferimenti event-ID-to-ATT&CK) sono ricche ma orientate all'essere umano e non correlate ai tipi di edge di BloodHound.
Il contributo di NoiseHound è la combinazione: un corpus leggibile dalla macchina che mappa gli edge di BloodHound alla telemetria di rilevamento, una ri-soluzione pesata sul rumore impostata come OPSEC dell'operatore ("il modo più silenzioso per arrivare a DA"), un modello dell'ambiente che si adatta alla postura dichiarata di un target, e un ciclo di calibrazione che trasforma i rilevamenti di laboratorio in punteggi misurati. La matematica del grafo è merce comune; il corpus e l'impostazione sono il punto. Il suo valore è buono solo quanto il corpus, motivo per cui la calibrazione e il contributo della community sono di prim'ordine - vedi sotto.
## Installazione
```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 .
```
Richiede Python 3.10+.
## Utilizzo
```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
```
Per prima cosa, verifica il parser sul tuo export (istogrammi + copertura del corpus, senza pathing) - il modo più rapido per validare NoiseHound su dati reali:
```bash
noisehound-inspect -i export.zip
```
### BloodHound CE / Neo4j in tempo reale
Invece di un file zip, punta `--input` al database Neo4j popolato da BloodHound CE
e NoiseHound legge il grafo (già analizzato) direttamente tramite 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"
```
Avvia BloodHound CE (include Neo4j sulla porta 7687) con il suo compose ufficiale:
`curl -L https://ghst.ly/getbhce | docker compose -f - up`.
Provalo con i campioni inclusi:
```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
```
L'ultimo è la dimostrazione più chiara della tesi: la rotta più silenziosa verso i Domain Admins è il percorso di sessione a 4 hop, classificato *sopra* il percorso RDP a 3 hop e l'ADCS ESC1 a 1 hop - più hop, meno rumore.
Il campione dimostra il valore centrale: la rotta più silenziosa è un percorso di sessione a 4 hop (punteggio 19,9), classificato *sopra* una scorciatoia ForceChangePassword a 2 hop (36,4). Meno hop non significa più silenzioso.
### Modalità blue-team detection-gap
Il percorso più silenzioso è quello in cui il rilevamento è più debole, quindi aggiungi `--defensive` per invertire l'output a favore dei difensori: segnala gli edge che sono silenziosi solo perché la loro telemetria è disattivata o assente, mappa ciascuno al controllo che lo intercetterebbe e classifica tali controlli in base a quanto aumentano il punteggio del percorso più silenzioso.
```bash
python -m noisehound -i export.zip -s jdoe -o "Domain Admins" --defensive
```
Sul campione full-spectrum rileva che il percorso più silenzioso verso Domain Admins
dipende da un accesso a LSASS non rilevato (`HasSession`, 20 -> 65 se strumentato) e
raccomanda di distribuire Sysmon Event 10 - chiudere questa singola lacuna innalza il percorso
più silenzioso da 19,9 a 48,4. Vedi [`docs/ROADMAP.md`](https://github.com/warpedatom/noisehound/blob/main/docs/ROADMAP.md) per la direzione
di questo e del resto del modello.
### Opzioni principali
| Opzione | Significato |
|--------|---------|
| `--input, -i` | BloodHound `.zip`, `.json`, o directory di esportazioni |
| `--source, -s` | Principal di partenza (`jdoe` o un id di oggetto) |
| `--objective, -o` | Nodo di destinazione (`Domain Admins` o un id di oggetto) |
| `--paths, -k` | Numero di percorsi più silenziosi da restituire (predefinito 5) |
| `--format, -f` | `text` (predefinito), `json`, o `html` |
| `--defensive` | Vista blue-team: lacune di rilevamento sui percorsi più silenziosi + correzioni |
| `--rank-by` | `noise` (predefinito) o `probability` (P di un avviso correlato) |
| `--correlation` | Coefficiente di correlazione SOC per P(rilevato), 0..1 (predefinito 0.5) |
| `--pareto` | Restituisce la frontiera di Pareto su rumore/hop/P(rilevamento) |
| `--engine` | `auto` (predefinito), `python`, o `rust` (il motore DeadAir) |
| `--avoid NODE` | Esclude un nodo da tutti i percorsi (ripetibile) |
| `--avoid-edge TYPE` | Esclude un tipo di arco da tutti i percorsi (ripetibile) |
| `--corpus` | Sovrascrive la directory del corpus di mappatura degli archi |
| `--environment, -e` | Postura del target dichiarata dall'operatore in JSON (regola i punteggi) |
| `--max-weight` / `--mean-weight` | Pesi di scoring (devono sommare a 1.0) |
| `--default-noise` | Punteggio per i tipi di arco assenti dal corpus (predefinito 60) |
---
## Profili di ambiente
Un punteggio statico del corpus non può sapere se un dato target ha il controllo degli oggetti
4662 attivo, distribuisce Sysmon, o esegue un ITDR come MDI - eppure questi fattori spostano
enormemente il rumore reale di un arco (DCSync è quasi silenzioso senza il controllo 4662 e
quasi certamente rilevato con esso). Invece di fingere che un unico numero vada bene per ogni
ambiente, dichiara la postura del target in un piccolo file JSON e NoiseHound
regolerà i punteggi in modo trasparente rispetto alle annotazioni di telemetria del corpus stesso:
```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 }
}
```
Gli aggiustamenti possono solo *aumentare* un punteggio verso un limite di rilevamento implicito dalla postura dichiarata. Gli `adjustments` sono override rigidi per singolo arco - il luogo in cui registrare i valori calibrati sul proprio laboratorio. Sono forniti dall'operatore, non misurati; non sostituiscono la validazione live della Fase 2, ma trasformano il corpus statico da "un numero per tutti gli ambienti" a "il numero per l'ambiente in cui ci si trova effettivamente". Sul campione incluso, dichiarare il profilo sopra sposta la rotta più silenziosa dal percorso di sessione con dump LSASS a un percorso di scrittura su directory - che è la scelta corretta una volta che la telemetria dell'host è attiva.
```bash
python -m noisehound -i samples/sample_graph.json -s jdoe -o "Domain Admins" \
-e samples/env_profile.example.json
```
Precedenza del punteggio: `static -> environment-adjusted -> live (Phase 2)`.
---
## Harness di calibrazione
I profili di ambiente valgono solo quanto i numeri che vi inserisci.
`noisehound-calibrate` chiude il ciclo: esegue le tecniche in un laboratorio di
rilevamento, registra ciò che ha generato un rilevamento e produce un profilo di
ambiente calibrato.
**Questo è già stato fatto.** [`profiles/`](https://github.com/warpedatom/noisehound/blob/main/profiles) include sei profili misurati da un
range Hyper-V Vulnerable-AD reale e da un tenant Azure di laboratorio - audit, EDR (Defender for
Endpoint), Elastic SIEM, Defender for Identity e livelli WDAC, oltre a un livello Azure/Entra misurato,
37 edge - prodotti dal harness automatizzato (`lab/`) e da questo
strumento. Usali direttamente, oppure misura i tuoi:
```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
```
Il modello di punteggio è uno stimatore di contrazione, onesto riguardo alla dimensione del campione:
```
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` è il costo di rilevamento atteso - la severità SOC quando scatta, un piccolo residuo quando non lo fa. Il peso `w` impedisce che una singola esecuzione sovrascriva il corpus, consentendo al contempo a un risultato ben campionato di dominare. Nell'esempio, HasSession sale da un valore statico di 20 a 52 (il lab ha rilevato il dump di LSASS in 4 esecuzioni su 5) mentre Kerberoast scende da 60 a 34 (non è mai scattato). Usa `--merge existing.json` per sovrapporre la nuova calibrazione a un profilo mantenendone i flag di postura, e `--smoothing` / `--residual` per regolare il modello.
---
## Punteggio rispetto ai rilevamenti distribuiti (Sigma)
I profili di ambiente e la calibrazione sono autodichiarati. `noisehound-sigma`
calcola il punteggio rispetto ai rilevamenti che un difensore ha *effettivamente scritto*: puntalo a un
set di regole Sigma e determina su quali archi del corpus ciascuna regola scatterebbe
(confrontando gli event ID di telemetria dell'arco e la tecnica ATT&CK), quindi emette un
profilo di ambiente che innalza gli archi coperti - un sostituto diretto per `--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
```
Per il livello identità, **`noisehound-mdi`** fa lo stesso nei confronti delle rilevazioni integrate di Microsoft Defender for Identity - mappa gli avvisi runtime di MDI (e, con `--include-posture`, le sue valutazioni ISPM) sugli archi del corpus ed emette un profilo di livello identità. MDI è indipendente dallo strumento, quindi la sua copertura vale indipendentemente dal tooling dell'attaccante.
```bash
noisehound-mdi -o env.mdi.json # + coverage report (which edges MDI watches, and the gaps)
```
Per gli edge **Azure/Entra**, **`noisehound-entra`** misura il livello cloud
allo stesso modo in cui sono stati misurati i livelli on-prem: attiva gli abusi `AZ*` in un tenant di laboratorio,
esporta la traccia `directoryAudits` di Entra, e conta ciò che effettivamente ha registrato in un
profilo calibrato (`docs/AZURE_CALIBRATION.md`).
```bash
noisehound-entra -a directoryAudits.json -m entra_runs.json --profile-out profiles/lab-tenant-azure.json
```
La corrispondenza è volutamente conservativa, così non nasconde mai una lacuna: una regola conta solo se fa riferimento a un ID evento generato dall'edge *e*, quando la regola è taggata ATT&CK, la sua tecnica concorda — quindi una regola DCSync DS-Access (4662) non viene erroneamente accreditata di coprire letture LAPS che condividono semplicemente l'ID evento. Il report elenca sia ciò che le tue regole coprono sia, cosa più utile, gli edge di attacco che nessuna regola copre. Combinato con `--defensive`, questo risponde alla domanda: "date le detection che ho distribuito, dove è ancora invisibile il mio percorso di attacco più silenzioso?"
### Inventario live di Elastic Security
`noisehound-elastic` risponde alla stessa domanda rispetto alle detection che sono **effettivamente abilitate in questo momento** in uno stack Elastic Security in esecuzione, anziché rispetto alle regole su disco. Legge il motore di detection tramite l'API `_find` in sola lettura di Kibana (o un export offline), mappa la tecnica ATT&CK di ogni regola abilitata e qualsiasi codice evento Windows presente nella sua query, ed emette lo stesso profilo di copertura `--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
```
Riusa il matcher Sigma e aggiunge un livello solo-tecnica (contrassegnato `[technique]`, con punteggio inferiore) per le regole comportamentali KQL/EQL che non nominano mai un codice evento. Le regole disabilitate vengono ignorate. Stesso schema normalizza-poi-valuta per Splunk / Sentinel / MDI a seguire.
---
## AD CS ESC1-8
Al momento del caricamento NoiseHound esegue una versione mirata della post-elaborazione ADCS di BloodHound, sintetizzando archi di escalation dai fatti template/CA conservati. Un diritto `Enroll` su un template vulnerabile diventa un arco diretto `ADCSESCn` dal principal al gruppo Domain Admins del dominio (RID 512), così l'escalation tramite certificato è percorribile e valutata come qualsiasi altro arco:
| Arco | Condizione |
|------|-----------|
| `ADCSESC1` | Enrollee-supplies-subject + EKU client-auth, nessuna approvazione/firma RA |
| `ADCSESC2` | EKU Any-Purpose / SubCA, nessuna approvazione |
| `ADCSESC3` | Template enrollment-agent + un template di autenticazione sulla stessa CA |
| `ADCSESC4` | Controllo di scrittura pericoloso su un template pubblicato |
| `ADCSESC5` | Controllo dell'oggetto CA o del computer che lo ospita |
| `ADCSESC6` | La CA ha `EDITF_ATTRIBUTESUBJECTALTNAME2` impostato |
| `ADCSESC7` | `ManageCA` / `ManageCertificates` sulla CA |
| `ADCSESC8` | Endpoint web-enrollment HTTP vulnerabile (coerce + NTLM relay) |
Provalo: `python -m noisehound -i samples/sample_adcs_ce.zip -s jdoe -o "Domain Admins"`.
Semplificazioni documentate (falliscono in modo sicuro verso la visualizzazione di più percorsi): le restrizioni di enrollment a livello di CA non sono modellate (l'enrollment del template è considerato sufficiente); ESC5 copre l'oggetto CA e il suo host, non ogni container PKI; ESC9/10/13 sono fuori ambito. Gli archi ESC sintetici già presenti in un export post-elaborato vengono preservati.
---
## Il corpus (`edge_mappings/`)
Il corpus di telemetria degli archi è la vera proprietà intellettuale di questo strumento; il codice è una matematica di grafi relativamente semplice costruita sopra di esso. Ogni `edge_mappings/<Edge>.json` mappa un tipo di arco BloodHound alla sua superficie di rilevamento:
- sorgenti di telemetria attese (Windows Security Event ID, Sysmon Event ID, rete, euristiche EDR/ITDR) con affidabilità per sorgente e se il relativo auditing è attivo per impostazione predefinita
- un punteggio di rumore statico (0-100)
- tecnica MITRE, privilegio prerequisito, la primitiva di abuso abituale e note
```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."
}
```
Estendere il corpus è l'ambito in cui dovrebbe confluire la maggior parte dello sforzo continuativo. Aggiungi un nuovo file JSON, mantieni lo schema (validato al caricamento) e viene rilevato automaticamente. La v0.3 include 43 tipi di edge che coprono gli edge di abuso ACL, Kerberos, delega, ADCS ESC1-8, LAPS/gMSA, GPO, trust e diritti di accesso rilevanti per il path-finding.
I punteggi sono inizializzati dalla noise matrix del DreadHost Red Team Operator Playbook (mappature degli eventi Windows/Sysmon, valutazioni del rumore delle tecniche) e da fatti standard di rilevamento AD. Tarali in base ai dati di rilevamento del tuo laboratorio.
---
## Roadmap
- **Copertura Azure / Entra ID (fondamenta rilasciate, in espansione).** 13 edge di attack-path `AZ*` sono ora inclusi con telemetria di rilevamento nativa Entra - vedi [`docs/AZURE.md`](https://github.com/warpedatom/noisehound/blob/main/docs/AZURE.md). I dati Azure raccolti tramite AzureHound in BloodHound CE vengono valutati già oggi (`noisehound -o "Global Administrator"`), e sono ora inclusi anche l'ingestione nativa AzureHound e un tier di calibrazione Azure/Entra misurato (`noisehound-entra`, `profiles/lab-tenant-azure.json`). Prossimo passo: profili di postura Entra (MDCA / ID Protection / Sentinel) ed edge ibridi (Entra Connect / PHS-PTA) affinché **MDI** contribuisca attraverso il confine on-prem/cloud.
- **Completare la calibrazione - 37/77 misurati, in corso.** I restanti ~40 edge (coercion/relay, ADCS ESC2-13, CanRDP su bare metal), una calibrazione multi-ambiente più approfondita e un corpus multi-EDR (CrowdStrike/S1 accanto a MDE), oltre alla calibrazione del tooling per singolo edge per ampliare l'asse `--tooling`.
- **Sintesi ADCS ESC10a/10b/13** (la sintesi ESC1-9 è già inclusa).
Rilasciati: il motore Rust ([DeadAir](https://github.com/warpedatom/DeadAir), dispatch `--engine`), l'ingestione live Neo4j Bolt (`--input bolt://...`), l'asse selezionabile **`--tooling`** (off-the-shelf-on-host vs remote/native; `docs/TOOLING_AXIS.md`), l'hook Phase 2 **`--live-scores`** (i punteggi misurati sovrascrivono corpus/ambiente) e **`noisehound-mdi`** (copertura Defender for Identity -> profilo identity-tier). Il lavoro MDI rimanente è la *calibrazione degli avvisi runtime* vincolata al laboratorio (`docs/CALIBRATION.md`).
## Contribuire
Il corpus è estendibile dalla community ed è qui che i contributi contano di più. Aggiungere un edge è un singolo file JSON validato al caricamento e in CI:
```bash
noisehound-validate # schema + consistency checks over the corpus
python -m pytest tests/ -q
```
Consulta [CONTRIBUTING.md](https://github.com/warpedatom/noisehound/blob/main/CONTRIBUTING.md) per lo schema, la guida alla valutazione e le indicazioni per le PR, e [`docs/edge_schema.json`](https://github.com/warpedatom/noisehound/blob/main/docs/edge_schema.json) per lo schema formale degli edge.
## Calibrazione rispetto a un laboratorio
30 edge sono misurati (vedi [`profiles/`](https://github.com/warpedatom/noisehound/blob/main/profiles)); i restanti sono stime finché non li misuri, e ogni ambiente è diverso. [`docs/CALIBRATION.md`](https://github.com/warpedatom/noisehound/blob/main/docs/CALIBRATION.md) è un playbook completo: topologia del laboratorio, la policy di audit di Windows e la configurazione di Sysmon esatte per far scattare gli event ID del corpus, un runbook di esercitazione per ogni edge, un livello di realismo APT29-via-Caldera e come compilare i risultati in un profilo calibrato. Inizia con `noisehound-calibrate --template -o lab_detections.json`.
Il kit [`lab/`](https://github.com/warpedatom/noisehound/blob/main/lab) automatizza la strumentazione di rilevamento: `Enable-Telemetry.ps1` attiva la policy di audit, il logging degli script-block, la SACL DCSync e Sysmon; `Collect-Detections.ps1` conteggia ciò che è scattato in una finestra temporale. Si basa su [GOAD](https://github.com/Orange-Cyberdefense/GOAD) o [Vulnerable-AD](https://github.com/WazeHell/vulnerable-AD) (o su qualsiasi AD di laboratorio di training esistente) per il dominio vulnerabile stesso, anziché reimplementarli.
## Uso responsabile
NoiseHound è destinato a test di sicurezza autorizzati, esercitazioni purple-team, detection engineering e ricerca. Legge i dati BloodHound che hai già raccolto e calcola classifiche; non esegue nulla contro un target. Usalo solo dove disponi di autorizzazione scritta esplicita. I contributi non devono includere dati specifici di target o di engagement reali.
## 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
```