TL;DR. A ShimCache vive em memória. A hive SYSTEM em disco contém apenas entradas descarregadas no último clean shutdown. Para recuperar as entradas da sessão ativa de um host em execução ou que tenha caído, execute o windows.shimcachemem do Volatility 3 contra um dump de RAM, ou puxe ao vivo com o artefacto Windows.Registry.AppCompatCache do Velociraptor.
A cache vive em memória volátil enquanto o Windows corre. Só é escrita para a hive SYSTEM em clean shutdown. Isso significa que uma imagem de memória é muitas vezes o único sítio onde encontra entradas da ShimCache da sessão atual, que são precisamente as entradas com maior probabilidade de importar num incidente ativo. O artigo sobre tempos de armazenamento explica porquê.
Quando a cópia em memória importa mais do que a do disco
Quer a cache em memória quando:
- O host não foi limpamente desligado desde o incidente. A maioria dos reboots forçados, BSODs e cortes de energia deixam a ShimCache em disco desatualizada.
- Suspeita de anti-forense. Um atacante que editou a hive em disco pode não ter tocado na cópia em memória, que é reconstruída a cada sessão. Veja deteção de anti-forense.
- Precisa de entradas que foram desalojadas da hive em disco no último flush. O cap de 1024 entradas roda as antigas para fora, mas podem ainda estar em memória em condições específicas.
Com o Volatility 2
O plugin clássico é o shimcachemem. Contra uma imagem de memória de XP a Win10:
vol.py -f memory.raw --profile=Win10x64_19041 shimcachemem
Percorre as estruturas AppCompatCache dentro da representação em memória da hive SYSTEM e imprime linhas (mtime, path) da mesma forma que um parser offline faria. A fonte do plugin está no repositório do Volatility 2.
Com o Volatility 3
O Volatility 3 entrega isto como windows.shimcachemem:
vol -f memory.raw windows.shimcachemem
Sem mais seleção de perfil. O Vol 3 descobre o OS automaticamente. A documentação do Volatility 3 documenta o plugin juntamente com o resto do conjunto de artefactos do Windows. Já que tem o dump aberto, pode também puxar processos, conexões de rede e listas de módulos. O RAM parser cobre o workflow mais amplo de forense de memória.
Com o Velociraptor
Para recolher à escala em vez de analisar um único dump, o artefacto Windows.Registry.AppCompatCache do Velociraptor lê a ShimCache em memória diretamente de um endpoint em execução através da vista de registo viva. A mesma cache que o OS teria descarregado no shutdown, sem esperar pelo shutdown.
Combinar as duas vistas
Na prática terá frequentemente as duas:
- A cache em memória pelo Volatility ou Velociraptor.
- A cache em disco a partir da hive SYSTEM no mesmo host.
A cópia em memória é um superconjunto da cópia em disco em qualquer momento em que não tenha ocorrido um clean shutdown. Mas a cópia em disco pode incluir entradas que já foram desalojadas da memória após uptime longo. Puxe as duas, deduplique por (path, mtime), e alimente a união no seu workflow de caça.
Se as duas vistas discordarem em caminhos ou timestamps para o mesmo slot, isso é um indicador de adulteração. Veja anti-forense.
Próximos passos úteis
Uma vez que tenha as entradas:
- Use o Shimcache Parser para triagem offline rápida de uma hive extraída. Corre no browser, sem upload.
- Veja a referência do formato binário se está a descodificar o blob bruto à mão.
- Veja prova de execução antes de afirmar que uma entrada recuperada da memória significa que um programa correu.
- Faça carving do pagefile.sys se suspeita que a cache foi parcialmente apagada de memória e disco; fragmentos por vezes sobrevivem no swap.
Leitura adicional
- Documentação do Volatility 3, framework moderno de forense de memória.
- Volatility Foundation no GitHub, fonte de plugins incluindo
shimcachemem. - Velociraptor
Windows.Registry.AppCompatCache, recolha em sistema vivo.