TL;DR. Sim. Uma entrada na ShimCache persiste no registo independentemente de o ficheiro ainda existir em disco. Apagar o binário não apaga a sua entrada na ShimCache. É exatamente por isso que o artefacto é tão útil para apanhar ferramentas que um atacante largou, usou e limpou.
A cache guarda um caminho e um timestamp num valor de registo. Esse valor não tem ligação de volta ao sistema de ficheiros. Quando o NTFS liberta o executável, os dados do registo não se mexem. É inteiramente por isso que vale a pena extrair o artefacto, e inteiramente por isso que por vezes é a única prova sobrevivente de uma intrusão.
Resposta curta: sim, regista
A ShimCache guarda um caminho mais o mtime $STANDARD_INFORMATION do ficheiro dentro do valor em HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. Esse registo não tem ligação de volta ao sistema de ficheiros. Quando o executável é apagado, o NTFS liberta o ficheiro. O valor de registo fica intocado. A entrada permanece até ser desalojada por entradas mais recentes (a cache guarda até cerca de 1024) ou o próprio valor ser limpo.
Portanto, um binário que um atacante largou em C:\Users\Public\, correu, e apagou dez minutos depois pode ainda assim deixar uma entrada ShimCache limpa e legível a mostrar o caminho completo que ocupava.
Porque isto é forensicamente poderoso
Entradas de ficheiros apagados são muitas vezes a única prova sobrevivente das ferramentas do atacante:
- Um
mimikatz.exerenomeado apagado após roubo de credenciais. - Um arquivo de staging removido depois de exfiltração.
- Um dropper que se autoeliminou depois de instalar um payload.
- Uma cópia de
7z.exeusada para empacotar dados antes da transferência.
O ficheiro desapareceu. O caminho em cache diz-lhe que existiu, onde, e (através do timestamp de última modificação) liga-o a um build. Esta é a espinha dorsal de caçar malware com a ShimCache e de investigações de ransomware, onde os atacantes limpam rotineiramente as suas ferramentas.
Cruze com a MFT e o USN journal. Se o journal ainda transportar a sequência de criação e apagamento, tem uma âncora limpa de timeline. A reciclagem quase nunca os contém (eles fazem bypass) mas verifique mesmo assim.
Durante quanto tempo sobrevive uma entrada de ficheiro apagado?
Aplicam-se dois limites:
- Desalojamento. A cache está limitada a cerca de 1024 entradas. Num host movimentado, atividade intensa de executáveis pode empurrar entradas antigas para fora. Num servidor calmo, pode sobreviver durante meses.
- Tempo de flush. Novas entradas só são persistidas na hive em clean shutdown. Se o host não tiver sido desligado desde a remoção, a entrada sobrevivente pode estar ainda só em memória. Tire-a de um dump de RAM, veja o guia de extração de memória. O modelo de armazenamento e flush está coberto em onde a ShimCache está armazenada.
O que não prova
Uma entrada de ficheiro apagado prova que o ficheiro existiu e foi examinado nesse host. Não prova que o ficheiro foi executado, e não diz quando foi apagado. O timestamp é o mtime do ficheiro, não uma hora de eliminação. Trate-o como uma testemunha forte de existência e corrobore execução com Prefetch ou AmCache. Veja a ShimCache prova execução.
Para verificar que entradas numa hive apontam para ficheiros que já não existem, analise-a com o Shimcache Parser e cruze os caminhos com o sistema de ficheiros vivo (ou uma imagem forense). Tudo corre localmente no seu browser.
Leitura adicional
- Caching Out the Val da Mandiant, o argumento para a ShimCache como testemunha de ferramentas apagadas.
- SANS DFIR program execution poster, onde a ShimCache se enquadra entre as provas de execução.