Compartilhar no facebook
Facebook
Compartilhar no whatsapp
WhatsApp
Compartilhar no google
Google+
Compartilhar no linkedin
LinkedIn

Data Carving e Parsing: Reconstruindo e correlacionando logs eliminados

Você recebe um chamado, um vazamento de informação corporativa, seu chefe pede para investigar a saída de arquivos da empresa. Quando então você vai conversar com o técnico, recebe a informação de que a máquina foi formatada e disponibilizada a outro profissional, ou que a máquina está com o disco sem qualquer sistema de arquivos.

O que você tem é um disco com um bando de espaço não alocado. Será possível identificar algum log neste mar de “nada”? Em sistemas XP os logs tem magic numbers ou assinaturas idênticas. 30 00 00 00 4c 66 4c 65 01 00 00 00 01 00 00 00 – Igualmente um log típico tem 512k ou 1mb em servidores.

É aí que entra o conceito de data carving, que vai além de recuperar blocos de dados, mas dar significado aos mesmos (meaningful format), transformando-os em arquivos interpretáveis. Para esta tarefa indicamos a Ferramenta Data Lifter File Extractor Pro (http://www.datalifter.com/products.htm)

Podemos facilmente identificar padrões que indicam arquivos de logs em meio a blocos não estruturados. No Linux, temos o binário Scalpel (http://www.digitalforensicssolutions.com/Scalpel/), um dos melhores “file carver” da história, tendo sido escrito em derivação ao popular foremost.

Por default, todos os tipos de arquivos disponíveis no Scalpel ficam em /etc/scalpel/scalpel.conf Para executá-lo basta digital o comando seguido do device em que pretende recuperar os arquivos: scalpel /dev/hda1.

Logs recuperados. Mas muitos podem estar corrompidos. Como sabemos, os registros de logs no Windows ficam, via de regra, em arquivos “.evt” e para isso utilizaremos uma excelente ferramenta para reconstruir estes caras. A FixEvt, do reconhecido Rich Murphey (http://www.murphey.org/fixevt.html) é uma command line muito útil para o problema que temos. Para disparar: % fixevt *.evt

Assim o utilitário indicará que o arquivo foi reparado, ou que não precisa de reparo, que não foi reparado ou que pode ser reparado por outro método. Pronto, agora já recuperei logs e também reparei os corrompidos, mas ainda me falta a principal atividade, correlacioná-los.

Para isso utilizaremos a ferramenta LogParser, da Microsoft, capaz de ler nossos arquivos .evt, nos permitindo ainda rodar instruções SQL sobre os arquivos de log. Podemos, por exemplo, selecionar apenas os arquivos de logs que não estão corruptos, vejamos:

scalpel /dev/hda1
fixevt *.evt
for i in *.evt;do LogParser “select count(*) from $i” \
&& cp $i goodlogs; done

Podemos brincar com o LogParser apenas sabendo as colunas dos arquivos de logs que são, via de regra, Time, SID, Source, Severity, Message. Um exemplo para utilizarmo o LogParser é

select <columns> from <table> into <output-file>
logparser “select * from system.evt into milagre.csv”

Podemos ainda incrementar nossas análises por exemplo filtrando os logs por período ou mesmo buscando por uma mensagem específica dentro dos arquivos de logs, vejamos:

… where TimeGenerated > ‘2006-11-11 00:00:00’
and TimeGenerated < ‘2006-11-12 00:00:00’
… where Message like “%CD Burning%” …

Podemos, enfim, descobrir muitas informações, como correlacionar logs dos roteadores, que é o primeiro dispositivo que um atacante encontra quando ataca uma rede. Roteadores tem o papel de encaminhar pacotes que chegam à rede para seus destinatários. Muitos roteadores tem a capacidade de registrar o tráfego que passam por eles. Por vezes sua aplicação pode ser burra, não registrar nada, porém a prova necessária estar em um dispositivo como este… Pense!

Vale a pena avançar nos estudos!

BIBLIOGRAFIA:

http://www.dfrws.org/2007/proceedings/p92-murphey_pres.pdf

http://simson.net/ref/2011/2011-07-12%20Android%20Forensics.pdf

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Rolar para cima