Percorsi di Attacco AD: Catene di Configurazioni Errate

Cosa sono gli Active Directory Attack Paths?

I percorsi di attacco di Active Directory sono catene di relazioni — appartenenze a gruppi, permessi ACL, collegamenti GPO, configurazioni di delega, account kerberoastabili — che collegano un aggressore con pochi privilegi a Domain Admin. Nessuna singola configurazione errata deve essere critica da sola: ciò che conta è se possono essere concatenate.

Gli avversari moderni non sfruttano vulnerabilità individuali. Mappano l'intero ambiente Active Directory come un grafo, identificano il percorso più breve dalla loro posizione attuale fino a Domain Admin, e seguono quel percorso — un salto alla volta. Ogni salto sfrutta una configurazione errata diversa: una password craccata, un percorso di nidificazione di gruppi, una ACL sfruttabile, o un certificato falsificato.

Questo articolo copre le tre categorie di percorso più affidabili: percorsi ACL, percorsi GPO e percorsi di Kerberoasting verso Domain Admin.

Come funzionano gli Active Directory Attack Paths

L'analisi dei percorsi di attacco tratta Active Directory come un grafo diretto:

• Nodi = utenti, computer, gruppi, GPO, OU, domini
• Archi = relazioni sfruttabili (MemberOf, GenericAll, WriteDACL, GpLink, ecc.)

Strumenti come BloodHound (open source) raccolgono questi dati di grafo e usano Neo4j per trovare i percorsi più brevi tra due nodi qualsiasi. Un aggressore che esegue BloodHound da un account utente standard compromesso può visualizzare l'intero percorso verso Domain Admin in pochi minuti — spesso trovando percorsi che hanno richiesto anni di configurazioni errate accumulate per formarsi.

Categorie di percorso comuni

La catena di attacco

Passo 1 - Raccogliere i dati del grafo AD

# Da Linux con credenziali valide — collettore BloodHound CE (pip install bloodhound-ce)
bloodhound-ce-python -u [email protected] -p password -ns 10.10.0.1 -d corp.local -c All --zip

# bloodhound-python (pip install bloodhound) è il collettore legacy: solo BloodHound 4.2/4.3

# Da Windows
.\SharpHound.exe -c All --zipfilename corp_bloodhound.zip

Passo 2 - Trovare i percorsi più brevi verso Domain Admin

Nell'interfaccia di BloodHound o nel browser Neo4j:

// Percorso più breve da un utente qualsiasi verso Domain Admins
MATCH p=shortestPath((u:User {enabled:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"}))
RETURN p ORDER BY length(p) ASC LIMIT 10

// Trovare tutti gli utenti kerberoastabili con percorso verso DA
MATCH (u:User {hasspn:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"})
RETURN u.name, u.pwdlastset

// Trovare percorsi di diritti di modifica GPO verso i DC
MATCH p=(u:User)-[:GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner*1..]->(g:GPO)-[:GPLink]->(c:OU)
WHERE c.blocksinheritance = false
RETURN p

Passo 3 - Seguire il percorso più breve

Un percorso reale tipico:

1. L'aggressore compromette jsmith (utente standard) tramite phishing
2. jsmith ha GenericWrite su svc_deploy (residuo di un progetto precedente)
3. svc_deploy è kerberoastabile con una password vecchia di 3 anni
4. L'aggressore scrive uno SPN su svc_deploy tramite GenericWrite e cracca il ticket di servizio risultante (Kerberoasting mirato), oppure scrive msDS-KeyCredentialLink per le Shadow Credentials — GenericWrite da solo non consente un reset della password, che richiede ForceChangePassword o GenericAll
5. svc_deploy è membro del gruppo IT_Admins
6. IT_Admins è nidificato dentro Domain Admins
7. Compromissione totale del dominio — 3 salti nel grafo, nessun exploit

Passo 4 - Mantenere la persistenza

Una volta ottenuto l'accesso DA, l'aggressore stabilisce la persistenza tramite Golden Ticket, nuovi account backdoor, o backdoor nei certificati ADCS — assicurandosi di sopravvivere ai reset delle password e ai tentativi di remediation.

Rilevamento

Rilevare l'attraversamento di un percorso di attacco richiede il monitoraggio di ogni singolo salto — nessun singolo evento di log rivela l'intero percorso.

Event ID di Windows

Query di correlazione SIEM

KQL filtra solo i documenti — non può aggregare — quindi la correlazione vera e propria si esprime in ES|QL:

// Rilevare eventi rapidi e sequenziali di escalation dei privilegi dalla stessa origine
FROM logs-*
| WHERE event.code IN ("4769", "4724", "4728", "5136")
    AND @timestamp > NOW() - 1 hour
| STATS event_count = COUNT(*) BY winlog.event_data.SubjectUserName
| WHERE event_count > 3

Remediation

1. Eliminare prima i percorsi più brevi

Esegui BloodHound ed esporta i primi 10 percorsi più brevi verso Domain Admin. Per ogni percorso:

• Arco ACL: rimuovi l'ACE pericolosa dall'oggetto
• Arco di nidificazione di gruppi: rimuovi il gruppo dal gruppo privilegiato
• Arco kerberoastabile: ruota la password o migra a gMSA
• Arco GPO: rimuovi i diritti di modifica dall'account non amministrativo

2. Implementare il monitoraggio continuo dei percorsi di attacco

# Raccolta settimanale di BloodHound tramite attività pianificata
# SharpHound è un eseguibile nativo: passa i flag esplicitamente (lo splatting di hash-table si lega
# solo ai cmdlet PowerShell, non a un .exe)
.\SharpHound.exe -c All `
    --outputdirectory "C:\BloodHound\Collections\" `
    --zipfilename "weekly_$(Get-Date -Format yyyyMMdd).zip"
# Confronta con i dati della settimana precedente e genera un avviso sui nuovi percorsi DA

3. Dare priorità agli account kerberoastabili nel percorso DA

# Trovare tutti gli account kerberoastabili con qualsiasi percorso verso privilegi DA
# -Filter richiede una stringa; krbtgt ha uno SPN ma non è roastabile in pratica
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties MemberOf, PasswordLastSet |
    Where-Object { $_.SamAccountName -ne "krbtgt" } |
    Where-Object {
        $_.MemberOf | Get-ADGroup | Where-Object { $_.Name -match "Admin" }
    } | Select-Object SamAccountName, PasswordLastSet
# Migra subito questi account a gMSA

Come EtcSec rileva questo

EtcSec esegue un'analisi continua dei percorsi di attacco sull'intero grafo Active Directory, identificando tutti i percorsi da account con pochi privilegi verso Domain Admin.

PATH_ACL_TO_DA mappa ogni percorso basato su ACL da utenti standard verso Domain Admin, incluse catene multi-salto attraverso oggetti intermedi.

PATH_GPO_TO_DA identifica i percorsi in cui i diritti di modifica GPO su policy collegate a OU Tier 0 forniscono un percorso indiretto verso la compromissione di un Domain Controller.

PATH_KERBEROASTING_TO_DA segnala gli account di servizio kerberoastabili che possiedono — direttamente o transitivamente — privilegi Domain Admin, rappresentando il percorso di attacco ad alto impatto più comune negli ambienti reali.

Priorità di revisione

I percorsi di attacco di Active Directory verso Domain Admin vanno trattati come una vera esposizione all'interno del tuo patrimonio Active Directory, non come una singola impostazione isolata. Inizia definendo il perimetro di revisione: quali gruppi privilegiati, account di servizio, ACL, collegamenti GPO, trust, impostazioni di delega, template di certificati e workstation amministrative sono coinvolti, quali flussi di lavoro aziendali ne dipendono, quali privilegi espongono e quali eccezioni di emergenza sono state aggiunte nel tempo. Questo passaggio di definizione dell'ambito evita una remediation superficiale, perché il sintomo tecnico è spesso più piccolo del raggio d'impatto operativo. Documentando il percorso completo dalla configurazione al privilegio, il team può dare priorità ai cambiamenti che riducono il rischio rapidamente senza interrompere l'accesso in produzione. Questo crea anche una base difendibile per la validazione successiva e offre alla leadership una spiegazione chiara del perché il problema conti adesso.

Controlli adiacenti da rivedere

Quando gli aggressori raggiungono il tuo patrimonio Active Directory, raramente si fermano al primo punto debole. Attorno ai percorsi di attacco di Active Directory verso Domain Admin, di solito verificano se il percorso esposto può essere concatenato con account privilegiati obsoleti, nidificazione pericolosa dei gruppi, delega eccessiva, policy di password deboli, percorsi GPO scrivibili e abuso di ACL ereditate. I difensori devono quindi rivedere non solo la debolezza principale, ma ogni dipendenza vicina che trasforma l'accesso in persistenza o escalation dei privilegi. Verifica quali identità, ruoli, permessi e assunzioni di fiducia possono essere riutilizzati da un operatore motivato. Se una correzione chiude un solo oggetto lasciando intatti percorsi di privilegio adiacenti, il rischio effettivo cambia poco. Una revisione disciplinata delle opportunità di concatenamento è ciò che trasforma questo argomento in un esercizio pratico di hardening invece che in una semplice casella da spuntare.

Evidenze e telemetria da raccogliere

Una risposta solida ai percorsi di attacco di Active Directory verso Domain Admin richiede evidenze che i team di engineering e detection possano rileggere insieme. Raccogli gli Event ID 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, i cambi SYSVOL e l'attività dei certificati o della CA, confronta i cambi recenti con le finestre di manutenzione note, e isola gli account o i sistemi che hanno cambiato comportamento senza una motivazione di business chiara. Usa queste evidenze per rispondere a tre domande: quando è comparso il percorso a rischio, chi può ancora sfruttarlo, e se esiste un'esposizione simile altrove nel tuo patrimonio Active Directory. Una buona revisione della telemetria aiuta anche a distinguere il debito tecnico ereditato dall'abuso attivo. Questa distinzione conta, perché il piano di remediation per una configurazione errata datata è diverso da quello per un percorso che mostra già attività simile a quella di un aggressore o eccezioni di policy ripetute.

Debolezze adiacenti che vale la pena rivedere

Pochissimi ambienti contengono solo percorsi di attacco di Active Directory verso Domain Admin. In pratica, lo stesso segmento di tenant o directory contiene spesso anche account privilegiati obsoleti, nidificazione pericolosa dei gruppi, delega eccessiva, policy di password deboli, percorsi GPO scrivibili e abuso di ACL ereditate, e sono proprio queste debolezze vicine a decidere se il problema resta solo rumoroso o diventa davvero critico. Rivedi owner condivisi, permessi ereditati, eccezioni duplicate e scorciatoie amministrative di lunga data. Verifica se lo stesso team ha approvato schemi rischiosi simili in più punti, perché decisioni ripetute di solito indicano una lacuna di processo piuttosto che un singolo bug tecnico. Questa revisione più ampia evita una pulizia parziale e aumenta le probabilità di eliminare l'intero percorso di attacco. Migliora anche la prontezza per gli audit, perché lo stato finale è più facile da spiegare e da monitorare nel tempo.

Letture correlate

Rivedi questo argomento insieme a Abuso ACL e DCSync: i percorsi silenziosi verso Domain Admin, Nidificazione pericolosa dei gruppi AD: percorsi nascosti verso Domain Admin, Attacchi alle trust di Active Directory: dal dominio figlio alla radice della foresta, Configurazioni errate GPO: come Group Policy diventa un vettore di attacco, e Monitoraggio di Active Directory: gli Event ID di sicurezza che contano. Questi articoli correlati mostrano come le stesse debolezze di identità si concatenano di solito in una valutazione reale, invece di comparire come risultati isolati.

• Abuso ACL e DCSync: i percorsi silenziosi verso Domain Admin
• Nidificazione pericolosa dei gruppi AD: percorsi nascosti verso Domain Admin
• Attacchi alle trust di Active Directory: dal dominio figlio alla radice della foresta
• Configurazioni errate GPO: come Group Policy diventa un vettore di attacco
• Monitoraggio di Active Directory: gli Event ID di sicurezza che contano

L'uso di questi riferimenti mantiene la discussione sulla remediation concentrata sull'intero percorso di attacco invece che su una singola lacuna di controllo.

Checklist di validazione

Prima di chiudere la revisione, riesegui gli stessi controlli che hanno rivelato il problema e conferma che il percorso a rischio non esiste più dal punto di vista dell'aggressore. Verifica le identità, i privilegi, i percorsi di ereditarietà e i controlli compensativi rilevanti in produzione, non solo in staging o nella documentazione. Registra il proprietario tecnico, la dipendenza di business attesa, e l'evidenza che la nuova configurazione è sia più sicura sia operativamente sostenibile. Questo passaggio finale di validazione è ciò che mantiene l'articolo ancorato a come i team riducono davvero il rischio identitario.