TL;DR. A marca de tempo do ShimCache é a data de última modificação $STANDARD_INFORMATION do executável, copiada do sistema de arquivos — não a hora de execução nem a de cache. Trate-a como uma propriedade do arquivo, nunca como um evento numa linha do tempo.
O erro mais comum na análise de ShimCache é ler a coluna da marca de tempo como «quando isto rodou». Não é. Essa leitura equivocada já colocou horários errados em relatórios de incidente reais. Este artigo explica com precisão o que é esse valor e como usá-lo sem tirar uma conclusão errada.
O que a marca de tempo realmente é
Cada entrada ShimCache armazena a data de última modificação (mtime do $STANDARD_INFORMATION) do executável, como estava no volume NTFS no momento em que o Windows registrou a entrada. É uma cópia direta de um atributo do sistema de arquivos. Não diz nada sobre criação de processo, carga de módulo ou desligamento.
Três consequências imediatas:
- Um binário compilado no ano passado e executado hoje mostra a data do ano passado.
- Um arquivo copiado com uma ferramenta que preserva marcas de tempo mantém o seu mtime original, não a hora da cópia.
- Dois hosts executando o mesmo binário assinado mostrarão a mesma marca de tempo — porque é uma propriedade do arquivo, não da máquina.
Por que não é a hora de execução
O Windows adiciona uma entrada ShimCache quando examina um arquivo por razões de compatibilidade de aplicativos — o que muitas vezes, mas nem sempre, coincide com a execução. Mesmo quando coincide, o cache armazena o mtime do arquivo, não o instante do exame. Assim, a marca de tempo responde a «quando este arquivo foi modificado pela última vez?» e nunca a «quando ele rodou?». A distinção execução/existência é tratada a fundo em O ShimCache prova que um programa foi executado?.
Quando a marca de tempo ainda é valiosa
Fraca como hora de evento, é forte como âncora de identidade:
- Detecção de adulteração. Se um binário de sistema como
svchost.exemostra um mtime que não bate com o nível de patches do host, esse arquivo foi substituído. - Correlação de build. Malware compilado numa campanha costuma compartilhar um agrupamento de mtime entre vítimas — útil para agrupar.
- Ordenação, com cuidado. Dentro de um mesmo host, as entradas são armazenadas numa ordem de inserção aproximada. A ordem é mais confiável que as marcas absolutas para sequenciar a atividade.
Como os atacantes abusam dela
Como é apenas um atributo do sistema de arquivos, é trivialmente falsificável. O timestomping (por exemplo, fixar um mtime em 2009-07-14, a data clássica do kernel32.dll) faz um dropper se camuflar entre os arquivos do sistema. O ShimCache registra fielmente o valor adulterado — então uma marca «limpa» de 2009 num caminho dentro de C:\Users\Public\ é por si só um sinal de alerta. Os padrões antiforenses estão catalogados em Os atacantes podem apagar o ShimCache?.
Usá-la corretamente numa linha do tempo
Coloque o mtime do ShimCache numa coluna separada das horas de evento — nunca o funda na linha do tempo principal como se fosse uma ação. Corrobore o sequenciamento com artefatos que de fato carregam horas de evento: horas de execução do Prefetch, instalação/primeira execução do AmCache, Security 4688, Sysmon 1. A referência cruzada completa está em Prefetch, AmCache, ShimCache: referência rápida.
Para inspecionar você mesmo os valores brutos, solte uma colmeia SYSTEM no Shimcache Parser — ele mostra o mtime armazenado exato por entrada, no seu navegador, sem enviar nada.
Leitura adicional
- Mandiant: leveraging the ShimCache — o estudo original que definiu o uso forense do artefato.
- AppCompatCacheParser de Eric Zimmerman — parser de referência cuja saída usa a mesma semântica de mtime.