TL;DR. Sì. Una voce dello ShimCache persiste nel registro indipendentemente dal fatto che il file esista ancora su disco. Cancellare il binario non cancella la sua voce ShimCache. È esattamente per questo che l'artefatto è così utile per beccare strumenti che un attaccante ha rilasciato, usato e ripulito.
La cache memorizza un percorso e un timestamp in un valore di registro. Quel valore non ha alcun collegamento di ritorno al file system. Quando NTFS libera l'eseguibile, i dati del registro non si muovono. Che è il motivo intero per cui vale la pena tirare l'artefatto, e il motivo intero per cui a volte è l'unica prova sopravvissuta di un'intrusione.
Risposta breve: sì
Lo ShimCache memorizza un percorso più la mtime $STANDARD_INFORMATION del file dentro il valore a HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Quel record non ha alcun collegamento di ritorno al file system. Quando l'eseguibile viene cancellato, NTFS libera il file. Il valore di registro rimane intatto. La voce resta fino a che non viene evicta da voci più nuove (la cache contiene fino a ~1.024) o il valore stesso viene ripulito.
Quindi un binario che un attaccante ha rilasciato in C:\Users\Public\, eseguito e cancellato dieci minuti dopo può comunque lasciare una voce ShimCache pulita e leggibile che mostra il percorso completo che occupava.
Perché questo è potente sul piano forense
Le voci di file cancellati sono spesso l'unica prova sopravvissuta del tooling dell'attaccante:
- Un
mimikatz.exerinominato cancellato dopo il furto di credenziali. - Un archivio di staging rimosso dopo l'esfiltrazione.
- Un dropper che si è autocancellato dopo aver installato un payload.
- Una copia di
7z.exeusata per impacchettare i dati prima del trasferimento.
Il file è sparito. Il percorso della cache ti dice che è esistito, dove, e (via il timestamp di ultima modifica) lo lega a una build. È la spina dorsale di cacciare malware con lo ShimCache e delle indagini ransomware, dove gli attaccanti ripuliscono i loro strumenti di routine.
Incrocia con la MFT e il journal USN. Se il journal porta ancora la sequenza create-then-delete, hai un'ancora pulita per la timeline. Il cestino quasi mai li contiene (lo bypassano) ma controlla comunque.
Quanto a lungo sopravvive una voce di file cancellato?
Si applicano due limiti:
- Eviction. La cache è limitata a circa 1.024 voci. Su un host trafficato, una forte attività di eseguibili può spingere fuori voci vecchie. Su un server tranquillo può sopravvivere mesi.
- Timing del flush. Le nuove voci persistono nell'hive solo a uno shutdown pulito. Se l'host non è stato spento dalla cancellazione, la voce sopravvissuta può essere solo in memoria. Tirala da un dump RAM, vedi la guida all'estrazione dalla memoria. Il modello di memorizzazione e flush è trattato in dove è memorizzato lo ShimCache.
Cosa non dimostra
Una voce di file cancellato dimostra che il file è esistito e è stato esaminato su quell'host. Non dimostra che il file sia stato eseguito, e non ti dice quando è stato cancellato. Il timestamp è la mtime del file, non un tempo di cancellazione. Trattalo come un forte testimone di esistenza e conferma l'esecuzione con Prefetch o AmCache. Vedi lo ShimCache dimostra l'esecuzione?.
Per controllare quali voci su un hive puntano a file che non esistono più, parsalo con lo Shimcache Parser e incrocia i percorsi con il file system vivo (o un'immagine forense). Tutto gira in locale nel tuo browser.
Letture aggiuntive
- Caching Out the Val di Mandiant. l'argomento per lo ShimCache come testimone di strumenti cancellati.
- Poster SANS DFIR sull'esecuzione di programmi. dove si colloca lo ShimCache tra le prove di esecuzione.