AD CS Domain Escalation
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)
Questo è un riepilogo delle sezioni delle tecniche di escalation dei post:
I diritti di registrazione sono concessi a utenti a basso privilegio dall'Enterprise CA.
L'approvazione del manager non è necessaria.
Non sono necessarie firme da parte del personale autorizzato.
I descrittori di sicurezza sui modelli di certificato sono eccessivamente permissivi, consentendo agli utenti a basso privilegio di ottenere diritti di registrazione.
I modelli di certificato sono configurati per definire EKU che facilitano l'autenticazione:
Identificatori di Extended Key Usage (EKU) come Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), o nessun EKU (SubCA) sono inclusi.
La possibilità per i richiedenti di includere un subjectAltName nella Certificate Signing Request (CSR) è consentita dal modello:
L'Active Directory (AD) dà priorità al subjectAltName (SAN) in un certificato per la verifica dell'identità se presente. Ciò significa che specificando il SAN in una CSR, è possibile richiedere un certificato per impersonare qualsiasi utente (ad es., un amministratore di dominio). Se un SAN può essere specificato dal richiedente è indicato nell'oggetto AD del modello di certificato attraverso la proprietà mspki-certificate-name-flag. Questa proprietà è un bitmask, e la presenza del flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT consente la specifica del SAN da parte del richiedente.
La configurazione delineata consente agli utenti a basso privilegio di richiedere certificati con qualsiasi SAN a scelta, abilitando l'autenticazione come qualsiasi principale di dominio tramite Kerberos o SChannel.
Questa funzionalità è talvolta abilitata per supportare la generazione al volo di certificati HTTPS o di host da parte di prodotti o servizi di distribuzione, o a causa di una mancanza di comprensione.
Si nota che la creazione di un certificato con questa opzione attiva un avviso, il che non accade quando un modello di certificato esistente (come il modello WebServer, che ha CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT abilitato) viene duplicato e poi modificato per includere un OID di autenticazione.
Per trovare modelli di certificato vulnerabili puoi eseguire:
Per sfruttare questa vulnerabilità per impersonare un amministratore si potrebbe eseguire:
Poi puoi trasformare il certificato generato in formato .pfx e usarlo per autenticarti utilizzando Rubeus o certipy di nuovo:
I file binari di Windows "Certreq.exe" e "Certutil.exe" possono essere utilizzati per generare il PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
L'enumerazione dei modelli di certificato all'interno dello schema di configurazione della foresta AD, specificamente quelli che non richiedono approvazione o firme, che possiedono un EKU di Autenticazione Client o Accesso con Smart Card, e con il flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT abilitato, può essere eseguita eseguendo la seguente query LDAP:
Il secondo scenario di abuso è una variazione del primo:
I diritti di registrazione sono concessi a utenti a bassa privilegi da parte dell'Enterprise CA.
Il requisito per l'approvazione del manager è disabilitato.
La necessità di firme autorizzate è omessa.
Un descrittore di sicurezza eccessivamente permissivo sul modello di certificato concede diritti di registrazione del certificato a utenti a bassa privilegi.
Il modello di certificato è definito per includere l'Any Purpose EKU o nessun EKU.
L'Any Purpose EKU consente a un certificato di essere ottenuto da un attaccante per qualsiasi scopo, inclusa l'autenticazione del client, l'autenticazione del server, la firma del codice, ecc. La stessa tecnica utilizzata per ESC3 può essere impiegata per sfruttare questo scenario.
I certificati con nessun EKU, che fungono da certificati CA subordinati, possono essere sfruttati per qualsiasi scopo e possono anche essere utilizzati per firmare nuovi certificati. Pertanto, un attaccante potrebbe specificare EKU o campi arbitrari nei nuovi certificati utilizzando un certificato CA subordinato.
Tuttavia, i nuovi certificati creati per l'autenticazione del dominio non funzioneranno se la CA subordinata non è fidata dall'oggetto NTAuthCertificates, che è l'impostazione predefinita. Tuttavia, un attaccante può comunque creare nuovi certificati con qualsiasi EKU e valori di certificato arbitrari. Questi potrebbero essere potenzialmente abusati per una vasta gamma di scopi (ad es., firma del codice, autenticazione del server, ecc.) e potrebbero avere implicazioni significative per altre applicazioni nella rete come SAML, AD FS o IPSec.
Per enumerare i modelli che corrispondono a questo scenario all'interno dello schema di configurazione dell'AD Forest, può essere eseguita la seguente query LDAP:
Questo scenario è simile al primo e al secondo, ma abusando di un EKU (Agente di Richiesta di Certificato) diverso e 2 modelli diversi (pertanto ha 2 set di requisiti),
L'EKU di Agente di Richiesta di Certificato (OID 1.3.6.1.4.1.311.20.2.1), noto come Agente di Iscrizione nella documentazione Microsoft, consente a un principale di iscriversi per un certificato per conto di un altro utente.
L'“agente di iscrizione” si iscrive in un modello e utilizza il certificato risultante per co-firmare un CSR per conto dell'altro utente. Poi invia il CSR co-firmato all'CA, iscrivendosi in un modello che permette “iscriversi per conto di”, e l'CA risponde con un certificato appartenente all'“altro” utente.
Requisiti 1:
I diritti di iscrizione sono concessi a utenti a bassa privilegiatura dall'Enterprise CA.
Il requisito per l'approvazione del manager è omesso.
Nessun requisito per firme autorizzate.
Il descrittore di sicurezza del modello di certificato è eccessivamente permissivo, concedendo diritti di iscrizione a utenti a bassa privilegiatura.
Il modello di certificato include l'EKU di Agente di Richiesta di Certificato, consentendo la richiesta di altri modelli di certificato per conto di altri principali.
Requisiti 2:
L'Enterprise CA concede diritti di iscrizione a utenti a bassa privilegiatura.
L'approvazione del manager è bypassata.
La versione dello schema del modello è 1 o supera 2, e specifica un Requisito di Emissione di Politica Applicativa che richiede l'EKU di Agente di Richiesta di Certificato.
Un EKU definito nel modello di certificato consente l'autenticazione del dominio.
Le restrizioni per gli agenti di iscrizione non sono applicate sull'CA.
Puoi utilizzare Certify o Certipy per abusare di questo scenario:
Gli utenti che sono autorizzati a ottenere un certificato di agente di registrazione, i modelli nei quali gli agenti di registrazione sono autorizzati a registrarsi e gli account per conto dei quali l'agente di registrazione può agire possono essere limitati dalle CA aziendali. Questo si ottiene aprendo il certsrc.msc snap-in, facendo clic con il tasto destro sulla CA, cliccando su Proprietà, e poi navigando alla scheda “Agenti di registrazione”.
Tuttavia, si nota che l'impostazione predefinita per le CA è di “Non limitare gli agenti di registrazione.” Quando la restrizione sugli agenti di registrazione è abilitata dagli amministratori, impostandola su “Limitare gli agenti di registrazione,” la configurazione predefinita rimane estremamente permissiva. Consente a Tutti di accedere per registrarsi in tutti i modelli come chiunque.
Il descrittore di sicurezza sui modelli di certificato definisce le autorizzazioni specifiche che i principali AD possiedono riguardo al modello.
Se un attaccante possiede le necessarie autorizzazioni per modificare un modello e istituire eventuali misconfigurazioni sfruttabili delineate nelle sezioni precedenti, l'escalation dei privilegi potrebbe essere facilitata.
Le autorizzazioni note applicabili ai modelli di certificato includono:
Proprietario: Concede il controllo implicito sull'oggetto, consentendo la modifica di qualsiasi attributo.
FullControl: Abilita l'autorità completa sull'oggetto, inclusa la capacità di modificare qualsiasi attributo.
WriteOwner: Permette la modifica del proprietario dell'oggetto a un principale sotto il controllo dell'attaccante.
WriteDacl: Consente la regolazione dei controlli di accesso, potenzialmente concedendo a un attaccante FullControl.
WriteProperty: Autorizza la modifica di qualsiasi proprietà dell'oggetto.
Un esempio di privesc come il precedente:
ESC4 è quando un utente ha privilegi di scrittura su un modello di certificato. Questo può essere abusato, ad esempio, per sovrascrivere la configurazione del modello di certificato per rendere il modello vulnerabile a ESC1.
Come possiamo vedere nel percorso sopra, solo JOHNPC ha questi privilegi, ma il nostro utente JOHN ha il nuovo edge AddKeyCredentialLink verso JOHNPC. Poiché questa tecnica è correlata ai certificati, ho implementato anche questo attacco, noto come Shadow Credentials. Ecco un piccolo assaggio del comando shadow auto di Certipy per recuperare l'hash NT della vittima.
Certipy può sovrascrivere la configurazione di un modello di certificato con un singolo comando. Per default, Certipy sovrascriverà la configurazione per renderla vulnerabile a ESC1. Possiamo anche specificare il -save-old parametro per salvare la vecchia configurazione, che sarà utile per ripristinare la configurazione dopo il nostro attacco.
La vasta rete di relazioni interconnesse basate su ACL, che include diversi oggetti oltre ai modelli di certificato e all'autorità di certificazione, può influenzare la sicurezza dell'intero sistema AD CS. Questi oggetti, che possono influenzare significativamente la sicurezza, comprendono:
L'oggetto computer AD del server CA, che può essere compromesso attraverso meccanismi come S4U2Self o S4U2Proxy.
Il server RPC/DCOM del server CA.
Qualsiasi oggetto o contenitore AD discendente all'interno del percorso del contenitore specifico CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Questo percorso include, ma non è limitato a, contenitori e oggetti come il contenitore dei modelli di certificato, il contenitore delle autorità di certificazione, l'oggetto NTAuthCertificates e il contenitore dei servizi di registrazione.
La sicurezza del sistema PKI può essere compromessa se un attaccante a bassa privilegiatura riesce a ottenere il controllo su uno di questi componenti critici.
L'argomento discusso nel post di CQure Academy tocca anche le implicazioni del flag EDITF_ATTRIBUTESUBJECTALTNAME2, come delineato da Microsoft. Questa configurazione, quando attivata su un'Autorità di Certificazione (CA), consente l'inclusione di valori definiti dall'utente nel nome alternativo del soggetto per qualsiasi richiesta, comprese quelle costruite da Active Directory®. Di conseguenza, questa disposizione consente a un intruso di registrarsi attraverso qualsiasi modello impostato per l'autenticazione del dominio—specificamente quelli aperti alla registrazione di utenti non privilegiati, come il modello standard Utente. Di conseguenza, un certificato può essere ottenuto, consentendo all'intruso di autenticarsi come amministratore di dominio o qualsiasi altra entità attiva all'interno del dominio.
Nota: L'approccio per aggiungere nomi alternativi in una Richiesta di Firma del Certificato (CSR), attraverso l'argomento -attrib "SAN:" in certreq.exe (definito come “Name Value Pairs”), presenta un contrasto rispetto alla strategia di sfruttamento degli SAN in ESC1. Qui, la distinzione risiede in come le informazioni sull'account sono incapsulate—all'interno di un attributo del certificato, piuttosto che in un'estensione.
Per verificare se l'impostazione è attivata, le organizzazioni possono utilizzare il seguente comando con certutil.exe:
Questa operazione impiega essenzialmente l'accesso remoto al registro, quindi, un approccio alternativo potrebbe essere:
Strumenti come Certify e Certipy sono in grado di rilevare questa misconfigurazione e sfruttarla:
Per modificare queste impostazioni, assumendo di possedere diritti amministrativi di dominio o equivalenti, il seguente comando può essere eseguito da qualsiasi workstation:
Per disabilitare questa configurazione nel tuo ambiente, il flag può essere rimosso con:
Dopo gli aggiornamenti di sicurezza di maggio 2022, i certificati emessi di recente conterranno un estensione di sicurezza che incorpora la proprietà objectSid del richiedente. Per ESC1, questo SID è derivato dal SAN specificato. Tuttavia, per ESC6, il SID rispecchia il objectSid del richiedente, non il SAN.
Per sfruttare ESC6, è essenziale che il sistema sia suscettibile a ESC10 (Mappature di Certificati Deboli), che dà priorità al SAN rispetto alla nuova estensione di sicurezza.
Il controllo accessi per un'autorità di certificazione è mantenuto attraverso un insieme di permessi che governano le azioni della CA. Questi permessi possono essere visualizzati accedendo a certsrv.msc, facendo clic con il tasto destro su una CA, selezionando proprietà e poi navigando nella scheda Sicurezza. Inoltre, i permessi possono essere enumerati utilizzando il modulo PSPKI con comandi come:
Questo fornisce informazioni sui diritti principali, ovvero ManageCA e ManageCertificates, correlati ai ruoli di “amministratore CA” e “gestore certificati” rispettivamente.
Avere diritti ManageCA su un'autorità di certificazione consente al principale di manipolare le impostazioni da remoto utilizzando PSPKI. Questo include l'attivazione del flag EDITF_ATTRIBUTESUBJECTALTNAME2 per consentire la specifica SAN in qualsiasi modello, un aspetto critico dell'escalation del dominio.
La semplificazione di questo processo è realizzabile attraverso l'uso del cmdlet Enable-PolicyModuleFlag di PSPKI, che consente modifiche senza interazione diretta con l'interfaccia grafica.
Il possesso di diritti ManageCertificates facilita l'approvazione delle richieste in sospeso, eludendo efficacemente la protezione "approvazione del gestore certificati CA".
Una combinazione dei moduli Certify e PSPKI può essere utilizzata per richiedere, approvare e scaricare un certificato:
Nel precedente attacco Manage CA sono stati utilizzati i permessi per abilitare il flag EDITF_ATTRIBUTESUBJECTALTNAME2 per eseguire l'attacco ESC6, ma questo non avrà alcun effetto fino a quando il servizio CA (CertSvc) non verrà riavviato. Quando un utente ha il diritto di accesso Manage CA, l'utente è anche autorizzato a riavviare il servizio. Tuttavia, non significa che l'utente possa riavviare il servizio da remoto. Inoltre, l'ESC6 potrebbe non funzionare immediatamente nella maggior parte degli ambienti patchati a causa degli aggiornamenti di sicurezza di maggio 2022.
Pertanto, qui viene presentato un altro attacco.
Prerequisiti:
Solo permesso ManageCA
Permesso Manage Certificates (può essere concesso da ManageCA)
Il modello di certificato SubCA deve essere abilitato (può essere abilitato da ManageCA)
La tecnica si basa sul fatto che gli utenti con il diritto di accesso Manage CA e Manage Certificates possono emissione di richieste di certificato non riuscite. Il modello di certificato SubCA è vulnerabile a ESC1, ma solo gli amministratori possono iscriversi al modello. Pertanto, un utente può richiedere di iscriversi al SubCA - che sarà negata - ma poi emessa dal manager successivamente.
Puoi concederti il diritto di accesso Manage Certificates aggiungendo il tuo utente come nuovo ufficiale.
Il SubCA template può essere abilitato sulla CA con il parametro -enable-template. Per impostazione predefinita, il template SubCA è abilitato.
Se abbiamo soddisfatto i prerequisiti per questo attacco, possiamo iniziare richiedendo un certificato basato sul modello SubCA.
Questa richiesta verrà negata, ma salveremo la chiave privata e annoteremo l'ID della richiesta.
Con i nostri Manage CA e Manage Certificates, possiamo quindi emettere la richiesta di certificato fallita con il comando ca e il parametro -issue-request <request ID>.
E infine, possiamo recuperare il certificato emesso con il comando req e il parametro -retrieve <request ID>.
In ambienti in cui AD CS è installato, se esiste un endpoint di registrazione web vulnerabile e almeno un modello di certificato è pubblicato che consente l'iscrizione di computer di dominio e l'autenticazione dei client (come il modello Machine predefinito), diventa possibile per qualsiasi computer con il servizio spooler attivo essere compromesso da un attaccante!
Diversi metodi di registrazione basati su HTTP sono supportati da AD CS, resi disponibili attraverso ruoli server aggiuntivi che gli amministratori possono installare. Queste interfacce per la registrazione di certificati basata su HTTP sono suscettibili a attacchi di relay NTLM. Un attaccante, da una macchina compromessa, può impersonare qualsiasi account AD che si autentica tramite NTLM in entrata. Mentre impersona l'account vittima, queste interfacce web possono essere accessibili da un attaccante per richiedere un certificato di autenticazione client utilizzando i modelli di certificato User o Machine.
L'interfaccia di registrazione web (un'applicazione ASP più vecchia disponibile su http://<caserver>/certsrv/), per impostazione predefinita utilizza solo HTTP, che non offre protezione contro gli attacchi di relay NTLM. Inoltre, consente esplicitamente solo l'autenticazione NTLM attraverso il suo header HTTP di autorizzazione, rendendo inapplicabili metodi di autenticazione più sicuri come Kerberos.
Il Servizio di Registrazione Certificati (CES), il Servizio Web della Politica di Registrazione Certificati (CEP) e il Servizio di Registrazione Dispositivi di Rete (NDES) supportano per impostazione predefinita l'autenticazione negotiate tramite il loro header HTTP di autorizzazione. L'autenticazione negotiate supporta sia Kerberos che NTLM, consentendo a un attaccante di downgradare all'autenticazione NTLM durante gli attacchi di relay. Sebbene questi servizi web abilitino HTTPS per impostazione predefinita, HTTPS da solo non protegge contro gli attacchi di relay NTLM. La protezione dagli attacchi di relay NTLM per i servizi HTTPS è possibile solo quando HTTPS è combinato con il binding del canale. Sfortunatamente, AD CS non attiva la Protezione Estesa per l'Autenticazione su IIS, che è necessaria per il binding del canale.
Un comune problema con gli attacchi di relay NTLM è la breve durata delle sessioni NTLM e l'incapacità dell'attaccante di interagire con i servizi che richiedono la firma NTLM.
Tuttavia, questa limitazione è superata sfruttando un attacco di relay NTLM per acquisire un certificato per l'utente, poiché il periodo di validità del certificato determina la durata della sessione, e il certificato può essere utilizzato con servizi che richiedono la firma NTLM. Per istruzioni su come utilizzare un certificato rubato, fare riferimento a:
AD CS Account PersistenceUn'altra limitazione degli attacchi di relay NTLM è che una macchina controllata dall'attaccante deve essere autenticata da un account vittima. L'attaccante potrebbe aspettare o tentare di forzare questa autenticazione:
Force NTLM Privileged AuthenticationCertify’s cas enumera endpoint HTTP AD CS abilitati:
La proprietà msPKI-Enrollment-Servers è utilizzata dalle Autorità di Certificazione (CA) aziendali per memorizzare i punti di accesso del Servizio di Registrazione dei Certificati (CES). Questi punti di accesso possono essere analizzati e elencati utilizzando lo strumento Certutil.exe:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
La richiesta di un certificato viene effettuata da Certipy per impostazione predefinita in base al modello Machine o User, determinato dal fatto che il nome dell'account da relazionare termini con $. La specifica di un modello alternativo può essere ottenuta attraverso l'uso del parametro -template.
Una tecnica come PetitPotam può quindi essere impiegata per costringere l'autenticazione. Quando si tratta di controller di dominio, è necessaria la specifica di -template DomainController.
Il nuovo valore CT_FLAG_NO_SECURITY_EXTENSION (0x80000) per msPKI-Enrollment-Flag, noto come ESC9, impedisce l'inserimento della nuova estensione di sicurezza szOID_NTDS_CA_SECURITY_EXT in un certificato. Questo flag diventa rilevante quando StrongCertificateBindingEnforcement è impostato su 1 (l'impostazione predefinita), in contrasto con un'impostazione di 2. La sua rilevanza aumenta in scenari in cui una mappatura del certificato più debole per Kerberos o Schannel potrebbe essere sfruttata (come in ESC10), dato che l'assenza di ESC9 non altererebbe i requisiti.
Le condizioni in cui l'impostazione di questo flag diventa significativa includono:
StrongCertificateBindingEnforcement non è regolato su 2 (con il predefinito che è 1), o CertificateMappingMethods include il flag UPN.
Il certificato è contrassegnato con il flag CT_FLAG_NO_SECURITY_EXTENSION all'interno dell'impostazione msPKI-Enrollment-Flag.
Qualsiasi EKU di autenticazione del client è specificata dal certificato.
I permessi GenericWrite sono disponibili su qualsiasi account per compromettere un altro.
Supponiamo che John@corp.local detenga permessi GenericWrite su Jane@corp.local, con l'obiettivo di compromettere Administrator@corp.local. Il modello di certificato ESC9, a cui Jane@corp.local è autorizzata a iscriversi, è configurato con il flag CT_FLAG_NO_SECURITY_EXTENSION nella sua impostazione msPKI-Enrollment-Flag.
Inizialmente, l'hash di Jane viene acquisito utilizzando Shadow Credentials, grazie a John's GenericWrite:
Successivamente, il userPrincipalName di Jane viene modificato in Administrator, omettendo volutamente la parte del dominio @corp.local:
Questa modifica non viola i vincoli, dato che Administrator@corp.local rimane distinto come userPrincipalName di Administrator.
Dopo di ciò, il modello di certificato ESC9, contrassegnato come vulnerabile, viene richiesto come Jane:
È stato notato che il userPrincipalName del certificato riflette Administrator, privo di qualsiasi “object SID”.
Il userPrincipalName di Jane viene quindi ripristinato al suo originale, Jane@corp.local:
Tentare l'autenticazione con il certificato emesso ora restituisce l'hash NT di Administrator@corp.local. Il comando deve includere -domain <domain> a causa della mancanza di specifica del dominio nel certificato:
Due valori di chiave di registro sul controller di dominio sono indicati da ESC10:
Il valore predefinito per CertificateMappingMethods sotto HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel è 0x18 (0x8 | 0x10), precedentemente impostato su 0x1F.
L'impostazione predefinita per StrongCertificateBindingEnforcement sotto HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc è 1, precedentemente 0.
Caso 1
Quando StrongCertificateBindingEnforcement è configurato come 0.
Caso 2
Se CertificateMappingMethods include il bit UPN (0x4).
Con StrongCertificateBindingEnforcement configurato come 0, un account A con permessi GenericWrite può essere sfruttato per compromettere qualsiasi account B.
Ad esempio, avendo permessi GenericWrite su Jane@corp.local, un attaccante mira a compromettere Administrator@corp.local. La procedura rispecchia ESC9, consentendo di utilizzare qualsiasi modello di certificato.
Inizialmente, l'hash di Jane viene recuperato utilizzando Shadow Credentials, sfruttando il GenericWrite.
Successivamente, il userPrincipalName di Jane viene modificato in Administrator, omettendo deliberatamente la parte @corp.local per evitare una violazione dei vincoli.
Successivamente, viene richiesta un certificato che abilita l'autenticazione del client come Jane, utilizzando il modello predefinito User.
Jane's userPrincipalName viene quindi ripristinato al suo originale, Jane@corp.local.
Autenticarsi con il certificato ottenuto restituirà l'hash NT di Administrator@corp.local, rendendo necessaria la specifica del dominio nel comando a causa dell'assenza di dettagli sul dominio nel certificato.
Con il CertificateMappingMethods che contiene il flag bit UPN (0x4), un account A con permessi GenericWrite può compromettere qualsiasi account B privo della proprietà userPrincipalName, inclusi gli account macchina e l'amministratore di dominio integrato Administrator.
Qui, l'obiettivo è compromettere DC$@corp.local, iniziando con l'ottenere l'hash di Jane attraverso le Credenziali Shadow, sfruttando il GenericWrite.
Jane's userPrincipalName è quindi impostato su DC$@corp.local.
Un certificato per l'autenticazione del client viene richiesto come Jane utilizzando il modello predefinito User.
Jane's userPrincipalName viene ripristinato al suo originale dopo questo processo.
Per autenticarsi tramite Schannel, viene utilizzata l'opzione -ldap-shell di Certipy, che indica il successo dell'autenticazione come u:CORP\DC$.
Attraverso la shell LDAP, comandi come set_rbcd abilitano attacchi di Delegazione Constrainata Basata sulle Risorse (RBCD), compromettendo potenzialmente il controller di dominio.
Questa vulnerabilità si estende anche a qualsiasi account utente privo di un userPrincipalName o in cui non corrisponde al sAMAccountName, con il predefinito Administrator@corp.local che è un obiettivo primario a causa dei suoi privilegi LDAP elevati e dell'assenza di un userPrincipalName per impostazione predefinita.
Se il server CA non è configurato con IF_ENFORCEENCRYPTICERTREQUEST, può essere soggetto ad attacchi di relay NTLM senza firma tramite il servizio RPC. Riferimento qui.
Puoi usare certipy per enumerare se Enforce Encryption for Requests è disabilitato e certipy mostrerà le vulnerabilità ESC11.
È necessario configurare un server di relay:
Nota: Per i controller di dominio, dobbiamo specificare -template in DomainController.
Oppure usando il fork di impacket di sploutchy :
Gli amministratori possono configurare l'Autorità di Certificazione per memorizzarla su un dispositivo esterno come il "Yubico YubiHSM2".
Se un dispositivo USB è connesso al server CA tramite una porta USB, o un server di dispositivi USB nel caso in cui il server CA sia una macchina virtuale, è necessaria una chiave di autenticazione (a volte chiamata "password") affinché il Provider di Archiviazione delle Chiavi generi e utilizzi chiavi nel YubiHSM.
Questa chiave/password è memorizzata nel registro sotto HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword in chiaro.
Riferimento qui.
Se la chiave privata della CA è memorizzata su un dispositivo USB fisico quando hai ottenuto accesso shell, è possibile recuperare la chiave.
Per prima cosa, devi ottenere il certificato CA (questo è pubblico) e poi:
Infine, utilizza il comando certutil -sign per forgiare un nuovo certificato arbitrario utilizzando il certificato CA e la sua chiave privata.
L'attributo msPKI-Certificate-Policy consente di aggiungere la politica di emissione al modello di certificato. Gli oggetti msPKI-Enterprise-Oid responsabili dell'emissione delle politiche possono essere scoperti nel Contesto di Nominazione della Configurazione (CN=OID,CN=Public Key Services,CN=Services) del contenitore OID PKI. Una politica può essere collegata a un gruppo AD utilizzando l'attributo msDS-OIDToGroupLink di questo oggetto, consentendo a un sistema di autorizzare un utente che presenta il certificato come se fosse un membro del gruppo. Riferimento qui.
In altre parole, quando un utente ha il permesso di registrare un certificato e il certificato è collegato a un gruppo OID, l'utente può ereditare i privilegi di questo gruppo.
Utilizza Check-ADCSESC13.ps1 per trovare OIDToGroupLink:
Trova un permesso utente che può utilizzare certipy find o Certify.exe find /showAllPermissions.
Se John ha il permesso di registrare VulnerableTemplate, l'utente può ereditare i privilegi del gruppo VulnerableGroup.
Tutto ciò che deve fare è specificare il template, otterrà un certificato con diritti OIDToGroupLink.
La configurazione per il cross-forest enrollment è relativamente semplice. Il certificato CA radice della foresta di risorse è pubblicato alle foreste account dagli amministratori, e i certificati CA aziendali della foresta di risorse sono aggiunti ai contenitori NTAuthCertificates e AIA in ciascuna foresta account. Per chiarire, questo accordo concede alla CA nella foresta di risorse il controllo completo su tutte le altre foreste per le quali gestisce la PKI. Se questa CA fosse compromessa da attaccanti, i certificati per tutti gli utenti sia nella foresta di risorse che in quella account potrebbero essere falsificati da loro, rompendo così il confine di sicurezza della foresta.
Negli ambienti multi-foresta, è necessaria cautela riguardo alle CA aziendali che pubblicano modelli di certificato che consentono a Utenti Autenticati o principali stranieri (utenti/gruppi esterni alla foresta a cui appartiene la CA aziendale) diritti di iscrizione e modifica. Dopo l'autenticazione attraverso un trust, il SID Utenti Autenticati viene aggiunto al token dell'utente da AD. Pertanto, se un dominio possiede una CA aziendale con un modello che consente diritti di iscrizione agli Utenti Autenticati, un modello potrebbe potenzialmente essere iscritto da un utente di una foresta diversa. Allo stesso modo, se i diritti di iscrizione sono esplicitamente concessi a un principale straniero da un modello, si crea così una relazione di controllo accessi cross-forest, consentendo a un principale di una foresta di iscriversi a un modello di un'altra foresta.
Entrambi gli scenari portano a un aumento della superficie di attacco da una foresta all'altra. Le impostazioni del modello di certificato potrebbero essere sfruttate da un attaccante per ottenere privilegi aggiuntivi in un dominio straniero.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
