Documente Academic
Documente Profesional
Documente Cultură
www.4linux.com.br
Projetos na sua empresa
com a qualidade dos treinamentos
i
Capítulo 1
Computação Forense
1
1.2 Estratégias de investigação 4Linux – www.4linux.com.br
Infelizmente, por falta de padronização, há vários termos que podem gerar confusão
como: perícia forense, forense computação, investigação digital, forense digital, perí-
cia digital, dentre outros usados comumente para descrever a mesma ciência. Nor-
malmente o termo forense digital ou investigação digital é empregado quando o
escopo não abrange somente computadores, mas também smartphones, tablets e
outros dispositivos digitais.
Já o trabalho de perícia, tem a ver com o adjetivo perito, usado para descrever pessoa
extremamente hábil e conhecedora de algum assunto.
A estratégia adequada para a investigação vai depender do tipo de caso mas normal-
mente segue uma sequência lógica que envolve indetificação da evidência, preser-
vação, coleta, análise e apresentação. Alguns autores e investigadores subdividem
estes cinco estágios ou alteram sensivelmente sua ordem. Tudo depende da exper-
iência do especialista, do tipo de caso e de como a situação se apresenta.
1.2.1 Identificação
Nesta etapa todas as fontes de prováveis evidências devem ser consideradas e reg-
istradas. Desde câmeras de vigilância até pen drives soltos sobre a mesa, todos os
aparelhos envolvidos no caso devem ser considerados. Segue uma lista parcial de
itens a serem considerados:
• Teclado
• Mouse/Touchpad
• Scanners
• Discos externos
• Documentos impressos
Tudo deve ser anotado por você. É essencial fotografar também. Nesta etapa que
você define o que será preservado, ou seja, o que é importante para a investigação,
além de registrar o estado de todas as evidências antes de você manipulá-las. Isso
vai ajudar a provar a integridade das fontes de informação, se necessário.
1.2.2 Preservação
Os dados que estão presentes nas fontes de informações que você enumerou na
etapa anterior também precisam ter sua integridade garantida e é exatamente o que
acontece nesta etapa.
A ideia é que você não cause nenhuma alteração nas evidências quando começar a
coletá-las.
Um bom exemplo é a descarga elétrica estática (do inglês ESD: Eletrical Static Dis-
charge) que o contato físico com um hardware sensível pode causar e fazer com que
os dados tenham sua integridade comprometida. A ocorrência de uma ESD depende
de fatores como nível de carga no corpo, umidade relativa do ar no ambiente den-
tre outros fatores físicos, mas é possível até mesmo danificar uma placa de circuito
simplesmente ao enconstar nela. Para evitar esta desagradável surpresa, existem
pulseiras antiestáticas como a da foto abaixo.
Nesta etapa você também vai decidir se desliga ou não os aparelhos que contém
as evidências. Existe um ditado que diz: Se está ligado, não desligue e se está
desligado, não ligue. No entanto, nem sempre ele é válido. Pode haver casos onde o
ambiente está sob ataque e desligar (ou desconectá-lo da rede, se for o caso) pode
ajudar a minimizar os prejuízos. Você deve estudar as vantagens e desvantagens de
cada ação para o seu caso a fim de tomar a medida mais viável.
É possível também que você tenha que decidir entre desligar os computadores de
maneira tradicional, solicitando ao sistema operacional que inicie o processo de
Bloquear dispositivos contra gravação, seja por hardware ou por software também é
uma boa ideia nesta etapa.
Antes de coletar os dados, é essencial criar um hash das mídias envolvidas no pro-
cesso, tentando ser o menos intrusivo possível e com bloqueios contra escrita.
Após a coleta dos dados (que veremos com detalhes no capítulo 2), estes hashes
devem ser checados e precisam ser idênticos, salvas exceções onde não é possível
bloquear a mídia contra escrita e haja escrita constante. Neste caso, cada cópia da
mídia terá um hash diferente e uma cópia acompanhada deve ser validada individ-
ualmente.
1.2.3 Coleta
Todo o trabalho aqui deve ser feito para gerar o menor impacto possível na máquina,
ou seja, quanto menos alterações em memória e em disco o especialista causar
para coletar os dados, menos dados são perdidos na coleta. A este impacto dá-se
o nome de footprint. Instalar um programa para realizar a coleta é uma ação que
normalmente gera um footprint considerável uma vez que o programa de instalação
precisa ser carregado em memória e vários arquivos são criado e/ou alterados du-
rante a instalação, por isso na coleta recomenda-se utilizar ferramentas existentes
em um pen drive ou mídia similar, funcionais para o SO alvo e evitar qualquer alter-
ação no disco rígido das máquinas onde a coleta será realizada.
Logicamente não há como evitar alterações na memória RAM das máquinas que
farão parte da investigação, uma vez que os softwares utilizados para a coleta pre-
cisam ser carregados. No entanto, deve ser dada preferência aos softwars com
menor footprint, ou seja, os executáveis otimizados que não utilizam muita RAM para
funcionarem.
Nesta etapa também se precisa calcular os hashes dos arquivos coletados e imagens
geradas, para que sejam incluídos no relatório da etapa de apresentação.
Lembre-se que uma análise em dados coletados pode ser refeita várias vezes,
mas a coleta em si normalmente não. Portanto, esta etapa de coleta deve ser min-
uciosa e muito bem estudada. Qualquer perda de dados pode ser irrecuperável e
comprometer a abrangência da análise com consequências diretas na qualidade da
investigação como um todo.
1.2.4 Análise
O importante é definir o que está sendo procurado. Sem saber o que se procura, a
análise pode demorar muito ou mesmo nunca terminar e o trabalho do perito será
ineficiente.
Nesta etapa várias ferramentas podem ser utilizadas, assim como técnicas de análise
manual, que aprenderemos mais à frente. Abaixo uma lista de distribuições Linux que
agregam várias ferramentas específicas para computação forense. Seu uso não é
obrigatório, mas é importante conhecê-las:
BackBox Linux distribuição para pen tests e testes de segurança que objetiva ser
rápida e com o mínimo de pacotes possíveis.
DEFT Linux (Digital Evidence and Forensic Toolkit) distribuição fácil de usar que
reúne algumas das melhoras aplicações de código aberto para resposta à inci-
dentes e computação forense.
Helix uma das mais antigas distribuições focadas em computação forense, com
muitas aplicações da área.
Matriux distribuição para pen test e computação forense baseada em Debian, com
cerca de 300 aplicações da área e até kernel personalizado.
Swift Linux leve distribuição baseada com ferramentas para computação forense e
recuperação de dados.
1.2.5 Apresentação
O relatório deve ser bem explicativo, de preferência com uso de imagens para tornar
fácil o suficiente para um público não técnico entender, mesmo que sem profundi-
dade. Um modelo de relatório pode ser consultado no Anexo I.
Você deve entregar junto ao relatório uma tabela com todos os hashes calculados
durante a investigação e uma mídia (um DVD-R por exemplo) com os arquivos en-
contrados.
Aquisição de dados
11
2.3 Memória no espaço do kernel 4Linux – www.4linux.com.br
O kernel, drivers e afins rodam no sistema de forma privilegiada e com sua própria
área de memória. Este modo de execução é conhecido como kernelmode, espaço de
kernel ou ring0. A memória mapeada neste modo pode também ser obtida através
de um dump de memória.
• BIOS ROM
• Buffer de periféricos
Mídias ópticas como CD-R, DVD-R e BD-R são simples de serem copiadas e natu-
ralmente já são memórias somente de leitura. Qualquer software capaz de efetuar
uma cópia idêntica de um fluxo de dados será suficiente para obter o conteúdo de
uma mídia óptica, sem complicações.
Já dispositivos USB funcionam, na forma lógica, como discos rígidos e podem con-
ter uma ou várias partições, com diferentes sistemas de arquivos. Neste caso a
cópia também pode ser feita um software de cópia bit a bit, porém deve-se prestar
a atenção ao que se está copiando, inclusive nas permissões de acesso à mídia (é
interessante montar a mídia como somente leitura, assim como as mídias ópticas
são montadas).
Para dar um exemplo mais claro, um pen drive pode ter duas partições: uma NTFS
e uma ext4. Copiar a mídia inteira para um arquivo de imagem pode ser mais com-
plicado de analisar que copiar as partições separadamente para dois arquivos de
imagem distinhos.
2.6 Partições
A tabela de partições pode estar no MBR (Master Boot Record - Setor Mestre de Ini-
cialização), que é a forma tradicional de particionamento, ou no GPT (GUID Partition
Table). Neste último caso, o MBR ainda é usado mas apenas indicará onde está o
GPT.
O MBR é o primeiro setor do disco rígido e por ser um setor, tem 512 bytes de
Cada entrada de partição na tabela de partições ocupa 16 bytes, por isso o número
máximo de partições na tabela é 4.
Investigação em ambientes
GNU/Linux
É mais que sabido por todos os profissionais da área de tecnologia que ela muda
muita. Na computação forense não é diferente. Uma ferramenta ou abordagem
pode se tornar ultrapassada em questão de dias, por isso é importante se manter
atualizado a todo momento.
Em relação ao kernel Linux temos importantes mudanças nas versões recentes que
precisam ser levadas em consideração:
• /dev/kmem em desuso
• Proteção no /dev/mem
As mudanças não param e é importante para o profissional estar em dia com tais
atualizações para adaptar suas ferramentas e técnicas às novas configurações. Um
17
3.2 Aquisição de memória RAM 4Linux – www.4linux.com.br
Quando um novo filesystem começa a ganhar espaço, é bem possível que você se
depare com ele numa investigação e por isso é recomendado que você estude suas
especificações para não ficar perdido caso precise analisá-lo.
Existe ainda uma hipótese baseada na recuperação dos dados imediatamente após
o desligamento da máquina, quando os capacitores ainda estão se descarregando e
que pode envolver até o congelamento por resfriamento dos módulos de memória,
mas é algo que ainda não teve sua eficiência comprovada.
Para obter uma cópia da memória mapeada por um processo no Linux, primeiro
é preciso saber qual a faixa de endereços que o processo está utilizando. Para
isto, você pode consultar um arquivo especial em /proc/<pid>/maps onde <pid> é o
PID (Process IDentifier) do processo em questão. São várias regiões de memória
mapeadas para um processo, dentre elas a heap e a stack, também conhecida
como pilha. Por isso é importante saber o que se procura e conhecer as regiões de
memória onde os dados procurados costumam ser armazenados.
Após escolher a região, o gdb (GNU Debugger), pode ser utilizado para dumpar a
faixa de memória escolhida.
No exemplo abaixo, algumas linhas e colunas foram removidas para facilitar a visu-
alização:
$ cat /proc/17008/maps
00400000-00401000 r-xp 00000000 08:05 7604329
00600000-00601000 rw-p 00000000 08:05 7604329
7fe6d5d29000-7fe6d5ea6000 r-xp glib/x86_64-linux-gnu/libc-2.13.so
7fe6d5ea6000-7fe6d60a6000 ---p glib/x86_64-linux-gnu/libc-2.13.so
7fe6d60a6000-7fe6d60aa000 r--p glib/x86_64-linux-gnu/libc-2.13.so
7fe6d60aa000-7fe6d60ab000 rw-p glib/x86_64-linux-gnu/libc-2.13.so
7fe6d60b0000-7fe6d60cf000 r-xp glib/x86_64-linux-gnu/ld-2.13.so
Também pode ser útil para o investigador colher uma cópia de todo o conteúdo da
memória RAM. Apesar de ser mais difícil analisar, alguns softwares tentam com-
preender a organização dos dados na RAM e provêem uma saída bem interes-
sante.
dd if=/dev/mem of=ramdump
O arquivo ramdump será criado com todo o conteúdo da memória RAM. No entanto,
conforme consta na introdução deste capítulo, pode ser que o /dev/mem esteja prote-
gido e somente o primeiro megabyte de memória esteja acessível. Se esta proteção
estiver ativa, o dd não conseguirá copiar mais que 1 MB da memória:
# dd if=/dev/mem of=ramdump
dd: lendo "/dev/mem": Operação não permitida
2056+0 registros de entrada
2056+0 registros de saída
1052672 bytes (1,1 MB) copiados, 0,0362599 s,
29,0 MB/s
areas as well, these contain the PCI * mmio resources as well as potential bios/acpi
data regions. */
Fonte: https://github.com/torvalds/linux/blob/master/arch/x86/mm/init.c#L304
$ wget -c http://hysteria.sk/~niekt0/foriana/fmem_current.tgz
$ tar xf fmem_current.tgz
$ cd fmem*
$ make
$ sudo ./run.sh
$ free -m
total used free shared buffers cached
Mem: 3901 3779 122 0 138 1466
-/+ buffers/cache: 2175 1726
Swap: 926 0 926
Como eu usei a opção -m do free para exibir o resultado em megabyes, usei a opção
bs (block size) do dd para configurá-lo a copiar 3901 (opção count) blocos, ou seja,
o total da RAM, para o arquivo ramdump.
Adquirir dados de discos não é muito diferente de adquirir dados da memória, com
exceção é claro de sua característica não volátil, então mesmo com a máquina desli-
gada, os dados do disco permanecem (com algumas exceções pois pode haver ar-
madilhas que apagam rastros caso a máquina seja desligada - inclusive-se recomenda-
se desligar a máquina na tomada em alguns casos).
1+0 records in
1+0 records out
Você deve ter percebido que a sintaxe é muito parecida com a do dd, mas no co-
mando acima usamos a opção hash, que já calcula os hashes desejados da imagem
gerada, um dos recursos do dcfldd. Para mais informações, basta consultar o manual
da ferramenta, como com qualquer ferramenta Unix-like que se preze. ;)
# fdisk -l
29664+0 records in
29664+0 records out
Em seu antecessor, o ext3, somente os três primeiros atributos estão presentes, algo
que a comunidade de segurança já se incomodava. A resolução de tempo passou a
ser de nanosegundos, contra segundos do ext3.
http://e2fsprogs.sourceforge.net
dumpe2fs Exibe informações sobre uma partição. Pode ser usado com uma im-
agem gerada pelo e2image
debugfs Um debugger interativo que também pode ser usado com imagens do
e2image
Para cada arquivo existente no filesystem, existe uma estrutura responsável por
representá-lo chamada inode. O inode também armazena todas as informações
sobre um arquivo, com exceão de seu nome e conteúdo. Para verificar tais infor-
mações, podemos usar o comando stat:
# stat mbr.img
File: "mbr.img"
Size: 512 Blocks: 8 IO Block: 4096 arquivo comum
Device: 805h/2053d Inode: 7604329 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ nandu) Gid: ( 1000/ nandu)
Access: 2012-05-22 00:06:14.492249402 -0300
Modify: 2012-05-22 00:06:32.056336493 -0300
Change: 2012-05-22 00:06:32.056336493 -0300
Birth: -
No entanto, conforme você deve ter percebido, a data de criação do arquivo não
apareceu. Acontece que nem todas as ferramentas já estão adaptadas ao ext4, mas
por sorte o debugfs resolve:
$ rm mbr.iso
# debugfs -R ’stat <7604329>’ /dev/sda5
Inode: 7604329 Type: regular Mode: 0644 Flags: 0x80000
Generation: 3982433542 Version: 0x00000000:00000001
User: 1000 Group: 1000 Size: 0
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4fbb3ad4:d0c06a9c -- Tue May 22 04:05:56 2012
atime: 0x4fbb39fe:dce57df0 -- Tue May 22 04:02:22 2012
mtime: 0x4fbb3ad4:d0c06a9c -- Tue May 22 04:05:56 2012
crtime: 0x4fbb01ac:be7fc6ac -- Tue May 22 00:02:04 2012
dtime: 0x4fbb3ad4 -- Tue May 22 04:05:56 2012
Size of extra inode fields: 28
EXTENTS:
O debugfs também pode atuar com imagens de disco, como faremos nos exercí-
cios.
É possível ver quais os blocos utilizados por um determinado inode com o comando
dessa forma:
Um inode pode utilizar mais de um bloco por conta do tamanho do arquivo repre-
sentado por ele, mas em nosso exemplo ele utiliza apenas um bloco, de número
30447449. Podemos extrair tal bloco do disco com o dd:
O hash MD5 comprova que não há qualquer diferença entre o arquivo original e o
recuperado.
• Processos em execução
• Sockets abertos
• Usuários logados
• Arquivos abertos
• Tabela de rotas
• Tabela ARP
• Variáveis de ambiente
• Dispotivos montados
Você provavelmente já ouviu falar na tabela ASCII (American Standard Code for In-
formation Interchange), certo? É uma tabela que relaciona cada caractere com um
número, de 0 a 255, totalizando 256 caracteres possíveis. Para visualizá-la, você
pode conferir o Anexo II, mas se tiver o hack-functions instalado, basta comandar
asciitable no terminal.
Através da tablea ASCII é possível perceber que a letra maiúscula F, por exemplo,
possui o código 0x46 (70 decimal).
Na verdade o número 0x46 é representado como F, quando você pede. Por exem-
plo:
$ echo 0x46
0x46
$ echo -e ’\x46’
F
$ str2hex -x 4Linux
\x34\x4c\x69\x6e\x75\x78
No exemplo acima exibi o texto 0x46, o equivalente em ASCII do número 0x46, com
o comando echo. Em seguida, usei a função str2hex das hack-fuctions para exibir o
byte correspondente de cada caractere da string 4Linux. Que tal conferir na tabela
ASCII se a função está mostrando os bytes corretamente?
Sendo assim, devemos concordar que para procurar strings dentro de um arquivo,
seja ele qual for, é só procurar uma sequência de bytes (digamos, com no mínimo
três) que estejam na faixa de 0x20 até 0x7e, correto? Se olhar na table ASCII, verá
que estes são os caracteres imprimíveis.
strings.c
1 # include < stdio .h >
2 # include < stdbool .h >
3
4 int main ( int argc , char * argv [])
5 {
6 // ponteiro para o arquivo
7 FILE * arquivo ;
8
9 // buffer de 1 byte (0 a 255) para armazenar o byte lido
10 unsigned char buffer ;
11
12 // esta vari á vel vai controlar quando vamos pular linha
13 bool nova_string = false ;
14
15 // se n ã o for informado nenhum arquivo , emite um erro e sai
16 if ( argc != 2)
17 {
18 printf ( " Uso :\ n \ t % s < arquivo >\ n " , argv [0]) ;
19 return 1;
20 }
21
22 // tenta abrir o arquivo
23 arquivo = fopen ( argv [1] , " rb " ) ;
24
25 // caso n ã o consiga , emite um erro e sai
26 if ( arquivo == NULL )
27 {
28 printf ( " arquivo % s inexistente ou ileg í vel \ n " , argv [1]) ;
29 return 1;
30 }
31
32 // enquanto a fun ç ã o fread () retornar 1 , significa
33 // que 1 byte foi lido no arquivo e o loop continua
34 while ( fread (& buffer , sizeof ( buffer ) , 1 , arquivo ) == 1)
35 {
36 // se o byte estiver entre a faixa desejada
37 if ( buffer >= ’ ’ && buffer <= ’~ ’)
38 {
39 // se for uma nova string , pula uma linha
40 if ( nova_string == true )
41 putchar ( ’\ n ’) ;
42
43 // imprime na tela a representa ç ã o ASCII do byte
44 putchar ( buffer ) ;
45
46 // assume que a string ainda n ã o acabou
47 nova_string = false ;
48 }
49 else
50 {
51 // o byte atualmente lido n ã o pertence à
52 // faixa , ent ã o assumimos que uma nova
53 // string vem a í !
54 nova_string = true ;
55 }
56 }
57 putchar ( ’\ n ’) ;
58 fclose ( arquivo ) ; // fecha o arquivo
59
60 return 0;
61 }
O programa acima vai imprimir na tela todos os bytes de um arquivo passado por
argumento que possuam representação em ASCII e sejam imprimíveis.
Mas não precisamos escrever nosso próprio programa de busca de strings se es-
tivermos no Linux pois o projeto GNU já fornece um programa chamado strings que
faz exatamente isto:
$ strings -t x mbr.img
9d ZRr=
116 ‘|f
11f \|f1
180 GRUB
186 Geom
18b Hard Disk
195 Read
19a Error
O comando strings adimite que, para ser uma string, a sequência precisa ter pelo
menos 3 caracteres imprimíveis. A opção -t x faz com que ele imprima o offset da
string em hexadecimal. Assim, numa análise, você pode copiar todas as strings num
dump de memória para um arquivo:
3.4.2 Carving
Neste exemplo vamos buscar por arquivos GIF dentro do dump. Para isso pre-
cisamos conhecer a especificação do GIF, como mostra a tabela abaixo (fonte: Wikipedia):
De cara, vemos o header da última versão do formato, que deve ser composto pelos
bytes 0x47 0x49 0x46 0x38 0x39 0x61, que representam em ASCII a string "GIF89a".
Se quiser confirmar, pode checar na tabela ASCII.
Casamos com a string inteira. Seria muita coincidência esses 6 caracteres casarem
se isso não for o início de um GIF? É o que veremos:
$ hd -s 0x80000 -n 64 dump.bin
00080000 47 49 46 38 39 61 65 01 1a 02 f7 00 00 bb 9c 91 |GIF89ae.........|
00080010 6e 5b 54 d9 ad 9c 6b 69 69 ca a4 94 e3 8c 7d 3f |n[T...kii.....}?|
00080020 1e 0e 33 0d 09 f6 cb ba e1 b4 a3 e3 bb aa eb ca |..3.............|
00080030 8a c8 44 39 0b 05 04 6b 26 21 44 27 19 fa f2 e4 |..D9...k&!D’....|
O próximo byte, segundo o exemplo na documentação, quando é 0xf7, diz que o GIF
tem 256 cores, dentre outras informações. Este byte bate com o nosso 0xf7.
Não precisamos ir até o final checando todos os campos para chegar ao fim do
arquivo. A maioria dos formatos de arquivo definem um ou mais bytes para marcar
o fim do arquivo. No caso do GIF, veja na documentação que os últimos bytes são
0x00 (end) e 0x3b (GIF terminator). Lembre-se que isso é específico do formato
GIF e não é regra para qualquer tipo de arquivo. Cada um tem seu formato.
Os formatos que não possuem bytes que marcam o fim, geralmente possuem
um campo que diz o tamanho completo do arquivo.
Vamos à busca:
A primeira sequência que "00 3b"que o grep encontrou após o offset 0x80000 (início
do GIF) está em 0x82b65. Neste offset está o 0x00 e em 0x82b66 está o 0x3b,
portanto o próximo byte (0x55) não faz parte do GIF.
$ echo $((0x82b67-0x80000))
11111
A resposta é em decimal. Uma maneira mais fácil de fazer esta conta e já ter a
resposta em hexadecimal seria usando a função hexcalc:
É preciso somar mais um pois o primeiro byte, na posição 0x80000, já conta. Vamos
relembrar o que temos:
Tipo: GIF
Resolução: 357x538 pixels
Extração com o dd
A opção bs (block size) informa ao dd para assumir blocos de 1 byte. A opção count
diz quantos blocos ele vai ler, então vão dar exatamente 11111 bytes. E por fim, a
opção skip, que só aceita números em decimal (por isso a conversão com o bash)
informa quantos bytes o dd vai pular para começar a ler, assim como a opção -s"do
hd. Temos que começar a extração do byte 0x80000, que é onde começa o GIF.
Vamos conferir:
$ file possivel.gif
possivel.gif: GIF image data, version 89a, 357 x 538
$ wc -c possivel.gif
11111 possivel.gif
bém se baseia no formato de arquivos para realizar sua busca. Seu uso é bastante
simples:
1 FILES EXTRACTED
gif:= 1
------------------------------------------------------------------
Trabalhar com imagens de disco geralmente envolve montá-las como somente leitura
e buscar por arquivos de log, configuração e afins.
$ chmod -w sda.img
$ md5sum sda.img && sha1sum sda.img
cebdd715d4ecaafee8f147c2e85e0754 sda.img
ec3e661d7bc7bfbf5334e7dfad309f947dace5f7 sda.img
$ cp sda.img{,.1}
$ md5sum sda.img.1 && sha1sum sda.img.1
cebdd715d4ecaafee8f147c2e85e0754 sda.img.1
ec3e661d7bc7bfbf5334e7dfad309f947dace5f7 sda.img.1
blkcalc
ifind
sorter cria uma lista ordenada por tipo de arquivo de arquivos numa imagem
Basicamente, onde lê-se "imagem"na listagem acima, também se pode ler "disposi-
tivo", para usar as ferramentas em um dispositivo vivo (ex.: /dev/hda).
$ mmls -B sda.img
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
A opção -B do mmls adiciona a coluna Size, com os tamanhos das partições encon-
tradas.
Esta listagem também poderia ser feito com outros programas como fdisk ou
parted, mas como combinamos anteriormente, vamos dar foco nas ferramentas do
TSK.
Journal ID: 00
Journal Inode: 8
METADATA INFORMATION
--------------------------------------------
Inode Range: 1 - 499713
Root Directory: 2
Free Inodes: 330871
CONTENT INFORMATION
--------------------------------------------
Block Range: 0 - 1998335
Block Size: 4096
Free Blocks: 647705
$ head deletados
md5|file|st_ino|st_ls|st_uid|st_gid|st_size|st_atime|st_mtime|st_ctime|st_crtime
0|<sda.img-dead-8348>|8348|-/rrwxr-xr-x|0|0|0|1314888705|1316025882|1316025882|0
0|<sda.img-dead-8349>|8349|-/rrwxr-xr-x|0|0|0|1314888705|1316025882|1316025882|0
0|<sda.img-dead-9398>|9398|-/lrwxrwxrwx|0|0|22|1317147975|1314723730|1317149808|0
0|<sda.img-dead-9413>|9413|-/rrw-r--r--|0|0|0|1314723902|1314723902|1314723902|0
0|<sda.img-dead-16562>|16562|-/rrw-r--r--|6|0|0|1316191568|1316191568|1316191568|0
0|<sda.img-dead-33560>|33560|-/lrwxrwxrwx|0|0|28|1316026597|1314720528|1316028062|0
0|<sda.img-dead-33561>|33561|-/lrwxrwxrwx|0|0|30|1316026597|1314720528|1316028062|0
0|<sda.img-dead-33563>|33563|-/lrwxrwxrwx|0|0|28|1316026597|1314720528|1316028062|0
0|<sda.img-dead-33985>|33985|-/rrw-r--r--|0|0|0|1300882082|1314720504|1314720504|0
Perceba que vários arquivos estão com os tamanhos (st_size) zerados e não adi-
anta tentar recupera-los pois não há nada dentro deles. Mesmo os que estão com
tamanho maior que zero, ainda dependerá se os blocos antigamente utilizados pelo
inode já foram reutilizados ou não. Em caso positivo, a recuperação por software se
torna muito ineficiente.
A opção -r faz o fls funcionar de maneira recursiva, já a -d pede que só liste arquivos
excluídos.
Montando as partições
Todo o trabalho até agora vem sido feito com o arquivo sda.img sem ser montado, no
entanto, é extremamente útil montar as partições desta imagem do disco para facilitar
a busca por arquivos, caso este recurso esteja disponível. Então mãos à obra:
O que houve? Acertou se lembrou que o arquivo sda.img é uma imagem de um disco
inteiro e não só de uma partição, por isso é necessário montar somente a partição
no offset 2048 (lembra?) do arquivo e não ele inteiro.
Ops. O que houve agora? Lembre-se que esse offset diz respeito a um dispositivo
em blocos (disco rígido) onde a menor unidade de armazenamento é um setor, de
normalmente 512 bytes. Já a opção offset do mount precisa da posição exata do
arquivo de onde começar, para chegar nela basta multiplicar o offset apresentado
pelo mmls pelo tamanho do setor, que o mmls também nos diz:
É possível que a tabela de partições do disco esteja corrompida, neste caso é bom
que você conheça o filesystem utilizado para tentar identificar os dados incosistentes
e consertá-los. Se a situação estiver muito ruim, o jeito é utilizar carving, como
fizemos com dumps de memória.
Supondo que você recuperou um arquivo chamado "suspeito", vamos rodar algumas
ferramentas para tentar documentar seu comportamento, começando pela file, que
tenta identificar o tipo de arquivo em questão:
$ file suspeito
suspeito: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.26,
BuildID[sha1]=0x341dd4ba97cb52603efd9d1ede68e04a1f633bb7, not stripped
Já deu pra saber que o arquivo é um ELF (formato de executáveis usado no Unix/Linux)
e foi compilado para 64-bits, dentre outras informações.
$ readelf -h suspeito
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2’s complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x400490
Start of program headers: 64 (bytes into file)
Start of section headers: 7512 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 8
Size of section headers: 64 (bytes)
Number of section headers: 29
Section header string table index: 28
O readelf apresenta uma série de informações úteis, dentre elas o endereço do en-
trypoint, que é onde o código do programa começa a ser executado. Neste nosso
exemplo, é em 0x400490.
Já que estamos lidando com um binário dinamicamente linkado (vide saída do file),
podemos pedir ao readelf que nos mostre a tabela de símbolos dinâmicos utilizados
pelo binário:
De fato, trata-se de um binário compilado em C, visto que as funções que ele utiliza
estão na glibc (GNU C Library) e ele usa as funções write(), system() e creat(), para
checar o que tais funções fazem, basta checar as páginas de manual nas seções 2
e 3:
Experimente também usar o comando strings para buscar por texto dentro do
binário suspeito. Isto pode adiantar muito trabalho. ;)
Percebeu alguns endereços sendo copiado para alguns registrados antes da chamada
a __libc_start_main()? Vamos buscar o último (possivelmente a main do progra-
mador) com o objdump novamente:
Estudar Assembly foge ao nosso foco, mas dá pra ter uma ideia do que o programa
faz. Ou não? Se ficar difícil, pode-se partir para uma análise dinâmica, como vere-
mos a seguir.
O strace é um programa bastante poderoso, que faz uso da ptrace() - uma chamada
de sistema (syscall) para rastrear ações de um determinado processo, para logar
todas as chamadas de sistema que um processo faz. Note que o processo faz o
que o ele quer fazer, portanto se tratando de um arquivo suspeito, este deve ser
executado num ambiente controlado (máquina virtual ou similares).
A syscall open foi chamada com a flag O_RDONLY, que garante que o arquivo será
aberto com permissão somente para leitura. ;)
$ strace ./suspeito
creat("/tmp/ls", 0777) = 3
write(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\2\0>\0\1\0\0\0l\4@\0\0\0\0\0"...,
4577) = 4577
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD,
parent_tidptr=0x7ffff5750568) = 18172
wait4(18172, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 18172
--- SIGCHLD (Child exited) @ 0 (0) ---
exit_group(0) = ?
Deixarei como exercício para você dizer o que este suspeito faz. Como dica, use a
opção -f do strace para capturar as chamadas também do processo filho criado pela
chamada à syscall clone e o man do próprio Linux para consulta.
• Sem símbolos
Este capítulo será menor, visto que várias técnicas de análise já foram apresentadas
no capítulo anterior e utilizaremos das mesmas técnicas, com algumas peculiari-
dades, para análise de dumps Windows, portanto daremos maior foco nas difer-
enças.
57
4.2 Aquisição e análise de RAM com win32dd 4Linux – www.4linux.com.br
O NTFS ainda é muito utilizado, portanto daremos um foco especial nele, mas tam-
bém falaremos do novo ReFS.
Name Value
---- -----
File type: Raw memory dump file
Acquisition method: PFN Mapping
Content: Memory manager physical memory block
Processing....Done.
O arquivo ramdump será criado no diretório atual com o conteúdo da memória RAM.
O NTFS se estabeleceu como filesystem padrão nas versões do Windows para servi-
dores desde o Windows NT e se mantém até o Windows 2008. Já nas versões para
estação de trabalho, sua popularização veio com o Windows XP e desde então vem
sido o padrão de instalação até o Windows 7. A última versão da especificação é
a 3.1 (não confundir com a versão do driver, que é a 6.1 no Windows 7 e 2008 R2)
e basearemos nossos estudos nesta versão. Claro que nosso estudo será válido
também para entedimento de versões anteriores à 3.1 ou mesmo posteriores, ou até
outros filesystems como o ReFS (Windows 8) que veremos mais adiante.
No Windows é possível saber qual a versão de uma partição NTFS com o seguinte
comando:
Após localizar a partição NTFS (0x7) depois de ler a tabela de partições no MBR,
a primeira estrutura é o setor de boot da partição, de 512 bytes. A existência
deste setor é uma característica comum nos filesystems populares e nele há várias
informações importantes para forense, dentre elas um trecho conhecido como BPB
(Bios Parameter Block), que começa no byte 0xb do setor de boot da partição e vai
até o byte 0x54, resultando em 0x49 bytes de tamanho.
O BPB é uma estrutura com vários campos, sendo o mais importante deles o campo
de 8 bytes que começa no byte 0x30 chamado LogicalClusterMFT. Este cara contém
o número do cluster onde está armazenada a MFT (Master File Table), a tabela que
referencia todos os arquivos presentes na partição. Em uma analogia simples, esta
tabela é para o filesystem o que um índice é para um livro.
Uma maneira fácil de identificar uma entrada na MFT é a string FILE, no início de
cada entrada de 1024 bytes (2 setores). Cada entrada representa um arquivo, mas
existem arquivos especiais chamados metafiles que contém informações sobre a
partição. Existe até mesmo uma entrada que representa a própria MFT.
O Sleuth Kit possui suporte à partições NTFS, logo, é possível utilizá-lo sem prob-
lemas. As técnicas de carving apresentadas e ferramentas como foremost e scalpel
também possuem suporte e podem ser utilizadas quando a partição estiver corromp-
ida e não puder ser montada.
Existem milhares de pragas construídas para danificar sistemas e boa parte delas
são executáveis PE, que tem como sistema alvo os sistemas Windows. O tipo PE
(Portable Executable) é facilmente reconhecido por conta de uma herança do formato
MZ do MS-DOS que recebeu este nome de um dos desenvolvedores do MS-DOS
chamado Mark Zbikowski. Esta assinatura "MZ"está logo no início do arquivo e faz
$ hd -n 64 putty.exe
00000000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 |MZ..............|
00000010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |........@.......|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 |................|
00000040
$ file putty.exe
/home/nandu/winapp/putty.exe: PE32 executable (GUI) Intel 80386, for MS Windows
Para ver mais informações sobre o PE, pode-se utilizar o pev, um toolkit multiplataforma
que fornece uma série de binários para trabalhar com arquivos PE:
$ readpe -S putty.exe
Sections
Name: .text
Virtual Address: 0x1000
Physical Address: 0x53371
Size: 0x54000 (344064 bytes)
Pointer To Data: 0x1000
Relocations: 0
Characteristics: 0x60000020
contains executable code
is executable
is readable
Name: .rdata
Virtual Address: 0x55000
$ readpe -S mewpacker.exe
Sections
Name: SBL
Virtual Address: 0x1000
Physical Address: 0x23000
Size: 0 (0 bytes)
Pointer To Data: 0
Relocations: 0
Characteristics: 0xc00000e0
contains executable code
contains initialized data
contains uninitialized data
is readable
is writable
Name: ?ug?
Virtual Address: 0x24000
Physical Address: 0x19000
Size: 0x9fa9 (40873 bytes)
Pointer To Data: 0x200
Relocations: 0
Characteristics: 0xc00000e0
contains executable code
contains initialized data
contains uninitialized data
is readable
is writable
Perceba uma seção chamada SBL (sem ponto na frente) de tamanho zerado e uma
outra com um nome bem estranho. Coisa boa não é. Outro recurso é buscar funções
de TLS callbacks (comumente exploradas por programadores de malware) e packers
em si:
$ pescan mewpacker.exe
entrypoint: normal
$ pepack mewpacker.exe
packer: Mew 11 SE v1.2 (Eng) -> Northfox
No exemplo acima não havia funções TLS callbacks, mas o pescan acusou que o
DOS stub do PE é suspeito (foi modificado) e as seções também. Adicionalmente, o
pepack detectou o packer MEW. Vale a atenção!
E a partir do valor do EP, você pode usar o pedis para obter o disassembly:
Assim como usamos o strace para verificar as syscalls utilizadas por um ELF, pode-
mos usar o Process Explorer para obter as chamadas às funções da API do Windows
que o PE faz. O software é gráfico e ao executá-lo, podemos criar filtros pelo nome
do processo ou PID para que ele mostre ações apenas de quem queremos. Esta
análise deve ser feita em um ambiente controlado, sempre.
Além de executáveis em si, é possível ser infectado com outros tipos de arquivos
ou pode ser preciso entender algum formato específico para concluir o trabalho da
perícia forense. Neste capítulo vamos analisar arquivos PDF e imagens JPG.
Arquivos PDF (Portable Document Format) são verdadieros containers que podem
abrigar desde simples textos e imagens a poderosos programas em Flash ou JavaScript.
Dentro deles há tanto texto quando dados binários.
73
5.1 Documentos PDF com pdfid e pdf-parser 4Linux – www.4linux.com.br
[bytes]
endstream
endobj
3 0 obj
106
endobj
Os objetos podem ser de vários tipos e existem alguns nomes pré-definidos como
/JavaScript, /JS, /OpenAction, /RichMedia e /Launch. Estes particularmente são pre-
ocupantes pois podem conter código executável que o leitor de PDF tentará executar
ao ser aberto.
Objetos também podem referenciar outros objetos, neste caso a palavra "obj"é sub-
stituída pela letra maiúscula R. Com isso já dá para traçar uma linha investigativa
no sentido de observar os objetos de um documento PDF, principalmente se tiverem
esses nomes sugestivos apresentados.
$ ./pdfid.py teste.pdf
PDFiD 0.0.11 teste.pdf
PDF Header: %PDF-1.4
obj 6
endobj 6
stream 1
endstream 1
xref 2
trailer 2
startxref 1
/Page 1
/Encrypt 0
/ObjStm 0
/JS 1
/JavaScript 1
/AA 1
/OpenAction 0
/AcroForm 0
/JBIG2Decode 0
/RichMedia 0
/Launch 0
/Colors > 2^24 0
<<
/S /JavaScript
/JS 1054 0 R
>>
\begin{verbatim}
$ ./pdf-parser.py -o 54 test.pdf
obj 1054 0
Type:
Referencing:
Contains stream
[(1, ’\r\n’), (2, ’<<’), (2, ’/Length’), (1, ’ ’), (3, ’0000’), (2, ’/Filter’),
(1, ’ ’), (2, ’[’), (2, ’/F#6c#61#74e#44e#63#6fde’), (2,
’/#41#53#43II#38#35#44#65#63#6fd#65’), (2, ’]’), (2, ’>>’), (1, ’\r\n’)]
<<
/Length 0000
/Filter [
/FlateDecode /ASCII85Decode]
>>
O arquivo stream.txt conterá todo o fluxo de dados após passar pelos filtros e será
possível ver o código JavaScript nele.
Imagens JPG e PNG podem conter informações valiosas numa estrutura conhecida
como EXIF (Exchangeable Image File Format). Nem sempre essas informações são
visíveis ao SO. Avalie as capturas de tela abaixo. A primeira foi tirada no Gnome e a
segunda no Windows XP.
Percebemos que alguns campos existem numa captura e na outra não, mas estamos
visualizando os dados da mesma imagem.
$ jhead tracking.jpg
File name : tracking.jpg
File size : 314085 bytes
File date : 2011:03:30 02:13:53
Camera make : SAMSUNG
Camera model : GT-I5500B
Date/Time : 2010-11-18 00:46:23
Resolution : 1600 x 1200
Focal length : 2.7mm
Exposure time: 0.125 s (1/8)
Aperture : f/2.7
ISO equiv. : 200
Whitebalance : Auto
Metering Mode: center weight
Exposure : aperture priority (semi-auto)
GPS Latitude : ? 23d 19m 44.502s
GPS Longitude: ? 48d 29m 19.548s
Note que o jhead exibe até mesmo coordenadas GPS presentes na imagem, en-
quanto nem o Gnome nem o Windows XP o fazem. Essas informações podem ser
extremamente úteis numa perícia forense.
5.3 Esteganografia
$ wc -c *.jpg
145338 chess.jpg
161051 out.jpg
$ md5sum *.jpg
4c59e2956ba43e342a18ab4e8505cbb4 chess.jpg
9e8dc2125a2d8adbab424167f62947fa out.jpg
6.1 Sniffers
Normalmente o driver de uma placa de rede descarta os pacotes que não são des-
tinados ao endereço dela. Este é o funcionamento normal, no entanto, é possível
alterar este comportamento utilizando softwares conhecidos como sniffers de rede.
Além de não descartar nenhum pacote, os sniffers capturam (salvam) os bytes dos
pacotes recebidos em disco. O formato mais conhecido para armazenar pacotes é o
PCAP, implementado pela libpcap e WinPcap.
Exemplos de sniffers populares são o tcpdump e o Wireshark, sendo que este último
é também um poderoso analisador de tráfego.
O comando abaixo fará uma captura na interface wlan0 por todo pacote que seja
destinado ou tenha como origem a porta 80:
81
6.1 Sniffers 4Linux – www.4linux.com.br
O último parâmetro é a expressão, uma ou mais condições que devem ser satisfeitas
para o tcpdump salvar o pacote no arquivo informado pela opção -w. Caso nenhuma
expressão seja informada, todos os pacotes serão salvos.
Uma expressão para capturar todos os pacotes ICMP com tamanho maior que zero
seria:
$ man 7 pcap-filter
1 - Física a camada de mais baixo nível, que trata dos meios físicos de conexão.
4 - Transporte TCP/UDP.
Não vamos estudar teoria de redes aqui e por isso vamos entender como o Wireshark
nos apresenta informações sobre um pacote:
O próximo item pode ser comparado à camada 4 (transporte), pois possui infor-
mações sobre o protocolo de transporte utilizado (TCP/UDP), portas utilizadas, flags
TCP.
E por último a interpretação do protocolo HTTP (neste caso, que é um pacote HTTP
mesmo), que pode ser comparado à soma das camadas 5, 6 e 7. É similar ao Modelo
TCP/IP de 4 camadas.
Anti-forense
• Formatação de mídias
• Esteganografia
• Criptografia
A lista acima contém somente alguns exemplos. Tais ações dependem da criativi-
dade do atacante e dos recursos disponíveis.
85
7.1 Compilando seus próprios binários para alvos Linux 4Linux – www.4linux.com.br
• Obter um dump de memória rapidamente (de preferência via pen drive ao ser
inserido)
Compilar seu próprio binário estático para rodar na máquina alvo pode evitar que
você rode um binário malicioso na máquina e/ou dependa de versões de bibliotecas
específicas que a máquina alvo pode não ter. Para isso, a ideia é baixar o código-
fonte do software e, se for escrito em C, adicionar a opção -static ao gcc. Veremos
agora um exemplo de compilação do dcfldd. Para softwares escritos em outras lin-
guagens, consulte a documentação do compilador utilizado.
O arquivo binário dcfldd será criado e você pode conferir se realmente é um binário
estático com o ldd:
$ ldd dcfldd
not a dynamic executable
01 FAT12
02 XENIX root
03 XENIX usr
04 FAT16 <32M
05 Extended
06 FAT16
07 HPFS/NTFS/exFAT
08 AIX
09 AIX bootable
87
4Linux – www.4linux.com.br
0B W95 FAT32
10 OPUS
11 Hidden FAT12
12 Compaq diagnostics
16 Hidden FAT16
17 Hidden HPFS/NTFS
18 AST SmartSleep
24 NEC DOS
39 Plan 9
3C PartitionMagic recov
40 Venix 80286
42 SFS
4D QNX4.x
50 OnTrack DM
52 CP/M
54 OnTrackDM6
55 EZ-Drive
56 Golden Bow
5C Priam Edisk
61 SpeedStor
70 DiskSecure Multi-Boo
75 PC/IX
80 Old Minix
83 Linux
85 Linux extended
88 Linux plaintext
8E Linux LVM
93 Amoeba
94 Amoeba BBT
9F BSD/OS
A5 FreeBSD
A6 OpenBSD
A7 NeXTSTEP
A8 Darwin UFS
A9 NetBSD
AB Darwin boot
AF HFS / HFS+
B7 BSDI fs
B8 BSDI swap
BE Solaris boot
BF Solaris
C1 DRDOS/sec (FAT-12)
C6 DRDOS/sec (FAT-16)
C7 Syrinx
DA Non-FS data
DE Dell Utility
DF BootIt
E1 DOS access
E3 DOS R/O
E4 SpeedStor
EB BeOS fs
EE GPT
EF EFI (FAT-12/16/32)
F0 Linux/PA-RISC boot
F1 SpeedStor
F2 DOS secondary
F4 SpeedStor
FB VMware VMFS
FC VMware VMKCORE
FE LANstep
FF BBT
Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex Dec Hex
0 00 NUL 16 10 DLE 32 20 48 30 0 64 40 @ 80 50 P 96 60 ‘ 112 70 p
1 01 SOH 17 11 DC1 33 21 ! 49 31 1 65 41 A 81 51 Q 97 61 a 113 71 q
2 02 STX 18 12 DC2 34 22 " 50 32 2 66 42 B 82 52 R 98 62 b 114 72 r
3 03 ETX 19 13 DC3 35 23 # 51 33 3 67 43 C 83 53 S 99 63 c 115 73 s
4 04 EOT 20 14 DC4 36 24 $ 52 34 4 68 44 D 84 54 T 100 64 d 116 74 t
5 05 ENQ 21 15 NAK 37 25 % 53 35 5 69 45 E 85 55 U 101 65 e 117 75 u
6 06 ACK 22 16 SYN 38 26 & 54 36 6 70 46 F 86 56 V 102 66 f 118 76 v
7 07 BEL 23 17 ETB 39 27 ’ 55 37 7 71 47 G 87 57 W 103 67 g 119 77 w
8 08 BS 24 18 CAN 40 28 ( 56 38 8 72 48 H 88 58 X 104 68 h 120 78 x
9 09 HT 25 19 EM 41 29 ) 57 39 9 73 49 I 89 59 Y 105 69 i 121 79 y
10 0A LF 26 1A SUB 42 2A * 58 3A : 74 4A J 90 5A Z 106 6A j 122 7A z
11 0B VT 27 1B ESC 43 2B + 59 3B ; 75 4B K 91 5B [ 107 6B k 123 7B {
12 0C FF 28 1C FS 44 2C , 60 3C < 76 4C L 92 5C \ 108 6C l 124 7C |
13 0D CR 29 1D GS 45 2D - 61 3D = 77 4D M 93 5D ] 109 6D m 125 7D }
14 0E SO 30 1E RS 46 2E . 62 3E > 78 4E N 94 5E ^ 110 6E n 126 7E ~
15 0F SI 31 1F US 47 2F / 63 3F ? 79 4F O 95 5F _ 111 6F o 127 7F DEL
93
Capítulo 10
95
Capítulo 11
Anexo IV - Laudo
O laudo deve ser escrito em três vias assinadas pelo perito. Segue exemplo:
Listing:
1 Perito respons á vel :
2 Nome : Fernando Merc ê s
3 CPF : 987.201.432 -99
4 Email : fernando@merces . net
5 Telefone Comercial : (21) 0800 -0800
6 Telefone Celular : (21) 0300 -0300
7
8 Data de in í cio da per í cia :
9 1/4/2012
10
11 Data da emiss ã o do laudo :
12 10/4/2012
13
14 Sum á rio executivo :
15 Informa ç õ es sigilosas foram copiadas do servidor de dados da
empresa Dexter
16 Courrier enviadas por e - mail para terceiros . O objetivo é
descobrir como essa
17 informa ç ã o vazou .
18
19 Escopo da per í cia :
97
4Linux – www.4linux.com.br
20 Servidor de dados
21 Hostname : srv01
22 FQDN : srv01 . dexter . local
23 CPU : Intel Xeon 2.2 GHz
24 Mem ó ria : 8 GB DDR -2
25 Placa -mã e : Intel 80 DGP
26 Discos : 4 x Samsung SG2000 250 ,0 GB