Compreender a ShimCache do Windows (AppCompatCache)

4 min de leitura

A maioria dos analistas conhece a ShimCache da mesma forma: alguém na equipa diz "extrai a AppCompatCache, vê se o binário está lá" e funciona com frequência suficiente para que o artefacto ganhe uma reputação que não merece inteiramente. Já passei horas suficientes a discutir linhas de ShimCache em revisões de caso para saber que este artefacto vale o seu peso, mas apenas se o tratar pelo que realmente é. Não é um log de execução. Não é uma auditoria de processos. É uma lista de executáveis que o Windows observou com atenção suficiente para decidir se um shim de compatibilidade deveria ser aplicado.

Esse é o enquadramento. O resto é mecânica.

O que a cache regista de facto

A Application Compatibility Cache, quase sempre abreviada para ShimCache ou AppCompatCache, reside na hive SYSTEM e guarda até cerca de 1024 entradas no Windows moderno. Cada entrada contém o caminho completo de um executável, o $STANDARD_INFORMATION last-modified do ficheiro e (em versões mais antigas) uma flag a indicar se o binário foi efetivamente executado. Essa flag desapareceu no Windows 10 e 11. Faça de conta que nunca existiu.

O Windows reconstrói a cache em memória a cada arranque e só a escreve em disco num clean shutdown. Um BSOD, um reset forçado ou a morte de uma VM ao nível do hipervisor consome quaisquer entradas que estivessem na memória volátil. Esse simples facto explica metade das histórias "mas eu vi o binário em produção" que se transformam em chamados do tipo "a hive em disco não mostra nada".

Onde reside

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache

Esse AppCompatCache final é um valor, não uma subchave. O seu conteúdo é um único blob binário cuja disposição mudou em cada grande lançamento do Windows: XP, 7, 8, 8.1 e a família 10/11 usam todos esquemas diferentes. Analisar offline significa extrair a hive SYSTEM (juntamente com os logs de transação SYSTEM.LOG1 e SYSTEM.LOG2) e descodificar o blob contra a versão correta. Esta ferramenta analisa esse único ficheiro da hive SYSTEM no seu browser, sem upload. Não reproduz os logs: se a hive estiver dirty, reproduza-os primeiro com o rla.exe de Eric Zimmerman.

Porque é que os investigadores recorrem a ela

A ShimCache compensa porque sobrevive. Um atacante pode largar um binário, executá-lo, apagá-lo, limpar a pasta Prefetch e a ShimCache continua a guardar o caminho completo. Isto torna-a uma forte testemunha de existência para:

  • Malware que já foi apagado do disco.
  • Binários de sistema renomeados usados como payloads living-off-the-land.
  • Ferramentas preparadas a partir de uma partilha de rede que ninguém chegou a copiar localmente.

Combine os dados de caminho com a AmCache para atribuição por hash e pode pivotar para threat intel mesmo quando o ficheiro já desapareceu há muito.

Três coisas que apanham as pessoas desprevenidas

  1. O timestamp é o mtime do ficheiro, não o momento em que o programa foi executado. O timestomping altera o que a cache regista.
  2. Uma entrada não é prova de execução. A cache do Win10/11 não tem flag de execução nenhuma.
  3. A cache só descarrega num clean shutdown. Reinícios forçados destroem silenciosamente as entradas recentes.

Trate cada linha como uma hipótese. Corrobore com Prefetch, AmCache, EVTX / Sysmon ou hives do registo antes de escrever algo definitivo num relatório.

Por onde continuar

O resto do blogue está organizado em dois grupos.

Compreender a ShimCache

Usar em investigações