O que o timestamp da ShimCache realmente significa (e o que não significa)

TL;DR. O timestamp da ShimCache é o tempo de última modificação $STANDARD_INFORMATION do executável, copiado do sistema de ficheiros. Não é a hora em que correu. Não é a hora em que foi posto em cache. Trate-o como uma propriedade do ficheiro, nunca como um evento numa timeline.

O erro mais comum na análise de ShimCache é ler a coluna de timestamp como "quando isto correu". Não é. Já vi analistas pôr essa interpretação à frente de clientes e reguladores, e vi o relatório ser desfeito em revisão por qualquer pessoa com conhecimento prático de NTFS. Não seja esse analista.

O que o timestamp realmente é

Cada entrada guarda o tempo da última modificação $STANDARD_INFORMATION do ficheiro (SI mtime), tal como estava no volume NTFS no momento em que o Windows registou a entrada. Cópia direta de um atributo do sistema de ficheiros. Nada diz sobre criação de processo, carga de módulo, ou shutdown.

Três consequências imediatas:

Um binário compilado no ano passado e executado hoje mostra a data do ano passado.
Um ficheiro copiado com uma ferramenta que preserva timestamps mantém o seu mtime original, não a hora da cópia.
Dois hosts a correr o mesmo binário assinado mostrarão o mesmo timestamp, porque é uma propriedade do ficheiro, não de nenhuma máquina.

Porque não é o tempo de execução

O Windows adiciona uma entrada na cache quando examina um ficheiro por razões de compatibilidade aplicacional. Frequentemente, mas nem sempre, coincidente com execução. Mesmo quando coincide, a cache guarda o mtime do ficheiro, não o momento do exame. Portanto, o timestamp responde a "quando foi este ficheiro modificado pela última vez?" e nunca a "quando é que correu?". A distinção execução vs existência está coberta em profundidade em a ShimCache prova que um programa foi executado.

Se precisa de um tempo de execução real, precisa de tempos de execução do Prefetch, primeira execução da AmCache, Security 4688, ou Sysmon Event ID 1. A cache não lhe dá isso.

Quando o timestamp ainda é valioso

É fraco como tempo de evento mas forte como âncora de identidade:

Deteção de adulteração. Se um binário de sistema como o svchost.exe mostra um mtime que não coincide com o nível de patch do host, esse ficheiro foi substituído. Cruze com o atributo $FILE_NAME da MFT, que é mais difícil de timestompar.
Correlação de builds. Malware compilado numa campanha partilha frequentemente um cluster de mtime entre vítimas. Útil para agrupar incidentes ao mesmo ator.
Ordenação, com cuidado. Dentro de um host, as entradas são guardadas por ordem aproximada de inserção. A ordem é mais fiável do que os timestamps absolutos para sequenciar atividade. Mas ordem não é tempo, e a sequência de inserção reinicia no boot.

Como os atacantes abusam dele

Como é apenas um atributo do sistema de ficheiros, é trivialmente forjável. Timestomping (definir um mtime para 2009-07-14, a data clássica do kernel32.dll) faz um dropper misturar-se com ficheiros de sistema do Windows. A cache regista fielmente o valor stomped, portanto um timestamp limpo de 2009 num caminho em C:\Users\Public\ é por si só uma bandeira vermelha. Os padrões anti-forense estão catalogados em conseguem os atacantes limpar a ShimCache.

O atributo $FILE_NAME da MFT costuma reter o verdadeiro tempo de criação mesmo depois de $STANDARD_INFORMATION ser stomped. O MFT parser percorre a comparação. O USN journal também captura o evento de criação original na maioria dos casos.

Usá-lo corretamente numa timeline

Ponha o mtime da ShimCache numa coluna separada das horas de eventos. Nunca o funda na timeline principal como se fosse uma ação. Corrobore a sequência com artefactos que tenham horas de evento: tempos de execução do Prefetch, instalação / primeira execução da AmCache, Security 4688, Sysmon Event ID 1. A referência cruzada completa está em Prefetch, AmCache, ShimCache: uma referência rápida.

Para inspecionar os valores brutos por si próprio, largue uma hive SYSTEM no Shimcache Parser. Mostra o mtime exato armazenado por entrada, no seu browser, sem nada ser enviado.

Leitura adicional

Caching Out the Val da Mandiant, o artigo original que definiu o uso forense do artefacto.
AppCompatCacheParser de Eric Zimmerman, parser de referência cuja saída usa a mesma semântica de mtime.