TL;DR. Lo ShimCache vive in memoria. L'hive SYSTEM su disco contiene solo le voci scaricate all'ultimo shutdown pulito. Per recuperare le voci della sessione attiva da un host in esecuzione o crashato, lancia windows.shimcachemem di Volatility 3 contro un dump RAM, oppure tirale live con l'artefatto Windows.Registry.AppCompatCache di Velociraptor.
La cache vive in memoria volatile mentre Windows gira. Viene scritta nell'hive SYSTEM solo a shutdown pulito. Ciò significa che un'immagine di memoria è spesso l'unico posto in cui trovare voci dello ShimCache della sessione corrente, che sono esattamente le voci più probabilmente rilevanti per un incidente attivo. Il post sul timing di memorizzazione copre il perché.
Quando la copia in memoria conta più del disco
Vuoi la cache in memoria quando:
- L'host non è stato spento in modo pulito dall'incidente. La maggior parte dei reboot duri, BSOD e power-off forzati lasciano lo ShimCache su disco obsoleto.
- Sospetti anti-forense. Un attaccante che ha modificato l'hive su disco potrebbe non aver toccato la copia in memoria, che viene ricostruita ad ogni sessione. Vedi rilevamento anti-forense.
- Hai bisogno di voci che sono state evicte dall'hive su disco all'ultimo flush. Il cap di 1.024 voci ruota fuori quelle vecchie, ma possono essere ancora in memoria in condizioni specifiche.
Con Volatility 2
Il plugin classico è shimcachemem. Contro un'immagine di memoria da XP a Win10:
vol.py -f memory.raw --profile=Win10x64_19041 shimcachemem
Cammina le strutture AppCompatCache dentro la rappresentazione in memoria dell'hive SYSTEM e stampa righe (mtime, path) allo stesso modo di un parser offline. Il sorgente del plugin è nel repo Volatility 2.
Con Volatility 3
Volatility 3 lo fornisce come windows.shimcachemem:
vol -f memory.raw windows.shimcachemem
Niente più selezione di profilo. Vol 3 capisce l'OS automaticamente. I docs di Volatility 3 documentano il plugin insieme al resto del set di artefatti Windows. Finché hai aperto il dump, tanto vale tirare anche processi, connessioni di rete e liste di moduli. Il parser RAM copre il workflow più ampio di memory forensics.
Con Velociraptor
Per raccogliere su scala invece di analizzare un singolo dump, l'artefatto Windows.Registry.AppCompatCache di Velociraptor legge lo ShimCache in memoria direttamente da un endpoint in esecuzione tramite la vista registro live. Stessa cache che l'OS avrebbe scaricato allo shutdown, senza aspettare lo shutdown.
Combinare le due viste
In pratica spesso avrai entrambe:
- La cache in memoria da Volatility o Velociraptor.
- La cache su disco dall'hive SYSTEM sullo stesso host.
La copia in memoria è un superset della copia su disco in ogni momento in cui non è avvenuto uno shutdown pulito. Ma la copia su disco può includere voci già evicte dalla memoria dopo un lungo uptime. Tira entrambe, deduplica per (path, mtime) e dai l'unione in pasto al tuo workflow di hunting.
Se le due viste non concordano su percorsi o timestamp per lo stesso slot, è un indicatore di manipolazione. Vedi anti-forense.
Prossimi passi utili
Una volta che hai le voci:
- Usa lo Shimcache Parser per un triage offline veloce di un hive estratto. Gira nel tuo browser, senza upload.
- Vedi la referenza del formato binario se stai decodificando il blob grezzo da solo.
- Vedi prova di esecuzione prima di rivendicare che una voce recuperata dalla memoria significhi che un programma è stato eseguito.
- Esegui carving su pagefile.sys se sospetti che la cache sia stata in parte ripulita sia dalla memoria sia dal disco; frammenti a volte sopravvivono nello swap.
Letture aggiuntive
- Documentazione Volatility 3. framework moderno di memory forensics.
- Volatility Foundation su GitHub. sorgente dei plugin incluso
shimcachemem. - Velociraptor
Windows.Registry.AppCompatCache. raccolta su sistema vivo.