Windows 11 può ricordare una chiavetta USB anche dopo che l’abbiamo scollegata. Non conserva una copia dei file presenti sull’unità né mantiene automaticamente un registro completo di ciò che abbiamo letto, scritto o trasferito. La spiegazione sta nel funzionamento di Plug and Play, che associa a ogni periferica una serie di identificatori e proprietà per riconoscerla alle connessioni successive.
Si tratta di un comportamento noto da tempo, sebbene in questi giorni si sia sollevato un vespaio (a torto) su questa e su altre funzionalità, come la cache delle miniature. Già nel 2012 Microsoft documentava come l’inserimento di un dispositivo di archiviazione USB producesse informazioni nel Registro di sistema, in particolare sotto la chiave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR.
Sui social circolano messaggi secondo cui Windows manterrebbe una sorta di “lista permanente” di tutte le unità USB collegate al PC. Una parte dell’affermazione parte da un fatto reale, ma la conclusione è fuorviante.
Windows mantiene infatti metadati relativi a dispositivi che non risultano più fisicamente presenti; Microsoft li definisce non-present devices oppure, più informalmente, “phantom devices” (dispositivi fantasma, in italiano). Servono soprattutto per evitare di trattare ogni nuova connessione come se fosse la prima e per facilitare installazione dei driver, associazione dei volumi e attività diagnostiche.
Perché Windows conserva le informazioni sulle unità USB
Quando una chiavetta, un SSD esterno o un altro dispositivo compatibile entra in funzione, Windows verifica l’hardware collegato e crea una device instance. In pratica, il sistema deve capire quale dispositivo ha davanti, quale driver usare, quali proprietà espone e se quella periferica era già comparsa in passato. Per i classici dispositivi di archiviazione USB entra in gioco Usbstor.sys, driver presente in Windows da molte generazioni.
Una parte delle informazioni compare sotto HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR. Qui Windows organizza i dispositivi in base agli identificatori comunicati dall’hardware. Gli ID possono includere produttore, modello, revisione e, quando disponibile, elementi utili a distinguere una specifica unità da un’altra.
Quando scolleghiamo fisicamente una chiavetta, Windows non può sapere se non verrà usata in seguito oppure se tornerà ad essere connessa alla medesima porta 5 minuti dopo.
Eliminare ogni volta tutte le informazioni costringerebbe il sistema a ricostruire da zero parti della configurazione: la scelta è quindi quella di conservare la device instance, lasciandola semplicemente nello stato “non presente”.
Il comportamento non riguarda soltanto le unità USB. Gestione dei dispositivi, cache degli identificatori, mapping dei volumi e log tecnici esistono anche su altri sistemi operativi; sono meccanismi necessari per riconoscere l’hardware e diagnosticare problemi. Considerare la sola persistenza di un identificatore come prova di un’attività sospetta significa confondere una normale funzione di gestione con un sistema di sorveglianza.
Come vedere i dispositivi USB che Windows ricorda
Il metodo più immediato passa da Gestione dispositivi: basta premere Windows+X quindi Gestione dispositivi e infine scegliere Visualizza, Mostra dispositivi nascosti. Tra gli elementi nascosti possono comparire proprio periferiche fisicamente rimosse ma le cui informazioni non sono state cancellate dal Registro.
Da PowerShell o aprendo una finestra del Prompt dei comandi possiamo invece interrogare direttamente USBSTOR:
reg query "HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR" /s
L’opzione /s forza la scansione ricorsiva delle sottochiavi.
PowerShell offre un approccio più leggibile tramite il modulo PnpDevice:
Get-PnpDevice -Class DiskDrive | Where-Object { $_.InstanceId -like 'USBSTOR\*' } | Format-List Status,FriendlyName,InstanceId
Quali dati su ciascuna chiavetta può conservare Windows
I dati memorizzati variano a seconda del dispositivo e di ciò che il firmware comunica al sistema operativo. Possiamo trovare un FriendlyName leggibile, per esempio il nome commerciale del dispositivo, identificatori hardware, identificatori di istanza e proprietà relative all’installazione.
Alcuni dispositivi espongono inoltre un numero seriale affidabile, altri no; in certi casi Windows ricava l’identità dell’istanza usando informazioni differenti. L’attribuzione univoca richiede quindi molta prudenza.
Windows espone anche proprietà temporali tramite Get-PnpDeviceProperty. Un esempio:
$deviceId = 'INSERIRE_QUI_INSTANCE_ID_COMPLETO'
Get-PnpDeviceProperty -InstanceId $deviceId | Where-Object { $.KeyName -match '_(FirstInstallDate|InstallDate|LastArrivalDate|LastRemovalDate)$' } | Format-List KeyName,Data
FirstInstallDate indica la prima installazione della device instance e non cambia a ogni aggiornamento del driver; InstallDate rappresenta invece l’ultima installazione dell’istanza e può cambiare quando il driver riceve un aggiornamento. Eventuali proprietà di arrivo e rimozione possono offrire ulteriori indicazioni temporali, ma non vanno interpretate come un diario completo di ogni collegamento avvenuto nella vita del PC.
USBSTOR non è sempre presente: attenzione ai dispositivi UASP
Un dettaglio importante è che USBSTOR non rappresenta ogni possibile unità collegata via USB. Microsoft documenta che Usbstor.sys gestisce i dispositivi di archiviazione di massa compatibili, in particolare quelli che utilizzano il tradizionale protocollo Bulk-Only Transport. Da queste periferiche Windows ricava identificatori nel formato USBSTOR\..., costruiti anche sulla base delle informazioni SCSI restituite dal dispositivo.
Con SSD esterni, box NVMe e altri dispositivi moderni può però entrare in gioco UASP, USB Attached SCSI Protocol. In questi casi l’identificatore visibile attraverso Plug and Play può comparire sotto SCSI\... anziché USBSTOR\....
Se il comando reg query "HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR" /s restituisce un errore perché la chiave non esiste, non significa necessariamente che il PC non abbia mai usato dispositivi di archiviazione esterni. Può semplicemente significare che non risultano device instance gestite tramite Usbstor.sys.
Per una verifica meno vincolata al tipo di driver conviene partire dal comando seguente osservando gli InstanceId effettivamente presenti:
Get-PnpDevice -Class DiskDrive | Format-List Status,FriendlyName,InstanceId
Una voce USBSTOR non dimostra che qualcuno abbia copiato file
La presenza di un dispositivo nel database Plug and Play può dimostrare che Windows lo ha riconosciuto, ma non dice automaticamente quali file contenesse, quali documenti siano stati letti o se sia avvenuto un trasferimento di dati.
Per ottenere informazioni più precise sui file effettivamente aperti, modificati o copiati da e verso un’unità rimovibile, Windows usa meccanismi di auditing separati rispetto a USBSTOR. La voce più interessante è Audit Removable Storage, una sottocategoria dei criteri di controllo avanzati che può generare eventi nel registro Sicurezza quando un processo o un utente accede a file e cartelle presenti su supporti rimovibili.
Un cenno agli strumenti di auditing di Windows
In pratica, sui sistemi Windows Pro, Enterprise ed Education si può aprire secpol.msc, quindi raggiungere Criteri locali, Criteri di controllo avanzati, Accesso agli oggetti, Controlla archiviazione rimovibile. Qui è possibile abilitare il controllo per gli eventi riusciti, per quelli non riusciti oppure per entrambi.
La stessa configurazione può essere applicata anche da riga di comando, con privilegi amministrativi:
auditpol /set /subcategory:"Removable Storage" /success:enable /failure:enable
Su un sistema in italiano il nome visualizzato della sottocategoria può cambiare in base alla localizzazione; per vedere le categorie disponibili conviene usare:
auditpol /get /category:*
Una volta abilitato l’auditing, gli eventi compaiono in Visualizzatore eventi, Registri di Windows, Sicurezza. Tra quelli più utili ci sono 4656, relativo alla richiesta di accesso a un oggetto; 4663, che indica l’effettivo utilizzo di uno specifico diritto di accesso e 4658, registrato alla chiusura dell’handle.
L’evento 4663 è particolarmente interessante perché può contenere il percorso dell’oggetto coinvolto, il processo che ha effettuato l’accesso e il tipo di operazione richiesta. Se, per esempio, un’applicazione apre E:\Documenti\report.xlsx, nel registro può comparire il nome completo del file insieme al processo responsabile.
La presenza di un evento 4663 non equivale però alla prova che un file sia stato copiato su una chiavetta: può indicare lettura, scrittura, modifica degli attributi o altre operazioni. Per ricostruire una copia bisogna correlare più eventi, i percorsi sorgente e destinazione, il processo coinvolto e gli accessi effettivamente richiesti.
C’è inoltre un limite fondamentale: l’auditing deve risultare attivo nel momento in cui avviene l’accesso. Abilitarlo successivamente non permette di ricostruire retroattivamente ciò che è successo.
Come rimuovere i vecchi dispositivi fantasma
Su un normale PC non c’è quasi mai una ragione per eliminare manualmente le informazioni sui dispositivi via via collegati.
Se però volessimo davvero rimuovere un dispositivo non più utilizzato, la strada più semplice consiste nell’aprire Gestione dispositivi, mostrare i dispositivi nascosti, individuare l’unità non collegata e riportata in grigio, quindi scegliere Disinstalla dispositivo.
È preferibile evitare cancellazioni aggressive direttamente sotto Enum\USBSTOR: sono chiavi che fanno parte della gestione Plug and Play e modificarle indiscriminatamente può produrre comportamenti imprevisti, problemi di enumerazione o richieste di reinstallazione dei driver.
Microsoft mette inoltre a disposizione il programma DevNodeClean per scenari amministrativi in cui si accumulano numerosi dispositivi storage non più presenti. Si tratta però di uno strumento pensato soprattutto per attività di manutenzione e troubleshooting: non serve eseguire una pulizia periodica di USBSTOR su un comune PC.