Project Zero scopre bypass di Administrator Protection in Windows: UI Access diventa la crepa silenziosa

Quando Microsoft introduce Administrator Protection, l’obiettivo è chiaro: rendere più difficile il salto da utente “normale” a contesto amministrativo, separando in modo più netto il mondo a privilegi limitati da quello ad alta integrità. Il problema, come spesso succede in Windows, non è l’idea ma la compatibilità con il passato. Ed è qui che entra in gioco UI Access, una funzione nata per l’accessibilità che, nelle mani giuste, diventa un canale per aggirare la separazione. Il 12 febbraio 2026 Project Zero pubblica l’analisi di James Forshaw su cinque vulnerabilità legate a UI Access che consentono bypass pratici di Administrator Protection. Microsoft interviene con patch, ma la lezione resta: in Windows le feature di sicurezza “nuove” vivono sempre in equilibrio instabile con meccanismi storici come UIPI e Mandatory Integrity Control (MIC).

Administrator Protection: cosa cambia davvero e perché diventa un bersaglio

Administrator Protection lavora per isolare due identità operative: da un lato l’utente che vive a livello “normale”, dall’altro l’amministratore che dovrebbe comparire solo quando serve. L’idea è ridurre l’esposizione del token amministrativo, limitare gli scenari in cui un processo a integrità media riesce a interagire con un processo ad alta integrità, e in generale rendere meno banale il passaggio verso privilegi elevati. Questo modello si scontra con un dato strutturale: Windows non è un sistema “pulito” che nasce oggi. Porta con sé una lunga storia di interazioni tra processi via interfaccia grafica, messaggi di finestra, handle e hook. E la storia degli attacchi Shatter è il promemoria più chiaro: quando un processo privilegiato espone una UI manipolabile, il confine tra “utente” e “sistema” diventa negoziabile.

Dagli attacchi Shatter a UIPI e MIC: il passato che non passa

Prima di Windows Vista, molte escalation passavano da qui: un processo privilegiato mostrava una UI e un utente non privilegiato riusciva a manipolarla tramite messaggi finestra, iniettando comportamento e, in alcuni casi, codice. Con Vista e l’introduzione di UAC, Microsoft tenta di mettere ordine creando User Interface Privilege Isolation (UIPI), basata su Mandatory Integrity Control (MIC). In sintesi, UIPI riduce la possibilità che un processo a integrità media mandi messaggi “pericolosi” a un processo ad alta integrità. Non è un muro totale, perché esistono messaggi consentiti, ma l’architettura cambia: i processi non sono più liberi di giocare sullo stesso desktop come se nulla fosse. È la base concettuale su cui si appoggiano molte protezioni moderne in Windows.

UI Access: la deroga necessaria che diventa un’arma

Il punto è che l’accessibilità ha esigenze reali. Strumenti come screen reader e assistenti di input devono poter interagire con applicazioni elevate, altrimenti diventano inutili proprio quando l’utente ne ha più bisogno. Da qui nasce UI Access, un flag nel token che consente bypass controllati delle restrizioni UIPI, permettendo a tool certificati di interagire con processi ad alta integrità senza incappare in blocchi. Questa eccezione non è “gratis”. Per essere considerato UI Access, un executable deve rispettare requisiti specifici: manifest con uiAccess=true, firma con certificato trusted installato nel root store macchina, e soprattutto collocazione in directory considerate protette, tipicamente C:\Program Files o altre path amministrative, evitando sottodirectory scrivibili. In teoria, questo set di vincoli dovrebbe rendere la feature sicura. In pratica, Project Zero mostra che basta una crepa in uno di questi pilastri per trasformare UI Access in un ponte verso privilegi più alti.

Il cuore del problema: processi UI Access ad alta integrità che girano col token “sbagliato”

La frizione più pericolosa, nel contesto di Administrator Protection, è questa: un processo UI Access può ottenere alta integrità, ma in alcuni scenari finisce per eseguire codice nel contesto dell’utente limitato. È una combinazione tossica, perché rompe l’assunto base della separazione: se qualcosa ha capacità da processo elevato ma resta legato al contesto dell’utente “normale”, allora può diventare un canale silenzioso per interferire con il mondo amministrativo.

Forshaw descrive bypass che sfruttano proprio queste incongruenze, con tecniche che toccano tre aree ricorrenti: directory “sicure” ma scrivibili, repurposing di executables esistenti e manipolazioni del token.

Bypass 1: directory “sicure” che in realtà permettono scrittura

Uno dei cardini della sicurezza UI Access è la verifica della directory: se l’exe vive in una path protetta, dovrebbe essere “non modificabile” dall’utente. Il problema è che Windows ha storicamente avuto eccezioni, sottodirectory, edge case NTFS e percorsi che sembrano sicuri ma finiscono per essere scrivibili in modo inaspettato. L’analisi richiama controlli come AiCheckSecureApplicationDirectory in appinfo.dll e mostra come bypass di questi controlli possano permettere di piazzare o sovrascrivere eseguibili in posizioni ritenute affidabili. In passato, tecniche come l’abuso di NTFS alternate data streams hanno già dimostrato quanto sia facile “piegare” la validazione dei path, e la storia torna perché la logica è la stessa: se riesci a far passare un binario controllato dall’utente come “applicazione sicura”, hai un punto di ingresso privilegiato. Microsoft interviene rafforzando esclusioni e controlli su directory specifiche, includendo casi che nel tempo erano diventati terreno fertile per bypass.

Bypass 2: repurposing di executables UI Access già presenti nel sistema

Se non puoi installare un nuovo exe UI Access, puoi provare a sfruttarne uno già presente. Forshaw mostra come sia possibile individuare executables che hanno già uiAccess=true e poi cercare modalità per fargli caricare DLL controllate, interpretare parametri in modo utile o agganciare comportamenti tramite configurazioni e variabili di ambiente. Il punto operativo è che un exe “legittimo” con UI Access, se ha anche solo una debolezza di caricamento librerie o di path resolution, può diventare un veicolo. Vengono citati scenari dove la manipolazione di percorsi, la risoluzione di directory base e l’abuso di parametri di CreateProcessAsUser consentono di orientare la ricerca di DLL verso location controllate dall’utente. In questi casi, l’attaccante non deve “bucare” il kernel: gli basta far fare al sistema una cosa che il sistema sa già fare, ma nel posto sbagliato.

Bypass 3: manipolazioni del token e degradazione dell’integrità

Un’altra classe descritta riguarda la gestione del token: se un attaccante può duplicare token, modificarne integrità o forzare stati borderline, può tentare di ottenere un processo UI Access in condizioni che non dovrebbero essere consentite. Qui emergono tecniche di riduzione integrità, blocchi come NtSetInformationToken, e percorsi alternativi che possono aggirare limitazioni con funzioni di creazione token in contesti sandbox o App Container. Il tema non è solo la singola API, ma la coerenza complessiva: se UI Access deve essere un’eccezione strettamente controllata, ogni via laterale che permette di “ricreare” quel token in condizioni diverse è un rischio.

RAiLaunchAdminProcess e l’accessibilità che salta il prompt

UI Access, per definizione, serve anche a evitare che strumenti di accessibilità finiscano bloccati dietro prompt UAC. Per questo esistono meccanismi e servizi che consentono di lanciare processi con UI Access tramite RPC, ad esempio attraverso metodi come RAiLaunchAdminProcess. È un punto logico: un utente con disabilità non può “restare bloccato” da un prompt che impedisce l’uso degli strumenti. Ma in un contesto offensivo, questo diventa un moltiplicatore. Se riesci a far partire un processo UI Access in modo affidabile, e poi riesci a sfruttarlo per interferire con processi elevati, hai un bypass che diventa pratico e ripetibile. Forshaw collega questi scenari a exploitation che, una volta ottenuta esecuzione nel processo UI Access, possono portare a hooking e caricamento DLL tramite meccanismi come SetWindowsHookEx, specialmente quando esistono finestre o contesti che consentono handle e interazioni.

Nove bypass precedenti e una costante: il confine UI è fragile

Project Zero segnala che esistono stati già noti e già corretti: vengono citati nove bypass precedenti sistemati nel tempo. È un dettaglio che pesa perché indica una dinamica ricorrente: quando una feature crea un ponte tra integrità diverse, la superficie d’attacco tende a riemergere in forme nuove. La ragione è strutturale. UIPI e MIC non sono semplici “toggle”, sono regole che dipendono da token, directory, firme, servizi e logiche di creazione processo. Appena un elemento non è perfettamente allineato, l’attaccante cerca la scorciatoia. UI Access, essendo un’eccezione progettata per essere potente, paga un prezzo alto in termini di audit e test.

Microsoft patcha: filtraggio del token “shadow” e hardening su directory e controlli

Il dato positivo è che, in questo caso, Microsoft applica patch per chiudere i vettori descritti. L’intervento chiave viene descritto come un rafforzamento del modello Administrator Protection tramite copia filtrata del token shadow, per evitare che i processi UI Access possano ereditare condizioni che rompono la separazione tra profili. Accanto a questo, arrivano correzioni su controlli di directory, esclusioni di path problematiche e mitigazioni su manipolazioni di token e path resolution. La sostanza è che Microsoft tenta di richiudere la “deroga” UI Access dentro confini più solidi, evitando che la funzione di accessibilità diventi un bypass generalizzato.

Perché questa storia è importante anche fuori dal mondo Windows internals

Queste scoperte non sono solo materiale da blog tecnico. Il tema operativo è che Administrator Protection è un tassello della strategia Microsoft contro privilege escalation e bypass UAC. Se la feature viene percepita come aggirabile tramite componenti storici, gli attaccanti ottengono due vantaggi: possono costruire catene più silenziose e possono farlo usando meccanismi “legittimi” del sistema, quindi più difficili da distinguere da attività normale. Allo stesso tempo, la storia mostra un punto spesso ignorato: l’accessibilità non è una funzione marginale. È una parte profonda del sistema operativo, e proprio perché deve avere potere, diventa un bersaglio. Proteggerla richiede test e threat modeling di livello pari, se non superiore, a quello delle componenti più “ovvie” della security.