← Torna al blog

Anti-forense NTFS: cosa fanno davvero gli attaccanti e cosa li tradisce

· 8 min di lettura

Ogni tecnica anti-forense su NTFS lascia qualcosa dietro. Il motivo è strutturale. La MFT, il journal USN, $LogFile e le Volume Shadow Copies registrano ciascuno una vista diversa degli stessi eventi, e modificare uno di essi è esso stesso un evento che gli altri registrano. Un attaccante che si nasconde da un artefatto quasi sempre si accende su un altro. Un difensore che percorre tutti e quattro insieme è difficile da battere.

Questo è il catalogo. Per ogni tecnica: cosa fanno gli attaccanti, quale residuo lascia e quale artefatto la tradisce.

Timestomping

Il classico. Strumenti come SetMACE, timestomp, i noti script PowerShell Invoke-TimeStomp e qualsiasi numero di helper red team chiamano SetFileTime o scrivono direttamente in $STANDARD_INFORMATION per far sembrare un file più vecchio o più nuovo di quanto sia. Le varianti recenti toccano anche $FILE_NAME rinominando il file (cosa che obbliga NTFS ad aggiornare FN) e poi rinominandolo di nuovo. Il trucco del "doppio rinomino" è ciò che separa un operatore competente da uno script kiddie.

Cosa lo tradisce:

  • Divergenza SI/FN. Un semplice SetFileTime tocca solo SI. I timestamp FN corrispondenti sono ancora i veri orari di creazione/rinomino. Vedi i quattro timestamp MFT. Qualsiasi record dove SI created sia a più di pochi secondi da FN created è sospetto. Dove SI created precede FN created, è naturalmente impossibile: i file non possono esistere prima di essere nominati.
  • Granularità sotto il secondo. NTFS memorizza i timestamp in tick da 100 nanosecondi. Le operazioni native lasciano rumore nelle cifre più basse. La maggior parte degli strumenti di timestomping arrotonda al secondo. Una colonna di suffissi .0000000 allineati su più file è un'impronta.
  • Verità di $UsnJrnl. Il journal USN registra l'ora reale di modifica quando le voci vengono scritte. Un DATA_OVERWRITE USN per l'attributo $DATA di un record con un timestamp che non concorda con l'orario SI modified della MFT è timestomping colto sul fatto.
  • Snapshot VSS. Le Volume Shadow Copies più vecchie contengono i valori pre-stomp. Diffa la $MFT attuale contro la $MFT dello snapshot per lo stesso record e il cambiamento è visibile.

Il trucco del doppio rinomino sconfigge la divergenza SI/FN. Non sconfigge le voci del journal USN né i diff VSS.

Alternate Data Streams come nascondiglio di payload

Un attributo $DATA con un nome (legit.docx:payload.exe) è invisibile a Explorer, invisibile a dir, e usato di routine per nascondere eseguibili, script o configurazioni codificate che il file visibile non tradisce. Lanciato via wmic process call create, rundll32, o Get-Content -Stream più Invoke-Expression.

Cosa lo tradisce:

  • Le passate sulla MFT espongono ogni attributo $DATA. L'enumerazione file per file manca gli stream sui file che non hai pensato di controllare. La MFT no. Vedi alternate data stream.
  • Sysmon Event ID 15 (FileCreateStreamHash) è l'unico evento Sysmon che fa l'hash della creazione di ADS. Se Sysmon è distribuito e configurato, cattura direttamente i drop di stream.
  • Zone.Identifier. I download dal browser portano questo ADS. Un binario in \Downloads\ che non lo ha o non è mai venuto da un browser o è stato deliberatamente rimosso (Unblock-File).

Cancellare un singolo file

I wiper sofisticati sovrascrivono i cluster del file e poi eliminano il record MFT. I meno sofisticati (SDelete di default, cipher /w, del /f) sovrascrivono i dati ma lasciano il record MFT al suo posto.

Cosa lo tradisce:

  • Il record MFT stesso. Un record eliminato con $FILE_NAME e $STANDARD_INFORMATION intatti nomina ancora il file, dà la sua directory padre e mostra i timestamp al momento dell'eliminazione. Vedi cosa sopravvive a una cancellazione.
  • Voci di creazione ed eliminazione in $UsnJrnl. Entrambi gli eventi sono registrati indipendentemente dal fatto che i dati siano stati cancellati.
  • $LogFile. I record di transazione per le operazioni di metadati restano lì finché non ruotano.
  • Snapshot VSS. Se uno snapshot esisteva prima del wipe, il file è intatto al suo interno.

Cancellare il record MFT stesso

Un attaccante più aggressivo scrive nuovi file specificamente per forzare NTFS a riusare lo slot, sovrascrivendo il record eliminato. Questo riesce: lo slot è andato. L'eliminazione è comunque un evento.

Cosa lo tradisce:

  • Incremento del numero di sequenza. Un riferimento da $UsnJrnl o $LogFile al record R sequenza S è ora obsoleto; il record attuale è alla sequenza S+1. Un riferimento incrociato espone il riuso.
  • Storia di $UsnJrnl. Creazione, modifica ed eliminazione originali sono ancora registrate. Lo è anche la creazione del nuovo file. Il riuso lascia una traccia USN.
  • Snapshot VSS. Le copie snapshot di $MFT precedenti al riuso contengono ancora il record originale alla sequenza S.

Troncamento di $UsnJrnl

Il journal dei cambiamenti è finito. Un attaccante che esegue operazioni rumorose (molte scritture di file) può forzare $UsnJrnl a wrappare, espellendo voci più vecchie. La dimensione predefinita è 32 MB sulla maggior parte delle installazioni; maggiore su Server.

Cosa lo tradisce:

  • Un $UsnJrnl corto con una USN iniziale alta. Se il primo record del journal è di ore o minuti prima dell'incidente su un host che è online da settimane, è stato ruotato in modo innaturalmente rapido. Calcola il tasso atteso.
  • $LogFile non ruota nello stesso modo. È dimensionato sul volume e sovrascrive secondo una politica diversa. Operazioni che hanno spinto fuori il journal USN sono talvolta ancora in $LogFile.
  • Le operazioni rumorose stesse lasciano migliaia di record MFT. Le migliaia di file rimescolati necessari per wrappare il journal sono visibili in $MFT. La tecnica è rumorosa.

Eliminazione di $UsnJrnl

fsutil usn deletejournal /D C: rimuove del tutto il journal. Il journal ricreato comincia con un contatore USN fresco. Il numero di sequenza del record MFT $Extend\$UsnJrnl aumenta per riflettere l'eliminazione e ricreazione.

Cosa lo tradisce:

  • Prima USN sospettosamente alta o primo record sospettosamente recente. Un $UsnJrnl fresco di creazione il cui primo record è successivo all'incidente è un indizio.
  • Numero di sequenza della voce di directory $Extend incrementato. Il record MFT di $UsnJrnl stesso ha una sequenza più alta della baseline.
  • Snapshot VSS. Gli snapshot precedenti all'eliminazione contengono ancora il journal originale completo. Montali con vshadowmount ed estrai.

Rinominare il malware con il nome di un file di sistema

Nascondere uno strumento come svchost.exe, lsass.exe, cmd.exe o un altro binario Windows familiare. Non strettamente anti-forense MFT, ma è il trucco che più spesso confonde gli analisti in libertà.

Cosa lo tradisce:

  • Riferimento alla directory padre in $FILE_NAME. Il svchost.exe legittimo vive in C:\Windows\System32. Un file con quel nome in \Users\bob\AppData\Local\Temp\ non lo è. Controlla il riferimento al padre, non solo il nome.
  • Dimensione e hash di $DATA. Il binario legittimo è ben noto. Fai SHA-256 dell'impostore e confronta. Le discrepanze sono immediate.
  • ADS Zone.Identifier se è stato scaricato.
  • Firma del codice. I binari Microsoft sono firmati. Verifica la firma Authenticode sul file on-disk; l'impostore non ne avrà una o ne avrà una non-Microsoft.

Meno comune ma vale la pena conoscere. Più attributi $FILE_NAME sullo stesso record MFT permettono a un attaccante di far apparire lo stesso payload in due directory contemporaneamente. Eliminarlo da una rimuove solo un $FILE_NAME; il file vive finché l'ultimo link non viene rimosso.

Cosa lo tradisce:

  • Campo hardlink_count nell'header del record. Se un record ha conteggio > 1, ogni $FILE_NAME è uno dei link. La MFT li mostra tutti.
  • Motivo HARD_LINK_CHANGE in $UsnJrnl alla creazione e rimozione di hard link.

Manipolazione di $LogFile

fsutil non offre un'opzione "elimina il file di log", ma il log ruota da solo e le operazioni che riempiono il volume possono espellere voci. Operatori sofisticati cercano occasionalmente di pulire $LogFile per rimuovere record di transazione attorno a un incidente.

Cosa lo tradisce:

  • $LogFile è bloccato mentre Windows è in esecuzione. Manometterlo richiede di smontare il volume, che è esso stesso un evento.
  • Snapshot VSS prima della manomissione contengono ancora il log completo.

Scarabocchi del ransomware sulla MFT

Alcune famiglie di ransomware (Petya, NotPetya, una manciata da allora) corrompono deliberatamente $MFT per rendere il volume non montabile. È distruttivo piuttosto che evasivo; l'obiettivo è il denial of service, non la furtività.

Cosa lo tradisce:

  • Record BAAD dove dovrebbe esserci FILE. La pietra tombale di chkdsk per i record irreparabili è ciò che NTFS lascia dopo il wipe. A volte lo scarabocchiatore non scrive BAAD, nel qual caso i record sono non parsabili ma scansionabili per firma.
  • Un sistema non avviabile, ma un'immagine forensicamente preziosa. I cluster di dati sono di solito intatti. Fai una scansione di firma sul volume per record FILE e la maggior parte della tabella è leggibile. Vedi pattern del ransomware in MFT per i dettagli.

Il principio generale

Ogni tecnica anti-forense su NTFS lascia un artefatto da qualche parte. Il motivo è strutturale: $MFT, $UsnJrnl, $LogFile e VSS registrano ciascuno una vista diversa degli stessi eventi. L'attaccante che pulisce la MFT lascia voci USN. L'attaccante che elimina il journal USN lascia un bump fresco del numero di sequenza di $Extend\$UsnJrnl e gli snapshot VSS intatti. L'attaccante che esegue vssadmin delete shadows lascia voci nel log eventi di Windows (System 8224, Application VSS 8194) e possibilmente Sysmon Event ID 1 per l'invocazione di vssadmin.exe.

Un triage che percorre tutti e quattro gli artefatti NTFS più i log eventi e VSS è ciò che cattura gli operatori sofisticati. Il triage su singolo artefatto li perde.

Letture aggiuntive

Articoli correlati

Risorse esterne