Furto e Falsificazione di Certificati: Steal or Forge Authentication Certificates (T1649)

I certificati digitali rappresentano uno dei pilastri dell'autenticazione in ambienti enterprise. Quando un avversario riesce a rubarli o a forgiarli, ottiene credenziali valide che sopravvivono ai reset delle password, aggirano l'MFA e operano con la piena fiducia dell'infrastruttura PKI. La tecnica T1649 si colloca nella tattica Credential Access (TA0006), la fase della kill chain in cui l'attaccante cerca di impossessarsi di nomi utente e credenziali per muoversi nell'ambiente vittima senza destare sospetti.

Il perimetro d'attacco è ampio: Active Directory Certificate Services (AD CS) in ambienti on-premise, certificati device in Entra ID (ex Azure AD) per contesti cloud, e chiavi private conservate nel registro Windows, nel file system o nel certificate store del sistema operativo. I vettori d'abuso spaziano dal furto di certificati già emessi — estratti dallo storage cifrato o da file mal protetti — alla richiesta fraudolenta di nuovi certificati sfruttando template mal configurati. Il caso più devastante è la cosiddetta golden certificate: l'avversario che compromette la chiave privata della CA radice o subordinata può emettere certificati arbitrari per qualsiasi identità del dominio, garantendosi persistenza praticamente illimitata.

I dati parlano di 1 gruppo APT documentato, 2 tool offensivi noti e 4 mitigazioni raccomandate — numeri contenuti che non devono ingannare: la superficie d'attacco cresce con ogni template pubblicato senza revisione.

La prima fase di ogni engagement su AD CS è l'enumerazione. Certipy (open source), il tool Python di riferimento per l'attacco ai servizi di certificazione Active Directory, permette di mappare l'intera infrastruttura PKI con un solo comando:

certipy find -u utente@dominio.local -p password -dc-ip 10.0.0.1

Questo produce un output in JSON e un file di testo con tutti i template vulnerabili, le CA disponibili, le permission di enrollment e i flag EKU. Certipy classifica automaticamente le misconfigurazioni note — come ESC1, ESC4, ESC8 — indicando chiaramente quali template consentono a un utente non privilegiato di specificare un Subject Alternative Name (SAN) arbitrario.

Per il corrispettivo Windows, Certify (open source, del progetto GhostPack) offre funzionalità analoghe in C#:

Certify.exe find /vulnerable

Enumera i template con enrollment aperto e SAN abilitato. Una volta identificato un template vulnerabile di tipo ESC1, si richiede un certificato impersonando un Domain Admin:

Certify.exe request /ca:DC01.dominio.local\dominio-CA /template:VulnerableTemplate /altname:administrator

Il certificato ottenuto in formato PEM va convertito in PFX per l'uso con Rubeus o con lo stesso Certipy. Per la conversione si usa OpenSSL:

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

Con il PFX in mano, l'autenticazione via PKINIT consente di ottenere un TGT Kerberos senza conoscere la password:

certipy auth -pfx admin.pfx -dc-ip 10.0.0.1

Per simulare lo scenario golden certificate, se si ha accesso alla chiave privata della CA (tipicamente tramite backup o accesso fisico al server CA), Certipy forgia certificati arbitrari:

certipy forge -ca-pfx ca.pfx -upn administrator@dominio.local -subject "CN=Administrator"

Sul versante cloud, AADInternals (open source, modulo PowerShell) permette di creare e esportare certificati device per ambienti Entra ID. Il modulo è utile per testare scenari di device join e autenticazione certificato-based in tenant Azure AD.

Mimikatz completa il quadro con il modulo crypto, capace di esportare certificati e chiavi private dal certificate store locale, anche quando contrassegnati come non esportabili:

mimikatz # crypto::certificates /export /systemstore:LOCAL_MACHINE

In laboratorio, è fondamentale documentare ogni template vulnerabile individuato e la catena completa dall'enumerazione all'autenticazione, perché il valore del finding per il cliente sta nel dimostrare l'impatto reale, non la sola esistenza della misconfiguration.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo

Il detection di questa tecnica ruota attorno a due assi: gli eventi di enrollment dei certificati e l'accesso anomalo allo storage delle chiavi private.

Su Windows, la log source primaria è WinEventLog:Security. L'evento cardine è EventID 4886 ("Certificate Services received a certificate request") e il suo gemello EventID 4887 ("Certificate Services approved a certificate request and issued a certificate"). La correlazione tra i due — specialmente quando il campo Subject Alternative Name contiene un'identità diversa dal richiedente — è il segnale più forte di abuso ESC1.

L'EventID 4768 (Kerberos TGS request) con pre-autenticazione via certificato (tipo 16 — PKINIT) indica che qualcuno sta usando un certificato per ottenere un TGT. Se l'account associato non ha storicamente usato certificati per l'autenticazione, è un'anomalia da investigare immediatamente. A livello di tuning, differenziare tra service account e utenti interattivi riduce drasticamente i falsi positivi: molti servizi automatizzati usano legittimamente certificati.

Per gli ambienti con AD CS, è cruciale abilitare l'auditing granulare sulla CA. Il comando certutil -setreg CA\AuditFilter 127 attiva il logging completo di tutte le operazioni sul servizio certificati. Senza questa configurazione, la maggior parte degli eventi di enrollment non viene registrata.

L'accesso al registry path HKLM\SOFTWARE\Microsoft\SystemCertificates e ai file .pfx o .p12 nel file system va monitorato tramite Sysmon (open source). L'EventID 13 (Registry Value Set) su questi path, combinato con process chain anomale — come certutil.exe o openssl.exe lanciati da un processo figlio di cmd.exe o powershell.exe in contesto utente — produce alert ad alta fedeltà.

Su Linux, la detection passa da auditd. Regole di audit su path come /etc/ssl/private/, /etc/pki/ e sui comandi openssl pkcs12 o certtool intercettano i tentativi di esportazione. Il tuning chiave è escludere i servizi automatizzati (web server, agent di deploy) che accedono regolarmente ai certificate store.

Per macOS, il log unificato e gli eventi Keychain catturano le invocazioni del comando security e le chiamate API al Keychain. Una allowlist delle applicazioni legittime (browser, client VPN) riduce il rumore.

Sul fronte Identity Provider, i log di Azure Sign-In (azure:signinlogs) e i log unificati di M365 evidenziano enrollment anomali, modifiche alla configurazione CA e uso di token-signing certificates da geolocazioni inattese. Il contesto geografico è un potente filtro per distinguere attività lecita da compromissione.

Vuoi diventare SOC Analyst ma non sai da dove iniziare?

Scarica la guida gratuita e scopri come si monitorano e bloccano gli attacchi informatici

L'analisi forense di un abuso certificati inizia dallo stabilire cosa è stato rubato, cosa è stato forgiato e quando. I due scenari lasciano tracce diverse.

Nel caso di furto di certificati esistenti, gli artefatti primari su Windows risiedono nel registry. I certificati utente si trovano sotto HKCU\SOFTWARE\Microsoft\SystemCertificates\My\Certificates, quelli macchina sotto HKLM\SOFTWARE\Microsoft\SystemCertificates. L'analisi dell'hive NTUSER.DAT e SYSTEM con strumenti come Registry Explorer (open source, di Eric Zimmerman) permette di verificare timestamp di ultimo accesso alle chiavi contenenti i blob dei certificati. La presenza di file .pfx o .pem in directory temporanee, nel profilo utente o in path associati a tool offensivi è un indicatore forte.

Per ricostruire l'enrollment fraudolento, la CA stessa è la fonte primaria. Il database della CA (tipicamente %SystemRoot%\CertLog) registra ogni certificato emesso con data, template, richiedente e SAN. Il comando certutil -view -csv esporta l'intero database in formato analizzabile. Il campo "Requester Name" confrontato con il SAN del certificato rivela immediatamente le richieste di impersonation: se l'utente jsmith ha richiesto un certificato con SAN administrator@dominio.local, si tratta di abuso ESC1.

Gli Event Log di Windows conservano la sequenza temporale completa. L'EventID 4886 segna la richiesta, 4887 l'approvazione, e 4768 con tipo di pre-autenticazione PKINIT conferma l'uso del certificato forgiato per ottenere un TGT. Questa tripletta, correlata temporalmente, costituisce la spina dorsale della timeline.

Su sistemi Linux, l'analisi si concentra su /var/log/audit/audit.log alla ricerca di syscall open, read ed execve su path PKI. I file di history della shell (.bash_history, .zsh_history) possono contenere invocazioni esplicite di openssl con parametri di esportazione.

Per lo scenario golden certificate, l'indagine deve risalire alla compromissione del server CA. L'accesso alla chiave privata della CA — conservata nel registry o protetta da HSM — è l'evento zero. Se la chiave è stata esportata, ogni certificato emesso successivamente è potenzialmente sospetto. L'unica remediation completa è la riemissione dell'intera catena PKI.

Un elemento spesso trascurato: i certificati forgiati restano validi anche dopo il reset password dell'utente. Nella timeline, questo si manifesta come autenticazioni riuscite per account le cui credenziali sono state cambiate — un'anomalia che solo la correlazione tra log AD e log CA può rivelare.

Vuoi diventare Forensic Analyst ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto per analizzare incidenti e prove digitali

APT29 — L'abuso sistematico delle CA enterprise

APT29 (G0016), il gruppo attribuito alla Russia e noto anche come Cozy Bear, ha dimostrato una comprensione matura dell'infrastruttura PKI enterprise. La loro attività documentata include l'abuso di template AD CS mal configurati per impersonare utenti amministrativi e generare certificati di autenticazione aggiuntivi. Non si tratta di un uso opportunistico: APT29 sfrutta la PKI come meccanismo di persistenza calcolato, consapevole che un certificato valido sopravvive ai classici interventi di incident response come il reset delle password o la revoca delle sessioni.

Il pattern operativo di APT29 in questo contesto suggerisce una ricognizione preliminare approfondita dell'ambiente AD CS — enumerazione dei template, identificazione delle permission di enrollment — seguita da un abuso chirurgico mirato a identità ad alto privilegio. Questo approccio è coerente con il profilo generale del gruppo: paziente, orientato alla persistenza, focalizzato su obiettivi governativi e strategici.

Arsenal tecnico

Il panorama dei tool associati a questa tecnica evidenzia due strumenti di riferimento. AADInternals (S0677) estende l'attacco al cloud, con capacità di creare e esportare certificati per device joined o registered in Entra ID. Questo posiziona la tecnica non solo in contesti on-premise ma anche in architetture ibride e cloud-native. Mimikatz (S0002), con il suo modulo CRYPTO, resta il tool storico per l'esportazione di certificati e chiavi private dal certificate store locale, compresi quelli con flag di non esportabilità.

Trend e implicazioni strategiche

L'attacco ai servizi di certificazione è in crescita come vettore di persistenza avanzata. La ragione è strutturale: molte organizzazioni hanno implementato AD CS anni fa senza mai revisionare template e permission, creando una superficie d'attacco latente. Il concetto di golden certificate rappresenta l'evoluzione naturale del golden ticket Kerberos — stesso impatto (domain dominance), ma con un vettore più difficile da rilevare e rimediare, poiché la revoca completa richiede la rotazione della chiave CA.

Per il threat intelligence, il segnale da monitorare è l'adozione di questa tecnica da parte di gruppi ransomware e attori finanziariamente motivati: quando una TTP migra dallo spionaggio statale al cybercrime, l'impatto sul volume degli incidenti aumenta esponenzialmente. I team di CTI dovrebbero tracciare attivamente gli indicatori di compromissione delle CA — certificati con SAN anomali, enrollment massivi, accessi ai server CA — come early warning di compromissioni profonde del dominio.