Active Directory Methodology
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Active Directory funge da tecnologia fondamentale, consentendo ai network administrator di creare e gestire in modo efficiente domini, utenti e oggetti all'interno di una rete. È progettato per scalare, facilitando l'organizzazione di un numero esteso di utenti in gruppi e sottogruppi gestibili, controllando i diritti di accesso a vari livelli.
La struttura di Active Directory è composta da tre livelli principali: domini, alberi e foreste. Un dominio comprende una raccolta di oggetti, come utenti o dispositivi, che condividono un database comune. Gli alberi sono gruppi di questi domini collegati da una struttura condivisa, e una foresta rappresenta la raccolta di più alberi, interconnessi tramite relazioni di fiducia, formando il livello più alto della struttura organizzativa. Specifici diritti di accesso e comunicazione possono essere designati a ciascuno di questi livelli.
I concetti chiave all'interno di Active Directory includono:
Directory – Contiene tutte le informazioni relative agli oggetti di Active Directory.
Oggetto – Denota entità all'interno della directory, inclusi utenti, gruppi o cartelle condivise.
Dominio – Funziona come contenitore per gli oggetti della directory, con la capacità di più domini di coesistere all'interno di una foresta, ciascuno mantenendo la propria raccolta di oggetti.
Albero – Un raggruppamento di domini che condividono un dominio radice comune.
Foresta – Il culmine della struttura organizzativa in Active Directory, composta da diversi alberi con relazioni di fiducia tra di loro.
Active Directory Domain Services (AD DS) comprende una serie di servizi critici per la gestione centralizzata e la comunicazione all'interno di una rete. Questi servizi comprendono:
Servizi di Dominio – Centralizza l'archiviazione dei dati e gestisce le interazioni tra utenti e domini, inclusi funzionalità di autenticazione e ricerca.
Servizi di Certificato – Supervisiona la creazione, distribuzione e gestione di certificati digitali sicuri.
Servizi di Directory Leggeri – Supporta applicazioni abilitate per directory tramite il protocollo LDAP.
Servizi di Federazione della Directory – Fornisce capacità di single-sign-on per autenticare gli utenti attraverso più applicazioni web in una singola sessione.
Gestione dei Diritti – Aiuta a proteggere il materiale protetto da copyright regolando la sua distribuzione e uso non autorizzati.
Servizio DNS – Cruciale per la risoluzione dei nomi di dominio.
Per una spiegazione più dettagliata, controlla: TechTerms - Definizione di Active Directory
Per imparare a attaccare un AD devi comprendere molto bene il processo di autenticazione Kerberos. Leggi questa pagina se non sai ancora come funziona.
Puoi visitare https://wadcoms.github.io/ per avere una visione rapida dei comandi che puoi eseguire per enumerare/sfruttare un AD.
Se hai solo accesso a un ambiente AD ma non hai credenziali/sessioni, potresti:
Pentestare la rete:
Scansiona la rete, trova macchine e porte aperte e prova a sfruttare vulnerabilità o estrarre credenziali da esse (ad esempio, le stampanti potrebbero essere obiettivi molto interessanti.
Enumerare il DNS potrebbe fornire informazioni sui server chiave nel dominio come web, stampanti, condivisioni, vpn, media, ecc.
gobuster dns -d domain.local -t 25 -w /opt/Seclist/Discovery/DNS/subdomain-top2000.txt
Dai un'occhiata alla Metodologia di Pentesting Generale per trovare ulteriori informazioni su come fare questo.
Controlla l'accesso nullo e Guest sui servizi smb (questo non funzionerà su versioni moderne di Windows):
enum4linux -a -u "" -p "" <DC IP> && enum4linux -a -u "guest" -p "" <DC IP>
smbmap -u "" -p "" -P 445 -H <DC IP> && smbmap -u "guest" -p "" -P 445 -H <DC IP>
smbclient -U '%' -L //<DC IP> && smbclient -U 'guest%' -L //
Una guida più dettagliata su come enumerare un server SMB può essere trovata qui:
Enumerare Ldap
nmap -n -sV --script "ldap* and not brute" -p 389 <DC IP>
Una guida più dettagliata su come enumerare LDAP può essere trovata qui (fai particolare attenzione all'accesso anonimo):
Avvelenare la rete
Raccogli credenziali impersonando servizi con Responder
Accedi all'host abusando dell'attacco di relay
Raccogli credenziali esponendo falsi servizi UPnP con evil-SSDP
Estrai nomi utenti/nomi da documenti interni, social media, servizi (principalmente web) all'interno degli ambienti di dominio e anche da fonti pubblicamente disponibili.
Se trovi i nomi completi dei lavoratori dell'azienda, potresti provare diverse convenzioni di nome utente AD (leggi questo). Le convenzioni più comuni sono: NomeCognome, Nome.Cognome, NamSur (3 lettere di ciascuno), Nam.Sur, NSurname, N.Surname, CognomeNome, Cognome.Nome, CognomeN, Cognome.N, 3 lettere casuali e 3 numeri casuali (abc123).
Strumenti:
Enum SMB/LDAP anonimo: Controlla le pagine pentesting SMB e pentesting LDAP.
Enum Kerbrute: Quando viene richiesto un nome utente non valido, il server risponderà utilizzando il codice di errore Kerberos KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN, permettendoci di determinare che il nome utente era non valido. I nomi utente validi genereranno o il TGT in una risposta AS-REP o l'errore KRB5KDC_ERR_PREAUTH_REQUIRED, indicando che l'utente deve eseguire la pre-autenticazione.
Server OWA (Outlook Web Access)
Se hai trovato uno di questi server nella rete, puoi anche eseguire l'enumerazione degli utenti contro di esso. Ad esempio, potresti utilizzare lo strumento MailSniper:
Puoi trovare elenchi di nomi utente in questo repo github **** e in quest'altro (nomi utente statisticamente probabili).
Tuttavia, dovresti avere il nome delle persone che lavorano nell'azienda dal passo di ricognizione che avresti dovuto eseguire prima di questo. Con il nome e il cognome potresti usare lo script namemash.py per generare potenziali nomi utente validi.
Ok, quindi sai di avere già un nome utente valido ma nessuna password... Prova:
ASREPRoast: Se un utente non ha l'attributo DONT_REQ_PREAUTH puoi richiedere un messaggio AS_REP per quell'utente che conterrà alcuni dati crittografati da una derivazione della password dell'utente.
Password Spraying: Proviamo le password più comuni con ciascuno degli utenti scoperti, magari qualche utente sta usando una password debole (tieni presente la politica delle password!).
Nota che puoi anche spray i server OWA per cercare di accedere ai server di posta degli utenti.
Potresti essere in grado di ottenere alcuni hash di sfida per decifrare avvelenando alcuni protocolli della rete:
Se sei riuscito a enumerare l'active directory avrai più email e una migliore comprensione della rete. Potresti essere in grado di forzare attacchi relay NTML **** per ottenere accesso all'ambiente AD.
Se puoi accedere ad altri PC o condivisioni con l'utente null o guest potresti posizionare file (come un file SCF) che, se in qualche modo accessibili, attiveranno un'autenticazione NTML contro di te così potrai rubare la sfida NTLM per decifrarla:
Per questa fase devi aver compromesso le credenziali o una sessione di un account di dominio valido. Se hai alcune credenziali valide o una shell come utente di dominio, dovresti ricordare che le opzioni fornite prima sono ancora opzioni per compromettere altri utenti.
Prima di iniziare l'enumerazione autenticata dovresti sapere qual è il problema del doppio salto Kerberos.
Aver compromesso un account è un grande passo per iniziare a compromettere l'intero dominio, perché sarai in grado di avviare l'Enumerazione di Active Directory:
Per quanto riguarda ASREPRoast ora puoi trovare ogni possibile utente vulnerabile, e per quanto riguarda Password Spraying puoi ottenere un elenco di tutti i nomi utente e provare la password dell'account compromesso, password vuote e nuove password promettenti.
Potresti usare il CMD per eseguire una ricognizione di base
Puoi anche usare powershell per la ricognizione che sarà più furtivo
Puoi anche usare powerview per estrarre informazioni più dettagliate
Un altro strumento fantastico per la ricognizione in un active directory è BloodHound. Non è molto furtivo (a seconda dei metodi di raccolta che usi), ma se non ti importa di questo, dovresti assolutamente provarlo. Scopri dove gli utenti possono RDP, trova percorsi verso altri gruppi, ecc.
Altri strumenti automatizzati per l'enumerazione AD sono: AD Explorer, ADRecon, Group3r, PingCastle.
Record DNS dell'AD poiché potrebbero contenere informazioni interessanti.
Un strumento con GUI che puoi usare per enumerare la directory è AdExplorer.exe dal SysInternal Suite.
Puoi anche cercare nel database LDAP con ldapsearch per cercare credenziali nei campi userPassword & unixUserPassword, o anche per Description. cf. Password in AD User comment on PayloadsAllTheThings per altri metodi.
Se stai usando Linux, potresti anche enumerare il dominio usando pywerview.
Potresti anche provare strumenti automatizzati come:
Estrazione di tutti gli utenti di dominio
È molto facile ottenere tutti i nomi utente del dominio da Windows (net user /domain, Get-DomainUser o wmic useraccount get name,sid). In Linux, puoi usare: GetADUsers.py -all -dc-ip 10.10.10.110 domain.com/username o enum4linux -a -u "user" -p "password" <DC IP>
Anche se questa sezione di enumerazione sembra piccola, è la parte più importante di tutte. Accedi ai link (principalmente quello di cmd, powershell, powerview e BloodHound), impara come enumerare un dominio e pratica finché non ti senti a tuo agio. Durante una valutazione, questo sarà il momento chiave per trovare la tua strada verso DA o per decidere che non si può fare nulla.
Kerberoasting implica ottenere ticket TGS utilizzati dai servizi legati agli account utente e decifrare la loro crittografia—che si basa sulle password degli utenti—offline.
Maggiori informazioni su questo in:
Una volta ottenute alcune credenziali, potresti controllare se hai accesso a qualche macchina. A tal fine, potresti usare CrackMapExec per tentare di connetterti a diversi server con diversi protocolli, in base alle tue scansioni delle porte.
Se hai compromesso credenziali o una sessione come utente di dominio regolare e hai accesso con questo utente a qualsiasi macchina nel dominio, dovresti cercare di trovare il modo di escalare i privilegi localmente e cercare credenziali. Questo perché solo con privilegi di amministratore locale sarai in grado di dumpare gli hash di altri utenti in memoria (LSASS) e localmente (SAM).
C'è una pagina completa in questo libro su escalation dei privilegi locali in Windows e una checklist. Inoltre, non dimenticare di usare WinPEAS.
È molto improbabile che tu trovi ticket nell'utente attuale che ti diano permesso di accedere a risorse inaspettate, ma potresti controllare:
Se sei riuscito a enumerare l'active directory avrai più email e una migliore comprensione della rete. Potresti essere in grado di forzare gli attacchi relay NTML.
Ora che hai alcune credenziali di base dovresti controllare se puoi trovare file interessanti condivisi all'interno dell'AD. Potresti farlo manualmente, ma è un compito molto noioso e ripetitivo (e ancora di più se trovi centinaia di documenti che devi controllare).
Segui questo link per scoprire gli strumenti che potresti utilizzare.
Se puoi accedere ad altri PC o condivisioni potresti posizionare file (come un file SCF) che, se in qualche modo accessibili, attiveranno un'autenticazione NTML contro di te così potrai rubare la sfida NTLM per decifrarla:
Questa vulnerabilità ha permesso a qualsiasi utente autenticato di compromettere il controller di dominio.
Per le seguenti tecniche un normale utente di dominio non è sufficiente, hai bisogno di privilegi/credenziali speciali per eseguire questi attacchi.
Speriamo che tu sia riuscito a compromettere qualche account admin locale utilizzando AsRepRoast, Password Spraying, Kerberoast, Responder inclusi i relay, EvilSSDP, escalating privileges locally. Poi, è tempo di estrarre tutti gli hash in memoria e localmente. Leggi questa pagina sui diversi modi per ottenere gli hash.
Una volta che hai l'hash di un utente, puoi usarlo per impersonarlo. Devi usare qualche strumento che eseguirà l'autenticazione NTLM utilizzando quell'hash, oppure potresti creare una nuova sessionlogon e iniettare quell'hash all'interno del LSASS, così quando viene eseguita qualsiasi autenticazione NTLM, quell'hash verrà utilizzato. L'ultima opzione è ciò che fa mimikatz. Leggi questa pagina per ulteriori informazioni.
Questo attacco mira a utilizzare l'hash NTLM dell'utente per richiedere ticket Kerberos, come alternativa al comune Pass The Hash sul protocollo NTLM. Pertanto, questo potrebbe essere particolarmente utile in reti dove il protocollo NTLM è disabilitato e solo Kerberos è consentito come protocollo di autenticazione.
Nel metodo di attacco Pass The Ticket (PTT), gli attaccanti rubano il ticket di autenticazione di un utente invece dei loro valori di password o hash. Questo ticket rubato viene poi utilizzato per impersonare l'utente, ottenendo accesso non autorizzato a risorse e servizi all'interno di una rete.
Se hai l'hash o la password di un amministratore locale dovresti provare a accedere localmente ad altri PC con esso.
Nota che questo è piuttosto rumoroso e LAPS lo mitigherebbe.
Se un utente ha privilegi per accedere alle istanze MSSQL, potrebbe essere in grado di usarlo per eseguire comandi nell'host MSSQL (se in esecuzione come SA), rubare l'hash NetNTLM o persino eseguire un attacco di relay. Inoltre, se un'istanza MSSQL è fidata (collegamento al database) da un'altra istanza MSSQL. Se l'utente ha privilegi sul database fidato, sarà in grado di utilizzare la relazione di fiducia per eseguire query anche nell'altra istanza. Queste fiducia possono essere concatenate e a un certo punto l'utente potrebbe essere in grado di trovare un database mal configurato dove può eseguire comandi. I collegamenti tra i database funzionano anche attraverso le fiducia tra foreste.
Se trovi un oggetto Computer con l'attributo ADS_UF_TRUSTED_FOR_DELEGATION e hai privilegi di dominio nel computer, sarai in grado di estrarre i TGT dalla memoria di ogni utente che accede al computer. Quindi, se un Domain Admin accede al computer, sarai in grado di estrarre il suo TGT e impersonarlo usando Pass the Ticket. Grazie alla delegazione vincolata potresti anche compromettere automaticamente un Print Server (speriamo che sia un DC).
Se un utente o un computer è autorizzato per la "Delegazione vincolata", sarà in grado di impersonare qualsiasi utente per accedere a determinati servizi in un computer. Quindi, se comprometti l'hash di questo utente/computer sarai in grado di impersonare qualsiasi utente (anche gli amministratori di dominio) per accedere a determinati servizi.
Avere il privilegio di SCRITTURA su un oggetto Active Directory di un computer remoto consente di ottenere l'esecuzione di codice con privilegi elevati:
L'utente compromesso potrebbe avere alcuni privilegi interessanti su alcuni oggetti di dominio che potrebbero consentirti di muoverti lateralmente/escalare privilegi.
Scoprire un servizio Spool in ascolto all'interno del dominio può essere abusato per acquisire nuove credenziali e escalare privilegi.
Se altri utenti accedono alla macchina compromessa, è possibile raccogliere credenziali dalla memoria e persino iniettare beacon nei loro processi per impersonarli. Di solito gli utenti accedono al sistema tramite RDP, quindi ecco come eseguire un paio di attacchi sulle sessioni RDP di terze parti:
LAPS fornisce un sistema per gestire la password dell'amministratore locale sui computer uniti al dominio, assicurando che sia randomizzata, unica e frequentemente cambiata. Queste password sono memorizzate in Active Directory e l'accesso è controllato tramite ACL solo per gli utenti autorizzati. Con permessi sufficienti per accedere a queste password, diventa possibile passare ad altri computer.
Raccogliere certificati dalla macchina compromessa potrebbe essere un modo per escalare privilegi all'interno dell'ambiente:
Se sono configurati modelli vulnerabili, è possibile abusarne per escalare privilegi:
Una volta ottenuti i privilegi di Domain Admin o ancora meglio di Enterprise Admin, puoi dumpare il database di dominio: ntds.dit.
Maggiori informazioni sull'attacco DCSync possono essere trovate qui.
Maggiori informazioni su come rubare il NTDS.dit possono essere trovate qui
Alcune delle tecniche discusse in precedenza possono essere utilizzate per la persistenza. Ad esempio potresti:
Rendere gli utenti vulnerabili a Kerberoast
Rendere gli utenti vulnerabili a ASREPRoast
Concedere privilegi di DCSync a un utente
L'attacco Silver Ticket crea un ticket di servizio Ticket Granting Service (TGS) legittimo per un servizio specifico utilizzando l'hash NTLM (ad esempio, l'hash dell'account PC). Questo metodo viene impiegato per accedere ai privilegi di servizio.
Un attacco Golden Ticket comporta che un attaccante ottenga accesso all'hash NTLM dell'account krbtgt in un ambiente Active Directory (AD). Questo account è speciale perché viene utilizzato per firmare tutti i Ticket Granting Tickets (TGT), essenziali per l'autenticazione all'interno della rete AD.
Una volta che l'attaccante ottiene questo hash, può creare TGT per qualsiasi account scelga (attacco Silver Ticket).
Questi sono simili ai golden ticket forgiati in un modo che bypassa i comuni meccanismi di rilevamento dei golden ticket.
Avere certificati di un account o essere in grado di richiederli è un ottimo modo per poter persistere nell'account degli utenti (anche se cambia la password):
Utilizzare certificati è anche possibile per persistere con privilegi elevati all'interno del dominio:
L'oggetto AdminSDHolder in Active Directory garantisce la sicurezza dei gruppi privilegiati (come Domain Admins e Enterprise Admins) applicando una standard Access Control List (ACL) su questi gruppi per prevenire modifiche non autorizzate. Tuttavia, questa funzionalità può essere sfruttata; se un attaccante modifica l'ACL di AdminSDHolder per dare accesso completo a un utente normale, quell'utente ottiene un controllo esteso su tutti i gruppi privilegiati. Questa misura di sicurezza, destinata a proteggere, può quindi ritorcersi contro, consentendo accessi non autorizzati a meno che non venga monitorata da vicino.
Maggiori informazioni sul gruppo AdminDSHolder qui.
All'interno di ogni Domain Controller (DC), esiste un account di amministratore locale. Ottenendo diritti di amministratore su tale macchina, l'hash dell'amministratore locale può essere estratto utilizzando mimikatz. Successivamente, è necessaria una modifica del registro per abilitare l'uso di questa password, consentendo l'accesso remoto all'account dell'amministratore locale.
Potresti dare alcuni privilegi speciali a un utente su alcuni oggetti di dominio specifici che consentiranno all'utente di escalare privilegi in futuro.
I descrittori di sicurezza vengono utilizzati per memorizzare i privilegi che un oggetto ha su un oggetto. Se riesci a fare un piccolo cambiamento nel descrittore di sicurezza di un oggetto, puoi ottenere privilegi molto interessanti su quell'oggetto senza dover essere membro di un gruppo privilegiato.
Modifica LSASS in memoria per stabilire una password universale, concedendo accesso a tutti gli account di dominio.
Scopri cos'è un SSP (Security Support Provider) qui. Puoi creare il tuo SSP per catturare in testo chiaro le credenziali utilizzate per accedere alla macchina.\
Registra un nuovo Domain Controller nell'AD e lo utilizza per inviare attributi (SIDHistory, SPNs...) su oggetti specificati senza lasciare alcun log riguardo alle modifiche. Hai bisogno di privilegi DA e di essere all'interno del dominio radice. Nota che se usi dati errati, appariranno log piuttosto brutti.
In precedenza abbiamo discusso di come escalare privilegi se hai sufficienti permessi per leggere le password LAPS. Tuttavia, queste password possono anche essere utilizzate per mantenere la persistenza. Controlla:
Microsoft considera la Foresta come il confine di sicurezza. Ciò implica che compromettere un singolo dominio potrebbe potenzialmente portare alla compromissione dell'intera Foresta.
Una fiducia di dominio è un meccanismo di sicurezza che consente a un utente di un dominio di accedere alle risorse in un altro dominio. Crea essenzialmente un collegamento tra i sistemi di autenticazione dei due domini, consentendo che le verifiche di autenticazione fluiscano senza problemi. Quando i domini stabiliscono una fiducia, scambiano e mantengono specifiche chiavi all'interno dei loro Domain Controllers (DC), che sono cruciali per l'integrità della fiducia.
In uno scenario tipico, se un utente intende accedere a un servizio in un dominio fidato, deve prima richiedere un ticket speciale noto come inter-realm TGT dal DC del proprio dominio. Questo TGT è crittografato con una chiave condivisa su cui entrambi i domini hanno concordato. L'utente presenta quindi questo TGT al DC del dominio fidato per ottenere un ticket di servizio (TGS). Dopo la validazione con successo dell'inter-realm TGT da parte del DC del dominio fidato, emette un TGS, concedendo all'utente accesso al servizio.
Passaggi:
Un computer client nel Dominio 1 avvia il processo utilizzando il proprio hash NTLM per richiedere un Ticket Granting Ticket (TGT) dal proprio Domain Controller (DC1).
DC1 emette un nuovo TGT se il client viene autenticato con successo.
Il client richiede quindi un inter-realm TGT da DC1, necessario per accedere alle risorse nel Dominio 2.
L'inter-realm TGT è crittografato con una chiave di fiducia condivisa tra DC1 e DC2 come parte della fiducia tra domini bidirezionale.
Il client porta l'inter-realm TGT al Domain Controller (DC2) del Dominio 2.
DC2 verifica l'inter-realm TGT utilizzando la sua chiave di fiducia condivisa e, se valido, emette un Ticket Granting Service (TGS) per il server nel Dominio 2 a cui il client desidera accedere.
Infine, il client presenta questo TGS al server, che è crittografato con l'hash dell'account del server, per ottenere accesso al servizio nel Dominio 2.
È importante notare che una fiducia può essere unidirezionale o bidirezionale. Nelle opzioni bidirezionali, entrambi i domini si fideranno l'uno dell'altro, ma nella relazione di fiducia unidirezionale uno dei domini sarà il fidato e l'altro il fiducioso. Nel secondo caso, sarai in grado di accedere solo alle risorse all'interno del dominio fiducioso dal fidato.
Se il Dominio A si fida del Dominio B, A è il dominio fiducioso e B è quello fidato. Inoltre, in Dominio A, questo sarebbe una fiducia in uscita; e in Dominio B, questo sarebbe una fiducia in entrata.
Diverse relazioni di fiducia
Fiducia Genitore-Figlio: Questa è una configurazione comune all'interno della stessa foresta, dove un dominio figlio ha automaticamente una fiducia bidirezionale transitiva con il suo dominio genitore. Essenzialmente, ciò significa che le richieste di autenticazione possono fluire senza problemi tra il genitore e il figlio.
Fiducia Cross-link: Riferita come "fiducia abbreviata", queste vengono stabilite tra domini figli per accelerare i processi di riferimento. In foreste complesse, i riferimenti di autenticazione devono generalmente viaggiare fino alla radice della foresta e poi giù fino al dominio di destinazione. Creando collegamenti incrociati, il viaggio viene accorciato, il che è particolarmente vantaggioso in ambienti geograficamente dispersi.
Fiducia Esterna: Queste vengono impostate tra domini diversi e non correlati e sono di natura non transitiva. Secondo la documentazione di Microsoft, le fiducia esterne sono utili per accedere a risorse in un dominio al di fuori dell'attuale foresta che non è connesso tramite una fiducia tra foreste. La sicurezza è rafforzata attraverso il filtraggio SID con fiducia esterne.
Fiducia Tree-root: Queste fiducia vengono stabilite automaticamente tra il dominio radice della foresta e un nuovo albero radice aggiunto. Anche se non comunemente incontrate, le fiducia tree-root sono importanti per aggiungere nuovi alberi di dominio a una foresta, consentendo loro di mantenere un nome di dominio unico e garantendo una transitività bidirezionale. Maggiori informazioni possono essere trovate nella guida di Microsoft.
Fiducia tra Foreste: Questo tipo di fiducia è una fiducia bidirezionale transitiva tra due domini radice di foresta, imponendo anche il filtraggio SID per migliorare le misure di sicurezza.
Fiducia MIT: Queste fiducia vengono stabilite con domini Kerberos non Windows, conformi a RFC4120. Le fiducia MIT sono un po' più specializzate e si rivolgono a ambienti che richiedono integrazione con sistemi basati su Kerberos al di fuori dell'ecosistema Windows.
Una relazione di fiducia può anche essere transitiva (A si fida di B, B si fida di C, quindi A si fida di C) o non transitiva.
Una relazione di fiducia può essere impostata come fiducia bidirezionale (entrambi si fidano l'uno dell'altro) o come fiducia unidirezionale (solo uno di loro si fida dell'altro).
Enumerare le relazioni di fiducia
Controlla se qualche principale di sicurezza (utente/gruppo/computer) ha accesso alle risorse dell'altro dominio, magari tramite voci ACE o essendo in gruppi dell'altro dominio. Cerca relazioni tra domini (la fiducia è stata creata per questo probabilmente).
Kerberoast in questo caso potrebbe essere un'altra opzione.
Compromettere gli account che possono pivotare tra i domini.
Gli attaccanti potrebbero accedere alle risorse in un altro dominio attraverso tre meccanismi principali:
Appartenenza a Gruppi Locali: I principali potrebbero essere aggiunti a gruppi locali su macchine, come il gruppo "Amministratori" su un server, concedendo loro un controllo significativo su quella macchina.
Appartenenza a Gruppi di Domini Esterni: I principali possono anche essere membri di gruppi all'interno del dominio esterno. Tuttavia, l'efficacia di questo metodo dipende dalla natura della fiducia e dall'ambito del gruppo.
Liste di Controllo di Accesso (ACL): I principali potrebbero essere specificati in un ACL, in particolare come entità in ACE all'interno di un DACL, fornendo loro accesso a risorse specifiche. Per coloro che desiderano approfondire la meccanica delle ACL, DACL e ACE, il whitepaper intitolato “An ACE Up The Sleeve” è una risorsa preziosa.
Ci sono 2 chiavi fidate, una per Child --> Parent e un'altra per Parent --> Child. Puoi utilizzare quella usata dal dominio corrente con:
Esegui l'escalation come amministratore dell'Enterprise al dominio padre/figlio abusando della fiducia con l'iniezione di SID-History:
Comprendere come la Configurazione Naming Context (NC) possa essere sfruttata è cruciale. La Configurazione NC funge da repository centrale per i dati di configurazione in ambienti Active Directory (AD). Questi dati vengono replicati a ogni Domain Controller (DC) all'interno della foresta, con DC scrivibili che mantengono una copia scrivibile della Configurazione NC. Per sfruttare questo, è necessario avere privilegi di SYSTEM su un DC, preferibilmente un DC figlio.
Collegare GPO al sito DC radice
Il contenitore Siti della Configurazione NC include informazioni sui siti di tutti i computer uniti al dominio all'interno della foresta AD. Operando con privilegi di SYSTEM su qualsiasi DC, gli attaccanti possono collegare GPO ai siti DC radice. Questa azione compromette potenzialmente il dominio radice manipolando le politiche applicate a questi siti.
Per informazioni approfondite, si può esplorare la ricerca su Bypassing SID Filtering.
Compromettere qualsiasi gMSA nella foresta
Un vettore d'attacco coinvolge il targeting di gMSA privilegiati all'interno del dominio. La chiave KDS Root, essenziale per calcolare le password delle gMSA, è memorizzata all'interno della Configurazione NC. Con privilegi di SYSTEM su qualsiasi DC, è possibile accedere alla chiave KDS Root e calcolare le password per qualsiasi gMSA nella foresta.
Un'analisi dettagliata può essere trovata nella discussione su Golden gMSA Trust Attacks.
Attacco di modifica dello schema
Questo metodo richiede pazienza, aspettando la creazione di nuovi oggetti AD privilegiati. Con privilegi di SYSTEM, un attaccante può modificare lo Schema AD per concedere a qualsiasi utente il controllo completo su tutte le classi. Questo potrebbe portare ad accessi non autorizzati e controllo su nuovi oggetti AD creati.
Ulteriori letture sono disponibili su Schema Change Trust Attacks.
Da DA a EA con ADCS ESC5
La vulnerabilità ADCS ESC5 mira al controllo sugli oggetti di Public Key Infrastructure (PKI) per creare un modello di certificato che consente l'autenticazione come qualsiasi utente all'interno della foresta. Poiché gli oggetti PKI risiedono nella Configurazione NC, compromettere un DC figlio scrivibile consente l'esecuzione di attacchi ESC5.
Maggiori dettagli su questo possono essere letti in From DA to EA with ESC5. In scenari privi di ADCS, l'attaccante ha la capacità di impostare i componenti necessari, come discusso in Escalating from Child Domain Admins to Enterprise Admins.
In questo scenario il tuo dominio è fidato da un dominio esterno che ti concede permessi indeterminati su di esso. Dovrai scoprire quali principi del tuo dominio hanno accesso a quale dominio esterno e poi cercare di sfruttarlo:
In questo scenario il tuo dominio sta fidandosi di alcuni privilegi a un principale di domini diversi.
Tuttavia, quando un dominio è fidato dal dominio fiducioso, il dominio fidato crea un utente con un nome prevedibile che utilizza come password la password fidata. Ciò significa che è possibile accedere a un utente dal dominio fiducioso per entrare in quello fidato per enumerarlo e cercare di aumentare ulteriormente i privilegi:
Un altro modo per compromettere il dominio fidato è trovare un collegamento SQL fidato creato nella direzione opposta della fiducia del dominio (cosa non molto comune).
Un altro modo per compromettere il dominio fidato è aspettare su una macchina a cui un utente del dominio fidato può accedere per effettuare il login tramite RDP. Poi, l'attaccante potrebbe iniettare codice nel processo della sessione RDP e accedere al dominio di origine della vittima da lì. Inoltre, se la vittima ha montato il suo disco rigido, dal processo della sessione RDP l'attaccante potrebbe memorizzare backdoor nella cartella di avvio del disco rigido. Questa tecnica è chiamata RDPInception.
Il rischio di attacchi che sfruttano l'attributo della cronologia SID attraverso le fiducie tra foreste è mitigato dal Filtraggio SID, che è attivato per impostazione predefinita su tutte le fiducie inter-foresta. Questo è supportato dall'assunzione che le fiducie intra-foresta siano sicure, considerando la foresta, piuttosto che il dominio, come il confine di sicurezza secondo la posizione di Microsoft.
Tuttavia, c'è un problema: il filtraggio SID potrebbe interrompere le applicazioni e l'accesso degli utenti, portando alla sua disattivazione occasionale.
Per le fiducie inter-foresta, l'uso dell'Autenticazione Selettiva garantisce che gli utenti delle due foreste non siano autenticati automaticamente. Invece, sono necessarie autorizzazioni esplicite affinché gli utenti possano accedere ai domini e ai server all'interno del dominio o della foresta fiduciosa.
È importante notare che queste misure non proteggono contro lo sfruttamento del Contesto di Nominazione di Configurazione (NC) scrivibile o attacchi all'account di fiducia.
Ulteriori informazioni sulle fiducie di dominio in ired.team.
Scopri di più su come proteggere le credenziali qui.\
Restrizioni per gli Amministratori di Dominio: Si raccomanda che gli Amministratori di Dominio possano accedere solo ai Controller di Dominio, evitando il loro utilizzo su altri host.
Privilegi degli Account di Servizio: I servizi non dovrebbero essere eseguiti con privilegi di Amministratore di Dominio (DA) per mantenere la sicurezza.
Limitazione Temporale dei Privilegi: Per i compiti che richiedono privilegi DA, la loro durata dovrebbe essere limitata. Questo può essere ottenuto con: Add-ADGroupMember -Identity ‘Domain Admins’ -Members newDA -MemberTimeToLive (New-TimeSpan -Minutes 20)
Implementare l'inganno implica impostare trappole, come utenti o computer esca, con caratteristiche come password che non scadono o sono contrassegnate come Fidate per Delegazione. Un approccio dettagliato include la creazione di utenti con diritti specifici o l'aggiunta a gruppi ad alto privilegio.
Un esempio pratico implica l'uso di strumenti come: Create-DecoyUser -UserFirstName user -UserLastName manager-uncommon -Password Pass@123 | DeployUserDeception -UserFlag PasswordNeverExpires -GUID d07da11f-8a3d-42b6-b0aa-76c962be719a -Verbose
Maggiori informazioni sull'implementazione di tecniche di inganno possono essere trovate in Deploy-Deception su GitHub.
Per Oggetti Utente: Indicatori sospetti includono ObjectSID atipico, accessi infrequenti, date di creazione e conteggi di password errate bassi.
Indicatori Generali: Confrontare gli attributi di potenziali oggetti esca con quelli genuini può rivelare incongruenze. Strumenti come HoneypotBuster possono aiutare a identificare tali inganni.
Bypass della Rilevazione Microsoft ATA:
Enumerazione Utente: Evitare l'enumerazione delle sessioni sui Controller di Dominio per prevenire la rilevazione da parte di ATA.
Impersonificazione del Ticket: Utilizzare chiavi aes per la creazione di ticket aiuta a evitare la rilevazione non degradando a NTLM.
Attacchi DCSync: È consigliato eseguire da un non-Controller di Dominio per evitare la rilevazione da parte di ATA, poiché l'esecuzione diretta da un Controller di Dominio attiverà avvisi.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
