Aprire un file sospetto senza sporcare il PC: Windows Sandbox configurata a mano

La scena si ripete ogni settimana. Un fornitore manda un installatore che nessuno aspettava; su un forum qualcuno consiglia una utility da 400 kB che risolve esattamente il tuo problema; un cliente gira un allegato arrivato da un indirizzo che somiglia a quello di sempre. Aprirlo sul computer di lavoro è una scommessa, e la posta in gioco non è il computer: sono le credenziali salvate nel browser, le chiavi SSH, le cartelle dei clienti sincronizzate su cloud.

La risposta ortodossa — «usa una macchina virtuale» — è corretta e quasi nessuno la applica, perché creare la VM, installarci Windows e ricordarsi di riportarla allo stato pulito costa mezz'ora. Windows ne ha una versione che costa dieci secondi, è installata di serie nelle edizioni professionali e si butta via da sola: Windows Sandbox. Chi la usa la lascia quasi sempre con le impostazioni di partenza, pensate per la comodità e non per la prudenza.

Una stanza che si butta via

La documentazione Microsoft la descrive come «a lightweight, isolated desktop environment for safely running applications», adatta a «testing, debugging, exploring unknown files». Non è un emulatore né una finestra di compatibilità: è un sistema operativo completo che gira accanto al tuo. La pagina ufficiale è esplicita sul meccanismo — «relies on the Microsoft hypervisor to run a separate kernel that isolates Windows Sandbox from the host» — e sul destino di quel che ci metti dentro: «the sandbox is temporary; closing it deletes all software, files, and state».

Due parole sui termini. L'hypervisor è lo strato software che sta sotto i sistemi operativi e li tiene separati; il kernel è il nucleo del sistema operativo, la parte che parla con l'hardware. «Isolamento del kernel» significa che il programma aperto nella sandbox non chiede servizi al nucleo del tuo Windows, ma a un secondo nucleo che vive e muore con la finestra: una separazione più profonda di quella fra due account utente dello stesso computer. Il «nulla persiste», però, vale alla chiusura e non al riavvio interno: da Windows 11 versione 22H2 i dati sopravvivono ai riavvii avviati dentro la sandbox.

Due limiti da sapere subito. La funzionalità non c'è in tutte le edizioni — Pro, Enterprise, Pro Education/SE ed Education sì, e «Windows Sandbox is currently not supported on Windows Home edition» — e se c'è si attiva da «Attiva o disattiva funzionalità di Windows», con un riavvio e la virtualizzazione hardware abilitata nel firmware UEFI. Inoltre «Windows Sandbox currently doesn't allow multiple instances to run simultaneously»: una sandbox per volta.

I valori predefiniti sono comodi, non prudenti

Qui sta la differenza fra un isolamento vero e la sensazione di isolamento. Se lanci la sandbox dal menu Start, senza configurarla, parte con la rete attiva, gli appunti condivisi con il computer ospite e la GPU condivisa. La documentazione lo dice voce per voce: la rete «enables networking by creating a virtual switch on the host», gli appunti sono quelli del PC («copy/paste between the host and sandbox are permitted under Default»), la GPU virtuale è attiva per impostazione predefinita. E accanto alla rete c'è l'avvertenza: «enabling networking can expose untrusted applications to the internal network».

In pratica: un programma malevolo lanciato nella sandbox predefinita non tocca i tuoi file, ma vede la tua rete locale — il NAS, la stampante, il gestionale, il router — e raggiunge Internet per scaricare la sua seconda fase. Dal punto di vista di chi sta all'altro capo, è un computer dentro il tuo ufficio.

Il file di configurazione: dodici righe di XML

Tutto si governa con un file di testo con estensione .wsb, scritto in XML (un formato a etichette annidate, come l'HTML): doppio clic e la sandbox parte già configurata. Gli elementi utili, con il valore predefinito che la documentazione Microsoft attribuisce a ciascuno:

Una voce merita un commento: ProtectedClient è l'unica che aggiunge sicurezza invece di togliere comodità — «adds a new layer of security boundary by running inside an AppContainer Isolation execution environment» — e il fatto che sia predefinita a «disattivato» dice, implicitamente, che la configurazione di partenza non è la più chiusa possibile.

Questo è il file che uso per aprire qualcosa di cui non mi fido. Lo si salva come triage.wsb, dopo aver creato sul PC una cartella C:\Quarantena dove mettere il file da esaminare:

<Configuration>
  <vGPU>Disable</vGPU>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <PrinterRedirection>Disable</PrinterRedirection>
  <AudioInput>Disable</AudioInput>
  <VideoInput>Disable</VideoInput>
  <ProtectedClient>Enable</ProtectedClient>
  <MemoryInMB>4096</MemoryInMB>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Quarantena</HostFolder>
      <SandboxFolder>C:\Quarantena</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>explorer.exe C:\Quarantena</Command>
  </LogonCommand>
</Configuration>

Una stranezza da conoscere, perché fa perdere tempo: la pagina di riferimento scrive l'elemento della GPU come <vGPU>, l'esempio ufficiale Downloads.wsb lo scrive <VGpu>, e la pagina della riga di comando usa il valore Disabled dove la tabella ammette Disable. Sono tre pagine ufficiali che discordano: se la sandbox rifiuta di partire lamentando la configurazione, la grafia di quelle voci è il primo posto dove guardare.

Le cartelle condivise sono il punto dove si sbaglia

Il file sopra condivide una sola cartella, e in sola lettura. Non è pignoleria: l'avvertenza sulle cartelle mappate è la più netta di tutta la pagina — «files and folders mapped from the host can be compromised by apps in the sandbox or potentially affect the host». Una cartella condivisa in scrittura è un buco nel muro, e la dimensione la decidi tu. Da qui due regole, valide per chiunque tratti dati di terzi: non si mappano cartelle di lavoro — non «Documenti», non quella sincronizzata del cloud, non quella di un cliente — ma una cartella di quarantena creata per lo scopo; e ReadOnly sta a true per impostazione.

Il prezzo va messo in conto: con gli appunti disattivati e la cartella in sola lettura dalla sandbox non esce niente, e se stavi provando un convertitore il file convertito muore con la finestra. Se l'obiettivo è capire che cosa fa un installatore, tutto chiuso; se l'obiettivo è ottenere un risultato da un programma di cui non ti fidi, una seconda cartella scrivibile, vuota e distinta da quella del file sospetto, è il minimo male. Quel che non va fatto è lasciare aperto tutto per comodità e raccontarsi di aver aperto il file «in sandbox».

Dalla riga di comando, se hai 24H2

Chi usa già la sandbox probabilmente non sa che si pilota anche da terminale: «starting with Windows 11, version 24H2, the Windows Command Line Interface (CLI) offers powerful tools for creating, managing, and controlling sandboxes, executing commands, and sharing folders». Il comando è wsb, con i sottocomandi start, list, stop, exec, share, connect e ip; --raw restituisce l'output in JSON, cioè in un formato che uno script può leggere. La configurazione si può passare direttamente, senza file:

wsb start --config "<Configuration><Networking>Disabled</Networking></Configuration>"
wsb list
wsb stop --id 12345678-1234-1234-1234-1234567890AB

Il valore pratico non è la comodità ma la ripetibilità: una procedura scritta in uno script fa sempre le stesse cose, e una procedura ripetibile si può documentare. Due dettagli: wsb share accetta --allow-write, quindi da terminale è facilissimo aprire in scrittura ciò che nel file avevi chiuso; e wsb exec non funziona su una sandbox silenziosa, perché «an active user session is required to execute a command» — prima serve un wsb connect.

Quello che la sandbox non è

A uno strumento comodo si finisce per chiedere cose che non fa. Non è un laboratorio di analisi del malware: non registra il traffico di rete, non confronta lo stato del sistema prima e dopo, non conserva nulla che possa diventare una prova. E non sostituisce l'antivirus sul computer ospite, perché il file sospetto, prima di entrare nella sandbox, è passato dal disco del PC. Aggiungo una considerazione mia, non della documentazione: molti programmi malevoli riconoscono di girare in un ambiente virtualizzato e proprio lì si comportano bene. «L'ho aperto nella sandbox e non faceva niente» non è un certificato di innocuità: la sandbox protegge il tuo computer mentre guardi, non emette giudizi sul file.

Cosa puoi fare

Se usi Windows 11 Pro, apri «Attiva o disattiva funzionalità di Windows» e guarda se «Windows Sandbox» è spuntata: nella maggior parte delle installazioni non lo è. Attivala, riavvia, verifica che parta. Poi crea C:\Quarantena e salva sul desktop il file .wsb riportato sopra: la prossima volta che arriva un installatore inatteso, lo copi là dentro e fai doppio clic sulla configurazione, non sull'installatore.

Se sei responsabile dei PC di un ufficio, la verifica è un'altra: quanti utenti hanno un'edizione che la supporta, e quanti aprono allegati sullo stesso computer con cui accedono al gestionale. Un ultimo avvertimento: se il file potrebbe finire in un contenzioso o in una segnalazione, la sandbox non è lo strumento giusto — lì serve una copia conservata senza alterarla, con l'impronta calcolata prima di toccarla, e un ambiente che registri ciò che accade. La sandbox è per il lavoro di tutti i giorni: un modo rapido e onesto di dire «questo non lo apro sul mio computer».