PERÍCIA FORENSE COMPUTACIONAL:

Análise de Malware em Forense computacional utilizando

de sistema operacional GNU/Linux
Alex Sander de Oliveira Toledo1
Robert de Souza2

RESUMO: O presente trabalho apresenta as boas práticas na coleta, restauração, identificação, preservação, documentação, análise dos dados periciais,
apresentação de vestígios, evidências, provas digitais e interpretação aplicadas aos componentes físicos ou dados processados e/ou armazenados nas mídias
computacionais, garantindo assim o valor jurídico das provas eletrônicas.

PALAVRAS-CHAVE: Perícia forense computacional, Malware, Linux.

1 INTRODUÇÃO “[...] Não há padrões internacionais para o tratamen-

Segundo Melo (2009), a informação é hoje um dos ativos
mais importantes das corporações, sendo de suma importân-
cia que sua integridade seja mantida. Em um passado não
muito distante um servidor mal configurado representava ris-
cos, mas estes eram confinados dentro dos limites da LAN da
corporação.
Com o advento da Internet estas fronteiras foram elimina-
das, facilitando muito a ocorrência de crimes eletrônicos, onde
o criminoso e a vítima podem encontrar-se em localidades ge-
ográficas diferentes, até mesmo em países distintos. O cres-
cimento do número de computadores interconectados (Inter-
net) e o aumento de softwares com finalidades ilícitas de fácil
utilização disponíveis na rede aumentaram significativamente o
número de ataques.
Ainda Segundo Melo (2009), por mais seguro que seja um
Firewall ou um sistema de segurança, os sistemas operacionais
estão sempre sujeitos a falhas ainda desconhecidas, por este
motivo sugere-se prudência ao afirmar que um sistema está
imune a invasões ou invulneráveis.
As técnicas forenses são imprescindíveis para identificar
se um computador foi invadido, determinando de que forma
foi alterado, estabelecendo critérios para preparar o ambiente
visando registrar os dados periciais, facilitar a identificação do
invasor e amparar as medidas legais a serem tomadas para
caso a resposta seja positiva, pois a invasão constitui crime
eletrônico.
O valor jurídico de provas eletrônicas manipuladas de for-
ma incorreta, sem os padrões previstos e devidamente estabe-
lecidos podem ser facilmente contestadas.
Segundo Melo (2009, p. 1), não há padrões internacionais
para o tratamento de dados periciais:
to de dados periciais, embora existam documentos
de boas práticas dedicados a classificar respostas a
incidentes de segurança e um capítulo da ISO NBR
IEC17799:2005 que endereça o assunto [ABNT].”
É importante empregar boas práticas na coleta, restaura-
ção, identificação, preservação, documentação, análise dos
dados periciais, apresentação de vestígios, evidências, provas
digitais e interpretação aplicadas aos componentes físicos ou
dados processados e/ou armazenados nas mídias computa-
cionais, garantindo assim o valor jurídico das provas eletrônicas
captadas no processo de perícia forense computacional.
Segundo Melo (2009), as principais fontes de dados pe-
riciais encontram-se nas estações de trabalho em ambiente
computacional distribuído, servidores, locais na internet, em lo-
cal remoto na Internet, sistemas de informação, e equipamen-
tos eletrônicos programáveis.
Segundo Tanenbaum (2003), existe uma diferença notória
entre Sistemas de Ambientes Computacional Distribuído e Sis-
tema de Redes de Computadores, ou seja, não se pode con-
fundir uma unidade de controle (servidor) e vários dispositivos
escravos com uma rede. Rede é uma visão conceitual aplicável
a um grande computador com terminais e/ou muitos micro-
computadores e impressoras conectados.
Um sistema computacional é considerado Distribuído
quando a camada de rede não está implementada, ou seja,
a interface de rede ativa pode-se comunicar diretamente com
todos os demais computadores.
Segundo Melo (2009), devido à evolução dos tipos de Malwa-
res (softwares maliciosos) as soluções de seguranças devem
sempre ser revistas, os fabricantes de Sistemas Operacionais e

172 | PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/2012 - EDIÇÃO 5 - ISSN 2176 7785
Softwares de Segurança sempre disponibilizam novas soluções.
Caso um invasor utilize de técnicas clássicas, como arma-
zenar, manter, e ou esconder ferramentas anti-forense durante
sua ação em diretórios clássicos como /tmp, um perito pode
facilmente localizar evidências atuando apenas com binários
compilados estaticamente, neste caso imagina-se que rootkits
baseados em técnicas arrojadas de LKM (Loadable Kernel Mo-
dule) não sejam utilizadas.
Segundo Melo (2009, p. 67) em relação à técnicas mais
arrojadas:
“Caso seja constatado o uso de técnicas mais arroja-
das, os dados levantados durante uma Live Análise são
facilmente contestadas. Somente durante a Post Mortem
Análise, os resultados são realmente confiáveis, pois du-
rante a Live Analise possivelmente as chamadas ao sis-
tema podem ser interceptadas.”
Segundo Farmer e Venema (2007, p. 174-175), os passos
para coleta de dados são:
“(...) O(s) computador(es) em questão deve(m) ser
colocado(s) off-line. Há alguns potenciais problemas
com isso, porque o sistema talvez espere estar on-line.
Portanto, colocar a máquina off-line poderia destruir ves-
tígios à medida que o sistema gera erros, repetidamente
tenta novas conexões ou, em geral, altera seu estado.
Alternativamente, você poderia tentar cortar a conexão
da máquina com o roteador e mantê-la em uma rede lo-
cal, mas os serviços de DNS e serviços de rede e outros
sistemas na mesma área de rede ainda podem causar
problemas.
À medida que você avança, é necessário monitorar tudo o
que você digita ou faz. Em geral é uma situação do tipo “coletar
primeiro, analisar mais tarde”. Anote as configurações de har-
dware, software, sistemas e rede que estão definidas.”
O autor aponta estas considerações devido à divergência
de opiniões sobre o assunto, pois alguns peritos consideram o
fato de desligar a máquina um grave erro, já que alguns invaso-
res podem utilizar de técnicas mais arrojadas e plantar bombas
para que caso a máquina seja retirada da rede ou desligada,
executem comandos, e desta forma eliminem vários vestígios
e destrua provas que seriam de grande valor no laudo pericial.
2 IDENTIFICAÇÃO E DESCRIÇÃO DOS MALWARES
“Malware pode ser definido como Malicious Software ou
Software Malicioso, ou seja é um termo genérico que engloba
todos os tipos de programas especificamente desenvolvidos
PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/2012 - EDIÇÃO 5 - ISSN 2176 7785 l 173
para executar ações maliciosas em um computador. O Malwa-
re contém ameaças reais de vários tipos e propósitos.” (MELO,
2009, p.10).
Segundo Brian, James e George (2003, p.194) a respeito
dos Cavalos de Tróia:
“Os cavalos de troia são programas criados para contor-
nar a segurança da sua máquina, mas disfarçados como
algo benigno. Assim como a criação grega, um cavalo de
Tróia do computador não pode fazer nada sozinho, mas
precisa contar com o usuário ajudando-o a cumprir seu
destino. Existe três usos principais da palavra troiano no
linguajar moderno do computador:
Programa de cavalo de Tróia: um programa malicioso que
se disfarça de uma coisa, mas contorna sua segurança em
segredo. Esse é o uso mais comum da palavra.
Código-fonte troiano: uma cópia do código-fonte do pro-
grama que foi modificada para conter alguma porta dos
fundos ou brecha na segurança.
Binários troianos: Após uma invasão um atacante pode
substituir binários do sistema por versões que contêm pos-
tar dos fundos ou que ocultam suas atividades.”
Segundo MELO (2009, p. 10), define-se Vírus:
“Programa que pode atuar como um binário indepen-
dente ou alojar-se em um programa executável, tornan-
do-o um arquivo binário infectado. Em sua engenharia,
não é definido um vetor de transmissão automatizado.
Depende da execução do programa, do arquivo hospe-
deiro ou de um meio, como um cliente de correio, para
que possa voltar a propagar e dar continuidade ao pro-
cesso de infecção.”
Segundo Melo (2009), o Worm é um tipo de Malware capaz
de se propagar automaticamente por meio de redes enviando
copias de si mesmo para outros computadores, esta propaga-
ção está prevista em sua engenharia, e se dá por meio da explo-
ração de vulnerabilidades existentes ou falhas nas configurações
de softwares instalados nos computadores, criando um cenário
em que não é necessário ser executado para se propagar, po-
dendo propagar-se em qualquer tipo de sistema operacional.
Ainda Segundo MELO (2009, p. 12) sobre Rootkits e Spywares:
“Rootkit – Tipo de Malware muito arrojado, sua enge-
nharia normalmente prevê a instalação de binários, mó-
dulos, bibliotecas que disponibilizam os mais variados
recursos como: Backdoors, Cleanlogs, Keyloggers.
Usa técnicas para esconder processos e outras infor-
mações inerentes ao mecanismo, o que dificulta sua
 identificação, além de sua instalação se dar de forma
automatizada.
Normalmente são instalados logo após o comprometi-
mento de um computador por um invasor.
Spyware – Uma categoria muito peculiar de Malware,
que usufrui as capacidades dos browsers em execu-
tar aplicações. A maioria quase absoluta desse tipo
de Malware é escrita tendo como alvo sistemas Mi-
crosoft.”
Portanto estes Malwares colocam em risco os princípios
básicos da segurança (integridade, disponibilidade e confia-
bilidade) estas ameaças podem trazer diversos prejuízos às
organizações, prejuízos não só financeiros, mas também de
perda parcial ou total de seus ativos da Tecnologia da Infor-
mação e Comunicação (TIC).
3 DESCOBERTA DO MALWARE
Quando é descoberto o Malware em um sistema, há
muitas decisões e ações que devem ser tomadas. Para me-
Segundo MELO (2009, p. 36), quanto ao cuidado na execu-
ção das ferramentas de análise Live Forense:
O conjunto de ferramentas selecionadas deve ser compilado
estaticamente para compor o ferramental de Resposta de Incidente
que deverá ser utado na Live Forense. A compilação da ferramenta
no modo estático a partir do código fonte gera um binário que não
utiliza as bibliotecas dinâmicas do sistema. Adotando-se essa pre-
caução o binário alojado em CDROM se torna imune a tentativas de
inoculação de código por programas maliciosos.
3.2 ANÁLISE DE MEMÓRIA
Segundo Farmer e Venema (2007), todos os sistemas ope-
racionais modernos utilizam memória virtual como uma abstra-
174 | PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/2012 - EDIÇÃO 5 - ISSN 2176 7785
lhor estruturarmos o processo de investigação e análise de
Malwares, o dividiremos em cinco fases: Preservação e análi-
se de dados voláteis, Análise de memória, Análise de discos,
Análise estática de Malware e Análise dinâmica de Malware.
3.1 PRESERVAÇÃO E ANÁLISE DE DADOS VOLÁTEIS
Segundo Farmer e Venema (2007), em uma análise post-
mortem, tem-se pouco tempo para coletar informações en-
quanto a máquina comprometida permanece em execução,
para uma coleta eficaz os autores utilizam a ferramenta grave-
robber (ladrão de túmulos) do Coroner’s Toolkit, que é otimi-
zada para este cenário.
A grave-robber captura informações voláteis sobre proces-
sos e conexões de rede, atributos de arquivo como registros
de data/hora de acesso, arquivos de configuração, log e outros
tipos de arquivos. O resultado é armazenando em um banco
de dados que deve ser transferido para um sistema de análise.
Esta abordagem captura o estado volátil do processo,
mas há desvantagens, se o kernel foi subvertido, as informa-
ções podem estar incompletas ou corrompidas.
ção para tratar combinações da RAM, espaço de troca, ROM,
NVRAM e outros recursos de memória. O gerenciador de me-
mória que executa no kernel, trata a alocação e desalocação da
memória em um computador.
Segundo Melo (2009), a memória principal contém todo tipo
de informação volátil, como informações de processos que es-
tejam em execução, dados que estão sendo manipulados e que,
muitas vezes ainda não foram salvos em disco e informações no
sistema operacional.
O autor ainda exemplifica a coleta de evidência da memória
RAM, destacando os arquivos /dev/kmem que têm as informa-
ções de memória da área de kernel e /dev/mem, que é toda a
memória da máquina:
 # /cdrom/dd if=/dev/mem | cdrom/nc <ip> <porta>
# /cdrom/dd if=/dev/kmem | cdrom/nc <ip> <porta>
# /cdrom/dd if=/dev/rswap | cdrom/nc <ip> <porta>
# /cdrom/dd if=/dev/kcore | cdrom/nc <ip> <porta>
No exemplo acima o “#” informa que o usuário logado é o
root (super usuário do sistema), o “/cdrom” o diretório onde o
ferramental de resposta a incidente foi instalado para a utilização
em “Live Forense”, o comando “dd if=/dev/mem | /cdrom/nc
<ip> <porta> transfere uma imagem do conteúdo da memória
RAM, área de kernel, e swap para a máquina do perito através
do ip e da porta estipulada nos comandos citados.
3.3 ANÁLISE DE DISCO
Segundo Farmer e Venema (2007), há diversas maneiras de se
duplicar as informações sobre o sistema de arquivos. Qual método
estará disponível dependerá da situação, os dois autores já captu-
raram informações efetuando o login em uma máquina comprome-
tida, listando os arquivos para o terminal e registrando essa sessão
com um programa emulador de terminal. Veremos a seguir alguns
métodos para capturar estas informações.
3.4 CÓPIA DE ARQUIVOS INDIVIDUAIS
Segundo Farmer e Venema (2007), essa é a abordagem
menos precisa, porque só captura o conteúdo dos arquivos. Ne-
nhuma meta-informação é capturada, exceto talvez o tamanho
do arquivo. Todas as demais meta-informações são perdidas,
como posse do arquivo, datas/horas de acesso, permissões etc.
Estas informações só não são perdidas quando salvas
usando outro meio. Por exemplo, o utilitário grave-robber do
Coroner’s Toolkit que copia os arquivos selecionados (como
arquivos de configuração e registros em log) depois de salvar
suas meta-informações em um arquivo chamado body.
3.4.1BACKUP
Ainda segundo Farmer e Venema (2007), dependendo do
software de backup utilizado, esse método preserva algumas
meta-informações como posse, informações sobre links físicos
e a última data/hora da modificação, mas não captura a data/
hora do último acesso de leitura. Utilitários UNIX comumente
utilizados são tar, cpio e dump. A desvantagem de fazer um ba-
ckup é que o que você vê é tudo o que você obtém. Backups
não capturam as informações de arquivos excluídos
3.4.2 CÓPIA DE PARTIÇÕES DE DISCOS INDIVIDUAIS
Segundo Farmer e Venema (2007, p. 55), a respeito da có-
pia de partições:
PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/2012 - EDIÇÃO 5 - ISSN 2176 7785 l 175
Esse método cria uma cópia idêntica bit a bit de cada
sistema de arquivos, incluindo todas as meta-informa-
ções e todas as informações que permanecem em um
espaço não-alocado no fim dos arquivos, entre os ar-
quivos, nos blocos de inode não-alocados e assim por
diante. Isso em geral é feito com o comando dd.
Um benefício importa dessa abordagem é que ela é
neutra em relação ao sistema de arquivos. Por exemplo,
a mesma técnica pode ser utilizada para copiar tanto
partições UNIX quanto partições Windows. A desvanta-
gem é que os dados armazenados entre e fora das par-
tições não são analisados. Os fragmentos de comando
a seguir lêem a primeira partição UNIX no primeiro disco.
Linux #dd if=/dev/hda1 bs=100k . . .
Freebsd #dd if=/dev/da0s1a bs=100k . . .
Solaris #dd if=/dev/dsk/c0t0d0s0 bs=100k . . .
3.4.3 COPIAR DISCO INTEIRO
Segundo Farmer e Venema (2007), o resultado é uma cópia
idêntica bit a bit de todas as informações acessíveis no disco, in-
cluindo o espaço de armazenamento antes e depois das partições
de disco. Isso pode ser necessário quando há suspeitas de que os
dados poderiam permanecer ocultos fora das partições de disco.
Mais uma vez o “dd” é o comando ideal para realizar esta cópia.
Este método possui limitações, ele não lerá os blocos de
disco que contém erros e que o hardware silenciosamente rema-
peou para os chamados blocos sobressalentes. Esse método
também não fornecerá acesso aos blocos sobressalentes não
utilizados, porque eles residem fora da área normalmente aces-
sível ao disco. Os fragmentos de comando a seguir lêem todos
os blocos acessíveis no primeiro disco:
Linux #dd if=/dev/hda bs=100k . . .
Freebsd #dd if=/dev/da0 bs=100k . . .
Solaris #dd if=/dev/c0t0d0s2 bs=100k . . .
Ainda segundo Farmer e Venema (2007), a exatidão das in-
formações capturadas aumenta na medida em que dependemos
menos da integridade do sistema comprometido. Por exemplo,
quando arquivos individuais são capturados enquanto ainda estão
conectados à máquina da vítima, o aplicativo subvertido ou o sof-
tware de kernel subvertido pode distorcer esse resultado. A subver-
são é muito menos provável quando utilizamos um procedimento
de baixo nível de geração de imagens de disco, com a unidade de
disco conectada a uma máquina confiável.
3.5 ANÁLISE ESTÁTICA DE MALWARE
Segundo Farmer e Venema (2007, p. 120), sobre as técni-
cas de análise estática:
 “[...] Desassemblagem de programa (converter um ar-
quivo de programa em uma listagem de intrusões de
linguagem de máquina), descompilação de programa
(converter instruções de linguagem de máquina no códi-
go-fonte equivalente da linguagem de nível mais alto) e
análise estática (examinar um programa sem realmente
executá-lo)”
A desassemblagem de programa é um recurso padrão de
todo programa depurador importante, entretanto ferramentas
que descompilam programas em linguagem de alto nível como
C só existem para ambientes limitados. A ameaça da engenharia
reversa também apresenta um problema para programadores
de aplicativos Java.
A preocupação com o furto de propriedade intelectual talvez
tenha muito a ver com essa disponibilidade limitada de descom-
piladores.
3.6 ANÁLISE DINÂMICA DE MALWARE
Segundo Farmer e Venema (2007, p. 104), sobre os perigos
da análise dinâmica:
“Uma maneira de descobri o propósito de um programa
desconhecido é simplesmente executá-lo e ver o que
acontece. Há vários problemas potenciais com essa abor-
dagem. O programa poderia executar de uma maneira
confusa e destruir todas as informações na máquina [..]”
“Em vez de executar um programa desconhecido em uma
ambiente onde eles podem causar danos, é mais seguro exe-
cutar esse programa em uma caixa de areia. O termo caixa de
areia (sandbox) foi emprestado da balística, na qual as pessoas
testam armas atirando em uma caixa de areia de modo que as
balas não possam causar nenhum dano. Uma caixa de areia de
software é um ambiente controlado para executar o software.”
Ainda segundo Farmer e Venema (2007), as caixas de
areia podem ser implementadas de diversas maneiras, a
abordagem mais simples é o de cordeiro sacrificial, uma má-
quina real, mas descartável, com acesso limitado à rede ou
simplesmente sem acesso à rede.
4 COLETA DO MALWERE
Segundo Melo (2009), um perito forense, ao iniciar uma perícia
no sistema que teve uma segurança violada, busca evidências que
caracterizem e possibilitem identificar como e o quanto a violação
afetou as informações e o próprio Sistema Operacional.
Ainda segundo MELO (2009, p. 33), a coleta de evidências
pode ser dividida, de forma macro, em três etapas:
176 | PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/2012 - EDIÇÃO 5 - ISSN 2176 7785
A primeira etapa consiste na coleta de evidências antes
do desligamento do sistema da fonte elétrica, que tem
por objetivo registrar o estado do sistema, e a segunda
etapa, após o desligamento.
A segunda etapa, pelo termo oriundo do inglês, Network
Forensic, que consiste na coleta de análise de informa-
ções de atividade de rede, tanto do servidor em ques-
tão, como dos demais ativos de redes que tenham infor-
mações pertinentes.
E por último, a etapa em que todas as informações reu-
nidas nas etapas anteriores são cruzadas com informa-
ções identificadas na análise das imagens de mídias
coletadas. Essa última fase é tecnicamente conhecida
como Post Mortem Analysis.
Tanto na Live Analysis, na Network Forensic como na
Post Mortem Analysis, o objetivo é a coleta do máximo de
evidências digitais. O termo Dado pericial digital (pode
ser um vestígio, evidência ou mesmo se consolidar em
prova durante uma perícia) refere-se a toda e qualquer
informação digital capaz de demonstrar que ocorreu um
incidente de segurança ou mesmo um crime, dentro do
contexto da Perícia Computacional.
Segundo Farmer e Venema (2007), a sabedoria tradicional da
computação forense, conta com métodos muito conservadores, ra-
ramente nada além de desligar um computador e fazer uma cópia
de disco. Caso seja necessário assegurar que os dados coletados
sejam otimizados para poderem ser aceitos em um tribunal e só
conseguir capturar parte deles, então uma metodologia mais cau-
telosa pode ser a melhor opção em alguns casos.
Ainda segundo Farmer e Venema (2007, p. 172), sobre as
técnicas conservadoras:
“Infelizmente, essas técnicas conservadoras não têm uma
grande quantidade de informações potencialmente úteis
sobre a situação, como processos em execução e kernels,
estado de rede, dados na RAM e muito mais. Somente um
entendimento limitado pode surgir do exame de um disco
morto. E, embora informações dinâmicas talvez sejam um
pouco mais voláteis e, portanto suspeitas, quaisquer con-
denações com base em uma única série de leituras dos
dados também são suspeitas.[...]”
5 ANÁLISE DO ARQUIVO
Segundo Farmer e Venema (2007), pequenos programas
podem gerar muitos problemas, como observado abaixo, o có-
digo de um programa de backdoor recuperado após um ataque:
scanf (“%s”, buffer);
 if (strcmp(password, buffer)==0){
puts(“.”);
setuid(0);
setgid(0);
execl(“/bin/sh”,“sh”,(char *)0);
} Conforme os autores mencionados neste trabalho, parto do
return (0);
Com exceção da chamada de função de comparação de
string strcmp(), nenhuma chamada de função é testada quanto
a retornos de erro. Se uma operação falhar o programa simples-
mente prossegue. Erro de leitura de entrada a partir de scanf(),
caso todas as operações falhem o programa termina silencio-
samente.
6 Laboratório
Um cenário de análise de servidor foi montado para exem-
plificar a perícia forense computacional na busca por Malwares
em servidores Linux, a ferramenta utilizada para a perícia é o
Sistema Operacional Back Track.
princípio que todas as atividades para manter o sistema integro
e com o mínimo possível de perda de dados voláteis tenham
sido realizadas como: a decisão de remover o cabo de rede ou
não do servidor que sofreu a intrusão, se houve alguma interven-
ção por parte de outro profissional após a identificação do pro-
blema e se este realizou alguma atividade e quais, que a cópia
dos dados da memória tenham sido realizadas em local seguro
e fora da máquina periciada, que uma imagem bit a bit do disco
tenha sido efetuada.

O chkrootkit é um detector de presença de  de rootkits em rootkits na máquina e atualmente é capaz de identificas mais de
sistemas baseados em Unix. O software  utiliza cerca de nove ti- 60 tipos de ameaças diferentes como rootkits, worms, trojans,
pos de análise para detectar traços de atividade ou presença de dentre outros.

PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/2012 - EDIÇÃO 5 - ISSN 2176 7785 l 177
 Iniciando o chkrootkit o sistema informa os parâmetros que Neste ponto fazemos uma varredura em busca de Malwares
podem ser utilizados na detecção de Malwares. alojados na máquina.

Executando o chkrootkit ele checa o sistema em busca de Com esta atividade conseguimos identificar a presença ou
Malwares e já exibe o resultado na tela informando se o arquivo não do Malware no sistema operacional.
está ou não infectado.

178 | PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/2012 - EDIÇÃO 5 - ISSN 2176 7785
 O rkhunter é outra ferramenta de grande importância na detecção de rootkits no sistema, este avisa caso haja arquivos sus-
peitos no sistema.

Um dos parâmetros do rkhunter é o “--update”, que atualiza sua base de dados de Malwares.
Sua execução se da através do comando “rkhunter --check”.

Os arquivos que contiverem a cor verde – not found e ok – estão normais. Já aqueles que forem marcados como
“Warning” estão comprometidos e serão exibidos na cor vermelha, sendo assim deve-se proceder a remoção do rootkit.
Antes de executar a remoção o Malware deve ser isolado em um dispositivo de armazenamento que seja externo ao disco da
máquina comprometida, onde não possa mais gerar danos e possibilite uma análise posterior, talvez até mesmo sua execução em
ambiente fechado e preparado para tal.

PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/2012 - EDIÇÃO 5 - ISSN 2176 7785 l 179
 O Malware deve ser removido do sistema operacional e a vulnerabilidade que permitiu sua inserção deve ser tratada, para que
esta falha não seja explorada novamente por um atacante.

O relatório final da execução e da análise do Malware fica
registrada em /var/log/rkhunter.log.
O Malware encontrado é um Backdoor que permite um
acesso do atacante à máquina comprometida de forma rápida
sem a necessidade de realizar todos os passos para sua intru-
são, este código mantém uma porta de comunicação aberta en-
tre o atacante e a máquina comprometida.
Abaixo um trecho do código da Backdoor utilizada para o
acesso do atacante à máquina através de uma falha de segu-
rança do PHP:
<?php
.passthru(“date”);
.echo “Iniciando via NETCAT da Backdoor”;
.passthru (“nc –l –p 65321 –e /Bin/sh”);
.echo “Backdoor Instalada!!!>;-)”;
.echo “Passaporte para sistema disponível!!! >;-)”;
?>
7 CONCLUSÃO
A perícia forense computacional é um instrumento im-
prescindível para identificar se um sistema computacional foi
invadido, e de que forma foi alterado, estabelecendo critérios
para preparar o ambiente visando registrar os dados periciais,
facilitar a identificação do invasor e amparar as medidas legais

180 | PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/2012 - EDIÇÃO 5 - ISSN 2176 7785
a serem tomadas diante da intrusão.
O valor jurídico de provas eletrônicas manipuladas de forma
incorreta, sem os padrões previstos e devidamente estabeleci-
dos pode ser facilmente contestado, e toda atividade do perito
deve ser acompanhada por um ou mais profissionais da TIC da
empresa que o contratou para a perícia, isso para assegurar a
integridade não só da coleta dos dados, mas também para res-
guardar o perito, evitando assim que de perito torne-se réu.
Enfim, a utilização de ferramentas que auxiliam e dão supor-
te à investigação é de suma importância, pois estas conseguem
garimpar informações de forma eficaz e ágil, primando pela in-
tegridade e minimizando os riscos da perda de dados voláteis.
A partir deste trabalho discutimos e demonstramos as técni-
cas e procedimentos da perícia forense computacional que au-
xiliam na análise de sistemas computacionais comprometidos,
apontando as melhores práticas na atualidade e metodologias
a serem aplicadas na descoberta, coleta e análise de Malwares.

REFERÊNCIAS BIBLIOGRÁFICAS
FARMER, Dan; VENEMA, Wietse. Perícia Forense Computacional: Te-
oria e prática aplicada. São Paulo: Pearson Prentice Hall, 2007.

MELO, Sandro. Computação Forense com Software Livre: Concei-

tos, técnicas, ferramentas e estudos de casos. 1. ed. Rio de Janeiro: Alta
Books. 2009.

TANENBAUM, Andrew S. Redes de Computadores. 4. ed. Campus

(Elsevier), 2003.

HATCH, Brian; B. LEE, James; KURTZ, George. Segurança contra Ha-

ckers Linux. 2. ed. São Paulo: Futura, 2003.

FILHO, João Eriberto Mota. Forense computacional utilizando fer-

ramentas GNU/Linux. Brasília: Serpro, 10 de Novembro de 2009. Pa-
lestra ministrada no CISL – Comitê Técnico de Implantação de Software
livre, 10/11/2011. Forense computacional utilizando ferramentas GNU/
LINUX. Disponível em: http://streaming.serpro.gov.br/cisl/forense.html.

NOTAS DE RODAPÉ
1 Coordenador e Professor do Curso de Bacharelado em Sistemas de
Informação do Centro Universitário Newton Paiva

2 Graduando em Bacharelado em Sistemas de Informação do Centro

Universitário Newton Paiva

PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/2012 - EDIÇÃO 5 - ISSN 2176 7785 l 181