Trust AD: Dal Dominio Figlio alla Radice

Cosa Sono gli Attacchi alle Trust AD?

Gli attacchi alle Trust AD sfruttano i percorsi di autenticazione e autorizzazione che permettono a un dominio o a una foresta di accedere alle risorse di un altro. Le trust sono una parte normale di AD DS. Le trust padre-figlio all'interno di una foresta, le trust esterne, le shortcut trust e le forest trust esistono tutte per supportare reali esigenze di accesso. Il rischio e che una trust estende anche il perimetro di sicurezza che i difensori devono comprendere.

Una trust non significa automaticamente una compromissione. Il rischio pratico dipende dal tipo di trust, dalla direzione, dalla transitivita, dal comportamento del SID filtering, dalla selective authentication, dal tiering amministrativo e dal livello di compromissione nel dominio di origine. Ma in una foresta multi-dominio, la compromissione di un dominio figlio puo diventare un incidente a livello di foresta se l'aggressore riesce ad abusare di percorsi di trust Kerberos, SID privilegiati o accesso amministrativo che attraversa il confine.

Una buona review parte da tre domande:

quali trust esistono e chi ne e proprietario
quali trust hanno ancora un requisito di business attuale
se ogni trust limita l'autorizzazione cross-dominio all'ambito previsto

Come Funzionano le Trust di Active Directory

Microsoft documenta che AD DS usa relazioni di trust tra domini e foreste per fornire autenticazione tra domini e foreste. Prima che l'accesso attraverso una trust sia possibile, Windows calcola un percorso di trust tra il domain controller della risorsa e un domain controller nel dominio dell'account richiedente.

Le trust possono essere monodirezionali o bidirezionali. Possono inoltre essere transitive o non transitive. In una foresta AD DS on-premises, i nuovi domini figlio creano automaticamente relazioni di trust bidirezionali e transitive con il dominio padre. Questa transitivita permette alle richieste di autenticazione di seguire i percorsi di trust lungo l'albero dei domini, quando i permessi lo consentono.

Questo comportamento e utile, ma significa che i difensori non dovrebbero trattare un dominio figlio come una directory a basso impatto. Se un dominio figlio e amministrato male, riceve una fiducia eccessiva o viene compromesso a livello di domain controller, la foresta deve essere rivista come un sistema di sicurezza connesso.

Dove Interviene il SID Filtering

I ticket Kerberos includono dati di autorizzazione, tra cui i SID usati per le decisioni di accesso. Il SID History esiste per scenari di migrazione in cui un account deve mantenere l'accesso a risorse che fanno ancora riferimento a un vecchio SID. La documentazione Microsoft su DsAddSidHistory segnala che aggiungere SID all'attributo sIDHistory di un security principal e un'operazione sensibile per la sicurezza, e che se un dominio delle risorse si fida del dominio account di un SID rubato o non autorizzato, l'utente non autorizzato puo ottenere accesso non autorizzato alle risorse di quel SID.

Il SID filtering e progettato per ridurre questo rischio ai confini di trust. La specifica PAC di Microsoft descrive il comportamento del SID filtering attraverso i confini di trust, incluse le trust cross-forest ed esterne. Il comportamento esatto dipende dal confine di trust e dalla categoria del SID, quindi e importante non ridurre il tema a un singolo flag senza comprendere il tipo di trust.

Per le trust esterne, gli amministratori in genere rivedono lo stato di quarantena o di SID filtering. Per le forest trust, anche la selective authentication e le impostazioni della forest trust possono essere rilevanti. Per le trust padre-figlio all'interno della stessa foresta, il tema piu grande e spesso architetturale: tutti i domini fanno parte dello stesso tessuto di trust della foresta, quindi la compromissione di un dominio puo avere conseguenze oltre il dominio locale.

Limiti di Ambito e Precondizioni

Questo non e un'affermazione secondo cui ogni trust AD e sfruttabile. L'abuso di trust ad alto impatto richiede normalmente un prerequisito forte, come:

la compromissione di un domain controller o di un segreto equivalente a livello di dominio nel dominio di origine
la capacita di forgiare o manipolare i dati di autorizzazione Kerberos
un percorso di trust che accetta il contesto di autorizzazione risultante
risorse target che autorizzano l'accesso in base a SID privilegiati o gruppi cross-dominio
una separazione debole tra i tier amministrativi tra domini

Per questo la review delle trust dovrebbe essere collegata alle assunzioni di incident response. Se il segreto krbtgt di un dominio figlio o i suoi domain controller sono compromessi, non trattare l'incidente come isolato finche i percorsi di trust, le sessioni privilegiate e l'autorizzazione cross-dominio non sono stati rivisti.

Pattern Comuni di Abuso delle Trust

Dal Dominio Figlio al Padre o alla Radice della Foresta

Lo scenario di escalation classico inizia con la compromissione di un dominio figlio. Se l'aggressore controlla il dominio di origine in modo sufficientemente profondo, puo provare a forgiare materiale Kerberos che porta dati di autorizzazione privilegiati verso una risorsa padre o della radice della foresta. Se questo ha successo dipende dal comportamento e dal filtering della trust, ma la lezione difensiva e chiara: i domini figlio richiedono una protezione di livello Tier 0 quando fanno parte della stessa foresta.

Trust Esterne Obsolete

Le vecchie trust esterne sono comuni dopo migrazioni, integrazioni con partner, acquisizioni o progetti temporanei. Una trust obsoleta puo ancora permettere percorsi di autenticazione che nessuno possiede piu attivamente. Anche con il SID filtering abilitato, una trust non necessaria resta comunque una superficie di attacco non necessaria.

Ownership Debole delle Trust

Una trust senza proprietario diventa difficile da modificare perche nessuno puo approvarne la rimozione. Questo porta a eccezioni permanenti. Ogni trust rimanente dovrebbe avere un owner applicativo, un owner di business, una direzione di autenticazione, gli utenti attesi e una data di review.

Amministrazione Privilegiata Attraverso i Confini

Le trust diventano piu pericolose quando gli amministratori usano credenziali privilegiate tra domini o foreste. Una sessione privilegiata in un dominio con governance piu debole puo esporre credenziali o token che permettono di muoversi verso un dominio piu sensibile. Il hardening delle trust e il hardening dell'accesso privilegiato devono essere rivisti insieme.

Rilevamento

Nessun singolo evento Windows dimostra un attacco alle trust. Il rilevamento richiede un inventario delle trust, la revisione degli eventi Kerberos, il contesto dei logon privilegiati e il change monitoring.

Fonti di Eventi e Log di Windows

Segnale	Perche e Importante
4769 richieste di service ticket Kerberos	Aiuta a indagare l'attivita di service ticket cross-dominio o cross-realm.
4624 logon riusciti	Mostra logon amministrativi o cross-dominio sui sistemi target.
4672 assegnazione di privilegi speciali	Utile quando un logon riceve diritti ad alto privilegio in modo inatteso.
Modifiche agli oggetti trust	Le modifiche alla direzione, agli attributi o al comportamento di filtering di una trust possono alterare il confine.
Modifiche ai gruppi privilegiati	Le modifiche di membership cross-dominio o dei gruppi annidati possono esporre percorsi basati sulle trust.

I dati degli eventi richiedono contesto. Un evento 4769 cross-dominio puo essere normale per un'applicazione. Un logon amministrativo cross-dominio da un account inatteso, dopo un incidente nel dominio figlio, e molto diverso.

Revisione dell'Inventario delle Trust

Inventaria tutte le trust e classificale:

Get-ADTrust -Filter * |
  Select-Object Name, TrustType, TrustDirection, ForestTransitive, SelectiveAuthentication, SIDFilteringQuarantined

Usa il risultato per la triage. SIDFilteringQuarantined = False non e automaticamente prova di compromissione o misconfigurazione, ma dovrebbe avere un owner e una motivazione. Se nessuno riesce a spiegare perche la trust necessita delle sue impostazioni attuali, appartiene alla coda di cleanup.

Rimedio

La trust piu sicura e quella che non esiste piu perche la dipendenza di business e terminata. Metti in sicurezza le trust rimanenti in base al loro tipo e scopo.

1. Rimuovi le Trust Obsolete

Rivedi per prime le vecchie trust di partner, migrazione, test e acquisizione. Se una trust non ha owner, non ha una dipendenza applicativa attiva e non ha un requisito di accesso recente, rimuovila tramite il normale processo di change.

2. Rivedi SID Filtering e Quarantena

Per le trust esterne dove e compatibile, abilita quarantena o SID filtering e valida i workflow dipendenti. Il comando Microsoft netdom trust supporta l'opzione /Quarantine per la gestione delle trust, e la documentazione del comando segnala che No accetta qualsiasi SID. Questa impostazione non dovrebbe essere lasciata al caso storico.

3. Usa la Selective Authentication Dove Appropriato

Per le forest trust, la selective authentication puo limitare quali utenti della foresta trusted possono autenticarsi su risorse specifiche. Non sostituisce buone ACL o una buona igiene dell'accesso privilegiato, ma riduce l'ampia portata di autenticazione.

4. Tratta i Domini Figlio come ad Alta Conseguenza

Non presumere che un dominio figlio sia una zona amministrativa a basso rischio. Proteggi i domain controller del dominio figlio, i gruppi privilegiati, la gestione di krbtgt e le workstation amministrative con la stessa serieta della radice della foresta, quando i percorsi di trust permettono l'accesso cross-dominio.

5. Riduci le Sessioni Privilegiate Attraverso i Confini

Non usare di routine account privilegiati della radice della foresta o del dominio padre in domini figlio meno trusted. Se gli amministratori devono attraversare il confine, usa account dedicati, workstation amministrative controllate e logging che renda la sessione visibile.

Cosa Non Cambiare alla Cieca

Non abilitare o rimuovere controlli di trust senza testare il flusso di autenticazione dipendente. SID filtering, quarantena e selective authentication possono rompere pattern di accesso legacy, workflow di migrazione o applicazioni costruite intorno a un ampio accesso cross-dominio. Questo rischio di compatibilita non e un motivo per lasciare la trust non sicura; e un motivo per documentare la dipendenza, testare in una finestra controllata e sostituire la trust ampia con accesso esplicito quando possibile. Se il business non puo rimuovere subito una trust rischiosa, l'eccezione dovrebbe includere un owner, una data di scadenza, un piano di monitoraggio e controlli compensativi per l'accesso privilegiato.

Validazione Dopo l'Hardening delle Trust

Dopo una modifica alla trust, valida sia la sicurezza sia la funzione di business:

riesegui l'inventario delle trust e registra direzione, tipo, transitivita, selective authentication e stato del SID filtering
conferma che i team applicativi abbiano ritestato i workflow che dipendono dalla trust
verifica che le vecchie trust di migrazione o partner siano state rimosse e non solo documentate
rivedi l'attivita Kerberos e di logon attraverso la trust dopo la modifica
controlla se gli utenti privilegiati si autenticano ancora attraverso il confine
documenta le eccezioni con owner, data di scadenza e controlli compensativi

Una review delle trust ha successo solo quando le trust rimanenti sono intenzionali, hanno un owner, sono monitorate e sono limitate all'accesso di cui il business ha ancora bisogno.

Come EtcSec Rileva Questo

EtcSec audita le relazioni di trust ed evidenzia i percorsi di trust che aumentano la probabilita di escalation cross-dominio.

I findings relativi alle trust sono piu utili quando vengono correlati con il percorso di attacco circostante: se un dominio figlio ha gia una scarsa igiene amministrativa, se una vecchia trust esterna esiste ancora, e se identita di alto valore o diritti delegati si trovano su entrambi i lati del confine.

Letture Correlate

Rivedi l'esposizione delle trust insieme a Percorsi di Attacco AD: Catene di Configurazioni Errate, Gruppi AD nidificati: Percorsi nascosti verso DA, Abuso ACL e DCSync: Percorsi verso Domain Admin, Attacchi Delega Kerberos: Non Vincolata a RBCD e Golden Ticket: Le Chiavi del Tuo Dominio. L'abuso delle trust e di solito un moltiplicatore di percorso, non una misconfigurazione isolata.

Attacchi alle Trust AD: Dal Dominio Figlio alla Radice