TL;DR. Atacantes combatem o ShimCache principalmente evitando desligamentos limpos (para que ele nunca seja gravado). Edições diretas no registro normalmente deixam o blob malformado. Detecte adulteração via caches anormalmente curtos, binários sempre-presentes do Windows ausentes, tamanhos de entrada malformados, ou divergência memória/disco.
O ShimCache é mais difícil de adulterar que a maioria dos artefatos do Windows, mas não é intocável. Este post percorre o que atacantes realmente tentam, por que a maioria desses tentativas deixa marcas, e como detectar adulteração durante a análise.
O kit anti-forense do atacante
1. Reinício forçado antes do flush. A «anti-forense» mais limpa contra o ShimCache é nunca dar ao Windows a chance de gravá-lo. Se o atacante força um corte de energia (ou mata uma VM no nível do hypervisor), o ShimCache em memória daquela sessão simplesmente se perde. A hive em disco ainda mantém o que foi gravado no anterior desligamento limpo. Veja quando o cache é gravado para o mecanismo.
2. Edição direta do blob de valor no registro. Um atacante privilegiado pode sobrescrever o valor HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Em teoria, isso permite remover entradas específicas — na prática, o layout binário é não-trivial o suficiente para que edições ruins normalmente deixem o blob malformado.
3. Substituição offline da hive SYSTEM. Se o atacante consegue colocar o sistema offline, pode trocar o arquivo de hive. Raro em intrusões oportunistas, aparece em casos estatais.
4. Time stomping do binário. Como o ShimCache armazena o mtime $STANDARD_INFORMATION do arquivo, um atacante que adultera os timestamps do binário antes do Windows examiná-lo desloca o carimbo de tempo cacheado. O ShimCache em si não está mentindo — os metadados que ele capturou já estavam adulterados.
5. Apagamento de AmCache e Prefetch. Atacantes que conhecem os artefatos corroborantes frequentemente os apagam também, deixando o ShimCache como testemunha solitária e esperando que seja descartado pelas razões do nosso post sobre prova de execução.
Sinais de detecção
Quando você suspeita de adulteração, procure:
- ShimCache anormalmente curto. O Windows enche o cache até ~1.024 entradas com uso normal. Um blob com apenas algumas entradas em um sistema rodando há dias é um sinal forte de adulteração.
- Entradas sempre-presentes ausentes. Vários binários do Windows aparecem confiavelmente em quase todo ShimCache (dependendo da versão: shell, helpers de tarefas agendadas, ferramentas do Windows Update). Sua ausência em uma estação usada é suspeita.
- Tamanhos de entrada malformados. Um blob que falha no parsing no meio do caminho, com o resto do buffer zerado ou preenchido com ruído, é indicador clássico de edição desajeitada. O Shimcache Parser vai elevar isso como erro explícito.
- Divergência memória / disco. Compare o ShimCache extraído da memória (guia) com a hive em disco. Entradas presentes em memória mas ausentes em disco podem significar reinício forçado — mas entradas em disco que contradizem a memória (caminhos ou mtimes diferentes para o mesmo slot) sugerem que alguém escreveu na hive.
- AmCache e ShimCache desencontrados. Se AmCache mostra um binário executado mas o ShimCache que deveria também ter a entrada está vazio, pergunte por quê. Apagamentos do ShimCache que não tocaram AmCache são comuns porque atacantes nem sempre percebem que AmCache existe.
O que isso diz aos investigadores
Algumas regras práticas:
- Trate um ShimCache vazio ou quase-vazio como evidência, não como ausência de evidência. Documente.
- Puxe a imagem de memória quando puder. Frequentemente captura o que a hive perdeu.
- Sempre corrobore com AmCache e Prefetch (referência). Três artefatos são muito mais difíceis de apagar consistentemente do que um só.
- Não afirme «o atacante apagou o ShimCache» sem poder mostrar o que foi apagado — aponte lacunas na contagem de entradas, binários de base ausentes, ou divergência memória/disco.
Leitura adicional
Windows.Registry.AppCompatCachedo Velociraptor — para coletar em escala e identificar anomalias.- Windows 10/11 AppCompatCache deep dive (Ø Security) — útil para entender quais campos um blob adulterado teria que falsificar.
- ShimCache & AmCache forensic analysis (Mehrnoush) — estudos de caso incluindo cenários de adulteração.