Análise de linha do tempo · Aula 2 de 5
MACB no NTFS: $SI vs $FN
12 min de leitura
Cada arquivo em um volume NTFS contém pelo menos oito carimbos de data/hora, e a qualidade de uma linha do tempo depende do conhecimento do perito sobre o que altera cada um deles. Esta aula explica a notação MACB usada em linhas do tempo, onde os oito valores ficam, qual componente os atualiza, como operações normais, como copiar, renomear e editar, os alteram e como reconhecer valores que não se encaixam nesses padrões. O Módulo 7 aborda o timestomping como técnica antiforense; aqui, o objetivo é ler uma linha do tempo corretamente.
Notação MACB
As linhas do tempo identificam cada carimbo de data/hora do sistema de arquivos com uma de quatro letras:
| Letra | Significado no NTFS | Causa típica |
|---|---|---|
| M | Modificado: última gravação do conteúdo | Dados gravados no $DATA do arquivo |
| A | Acessado: último acesso | Leitura ou execução, se as atualizações estiverem habilitadas |
| C | Alterado: última modificação da entrada da MFT | Qualquer alteração de metadados: nome, atributos, segurança, tamanho |
| B | Criado: criação | Arquivo criado neste volume |
C é a armadilha: no NTFS, significa que a entrada da MFT (metadados) foi alterada, não que o arquivo foi "criado". O Explorador do Windows nem sequer o exibe.
As ferramentas de linha do tempo combinam valores idênticos em uma única linha e exibem as letras como um código de quatro posições, com pontos nas posições que não se aplicam. Na saída de mactime do The Sleuth Kit, m.c. significa que esse horário corresponde tanto à modificação do conteúdo quanto à alteração da entrada da MFT, .a.. indica apenas um acesso e macb significa que os quatro valores são iguais, o que é normal na criação. O bodyfile do TSK (fls -m) lista os valores de $FN como uma entrada separada cujo nome termina em ($FILE_NAME), portanto um arquivo pode gerar linhas para os dois conjuntos. A saída l2tcsv do Plaso tem uma coluna MACB com as mesmas letras em maiúsculas (Aula 3.3).
Onde ficam os oito carimbos de data/hora
A Aula 1.3 apresentou os dois atributos. Seus carimbos de data/hora ficam nestes offsets dentro do conteúdo do atributo:
| Valor | $STANDARD_INFORMATION (0x10) | $FILE_NAME (0x30) |
|---|---|---|
| B, criação | 0x00 | 0x08 |
| M, modificação | 0x08 | 0x10 |
| C, modificação da entrada da MFT | 0x10 | 0x18 |
| A, acesso | 0x18 | 0x20 |
$FN começa com a referência de 8 bytes ao diretório pai, por isso seus carimbos de data/hora começam em 0x08. Todos os oito são valores FILETIME: contagens de 64 bits de intervalos de 100 nanossegundos desde 1601-01-01 00:00:00 UTC (Aula 3.1). Eles são armazenados em UTC, independentemente do fuso horário do sistema.
Um arquivo tem um $SI, mas um $FN por nome. Com nomes curtos 8.3 habilitados, Quarterly Report.xlsx tem um $FN Win32 e um $FN DOS (QUARTE~1.XLS), e cada um contém seus próprios quatro carimbos de data/hora, geralmente idênticos. Links físicos adicionam mais atributos $FN. A entrada do índice $I30 do diretório pai contém outra cópia do $FN, incluindo os carimbos de data/hora, que pode diferir do registro; entradas deixadas no espaço residual do índice podem preservar horários de arquivos excluídos ou renomeados.
Quem os atualiza
$SI é mantido pelo NTFS durante operações normais de arquivo, e qualquer processo com acesso de gravação de atributos no arquivo também pode defini-lo a partir do modo usuário. SetFileTime define os horários de criação, acesso e modificação; a chamada nativa NtSetInformationFile com a classe FileBasicInformation (e SetFileInformationByHandle) pode definir os quatro, incluindo o horário de modificação da entrada da MFT. Não são necessários privilégios de administrador. Softwares legítimos usam essas chamadas o tempo todo: ferramentas de arquivamento, cópia e backup, instaladores e clientes de sincronização em nuvem restauram horários intencionalmente.
$FN é gravado pelo driver NTFS no kernel quando um nome é criado, o que ocorre principalmente na criação, renomeação e movimentação. Não há uma API documentada para definir $FN diretamente. Por isso, $FN é mais difícil de falsificar e compará-lo com $SI é útil. Mais difícil não significa impossível: como uma renomeação ou movimentação normalmente copia os valores de $SI para o novo $FN, alguém pode definir $SI e depois mover o arquivo, e gravações diretas no disco podem alterar qualquer coisa (Módulo 7).
O último acesso é uma evidência fraca
O valor de registro NtfsDisableLastAccessUpdate em HKLM\SYSTEM\CurrentControlSet\Control\FileSystem controla as atualizações de A. Desde o Windows Vista, elas vêm desabilitadas por padrão. A partir do Windows 10 versão 1803, o valor pode ser de 0x80000000 a 0x80000003: o bit 0x2 definido significa "Gerenciado pelo sistema", situação em que o Windows decide e habilita as atualizações em volumes de sistema de 128 GB ou menos, e o bit 0x1 definido significa desabilitado. fsutil behavior query disablelastaccess mostra a configuração em um sistema em execução. Portanto, a atualização de A depende da versão e do volume: nunca presuma que ela esteja habilitada ou desabilitada. Mesmo quando habilitada, o NTFS adia a gravação de um novo horário de acesso no disco em até uma hora. Trate A como uma evidência fraca: um A antigo não prova que o arquivo não foi aberto, e um A recente pode resultar de uma verificação de antivírus, indexação ou backup. Use Prefetch, arquivos LNK e Listas de Atalhos para demonstrar que um arquivo ou programa foi aberto (Módulo 2).
Regras práticas no Windows 10 e 11
Pesquisas sobre o NTFS no Windows 10 e 11 tabularam como operações comuns alteram os oito valores. A tabela mostra o resultado típico; o comportamento varia conforme a compilação do Windows e o programa que executa a operação, portanto teste na mesma versão antes de se apoiar em uma regra em um laudo.
| Operação | $SI M | $SI A | $SI C | $SI B | $FN M | $FN A | $FN C | $FN B |
|---|---|---|---|---|---|---|---|---|
| Criar | Novo | Novo | Novo | Novo | Novo | Novo | Novo | Novo |
| Modificar conteúdo | Novo | Se habilitado | Novo | – | – | – | – | – |
| Ler (acesso) | – | Se habilitado | – | – | – | – | – | – |
| Renomear, mesmo volume | – | – | Novo | – | De $SI | De $SI | De $SI | De $SI |
| Mover, mesmo volume | – | – | Novo | – | De $SI | De $SI | De $SI | De $SI |
| Copiar (novo arquivo) | Origem | Novo | Novo | Novo | Novo | Novo | Novo | Novo |
| Mover para outro volume | Origem | Novo | Novo | Origem | Novo | Novo | Novo | Novo |
"Novo" é o horário da operação, "–" indica que não houve alteração, "Origem" indica que o valor foi herdado do arquivo original e "De $SI" significa que o novo $FN recebe os valores de $SI existentes imediatamente antes da operação. Uma movimentação para outro volume é uma cópia seguida de uma exclusão: o novo registro recebe novos horários de $FN, como em uma cópia, mas recortar e colar no Explorador também preserva o $SI B da origem, portanto tanto M quanto B parecem antigos.
Três consequências são as mais importantes:
- Indicador de cópia. Uma cópia mantém o M da origem, mas recebe um novo B, portanto M anterior a B é o sinal normal de um arquivo copiado, não de adulteração.
- Arquivos compactados e downloads. Ferramentas de extração geralmente definem M a partir do horário armazenado no arquivo compactado, e algumas também restauram B e A, portanto os arquivos extraídos podem parecer ter anos de idade. Um download pelo navegador normalmente recebe B quando o arquivo é criado pela primeira vez e M quando a gravação termina; algumas ferramentas de download definem M a partir do cabeçalho Last-Modified do servidor. Um fluxo de dados alternativo
Zone.Identifierajuda a identificar downloads. - Aplicativos com salvamento seguro. Muitos editores, incluindo suítes de escritório, salvam gravando um arquivo temporário e renomeando-o para substituir o original. O arquivo passa então a ocupar um novo registro da MFT, enquanto o tunneling do NTFS (um cache, de 15 segundos por padrão, indexado pelo nome) atribui ao novo arquivo o horário de criação de $SI do arquivo antigo. Um B estável não prova que o registro seja o mesmo.
Exemplo resolvido: budget-q3.xlsx
(a) Copiado de uma unidade USB. A unidade FAT32 continha budget-q3.xlsx, cuja última modificação foi em 2026-07-28T16:42:10Z. Ele foi copiado para C:\Users\ana\Documents\. O registro (por exemplo, na saída de istat) mostra:
| Valor | $SI (0x10) | $FN (0x30) |
|---|---|---|
| Criação | 2026-08-03T09:15:42.6183420Z | 2026-08-03T09:15:42.6183420Z |
| Modificação | 2026-07-28T16:42:10.0000000Z | 2026-08-03T09:15:42.6183420Z |
| Modificação da MFT | 2026-08-03T09:15:42.7401138Z | 2026-08-03T09:15:42.6183420Z |
| Acesso | 2026-08-03T09:15:42.6183420Z | 2026-08-03T09:15:42.6183420Z |
Raciocínio: $SI M é 5 dias, 16 horas e 33 minutos anterior a $SI B, o que corresponde ao padrão de cópia (a coluna Copied do MFTECmd sinaliza isso). $SI B é igual a $FN B, portanto nada sugere uma alteração para uma data anterior. $SI M tem a parte de frações de segundo zerada porque o FAT32 armazena horários de modificação em incrementos de 2 segundos e a cópia o preservou; 16:42:10 é um segundo par. O FAT armazena o horário local, portanto a conversão para UTC usou o fuso horário do sistema que realizou a cópia (Aula 3.5). O arquivo chegou às 09:15:42Z; corrobore o dispositivo USB com os artefatos da Aula 2.6.
(b) Editado e salvo no próprio arquivo em 2026-08-04T22:31:07.4410023Z. $SI M e $SI C passam a ser 2026-08-04T22:31:07.4410023Z. $SI B permanece em 09:15:42.6183420Z, e $SI A não muda porque as atualizações de último acesso estão desabilitadas. Os quatro valores de $FN permanecem em 2026-08-03T09:15:42.6183420Z. Agora M é posterior a B, portanto o indicador de cópia desapareceu de $SI; o horário de chegada permanece em $SI B e nos quatro valores de $FN. Se um editor com salvamento seguro tivesse sido usado, compare o número do registro com artefatos anteriores antes de presumir que se trata do mesmo registro.
Interpretação de anomalias
Padrões que não se encaixam na tabela merecem uma análise mais detalhada:
- $SI B anterior a $FN B. Após criação, cópia, renomeação e movimentação no mesmo volume, $SI B é igual a $FN B. Recortar e colar a partir de outro volume e algumas extrações de arquivos compactados também produzem um $SI B mais antigo, mas deixam $SI C no horário da operação.
- Valores de frações de segundo zerados. Um FILETIME cuja parte de 100 nanossegundos é 0000000. O NTFS registra com precisão total, enquanto muitas ferramentas que definem horários usam segundos inteiros.
- Datas de $SI anteriores à instalação do sistema operacional, usando
InstallDate(segundos Unix) emHKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion. Atualizações de recursos redefinem esse valor, portanto compare com cuidado.
Cada um tem causas legítimas: extração de arquivos compactados, instaladores, clientes de sincronização e arquivos provenientes de mídias FAT. Trate-os como pistas, não como constatações, e confirme com $UsnJrnl (um motivo BASIC_INFO_CHANGE no momento em que os valores foram definidos) e $LogFile (Aula 1.4 e Módulo 7). O MFTECmd, por exemplo, grava os oito valores como Created0x10, Created0x30, LastModified0x10, LastModified0x30, LastRecordChange0x10, LastRecordChange0x30, LastAccess0x10 e LastAccess0x30 (0x10 é $SI, 0x30 é $FN) e sinaliza registros com SI<FN (um horário de $SI anterior ao horário de $FN), uSecZeros (valores de frações de segundo zerados) e Copied. Algumas ferramentas deixam as colunas de $FN vazias quando seus valores são iguais aos de $SI, portanto verifique como sua ferramenta os exibe.
Exemplo resolvido: um arquivo submetido a timestomping
C:\ProgramData\Intel\igfxupd.exe mostra os quatro valores de $SI como 2019-03-19T04:12:00.0000000Z e os quatro valores de $FN como 2026-08-05T02:14:48.9917304Z. InstallDate é 1.676.037.931, o que corresponde a 2023-02-10T14:05:31Z.
O valor bruto de criação de $SI consiste nos 8 bytes 00 E8 45 E6 09 DE D4 01, lidos em little-endian como 0x01D4DE09E645E800 = 131.974.423.200.000.000. Dividido por 10.000.000, isso resulta em 13.197.442.320 segundos com resto 0: sem fração de segundo. O valor de $FN 134.303.696.889.917.304 deixa um resto de 9.917.304, ou seja, 0,9917304 s.
Raciocínio: $SI B é sete anos anterior a $FN B; as frações de segundo de $SI estão zeradas, enquanto as de $FN não estão; $SI é anterior à instalação; e $SI C também foi definido, o que SetFileTime sozinho não consegue fazer. Uma cópia normal atribuiria um novo $SI B, e uma movimentação de outro volume ou uma extração que restaurasse B ainda deixaria $SI C no horário da operação. A afirmação defensável é que o nome do arquivo foi criado neste volume em 2026-08-05T02:14:48Z e que seus valores de $SI provavelmente foram definidos depois, aguardando confirmação de $UsnJrnl.
Foco no exame: Espere ter de identificar quais dos oito carimbos de data/hora uma operação altera, reconhecer M anterior a B como uma cópia e escolher $FN em vez de $SI quando $SI parecer manipulado. Tarefas práticas podem solicitar o horário de chegada de um arquivo a um volume, que vem de B e deve ser informado em UTC com precisão total. Questões sobre último acesso testam se você sabe que ele geralmente está desabilitado e, portanto, constitui uma evidência fraca.
Pontos principais
- MACB significa Modificado, Acessado, entrada da MFT alterada e Criado; no NTFS, C é alteração de metadados, não criação.
- $SI e cada $FN contêm quatro valores FILETIME em UTC; um arquivo tem um $SI, mas um $FN por nome, além de uma cópia no índice $I30 do diretório pai.
- $SI pode ser definido a partir do modo usuário por qualquer processo com acesso de gravação de atributos; $FN é gravado pelo kernel na criação, renomeação e movimentação, portanto é mais difícil de falsificar.
- Uma cópia mantém o M da origem e recebe um novo B, portanto M anterior a B é normal em arquivos copiados.
- A atualização do último acesso depende da versão e do volume; trate A como uma evidência fraca.
- $SI B anterior a $FN B, frações de segundo zeradas e datas anteriores à instalação são pistas a confirmar com $UsnJrnl e $LogFile.