quinta-feira, 3 de dezembro de 2009

Tudo (ou quase tudo) que você sempre quis saber sobre Anti-Forense, mas não teve tempo de perguntar na palestra

Vamos conversar um pouco mais sobre Anti-Forense e algumas maneiras de tratá-la. Esse assunto rende muito e, para falar sobre ele em 45 min, muita coisa tem que ser passada bem rapidamente.

Esculhambando as MAC Times

Um dos mais úteis instrumentos de investigação é a linha de tempo. Ordenar cada um dos eventos e sequenciá-los pode indicar o que aconteceu e ajudar também a chegar na causa de um incidente. É como ler um diário de bordo, só que nesse caso, quem o escreve são os programas do computador.

A timeline mais comum é aquela baseada no que chamamos de MAC times, atributos de data e hora relacionados com eventos de arquivos. O M diz respeito a data/hora da última modificação do arquivo; O A é relativo a data/hora do último acesso e o C é relativo a data/hora de criação do arquivo. Vale a pena reforçar duas coisas:

1) Isso vale para o NTFS. Outros sistemas de arquivos podem não ter esses atributos;
2) Há ainda um outro atributo, conhecido por E e se refere a data/hora da última alteração de atributos do arquivo.

Como a maioria das ações em uma máquina corre por acessar, alterar e criar arquivos, levantar e ordenar essas ações dão uma linha de tempo excelente. Pense em casos de invasão ou infecção por vírus. Uma linha de tempo com foco em uma faixa de datas aproximada pode indicar a causa, o vetor de entrada e até mesmo arquivos afetados que nem imaginaríamos.

Como a Anti-Forense tem por objetivo principal acabar com as técnicas, processos e ferramentas de Computação Forense, uma técnica bem específica foi moldada para "esculhambar" com a já famosa e muito utilizada timeline. Imagine o seguinte:

1) Alguém liga para o Service Desk da empresa e avisa que sua máquina está com um comportamento muito estranho. São 9h00;
2) A turma responsável dá uma olhada, determina que houve uma infecção por malware, não capturado pelo Antivírus instalado na máquina. Para verificar a extensão do dano e saber quantos arquivos foram danificados pelo vírus, uma timeline é montada;
3) A timeline revela que a infecção se alastrou depois de um certo arquivo ser criado na máquina, às 8h30. Esse arquivo foi "baixado" por engano pelo próprio usuário, que caiu em um phishing;
4) Ainda usando a timeline, filtrando-a entre 8h30 e 9h, soube-se que os arquivos X, Y e Z foram afetados pelo mesmo malware.

A situação acima ficaria fora de controle se o malware usasse a técnica de Anti-Forense descrita. Logo de início, a turma de investigação veria que há um download suspeito por volta de 8h30, mas esse arquivo está com data de criação de 3 anos atrás. A mesma data está registrada no último acesso e última modificação. Ele ficou de fora da linha de tempo montada com foco entre 8h30 e 9h. Os vários arquivos X, Y e Z também, já que inexplicavelmente, eles tem suas datas indicando o ano de 1601 como data/hora dos atributos.

Nesse cenário com uso de Anti-Forense, por outras técnicas poderíamos chegar ao vetor inicial e a causa da infecção, mas provavelmente os arquivos corrompidos X, Y e Z não seriam detectados.

Falando especificamente de Windows e NTFS, a turma da Anti-Forense Metasploit Project liberou um utilitário para esse fim. O Timestomp permite tanto zerar as datas dos atributos quanto modificar para um valor específico todos ou apenas alguns dos atributos.

Anti-Anti-Forense


Alguns pontos podem ser levantados para indicar a presença de técnicas Anti-Forense. Principalmente, leva-se em conta que a ação de subverter das datas dos atributos não leva em consideração que o atacante terá tempo suficiente para pesquisar e setar uma data falsa, mas que ainda mantenha a lógica dos valores. Por isso, algumas idéias:

1) O NTFS mantém os mesmos 4 atributos de data/hora em dois lugares. Há os MACE times gravados no Standard Information Attribute (SIA) e há os MACE times gravados no FileName Attribute (FN). Embora eu não tenha localizado uma documentação que claramente estabeleça a diferença entre as duas e quando uma ou outra é alterada, fiz vários testes de comportamento desses atributos e pude perceber que o comportamento lógico deles (ou seria ilógico) é que, em quaisquer das operações setadas, os atributos da FN são trabalhados primeiro que os da SIA. Portanto, é lógico que as datas/hora do FN sejam mais antigas que as do SIA

2) A resolução de horas dos atributos vão até os milissegundos. É muito comum que, ao subverter uma data, o atacante informe uma data/hora até, no máximo, os segundos. Dessa forma, os atributos ficam com os milissegundos zerados. Isso pode ser usado como característica de detecção. Não é uma técnica definitiva, pois alguns produtos, ao criarem arquivos, também escrevem horas indo até os segundos, e nesse caso, também ficam com os milissegundos zerados.

3) As datas de criação de um arquivo ordinário, em geral, não podem ser mais antigas que a data de formatação do sistema de arquivos (ou seja, a data de quando o disco foi formatado). Há alguns casos onde arquivos copiados/movidos de outras mídias podem ferir essa regra.

4) As datas dos arquivos não podem estar no futuro. Alguns atacantes se confundem ao setar a data, com as posições de dia e mês, e acabam por colocar a data do arquivo no futuro. Normalmente, isso nem seria notado, mesmo em uma linha do tempo, que em geral também é limitada nas datas onde acreditamos que o incidente tenha acontecido.

5) Quando a opção de data zerada do timestomp é usada, isso deixa o Encase sem indicar data alguma. No caso de acesso via utilitários, é comum que o ano apareça como de 16o1. Essa é a maior marca de que a máquina foi vítima de Anti-Forense. Esse é um dos poucos casos onde não conheço possibilidade de falso positivo.

6) O conceito de linha do tempo precisa ser expandido. Há muitos eventos acontecendo em uma invasão ou outro incidente, não podemos ficar focados apenas no que os arquivos dizem. Seguindo essa lógica, todas as fontes de informação que registram ações com data/hora devem ser alinhadas e ordenadas em uma linha de tempo, principalmente as fontes externas à maquina suspeita, onde o atacante teria menos controle e recebem menos atenção. Linhas de tempo bem completas podem incluir acionamento de arquivos executáveis e DLLs vindos de um Prefetch, uso de arquivos obtidos pelo Registry, logs diversos, eventos do Windows, etc. Tem data/hora, então pode ser útil. Um exemplo da aplicação desse conceito:

- O atacante usa o reg para baixar o SAM da máquina para um arquivo SAM.txt, sendo que ele falha na primeira tentativa. Ele o abre, verifica o conteúdo, e o envia para um servidor remoto via HTTP. Em seguida, o atacante remove o arquivo SAM.txt e usa o timestomp, zerando os MAC times do reg.exe.

Nesse contexto, uma linha de tempo que englobe os atalhos de Recent, o log de acesso do proxy e
o log de eventos do Windows pode colocar no devido lugar a ação de gerar um arquivo que foi acessado e enviado, mas não existe mais.

Eu criei uma rotina que verifica os atributos MACE dos arquivos e indica os que são suspeitos de Anti-Forense. Baixe-a no conjunto de rotinas do Byte Investigator.

Comentários ? Alguém que já tenha encontrado alguma dessas situações em uma investigação e gostaria de compartilhar como tratou o problema ?

Até o próximo post !

8 comentários:

Giancarlo disse...

Bacana o post Tony.
Realmente bagunçar com os MACE Times pode causar problemas e confusões.
Uma dúvida básica me surgiu agora: o NTFS possui algum limite de data de arquivo? Posso gerar um arquivo com data perto do infinito para que ele não seja encontrado via filtro de datas?

t+
Giancarlo

Tony Rodrigues disse...

O timestamp de arquivo no NTFS é um numero em 64-bit que significa o número de centésimos de nanosegundos desde 1601, se nao me engano. A maior data possível seria, em tese, se todos os bits estiverem em um. Eu tenho aqui um utilitário chamado Dcode que faz a decodificação para esse tipo de dado, e estranhamente ele n deixa ir até o máximo. Só consegui setar em 0x01FEFFFFFFFFFFFF, o que chega perto de 2048, +- ...
O meu script tb verifica isso, de ter timestamps com datas futuras. Nunca vi usarem na prática, porém ...

[]s

Tony

SS disse...

Olá Tony, quando vi este seu post me relembrei de um post do começo do ano que abordava este mesmo assunto de Anti-Anti-Forensics utilizando a mesma abordagem também (MFT, SIA, FNA) e um Enscript para identificar isto automaticamente..

Caso você não tenha lido ainda, vale a olhada: http://www.forensickb.com/2009/02/detecting-timestamp-changing-utlities.html

[ ]s e ótimo 2010!

Sandro Süffert
http://blog.suffert.com

Tony Rodrigues disse...

Sandro, meu camarada !

Eu já tinha lido esse artigo. Aliás, os artigos do Lance Mueller são sempre muito bons. Pena que ele disponibiliza o Enscript no formato compilado, e não deu para bater a lógica que ele usou com a que usei no meu script perl. Fizemos basicamente o mesmo tipo de pesquisa, criando e "bulinando" com os arquivos, acompanhando as respectivas alterações nos atributos SIA e FN. O que acontece nos SIA bate com a documentação da MS, já no FN eu n achei nada e as regras que eu usei no script foram empíricas. Imagino que as do Lance tb. Bom, no fim das contas tanto esse trabalho dele quanto o meu tem a mesma raiz, que é uma palestra na Black Hat da turma do Metasploit AntiForensics Project. É bem conhecida, tenho certeza que vc já deve ter lido.

Estou escrevendo a parte 2 desse artigo, onde vou falar outras possibilidades de comparação de timestamps para mostrar arquivos suspeitos de terem passado por anti-forense. Espero publicá-lo logo !

No mais, bom 2010 para vc e família ! Abração

SS disse...

Grande Tony,

Lá vai o primeiro comentário de 2010:

Sobre o atributo $FILE_NAME (Type Identifier: 48), ele realmente praticamente duplica o que existe no $STANDARD_INFORMATION.

Existem 2 $FILE_NAME para cada entrada da MFT (um da própria entrada e outro no index do diretório pai) - e como você sabe os valores podem divergir..

Como o Windows normalmente não atualiza estes valores, os timestamps presentes no $FILE_NAME ficam inalteradas e são chave para identificação de alterações e para ótimas ferramentas e posts sobre Anti-Anti-Forense =)

---

PS: Uma ótima referência sobre o atributo NTFS $FILE_NAME e obviamente sobre File Systems em geral é o ótimo livro "File System Forensics Analysis" (capítulo 12) do Brian Carrier. (Aliás depois dá uma olhada nos livros que listei em http://bit.ly/6JTkhy - e se possível, contribua com alguns breves "reviews" de títulos!)

Um excelente 2010 para nós todos, camarada!

Tony Rodrigues disse...

Começamos bem o ano !!

Rapaz, esse livro é de cabeceira. Leitura obrigatória para a nossa profissão, muito bom mesmo. Quando eu iniciei essa pesquisa, eu o consultei, mas ele não traz as regras de atualização do $FN, então parti para testes mesmo. Concluí exatamente o que vc escreveu, mas tb percebi algumas modificações desse atributo quando em cópias, movimentações e alterações do nome.

Eu já vi a sua lista de livros, está excelente. Vou dar uma nova olhada e tentar perceber algum novo para indicar. Acho difícil, pois ela estava bem completa !

No mais, bom 2010 para vc !!

[]ao,

Tony

SS disse...

Grande Tony, na correria como sempre mas gostaria de acrescentar mais informação ao assunto que você já publicou (em vez de criar um post redundante sobre o mesmo tema):

Gostei muito da ferramenta "analyzeMFT" - segue o link: http://www.integriography.com/projects/analyzeMFT

analyzeMFT - a Python tool to deconstruct the Windows NTFS $MFT
file

Overview:

analyzeMFT.py is designed to fully parse the MFT file from an NTFS filesystem and present the results as accurately as possible in a format that allows further analysis with other tools. At present, it parses the attributes from a $MFT file to produce the following output:

* Record Number
* Good - if the entry is valid
* Active - if the entry is active
* Record type - the type of record
* Record Sequence - the sequence number for the record
* Parent Folder Record Number
* Parent Folder Sequence Number
* For the standard information attribute:
o Creation date
o Modification date
o Access date
o Entry date
* For up to four file name records:
o File name
o Creation date
o Modification date
o Access date
o Entry date
* Object ID
* Birth Volume ID
* Birth Object ID
* Birth Domain ID
* And flags to show if each of the following attributes is present:
o Standard Information, Attribute List, Filename, Object ID, Volume Name, Volume Info, Data, Index Root, Index Allocation, Bitmap, Reparse Point, EA Information, EA, Property Set, Logged Utility Stream
* Notes/Log - Field used to log any significant events or observations relating to this record

For each entry in the MFT a record is written to an output file in CSV format.

analyzeMFT will run on any system with Python installed. A standalone Windows executable is also available.

Grande [ ]!

Tony Rodrigues disse...

Sandro, meu camarada !
Vi o utilitário, me pareceu bastante interessante. Obrigado pela contribuição !!!

Abraços,

Tony