External Forest Domain - One-Way (Outbound)
Last updated
Last updated
Impara e pratica il Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica il Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
In questo scenario il tuo dominio sta fidando alcuni privilegi a un principale di domini diversi.
Una vulnerabilità di sicurezza esiste quando viene stabilita una relazione di fiducia tra due domini, identificati qui come dominio A e dominio B, dove il dominio B estende la sua fiducia al dominio A. In questa configurazione, viene creato un account speciale nel dominio A per il dominio B, che gioca un ruolo cruciale nel processo di autenticazione tra i due domini. Questo account, associato al dominio B, viene utilizzato per crittografare i ticket per accedere ai servizi tra i domini.
L'aspetto critico da comprendere qui è che la password e l'hash di questo account speciale possono essere estratti da un Domain Controller nel dominio A utilizzando uno strumento da riga di comando. Il comando per eseguire questa azione è:
Questa estrazione è possibile perché l'account, identificato con un $ dopo il suo nome, è attivo e appartiene al gruppo "Domain Users" del dominio A, ereditando così i permessi associati a questo gruppo. Ciò consente agli individui di autenticarsi contro il dominio A utilizzando le credenziali di questo account.
Attenzione: È possibile sfruttare questa situazione per ottenere un accesso nel dominio A come utente, sebbene con permessi limitati. Tuttavia, questo accesso è sufficiente per eseguire l'enumerazione nel dominio A.
In uno scenario in cui ext.local è il dominio fiducioso e root.local è il dominio di fiducia, un account utente chiamato EXT$ verrebbe creato all'interno di root.local. Attraverso strumenti specifici, è possibile estrarre le chiavi di fiducia di Kerberos, rivelando le credenziali di EXT$ in root.local. Il comando per ottenere questo è:
Seguendo questo, si potrebbe utilizzare la chiave RC4 estratta per autenticarsi come root.local\EXT$ all'interno di root.local utilizzando un altro comando dello strumento:
Questo passaggio di autenticazione apre la possibilità di enumerare e persino sfruttare i servizi all'interno di root.local, come eseguire un attacco Kerberoast per estrarre le credenziali degli account di servizio utilizzando:
Nel flusso precedente è stato utilizzato l'hash di fiducia invece della password in chiaro (che è stata anche estratta da mimikatz).
La password in chiaro può essere ottenuta convertendo l'output [ CLEAR ] di mimikatz da esadecimale e rimuovendo i byte nulli ‘\x00’:
A volte, quando si crea una relazione di fiducia, l'utente deve digitare una password per la fiducia. In questa dimostrazione, la chiave è la password di fiducia originale e quindi leggibile dall'uomo. Man mano che la chiave cicla (30 giorni), la password in chiaro non sarà leggibile dall'uomo ma tecnicamente ancora utilizzabile.
La password in chiaro può essere utilizzata per eseguire l'autenticazione regolare come account di fiducia, un'alternativa alla richiesta di un TGT utilizzando la chiave segreta Kerberos dell'account di fiducia. Qui, interrogando root.local da ext.local per i membri di Domain Admins:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
