Mostrando postagens com marcador anti-forensics. Mostrar todas as postagens
Mostrando postagens com marcador anti-forensics. Mostrar todas as postagens

sexta-feira, 15 de outubro de 2010

Anti Anti Forensics

O vídeo e o PDF da minha palestra no H2HC 6th Edition, em 2009, está liberado.

O objetivo dessa palestra foi abordar os principais conceitos e técnicas ligados à Anti-Forense, além de mostrar os vestígios que essas técnicas deixam. Outro ponto importante da palestra foi abordar que Anti-Forense não produz um crime perfeito, ao passo que Peritos também não possuem técnicas perfeitas. Essa "guerra" produz crescimento e amadurecimento das técnicas, no fim das contas.

Até o próximo post !

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 !

quinta-feira, 15 de outubro de 2009

Anti-Anti-Forense

Esse é o tema sobre o qual estarei falando na 6a edição do mais importante evento Hacker do Brasil - o H2HC - Hacker-2-Hacker Conference. O evento será no final de semana de 28 e 29 de novembro, em São Paulo.

Já faz algum tempo que venho olhando esse assunto com atenção. A primeira vez que li sobre esse termo foi em uma palestra feita pela turma do projeto Metasploit. A palestra procurava expor fraquezas em algumas técnicas ou ferramentas usadas em Computação Forense.

Depois dessa palestra, anti-forense entrou para o abstrato. Tudo seria resolvido por anti-forense, e os peritos estavam com os dias contados. Não levaria muito tempo e todos aplicariam os conceitos que, por hora, apenas alguns Hackers Jedi conheciam. Com o passar do tempo, chegamos ao ponto de perceber uma certa disputa, quase um clima de guerra. Hackers que escrevem sobre o assunto desdenham dos investigadores e colocam as técnicas como imbatíveis. Os peritos, por outro lado, usam de grande ironia e expõem a questão como se fosse brincadeira de criança resolver qualquer coisa relacionada a isso. Vi muitos desses textos enquanto pesquisava alguns detalhes para a palestra.

Nem "rocket science" nem algo trivial. Anti-Forense deve ser visto como crítica construtiva e pode ajudar (e muito !) no combate aos crimes, uma vez que tira o perito de sua posição de conforto e o faz repensar nas suas técnicas e ferramentas. É com esse intuito que venho pesquisando algumas técnicas, principalmente como poderiam ser detectadas ou revertidas. O ponto comum nas técnicas de "contra-ataque" é que, em algum momento, algo aparece. Harlan Carvey costuma usar uma analogia com técnicas militares, onde mesmo o melhor e mais prudente snipper precisa fazer alguns movimentos, comer, dormir ... É nessa hora que ele pode se expor, e de forma análoga, quando o malware, o atacante ou o utilitário são usados, marcas e vestígios importantes aparecem. É só estar bastante atento a elas.

Espero vê-los por lá. Será uma boa oportunidade para conhecer a turma que acompanha o blog.

Até o próximo post !

quinta-feira, 9 de abril de 2009

Anti-Forense ?

Há um post interessante sobre anti-forense no blog do Lance Mueller que vem bem a calhar sobre a nossa ultima discussão, falando de correlação. No post ele comenta acerca de um caso onde um atacante procurou usar técnicas de anti-forense para atrapalhar as investigações e encobrir alguns vestígios. O atacante trocou nomes e timestamps (datas de criação, modificação, etc) dos arquivos envolvidos no ataque. De maneira bastante divertida, Lance diz que não concorda com esse termo "anti-forense" e que isso é, na verdade, anti-administrador.

Por que ele disse isso ?

Primeiro porque um perito deve sempre verificar vários itens, independentemente do lugar que estão. Se estiverem no System, System32 ou Windows, mais atenção ainda deveremos ter. Em segundo lugar, porque o sistema era um Windows 2003, e o atacante usou timestamps de 2001.

Repare que, nos dois casos, o autor está usando correlação para chegar a uma conclusão a respeito do que aconteceu, e das técnicas de obfuscação usadas.

Um outro autor muito famoso no meio da Computação Forense, Harlan Carvey, costuma dizer que anti-forense não afeta os sistemas, mas sim as pessoas. Seria mais um anti-perito, pois o profissional atento vai correlacionar os dados que puder e vai concluir o que de fato ocorreu.

Comentários ?

Até o próximo post !

quinta-feira, 11 de setembro de 2008

Chororô

Nunca fui de ficar choramingando em épocas difíceis. Mas a coisa está realmente feia para mim, em relação a tempo. Como já disse aqui, estou preparando um curso sobre Forense Computacional, e o material está consumindo 100% da minha CPU.

Bom, como não adianta ficar se lamentando, que isso não cria tempo extra, decidi colocar pelo menos um mini-post.

O assunto é dos bons: Anti-Forense. Eu o acho intrigante, pois enquanto há pessoas trabalhando para melhorar as técnicas, alguns estão procurando os nossos erros ... No problem, já dizem os mais velhos que não crescemos sem um antagonismo para nos forçar a melhorar. Então que venham esses meliantes !

O artigo que vou falar é muito interessante. Ele não tem o interesse de simplesmente divulgar falhas nos métodos ou mostrar como os Investigadores Digitais podem ser "facilmente" enganados. Foi um estudo sério, realizado por um investigador da equipe do CERT, que busca dentre várias ferramentas tidas como "ferramentas para manter a privacidade", as suas características e como elas são usadas para eliminar evidências.

A parte boa é ver que muitas dessas ferramentas, de acordo com o artigo, apresentam falhas naquilo que prometem. Algumas são bugs mesmo, e outras são falhas de conceito, pois removem dados em um local e esquecem de remover outros.

O artigo vale a pena, principalmente para se buscar por ferramentas desse tipo nas imagens e, se encontrando alguma, intensificar buscas de artefatos. Ele vai ajudar, servindo de referência, nesses casos. Outro ponto importante é que, na medida em que se acha um software desse tipo na máquina, cai o véu de inocência do nosso suspeito ... Pelo menos no sentido de nós, peritos, ficarmos mais atentos aos artefatos.

Baixe o artigo aqui.

Comentários ?

Até o próximo post !

quinta-feira, 23 de agosto de 2007

E o Live Accquisition leva um TKO ...

Se estivéssemos em uma luta de boxe das boas entre a turma do Live X Dead acquisition (captura da imagem de um disco ativo e em uso pelo SO ou não), o artigo que acabei de ler representaria um bom direto de direita, daqueles de levantar a platéia e fazer o juiz abrir a contagem, com o lutador ainda se perguntando se anotaram a placa do caminhão ...

O artigo é uma apresentação do Darren Bilby, da Security Assessment, para a Ruxcon 2006. Sob o título de "Low Down and Dirty: Anti-Forensic Rootkits", o autor explora o que o mundo dos rootkits pode trazer e afetar ferramentas de captura de imagens forenses.

Na sua essência, um rootkit é um código (ou conjunto de) que tem por objetivo alterar o comportamento normal das rotinas, comandos e drivers do sistema operacional, na maioria das vezes para esconder a presença de outros códigos.
Os rootkits mais clássicos são aqueles em Unix que substituiam comandos e, dessa forma, conseguiam fazer passar despercebidos os arquivos e processos usados em ataques e invasões.

Por exemplo, o comando ps, que lista os processos executando na máquina, era substituído por um outro ps, parte do rootkit, que ao ser usado continuava listando realmente todos os processos em execução, MENOS os processos relativos ao ataque.

Rootkits mais complexos chegam a trocar e alterar códigos e device drivers diretamente no kernel do SO, e são cada vez mais difíceis de detectar. Eles se protegem de ferramentas de detecção, inclusive, interceptando chamadas e alterando o resultado, de forma a se manterem indetectáveis.

O artigo explora justamente o conceito de que um rootkit, se devidamente instalado e presente em um sistema, pode ser preparado para ser totalmente indetectável aos mecanismos usados em um software de captura de imagem. Mesmo o famoso DD poderia ser enganado com algumas técnicas, de forma a capturar não toda a mídia, mas apenas aquilo que o rootkit deixar.

O por que do nocaute técnico ? É que em uma live acquisition o rootkit estaria ativo, e portanto, alterando tudo que o DD está capturando. Em um sistema infectado por um desses, o Investigador de Forense Computacional poderia estar literalmente levando gato por lebre ...

Obviamente, na Dead Acquisition isso não acontece. O sistema não carregou o rootkit para memória, a captura ocorre normalmente e uma boa análise da imagem vai indicar a presença dos arquivos alterados que fazem parte do código maledito, como diriam alguns ... ;)

Continuo no débito do artigo do Hash com Database ...

Até o próximo post !