(In)sicurezza virtualizzata: come i criminali possono utilizzare gli enclave VBS come armi

I criminali cercano sempre nuovi modi per fornire ed eseguire malware sugli host senza venire rilevati. Abbiamo analizzato alcune nuove tecniche che consentono di eseguire i malware all'interno di un VBS (Vrtualization-Based Security) e di eludere i comuni sistemi di sicurezza. L'8 agosto 2025, ho esaminato questa superficie di attacco in una presentazione che ho tenuto alla DEF CON 33 a Las Vegas.

Gli enclave VBS, che fanno parte delle soluzioni di sicurezza di Microsoft, creano un ambiente virtuale per isolare i componenti critici del sistema operativo. Gli enclave VBS consentono, infatti, di isolare una sezione di un processo, rendendola inaccessibile ad altri processi, al processo stesso e, persino, al kernel. 

Anche se gli enclave VBS sono in grado di migliorare la sicurezza, possono comunque offrire interessanti opportunità per i criminali. Ecco perché i malware eseguiti all'interno di un enclave potrebbero rimanere invisibili ai comuni sistemi di rilevamento e indagine basati sulla memoria. Tenendo presente questo concetto, siamo riusciti a trovare vari modi con cui gli enclave VBS potrebbero venire sfruttati.

È importante comprendere il concetto dei livelli VTL (Virtual Trust Level) su cui si basano gli enclave VBS. Ogni livello di attendibilità fornisce entità eseguite al suo interno con diverse autorizzazioni di accesso alla memoria fisica. I livelli VTL inferiori non possono accedere alla memoria dei livelli superiori.

Attualmente, Windows utilizza due principali livelli di attendibilità:  il livello VTL0, utilizzato per eseguire i tradizionali componenti del sistema operativo, incluse le modalità di esecuzione del kernel normale e dell'utente normale; e il livello VTL1, che è il livello con maggiori privilegi rispetto al livello VTL0, che crea due modalità di esecuzione: la modalità protetta del kernel e la modalità utente isolata.

• La modalità protetta del kernel viene usata per eseguire il kernel nel livello VTL1 e, pertanto, dispone di un maggior numero di privilegi rispetto al kernel normale. Il kernel protetto può applicare le policy al kernel normale e limitarne l'accesso alle aree sensibili della memoria. Poiché il kernel protetto è molto limitato e non supporta driver di terze parti, presenta una superficie di attacco notevolmente ridotta.
• La modalità utente isolata viene utilizzata per eseguire processi sicuri, un tipo speciale di processo in modalità utente che utilizza le funzionalità di isolamento della memoria offerte dal livello VTL1. La memoria della modalità utente isolata non è accessibile da alcun codice VTL0, incluso quello del kernel normale.

Insieme, i livelli VTL0 e VTL 1 creano quattro modalità di esecuzione: 

• Ring0 VTL0: modalità del kernel normale
• Ring0 VTL1: modalità protetta del kernel
• Ring3 VTL0: modalità utente normale
• Ring3 VTL1: modalità utente isolata

Un enclave VBS crea una sezione di un processo della modalità utente all'interno della modalità utente isolata, in cui possiamo caricare le DLL denominate "moduli dell'enclave", che diventano un "ambiente di esecuzione attendibile", in cui cioè i dati e il codice in esso contenuti sono inaccessibili a tutto ciò che viene eseguito nel livello VTL. Questa funzione rende più semplice isolare le operazioni riservate dai criminali che possono violare un sistema.

Poiché l'accesso al livello VTL1 è limitato, per caricare una DLL all'interno di un enclave è necessario firmarla correttamente tramite uno speciale certificato emesso da Microsoft. Qualsiasi tentativo di caricare un modulo senza una firma di questo tipo determinerà un esito negativo del processo. Anche se i moduli dell'enclave possono essere firmati solo da terze parti affidabili, non viene controllato chi può caricare questi moduli:  purché siano firmati, qualsiasi processo può caricare moduli arbitrari in un enclave.

Gli enclave VBS risultano allettanti per i criminali per alcuni motivi. Innanzitutto, lo spazio degli indirizzi degli enclave è inaccessibile a tutto ciò che viene eseguito nel livello VTL0, inclusi gli strumenti EDR (Endpoint Detection and Response) e di analisi degli endpoint. In secondo luogo, le chiamate API effettuate dall'interno di un enclave possono rimanere invisibili ai sistemi EDR,

pertanto, abbiamo esaminato il modo con cui i criminali possono eseguire codice dannoso all'interno di un enclave e quali tecniche possono utilizzare dopo aver eseguito il malware. In questo blog, verranno illustrati i risultati delle nostre analisi.

Un modulo dell'enclave VBS può essere configurato in modo da essere sottoposto a debug. Poiché i moduli degli enclave vengono eseguiti nel livello VTL1, di norma, non è possibile sottoporli a debug perché il debugger non può accedere alla memoria dell'enclave per recuperare i dati o inserire dei breakpoint. Tuttavia, abbiamo scoperto che, il modulo di un enclave che può essere sottoposto a debug, se eseguito, viene comunque caricato nel livello VTL1. 

Per attivare l'operazione di debug, il kernel protetto implementa alcune eccezioni da applicare ai moduli degli enclave che possono essere sottoposti a debug. È possibile modificare anche le autorizzazioni della memoria all'interno del modulo di un enclave che può essere sottoposto a debug mediante il processo VTL0. I dati gestiti dal modulo possono essere resi facilmente vulnerabili,

il che viene a minare in modo efficace lo scopo principale degli enclave VBS, ossia isolare una sezione della memoria dal livello VTL0. Per tale motivo, Microsoft consiglia vivamente agli sviluppatori di non immettere sul mercato moduli di enclave che possono essere sottoposti a debug.

Se un criminale ottiene un qualsiasi modulo di un enclave firmato che può essere sottoposto a debug, può eseguire codice nel livello VTL1 effettuando le operazioni che ho delineato in occasione della DEF CON. Questa possibilità presenta un rischio per il criminale: come il criminale riesce ad accedere alla memoria dell'enclave, un sistema EDR può farlo altrettanto bene. Tuttavia, l'attacco è in grado di eludere il monitoraggio delle API che può limitare la visibilità di una soluzione EDR.

Questa tecnica potrebbe essere utilizzata per creare un impianto "semi-VTL1" nascosto, che sfrutta alcuni dei vantaggi ottenuti dall'esecuzione interna all'enclave.

Abbiamo esaminato l'eventualità in cui un criminale potrebbe usare una versione della tecnica BYOVE (Bring Your Own Vulnerable Enclave) per eseguire malware in un enclave VBS, il che consente di rilevare una vulnerabilità,

a cui è stato assegnato il codice CVE-2023-36880, presente nel modulo dell'enclave firmato VBS che viene utilizzato da Microsoft Edge. Scoperta da Alex Gough del Chrome Platform Security Team, questa vulnerabilità consente ai criminali di leggere e scrivere dati arbitrari all'interno dell'enclave. 

Abbiamo tentato di abusare della primitiva di lettura/scrittura per sovrascrivere lo stack dell'enclave con una catena ROP (Return-Oriented Programming), che ci avrebbe consentito di eseguire uno shellcode all'interno dell'enclave. Tuttavia, abbiamo scoperto che gli enclave sono protetti dall'esecuzione di codice non firmato tramite ACG (Arbitrary Code Guard), una funzione di mitigazione dei problemi di sicurezza, che è stata progettata per bloccare l'esecuzione di codice creato in fase di runtime (Figura). 

Non abbiamo (ancora) trovato un metodo per bypassare l'ACG in un enclave e per caricare codice non firmato al suo interno, anche se in teoria, è possibile sferrare un exploit ROP completo.

Abbiamo esaminato una tecnica di elusione della memoria denominata "Mirage" e ispirata ad un'altra tecnica di elusione chiamata Gargoyle, che crea un payload in grado di passare continuamente da uno stato legittimo ad uno dannoso. 

Mirage esegue questa operazione passando dalla memoria dell'enclave VTL1 a quella dell'enclave VTL0 e viceversa. Questo ciclo memorizza uno shellcode nella memoria dell'enclave VTL1, lo trasferisce periodicamente nell'enclave VTL0 sfruttando la vulnerabilità, lo esegue, quindi lo cancella subito dopo dalla memoria dell'enclave VTL0.

Poiché il payload impiega la maggior parte del tempo nascosto nel livello VTL1, è resiliente alle operazioni di scansione e di eliminazione della memoria. Durante la sua fase di inattività, il payload è sia invisibile che inaccessibile. Inoltre, la scrittura dello shellcode nel livello VTL0 viene eseguita dall'enclave, al di fuori della portata degli strumenti EDR, il che ne rende difficile il rilevamento tramite il monitoraggio.

Un'altra interessante applicazione per i malware degli enclave è l'anti-debugging. Il codice eseguito all'interno dell'enclave rimane inaccessibile alle applicazioni VTL0, inclusi i debugger, fornendo ai malware un vantaggio significativo.

Abbiamo esaminato una serie di approcci. Basandoci sull'accesso dell'enclave allo spazio degli indirizzi VTL0 del processo, possiamo leggere la PEB (Process Environment Block) manualmente e controllare il valore del flag BeingDebugged. Se viene rilevato un debugger, l'enclave può terminare il processo.

Abbiamo anche esaminato una tecnica di anti-debugging basata sul tempo che utilizza i cicli del clock del processore per misurare il tempo impiegato tra le varie chiamate dell'enclave e per terminare il processo se viene rilevato un ritardo significativo.

Spostando alcune parti critiche del nostro codice in un enclave insieme ad un controllo di anti-debugging, possiamo creare un malware praticamente invisibile alle analisi dinamiche. Se implementato correttamente, questo approccio potrebbe essere sconfitto solo eseguendo il debug di Hyper-V o del kernel protetto.

Attualmente, gli enclave vengono utilizzati solo da un numero limitato di applicazioni, pertanto l'utilizzo/abuso di un enclave anomalo può rappresentare un'ottima opportunità per il rilevamento. Per sfruttare questa opportunità, gli addetti alla sicurezza possono focalizzarsi sulle seguenti operazioni:

• Creare uno standard di riferimento per riconoscere un utilizzo legittimo degli enclave VBS e segnalare eventuali deviazioni
• Monitorare le API dell'enclave per eventuali anomalie
• Monitorare il caricamento dei DLL dell'enclave, che possono indicare un nuovo processo
• Utilizzare altre tecniche di sicurezza progettate per isolare applicazioni e sistemi critici, come la microsegmentazione

Mentre gli enclave VBS forniscono uno strumento efficace per proteggere le sezioni sensibili delle loro applicazioni, possono essere anche usati dai criminali per "tenere al sicuro" i loro malware. Come ho spiegato nella presentazione tenuta alla DEF CON, le strategie di attacco degli enclave sono, attualmente, molto teoriche. Tuttavia, possono essere certi che i criminali più esperti stanno cercando di individuare eventuali vulnerabilità tramite le quali possono utilizzare gli enclave VBS per scopi dannosi. 

Gestire l'utilizzo dell'enclave all'interno del proprio ambiente è un primo passo notevole per superare questa minaccia in continua evoluzione.

Per una spiegazione tecnica completa, vi consiglio di leggere il mio blog precedente dal titolo Abuso degli enclave VBS per creare malware elusivo.