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

4 min di lettura

TL;DR. Gli attaccanti combattono lo ShimCache soprattutto evitando gli spegnimenti puliti (così non viene mai scritto). Le modifiche dirette al registro lasciano di solito il blob malformato. Rileva la manomissione tramite cache anormalmente corte, binari sempre-presenti mancanti, dimensioni di voce malformate o divergenza memoria/disco.

Lo ShimCache è più difficile da manomettere della maggior parte degli artefatti Windows, ma non è intoccabile. Questo post passa in rassegna cosa gli attaccanti tentano davvero, perché la maggior parte dei tentativi lascia impronte e come rilevare la manomissione in analisi.

Il toolkit anti-forense dell'attaccante

1. Riavvio forzato prima del flush. L'«anti-forense» più pulita contro lo ShimCache è non dare a Windows la chance di scriverlo. Se l'attaccante forza un power-off (o uccide una VM a livello hypervisor), lo ShimCache in memoria per quella sessione è semplicemente perso. La hive su disco conserva ciò che era stato flushato al precedente spegnimento pulito. Vedi quando viene scritto il cache per il meccanismo.

2. Modifica diretta del blob nel registro. Un attaccante privilegiato può sovrascrivere il valore HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache\AppCompatCache. In teoria permette di rimuovere voci specifiche — in pratica il layout binario è abbastanza non triviale da far sì che modifiche fatte male lascino il blob malformato.

3. Sostituzione offline della hive SYSTEM. Se l'attaccante può mettere il sistema offline, può scambiare il file della hive. Raro nelle intrusioni opportunistiche, presente nei casi statali.

4. Time stomping del binario. Poiché lo ShimCache memorizza l'mtime $STANDARD_INFORMATION del file, un attaccante che altera i timestamp del binario prima che Windows lo esamini sposta la marca temporale cachata. Lo ShimCache di per sé non mente — i metadati che ha catturato erano già manomessi.

5. Cancellazione di AmCache e Prefetch. Gli attaccanti che conoscono gli artefatti corroboranti li cancellano anch'essi, lasciando lo ShimCache come unico testimone e sperando venga scartato per le ragioni del nostro post sulla prova di esecuzione.

Segnali di rilevamento

Quando sospetti manomissione, cerca:

  • ShimCache insolitamente corto. Windows riempie il cache fino a ~1.024 voci con uso normale. Un blob con solo poche voci su un sistema in funzione da giorni è un segnale forte.
  • Voci sempre-presenti mancanti. Diversi binari Windows compaiono in modo affidabile in quasi tutti gli ShimCache (a seconda della versione: shell, helper di attività pianificate, tool Windows Update). La loro assenza su una workstation usata è sospetta.
  • Dimensioni di voce malformate. Un blob che fallisce il parsing a metà strada, con il resto del buffer azzerato o riempito di rumore, è un classico indicatore di editing maldestro. Lo Shimcache Parser lo segnalerà come errore esplicito.
  • Divergenza memoria / disco. Confronta lo ShimCache estratto dalla memoria (guida) con la hive su disco. Voci presenti in memoria ma assenti su disco possono indicare riavvio forzato — voci presenti su disco che contraddicono la memoria (percorsi o mtime diversi per lo stesso slot) suggeriscono che qualcuno ha scritto nella hive.
  • AmCache e ShimCache discordanti. Se AmCache mostra un binario eseguito ma lo ShimCache che dovrebbe avere la voce è vuoto, chiedi perché. Cancellazioni di ShimCache che non toccano AmCache sono comuni perché gli attaccanti non sanno sempre che AmCache esiste.

Cosa dice tutto ciò agli investigatori

Alcune regole pratiche:

  • Tratta uno ShimCache vuoto o quasi-vuoto come evidenza, non come assenza di evidenza. Documentalo.
  • Estrai l'immagine di memoria quando puoi. Spesso recupera ciò che la hive ha perso.
  • Corrobora sempre con AmCache e Prefetch (riferimento). Tre artefatti sono molto più difficili da cancellare in modo coerente di uno solo.
  • Non affermare «l'attaccante ha cancellato lo ShimCache» senza poter mostrare cosa è stato cancellato — segnala buchi nel conteggio, binari di base mancanti o divergenza memoria/disco.

Approfondimenti

Articoli correlati