Microsoft RAMP si ferma al confine della tua autorità di certificazione

Microsoft ha corretto CVE-2026-54121 il 14 luglio. I ricercatori H0j3n e Aniq Fakhrul hanno pubblicato un proof of concept funzionante 10 giorni dopo, chiamandolo Certighost. Se i tuoi server AD CS hanno installato l’aggiornamento cumulativo di luglio, sei protetto. Se sono ancora alle build di giugno, sei esposto a codice exploit pubblico.

L’attacco in sé è breve. Un utente standard del dominio senza diritti di amministratore manipola attributi su un account macchina che controlla, attiva una logica di fallback difettosa all’interno dell’autorità di certificazione e riceve un certificato firmato che si autentica come controller di dominio tramite PKINIT. Da lì, DCSync fornisce l’hash krbtgt e la possibilità di falsificare Golden Tickets nell’intera foresta. Richiede una Enterprise CA integrata con Active Directory e la capacità di creare o controllare un account computer, che la quota predefinita di 10 account macchina concede a ogni utente del dominio.

L'account che ha avviato la catena non ha mai avuto privilegi elevati in nessun momento. Questo è il dettaglio che conta qui, perché la roadmap di Microsoft per privileged access è costruita attorno a un modello di minaccia che questo attacco evita.

I tre gruppi di iniziativa di RAMP

Il Piano di Modernizzazione Rapida consiglia di separare e gestire gli account privilegiati, migliorare l’esperienza delle credenziali per chi li detiene e distribuire postazioni di lavoro amministrative. Sotto questi ci sono i dettagli su cui la maggior parte dei team di sicurezza sta lavorando ora: Privileged Identity Management (PIM), account di accesso di emergenza, categorizzazione dei ruoli Microsoft Entra per impatto, MFA e accesso senza password per gli amministratori, blocco dell’autenticazione legacy e Privileged Access Workstations.

La maggior parte di questo è lavoro di Microsoft Entra ID. Ciò che RAMP richiede on premises si riduce a account amministrativi separati, workstation dedicate per chi le usa e password uniche per l’amministratore locale. Certighost è un difetto in AD CS. Nessuno di questi tre lo coinvolge.

RAMP non contiene alcuna iniziativa di autorità di certificazione. Microsoft lo ha definito intenzionalmente in questo modo, e le linee guida lo confermano, basandosi su un documento separato di implementazione di Privileged Access Management. RAMP risponde a chi detiene accesso elevato nel tuo ambiente. Come la tua CA decide quale identità associare a un certificato è una questione diversa.

Certighost non sarà l'ultimo

L'integrità del rilascio dei certificati è una categoria che continua a produrre casi. La maggior parte dei metodi noti sono le tecniche di attacco ESC documentate da "Certified Pre-Owned", dove un modello o una flag CA consente a un utente senza privilegi di richiedere un certificato per un'identità che non possiede. Certighost è una forma diversa. La configurazione del modello è irrilevante. Il difetto è nella logica di gestione delle richieste dell'autorità di certificazione, in come ha risolto quale oggetto della directory la richiesta stesse realmente indicando.

Quella distinzione è importante per ciò che farai a riguardo. Un audit del modello di certificato, che è il consiglio standard, non avrebbe rilevato questo.

Cosa che i clienti fraintendono a riguardo

La maggior parte dei clienti considera AD CS coperto perché qualcuno se ne occupa. L'autorità di certificazione è affidata a un team PKI o infrastrutturale, il team di identity presume che ciò significhi che è gestito, e una linea di reporting diversa viene interpretata come un controllo. Quando chiedo se hanno verificato le loro configurazioni rispetto a uno dei percorsi ESC, la risposta è solitamente che non ne erano a conoscenza.

I team che ne sono responsabili vengono valutati in base alla disponibilità. L’emissione ha successo, i rinnovi non scadono, l’autenticazione non si interrompe, la CA è sana secondo ogni metrica di cui sono responsabili. Rimane sana in tutte quando un utente standard registra un certificato per un account a cui non ha diritto, ed è proprio per questo che nessuno se ne accorge.

La governance non ha nulla a cui aggrapparsi

I controlli di RAMP si attivano attorno a un account privilegiato. Certighost non lo tocca mai finché la CA non emette il certificato che lo crea.

Non esiste un account intermedio che PIM possa controllare né un'autenticazione admin che MFA possa sfidare. L'escalation e il pagamento avvengono in un'unica transazione all'interno dell'elaborazione della richiesta dell'autorità di certificazione, e l'account iniziale dell'avversario rimane esattamente dove era, allo stesso livello di ogni altro utente standard del dominio. Anche la quota di account macchina che rende possibile la fase di staging non è un'iniziativa RAMP.

RAMP punta a Microsoft Defender for Identity (MDI), e MDI offre una reale copertura dei certificati. Le valutazioni della postura analizzano modelli e impostazioni CA per i percorsi di escalation noti, e i controlli che esaminano la CA richiedono un sensore MDI sul server AD CS. Esiste anche un rilevamento nominato per questa tecnica che si attiva sul modello di richiesta.

Entrambi valgono la pena. Nessuno dei due nega la richiesta di iscrizione. Una valutazione della postura è un rapporto di configurazione che si legge a cadenza, mentre una rilevazione è un avviso che arriva durante il completamento della transazione.

Così un team di sicurezza può completare RAMP end to end, farlo bene, eseguire MDI insieme e comunque non avere alcun controllo che valuti e rifiuti una richiesta di certificato. La governance di Privileged Access Management e l'integrità dell'autorità di certificazione sono problemi separati. RAMP ne risolve uno, e direi che considerare un rollout completato come copertura per entrambi è la più comune errata interpretazione dello scopo di quella roadmap.

Se qualcuno mi dice che ha completato il lavoro su RAMP, la mia prima domanda è chi possiede l’autorità di certificazione. Se devono scoprirlo, questa è la risposta. RAMP è la roadmap giusta e completarla significa che i loro account privilegiati sono gestiti, il che è un vero progresso e non nulla. Non dice nulla sul sistema che può creare uno di quegli account da una richiesta di certificato di un utente standard. Monitorare quel sistema è il minimo. Quello che vorrei dopo è qualcosa che possa rifiutare la richiesta.

Blocco della richiesta di iscrizione

Netwrix Threat Prevention (NTP) e Netwrix Threat Manager (NTM) operano su entrambi i fronti. Sul lato monitoraggio, NTM copre gli stessi aspetti indicati da RAMP tramite Defender for Identity, rilevando abusi di AD CS e modelli di uso improprio dei certificati in tempo reale.

Il lato della prevenzione è ciò che li distingue. NTP valuta le richieste di iscrizione rispetto a modelli noti di abuso di AD CS, comprese le tecniche ESC1 fino a ESC7, e le blocca prima che esista un certificato invece di generare un record che ne sia stato emesso uno. Una valutazione della postura indica che un modello è errato e un rilevamento indica che una richiesta sembrava sbagliata, ma l’applicazione è l’unica delle tre che termina la transazione.

Esegui RAMP, poi controlla la tua autorità di certificazione

Segui RAMP. Il lavoro che richiede è un lavoro che vale la pena fare. Applica le patch ai tuoi server AD CS e imposta la quota degli account macchina a zero mentre sei lì.

Poi vai a controllare la tua autorità di certificazione, perché RAMP non ti ci porterà. Verifica i modelli, e poi poni la domanda più difficile sotto di essi: quando un account standard invia una richiesta di iscrizione affermando un’identità che non gli appartiene, cosa nel tuo ambiente valuta quella richiesta, e qualcosa la blocca o la registra semplicemente?