Hashset de Malware

Uma tecnica muito útil para um investigador ganhar tempo ou para ser alertado quanto a presença de arquivos maliciosos na máquina investigada é a filtragem por hashset.

De maneira muito resumida (já falamos nesse tópico aqui no blog), a filtragem por hashset permite, durante uma varredura pelos arquivos da imagem sendo periciada, eliminar do foco da investigação aqueles arquivos que são conhecidos e não poderiam ser relacionados com nenhum ponto ou problema da nossa investigação. Esses arquivos, conhecidos como known good, são os arquivos originais do sistema operacional, utilitários, programas e até mesmo imagens que fazem parte de pacotes comerciais ou não. Os arquivos known good podem ser reconhecidos através de um hashset, uma relação deles univocamente identificada pelo seu hash, em MD5 ou SHA-1. Durante a varredura, os arquivos cujo hash se encontram na base known good podem ser tranquilamente ignorados.

Por outro lado, seria interessante que durante essa mesma varredura pudéssemos ser alertados da presença inequívoca de um arquivo malicioso. Podemos atingir esse objetivo através de um hashset que reúna somente arquivos com reputação duvidosa, com malware, ferramentas hacker e códigos destrutíveis. Esse conjunto de hashs é comumente conhecido como known bad hashset, e a identificação também ocorre pelo hash do arquivo, em MD5 ou SHA-1.

Na verdade, o algoritmo nem precisa ser um desses dois. O que precisamos é ter a base de hashs (hashset) usando um determinado algoritmo de hash e varrer a imagem calculando o hash de cada arquivo neste mesmo algoritmo.

O problema surge exatamente aqui. A maior base pública de hashsets disponível é a NSRL, e curiosamente ela oferece, na mesma base, as duas classes: known good e known bad. Tomando como exemplo o sorter, se usarmos a base NSRL como known good, os arquivos maliciosos que porventura existirem na imagem serão ignorados. Por outro lado, se usarmos a base como known bad, seríamos alertados erroneamente em milhares de arquivos.

A solução desse impasse, enviada pelo colega Doug White do NIST, está em separar a base (que na verdade é composta por um conjunto de arquivos) em known good e known bad. Isso pode ser feito porque um dos arquivos que compoe a base possui um campo de classificação, e os arquivos known bad tem a classificação "Hacker Tool". Basta filtrarmos todos esses "Hacker Tool", jogando-os para um arquivo a parte, e teremos o Known Bad extraído da NSRL. Quem não tem essa classificação pode ser jogado em outro arquivo e será o Known Good.

Abaixo segue um código perl que fará a extração, conforme comentado:

#!/usr/bin/perl -w
# Extracts known good and known bad hashsets from NSRL
# uso: nsrlext.pl -n -p -g -b [-h]
#
# -n :nsrl files comma separated. Ex: -n c:\nsrl\RDA_225_A\NSRLFile.txt,c:\nsrl\RDA_225_B\NSRLFile.txt
# -p :nsrl prod files comma separated. Ex: -p c:\nsrl\RDA_225_A\NSRLProd.txt,c:\nsrl\RDA_225_B\NSRLProd.txt
# -g :known good txt filename. Ex: -g good.txt
# -b :known bad txt filename. Ex: -b bad.txt
# -h :help
#
#
use Getopt::Std;

my $ver="0.1";

#opcoes
%args = ( );
getopts("hn:p:g:b:", \%args);

#help
if ($args{h}) {
&cabecalho;
print << DETALHE ;
uso: nsrlext.pl -n nsrl_files_comma_separated -p nsrl_prod_files_comma_separated [-g known_good_txt] [-b known_bad_txt] [-h]

-n :nsrl files comma separated. Ex: -n c:\\nsrl\\RDA_225_A\\NSRLFile.txt,c:\\nsrl\\RDA_225_B\\NSRLFile.txt
-p :nsrl prod files comma separated. Ex: -p c:\\nsrl\\RDA_225_A\\NSRLProd.txt,c:\\nsrl\\RDA_225_B\\NSRLProd.txt
-g :known good txt filename. Ex: -g good.txt
-b :known bad txt filename. Ex: -b bad.txt
-h :help

DETALHE
exit;
}

die "Enter the NSRL hashset file list (comma delimited)\n" unless ($args{n});
die "Enter the NSRL product file list (comma delimited)\n" unless ($args{p});

die "Enter known good and/or known bad output filenames\n" unless (($args{g}) || ($args{b}));

my %hack;

&cabecalho;

#Prod files
my @prod = split(/,/, $args{p});

foreach $item (@prod) {
open(PRODUCT, "< $item");

while (< PRODUCT >) {
chomp;
my @line = split(/,/, $_);

#create a hash of hacker tool codes
$hack{$line[0]} = $item if ($line[6] =~ /Hacker Tool/);
}

close(PRODUCT);
}

#hashset files
my @hset = split(/,/, $args{n});

open(BAD, "> $args{b}") if ($args{b});

open(GOOD, "> $args{g}") if ($args{g});

my $i=0;

foreach $item (@hset) {
open(NSRL, "< $item");

while () {

#stdout feedback
print ">" if (($i % 10000) == 0);

my @line = split(/,/, $_);

if ($hack{$line[5]}) {
#is a hacker tool
print BAD $_ if ($args{b});
}
else {
print GOOD $_ if ($args{g});
}

$i++;
}

close(NSRL);
}

print "\nDone !\n";

close(BAD) if ($args{b});
close(GOOD) if ($args{g});

### Sub rotinas ####

sub cabecalho {
print << CABEC;

nsrlext.pl v$ver
Extracts known good and known bad hashsets from NSRL
Tony Rodrigues
dartagnham at gmail dot com
--------------------------------------------------------------------------

CABEC
}

#-----EOF-------


Comentários ?

Até o próximo post !

Fuzzy Hashset

Notícia curta mas muito boa.

Já conversamos algumas vezes aqui no blog sobre fuzzy hash. Uma das capacidades dessa implementação hash é a possibilidade de indicar conteúdos "parecidos", ou seja, podemos indicar quanto um arquivo é próximo de outro usando-os em um algoritmo de hash fuzzy. O utilitário que calcula esse hash é o já conhecido ssdeep, que está na versão 2.3, novinha em folha.

Apesar desse software ter grande utilidade para a Forense Computacional, havia algo que há muito sentíamos falta: Um conjunto de hashs de referencia, usando o algoritmo fuzzy. Pois bem, depois de muitos pedidos da comunidade e pesquisadores, o NIST ouviu as nossas preces e lançou uma variação da já conhecida biblioteca/hashset NSRL contendo milhares de hashs pré-calculados usando o ssdeep. Eu ainda recebi a notícia em primeira mão pelo Doug White, um dos especialistas responsáveis pela NSRL.

Entre outras coisas, esse novo hashset vai permitir a aplicação de comparações e filtragem por hashset, mas usando uma técnica ligeiramente diferente da que já existe, para fugir dos casos onde houver anti-forense sendo aplicada.

Planejo um artigo mais detalhado sobre o uso dessa biblioteca/hashset em breve.

Baixe aqui o conteúdo.

Comentários ??

Até o próximo post !

Tempos modernos

Esse post é quase off-topic. É um grande elogio e agradecimento à proximidade que a Internet nos trouxe.

Estava escrevendo um material para apresentar no H2HC quando tive uma dúvida. Postei a pergunta em dois fóruns internacionais que faço parte; Em um deles, fui atendido por um dos pesquisadores do NIST, Doug White, que entre outras coisas é responsável pela NSRL. A minha pergunta era exatamente sobre a NSRL oferecer ou não uma base de hashs fuzzy, já que eu tenho a base corrente, e só tem MD5 e SHA1 nela. Ele me informou que eles já tem os valores calculados, mas o hashset não está publicado por pouca demanda. Nós "conversamos" sobre isso e acho que vamos ter a base publicada. Comentei com ele sobre alguns detalhes da minha palestra e ele entendeu a importância e a relevância que a base terá. É só aguardar ...

Na outra lista, nova resposta ilustre. Quem me escreveu foi nada mais nada menos que Jesse Kornblum, o próprio criador do ssdeep e dos outros inúmeros "deeps" que temos. Além desse trabalho, Jesse também é o autor da Primeira Lei da Forense Computacional, que já tratamos aqui no blog.

Tanto um quanto o outro foram extremamente gentis e dispostos a ajudar. Não faz muito tempo, eu também estava trocando emails com Matthieu Suiche, autor de inúmeros utilitários de Forense de Memória, tais como o Sandman e o win32dd. Emails com o Harlan Carvey (o papa do Windows Registry) já se tornaram comuns e já escrevi aqui sobre ter consultado diretamente o pesquisador que quebrou o MD5 em um certificado digital.

Isso não é sensacional ? Ter ao alcance do teclado a opinião de verdadeiros gênios da nossa ciência ? A Internet faz mesmo o mundo ficar menor ...

Comentários ?

Até o próximo post !

What Programs Do

A parte de Análise em Informática Forense pode ser, dentre tantas técnicas, resumida a você poder contar como foi que algo aconteceu. Fazemos isso observando a imagem forense (ou as imagens) das mídias envolvidas e mesmo da memória. Observamos artefatos deixados pelo sistema operacional e pelos diversos programas instalados para poder determinar aspectos do caso e definir a análise.

Trazendo isso para uma análise da cena do crime, sabemos que uma pessoa deixa impressões digitais ao tocar determinados objetos; sabemos que um disparo de arma de fogo deixa resíduos de pólvora. Em um acidente de carro, podemos saber quem estava ao volante percebendo a direção da marca (hematoma) deixado pelo cinto de segurança.

O que isso significa ? Que na prática, nossa atuação e nossa análise será cada vez mais facilitada pelo conhecimento dos artefatos deixados pelo SO e pelos utilitários/aplicativos.

Pois bem. Uma turma da SANS deu um passo importante nessa direção. O projeto, cujo nome é o título desse post, está no blog na SANS e tem por objetivo postar todos os artefatos gerados por um programa qualquer.

O projeto ainda se encontra em fase inicial, e não tenho idéia de como vai ser disponibilizado para consulta, mas imagino dois usos específicos para ele.

1) Você está verificando se um tal programa XYZ foi usado na máquina, e se pergunta quais artefatos e onde procurar. Faz a busca no site do projeto e ... voilá ! Sabe onde procurar cada item para determinar o uso (ou não) do XYZ.

2) Você encontrou uma chave de registry ou um arquivo de log e não tem idéia de que utilitário teria criado o item. Uma rápida busca no site do projeto e imediatamente você fica sabendo que o tal item misterioso foi criado pela aplicação XYZ, que não mais existe naquela máquina ...

Fiquem de olho, esse projeto promete ser tão útil quanto o da NSRL, que publica o database com os hashes de programas. Um ponto importante é que estava em voga ampliar esse projeto para fornecer hashes dos arquivos por grupos de 512 bytes, normalmente bate com os setores dos sistemas de arquivos mais comuns. Por que ? Com os hashes, seria possível descobrir que um determinado setor é na verdade o n-ésimo bloco do programa XYZ, e isso facilitaria uma operação de carving onde há fragmentação. Alguém sabe se esse projeto andou ?

Comentários ?

Até o próximo post !

Carving

Carving é o nome de um procedimento/técnica muito importante para a Forense Computacional. Através do carving, podemos conseguir acessar um arquivo de forma independente da sua tabela de alocação, ou endereçamento; O carving age de forma independente do sistema de arquivos.

Vamos a um exemplo prático:

Uma feira de negócios é montada em um grande pavilhão. Para demarcar o local destinado ao estande de cada empresa, os organizadores dividem o espaço útil (as vias e corredores não contam) pelo tamanho mínimo de um estande, e com isso determinam que quantos estandes terá a feira. O espaço útil é então separado e dividido nos blocos de estandes.

Para facilitar a localização de cada estande, a organização associa letras aos corredores, e um número crescente a cada estande. Assim, o quarto estande do terceiro corredor seria o estande C4, e foi comprado pela empresa XXX. Na porta do pavilhão há uma lista com o nome de cada empresa em ordem alfabética e sua respectiva localização. Observamos, inclusive, que há empresas que compraram 3 estandes, para poder exibir seu material com mais liberdade.

Nessa pequena analogia, temos o seguinte:

- O pavilhão é a mídia, o HD.
- Os organizadores fazem o papel do sistema operacional.
- A divisão do pavilhão em corredores e unidades de locação (os estandes) é a formatação do disco.
- Uma empresa expositora seria um arquivo.
- A associação das letras e números seriam um endereço alocável.
- Uma empresa comprando um estande seria um arquivo alocado.
- A lista colocada na porta do pavilhão é a tabela de alocação do sistema de arquivos.
- Um estande não alugado é um setor livre para ser alocado.
- Uma empresa que aluga 3 estandes é um arquivo que ocupa 3 setores.

Pois bem, se você chega ao portão do pavilhão a procura da empresa XXX, você a procura na lista, verifica o endereço dela (C4) e se dirige até o local. Esse é o mesmo processo, de maneira resumida, é o que acontece quando se quer acessar determinado arquivo.

Agora, imagine o que aconteceria se a tal lista da entrada se perdesse ? O processo normal de busca da empresa não funcionaria mais, já que a lista sumiu.

Em termos de sistema de arquivos, é possível que a tabela seja corrompida, ou ainda que apenas uma parte do HD seja recuperada, e essa parte não tem a tabela de alocação. Nesses casos, entra em ação a técnica de carving, para achar arquivos no que parece um monte de bytes.

Como isso é feito ?

A técnica mais usada é baseada nos chamados magic numbers, são sequências de bytes que estão sempre presentes no arquivo, em geral no seu cabeçalho. Esses bytes funcionam como uma assinatura: Se forem achados, alguns itens são verificados e a estrutura é confirmada. Em geral, os programas de carving extraem os arquivos identificados das imagens para um diretório, disponibilizando-os para uso. Os arquivos JPEG sempre começam com ffd8 ffe0, por exemplo. Uma vez identificado que é o início de um JPEG, o cabeçalho é dissecado e o fim do arquivo determinado.

O grande problema é que em um sistema de arquivos nem sempre um arquivo ocupa setores contíguos. Conhecido como fragmentação de arquivos, isso acontece, por exemplo, quando um arquivo cujo tamanho ocupa 5 setores está para ser escrito no disco e encontra 3 setores contíguos livres, um setor já ocupado por um outro arquivo, e em seguida mais dois setores livres. O sistema operacional vai alocar o arquivo nesses 5 setores, marcando na tabela que esse arquivo ficou fragmentado. Tal situação ficaria mais ou menos assim:
Arquivo 1: AAAAA
Arquivo 2: B
No disco: AAABAA
Seguindo a técnica, os bytes do arquivo 2 vão parar no meio do arquivo 1 recuperado, estragando tudo !

Várias técnicas vem sendo pesquisadas para reduzir ou eliminar esse problema, e inclusive há um concurso anual de algoritmos e desafios envolvendo carving.

Algo que com certeza vai ajudar bastante é a técnica de montar hashsets dos arquivos conhecidos por setor. Essa técnica é baseada na filtragem de arquivos conhecidos por reconhecimento de seus hashes, como a biblioteca NSRL, só que, nesse caso, cada arquivo conhecido teria associado a ele o hashset de cada setor que esse arquivo ocupa em um disco. Durante uma operação de carving baseada nessa técnica, os setores seriam separados e reconhecidos contra a base de hashsets pelos seus hashes. No exemplo acima, calcularíamos o hash de cada um dos 6 setores, e depois o algoritmo verificaria o seguinte:

- O setor 1 é o primeiro setor do arquivo conhecido A
- O setor 2 é o segundo setor do arquivo conhecido A
- O setor 3 é o terceiro setor do arquivo conhecido A
- O setor 4 é o primeiro setor (ou único, no caso) do arquivo conhecido B
- O setor 5 é o quarto setor do arquivo conhecido A
- O setor 6 é o quinto setor do arquivo conhecido A

Facilita bastante. Logicamente, essa técnica tem alguns problemas; Os arquivos que não ocuparem um setor inteiro, bem como o último setor de um arquivo, não terão como serem reconhecidos, pois o calculo do hash seria influenciado pelo slack space (aquele espaço do setor que o arquivo não ocupou). Outro problema é que os hashsets serão criados para arquivos de programas, e não teremos obviamente hashsets para arquivos de fotos do usuário do HD, ou os seus documentos criados no editor de textos, por exemplo. Isso ajudará a eliminar setores, mas ainda pode não ser uma técnica definitiva.

Alguém tem alguma novidade com relação a essa técnica, ou conhece alguma iniciativa de montar hashsets para isso ? Por favor, compartilhe conosco nos comentários.

Até o próximo post !

Nosso Amigo Hash - Parte V

Hash Aplicado na Forense Computacional - Prática

Classificação de arquivos usando banco de dados

Enfim, cheguei ao tão falado post. Minha cara de pau já estava além da conta, mas realmente foi impossível escrever antes ...

Um ponto importante: Esse artigo é uma adaptação do artigo escrito pelo Mark McKinnon em seu blog.

Apenas relembrando o final do último artigo sobre hash, nosso objetivo maior é classificar cada arquivo em nossa imagem a ser analisada, de forma a indicar se o arquivo é conhecido ou não. Com essa classificação, conseguimos reduzir a ação de análise forense e focar em arquivos que podem realmente ter relevância para o processo. Quem nos apoiará na classificação é a base de hashes (conhecida também por hashset) do NSRL.

Pois bem, o problema é que as ferramentas disponíveis não são eficientes com bases grandes como a do NSRL. Tanto pelo fato da memória lotar com a base (que é realmente gigantesca e é carregada para a memória antes da primeira comparação/classificação) quanto pelo próprio algoritmo de busca na base não ser o melhor para esse fim.


Vamos melhorar isso acrescentando mais uma ferramenta importante à nossa equação: Um banco de dados. A estratégia é dividir o problema em três fases:

1) Vamos criar uma base de dados e popular ela com os hashes da NSRL

2) Vamos passar o MD5Deep na imagem (ela precisará estar montada) e carregar os hashes obtidos em uma outra tabela da base.

3) A classificação dos arquivos poderá ser facilmente obtida com queries SQL a partir daí.


Note que:

- Há um notável ganho com essa solução, principalmente se levarmos em conta que o tempo levado para obter o resultado por uma segunda vez (uma repetição da classificação, por exemplo) é muito pequeno, compreendendo apenas a fase 3.

- A base de hashes da NSRL não é normalizada e repete arquivos com frequência, porque ela registra os arquivos conforme a aplicação que os arquivos pertencem, e é muito comum um arquivo pertencer a mais de uma aplicação ou versão.

- Na verdade, não nos importa saber de qual aplicação, versão ou SO específico é o arquivo em questão. Queremos apenas dizer se o arquivo é conhecido ou não. Isso vai nos facilitar bastante o tratamento, e a base NSRL ficará bastante reduzida.

- Vamos nos ater ao MD5, mas o SHA-1 poderá ser usado, a gosto ;)



Fase 1



Vamos criar a base de dados e carregar a base NSRL. Estou considerando que os quatro discos com a base NSRL já se encontram descompactados e disponíveis. Usarei como servidor de banco de dados o SQL Server, mas o processo pode ser facilmente adaptado para outros SGBDs.


1) Usando a ferramenta Enterprise Manager (ou o Query Analyser, para quem prefere usar DDLs SQL diretamente), crie uma base de dados. Escolha um nome para a base e use as opções default.

2) Abra a base, clique em tables com o botão direito, depois All Tasks e em seguida em Import Table.

3) Na primeira tela do Wizard, escolha para Data Source o text file. Informe, na caixa de texto Filename, o nome do arquivo NSRLFiles.txt. Clique em Next.

4) Deixe as opções default dessa tela, e marque também a check box First Row has Column Name. Clique em Next.

5) Nessa tela, novamente ficaremos com as opções default (delimiter = comma). Clique Next.

6) Na tela Destination, mantenha as opções default. Clique Next.

7) Na tela Select Source Table and Views, permaneça com o nome sugerido para a nova tabela (nsrlfile, o mesmo nome do arquivo a ser carregado). Clique Next.

8) Essa é a ultima tela. Clique Next.


O arquivo será carregado e gerará a tabela nsrlfile. Esse nome já aparecerá na relação de tabelas do banco.


Esse processo deverá ser repetido para o arquivo nsrlfile.txt de cada um dos quatro diretórios (ou discos) da base NSRL. A cada carga, o arquivo será importado e seus dados serão adicionados a tabela nsrlfile criada.


No final do processo, essa tabela estará com milhares de registros, muitos deles duplicados. Tenha em mente que é necessário ter bastante espaço em disco para essa carga inicial. Ela também consome bastante tempo.

Como nosso interesse é apenas indicar se o arquivo é conhecido ou não, podemos retirar todas as duplicações, e ainda por cima podemos retirar também alguns campos da tabela.

Entre no utilitário Query Analyser, conecte-se ao banco recem criado e digite a seguinte query:
Select distinct [md5], [sha-1], FileName into NSRL from nsrlfile

A query acima vai criar uma tabela nova somente com os campos de hash md5 e sha-1, mais o nome do arquivo. Cada registro só aparecerá uma única vez.

Para melhorar ainda mais o acesso no futuro, é interessante criar índices para os campos md5 e SHA-1. Esses índices podem ser criados diretamente com DDL SQL ou na interface do Entreprise Manager. Se optar por essa forma, você deve:
- Clicar com o botão direito sobre o nome da tabela NSRL e clicar no menu Design Table.
- Em seguida, clique no segundo botão da esquerda para direita (Table and Index Properties).
- Ao abrir a janela de propriedades, clique na aba Indexes/Keys e no botão NEW para criar um novo índice.
- Indique o campo MD5 na lista Column Name. Aceite o nome sugerido para o indice.
- Clique novamente no botão NEW, indique o campo SHA-1 na Column Name. O nome sugerido para o índice deve ser mantido.
- Clique em Close e logo em seguida no primeiro botão da esquerda para direita, para salvar as alterações.

Lembre-se que essa operação pode demorar bastante, já que a tabela é bem grande. Aqui, nós estamos criando dois índices distintos para facilitar as consultas posteriores.

Ao final dessa fase, temos a base NSRL completamente carregada, sem duplicações, e indexada na tabela NSRL. Vamos para a próxima fase, mas antes exclua a tabela nsrlfile.

Fase 2

O objetivo dessa fase é obter um conjunto de hashes da nossa imagem, e em seguida carregá-los para nosso banco. Na fase 3 faremos a classificação propriamente dita.

O conjunto de hashes é obtido através do uso do MD5Deep (ou o SHA1Deep). Vamos manter nosso foco para o MD5, mas os passos para o SHA-1 são análogos.

- Inicialmente, monte a imagem sendo analisada. Provavelmente, você estará com um Live CD de análise de forense computacional, como o Helix ou o FCCU.

- Vá para a raiz da imagem montada e use o comando MD5Deep -r * > resultado.txt

Esse comando faz com que todos os arquivos tenham seu hash calculado, desde a raiz, e de forma recursiva. Toda a saída do comando é jogada para o arquivo resultado.txt. Lembre-se que essa operação pode ser demorada, de acordo com o tamanho da imagem e do número de arquivos nela.

O próximo passo é carregar esse arquivo para uma tabela na nossa base. Não vou entrar em detalhes novamente, pois o processo é o mesmo de quando carregamos os arquivos nsrlfile.txt. Apenas leve em conta que, nesse caso, nao há nomes de campos na primeira linha e como separador de campo indique dois espaços. Observe que o próprio programa de carga já mostra as primeiras linhas carregadas, com nomes de colunas col001 e col002. Confira se está tudo certinho e indique aux como nome da tabela a ser criada com esse resultado. Novamente, essa operação será longa, dependendo do tamanho do arquivo a ser carregado.

Ao final dessa operação, teremos uma nova tabela chamada aux com duas colunas (Col001 e Col002). Vamos ao Query Analyser rodar um comando SQL que vai criar uma nova tabela a partir dessa, acrescentando um campo para o código do caso. Com esse código, sempre poderemos guardar as informações relativas ao caso e consultar quantas vezes quisermos.

Select [Caso] = '2007-001', [md5] = Col001, Arq = Col002 into Hashes from Aux

Confira se o conteúdo da tabela Hashes está igual ao da tabela Aux. Exclua a tabela Aux (vamos salvar espaço, certo ?) e crie índice para o campo MD5 da tabela Hashes.

Ao final dessa fase, nós temos uma base de dados com duas tabelas: a NSRL, com toda a base de hashes da nsrl, sem duplicações e campos desnecessários, e a tabela hashes, já carregada com os hashes da imagem do nosso primeiro caso. Todas devidamente indexadas.

Vamos para a próxima fase ...

Fase 3

Essa é a hora da verdade ... Vamos executar duas queries. Uma imprimirá os arquivos conhecidos e a outra os não conhecidos. Usando o Query Analyser:

Select CONHECIDOS=Arq from hashes h left outer join nsrl n on h.md5 = n.md5
where
caso = 'codigo do caso'
and
n.md5 is not null

Select DESCONHECIDOS=Arq from hashes h left outer join nsrl n on h.md5 = n.md5
where
caso = 'codigo do caso'
and
n.md5 is null

A saída de cada um pode ser usada em análises mais minuciosas. Ela equivale à saída do comando MD5Deep com as opções comentadas no último post sobre hashes.

Comentários e melhorias

- As duas queries acima podem ser gravadas como stored procedures, passando o código do caso por parâmetro. Ficará mais fácil para re-executar as classificações

- O tamanho da base ficará enorme, mas pouco utilizado. Um comando de Shrink Database é interessante para recuperar o espaço.

- Backup é fundamental. Faça um backup logo após o término de cada fase, para garantir.

- Uma abordagem alternativa é fazer o Shrink Database logo após o término da Fase 1. Faça um backup em seguida, e assim ganhará mais tempo e gastará menos espaço no backup.

- A fase 3 será executada todas as vezes que você quiser reclassificar os arquivos. Melhor do que fazer isso é gravar as duas saídas ...

- Se quiser adicionar os hashes de um novo caso/imagem, a operação é bem simples. Obtenha o arquivo com os hashes (como no caso do resultado.txt). Carregue-o para uma tabela aux, como no processo da fase 2. Logo em seguida, no Query Analyser, execute a seguinte query:

Insert hashes select Caso = 'codigo do novo caso', [md5] = Col001, Arq = Col002 from aux

Esse comando SQL vai inserir a tabela recem carregada para a tabela de hashes definitiva. Exclua a tabela aux, ao final. A partir daqui, execute as queries da fase 3 para classificar os arquivos.

- O processo explicado acima pode ser feito em uma passada só, diretamente na carga. Se você conhece o SQL Server, vá em frente !

- A NSRL libera versões novas 4 vezes por ano. A fase 1 precisará ser refeita todas as vezes, se você quiser se manter atualizado com as versões.

- Uma boa opção é montar uma base própria de hashes contendo figuras, musicas e outros itens. Recomendo colocar esses em uma tabela a parte, carregando-a da mesma forma que os arquivos anteriores. As queries da fase 3 precisarão de uma adaptação, pois a classificação será feita a partir de uma union da tabela NSRL com a tabela criada por você.

- É possível inserir mais um nível de classificação: Quebrar os arquivos conhecidos em bons e maus. Basta criar mais um campo na tabela NSRL com o default de ser bom. Na tabela acima, com seus próprios hashes como base, sempre que um arquivo for reconhecido como mau, o tal campo deve ser setado de acordo.

Finalmente ...

Demorou, mas chegamos ao fim dessa parte do artigo. Vou parar por aqui comentando o seguinte:

1) Você aprendeu que a classificação de arquivos é muito importante, pois com ela diminuímos os arquivos a serem analisados, tornando a investigação viável e mais focada.

2) Você aprendeu também que se modificamos apenas um mero bit em um arquivo, o resultado da computação do hash dele vai ser completamente diferente do original. Veja bem ... Estamos falando de mudar um mísero bit !

De posse das duas informações acima, pense junto comigo o que alguém poderia fazer para piorar a vida de um Investigador Computacional...

Certo, você percebeu ! Se um usuário mal intencionado trocar apenas um bit, ou byte, de todos os arquivos no HD, a classificação desse HD diria que todos os arquivos são desconhecidos. Isso inviabilizaria (ou tornaria muito difícil) a investigação. Essa técnica é conhecida como Anti-Forensics (é uma das técnicas usadas, na verdade), e pode atrapalhar um bocado a nossa investigação.

Mas nem tudo está perdido !

No próximo artigo sobre hash, vamos falar de uma solução bastante nova para esse problema.

Até o próximo post !

Nosso Amigo Hash - Parte IV

Hash aplicado na Forense Computacional - Prática

Quinto exemplo: Determinando e Selecionando Arquivos Conhecidos e Desconhecidos

Já comentei em um dos posts passados sobre um grande problema para os investigadores computacionais: O enorme número de arquivos e artefatos para serem analisados.

A técnica mais comum para diminuir a quantidade de arquivos é aplicar filtros que separem a mídia analisada, destacando os arquivos que são conhecidos dos desconhecidos. Dessa forma, esquecemos os conhecidos e mantemos o foco da análise nos desconhecidos, na busca de evidências.

Para ajudar nessa classificação (conhecido e desconhecido), entra em cena nosso amigo hash. A técnica consiste em:
1) Computa-se o hash do arquivo
2) Busca-se na base pelo hash computado. Se achou, o arquivo é classificado como conhecido
3) Se não achou, o arquivo é classificado como desconhecido e vai receber maior atenção durante a análise.

Dando nomes aos bois

Continuaremos usando o CD do Helix nos nossos exemplos.

Para aplicar a técnica, usamos o utilitário MD5Deep. Esse utilitário é muito semelhante ao já apresentado MD5Sum. Ele calcula o hash MD5 do arquivo indicado (ou do diretório), mas tem algumas vantagens sobre o MD5Sum:

• O MD5Deep tem a opção de calcular hashes para cada arquivo em um diretório indicado, podendo descer na estrutura dos subdiretórios, de forma recursiva.
• É possível passar ao MD5Deep uma lista de hashes e, através de parâmetros, fazê-lo verificar se o hash computado está ou não na lista passada.

A lista citada possui um formato conhecido e pode ser tanto gerada pelo próprio MD5Deep/MD5Sum ou então obtida fazendo o download das bases conhecidas como Hashsets.

Uma das mais acessíveis é a disponibilizada pela NSRL. Essa base, produzida e mantida pelo NIST, é uma grande lista de arquivos contendo o hash computado em MD5 e SHA-1, devidamente separados por Sistema Operacional, Pacote, versão de Software, etc. Ela é atualizada trimestralmente e está na versão 2.17 enquanto escrevo esse post.

Vamos a prática

Primeiro, vamos baixar e montar as bases da NSRL:

1) Faça o download dos 4 arquivos disponibilizados no site da NSRL, nesse link. Verifique que há quatro downloads para se ter a base completa (disc 1 a disc 4) . Lembre-se que os arquivos são muito grandes e podem levar bastante tempo.

2) Após os downloads, use o MD5Sum ou o MD5Deep para calcular o hash do arquivo baixado com o hash declarado no link signatures.

3) Cada arquivo é uma imagem de CD. Extraia dessa imagem os arquivos compactados que no final terão as bases de hashes.

4) Mantenha as bases em um diretório único, divididas nos respectivos subdiretórios, para facilitar.

Ao final dessa etapa, você deverá ter um diretório com 4 subdiretórios, e em cada um deles os arquivos descompactados e extraídos das imagens .iso baixadas. Vamos supor que temos /NSRLFILES com os subdiretórios A, B, C e D.

Na nossa prática, faremos a classificação dos arquivos do diretório /Arquivos de Programas e todos os seus subdiretórios. Todos os arquivos desconhecidos, isto é, que não estiverem na base NSRL, serão exibidos.

cd /Arquivos de Programas
MD5Deep -r -x /NSRLFILES/A/NSRLFile.txt -x /NSRLFILES/B/NSRLFile.txt -x /NSRLFILES/C/NSRLFile.txt -x /NSRLFILES/D/NSRLFile.txt *

A opção -r junto com o * no final do comando faz com que o MD5Deep calcule o hash de todos os arquivos do diretório /Arquivos de Programas e seus subdiretórios.

A opção -x passa uma base de hashes para o utilitário e indica a ele que liste o arquivo se ele não estiver relacionado na base. Como a base NSRL é dividida em 4, adicionamos todas as 4 através dos parâmetros -x. Todos os arquivos que forem listados a partir desse comando são arquivos desconhecidos que receberão maior foco na investigação.

Variações

Podemos, ao invés de classificar todos os arquivos de um diretório, classificar apenas um arquivo (ARQUIVO.EXE, no nosso exemplo). Nesse caso, o comando seria:

cd /Arquivos de Programas
MD5Deep -x /NSRLFILES/A/NSRLFile.txt -x /NSRLFILES/B/NSRLFile.txt -x /NSRLFILES/C/NSRLFile.txt -x /NSRLFILES/D/NSRLFile.txt ARQUIVO.EXE

Outra variação desse uso é carregar apenas a base específica do NSRL. Se você prestou bastante atenção, percebeu que a NSRL dividiu suas bases (non-English sw, operationg systems, application sw, images & graphics) e assim é possível passar para o utilitário MD5Deep apenas a base que se aplica.

Também é possível usar o MD5Deep para criar sua própria base de hashes, bastando redirecionar a saída do comando para um arquivo:

MD5Deep * > novabase.txt

Problemas

Um ponto muito ruim nessa técnica é que as bases são muito grandes e o utilitário carrega para a memória todas as bases passadas para ele antes de começar as comparações. Dessa forma, a memória rapidamente é exaurida com o comando acima que carrega várias bases. Esse problema ficou ainda pior se usado no Helix 1.8, pois nessa versão não há suporte ao swapon/swapoff, comandos que acionam a memória virtual (swap). Nesse caso, a RAM é usada até sua exaustão e o Helix trava.

Além de tentar carregar apenas uma base específica, uma opção para esse problema seria usar esse comando fora do Helix, em um sistema com a memória virtual devidamente configurada.

Ainda assim, há uma opção melhor através do uso de banco de dados, e estaremos falando nisso nos próximos posts.

Uma ultima observação

Os exemplos tratados aqui fazem referência a classificação entre arquivos conhecidos e desconhecidos. Algumas instituições, ao contrário da NSRL, oferecem bases classificadas entre conhecidos bons e conhecidos maus. Exemplos disso seriam uma base com hashes de códigos maliciosos ou hashes de imagens com conteúdo sobre pedofilia. Entretanto, nesses casos nosso interesse maior na investigação é justamente descobrir na imagem analisada os arquivos que tiverem hash coincidindo na base. O comando seria:

cd /Arquivos de Programas
MD5Deep -m /BASEVIRUS/base.txt *

Todos os arquivos do diretório que estiverem classificados na base serão listados. O investigador, a partir daí, intensifica sobre esse resultado sua análise.

Até o próximo post !