TL;DR. La marca temporale dello ShimCache è la data di ultima modifica $STANDARD_INFORMATION dell'eseguibile, copiata dal file system — non l'ora di esecuzione né quella di cache. Trattala come una proprietà del file, mai come un evento su una linea temporale.
L'errore più comune nell'analisi dello ShimCache è leggere la colonna della marca temporale come «quando è stato eseguito». Non lo è. Questa lettura errata ha già messo orari sbagliati in veri report di incidente. Questo articolo spiega con precisione cos'è quel valore e come usarlo senza trarre una conclusione errata.
Cos'è davvero la marca temporale
Ogni voce ShimCache memorizza la data di ultima modifica (mtime di $STANDARD_INFORMATION) dell'eseguibile, com'era sul volume NTFS nel momento in cui Windows ha registrato la voce. È una copia diretta di un attributo del file system. Non dice nulla sulla creazione del processo, sul caricamento del modulo o sullo spegnimento.
Tre conseguenze immediate:
- Un binario compilato l'anno scorso ed eseguito oggi mostra la data dell'anno scorso.
- Un file copiato con uno strumento che preserva le marche temporali mantiene il suo mtime originale, non l'ora di copia.
- Due host che eseguono lo stesso binario firmato mostreranno la stessa marca temporale — perché è una proprietà del file, non della macchina.
Perché non è l'ora di esecuzione
Windows aggiunge una voce ShimCache quando esamina un file per ragioni di compatibilità applicativa — il che spesso, ma non sempre, coincide con l'esecuzione. Anche quando coincide, la cache memorizza il mtime del file, non l'istante dell'esame. La marca temporale risponde quindi a «quando è stato modificato l'ultima volta questo file?» e mai a «quando è stato eseguito?». La distinzione esecuzione/esistenza è trattata in dettaglio in Lo ShimCache prova che un programma è stato eseguito?.
Quando la marca temporale resta utile
Debole come ora di evento, è solida come àncora di identità:
- Rilevamento di manomissioni. Se un binario di sistema come
svchost.exemostra un mtime incoerente con il livello di patch dell'host, quel file è stato sostituito. - Correlazione di build. Il malware compilato in una campagna condivide spesso un cluster di mtime tra le vittime — utile per raggruppare.
- Ordinamento, con cautela. Su uno stesso host le voci sono memorizzate in un ordine d'inserimento approssimativo. L'ordine è più affidabile delle marche assolute per sequenziare l'attività.
Come ne abusano gli attaccanti
Essendo solo un attributo del file system, è banalmente falsificabile. Il timestomping (ad esempio fissare un mtime al 2009-07-14, la data classica di kernel32.dll) fa mimetizzare un dropper tra i file di sistema. Lo ShimCache registra fedelmente il valore alterato — quindi una marca «pulita» del 2009 su un percorso in C:\Users\Public\ è di per sé un campanello d'allarme. Gli schemi anti-forensi sono catalogati in Gli attaccanti possono cancellare lo ShimCache?.
Usarla correttamente in una linea temporale
Metti il mtime dello ShimCache in una colonna separata dagli orari degli eventi — non fonderlo mai nella linea temporale principale come se fosse un'azione. Conferma la sequenza con artefatti che davvero portano orari di evento: orari di esecuzione di Prefetch, installazione/primo avvio di AmCache, Security 4688, Sysmon 1. Il riferimento incrociato completo è in Prefetch, AmCache, ShimCache: riferimento rapido.
Per ispezionare tu stesso i valori grezzi, trascina una hive SYSTEM nello Shimcache Parser — mostra il mtime esatto memorizzato per ogni voce, nel tuo browser, senza caricare nulla.
Approfondimenti
- Mandiant: leveraging the ShimCache — lo studio originale che ha definito l'uso forense dell'artefatto.
- AppCompatCacheParser di Eric Zimmerman — parser di riferimento il cui output usa la stessa semantica di mtime.