Timestomping, cancellazione dei registri e dati nascosti

La lezione 7.1 ha trattato la distruzione dei dati. Questa lezione illustra invece tre modi per trarre in inganno un esaminatore: modificare le marche temporali, cancellare o alterare i registri e nascondere dati. Ciascuno lascia una discrepanza tra fonti che registrano lo stesso evento in modo indipendente; il compito dell'esaminatore è individuarla, misurarla e dichiarare quanto solidamente avvalori l'ipotesi di manipolazione.

Timestomping

Il timestomping consiste nel modificare le marche temporali di un file affinché si confonda con gli altri o sembri più vecchio. La maggior parte degli strumenti modifica soltanto i valori di $STANDARD_INFORMATION ($SI), tramite SetFileTime (creazione, accesso, modifica) oppure NtSetInformationFile con la classe FileBasicInformation (tutti e quattro, compreso il momento di modifica della voce MFT). Nessuna delle due operazioni richiede diritti di amministratore, e $FILE_NAME ($FN) è più difficile da falsificare (lezione 3.2). Alcune tecniche pubblicate allineano anche $FN combinando modifiche a $SI con una ridenominazione o uno spostamento all'interno del volume, durante cui NTFS copia i valori $SI nel nuovo $FN. Ciò può produrre valori $SI e $FN coincidenti, ma aggiunge record di ridenominazione al journal.

Rilevamento a più livelli

Nessun singolo controllo è conclusivo, perché anche gli strumenti di archiviazione, i programmi di installazione e i client di sincronizzazione impostano le marche temporali. Applicare i controlli a più livelli e indicare quanti concordano.

1. Confronto tra $SI e $FN. Un $SI B precedente a $FN B, oppure un $SI C che non corrisponde ad alcuna operazione, costituisce il primo indizio.
2. Frazione di secondo nulla. Un FILETIME conta intervalli di 100 nanosecondi, quindi una marca temporale autentica corrisponde a un secondo esatto soltanto circa una volta su dieci milioni. Diversi strumenti scrivono secondi interi. Quelli più recenti rendono casuale la frazione, quindi una frazione diversa da zero non dimostra nulla.
3. Voci MFT adiacenti. I numeri delle voci rappresentano approssimativamente l'ordine di creazione, perché $MFT cresce man mano che vengono aggiunti file. Una voce le cui voci adiacenti sono state tutte create nello stesso giorno, ma il cui $SI indica anni prima, è sospetta. Le voci liberate vengono riutilizzate, quindi questo elemento serve soltanto a corroborare altri riscontri.
4. Anteriore al sistema. Confrontare $SI B con InstallDate (reimpostato dagli aggiornamenti delle funzionalità) e con $SI B dei file di metadati del volume stesso, come $MFT (voce 0) e $Volume (voce 3), che normalmente registrano quando il volume è stato formattato. I file copiati o estratti possono conservare marche temporali precedenti, ma in tal caso i loro valori $SI C e $FN ne mostrano l'arrivo.
5. $UsnJrnl. L'impostazione delle marche temporali scrive un record con BASIC_INFO_CHANGE (0x00008000) per il numero di riferimento del file, con una marca temporale assegnata dall'orologio al momento effettivo della modifica. Il flag comprende anche le modifiche agli attributi, quindi va interpretato insieme ai valori $SI. Gli strumenti di copia ed estrazione di solito impostano le marche temporali mentre il file è ancora aperto, nella stessa sequenza ravvicinata di operazioni di FILE_CREATE; una sequenza separata successiva è più indicativa. Record di ridenominazione contigui indicano la tecnica basata su $FN.
6. $LogFile. Un'operazione UpdateResidentValue sull'attributo $SI contiene le vecchie marche temporali nei dati di undo e quelle nuove nei dati di redo, se il registro copre ancora quel momento (da minuti a ore).
7. Altri artefatti che hanno registrato il file. Un file LNK conserva le marche temporali $SI di creazione, accesso e modifica della destinazione, così come erano quando il collegamento è stato scritto, agli offset dell'intestazione 0x1C, 0x24 e 0x2C (lezione 2.4). Prefetch, Amcache e Jump List mostrano quando il file è stato utilizzato. Se ogni riferimento risale al 2026, una data di creazione del 2019 rimane isolata.
8. Marche temporali interne. Il TimeDateStamp di un file PE (secondi Unix nell'intestazione COFF, all'offset e_lfanew + 8; mostrato come LinkDate dai parser di Amcache) non può logicamente essere successivo alla creazione del file. I metadati dei documenti, come dcterms:created nei file di Office (scheda Dettagli di Esplora file), funzionano allo stesso modo. Entrambi possono essere falsificati, e le compilazioni deterministiche inseriscono un hash anziché una marca temporale in TimeDateStamp.

La manipolazione dell'orologio è diversa

Qualcuno potrebbe invece portare indietro l'orologio di sistema, creare il file e ripristinare l'orologio. In questo caso $SI, $FN, i record USN e i registri eventi riportano tutti la falsa ora, con normali frazioni di secondo. I segnali sono quelli della lezione 3.5: evento 1 di Kernel-General nel registro System (OldTime, NewTime) ed evento 4616 nel registro Security (PreviousTime, NewTime), e numeri di sequenza (USN, EventRecordID) che aumentano mentre gli orari tornano indietro. Il timestomping sposta un attributo; le modifiche dell'orologio spostano tutto ciò che viene scritto in quell'intervallo.

Cancellazione dei registri

Windows

La cancellazione del registro Security scrive l'evento Security 1102 ("Il registro di controllo è stato cancellato") come primo record del nuovo registro; la cancellazione di qualsiasi altro registro scrive l'evento System 104, che indica il canale. Entrambi provengono dal provider Microsoft-Windows-Eventlog e registrano SubjectUserName, SubjectDomainName e, per il 1102, SubjectUserSid e SubjectLogonId. La cancellazione di Security richiede il diritto "Gestione file registro di controllo e di sicurezza", che gli amministratori possiedono per impostazione predefinita.

Individuare anche il mezzo utilizzato: wevtutil cl <log> lascia un file Prefetch per WEVTUTIL.EXE nelle edizioni client e un evento 4688 se è attivo il controllo della creazione dei processi (con la riga di comando soltanto se è abilitata anche la registrazione della riga di comando); Clear-EventLog compare nell'evento 4104 di PowerShell/Operational quando è abilitata la registrazione dei blocchi di script, e in ConsoleHost_history.txt.

Altri segnali di manomissione:

• EventRecordID. Un registro cancellato riparte da 1. Un registro che ha subito una normale rotazione inizia da un valore più alto e non presenta lacune interne, quindi un salto all'interno di un singolo file richiede una spiegazione.
• Copertura temporale e dimensioni. Un registro Security che inizia pochi minuti prima dell'incidente su un sistema utilizzato da mesi, oppure un file molto al di sotto del proprio MaxSize, è compatibile con una cancellazione recente. Sono rilevanti anche i periodi di silenzio mentre altre fonti mostrano attività.
• Eliminazione selettiva. Alcuni strumenti rimuovono o nascondono singoli record riscrivendo il file. Cercare lacune negli ID, errori del checksum CRC32 nelle intestazioni del file o dei chunk e record che i parser segnalano come nascosti o danneggiati. Trattarli come indizi.
• Manomissione del servizio e dei criteri. Security 1100 ("Il servizio di registrazione eventi è stato arrestato") e System 6006 (servizio Registro eventi arrestato) sono normali durante l'arresto del sistema; se non sono seguiti da un avvio (6005), suggeriscono che il servizio sia stato arrestato. Security 4719 registra una modifica dei criteri di controllo. Le tecniche che sospendono la registrazione in memoria non scrivono nulla; soltanto le lacune rispetto ad altre fonti le rivelano.

I record cancellati sono spesso recuperabili: copie precedenti nelle copie shadow del volume (lezione 2.9), chunk ElfChnk da 64 KB recuperati mediante carving dallo spazio non allocato, da pagefile.sys o da hiberfil.sys (ad esempio con EVTXtract), e copie inoltrate a un collettore o a un SIEM.

Linux

Confrontare le fonti che registrano gli stessi eventi (lezione 6.4). Un /var/log/auth.log troncato, oppure privo di righe di sessione che journalctl mostra ancora per sshd, indica un'alterazione. Ogni record wtmp occupa 384 byte su Linux x86-64; utmpdump /var/log/wtmp mostra un record azzerato come tipo 0 con una marca temporale del 1970 (sui sistemi che utilizzano invece wtmpdb, esaminare /var/lib/wtmpdb/wtmp.db, lezione 6.4), e un record rimosso come un accesso senza la relativa disconnessione o una lacuna nella sequenza degli avvii. journalctl --verify segnala file journal danneggiati; i messaggi "danneggiato o chiuso in modo non corretto" e i file .journal~ hanno spesso cause innocue. I nomi dei file journal archiviati contengono il numero di sequenza della loro prima voce, quindi un file mancante nel mezzo della serie si manifesta come una lacuna; la normale pulizia rimuove soltanto i più vecchi. La lezione 6.3 tratta gli espedienti relativi alla cronologia della shell, come la rimozione dell'impostazione di HISTFILE.

Dati nascosti

• Flussi di dati alternativi (lezione 1.4). Qualsiasi flusso diverso da Zone.Identifier e dai flussi di sistema noti merita un esame. MFTECmd (HasAds, IsAds), istat e dir /r li elencano; l'aggiunta di uno di essi scrive STREAM_CHANGE.
• Confronto tra estensione e firma. Confrontare i primi byte con l'estensione: 4D 5A (MZ) identifica un file PE, 50 4B 03 04 un contenitore ZIP (compresi i .docx), 25 50 44 46 (%PDF) un PDF, FF D8 FF un JPEG. Il modulo di Autopsy per le discrepanze delle estensioni e file automatizzano questo controllo.
• Spazio slack e spazio non allocato (lezione 1.2). Uno slack della RAM non nullo su un volume NTFS moderno, oppure dati strutturati distribuiti in numerose aree di slack, suggerisce un inserimento deliberato.
• Partizioni nascoste e lacune (lezione 1.1). Confrontare la tabella delle partizioni con le dimensioni del disco e cercare spazio non partizionato oltre il normale allineamento a 1 MiB. Su GPT, i bit di attributo 62 (nascosto) e 63 (nessuna lettera di unità) nascondono le partizioni dati di base da Esplora file.
• Steganografia. I test statistici (chi quadrato o analisi RS dei bit meno significativi) in strumenti come StegExpose o zsteg segnalano immagini, con falsi positivi. Dati aggiunti dopo FF D9 di un JPEG o IEND di un PNG, oppure software di steganografia negli artefatti di esecuzione, sono spesso indizi migliori.
• Contenitori cifrati camuffati da file. Un'entropia di Shannon prossima a 8,0 bit per byte, nessuna intestazione riconoscibile e dimensioni che siano un multiplo esatto di 512 byte sono compatibili con un contenitore (lezione 7.3). Anche i formati compressi raggiungono valori elevati, ma iniziano con una firma.
• Attributi e nomi. Attributi Nascosto e Sistema, nomi Unix che iniziano con un punto, nomi che imitano file di sistema nella cartella sbagliata, il carattere di forzatura della direzione da destra a sinistra U+202E e sottocartelle di $Recycle.Bin denominate con SID che non esistono nella chiave ProfileList.

Esempio svolto: svc.dll e un registro Security cancellato

La raccolta di triage dal portatile di ana mostra questa voce MFT:

Controllo della frazione di secondo. Il valore $SI è 132.073.632.000.000.000 (byte 00 40 8E BF 44 38 D5 01). Diviso per 10.000.000 equivale a 13.207.363.200 secondi, con resto 0. Il valore $FN 134.179.718.913.301.447 ÷ 10.000.000 = 13.417.971.891 con resto 3.301.447, ossia 0,3301447 s. La differenza, 2.106.086.913.301.447 intervalli o 210.608.691,33 s, è pari a 2.437 giorni 14 h 24 min 51,33 s.

Ragionamento. $SI B è anteriore di 6 anni e 8 mesi a $FN B e precede la formattazione del volume; ha una frazione di secondo nulla; le voci adiacenti sono state create quattro secondi prima e 35 secondi dopo la marca temporale $FN; e il journal registra una modifica delle marche temporali in una sequenza separata 12 secondi dopo la creazione, senza ridenominazione. $LogFile era stato sovrascritto ciclicamente e non copriva più le 14:25. L'affermazione sostenibile è che il nome svc.dll è stato creato su questo volume alle 2026-03-14T14:24:51Z e che le sue marche temporali $SI sono state impostate a 2019-07-12T00:00:00Z intorno alle 14:25:03Z, in modo coerente con il timestomping. Il journal non mostra chi lo abbia fatto.

Il registro. Security.evtx inizia con EventRecordID 1, un evento 1102 alle 2026-03-14T14:38:55Z con SubjectUserName ana e SubjectUserSid S-1-5-21-…-1001. Il registro Security è stato cancellato dall'account di ana 13 min 52 s dopo la modifica delle marche temporali, e tale account possedeva il diritto necessario. Qualsiasi evento 4616 di modifica dell'ora è andato perso insieme al registro, quindi occorre controllare la presenza di System Kernel-General 1 prima di considerare attendibile l'ora 14:25:03Z del journal; non ve n'è alcuno. Passi successivi: Prefetch per WEVTUTIL.EXE, 4104, copie shadow e chunk recuperati mediante carving.

Tecnica, rilevamento e grado di certezza

Il grado di certezza si riferisce alla manipolazione; stabilire chi l'abbia compiuta richiede elementi probatori distinti, come accessi e artefatti di esecuzione.

Focus sull'esame: Occorre saper riportare il momento effettivo di arrivo di un file ricavandolo da $FN o dal journal quando $SI è falsificato, e il momento della modifica ricavandolo da un record BASIC_INFO_CHANGE. È necessario saper eseguire il controllo della frazione di secondo su un FILETIME grezzo e leggere gli eventi 1102 o 104 per determinare chi ha cancellato quale registro e quando. Le domande possono richiedere di distinguere il timestomping da una modifica dell'orologio, oppure di indicare dove sia possibile recuperare i record cancellati.

Punti chiave

• Il timestomping modifica di solito soltanto $SI; confrontarlo con $FN, frazioni di secondo, voci MFT adiacenti, creazione del volume, $UsnJrnl, $LogFile, LNK e marche temporali interne, e contare quanti elementi concordano.
• BASIC_INFO_CHANGE registra il momento effettivo in cui sono stati impostati marche temporali o attributi; una sequenza separata dopo la creazione è più significativa di una interna alla sequenza di creazione.
• Una modifica dell'orologio sposta tutti gli artefatti insieme e lascia Kernel-General 1 o 4616; il timestomping sposta un attributo.
• 1102 (Security) e 104 (System) indicano l'account che ha cancellato un registro; gli ID dei record ripartono da 1 e i vecchi record possono sopravvivere in copie shadow, chunk recuperati mediante carving e copie inoltrate.
• Su Linux, confrontare i registri di testo con il journal, leggere wtmp con utmpdump e controllare i numeri di sequenza del journal.
• I dati nascosti si rivelano attraverso la struttura: attributi $DATA aggiuntivi, discrepanze delle firme, spazio slack anomalo, spazio non partizionato e file ad alta entropia privi di intestazioni.