it

Gli attaccanti possono ripulire lo ShimCache? Anti-forense e rilevamento

4 min di lettura

TL;DR. Gli attaccanti combattono lo ShimCache soprattutto evitando shutdown puliti così che la cache non venga mai svuotata. Le modifiche dirette al registro lasciano di solito il blob malformato. Individua la manipolazione tramite cache insolitamente corte, mancanza di binari Windows sempre presenti, dimensioni di voce malformate, o divergenza memoria-disco.

La cache è più difficile da manipolare della maggior parte degli artefatti Windows. Non impossibile. Dopo qualche incidente smetti di stupirti di ciò che gli attaccanti provano e inizi a stupirti di quanto spesso lascino impronte. Ecco il catalogo delle tecniche che ho effettivamente visto usare e cosa lascia dietro di sé ciascuna.

Cosa gli attaccanti provano davvero

1. Reboot duro prima del flush. L'anti-forense più pulita contro la cache è non dare mai a Windows la possibilità di scriverla. Forza un power-off duro o uccidi la VM sull'hypervisor, e lo ShimCache in memoria di quella sessione è semplicemente perso. L'hive su disco contiene ancora ciò che era stato scaricato al precedente shutdown pulito. È di gran lunga il pattern più comune negli ingaggi ransomware. Vedi quando la cache viene scritta per il meccanismo.

2. Modifiche dirette al blob del valore. Un attaccante a livello SYSTEM può sovrascrivere HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. In teoria questo rimuove voci specifiche. In pratica il layout binario è abbastanza non banale da far sì che le modifiche a mano lascino il blob malformato o il conteggio delle voci insensato.

3. Sostituzione offline dell'hive. Se l'attaccante può spegnere il sistema, può sostituire l'hive SYSTEM per intero. Raro al di fuori del lavoro nation-state ma accade. Il registry parser può mostrarti se i timestamp e la struttura dell'hive SYSTEM sono coerenti con il resto degli artefatti dell'host.

4. Timestomping del binario. Poiché la cache memorizza la mtime $STANDARD_INFORMATION del file, un attaccante che fa timestomping del binario prima che Windows lo esamini sposta il timestamp memorizzato. La cache non mente; i metadati del file che ha catturato erano già stati manipolati. Incrocia con l'attributo $FILE_NAME della MFT, più difficile da stompare.

5. Cancellazione degli artefatti di conferma. Gli attaccanti che imparano cosa fa lo ShimCache spesso ripuliscono anche AmCache, Prefetch, EVTX e il cestino, lasciando lo ShimCache come testimone solitario e sperando che venga scartato per i motivi del post sulla prova di esecuzione.

Segnali di rilevamento

Quando sospetti manipolazione, cerca:

  • Cache insolitamente corta. Windows riempie la cache a circa 1.024 voci con uso normale. Un blob con una manciata di voci su un sistema che gira da giorni è un forte segnale di manipolazione.
  • Voci sempre presenti mancanti. Diversi binari di Windows compaiono in modo affidabile in quasi ogni ShimCache, a seconda della versione: componenti shell, helper per task pianificati, tooling di aggiornamento OS. La loro assenza su una workstation usata è sospetta.
  • Dimensioni di voce malformate. Un blob che fallisce il parsing a metà, con il resto del buffer azzerato o riempito di spazzatura, è un classico indicatore di editing maldestro. Lo Shimcache Parser lo segnala come errore esplicito.
  • Divergenza memoria-disco. Confronta la cache estratta da un dump RAM con l'hive su disco (guida all'estrazione). Voci presenti in memoria ma assenti su disco possono significare un reboot duro. Voci presenti su disco che contraddicono la memoria (percorsi o mtime diversi per lo stesso slot) suggeriscono che qualcuno ha scritto nell'hive.
  • Mismatch AmCache e ShimCache. AmCache mostra un binario eseguito ma lo ShimCache è vuoto per quel file. Chiediti perché. Gli attaccanti che ripuliscono lo ShimCache spesso dimenticano che AmCache esiste.
  • Tracce di strumenti anti-forense. Cerca in Prefetch, Sysmon Event ID 1 e nel journal USN tracce di reg.exe, PowerShell Remove-ItemProperty o editor di hive di terze parti in esecuzione nella finestra rilevante.

Cosa significa per gli investigatori

Qualche regola pratica che impongo in ogni report:

  • Tratta uno ShimCache vuoto o quasi vuoto come prova. Non come assenza di prove. Documentalo esplicitamente.
  • Tira un dump RAM quando puoi. Spesso recupera ciò che l'hive ha perso.
  • Conferma sempre con AmCache e Prefetch. Vedi la referenza degli artefatti. Tre artefatti sono molto più difficili da ripulire in modo coerente di uno.
  • Non rivendicare "l'attaccante ha ripulito lo ShimCache" a meno che tu non possa mostrare cosa è stato ripulito. Indica buchi nel conteggio delle voci, binari di baseline mancanti, o divergenza memoria-disco.

Letture aggiuntive

Articoli correlati