Ogni record MFT memorizza quattro timestamp in due attributi separati. Sono otto numeri per record. Non sono sempre sincronizzati. La relazione tra di essi, e dove si rompe, è il fondamento dell'analisi temporale di NTFS. Se devi imparare un solo dettaglio della forense MFT, impara questo.
I quattro momenti che NTFS registra
Sia $STANDARD_INFORMATION (SI, tipo di attributo 0x10) che $FILE_NAME (FN, tipo di attributo 0x30) portano timestamp per gli stessi quattro eventi:
- Creato: quando il file è stato scritto per la prima volta sul volume.
- Modificato: quando il contenuto del file è cambiato per l'ultima volta.
- Acceduto: quando il file è stato letto per l'ultima volta.
- MFT-modificato: quando il record stesso è stato aggiornato per l'ultima volta (qualsiasi cambio di attributo, non solo di dati).
I timestamp sono memorizzati come valori a 64 bit in formato Windows FILETIME (tick da 100 nanosecondi dal 1601-01-01 UTC). Granularità di 100 nanosecondi. Abbastanza bit perché eventi naturali lascino rumore nelle cifre basse.
Perché esistono due set
$STANDARD_INFORMATION è il set di timestamp che vede lo user space. L'API Win32 SetFileTime scrive qui. Ogni normale operazione su file che tocca un timestamp aggiorna SI: scrittura, lettura (a seconda dell'impostazione del tempo di accesso), rinomino, cambio di attributo.
$FILE_NAME è stato aggiunto per compatibilità con il sottosistema POSIX nei primi NT e persiste per ragioni storiche. Viene aggiornato solo quando cambia il nome: creazione (quando il nome viene impostato per la prima volta), rinomino (quando il nome cambia) o spostamento tra directory (che rinomina nel senso NTFS). Dopo questo, FN resta fermo finché il file mantiene quel nome.
In pratica ciò significa che i timestamp SI ticchettano costantemente mentre quelli FN restano stabili. L'asimmetria è ciò che rende il timestomping rilevabile.
Cosa fa il timestomping
Gli strumenti che alterano i timestamp di solito chiamano SetFileTime. Questo scrive in SI. Non tocca FN. Dopo il timestomping:
- SI mostra ciò che l'attaccante ha scelto. Spesso retrodatato di anni (per far sembrare uno strumento appena rilasciato come un file di sistema) o spostato in avanti (per offuscare l'orario reale dell'attività).
- FN riflette ancora l'orario reale di creazione, possibilmente con un ampio margine.
Questo produce la firma canonica del timestomping: un file con SI creato nel 2018 e FN creato sei minuti fa.
Due pattern da osservare durante il triage:
- SI creato più vecchio di FN creato. È naturalmente impossibile. I file non possono esistere prima di essere nominati. Qualsiasi record dove SI creato precede FN creato è stato toccato.
- SI modificato lontano da FN modificato su un file che chiaramente non è stato rinominato. FN modificato si muove solo nei rinomini; se SI dice 2017 e FN dice ieri senza un rinomino in mezzo, qualcosa non va.
Il trucco del doppio rinomino
Gli operatori che sanno che la divergenza SI/FN è rilevabile usano un workaround: rinomina il file (cosa che obbliga NTFS ad aggiornare FN), poi chiama SetFileTime sia su SI che su FN, poi rinomina indietro. Ora entrambi gli attributi mostrano i valori retrodatati.
Questo sconfigge il confronto SI/FN. Non sconfigge:
- Il journal USN. Ogni rinomino scrive una coppia
RENAME_OLD_NAME/RENAME_NEW_NAME. I due rinomini necessari per il trucco sono visibili nel journal. I loro timestamp nel journal sono gli orari reali, non i valori FN falsificati. $LogFile. I record di transazione attorno al rinomino restano nel log.- Snapshot VSS. Gli snapshot più vecchi hanno i valori FN pre-stomp. Diffa la MFT attuale contro la MFT dello snapshot per lo stesso record.
Il doppio rinomino è più difficile da fare in silenzio. Resta comunque comune nei toolkit red team maturi.
Granularità sotto il secondo, l'indizio dello strumento pigro
NTFS memorizza i timestamp in tick da 100 nanosecondi. Le operazioni native di Windows lasciano rumore nelle cifre basse. L'OS non azzera la componente sotto il secondo quando scrive un timestamp; ciò che l'orologio del kernel ha restituito è ciò che viene registrato.
La maggior parte degli strumenti di timestomping arrotonda al secondo più vicino prima di scrivere. Il risultato è un timestamp che termina in .0000000 UTC. Un singolo timestamp del genere è insignificante (eventi naturali occasionali arrotondano). Una colonna di suffissi .0000000 allineati su molti file è un'impronta.
È facile da controllare. Prendi le colonne created, modified, accessed e MFT-modified dal tuo parse MFT. Filtra ogni record dove tutti e quattro i timestamp SI terminano in .0000000. Confronta con una baseline di attività naturale di Windows. Il contrasto è immediato.
Cosa fa Windows stesso ai timestamp
Per usare il confronto SI/FN devi sapere cosa fa Windows da sé ai quattro campi. Il bigino:
- SI creato: scritto alla creazione. Aggiornato da alcuni installer quando "creano" un file estraendolo.
- SI modificato: scritto a ogni scrittura di dati. Aggiornato da
SetFileTime. Non aggiornato da cambiamenti di soli metadati. - SI acceduto: di default disabilitato su Windows 7+ (imposta
fsutil behavior set disablelastaccess 0per abilitarlo). Se disabilitato, questo campo viene comunque aggiornato occasionalmente da certe operazioni (software di backup, scansioni EDR), ma è inaffidabile come segnale di "ultima lettura" in entrambe le direzioni. - SI MFT-modificato: scritto a ogni cambio di attributo, inclusi rinomini, cambi di ACL, creazione di ADS e scritture di dati.
- FN creato: scritto quando il nome viene impostato per la prima volta (creazione, creazione di hard link, rinomino).
- FN modificato, FN acceduto, FN MFT-modificato: scritti quando il nome viene impostato, poi in gran parte stabili.
Su un'installazione pulita, i quattro timestamp di FN sono tipicamente uguali tra loro (sono stati tutti impostati nello stesso istante quando il nome è stato assegnato). Quando vedi FN con tutti e quattro i timestamp identici e i quattro SI che divergono, è normale.
Windows Update e binari patchati
Windows Update tocca i timestamp SI dei binari patchati. Dopo un aggiornamento cumulativo, metà di \Windows\System32\ ha SI modificato entro minuti l'uno dall'altro e FN che è stato stabile dall'ultimo service pack. È normale. Trattalo come pattern di baseline, non come attività anomala.
Incrocia con CBS.log e setupapi.dev.log per la finestra di patching. Se SI dice che svchost.exe è stato modificato alle 03:14 e il log CBS mostra un'installazione di componente alle 03:14, è Windows Update, non un attaccante.
Come faccio screening del timestomping
Lo screening che eseguo su un estratto MFT fresco:
- Tira ogni record dove SI creato < FN creato. Rivedi manualmente ciascuno.
- Tira ogni record dove SI modificato è più di 30 giorni prima di FN modificato e il file è in una directory scrivibile dall'utente. Revisione manuale.
- Tira ogni record dove tutti e quattro i timestamp SI terminano in
.0000000e il file non è un binario di sistema di Windows. Revisione manuale. - Diffa la MFT attuale contro lo snapshot VSS più recente. Evidenzia i record i cui timestamp SI si sono mossi all'indietro. Revisione manuale.
Quella sequenza cattura la maggior parte del timestomping in libertà. Gli operatori sofisticati che usano il trucco del doppio rinomino o l'eliminazione di VSS richiedono i livelli journal e log eventi per essere rilevati, ma i quattro controlli sopra li faranno emergere comunque attraverso altri artefatti (il rinomino nel journal USN, l'eliminazione VSS nel log eventi).
Letture aggiuntive
- David Cowen, copertura di Forensic Lunch sul timestomping. Anni di studi di caso di praticanti.
- SANS, bigino delle regole temporali di Windows. Riferimento rapido per ciò che ogni operazione di Windows fa a ogni timestamp.
- Le note su
$STANDARD_INFORMATIONe$FILE_NAMEdel progetto linux-ntfs. Riferimento di layout a livello di campo.