Huy Kha | Architetto senior per l'identità e la sicurezza

L'escalation dei privilegi in Active Directory (AD) consente ai cyber-attaccanti di aumentare l'accesso all'interno dell'ambiente e potenzialmente di compromettere intere reti, senza essere scoperti. Enterprise CA Security Configuration (ESC1) è un metodo di attacco che è cresciuto in popolarità perché consente ai malintenzionati di ottenere un accesso privilegiato attraverso uno strumento che in realtà è stato progettato per semplificare la vita degli amministratori: i modelli di certificato.

Che cos'è un attacco ESC1?

I modelli di certificato aiutano a semplificare l'amministrazione delle autorità di certificazione (CA) di Active Directory Certificate Services (AD CS), fornendo un insieme preconfigurato di regole e impostazioni da applicare alle richieste di certificato in arrivo. Essi consentono agli amministratori di semplificare la gestione dei certificati e di garantire la coerenza nell'applicazione dei criteri di certificazione.

Tuttavia, i modelli di certificato possono essere vulnerabili all'uso improprio.

In un attacco ESC1, un utente malintenzionato sfrutta un modello di certificato Enterprise CA mal configurato in AD CS per richiedere un certificato per un account con privilegi elevati, ad esempio l'amministratore di dominio. Quindi, utilizza il certificato per agire come tale account, ottenendo un controllo non autorizzato.

Come funziona un attacco ESC1?

Per eseguire un attacco ESC1, un attore malintenzionato deve avere AD CS in funzione e deve avere il permesso di iscriversi a un modello di certificato non configurato correttamente.

L'attaccante cerca una configurazione del modello di certificato vulnerabile(Figura 1) con:

  • L'impostazione Supply in Request è selezionata, il che consente all'aggressore di richiedere un certificato per qualsiasi account.
  • Utilizzo esteso della chiave (EKU) estensioni come Client Authentication, PKINIT Client Authentication, Smart Card Logon, Any Purpose-o nessuna EKU (come ad esempio SubCA)
Figura 1. Modello di certificato vulnerabile, che consente a un utente malintenzionato di impersonare tutti gli utenti del dominio.

In presenza di queste condizioni, l'aggressore può richiedere un certificato per qualsiasi account del dominio(Figura 2) e quindi utilizzarlo per impersonare quell'account.

Figura 2. Richiesta di un certificato per conto di un account specificato

Come ci si può difendere da un attacco ESC1?

Se l'organizzazione dispone di modelli di certificato che consentono nomi alternativi di soggetti (SAN) e supportano Client Authentication EKU, potrebbero essere vulnerabili a un attacco ESC1.

Per evitare che ciò accada, seguite questi passi pratici:

  • Controllare i modelli di certificato: Esaminare tutti i modelli di certificato e identificare quelli che consentono le SAN e hanno estensioni EKU come:
    • 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 (OID 1.3.6.1.4.1.311.20.2.2)
    • Any Purpose (OID 2.5.29.37.0)
    • Oppure modelli senza EKU (come ad esempio SubCA)
  • Limitare chi può iscriversi: Assicuratevi che solo gli utenti o i gruppi che hanno veramente bisogno di accedere possano iscriversi ai certificati con questi modelli. Il restringimento dell'accesso aiuta a ridurre al minimo chi può sfruttare i modelli.
  • Richiedono l'approvazione del manager della CA: Per tutti i modelli di certificato che consentono SAN e supportano Client Authentication, attivare l'approvazione del gestore dei certificati della CA. Ciò significa che qualcuno deve approvare ogni richiesta prima che venga emesso un certificato.
  • Disattivare i modelli inutilizzati: Se alcuni modelli di certificato non vengono utilizzati, disabilitateli o modificateli per eliminare le configurazioni rischiose. Ad esempio, disattivate l'impostazione Supply in Request, in modo che gli utenti non possano richiedere certificati per altri account.

I difensori possono utilizzare il Purple Knight strumento di valutazione della sicurezza AD gratuito per identificare i modelli di certificato non sicuri e adottare misure per porvi rimedio(Figura 3).

Figura 3. Strumento Purple Knight che mostra i modelli di certificato vulnerabili

I difensori possono anche utilizzare Invoke-Locksmith1 (Figura 4) per identificare rapidamente i modelli di certificato non sicuri e intervenire per correggerli. Lo script Locksmith PowerShell include un'opzione per la correzione automatica, ma è importante testare e rivedere accuratamente tutto prima di implementare qualsiasi azione correttiva.

Una grande caratteristica di Invoke-Locksmith è che comprende anche Invoke-RevertLocksmithche consente a un'organizzazione di ripristinare facilmente qualsiasi modifica se nota un impatto negativo. Ciò fornisce un ulteriore livello di sicurezza quando si modificano i modelli di certificato.

Figura 4. Correzione dei modelli di certificato vulnerabili con Invoke-Locksmith

Come rilevare gli attacchi ESC1

In un ambiente aziendale di grandi dimensioni, il rilevamento di richieste dannose a modelli di certificati vulnerabili può essere impegnativo. Mentre gli ID evento 4886 e 4887 possono mostrare quale utente ha richiesto un certificato, non rivelano il valore che un utente malintenzionato ha specificato nel file subjectAltName per impersonare un account specifico.

Dal punto di vista forense, tutte le richieste di certificato vengono registrate (Figura 5) e possono essere visualizzati nell'interfaccia utente dell'autorità di certificazione alla voce Certificati emessi. Questa sezione mostra quando una richiesta di certificato include valori come quelli presenti nella sezione subjectAltNameinsieme ad altri dettagli importanti come l'autore della richiesta, il modello di certificato utilizzato, l'EKU e i relativi timestamp. Questi registri sono utili per indagare e rintracciare eventuali richieste di certificati sospetti.

Figura 5. Certificati emessi dal server CA

Profili degli attori delle minacce

I seguenti attori delle minacce hanno eseguito attacchi ESC1 in libertà:

  • UNC53302
  • APT293

Strumenti ESC1

I seguenti strumenti pubblici per l'abuso dei certificati di Active Directory possono essere utilizzati per eseguire un attacco ESC1:

  • Certificare
  • Certifico

Panoramica delle minacce

Tattica ATT&CK: escalation dei privilegi

Il 4 aprile 2024, Google Cloud ha pubblicato un rapporto che illustra come l'attore della minaccia UNC5330 abbia sfruttato le vulnerabilità CVE-2024-21893 e CVE-2024-21887 in Ivanti Connect Secure per infiltrarsi nella rete di una vittima. Ha utilizzato un account LDAP bind per sfruttare un modello di certificato Windows vulnerabile, creando un oggetto computer e impersonando un amministratore di dominio.4

Il 28 aprile 2022, Mandiant ha segnalato che APT29 ha sfruttato modelli di certificati mal configurati per impersonare utenti amministratori. Abusando di queste configurazioni errate in AD CS, l'aggressore è stato in grado di richiedere certificati come utenti a basso livello di privilegio e di specificare account ad alto livello di privilegio nel campo Subject Alternative Name (SAN). Questo ha permesso loro di autenticarsi come utenti ad alto privilegio.5

Istantanea Semperis

AD CS deve essere trattato come una risorsa di livello 0 perché ha un controllo diretto sulla sicurezza dell'intero ambiente Active Directory. La compromissione di AD CS potrebbe consentire agli aggressori di emettere certificati che permettono loro di impersonare account con privilegi elevati, di aggirare i controlli di sicurezza e di ottenere l'accesso completo a sistemi sensibili.

Ulteriori informazioni sull'escalation dei privilegi in AD

Note finali

  1. https://github.com/jakehildreth/Locksmith/tree/main
  2. https://malpedia.caad.fkie.fraunhofer.de/actor/unc5330
  3. https://malpedia.caad.fkie.fraunhofer.de/actor/apt29
  4. https://cloud.google.com/blog/topics/threat-intelligence/ivanti-post-exploitation-lateral-movement
  5. https://cloud.google.com/blog/topics/threat-intelligence/tracking-apt29-phishing-campaigns