Cestino e copie shadow del volume

Quando un utente elimina un file in Windows, spesso il file non scompare. Un'eliminazione tramite Esplora file di solito sposta il file nel Cestino, insieme a un piccolo record che indica da dove proviene, quando è stato eliminato e chi lo ha eliminato. Le copie shadow del volume possono conservare versioni precedenti di interi volumi. Questa lezione tratta entrambi gli argomenti in Windows 10 e 11: come vengono memorizzati, come decodificarli, che cosa dimostrano e quali sono i loro limiti. Nelle indagini e all'esame, il Cestino è una probabile fonte di un percorso originale esatto, di una data e ora di eliminazione o di un SID.

Il Cestino in Windows Vista e versioni successive

Ogni volume fisso dotato di Cestino, indipendentemente dal file system, contiene una cartella di sistema nascosta X:\$Recycle.Bin\. Al suo interno, Windows crea una sottocartella per ogni utente che ha eliminato qualcosa su quel volume, denominata in base all'identificatore di sicurezza (SID) dell'utente, ad esempio C:\$Recycle.Bin\S-1-5-21-1844237615-456351123-789044191-1001\. Il Cestino è quindi specifico per volume e per utente: un file eliminato da D: viene spostato in D:\$Recycle.Bin, non in C:. La cartella del SID collega ogni eliminazione a un account. Per ricavare il nome utente dal SID, utilizzare la chiave ProfileList nell'hive SOFTWARE oppure l'hive SAM (lezione 2.2).

Ogni elemento eliminato diventa una coppia di voci che condividono la stessa parte casuale del nome:

• $I + 6 caratteri casuali + estensione originale, ad esempio $IABC123.pdf: un piccolo file di metadati che contiene il percorso originale, la dimensione e la data e ora di eliminazione.
• $R + gli stessi 6 caratteri + estensione, ad esempio $RABC123.pdf: il contenuto. Se è stata eliminata una cartella, $R… è una cartella che contiene ancora i file e le sottocartelle originali con i loro nomi originali.

All'interno dello stesso volume, l'invio di un file al Cestino è una ridenominazione (uno spostamento), non una copia. Il file $R conserva il record MFT e i dati del file originale, quindi il suo hash corrisponde a quello del file originale. La ridenominazione di solito compare anche nel journal delle modifiche $UsnJrnl (lezione 1.4). Ogni cartella del SID di solito contiene anche un file desktop.ini, che non costituisce prova di alcuna eliminazione.

Il formato del file $I

Tutti gli interi nel file $I sono in formato little-endian.

La versione 1 (da Vista a 8.1) presenta gli stessi primi 24 bytes, con il campo della versione impostato su 1. Non dispone di un campo per la lunghezza: il percorso inizia all'offset 24 in un campo fisso di 520 bytes (260 caratteri UTF-16), completato con zeri, quindi ogni file $I di versione 1 misura 24 + 520 = 544 bytes. Un file di versione 2 misura 28 + 2 × (lunghezza del percorso) bytes. Un parser che controlla il campo della versione legge entrambi i formati.

FILETIME, trattato nella lezione 2.1, è un conteggio a 64 bit di intervalli di 100 nanosecondi a partire dal 1601-01-01 00:00:00 UTC. La data e ora di eliminazione di $I è memorizzata in UTC, quindi l'impostazione del fuso orario del sistema non la modifica.

Esempio svolto: decodifica di un file $I

Un'acquisizione di triage contiene C:\$Recycle.Bin\S-1-5-21-1844237615-456351123-789044191-1001\$IABC123.pdf, lungo 94 bytes. Il suo contenuto:

1. Versione. 2, quindi si tratta del formato di Windows 10/11 e il campo della lunghezza del percorso è presente.
2. Dimensione. Invertire l'ordine dei bytes: 0x0003CB24 = 3 × 65.536 + 0xCB24 (52.004) = 196.608 + 52.004 = 248.612 bytes.
3. Data e ora di eliminazione. Invertire l'ordine dei bytes: 0x01DCB3D17F0D352A = 134.179.801.275.381.034. Sottrarre il valore FILETIME dell'epoca Unix, 116.444.736.000.000.000: il risultato è 17.735.065.275.381.034 intervalli di cento nanosecondi, ovvero 1.773.506.527,5381034 secondi dal 1970-01-01. 1.773.506.527 = 20.526 giorni × 86.400 + 60.127 secondi. 20.526 giorni dopo il 1970-01-01 corrispondono al 2026-03-14. 60.127 secondi = 16 h (57.600) + 42 min (2.520) + 7 s. La data e ora di eliminazione è 2026-03-14T16:42:07Z (al secondo; il valore completo è 16:42:07.5381034).
4. Lunghezza del percorso. 0x21 = 33 caratteri, incluso il carattere nullo. 28 + 33 × 2 = 94 bytes, che corrisponde alla dimensione del file, quindi il record è completo.
5. Percorso. Decodificare 32 caratteri UTF-16LE (0x43 0x00 = C, 0x3A 0x00 = :, 0x5C 0x00 = \ …): C:\Users\ana\Documents\offer.pdf.

Verificare il risultato mediante riscontri: la dimensione di $RABC123.pdf dovrebbe essere di 248.612 bytes, il suo hash è quello del documento eliminato e il SID …-1001 dovrebbe corrispondere all'account ana. RBCmd è un esempio di parser gratuito: RBCmd.exe -d "C:\$Recycle.Bin" --csv out scrive una riga per ogni file $I (legge anche INFO2). Utilizzarlo per verificare la decodifica manuale.

Che cosa non registra il Cestino

• Ripristino e svuotamento. Il ripristino di un elemento rinomina $R ripristinando il percorso originale ed elimina $I. Lo svuotamento del Cestino, o l'eliminazione di un singolo elemento al suo interno, li elimina entrambi. I record MFT e i cluster dei file rimossi diventano quindi non allocati e possono essere recuperati con i metodi della lezione 1.8 finché non vengono riutilizzati. Un file $I recuperato in questo modo fornisce ancora il percorso originale e la data e ora di eliminazione.
• Esclusione del Cestino. Shift+Delete, del nel Prompt dei comandi, Remove-Item in PowerShell e la maggior parte dei programmi che eliminano direttamente i file non utilizzano il Cestino. Anche gli elementi eliminati dalle condivisioni di rete vengono solitamente eliminati direttamente. L'assenza di un file $I non dimostra quindi che un file non sia stato eliminato.
• Limiti di dimensione. Il Cestino di ciascun volume ha una dimensione massima, modificabile dall'utente. Esplora file propone invece di eliminare definitivamente i file troppo grandi per il Cestino. L'impostazione è memorizzata per ogni utente in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volume\{volume GUID}, con i valori MaxCapacity (in MB) e NukeOnDelete (1 indica che il Cestino viene escluso per quel volume).
• Volumi rimovibili. I file eliminati tramite Esplora file da unità che Windows considera rimovibili, come la maggior parte delle unità flash USB, vengono normalmente eliminati definitivamente; i dischi USB che si identificano come fissi dispongono di un $Recycle.Bin come i volumi interni. Quando si esamina un'immagine USB, controllare anche la sua directory radice per individuare $Recycle.Bin e le cartelle dei SID.

Copie shadow del volume

Il servizio Copia shadow del volume (VSS) crea istantanee di un volume riferite a uno specifico istante. Le istantanee operano a livello di blocco e utilizzano il meccanismo copy-on-write: quando esiste un'istantanea e un blocco del volume attivo sta per essere sovrascritto, il contenuto precedente di quel blocco viene prima salvato in un'area di archiviazione differenziale. Un'istantanea è quindi costituita dal volume corrente più tutti i blocchi salvati da quando è stata creata. L'archivio si trova nella cartella nascosta System Volume Information alla radice del volume, in file i cui nomi contengono il GUID {3808876b-c176-4e48-b7ae-04046e6cc752}. Questi file non possono essere letti come file ordinari; devono essere analizzati con un parser.

Le istantanee vengono create da Ripristino configurazione di sistema (punti di ripristino), Windows Update e molti programmi di installazione, dai software di backup e manualmente: su Windows Server con vssadmin create shadow e sulle edizioni client con wmic shadowcopy call create Volume=C:\ (WMIC è assente per impostazione predefinita dalle installazioni pulite di Windows 11 24H2 ed è rimosso da 25H2 e versioni successive; utilizzare invece PowerShell Invoke-CimMethod -ClassName Win32_ShadowCopy -MethodName Create -Arguments @{Volume="C:\"}) oppure la classe WMI Win32_ShadowCopy. Per impostazione predefinita, un volume conserva al massimo 64 istantanee (valore configurabile). Lo spazio di archiviazione è limitato da una quota impostata con vssadmin resize shadowstorage e le istantanee meno recenti vengono eliminate al raggiungimento della quota o del limite numerico.

Protezione sistema (Ripristino configurazione di sistema) è spesso disabilitata per impostazione predefinita per l'unità di sistema in Windows 10 e 11. La sua attivazione dipende dal dispositivo, dalla modalità di installazione di Windows e dalla dimensione del disco. Verificare, senza mai dare nulla per scontato; molti sistemi moderni non dispongono di alcuna copia shadow.

Valore forense. Un'istantanea può fornire versioni precedenti di file successivamente modificati, file eliminati dopo l'istantanea, hive del registro precedenti (ad esempio, un NTUSER.DAT risalente a prima dell'eliminazione di una chiave) e registri eventi anteriori alla loro cancellazione. Confrontare ogni istantanea con il volume attivo e indicare per ogni elemento l'istantanea di provenienza e la relativa data e ora di creazione.

Accesso su un sistema in esecuzione. vssadmin list shadows elenca ogni istantanea con il relativo ID, la data e ora di creazione e il nome del dispositivo, ad esempio \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3. mklink /d C:\vss3 \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\ la rende accessibile come cartella. La barra rovesciata finale è obbligatoria.

Accesso in un'immagine. vshadowinfo di libvshadow elenca le istantanee di un volume (con -o che specifica l'offset in bytes del volume nell'immagine), mentre vshadowmount rende ciascuna di esse accessibile come file di volume grezzo (vss1, vss2 …), che può essere montato in sola lettura o elaborato con The Sleuth Kit. Arsenal Image Mounter e altri strumenti possono montare un'immagine con le relative istantanee su Windows.

Eliminazione da parte degli attaccanti. I ransomware e gli intrusi eseguono comunemente vssadmin delete shadows /all /quiet o wmic shadowcopy delete per impedire il recupero. L'eliminazione stessa lascia tracce, come eventi di creazione dei processi, file Prefetch e cronologia dei comandi; il modulo 7 le tratta.

Un'acquisizione di triage copia file selezionati con i loro percorsi originali e di solito non include le copie shadow, che non sono file ordinari. Nelle indagini basate su acquisizioni di triage, ci si deve aspettare di lavorare con il Cestino molto più spesso che con VSS.

Confronto tra i due

Focus sull'esame: Prepararsi a decodificare manualmente un file $I o a verificare l'output di uno strumento: il percorso originale, la dimensione e la data e ora di eliminazione in UTC, il SID dell'utente che ha eseguito l'eliminazione e l'hash del file $R corrispondente. Conoscere le strutture delle versioni 1 e 2 e come riconoscerle, nonché le tracce lasciate dal ripristino, dallo svuotamento e da Shift+Delete. Per VSS, conoscere il funzionamento delle istantanee, dove sono memorizzate, come elencarle e accedervi e perché di solito sono assenti da un'acquisizione di triage.

Punti chiave

• Ogni volume fisso dispone di un proprio $Recycle.Bin, con una sottocartella per ogni SID utente; ogni elemento eliminato diventa una coppia $I (metadati) e $R (contenuto) con gli stessi 6 caratteri casuali.
• $I versione 2: versione a 0, dimensione a 8, data e ora di eliminazione FILETIME (UTC) a 16, lunghezza del percorso a 24, percorso UTF-16LE a 28. La versione 1 ha una dimensione fissa di 544 bytes con il percorso a 24.
• Il ripristino rinomina $R riportandolo al percorso originale ed elimina $I; lo svuotamento elimina entrambi e i loro record MFT e cluster diventano non allocati e possono essere recuperabili.
• Shift+Delete, l'eliminazione da riga di comando e i file di dimensioni eccessive escludono il Cestino, quindi l'assenza di $I non dimostra che un file non sia mai stato eliminato.
• Le istantanee VSS sono istantanee a livello di blocco basate su copy-on-write in System Volume Information; possono conservare file, hive e registri precedenti, ma sono spesso disabilitate o eliminate dagli attaccanti.
• Le acquisizioni di triage di solito includono il Cestino ma non le copie shadow.