Artefatos para detecção de manipulação de carimbo de data/hora em NTFS no Windows e sua confiabilidade

Por: [Palmbach, David, and Frank Breitinger. “Artifacts for Detecting Timestamp Manipulation in NTFS on Windows and Their Reliability.” Forensic Science International: Digital Investigation 32 (2020): 300920. URL: https://dx.doi.org/10.1016/j.fsidi.2020.300920]

Resumo

Os carimbos de data/hora provaram ser uma fonte conveniente de evidências para examinadores na reconstrução de crimes de computador. Consequentemente, adversários ativos e malware implementaram técnicas de timestomping (ou seja, mecanismos para alterar timestamps) para ocultar seus rastros. Pesquisas anteriores sobre a detecção de manipulação de timestamp focaram principalmente em dois artefatos: o $MFT, bem como os registros no $LogFile. Neste artigo, apresentamos um novo uso de quatro artefatos de janelas existentes – o $USNjrnl, arquivos de link, arquivos de Prefetch e logs de eventos do Windows – que podem fornecer informações valiosas durante as investigações e diversificar os artefatos disponíveis para os examinadores. Esses artefatos contêm informações sobre programas executados ou timestamps adicionais que, quando ocorrerem inconsistências, podem ser usados ​​para provar a falsificação do timestamp. Além disso, examinamos a confiabilidade dos artefatos usados ​​para detectar a manipulação do carimbo de data/hora, ou seja, testando sua capacidade de reter informações contra usuários que tentam ativamente alterá-las ou excluí-las. Com base em nossas descobertas, concluímos que nenhum dos artefatos analisados ​​pode resistir à exploração ativa. Palavras-chave Manipulação de timestamp, Falsificação, $Logfile, $USNJrnl, SetMACE, nTimestomp, Timestomping, Anti-forense

1. Introdução

À medida que os crimes de computador se tornam mais prevalentes e sofisticados, os examinadores forenses contam fortemente com metadados, como carimbos de data/hora durante suas investigações (Buchholz e Spafford, 2004 ; Koen e Olivier, 2008). Devido à sua importância e ao fato de que é relativamente fácil alterar carimbos de data/hora com ferramentas atuais (de código aberto), a confiabilidade dessa evidência foi repetidamente questionada no tribunal (Hannon, 2018). A integridade dos carimbos de data/hora tornou-se uma questão cada vez mais importante, enquanto, por outro lado, detectar a manipulação do carimbo de data/hora não é trivial. Grupos sofisticados e atores estatais geralmente adicionam recursos de timestomping em seu malware, o que é bem documentado pelo MITER (b). Grupos de hackers, como Lazarus group for North Korea (Novetta, 2016), Fancy Bear for Russia (Alperovitch, 2016), Threat Group 3390 for China (Works, 2015), Copy Kittens for Iran (Sky, 2017) e muitos mais, foram documentados usando-o. Descrição do Problema. Embora os profissionais estejam cientes da possibilidade de falsificação do carimbo de data/hora, há uma quantidade limitada de literatura revisada por pares sobre a detecção de manipulação de carimbo de data/hora, bem como a confiabilidade dos artefatos usados ​​para fazer isso. Se o artefato que está sendo usado para identificar a manipulação do carimbo de data/hora puder ser manipulado (ou excluído), ele se tornará menos valioso para o examinador. Por exemplo, Jang et al. (2016) descobriram que não é possível detectar a manipulação de timestamp apenas analisando os valores no $MFT e métodos subsequentes foram necessários. No entanto, os autores limitaram sua pesquisa a uma fonte adicional (o $LogFile) para detectar falsificação de carimbo de data/hora. Portanto, no momento em que este artigo foi escrito, as duas fontes principais de informações usadas para identificar a manipulação do carimbo de data/hora são $MFT e $LogFile. Essa falta de diversidade é um problema para os profissionais, pois é possível que um adversário ativo oculte/ofusque as evidências em um sistema e evite a detecção. Por último, também há uma quantidade limitada de pesquisas sobre as ferramentas de timestomping atualmente disponíveis e métodos para detectar seu uso em um sistema. Questões de pesquisa. Esses desafios atuais nos levaram às seguintes três questões de pesquisa: RQ1. Qual é a gama de artefatos que podem ser usados ​​pelos examinadores para identificar a manipulação do carimbo de data/hora em NTFS no Windows? RQ2. Quão confiáveis ​​são os artefatos (ou seja, resilientes a ofuscação ou exclusão) que estão sendo usados ​​para detecção de manipulação de carimbo de data/hora? RQ3. Além de identificar a manipulação de timestamp diretamente, podemos detectar a execução/presença de ferramentas de falsificação de timestamp? Contribuição. Este artigo tem duas contribuições principais. Primeiro, expandimos a lista de artefatos conhecidos que podem ser usados ​​para detecção de falsificação de carimbo de data/hora. Embora a literatura existente se concentre principalmente no $MFT e no $LogFile, apresentamos um novo uso de quatro artefatos/métodos existentes do Windows para detectar a manipulação do carimbo de data/hora em NTFS. Em segundo lugar, analisamos a confiabilidade desses quatro artefatos, bem como do $LogFile, ou seja, as possibilidades de excluí-los ou ofuscá-los de qualquer maneira. Para teste, executamos vários experimentos usando três ferramentas de timestomping proeminentes: Timestomp, SetMACE e nTimestomp. Por fim, como uma pequena contribuição, destacamos algumas peculiaridades dessas ferramentas, bem como apresentamos métodos para identificar sua presença em um sistema. Visão geral. O restante deste documento está organizado da seguinte forma: A seção Background fornece informações básicas sobre NTFS, carimbos de data/hora e ferramentas de carimbo de data/hora. e é seguido pela seção de trabalho anterior. O aparato e a metodologia de nosso experimento serão discutidos na Seç. 4. O núcleo deste artigo é o Sec. 5 que apresenta nossas descobertas organizadas por artefato. As duas últimas seções incluem a discussão e nossa conclusão.

2. Aprofundando

Antes de abordar os vários métodos que podem ser usados ​​para identificar a manipulação do carimbo de data/hora, existem vários conceitos e termos chave com os quais o leitor deve se familiarizar. A seguir, fornecemos um breve resumo do NTFS (New Technology File System), para mais detalhes consulte Carrier (2005). Uma lista de acrônimos comumente usados ​​para este artigo pode ser vista na Tabela 1. Leitores familiarizados com NTFS (ou seja, terminologia e arquivos relacionados a carimbos de data/hora) podem pular esta seção. Tabela 1. Resumo das siglas usadas ao longo do artigo.
Acrônimo Arquivo real
SIA Atributo $STANDARD_INFORMATION
FNA Atributo $FILE_NAME
$MFT Tabela de arquivos mestre
LNK Arquivo de link
PF Prefetchr arquivo
$LogFile Arquivo de log
$USNjrnl $UsnJrnl: $J
MACE Modificado, acessado, criado, MFT alterado
O NTFS depende do $MFT, que é um banco de dados que contém uma lista abrangente de todos os arquivos e pastas no volume. Ele reserva as primeiras 16 entradas para arquivos de sistema do Windows, que podem ser identificados por $no início de seus nomes. Eles são protegidos e ocultos do usuário por padrão (são essenciais para o sistema operacional e não se destinam a ser alterados pelo usuário). Dois desses arquivos protegidos, o $LogFile e o $USNjrnl, rastreiam as alterações feitas nos arquivos do volume e podem ser fontes valiosas de informações para um examinador que tenta detectar a manipulação do carimbo de data/hora. Cada registro no $MFT contém vários atributos que são usados ​​para organizar o conteúdo e metadados de um arquivo. Com relação aos carimbos de data/hora, há dois atributos específicos que controlam essas informações para cada arquivo. O primeiro é o atributo $STANDARD_INFORMATION (SIA), que contém quatro carimbos de data/hora exclusivos aos quais nos referimos coletivamente como MACE 1 e são descritos na Tabela 2. Usaremos uma escrita abreviada para nos referirmos a mudanças particulares, por exemplo, SIA-M representa o ‘carimbo de data e hora da última modificação no SIA. O segundo é o $FILE_NAMEatributo (FNA) que contém o nome do arquivo, o nome do diretório pai e tem seu próprio conjunto de carimbos de data/hora MACE. Os carimbos de data/hora no FNA são atualizados apenas quando um dos outros atributos armazenados no FNA também é alterado, como o nome do arquivo ou sua localização na unidade. Consequentemente, o $MFT armazena oito carimbos de data/hora diferentes para cada arquivo no volume; quatro no SIA e quatro na FNA. É importante observar que o NTFS armazena cada carimbo de data/hora como um valor de 64 bits que representa o número de nanossegundos que se passaram desde 1º de janeiro de 1601 UTC (Windows, 2018). Tabela 2. Carimbos de data e hora do sistema de arquivos (MACE).
Timestamp Em formação
Última M odificado Quando o conteúdo do arquivo foi modificado.
Último A cesso Quando o arquivo foi acessado pela última vez.
Arquivo C reation Quando o arquivo foi criado, copiado ou alterado de diretórios.
MFT E ntry alterado Quando o registro $MFT do arquivo foi atualizado.
2.1. Modificação de SIA/FNA As descobertas sobre a modificação SIA/FNA apresentadas a seguir são baseadas na análise das três ferramentas – Timestomp, SetMACE e nTimestomp. Atualmente, não temos conhecimento de nenhuma outra ferramenta de código aberto que possa alterar os carimbos de data/hora no NTFS. Observe que não cobrimos técnicas de manipulação externa (ou seja, manipulação do disco rígido de um computador desligado) ou alteração de arquivos não localizados na unidade do sistema. Para alterar os quatro carimbos de data/hora SIA, as ferramentas usam o NtSetInformationFile (API) que pode acessar e gravar em todos os quatro (Schicht, 2018 ; Lim, 2019 ; Microsoft, 2018c ; Minnaard et al., 2014). Especificamente, a API permite que um usuário defina qualquer um dos valores SIA MACE para um valor de 64 bits de sua escolha. Para o nosso experimento, presumimos que o usuário que faz as alterações nos carimbos de data/hora tem um bom entendimento das regras de carimbo de data/hora NTFS 2 e, portanto, não há possibilidade de detectar a manipulação de carimbo de data/hora olhando apenas para os valores de carimbo de data/hora em SIA ou FNA (por exemplo, definir SIA-C a 01/01/1910 às 14:15 EST; ou definindo milissegundos para todos 0). Os carimbos de data/hora no FNA são configurados para espelhar os carimbos de data/hora SIA quando o arquivo é criado e não podem ser alterados diretamente. No entanto, os valores FNA são atualizados para espelhar os valores SIA sempre que o arquivo é renomeado ou muda de localização na unidade. Assim, Schicht (2014), o autor de SetMACE, usa uma combinação de alterações SIA e movimento, conforme ilustrado na Fig. 1para obter a atualização do FNA: Primeiro, os carimbos de data/hora SIA são alterados, o arquivo é movido para um diretório diferente, fazendo com que os carimbos de data/hora no FNA atualizem e espelhem as alterações feitas no SIA. O arquivo deve ser cronometrado novamente antes de ser realocado de volta ao seu local original, porque os valores FNA serão atualizados novamente. Finalmente, os valores SIA dos arquivos são cronometrados uma última vez para garantir que sejam definidos exatamente como o usuário deseja. Este método permitiu que os carimbos de data/hora armazenados no SIA e no FNA fossem modificados com precisão de nanossegundos, dificultando a detecção da manipulação do carimbo de data/hora em NTFS. Figura 1
  1. Download: Baixe a imagem em tamanho real
Fig. 1. Processo para modificar FNA. Mais tarde, Schicht (2014) percebeu que esse método pode deixar evidências adicionais para trás no sistema e, assim, reescrever SetMACE para gravar diretamente na unidade do sistema para as versões 1.0.0.6 e mais recentes. No entanto, a Microsoft (2018a) corrigiu isso e atualmente o acesso direto à unidade do sistema não é mais permitido. Portanto, voltamos ao SetMace 1.0.0.5, que usa a API que permite alterar arquivos na unidade do sistema. Outro método para alterar carimbos de data/hora são os comandos GetFileTime e SetFileTime. O comando GetFileTime pode ser usado para recuperar os carimbos de data/hora MACE de qualquer arquivo que o usuário mal-intencionado deseja e, em seguida, o comando SetFileTime pode ser usado para copiá-los para qualquer arquivo. Este método requer acesso de gravação ao arquivo, assim como o comando NtSetInformationFile faz e também não pode alterar os carimbos de data/hora do FNA (Carvey, 2014). O método discutido anteriormente para alterar os valores FNA alterando o diretório do arquivo também deve funcionar com esses comandos, embora não o tenhamos testado. 2.2. Peculiaridades das ferramentas de timestomping As ferramentas consideradas neste artigo são: Timestomp, SetMACE e nTimestomp. Os dois primeiros são muito proeminentes e têm sido usados ​​por vários pesquisadores/profissionais; nTimestomp foi escolhido porque foi lançado recentemente em 10 de janeiro de 2019 (Lim, 2019). Timestomp: conforme mencionado, o Windows armazena timestamps em valores de 64 bits que permitem precisão de nanossegundos. Gungor (2014) descobriu que a ferramenta Timestomp trunca o valor de nanossegundos para os carimbos de data/hora que altera. Os últimos 7 dígitos no carimbo de data/hora usados ​​para descrever os nanossegundos são definidos como zero pela ferramenta. Dado que é extremamente improvável que uma série de 7 zeros aconteça, isso pode ser usado como um indicador para manipulação de carimbo de data/hora. SetMACE e nTimestomp gravam com precisão de nanossegundos e, portanto, são mais difíceis de detectar. SetMACE: Até a versão 1.0.0.6, SetMACE usava a API do Windows para alterar os timestamps SIA e o método descrito anteriormente na Fig. 1 para atualizar os timestamps FNA. A ferramenta é capaz de alterar o carimbo de data/hora de destino para um valor definido pelo usuário de 64 bits. As versões mais recentes pararam de usar a API e, em vez disso, gravaram diretamente no disco rígido que foi corrigido pelo Windows (discutido na Seção 2.1). Consequentemente, a versão 3 mais recente não funcionará no Windows mais recente.

3. Trabalho prévio

Os carimbos de data/hora e seu valor para as investigações foram discutidos na literatura, por exemplo, por Schatz et al. (2006). No entanto, a manipulação do carimbo de data/hora e sua detecção não são tão bem exploradas e existem poucos artigos de pesquisa de pares nos quais a maior parte do trabalho atual concentra seus esforços na Tabela de arquivos mestre ($MFT) e no $LogFile. 3.1. Detectando manipulação com regras de carimbo de data/hora Uma primeira abordagem foram as regras de carimbo de data/hora, que podem ser usadas para detecção de manipulação e podem ajudar na reconstrução de eventos. Chow et al. (2007) foi um dos primeiros a criar uma lista abrangente de regras que poderiam ser usadas por examinadores para identificar comportamentos específicos em NTFS. Por exemplo, “quando um grande número de arquivos com ‘fechar’ A vezes é encontrado dentro do disco rígido, é provável que esses arquivos sejam verificados por alguma ferramenta, por exemplo, software antivírus”. Embora sua pesquisa não tenha como objetivo específico identificar a manipulação do carimbo de data/hora, ela estabeleceu a base para pesquisas futuras. Bang et al. (2009)promoveu esta pesquisa analisando adicionalmente os tempos SIA-E, bem como utilizando carimbos de data/hora FNA. Os autores puderam usar essas regras de carimbo de data/hora para identificar comportamentos de usuários mal-intencionados, ou seja, ocultar informações substituindo uma pasta por outra que tinha o mesmo nome. Bang et al. (2011) também pesquisaram o comportamento do carimbo de data/hora de arquivos e pastas em várias versões de sistemas operacionais, bem como a adição de mais regras de carimbo de data/hora. Por exemplo, uma lista de ações onde os tempos MACE existentes são mantidos e uma lista de ações onde eles são alterados para o tempo da operação. Embora a pesquisa anterior tenha se concentrado no uso de regras de carimbo de data/hora para identificar ações específicas do usuário, Ding e Zou (2010)foi o primeiro a usar essas regras para identificar a manipulação de carimbo de data/hora usando um conjunto de condições como: SIA-M deve ser menor ou igual a SIA-E, SIA-C deve ser menor ou igual a FNA-C, ou SIA- C deve ser menor ou igual a SIA-A. Eles foram capazes de provar a manipulação do timestamp em um caso de exemplo, comparando os valores no FNA aos valores no SIA e identificando inconsistências. 3.2. Detectando manipulação com o $LogFile Devido ao fato de que as ferramentas e técnicas de timestomping são capazes de alterar todos os oito timestamps no $MFT com precisão de nanossegundos, nenhuma das regras mencionadas pode ser utilizada para identificar a manipulação de timestamp (contanto que um invasor siga as regras) (Jang et al., 2016). No entanto, os carimbos de data/hora antes e depois de qualquer alteração também são armazenados no $LogFile, que pode oferecer suporte a uma análise. Até onde sabemos, Cho (2013) foi o primeiro a utilizar o $LogFile para detectar a manipulação do carimbo de data/hora. O autor discutiu o $LogFile como uma técnica complementar se as regras de carimbo de data/hora falharem em detectar falsificação. Em seu exemplo, eles concluíram que, uma vez que $LogFilenão continha nenhum registro para o FNA do arquivo, esses carimbos de data/hora nunca foram atualizados. Consequentemente, a relação entre os tempos FNA e os tempos SIA agora não satisfazia as regras básicas de carimbo de data/hora e eles eram capazes de identificar a manipulação. Embora essa pesquisa tenha sido um grande avanço, um estudo ainda mais recente e abrangente foi publicado por Jang et al. (2016). Os autores usaram várias ferramentas diferentes de timestomping para fazer alterações aleatórias de tempo em um grande número de arquivos de texto. Em seguida, eles aplicaram suas regras (semelhantes às que discutimos anteriormente) para identificar a manipulação do carimbo de data/hora, mas combinaram-na com a evidência do $LogFile. Uma limitação de sua pesquisa foi o fato de que eles usaram carimbos de data/hora aleatórios para suas alterações, que frequentemente não obedeciam às regras básicas de carimbo de data/hora NTFS. 3.3. Outros métodos para detectar manipulação Minnaard et al. (2014) descobriram que os carimbos de data/hora armazenados dos índices de diretório não foram atualizados quando um carimbo de data/hora foi alterado usando acesso direto ao disco. Eles concluíram que, embora inicialmente houvesse discrepâncias, havia um método de correção de erros no Windows que posteriormente atualizou o valor e corrigiu a discrepância. Este documento também discutiu diferentes métodos usados ​​para manipulação de carimbo de data/hora, como acesso direto ao disco e uso da API do Windows. Freiling e Hösch (2018) conduziram um experimento para mostrar como alterar evidências digitais sem deixar rastros é uma tarefa difícil. Embora a pesquisa deles não tenha se concentrado nos mesmos artefatos que usamos em nossa pesquisa, algumas de suas conclusões podem ser aplicadas diretamente. Por exemplo, eles descobriram que a remoção de evidências pode complicar muito a análise de um sistema. Em vez de alterar os artefatos, achamos mais fácil excluí-los ou limpar seu conteúdo. Além disso, a noção de que há muitas maneiras diferentes de identificar se a evidência digital foi adulterada está diretamente relacionada à nossa conclusão de que quanto mais métodos os examinadores têm para identificar a manipulação do carimbo de data/hora, maior a chance de sucesso. Willassen (2008) criou uma ferramenta que foi capaz de detectar a manipulação de timestamp comparando os números de registro $MFT. Visto que novos registros $MFT são colocados no primeiro buraco da mesa, apenas olhar para os números dos registros não forneceria uma ordem cronológica precisa para quando os arquivos foram adicionados. No entanto, usando marcadores geracionais, a ferramenta do autor foi capaz de detectar a manipulação do carimbo de data/hora. Infelizmente, não conseguimos localizar a ferramenta do autor e não havia detalhes suficientes no artigo para reproduzir com precisão os resultados de nosso experimento. Os quatro arquivos que testamos neste experimento estavam na seguinte ordem com base em seus $MFTnúmeros de registro T4, T1, T3, T2. Considerando que T1 foi nosso documento de teste e T2, T3 e T4 foram todos marcados com as mesmas datas e horas nessa ordem, não há nenhuma correlação lógica entre sua ordem e quando ou se eles foram marcados. Embora não tenhamos sido capazes de replicar seus resultados, isso ainda deve ser considerado um método adicional que poderia ser usado para identificar a manipulação de carimbo de data/hora. Além de analisar os carimbos de data/hora reais, também houve pesquisas e sugestões de que as próprias ferramentas também deixam artefatos valiosos para trás. Por exemplo, Geiger (2005) pesquisou seis diferentes ferramentas anti-forenses, como o CCLeaner. Eles concluíram que todos eles falharam em apagar completamente ou ocultar evidências que podem ser devido à complexidade dos sistemas operacionais. Portanto, pode ser possível encontrar a presença de um programa em um espaço não alocado ou outros artefatos. Cowen (2013) sugeriu que as evidências relacionadas às ferramentas usadas podem ser encontradas em arquivos PF, LNKs, shell bags, jump lists e registro do Windows usados ​​mais recentemente. Além disso, eles sugeriram comparar os tempos de criação de LNKs com os tempos de criação encontrados no $MFTmas eles falharam em fornecer qualquer raciocínio, regras ou exemplos. Gungor (2014) encontrou falhas nas próprias ferramentas de timestomping. Por exemplo, o Timestomp não modifica todo o valor de tempo de 64 bits usado no NTFS e, portanto, os nanossegundos são todos definidos como zero, tornando as alterações fáceis de identificar. Singh e Singh (2018) identificaram 9 artefatos diferentes em NTFS que podem ser usados ​​para identificar a execução do programa: arquivos PF, LNKs, listas de atalhos, userassist, amcache.hve, iconcache.db, appcompatflags, appcompatcache, runMRU e muicacheandSRUDB.dat. Eles ainda testaram ferramentas anti-forenses que excluem dados do sistema, como o CCleaner, e foram capazes de encontrar evidências de que todas as ferramentas eram executadas no sistema.

4. Aparelho e metodologia

Antes de discutir o procedimento de nossos experimentos e como fomos capazes de extrair evidências, listamos todos os produtos de software, incluindo suas versões que foram utilizadas:
  • Autopsy 4.7.0
  • Oracle VM VirtualBox 5.2.16
  • Windows 10 Pro versão 1803
  • UsnJrnl2Csv 1.0.0.22
  • NTFS LogFile Parser 2.0.0.46
  • Event Log Explorer 5.0.1.4018
  • FTK Imager 4.2.0.13
  • Tableau 2018.2.0
  • SetMace 1.0.0.5
  • nTimestomp (x64) v1.1
  • Timestomp
Todas as imagens foram capturadas com FTK Imager e processadas em Autopsy para análise posterior (para extrair arquivos/artefatos específicos). Certos arquivos precisaram ser extraídos e analisados ​​com outras ferramentas de código aberto, como UsnJrnl2Csv para $USNjrnl ou NTFS LogFile Parser para $LogFile. Os CSVs resultantes foram carregados no Tableau, o que ajudou a visualizar as informações. Percebemos que há uma variedade de ferramentas que podem ser usadas para analisar artefatos específicos do NTFS, mas escolhemos essas com base na disponibilidade, facilidade de uso e boa reputação. Outra ferramenta que vale a pena mencionar que pode ser usada para analisar muitos dos mesmos dados é o Log2Timeline de Plaso (Metz, 2019). Embora não tenhamos usado essa ferramenta em nosso experimento, acreditamos que ela seria capaz de extrair muitas das mesmas informações de uma imagem forense. Imagem de teste. Começamos criando uma máquina virtual no VirtualBox com um disco rígido virtual fixo de 40 GB. O sistema operacional usado para nossos testes foi o Windows 10 (instalação padrão). Não houve partições adicionais configuradas para este teste, apenas o volume do sistema. Quatro arquivos de teste foram criados no sistema chamados: f_default.txt, f_Timestomp.txt, f_SetMACE.txt e f_nTimestomp.txt. Procedimento. Nosso experimento foi feito usando as cinco etapas básicas a seguir; os resultados são apresentados na seção de resultados experimentais:
  1. Preparação: A imagem de teste mencionada foi inicializada e todas as três ferramentas de manipulação de carimbo de data/hora foram instaladas. Além disso, permitiu a UsnJrnl $executando o seguinte comando: fsutil USN createjournal m = 1000 a = 100 c:.
  2. Manipulação de carimbo de data/hora: Cada ferramenta foi executada para realizar uma manipulação de carimbo de data/hora em seu arquivo de teste correspondente. Uma visão geral é fornecida na Tabela 3, onde listamos os arquivos de teste com seus carimbos de data/hora SIA originais juntamente com os alterados.
Tabela 3. Alterações feitas nos arquivos de teste do experimento.
Nome do arquivo SIA-C original SIA-MACE alterado A ferramenta de tempo foi executada FNA alterado?
f_default.txt 01/03/2019 às 14:15 EST N/D N/D N/D
f_Timestomp.txt 01/03/2019 às 14:16 EST 01/03/2019 às 18:31:58 EST 02/03/2019 às 14:58:23 Não
f_SetMACE.txt 01/03/2019 às 14:17 EST 01/03/2019 às 18: 31: 58: 1234567 EST 02/03/2019 às 14:59:05 Não
f_nTimestomp.txt 01/03/2019 às 14:18 EST 01/03/2019 às 18: 31: 58: 1234567 EST 02/03/2019 às 15:00:13 sim
  1. Identificação e extração de evidências: Após a manipulação dos arquivos, fizemos a imagem da máquina virtual para análise posterior. Nós extraiu o $LogFile, o UsnJrnl $quaisquer arquivos Prefetch para as ferramentas timestomping para análise posterior (os arquivos de link foram examinados em Autopsy ), os logs de eventos do Windows, e. Os artefatos extraídos foram analisados ​​posteriormente usando ferramentas de código aberto, que discutiremos na Seç. 5.
  2. Teste de confiabilidade de evidência: Após análise adicional, a máquina de teste foi inicializada novamente e tentamos excluir todas as evidências de manipulação de carimbo de data/hora no dispositivo. O objetivo era testar cada um dos artefatos que analisamos na etapa anterior e testar sua confiabilidade, ou seja, pode um invasor/malware sofisticado adulterá-los ou excluí-los.
  3. Verificação: para testar esses resultados e porque a exclusão de evidências poderia produzir novas evidências, repetimos a etapa 3 e analisamos o sistema novamente.
Vários instantâneos foram criados ao longo do experimento, o que nos permitiu analisar o impacto de cada etapa individualmente.

5. Resultados experimentais

Um aspecto essencial de nosso trabalho foi encontrar artefatos que não foram usados ​​anteriormente para identificar a manipulação de carimbo de data/hora em NTFS. A seguir, fornecemos um resumo dos artefatos que usamos em nosso experimento, juntamente com os resultados de nossos testes. No geral, investigamos os cinco artefatos a seguir:
  1. $LogFile
  2. Prefetch de arquivos
  3. $USNjrnl
  4. LNKs (arquivos de link)
  5. Logs de eventos do Windows
Embora os artefatos acima possam ser bem conhecidos na comunidade forense, até onde sabemos, não há métodos propostos para usá-los para identificar uma possível falsificação de carimbo de data/hora, com exceção do $LogFile. As próximas seções discutem cada um desses artefatos, onde cada seção explicará primeiro o próprio artefato seguido por nossas descobertas experimentais. O último parágrafo de cada seção descreve a confiabilidade dos artefatos e nossos métodos para excluir ou ofuscar as evidências que eles continham. Observe que, como será mostrado nos parágrafos de confiabilidade de dados correspondentes, um adversário ativo pode ser capaz de falsificar informações. No entanto, argumentamos que todas as evidências digitais podem ser manipuladas e, portanto, nossos resultados ainda são úteis para os profissionais. 5.1. $LogFile O $LogFile foi usado anteriormente para detectar manipulação de carimbo de data/hora, que é resumido em seg. 3. O $LogFile é um arquivo protegido do Windows e é o3rdentrada no $MFT (Schwarz, 2007). Ele rastreia as alterações feitas nos arquivos do volume e foi criado para ajudar o sistema a se recuperar de uma falha inesperada. Os registros são armazenados sequencialmente, onde cada entrada recebe um Número de Sequência de Log (LSN) exclusivo que também é armazenado no registro $MFT do arquivo relacionado. Antes que quaisquer alterações de metadados para um arquivo sejam feitas, um registro é criado no $LogFile que detalha a modificação futura e armazena uma cópia dos dados originais. Portanto, se o sistema travar, ele pode ser revertido para um estado válido. Caso contrário, o registro $LogFile será sinalizado como a mudança foi bem-sucedida (Carrier, 2005) Para que esse método de registro no diário seja bem-sucedido, ele precisa registrar todas as alterações feitas em um arquivo que, por sua vez, cria um grande número de registros. É importante observar que o $LogFile é circular, o que significa que as entradas mais antigas são substituídas pelas mais recentes quando o arquivo atinge sua capacidade máxima (Polakovic, 2016). Seu tamanho varia de acordo com o tamanho do volume do sistema, mas normalmente é de 64 MB ou menos. Isso significa que ele contém aproximadamente entre 2 e 3 h ‘de informações com o uso normal do computador (Oh, 2013). Resultados. Extraímos e analisamos o $LogFile dos instantâneos usando Autopsy  e analisamos posteriormente o arquivo com o LogFileParser. 4 Cada $LogFile extraído tinha exatamente 56.639.488 bytes (56 MB), o que coincide com a declaração anterior de que o arquivo é≤64MB. O $LogFile (após a execução dos programas) continha registros para cada um dos arquivos PF das ferramentas de timestomping, ou seja, um timestamp de quando cada ferramenta foi executada. Também conseguimos recuperar um registro para f_nTimestomp.txt que continha os carimbos de data/hora do arquivo de antes e depois de terem sido alterados. No entanto, não houve registros para f_Timestomp.txt ou f_SetMACE.txt no $LogFile em nosso teste, provavelmente devido ao tamanho pequeno do arquivo. Confiabilidade de dados. O $LogFile é protegido, sempre habilitado e registra todas as alterações de metadados no sistema. Embora não tenhamos encontrado nenhuma maneira de alterá-lo diretamente, fomos capazes de explorar a pequena capacidade e seu comportamento de armazenamento circular. Para teste, rodamos um script python para inundar o $LogFile com informações irrelevantes. O script cria um diretório temporário em um local especificado pelo usuário e, a seguir, cria, modifica, lê e exclui um arquivo. Em nosso experimento, 1000 iterações foram suficientes para produzir um estouro (na verdade, as primeiras 202 foram sobrescritas). Embora isso exija o uso de um script adicional, é uma maneira eficaz de limpar o conteúdo do $LogFile. Alternativamente, pode-se esperar até que o arquivo seja sobrescrito naturalmente (consulte a Seção 5). 5.2. Arquivos Prefetch(Prefetch Files) Os arquivos PF são criados pelo sistema sempre que um programa é executado pela primeira vez e são usados ​​para acelerar futuras execuções; sempre que um programa é executado novamente, o Windows tenta localizar o arquivo de Prefetch associado. A convenção de nomenclatura para arquivos PF é simples, pois começa com o nome do programa associado (incluindo sua extensão), que é seguido por um hífen e 8 caracteres que representam um hash do caminho do arquivo de onde o aplicativo foi executado (McQuaid, 2014b) Mais relevante, esses arquivos PF armazenam carimbos de data/hora para as oito execuções mais recentes e permanecem no sistema mesmo que o software seja excluído. Resultados. Para analisar os arquivos PF no sistema, montamos uma cópia de nossa imagem e apontamos uma ferramenta chamada WinPrefetchView 5 na pasta de Prefetch do sistema de teste, geralmente C:/Windows/Prefetch. Como esperado, todas as ferramentas executadas durante nosso experimento criaram arquivos PF. Naturalmente, esses arquivos PF têm seu próprio registro $MFT e, portanto, seu próprio conjunto de carimbos de data/hora, que podem indicar a primeira vez que o programa foi executado. Além disso, os arquivos PF continham carimbos de data/hora para cada execução, conforme mostrado na Tabela 4. Além dos timestamps, também sabemos que cada programa permaneceu no mesmo local/diretório devido aos hashes idênticos. Deve-se notar que o caminho do arquivo que está sendo hash também inclui o nome do programa que está sendo executado, portanto, programas diferentes (ou renomeados) executados a partir do mesmo diretório não terão hashes correspondentes. Tabela 4. Prefetch de arquivos para ferramentas de timestomping e seus tempos de execução.
Arquivo Tempo de execução do programa
Timestomp.exe-C3A5003F.pf 02/03/2019 às 14:58:23
SetMace.exe-9AD6A728.pf 02/03/2019 às 14:59:06
nTimestomp.exe-295C9CCD.pf 02/03/2019 às 15:00:14
nTimestomp.exe-295C9CCD.pf 02/03/2019 às 15:00:41
nTimestomp.exe-295C9CCD.pf 02/03/2019 às 15:01:08
Conforme discutido na Seç. 2.1, modificar os valores do carimbo de data/hora no FNA requer que o usuário acione uma atualização natural do sistema de arquivos. Para conseguir isso, a ferramenta de timestomping deve ser executada no mínimo três vezes para sobrescrever os valores SIA enquanto move o arquivo de destino. Portanto, os arquivos PF podem ser usados ​​para detectar essa ação, analisando os carimbos de data/hora das oito vezes anteriores em que o programa foi executado. Por exemplo, Tabela 4 mostra que nTimestomp foi executado três vezes em menos de 60s. Isso pode servir como uma indicação de que os valores de FNA também podem ter sido manipulados. Obviamente, se uma ferramenta de timestomping automatizar esse processo (e não precisar ser executada três vezes), esse método é ineficaz. Em geral, os arquivos PF são uma boa fonte de evidência ao tentar identificar programas maliciosos em execução no sistema e devem ser utilizados por examinadores. Confiabilidade de dados. Os arquivos PF são arquivos normais do Windows e, portanto, excluí-los pode ser feito navegando até a pasta de Prefetch. Devido ao fato de que esses arquivos podem ser excluídos individualmente e os outros arquivos de PF permanecem inalterados, é difícil para um examinador identificar quando há informações faltando nesta pasta. No entanto, deve-se notar que quando processamos a imagem final na Autopsy, conseguimos recuperar alguns dos dados para o arquivo SetMACE PF. Os carimbos de data/hora SIA e FNA do arquivo PF foram criados em espaço não alocado, mas o conteúdo do arquivo não. Isso significa que não foi possível analisar os tempos de execução que normalmente são armazenados no arquivo. Embora nenhum dos outros arquivos PF tenha sido recuperado neste estudo, certamente é possível extrair arquivos inteiros de um espaço não alocado na memória. 5,3. Jornal $USN O $USNjrnl, às vezes referido como o diário de mudança, é um arquivo de log em NTFS que mantém registro de qualquer alteração feita nos arquivos. Os diários de mudança podem ser criados ou excluídos usando os comandos a seguir:
    • fsutil USN createjournal m = 1000 a = 100 c: cria um novo diário e permite que o sistema de arquivos acompanhe as alterações, onde m é o tamanho máximo, a é o delta de alocação e c: é a unidade que $USNjrnl será usado em (Microsoft, 2017).
    • fsutil USN deletejournal/dc: exclui o diário que essencialmente despeja seu conteúdo em um espaço não alocado.
O $USNjrnl também é um arquivo protegido do Windows, o que torna mais difícil alterar ou excluir. O arquivo está localizado na pasta $Extend, que é a 11º entrada no $MFT (Carrier, 2005, p. 202). Na pasta $Extend, há um arquivo denominado $USNJrnl: $Max que contém informações básicas sobre o próprio diário e um arquivo denominado $USNJrnl: $J que contém as entradas reais do diário. Para este artigo, nos concentraremos no último dos dois e usaremos o termo $USNjrnl como sinônimo. Quando ativado, ele pode ser extraído usando Autopsy antes de ser analisado com UsnJrnl2Csv. 6 O diário mantém vários eventos, mas o mais importante é que possui um registro para cada alteração de arquivo no volume (categoria de evento: BASIC_INFO_CHANGE). Embora o diário funcione de forma semelhante ao $LogFile, deve-se observar que ele não registra os dados originais ou quais alterações foram feitas. Em vez disso, ele registra a hora em que uma mudança ocorreu, o nome do arquivo associado e a categoria da mudança que ocorreu. Para esta pesquisa, focamos principalmente em registros que se enquadram na categoria BASIC_INFO_CHANGE, que inclui quaisquer alterações relacionadas aos metadados e carimbos de data/hora do arquivo (Microsoft, 2018d). Além disso, cada registro no $USNjrnl contém um identificador único denominado Número de Sequência de Atualização (USN), que também pode ser encontrado em qualquer SIA de arquivo. Resultados. Ao analisar o $USNjrnl, encontramos registros BASIC_INFO_CHANGE para cada um dos três arquivos que modificamos. Esses registros nos forneceram a última vez em que o arquivo de teste teve seus metadados alterados. Consequentemente, se $USNjrnl registrou uma alteração nos metadados do arquivo, o SIA-E do arquivo também deve mostrar essas alterações. Conforme visto na Tabela 5 (onde comparamos os tempos SIA-E do arquivo com os tempos de criação para os registros $USNjrnl BASIC_INFO_CHANGE), há discrepâncias. Todos os arquivos de teste em nosso experimento tinham BASIC_INFO_CHANGE registros criados em 02/03/2019, mas seus horários SIA-E foram atualizados pela última vez em 01/03/2019. Este é um forte indicador de que os carimbos de data/hora desses arquivos foram alterados. Tabela 5. Tempos de criação de registro BASIC_INFO_CHANGE comparados aos tempos de SIA-E para nossos arquivos de teste.
Arquivo Tempo de mudança de metadados
f_Timestomp.txt (SIA-E) 01/03/2019 às 18:31:58 EST
f_Timestomp.txt (registro USNJ) 02/03/2019 às 14:58:23 EST
f_SetMACE.txt (SIA-E) 01/03/2019 às 18:31:58 EST
f_SetMACE.txt (registro USNJ) 02/03/2019 às 14:59:06 EST
f_nTimestomp.txt (SIA-E) 01/03/2019 às 18:31:58 EST
f_nTimestomp.txt (registro USNJ) 02/03/2019 às 15:00:14 EST
Além disso, os registros $USNjrnl armazenados nos arquivos PF, ou seja, sempre que um programa foi executado (e o arquivo PF alterado) um registro BASIC_INFO_CHANGE foi encontrado. Consequentemente, procuramos programas ou arquivos que tinham registros BASIC_INFO_CHANGE no mesmo tempo ou próximo aos arquivos de teste. Essas comparações podem ser vistas na Tabela 6 e mostram que cada um dos arquivos de teste teve uma alteração de metadados ao mesmo tempo que um arquivo PF foi atualizado. Essa correlação pode ajudar os examinadores a identificar potencialmente quais programas foram executados para modificar os carimbos de data/hora. Além disso, se $USNjrnl não estiver disponível, essa mesma correlação pode ser feita usando os oito tempos de execução mais recentes armazenados em um arquivo PF. Tabela 6. Registros BASIC_INFO_CHANGE do $USNjrnl.
Arquivo Tempo de Mudança
f_Timestomp.txt 02/03/2019 às 14:58:23 EST
Timestomp.exe-C3A5003F.pf 02/03/2019 às 14:58:23 EST
f_SetMACE.txt 02/03/2019 às 14:59:06 EST
SetMace.exe-9AD6A728.pf 02/03/2019 às 14:59:06 EST
f_nTimestomp.txt 02/03/2019 às 15:00:14 EST
nTimestomp.exe-295C9CCD.pf 02/03/2019 às 15:00:14 EST
O $USNjrnl também cria um registro USN_REASON_FILE_CREATE 7 sempre que um arquivo é adicionado ao sistema (Microsoft, 2018d). Esse registro pode ser usado para identificar quando a ferramenta de timestomping chegou pela primeira vez ao sistema, o que poderia ser uma peça crucial de evidência em uma investigação. Além disso, também recuperamos um registro de criação de arquivo para os arquivos PF associados às ferramentas de timestomping que nos permitiu identificar quando as ferramentas foram executadas pela primeira vez no sistema. Confiabilidade de dados. Um intruso poderia mover o jornal para o espaço alocado a executar o fsutil usn deletejournal/DC: comando e criar uma nova revista no mesmo local executando o fsutil USN m createjournal = 1000 a = 100 c: de comando. Embora a limpeza de $USNjrnl seja simples, esses comandos acionam o Windows para registrar um evento em seu log de eventos do aplicativo: O ID de evento 3079 do Windows é criado quando $USNjrnl é excluído. Isso pode ser uma boa indicação para um examinador de que mais manipulação de dados pode ter ocorrido no sistema. Com base em nossos achados, concluímos que, por ser fácil de excluir, não deve ser considerado uma fonte confiável de informações para os examinadores. 5.4. Arquivos de link LNKs são essencialmente atalhos para arquivos locais que são criados manualmente pelo usuário ou automaticamente pelo sistema de arquivos. A mais comum das duas opções é o último caso: sempre que um arquivo local é criado ou aberto pela primeira vez, um LNK é criado em C:/Users/NAME/AppData/Roaming/Microsoft/Windows/Recent (McQuaid, 2014a). Todos os LNKs usados ​​em nossa análise foram recuperados deste local e criados automaticamente. Além disso, os LNKs contêm o caminho do arquivo para o arquivo associado, bem como informações adicionais sobre o local de armazenamento do arquivo, incluindo o nome do volume e potencialmente o endereço MAC do dispositivo remoto em que o arquivo está localizado. Mais importante ainda, cada LNK tem sua própria entrada $MFT que pode ser analisada. Resultados. Durante nosso experimento, testamos e confirmamos que sempre que um arquivo é aberto na máquina local (clicando diretamente nele ou localizando-o no explorador de arquivos), os tempos SIA-A e SIA-E do LNK associados também são atualizados. Portanto, os carimbos de data/hora SIA-A e SIA-E para o LNK devem corresponder aproximadamente aos carimbos de data/hora de seu arquivo associado. Esta regra exclui os carimbos de data/hora SIA-M e SIA-C do arquivo porque eles podem variar entre um arquivo e seu LNK correspondente. Um exemplo é fornecido na Tabela 7 que mostra várias discrepâncias ao comparar os carimbos de data/hora SIA dos dois arquivos. O arquivo padrão que criamos durante o experimento retrata a relação esperada: a diferença entre os dois timestamps está na faixa de segundos. Por outro lado, existem diferenças significativas para os arquivos manipulados, uma vez que nunca foram acessados ​​diretamente pelo usuário. Tabela 7. Teste os carimbos de data/hora SIA do arquivo em comparação com os carimbos de data/hora SIA do LNKs (extraídos diretamente da Autopsy ).
Arquivo SIA-M SIA-E SIA-A SIA-C
f_Deafult.lnk 01/03/2019 14:15:17 EST 01/03/2019 14:15:17 EST 01/03/2019 14:15:17 EST 01/03/2019 14:15:17 EST
f_Deafult.txt 01/03/2019 14:15:27 EST 01/03/2019 14:15:27 EST 01/03/2019 14:15:30 EST 01/03/2019 14:14:59 EST
f_Timestomp.lnk 01/03/2019 14:16:14 EST 01/03/2019 14:16:14 EST 01/03/2019 14:16:14 EST 01/03/2019 14:16:14 EST
f_Timestomp.txt 01/03/2019 18:31:58 EST 01/03/2019 18:31:58 EST 01/03/2019 18:31:58 EST 01/03/2019 18:31:58 EST
f_SetMACE.lnk 01/03/2019 14:17:29 EST 01/03/2019 14:17:29 EST 01/03/2019 14:17:29 EST 01/03/2019 14:17:29 EST
f_SetMACE.txt 01/03/2019 18:31:58 EST 01/03/2019 18:31:58 EST 01/03/2019 18:31:58 EST 01/03/2019 18:31:58 EST
f_nTimestomp.lnk 01/03/2019 14:18:10 EST 01/03/2019 14:18:10 EST 01/03/2019 14:18:10 EST 01/03/2019 14:17:17 EST
f_nTimestomp.txt 01/03/2019 18:31:58 EST 01/03/2019 18:31:58 EST 01/03/2019 18:31:58 EST 01/03/2019 18:31:58 EST
Embora isso possa ser um indicador para manipulação de carimbo de data/hora, é importante observar que o tempo SIA-A pode ser atualizado por outros programas que não atualizariam os carimbos de data/hora do LNK, como um scanner antivírus (Chow et al., 2007). Por exemplo, a execução de uma varredura com o Windows Defender confirmou que os carimbos de data/hora SIA-A para todos os arquivos de teste foram atualizados (os outros três carimbos de data/hora não foram afetados). Se houver uma varredura antivírus que atualizou o horário SIA-A, o horário SIA-E ainda poderá ser usado. Nota lateral: Um LNK não pode ser criado para um arquivo que não existe, ou seja, o horário SIA-C do arquivo não pode ser no futuro. O horário SIA-C do LNK deve ser igual ou posterior ao horário SIA-C listado para seu arquivo associado. Essa discrepância também pode ser vista na Tabela 7, onde os tempos SIA-C para todos os três arquivos de teste manipulados são 4 h após seus tempos SIA-C LNK associados. Da mesma forma, se o horário SIA-A de um LNK for atualizado, o horário SIA-A do arquivo correspondente também deverá ser atualizado. O tempo SIA-A de um LNK deve ser igual ou anterior ao tempo SIA-A do arquivo real. Confiabilidade de dados. Semelhante aos arquivos PF, os LNKs são arquivos normais do Windows que podem ser excluídos facilmente. Singh e Singh (2016) pesquisaram extensivamente os LNKs e descobriram que, embora eles pudessem ser excluídos, era possível recuperar algumas ou todas as informações do espaço não alocado. Eles também descobriram que se um LNK fosse modificado de alguma forma, as alterações seriam revertidas assim que o arquivo fosse acessado novamente. Em nosso experimento, pudemos criar um LNK para cada um de nossos documentos de teste. No entanto, além dos nomes dos arquivos, não conseguimos recuperar nenhuma informação. Também deve ser observado que um novo LNK não será criado até que o arquivo seja acessado novamente. 5.5. Logs de eventos do Windows O Windows mantém registros de eventos que acontecem no sistema, que são organizados em várias categorias e arquivos de registro separados: o registro do aplicativo, o registro do sistema e o registro de segurança (Microsoft, 2018b). Embora esses logs tenham uma coleção diversificada de dados, nos concentramos no log do sistema, que mantém eventos que nos permitem rastrear a atividade do usuário. Especificamente, um evento com o número de ID 7001 é criado quando um usuário efetua login; o logoff cria um evento 7002. Portanto, foi possível criar uma linha do tempo de quando o usuário estava ativo, que pode ser cruzada com outros carimbos de data/hora no sistema (carimbos de data/hora fora das sessões ativas do usuário são suspeitos). Resultados. A Autopsy conseguiu extrair o artefato e o abrimos localmente com um programa chamado Event Log Explorer. 8 Um exemplo de atividade do usuário para nosso experimento é ilustrado na Tabela 8. Se os horários SIA-C ou SIA-M estiverem fora de uma sessão ativa, é uma indicação de que ocorreu manipulação do carimbo de data/hora. Os tempos SIA-A e SIA-E não foram incluídos devido ao fato de que podem ter sido atualizados por um software antivírus ou algum outro programa em execução como serviço em segundo plano. Para os nossos ficheiros de experiências foram criadas fora de uma sessão de utilizador activa (comparar Tabela 7 vs. Tabela 8). Tabela 8. Tempos do usuário ativo de acordo com os eventos do sistema Windows.
Encontro Hora de login Hora de logoff
01/03/2019 13:19:09 EST 13:28:09 EST
01/03/2019 13:28:11 EST 14:52:03 EST
02/03/2019 14:37:03 EST 15:02:17 EST
02/03/2019 16:58:13 EST 17:13:22 EST
Confiabilidade de dados. Tanto o registro do aplicativo quanto o registro do sistema podem ser limpos clicando com o botão direito do mouse no visualizador de eventos do Windows e selecionando a opção limpar registro. No entanto, esta ação dispara um novo evento (104) no log do sistema, que inclui a hora em que foi apagado e o usuário que o apagou. Embora os logs de eventos do Windows tenham sido a fonte de informação mais persistente, eles não conseguem reter nenhuma evidência que pudesse ser usada para identificar a manipulação do carimbo de data/hora.

6. Discussão

As descobertas de trabalhos anteriores e nosso experimento mostraram que os carimbos de data/hora podem ser uma fonte valiosa de evidência, mas um adversário sofisticado poderia manipulá-los. A seguir, responderemos às três questões de pesquisa propostas na introdução. [RQ1] Qual é a gama de artefatos que podem ser usados ​​pelos examinadores para identificar a manipulação do carimbo de data/hora em NTFS no Windows? Embora a literatura existente se concentrasse principalmente em $MFT (carimbos de data/hora SIA/FNA) e $LogFile para detectar falsificações de carimbo de data/hora, encontramos quatro novos artefatos: $USNjrnl, arquivos PF, LNKs e logs de eventos do Windows. Esses artefatos aumentam a diversidade de artefatos disponíveis para os examinadores e, portanto, complementam o trabalho anterior. Cada um desses artefatos tem seu próprio valor exclusivo e dados relacionados à manipulação de carimbo de data/hora. Em comparação com o trabalho anterior, as novas descobertas dar examinadores mais ‘longo prazo’ artefatos como arquivos PF e LNK em comparação com o $LogFile e UsnJrnl $cujos dados podem ser substituídos naturalmente com bastante rapidez. Em geral, percebemos que há muitos (meta) dados disponíveis e que podemos ter perdido outros artefatos durante nossos experimentos. Por exemplo, Schicht (2014), em sua descrição da ferramenta SetMACE, sugeriu que evidências de falsificação de tempo também poderiam ser potencialmente recuperadas de volumes de sombra. A importância dos dados de volume de sombra foi abordada por Leschke e Nicholas (2013) que criaram uma ferramenta para visualizar suas alterações, ou seja, os timestamps de um arquivo sendo alterados. Esse conceito pode ser aplicado em uma escala ainda maior, executando comparações com backups inteiros, tentando identificar comportamento suspeito. No entanto, mais pesquisas são necessárias para concluir a viabilidade de detecção de falsificação de carimbo de data/hora. [RQ2] Quão confiáveis ​​são os artefatos (ou seja, resilientes à ofuscação ou exclusão) que estão sendo usados ​​para detecção de manipulação de carimbo de data/hora? Nossos experimentos mostraram que nenhum dos cinco artefatos que testamos neste artigo era uma fonte consistentemente confiável para identificar falsificações de carimbo de data/hora, pois eles não eram habilitados por padrão ($USNjrnl) ou poderiam ser excluídos/explorados. Um aspecto positivo era que a adulteração de artefatos ocasionalmente deixava para trás outros artefatos (mais permanentes). Por exemplo, limpar o log de eventos do Windows resultou em um novo evento do Windows. No entanto, esses artefatos são meramente suspeitos e não provam falsificação de carimbo de data/hora. Conforme apontado por Yoo et al. (2010), existe a possibilidade de extrair dados excluídos de um espaço não alocado. Durante nossos experimentos, só fomos capazes de esculpir arquivos PF e LNKs usando Autopsy, mas pode haver ferramentas que têm a capacidade de recuperar registros excluídos do $LogFile e do $USNjrnl. Trabalhos futuros podem examinar técnicas especializadas capazes de recuperar esses artefatos. Por outro lado, a Microsoft impôs restrições no NFTS que tornou mais difícil adulterar alguns artefatos (por exemplo, nenhuma gravação de disco direta no volume do sistema, nenhuma atualização de carimbo de data/hora FNA e arquivos protegidos do Windows não podem ser alterados). Uma solução potencial poderia ser identificar o uso indevido de comandos de configuração de tempo na API do Windows. Embora esses comandos sejam usados ​​em muitos programas benignos, eles não devem permitir a entrada do usuário, mas, em vez disso, dependem do relógio interno do computador. Para pesquisas futuras, recomendamos que, além de encontrar novos artefatos, também se discuta sua confiabilidade. Por outro lado, o sistema operacional deve tornar mais difícil adulterar metadados, colocando mais restrições em sua API ou desenvolver métodos para detectar mudanças, por exemplo, um ‘Blockchain local’ que captura informações e não permite mudanças (semelhante a Sutton e Samavi (2017)). [RQ3] Além de identificar a manipulação de timestamp diretamente, podemos detectar a execução/presença de ferramentas de falsificação de timestamp? Durante nossos experimentos, fomos capazes de detectar a presença e execução de ferramentas de timestomping utilizando os arquivos PF. Além disso, um examinador pode realizar buscas em cadeia no meio em questão para encontrar evidências. Observe, se um adversário mascarou o nome da ferramenta antes da execução (por exemplo, Windows/System32/svchost.exe), este procedimento não terá êxito (MITER, a). Semelhante à forma como o malware pode ser detectado por assinaturas exclusivas ou seu comportamento, pode-se criar assinaturas para ferramentas de timestomping populares (Idika e Mathur, 2007 ; Conlan et al., 2016). Por exemplo, em nosso cenário Timestomp foi sinalizado pelo Windows Defender e Magnet AXIOM versão 1.2.2.7502 como uma ferramenta anti-forense (SetMACE e nTimestomp não foram sinalizados). Se o registro da ferramenta de segurança estiver habilitado, o Timestomp pode aparecer em outro artefato (registros específicos do aplicativo). Por último, essas assinaturas podem ser usadas para impedir proativamente as ferramentas de timestomping de alterar os carimbos de data/hora.

7. Conclusão

A falsificação de carimbo de data/hora se tornou popular e muitos grupos de hackers e programas maliciosos utilizam essas técnicas para ocultar evidências e impedir investigações. Portanto, é essencial que pesquisadores e profissionais tenham vários artefatos e métodos para detectar falsificações de carimbo de data/hora. Quanto mais artefatos os examinadores sabem para identificar a manipulação do carimbo de data/hora, mais difícil se torna para um usuário mal-intencionado ofuscar todos os rastros. Neste artigo, propomos quatro novos métodos que não foram usados ​​anteriormente na literatura revisada por pares para detectar a manipulação do carimbo de data/hora: $USNjrnl, arquivos PF, LNKs e logs de eventos do Windows. Esses artefatos podem conter evidências de falsificação de carimbo de data/hora, fornecendo carimbos de data/hora adicionais e inalterados, bem como evidências de atividades de software suspeitas. Com base em nossas descobertas, propomos as cinco regras a seguir que podem ser usadas para detectar inconsistências de carimbo de data/hora em NTFS no Windows:
  1. O SIA-E para um arquivo deve ser semelhante ao registro BASIC_INFO_CHANGE mais recente para o arquivo no $USNjrnl.
  2. O SIA-E para um arquivo LNK deve ser idêntico ao SIA-E do arquivo associado.
  3. O SIA-C para um arquivo LNK deve ser igual ou mais recente que o SIA-C de seu arquivo associado.
  4. O SIA-A para um arquivo LNK deve ser igual ou anterior ao SIA-A de seu arquivo associado.
  5. Os horários SIA-C e SIA-M para um arquivo não podem ser em um momento em que não haja um usuário conectado.
Por outro lado, este artigo também explorou a confiabilidade de diferentes artefatos usados ​​para detectar falsificações de carimbo de data/hora. Concluímos que nenhum dos artefatos testados é uma fonte confiável de informações, pois podem ser explorados por um invasor sofisticado ou software malicioso. Além disso, até onde sabemos, não existem métodos atuais que possam comprovar de forma consistente a manipulação do carimbo de data/hora, pois a evidência sempre pode ser excluída ou alterada para evitar a detecção. Consequentemente, recomendamos o uso de uma combinação dos métodos mencionados anteriormente, como regras de carimbo de data/hora e análise de $LogFile, juntamente com outros artefatos do sistema, como arquivos LNKs e PF, para aumentar as chances de detectar ferramentas e técnicas de carimbo de data/hora. Além disso, as evidências armazenadas no $LogFile e $USNjrnl se torna obsoleto após um certo período de tempo, o que cria outro conjunto de problemas para os investigadores, pois a análise na máquina-alvo pode não ser feita por um longo período de tempo. Embora esta pesquisa tenha sido um primeiro passo sólido em uma visão mais ampla e holística da detecção de manipulação de carimbo de data/hora, este domínio precisa de mais pesquisas.

Referências

Alperovitch, 2016 D. AlperovitchBears in the midst: intrusion into the democratic national committee CrowdStrike Blog, 15 (2016) Google Scholar Bang et al., 2009 J. Bang, B. Yoo, J. Kim, S. LeeAnalysis of time information for digital investigation 2009 Fifth International Joint Conference on INC, IMS and IDC, IEEE (2009), pp. 1858-1864 CrossRefView Record in ScopusGoogle Scholar Bang et al., 2011 J. Bang, B. Yoo, S. LeeAnalysis of changes in file time attributes with file manipulation Digit. Invest., 7 (2011), pp. 135-144 ArticleDownload PDFView Record in ScopusGoogle Scholar Buchholz and Spafford, 2004 F. Buchholz, E. SpaffordOn the role of file system metadata in digital forensics Digit. Invest., 1 (2004), pp. 298-309 ArticleDownload PDFView Record in ScopusGoogle Scholar Carrier, 2005 B. CarrierFile System Forensic Analysis Addison-Wesley Professional (2005) Google Scholar Carvey, 2014 H. CarveyWindows Forensic Analysis Toolkit: Advanced Analysis Techniques for Windows 8 Elsevier (2014) Google Scholar Cho, 2013 G.-S. ChoA computer forensic method for detecting timestamp forgery in NTFS Comput. Secur., 34 (2013), pp. 36-46 ArticleDownload PDFView Record in ScopusGoogle Scholar Chow et al., 2007 K.-P. Chow, F.Y. Law, M.Y. Kwan, P.K. LaiThe rules of time on NTFS file system Second International Workshop on Systematic Approaches to Digital Forensic Engineering (SADFE’07), IEEE (2007), pp. 71-85 CrossRefView Record in ScopusGoogle Scholar Conlan et al., 2016 K. Conlan, I. Baggili, F. BreitingerAnti-forensics: furthering digital forensic science through a new extended, granular taxonomy Digit. Invest., 18 (2016), pp. 66-75 Google Scholar Cowen, 2013 D. CowenDaily blog #130: detecting fraud sunday funday 10/27/13 part 3 – setmace http://www.learndfir.com/2013/10/31/daily-blog-130-detecting-fraud-sunday-funday-102713-part-3-setmace/ (2013) Google Scholar Ding and Zou, 2010 X. Ding, H. ZouReliable Time Based Forensics in NTFS School of Software, Shanghai Jiao Tong University (2010), pp. 1-2 CrossRefGoogle Scholar Freiling and Hösch, 2018 F. Freiling, L. HöschControlled experiments in digital evidence tampering Digit. Invest., 24 (2018), pp. S83-S92 ArticleDownload PDFView Record in ScopusGoogle Scholar Geiger, 2005 M. GeigerEvaluating Commercial Counter-forensic Tools DFRWS (2005) Google Scholar Gungor, 2014 A. GungorDate forgery analysis and timestamp resolution https://www.meridiandiscovery.com/articles/date-forgery-analysis-timestamp-resolution/ (2014) Google Scholar Hannon, 2018 M.J. Hannon Metadata in Civil and Criminal Discovery–Part ii, vol 35, The Computer & Internet Lawyer (2018) Idika and Mathur, 2007 N. Idika, A.P. MathurA Survey of Malware Detection Techniques Purdue University (2007), p. 48 View Record in ScopusGoogle Scholar Jang et al., 2016 D.-I. Jang, G.-J.A.H. Hwang, K. KimUnderstanding anti-forensic techniques with timestamp manipulation 2016 IEEE 17th International Conference on Information Reuse and Integration (IRI), IEEE (2016), pp. 609-614 View Record in ScopusGoogle Scholar Koen and Olivier, 2008 R. Koen, M.S. OlivierThe Use of File Timestamps in Digital Forensics ISSA, Citeseer (2008), pp. 1-16 View Record in ScopusGoogle Scholar Leschke and Nicholas, 2013 T.R. Leschke, C. NicholasChange-link 2.0: a digital forensic tool for visualizing changes to shadow volume data Proceedings of the Tenth Workshop on Visualization for Cyber Security, ACM (2013), pp. 17-24 CrossRefView Record in ScopusGoogle Scholar Lim, 2019 B. Limntimetools https://github.com/limbenjamin/nTimetools (2019) Google Scholar McQuaid, 2014a J. McQuaidForensic analysis of lnk files https://www.magnetforensics.com/blog/forensic-analysis-of-lnk-files/ (2014) Google Scholar McQuaid, 2014b J. McQuaidForensic analysis of prefetch files in windows https://www.magnetforensics.com/blog/forensic-analysis-of-prefetch-files-in-windows/ (2014) Google Scholar Metz, 2019 J. MetzPlaso log2timeline https://github.com/log2timeline/plaso (2019) Google Scholar Microsoft, 2017 MicrosoftFsutil usn https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil-usn (2017) Google Scholar Microsoft, 2018a MicrosoftChanges to the file system and to the storage stack to restrict direct disk access and direct volume access in windows vista and in windows server 2008 https://support.microsoft.com/en-us/help/942448/changes-to-the-file-system-and-to-the-storage-stack-to-restrict-direct (2018) Google Scholar Microsoft, 2018b MicrosoftEvent logging https://docs.microsoft.com/en-us/windows/desktop/eventlog/event-logging (2018) Google Scholar Microsoft, 2018c MicrosoftNtSetInformationFile function https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-ntsetinformationfile (2018) Google Scholar Microsoft, 2018d MicrosoftRead_usn_journal_data_v0 structure https://docs.microsoft.com/en-us/windows/desktop/api/WinIoCtl/ns-winioctl-read_usn_journal_data_v0 (2018) Google Scholar Minnaard et al., 2014 W. Minnaard, C. de Laat, M. van Loosen MScTimestomping ntfs https://delaat.net/rp/2013-2014/p48/report.pdf (2014) Google Scholar MITRE (a) MITRE (a)Masquerading https://attack.mitre.org/techniques/T1036/ Google Scholar MITRE (b) MITRE (b)Timestomp https://attack.mitre.org/techniques/T1099/ Google Scholar Novetta, 2016 NovettaLoaders Installers and Uninstallers Report Operation Blockbuster (2016) Google Scholar Oh, 2013 J. OhNTFS log tracker http://forensicinsight.org/wp-content/uploads/2013/06/F-INSIGHT-NTFS-Log-TrackerEnglish.pdf (2013) Google Scholar Polakovic, 2016 P. PolakovicNTFS LogFile parser https://www.codeproject.com/Tips/1072219/NTFS-LogFile-Parser (2016) Google Scholar Schatz et al., 2006 B. Schatz, G. Mohay, A. ClarkA correlation method for establishing provenance of timestamps in digital evidence Digit. Invest., 3 (2006), pp. 98-107 ArticleDownload PDFView Record in ScopusGoogle Scholar Schicht, 2014 J. SchichtSetMACE https://github.com/jschicht/SetMace (2014) Google Scholar Schicht, 2018 J. Schichtmft2csv – setmace.wiki https://code.google.com/archive/p/mft2csv/wikis/SetMACE.wiki (2018) Google Scholar Schwarz, 2007 T. SchwarzNtfs Architecture for x86-Based Systems (2007) Google Scholar Singh and Singh, 2016 B. Singh, U. SinghA forensic insight into windows 10 jump lists Digit. Invest., 17 (2016), pp. 1-13 ArticleDownload PDFCrossRefView Record in ScopusGoogle Scholar Singh and Singh, 2018 B. Singh, U. SinghProgram execution analysis in windows: a study of data sources, their format and comparison of forensic capability Comput. Secur., 74 (2018), pp. 94-114 ArticleDownload PDFView Record in ScopusGoogle Scholar Sky, 2017 C. SkyOperation wilted tulip: exposing a cyber espionage apparatus https://www.clearskysec.com/wp-content/uploads/2017/07/Operation_Wilted_Tulip.pdf (2017) Google Scholar Sutton and Samavi, 2017 A. Sutton, R. SamaviBlockchain enabled privacy audit logs C. d’Amato, M. Fernandez, V. Tamma, F. Lecue, P. Cudré-Mauroux, J. Sequeda, C. Lange, J. Heflin (Eds.), The Semantic Web – ISWC 2017, Springer International Publishing, Cham (2017), pp. 645-660 CrossRefView Record in ScopusGoogle Scholar Willassen, 2008 S.Y. WillassenFinding evidence of antedating in digital investigations 2008 Third International Conference on Availability, Reliability and Security (2008), pp. 26-32 CrossRefView Record in ScopusGoogle Scholar Windows, 2018 WindowsFile times https://docs.microsoft.com/en-us/windows/desktop/sysinfo/file-times (2018) Google Scholar Works, 2015 S. WorksThreat group-3390 targets organizations for cyberespionage https://www.secureworks.com/research/threat-group-3390-targets-organizations-for-cyberespionage (2015) Google Scholar Yoo et al., 2010 B. Yoo, J. Park, J. Bang, S. LeeA study on a carving method for deleted ntfs compressed files 2010 3rd International Conference on Human-Centric Computing, IEEE (2010), pp. 1-6 CrossRefView Record in ScopusGoogle Scholar 1 Note, sometimes also referred to as MACb where b stands for birth. 2 Here a rule is a logical behavior of timestamps, e.g., “When the SIA-M time is equal to the SIA-C time, the file has neither been modified nor copied from another disk location. It is suggested that the file is still intact and has not been updated.” (Chow et al., 2007). 3 At the time of writing this paper, the latest version is 1.0.0.16. 4 https://github.com/jschicht/LogFileParser (last accessed 2019-04-25). 5 https://www.nirsoft.net/utils/win_prefetch_view.html (last accessed 2019-04-25). 6 https://github.com/jschicht/UsnJrnl2Csv (last accessed 2019-04-25). 7 Another category instead of the BASIC_INFO_CHANGE. 8 https://eventlogxp.com/download.html(last accessed 2019-04-25). © 2020 The Author(s). Published by Elsevier Ltd.

Aprenda mais no curso CFID

Gostou do artigo? Conheça o curso Computação Forense e Investigação Digital.

Este curso tem como objetivo apresentar os conceitos da Computação Forense e métodos de Investigação Digital, sendo baseado no conteúdo apresentado nas certificações mais conhecidas do mercado.

Hospedagem de site

digitalocean, excelente custo benefício.

Clique abaixo e aproveite!