TL;DR. Os atacantes lutam contra a ShimCache sobretudo evitando clean shutdowns para que a cache nunca seja descarregada. Edições diretas ao registo costumam deixar o blob malformado. Detete adulteração através de caches anormalmente curtas, ausência de binários do Windows sempre presentes, tamanhos de entrada malformados ou divergência entre memória e disco.
A cache é mais difícil de adulterar do que a maioria dos artefactos do Windows. Não impossível. Após alguns incidentes deixamos de nos surpreender com o que os atacantes tentam e começamos a surpreender-nos com a frequência com que deixam impressões digitais. Eis o catálogo de técnicas que vi de facto, e o que cada uma deixa para trás.
O que os atacantes realmente tentam
1. Reboot forçado antes do flush. A anti-forense mais limpa contra a cache é nunca dar ao Windows a oportunidade de a escrever. Force o corte de energia, ou mate a VM ao nível do hipervisor, e a ShimCache em memória dessa sessão simplesmente perde-se. A hive em disco mantém o que tiver sido descarregado no clean shutdown anterior. Este é, de longe, o padrão mais comum em casos de ransomware. Veja quando a cache é escrita para o mecanismo.
2. Edições diretas ao registo do blob. Um atacante ao nível SYSTEM pode sobrescrever HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Em teoria isso remove entradas específicas. Na prática a disposição binária é não-trivial ao ponto de edições à mão deixarem o blob malformado ou a contagem de entradas sem nexo.
3. Substituição offline da hive. Se o atacante conseguir derrubar o sistema, pode trocar a hive SYSTEM por inteiro. Raro fora de trabalho de nation-state mas acontece. O registry parser pode mostrar-lhe se os timestamps e a estrutura da hive SYSTEM são consistentes com os restantes artefactos do host.
4. Timestomping do binário. Como a cache guarda o mtime $STANDARD_INFORMATION do ficheiro, um atacante que faça timestomping do binário antes do Windows o examinar desloca o timestamp em cache. A cache não está a mentir; a metadata do ficheiro que capturou já tinha sido adulterada. Cruze com o atributo $FILE_NAME da MFT, que é mais difícil de timestompar.
5. Apagar artefactos corroborativos. Atacantes que aprendem o que a ShimCache faz costumam também limpar AmCache, Prefetch, EVTX e a reciclagem, deixando a ShimCache como testemunha solitária e esperando que seja descartada pelas razões no artigo de prova de execução.
Indícios de deteção
Quando suspeitar de adulteração, procure:
- Cache anormalmente curta. O Windows enche a cache até cerca de 1024 entradas em uso normal. Um blob com um punhado de entradas num sistema que está ligado há dias é um sinal forte de adulteração.
- Falta de entradas sempre presentes. Vários binários do Windows aparecem com fiabilidade em quase todas as ShimCache, consoante a versão: componentes de shell, helpers de tarefas agendadas, ferramentas de atualização do OS. A sua ausência numa estação de trabalho que tenha sido usada é suspeita.
- Tamanhos de entrada malformados. Um blob que falha a análise a meio, com o resto do buffer a zeros ou cheio de lixo, é um indicador clássico de edição desajeitada. O Shimcache Parser expõe isso como um erro explícito.
- Divergência entre memória e disco. Compare a cache extraída de um dump de RAM com a hive em disco (guia de extração). Entradas presentes em memória mas ausentes em disco podem significar um reboot forçado. Entradas em disco que contradizem a memória (caminhos ou mtimes diferentes para o mesmo slot) sugerem que alguém escreveu na hive.
- Inconsistência AmCache vs ShimCache. A AmCache mostra um binário executado mas a ShimCache está vazia para esse ficheiro. Pergunte porquê. Atacantes que limpam a ShimCache esquecem-se frequentemente da AmCache.
- Pegadas de ferramentas anti-forense. Procure em Prefetch, Sysmon Event ID 1 e no USN journal evidência de
reg.exe, PowerShellRemove-ItemPropertyou editores de hive de terceiros a correr na janela relevante.
O que isto diz aos investigadores
Algumas regras práticas que aplico a cada relatório:
- Trate uma ShimCache vazia ou quase vazia como evidência. Não como ausência de evidência. Documente-o explicitamente.
- Tire um dump de RAM quando puder. Apanha frequentemente o que a hive perdeu.
- Corrobore sempre com AmCache e Prefetch. Veja a referência de artefactos. Três artefactos são muito mais difíceis de apagar de forma consistente do que um.
- Não afirme "o atacante limpou a ShimCache" a menos que possa mostrar o que foi limpo. Aponte para falhas na contagem de entradas, binários de baseline em falta, ou divergência memória vs disco.
Leitura adicional
Windows.Registry.AppCompatCachedo Velociraptor, recolha à escala para detetar anomalias.- Windows 10/11 AppCompatCache deep dive no Ø Security, útil para compreender que campos um blob adulterado teria de falsificar.
- ShimCache & AmCache forensic analysis de Mehrnoush, estudos de caso incluindo cenários de adulteração.
- MITRE ATT&CK T1070 Indicator Removal, contexto para o que atacantes bem-recursados fazem em relação a artefactos como este.