universidade de brasília faculdade de tecnologia departamento de

UNIVERSIDADE DE BRASÍLIA
FACULDADE DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
FORENSE DE MEMÓRIA: EXTRAÇÃO E ANÁLISE DE
DADOS ARMAZENADOS EM MEMÓRIA VOLÁTIL
ANA PAULA TEIXEIRA ROSA
ORIENTADOR: LAERTE PEOTTA DE MELO
MONOGRAFIA DE ESPECIALIZAÇÃO EM ENGENHARIA
ELÉTRICA
BRASÍLIA / DF: JUNHO/2011
ii
UNIVERSIDADE DE BRASÍLIA
FACULDADE DE TECNOLOGIA
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
FORENSE DE MEMÓRIA: EXTRAÇÃO E ANÁLISE DE
DADOS ARMAZENADOS EM MEMÓRIA VOLÁTIL
ANA PAULA TEIXEIRA ROSA
MONOGRAFIA DE ESPECIALIZAÇÃO SUBMETIDA AO DEPARTAMENTO DE
ENGENHARIA ELÉTRICA DA FACULDADE DE TECNOLOGIA DA UNIVERSIDADE DE
BRASÍLIA, COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU
DE ESPECIALISTA.
APROVADA POR:
LAERTE PEOTTA DE MELO, MSc, UnB
(ORIENTADOR)
EDNA DIAS CANEDO, MSc, UnB
(EXAMINADOR INTERNO)
DINO MACEDO AMARAL, MSc, UnB
(EXAMINADOR EXTERNO)
DATA: BRASÍLIA/DF, 07 DE JUNHO DE 2011.
iii
iv
FICHA CATALOGRÁFICA
ROSA, ANA PAULA TEIXEIRA
Forense de Memória: Extração e Análise de Dados Armazenados em Memória Volátil [Distrito
Federal] 2011.
99p., 297 mm (ENE/FT/UnB, Especialista, Engenharia Elétrica, 2011).
Monografia de Especialização – Universidade de Brasília, Faculdade de Tecnologia. Departamento de
Engenharia Elétrica.
1. Segurança da Informação 2. Forense Computacional
3. Forense de Memória
I. ENE/FT/UnB. II. Forense de Memória: Extração e Análise de Dados Armazenados em Memória
Volátil
REFERÊNCIA BIBLIOGRÁFICA
ROSA, ANA PAULA TEIXEIRA (2011). Forense de Memória: Extração e Análise de Dados
Armazenados em Memória Volátil. Monografia de Especialização, Publicação Junho/2011,
Departamento de Engenharia Elétrica, Universidade de Brasília, Brasília, DF, 99p.
CESSÃO DE DIREITOS
NOME DO AUTOR: Ana Paula Teixeira Rosa
TÍTULO DA MONOGRAFIA: Forense de Memória: Extração e Análise de Dados Armazenados em
Memória Volátil.
GRAU/ANO: Especialista/2011.
É concedida à Universidade de Brasília permissão para reproduzir cópias desta Monografia de
Especialização e para emprestar ou vender tais cópias somente para propósitos acadêmicos e
científicos. Do mesmo modo, a Universidade de Brasília tem permissão para divulgar este documento
em biblioteca virtual, em formato que permita o acesso via redes de comunicação e a reprodução de
cópias, desde que protegida a integridade do conteúdo dessas cópias e proibido o acesso a partes
isoladas desse conteúdo. O autor reserva outros direitos de publicação e nenhuma parte deste
documento pode ser reproduzida sem a autorização por escrito do autor.
Ana Paula Teixeira Rosa
QSA 18 Casa 05
CEP 72015180 – Brasília – DF - Brasil
v
vi
Dedico a realização desse trabalho aos meus pais, que
sempre incentivaram meu desenvolvimento e a busca
pelo conhecimento, dedicando esforços para me oferecer
uma boa educação e possibilitar a realização dos meus
sonhos.
vii
viii
AGRADECIMENTOS
Primeiramente a Deus, pela oportunidade da vida, com suas inúmeras alegrias e
possibilidades de aprendizado.
Aos meus pais, Paulo e Sandra, e ao meu irmão, Matheus, pelo apoio e amor incondicional.
Ao meu orientador Prof. Msc. Laerte Peotta de Melo, pela colaboração, apoio e incentivo no
desenvolvimento deste trabalho.
A todos os colegas e amigos, meus sinceros agradecimentos.
ix
x
RESUMO
Tradicionalmente, a perícia forense computacional trabalha com a coleta e
análise de dados estáticos, armazenados em discos rígidos, buscando adquirir
evidências relacionadas à ocorrência de atividades maliciosas em sistemas
computacionais após a sua ocorrência. Com a evolução dos recursos
tecnológicos e a popularização do uso da Internet, tem se tornado inviável
manter apenas a abordagem tradicional, devido ao grande volume de
informações a serem analisadas e ao crescimento do número de casos de crimes
cibernéticos. Nesse contexto, a análise de dados armazenados em memória
volátil surge como nova abordagem, ao permitir a recuperação de dados
importantes à perícia forense computacional. Este estudo visa apresentar tal
abordagem, incluindo o tipo de informações que podem ser recuperadas, assim
como técnicas e procedimentos para extração e análise desses dados em sistemas
operacionais Windows, fazendo considerações sobre as vantagens e
desvantagens verificadas.
Palavras-chave: segurança da informação, forense computacional, forense de
memória
xi
xii
ABSTRACT
Computer forensics traditionally works with the collection and analysis of static
data stored on hard drives, seeking to acquire evidence related to the occurrence
of malicious activity on the computer systems after their occurrence. With the
evolution of technological resources and the popularization of Internet use it has
become impracticable to keep only the traditional approach due to the large
volume of information to be analyzed and the growing number of cases of
cybercrimes. In this context, analysis of data stored in volatile memory comes as
a new approach, to allow recovery of important data for forensic computing.
This study aims to present such an approach, including the type of information
that can be recovered as well as techniques and procedures for extraction and
analysis of these data in Windows operating systems, with a consideration of the
advantages and disadvantages identified.
Keywords: information security, computer forensics, memory forensics
xiii
xiv
SUMÁRIO
1. INTRODUÇÃO .................................................................................................................... 1
1.1. OBJETIVOS ................................................................................................................. 3
1.2. ORGANIZAÇÃO........................................................................................................... 4
2. REVISÃO BIBLIOGRÁFICA ............................................................................................ 5
2.1. EVIDÊNCIAS DIGITAIS ............................................................................................... 9
2.2. DESAFIOS DA FORENSE COMPUTACIONAL ............................................................. 11
2.3. PROCEDIMENTOS ..................................................................................................... 13
2.3.1. Identificando as Evidências............................................................................. 15
2.3.2. Preservando as Evidências .............................................................................. 17
2.3.3. Analisando as Evidências ................................................................................ 18
2.3.4. Apresentação dos Resultados.......................................................................... 20
3. PERÍCIA FORENSE COMPUTACIONAL: ANALISANDO A MEMÓRIA
VOLÁTIL ............................................................................................................................... 21
3.1. A MEMÓRIA VOLÁTIL ............................................................................................. 22
3.2. DADOS ENCONTRADOS NA MEMÓRIA VOLÁTIL ..................................................... 24
3.2.1. Processos ........................................................................................................... 24
3.2.2. Arquivos abertos e Conteúdo do Registro do Windows (Registry) ............. 24
3.2.3. Informações de rede......................................................................................... 25
3.2.4. Senhas e Chaves Criptográficas ..................................................................... 25
xv
3.2.5. Conteúdo decifrado ......................................................................................... 26
3.2.6. Dados Ocultos................................................................................................... 26
3.2.7. Códigos Maliciosos........................................................................................... 26
3.3. TÉCNICAS PARA ANÁLISE FORENSE DA MEMÓRIA ................................................ 27
3.3.1. Recuperação de Arquivos Mapeados em Memória ...................................... 27
3.3.2. Recuperação de Arquivos Através de Assinatura ........................................ 29
3.3.3. Detecção e Recuperação de Dados Escondidos ............................................. 30
3.4. EXTRAÇÃO DE DADOS DA MEMÓRIA VOLÁTIL ...................................................... 31
3.4.1. Hardware .......................................................................................................... 31
3.4.2. Crash Dumps .................................................................................................... 32
3.4.3. Dumps ............................................................................................................... 33
3.4.4. Virtualização .................................................................................................... 34
3.4.5. Hibernação ....................................................................................................... 34
3.5. FERRAMENTAS PARA AQUISIÇÃO DE CONTEÚDO DA MEMÓRIA RAM ................. 35
3.5.1. DD...................................................................................................................... 35
3.5.2. Mandiant Memoryze ....................................................................................... 35
3.5.3. ManTech Memory DD..................................................................................... 36
3.5.4. FastDump ......................................................................................................... 36
3.5.5. KntDD ............................................................................................................... 36
3.5.6. MoonSols Windows Memory Toolkit ............................................................ 37
xvi
3.5.7. Nigilant32.......................................................................................................... 37
3.5.8. FTK Imager ...................................................................................................... 37
3.5.9. Winen.exe.......................................................................................................... 38
3.6. FERRAMENTAS PARA ANÁLISE FORENSE DA MEMÓRIA ........................................ 38
3.6.1. Ferramentas básicas ........................................................................................ 40
3.6.2. Volatility Framework ...................................................................................... 40
3.6.3. Mandiant Memoryze ....................................................................................... 45
3.6.4. Windows Memory Forensic Toolkit............................................................... 48
4. ESTUDO DE CASO ........................................................................................................... 51
4.1. CENÁRIO .................................................................................................................. 51
4.2. REALIZAÇÃO DOS TESTES ....................................................................................... 52
5. CONCLUSÕES .................................................................................................................. 59
6. BIBLIOGRAFIA ................................................................................................................ 63
7. ANEXO I ............................................................................................................................. 67
8. ANEXO II ........................................................................................................................... 72
xvii
xviii
ÍNDICE DE TABELAS
TABELA 3.1 – O CICLO DE VIDA ESPERADO DOS DADOS. ............................................................ 10
xix
xx
ÍNDICE DE FIGURAS
FIGURA 2.1 – DINÂMICA DE UM INCIDENTE DE SEGURANÇA DIGITAL .......................................... 7
FIGURA 2.2 – PROCEDIMENTOS DA PERÍCIA FORENSE COMPUTACIONAL.................................... 14
FIGURA 2.3 – FLUXOGRAMA DA FASE DE ANÁLISE DAS EVIDÊNCIAS ......................................... 19
FIGURA 3.1 - REPRESENTAÇÃO VISUAL DA ÁRVORE DE DESCRITORES: VAD TREE. .................... 29
FIGURA 3.2 – TELA DO VISUALIZADOR AUDIT VIEWER – ABA FILES: ANÁLISE FORENSE DA
MEMÓRIA EFETUADA COM O SOFTWARE MEMORYZE. ......................................................... 47
FIGURA 3.3– TELA DO VISUALIZADOR AUDIT VIEWER – ABA REGISTRY KEYS: ANÁLISE FORENSE
DA MEMÓRIA EFETUADA COM O SOFTWARE MEMORYZE.
.................................................... 48
FIGURA 4.1 – DOWNLOAD DO BANKER ....................................................................................... 52
FIGURA 4.2 – MENSAGEM DE ERRO AO EXECUTAR O BANKER .................................................... 53
xxi
xxii
ÍNDICE DE QUADROS
QUADRO 3.1 - USO DO COMANDO VOLATILITY ............................................................................ 42
QUADRO 3.2 – USO DO COMANDO IDENT DA FERRAMENTA VOLATILITY ..................................... 42
QUADRO 3.3 - UTILIZANDO A OPÇÃO HELP DA FERRAMENTA VOLATILITY .................................. 42
QUADRO 3.4– USO DO COMANDO PSLIST DA FERRAMENTA VOLATILITY ..................................... 43
QUADRO 3.5 – USO DO COMANDO FILES DA FERRAMENTA VOLATILITY ...................................... 43
QUADRO 3.6 – USO DO COMANDO DLLLIST DA FERRAMENTA VOLATILITY .................................. 44
QUADRO 3.7 – USO DO COMANDO REGOBJKEYS DA FERRAMENTA VOLATILITY .......................... 44
QUADRO 3.8 – USO DO COMANDO PROCDUMP DA FERRAMENTA VOLATILITY ............................. 44
QUADRO 4.1 – AQUISIÇÃO DO DUMP DE MEMÓRIA UTILIZANDO A FERRAMENTA WIN32DD....... 54
QUADRO 4.2 – PROCESSOS CRIADOS PELO BANKER .................................................................... 54
QUADRO 4.3 – ARQUIVOS CRIADOS/ACESSADOS PELO PROCESSO “AVGUIX.EXE” ....................... 55
QUADRO 4.4 – BIBLIOTECAS UTILIZADAS/CARREGADAS PELO PROCESSO “AVGUIX.EXE” ........... 56
QUADRO 4.5 – CHAVES DE REGISTRO EM USO PELO PROCESSO “AVGUIX.EXE” ........................... 56
QUADRO 4.6 – EXTRAÇÃO DO CÓDIGO EXECUTÁVEL DO PROCESSO “AVGUIX.EXE” .................... 56
xxiii
xxiv
TABELA DE SIGLAS
AES – Advanced Encryption Standard
API – Application programming interface
ASCII – American Standard Code for Information Interchange
BIOS – Basic Input-Output System
CPU – Central Processing Unit
DKOM – Direct Kernel Object Manipulation
DLL – Dynamic-link Library
DMA – Direct Memory Access
GPL – General Public License
IBGE – Instituto Brasileiro de Geografia e Estatística
IDS – Intrusion Detection System
IP – Internet Protocol
MD5 – Message-Digest Algorithm 5
PC – Personal Computer
PCI – Peripheral Component Interconnect
PDA – Personal Digital Assistant
PEB – Process Environment Block
RAM – Random-Access Memory
RFC – Request for Comments
URL – Uniform Resource Locator
XML – Extensible Markup Language
xxv
xxvi
1.
INTRODUÇÃO
Com a popularização da Internet e crescente uso de dispositivos eletrônicos pessoais,
tem se tornado cada dia mais comum o consumo de produtos e serviços através do meio
virtual. Atividades que antes só poderiam ser realizadas presencialmente, agora são
freqüentemente concretizadas através da Internet, por meio digital, como o comércio
eletrônico, o ensino a distância e até mesmo a realização de operações financeiras e bancárias
por meio do Internet Banking.
No entanto, ao mesmo tempo em que oferece facilidades e conveniências, a crescente
utilização destas tecnologias também trouxe um novo palco para a ocorrência de atividades
ilícitas, praticadas através de meios digitais.
De acordo com os dados divulgados pelo IBGE em setembro de 2010, por meio da
PNAD 2009 - Pesquisa Nacional por Amostra de Domicílios, do ano de 2005 ao ano de 2009,
o número de domicílios com acesso à Internet aumentou em 71%, comprovando que o
número de brasileiros com acesso à Internet cresceu significativamente no país.
Paralelamente, cresceu também no Brasil a quantidade de crimes praticados através de
meios digitais. Conforme divulgado no relatório Global Fraud Report (KROLL, 2010) pela
Kroll, empresa de consultoria norte americana especializada em gestão de riscos, o roubo de
informações eletrônicas e fraudes no país possui números alarmantes, mais expressivos que a
média da pesquisa para todas as outras regiões do globo. Ainda de acordo com a pesquisa,
pela primeira vez, o roubo de informações e dados eletrônicos teve incidência maior que o
roubo físico nas empresas brasileiras. E segundo relatório publicado pela Symantec,
fabricante de softwares de segurança, 76% dos brasileiros usuários de Internet já foram
vítimas do cibercrime, um número acima da média global, que é de 65%.
Desse modo, além dos benefícios e comodidade oferecidos à sociedade com a Internet,
vieram também os inconvenientes, resultantes de atividades ilícitas cometidas através dos
meios eletrônicos por pessoas mal intencionadas, ou seja, os crimes cibernéticos. Contando
com a impunidade, com a ilusão do anonimato, e aproveitando-se das brechas abertas pelos
usuários leigos e descuidados, que não se preocupam com a segurança de seus dispositivos
eletrônicos, muitos infratores praticam condutas criminosas contra pessoas ou sistemas
computacionais utilizando a rede. Como exemplo, o roubo de dados e informações privadas,
1
estelionato ou o comprometimento de um sistema de comércio online de uma empresa,
afetando sua disponibilidade. No entanto, pressupor que na Internet vigora o anonimato é um
engano, já que a rastreabilidade das ações efetuadas neste meio é possível. Então, havendo a
possibilidade de se responsabilizar os usuários, estes podem vir a responder civil e
administrativamente, desde que se comprovem os danos causados e a autoria.
Diariamente são descobertas novas vulnerabilidades e novos métodos de ataque a
sistemas computacionais são desenvolvidos, bastando que se tenha um mínimo conhecimento
de informática e redes de computadores para que uma pessoa interessada obtenha facilmente
ferramentas de invasão na Internet, possibilitando-lhe causar danos a pessoas e organizações.
Nesse contexto, a Forense Computacional busca a aquisição e compreensão de
evidências sobre a ocorrência dos referidos crimes em ambientes computacionais, a fim de
provar sua existência. Com os resultados de uma análise forense, é possível fornecer
informações a processos criminais, para aplicação das medidas legais cabíveis, ou mesmo
determinar a causa de incidentes de segurança em empresas, subsidiando a adoção de medidas
corretivas e/ou preventivas nos sistemas e processos utilizados.
No entanto, com o constante aumento da capacidade de dispositivos de
armazenamento, tem se tornado muitas vezes inviável analisar todo o conteúdo disponível
para a perícia. Atualmente é comum lidar com discos rígidos cuja capacidade de
armazenamento pode ser medida em terabytes, o que influencia consideravelmente no tempo,
dificuldade e custo requeridos para a coleta e análise de todas as evidências presentes no
disco. Além disso, muitos sistemas, como os de comércio eletrônico, não admitem períodos
de indisponibilidade enquanto os dados do disco estão sendo copiados. Por fim, muitos dados
valiosos sobre o que estava acontecendo no sistema, que poderiam fornecer informações
importantes e contextualizar as evidências encontradas em disco, podem ser perdidas quando
a máquina é desligada.
Nesse sentido, a Live Forensics, ou “Forense ao Vivo”, busca trabalhar com um
snapshot, ou seja, uma imagem do estado do sistema, tentando obter uma imagem do
ambiente no momento em que ocorreu o incidente. E a memória volátil, que constitui-se como
um dos alvos de análise da Live Forensics, pode prover informações importantes, que em
conjunto com a abordagem tradicional da forense resulta em uma análise mais completa do
cenário em que ocorreu o incidente.
2
Diante desse cenário, em que ações fraudulentas ou criminosas em sistemas
computacionais se tornam cada vez mais freqüentes, a importância da perícia forense
computacional se torna cada vez maior para elucidar a ocorrência de tais ações ilícitas.
1.1. OBJETIVOS
O escopo desse trabalho concentra-se na apresentação dos conceitos, procedimentos e
técnicas empregadas na perícia forense computacional, destacando a importância da análise
de dados voláteis, obtidos a partir da memória RAM, para uma investigação forense. Para
isso, serão descritos quais os tipos de dados que podem ser recuperados da memória volátil
em sistemas que foram invadidos, a volatilidade das evidências disponíveis, assim como as
técnicas e ferramentas que podem ser utilizadas para realizar a captura e análise de dados da
memória RAM.
Serão apresentadas ferramentas e frameworks existentes para análise forense da
memória principal de um sistema, que podem ser utilizadas visando à recuperação de dados e
evidências relevantes à análise e compreensão do evento. Por fim, pretende-se demonstrar,
através de um estudo de caso, a eficácia de ferramentas de forense de memória para a
elucidação de incidentes digitais de segurança.
Os objetivos específicos desse trabalho são:
• Dissertar sobre a fundamentação teórica da Perícia Forense Computacional;
• Descrever quais dados pode ser recuperados através da captura e análise da memória
volátil;
• Descrever técnicas e procedimentos para recuperação de dados através da forense de
memória;
• Analisar ferramentas e frameworks disponíveis para a perícia da memória volátil.
• Apresentar um estudo de caso demonstrando a importância da análise de dados
voláteis para a perícia forense computacional.
3
1.2. ORGANIZAÇÃO
Esse trabalho foi dividido em cinco capítulos. O presente capítulo faz uma pequena
introdução ao tema proposto, apresenta os objetivos do trabalho, a motivação para seu
desenvolvimento e expõe como ele será estruturado.
No capítulo 2 – “Revisão Bibliográfica”, é realizada uma revisão teórica, introduzindo
conceitos relacionados a crimes cibernéticos, sua definição e cenário encontrado no Brasil
atualmente. Também são abordados procedimentos e metodologias aplicáveis à perícia
forense computacional e discutida a confiabilidade das informações encontradas em um
sistema sob investigação.
O capítulo 3 – “Perícia Forense Computacional: Analisando a Memória Volátil”,
aborda a aplicação da perícia forense computacional para análise de conteúdo obtido a partir
da memória volátil, enumerando que tipo de informação pode ser encontrada na memória
RAM e o quão persistente esses dados podem ser. Discorre sobre o gerenciamento de
memória, técnicas, procedimentos e ferramentas para realização de análise forense da
memória.
O capítulo 4 – “Estudo de Caso” exemplifica a utilização de ferramentas apropriadas
para forense de memória através de um estudo de caso, a fim de demonstrar a importância da
investigação do conteúdo da memória para a perícia forense computacional.
Por fim, o capítulo 5 – “Conclusão”, realiza considerações sobre o estudo realizado e
propõe a realização de novos trabalhos na área.
4
2.
REVISÃO BIBLIOGRÁFICA
No Brasil ainda não há legislação específica para combater os crimes cibernéticos,
também denominados de crimes digitais, crimes tecnológicos, crimes na Internet, cibercrimes,
dentre outras nomenclaturas. O artigo 5º da Constituição Federal de 1988, inciso XXXIX,
estipula que “não há crime sem lei anterior que o defina, nem pena sem prévia cominação
legal” (BRASIL, 1988). Então, como ainda não existe tipificação para os crimes cibernéticos,
a punição se torna difícil.
Existe, em andamento, um projeto de lei sobre crimes cibernéticos amplamente conhecido
e discutido, proposto pelo Senador Eduardo Azeredo em substituição ao Projeto de Lei da
Câmara nº 89, de 2003, e Projetos de Lei do Senado nº 137 e nº 76, de 2000, todos referentes
a crimes na área de informática. Porém, enquanto ainda não existe definição e tipificação para
delitos informáticos, cometidos com a utilização de meios de tecnologia e telecomunicações,
a impunidade prevalece.
Em decorrência de suas particularidades e natureza jurídica, a definição para crimes
cibernéticos é complexa. Castro (CASTRO, 2003) prefere chamá-los de crimes de
informática, a fim de englobar todos os crimes que possuem relação com os sistemas de
informática e não apenas os que tenham relação com a Internet.
Crime de Informática é aquele praticado contra o sistema de informática ou
através deste, compreendendo os crimes praticados contra o computador e
seus acessórios e os perpetrados através do computador. Inclui-se neste
conceito os delitos praticados através da Internet, pois pressuposto para
acessar a rede é a utilização de um computador. (CASTRO, 2003).
Admite-se essa definição com a ressalva de que para acessar a rede não é necessária a
utilização de um computador, já que atualmente inúmeros dispositivos permitem o acesso à
Internet, como celulares, smartphones, vídeo games, tablets, etc. Assim, outra definição
citada por Castro, mas proposta por João Marcello de Araujo Junior e que é mais abrangente
“[...] conceitua como sendo uma conduta lesiva, dolosa, a qual não precisa, necessariamente,
corresponder à obtenção de uma vantagem ilícita, porém praticada, sempre, com a utilização
de dispositivos habitualmente empregados nas atividades de informática.” (CASTRO, 2003).
Quanto à classificação, a mesma autora destaca que podem ser classificados como
próprios e impróprios. Os crimes próprios só podem ser consumados com a utilização da
5
informática, enquanto os impróprios podem ser práticos com ou sem o auxílio da informática,
por se tratarem de condutas já tipificadas e protegidas pela legislação brasileira.
Existem outras classificações bem aceitas para auxiliar o entendimento de crimes que
envolvem computadores. (HUEBNER, BEM, BEM, 2007) propõem a seguinte classificação
em três categorias:
• Crimes centrados em computadores: atividade criminosa que tem como alvo sistemas
computacionais,
redes,
mídias
de
armazenamento
ou
outros
dispositivos
computacionais. Por exemplo, invadir um site comercial e alterar seu conteúdo.
Podem ser vistos como novos métodos, promovendo uma nova classe de crimes.
• Crimes assistidos por computadores: utilização de sistemas computacionais como
ferramentas, para auxiliar em uma atividade criminosa em que o uso de computadores
não é estritamente necessário, por exemplo, a pornografia infantil. Podem ser vistos
como novas formas de se cometer crimes convencionais.
• Crimes computacionais incidentais: atividade criminosa em que o uso do sistema
computacional é incidental, não estando relacionado diretamente à atividade criminosa
propriamente dita. Por exemplo, uso do computador para contabilizar e manter
registros de tráfico de drogas. Podem ser vistos como a utilização de novas
ferramentas em substituição às convencionais. No exemplo anterior, um livro de
registros de contabilidade estaria sendo substituído por um software, como um editor
de planilhas.
Nesse trabalho também será utilizado o termo “incidente de segurança”, que segundo
(MANDIA, PROSISE, 2003) pode ser definido como “qualquer ação fora da lei,
desautorizada ou inaceitável que envolva um sistema computacional ou uma rede de
computadores”. Ainda, de acordo com o autor, essa ação pode incluir qualquer dos eventos a
seguir: roubo de segredos comerciais, correio eletrônico contendo spam ou assédio, intrusões
ilegais ou não autorizadas em sistemas computacionais, desfalque, posse ou divulgação de
pornografia infantil, ataques de negação de serviço (DoS), extorsão, dentre outras ações cuja
evidência esteja armazenada em mídias digitais, como fraudes, roubos e outros crimes
tradicionais.
Em outras palavras, a RFC 4949, define um incidente de segurança como “[...] um evento
de sistema de segurança em que a política de segurança do sistema é desobedecida ou
violada.” (SHIREY, 2007), exaltando a importância da implantação de políticas para gerir a
segurança de informação.
6
A Figura 2.1 ilustra a dinâmica de um incidente digital, apresentando o relacionamento
entre os eventos para casos de ataques e incidentes. Para prevenir ataques deve-se impedir que
o invasor consiga realizar completamente a conexão através das sete etapas descritas.
Figura 2.1 – Dinâmica de um incidente de segurança digital
(HOWARD, 1998).
Grande parte destes eventos, que causam impactos significantes às pessoas e
organizações, viola de alguma forma as leis e podem ser investigados como crime nas esferas
7
civil e criminal. O combate ao crime cibernético é um problema global, pois não existem
fronteiras no espaço cibernético; os criminosos estão distribuídos por todos os lugares e a
cooperação internacional é imprescindível para combatê-lo. Muitos esforços nesse sentido já
podem ser vislumbrados, no entanto ainda há um longo caminho a percorrer.
Assim, a perícia forense computacional, também conhecida como computação forense,
informática forense ou forense digital, dentre outros termos, tem ganhado importância cada
vez maior para as autoridades policiais e judiciárias, assim como para empresas e
organizações, à medida que utiliza conhecimentos em informática aliados a técnicas de
investigação a fim de obter evidências sobre a ocorrência de incidentes de segurança em
sistemas computacionais. A forense computacional propõe métodos científicos para
identificar, coletar, preservar, analisar e documentar evidências digitais em dispositivos
eletrônicos (FREITAS, 2006). Tem como objetivo primário determinar a dinâmica,
materialidade e autoria de ilícitos ligados à área de informática, tendo como questão principal
a identificação e o processamento de evidências digitais em provas materiais de crime, por
meio de métodos técnico-científicos, conferindo-lhe validade probatória em juízo
(ELEUTÉRIO, MACHADO, 2011).
Outra definição, mais completa, e proposta por (PALMER, 2001) conceitua a Ciência
Forense Computacional como “a utilização de métodos derivados e comprovados
cientificamente para a preservação, coleta, validação, identificação, análise, interpretação,
documentação e apresentação de evidências digitais provenientes de fontes digitais a fim de
facilitar ou promover a reconstrução de eventos considerados criminosos, ou auxiliar a
previsão de ações não autorizadas que demonstrarem ser prejudiciais às operações
planejadas”.
Através do processo de análise forense, um analista tem a intenção de reconstituir os
eventos passados para descobrir quem invadiu o sistema, quando o incidente ocorreu, como o
invasor obteve o acesso e conseguiu concretizar a invasão, a quais sistemas teve acesso e o
que fez enquanto teve domínio do ambiente. Vale ressaltar, porém, que tão importante quanto
se encontrar os responsáveis e buscar uma punição ou compensação litigiosa, é o aprendizado
resultante da análise do problema, que deve ser considerado como meta dos trabalhos forenses
aplicados à área de Segurança da Informação (ROSA, 2004).
Ainda, (FARMER, VENEMA, 2007) definem a forense computacional como o
processo de “coleta e análise de dados de maneira tão livre de distorção ou viés que seja
possível reconstruir os dados ou o que aconteceu no passado no sistema”. Sugerem que, para
8
cumprir os métodos investigativos tradicionais, o investigador deve seguir uma série de
estágios quando está diante da cena de um incidente (FARMER, VENEMA, 1999):
• Proteger e isolar.
• Registrar o incidente.
• Conduzir uma busca sistemática por evidências.
• Coletar e manter as evidências.
• Manter cadeia de custódia.
2.1. EVIDÊNCIAS DIGITAIS
Edmond Locard foi um pioneiro na área de ciência Forense e formulou um princípio
que é bastante difundido e amplamente adotado pela ciência forense, conhecido como
Princípio da Troca de Locard. Este princípio afirma que sempre que dois itens entrarem em
contato haverá uma troca de material, o que pode ser traduzido pela conhecida expressão
“todo contato deixa um rastro”. Fazendo uma analogia ao ambiente envolvido em um
incidente de segurança, sempre haverá evidências na cena do crime; inclusive as deixadas
pelos investigadores durante a realização de seus trabalhos. Por isso mesmo, é importante que
os investigadores documentem rigorosamente todos os procedimentos adotados, assim como
seus resultados previstos, para que os efeitos indesejáveis sejam reduzidos ao mínimo
possível e sempre com resultados previsíveis (RODRIGUES, 2007).
Entende-se como evidência digital “qualquer informação de valor probatório que é
armazenada ou transmitida em formato digital” (HUEBNER, BEM, BEM, 2007). Exemplos
de evidências digitais que podem ser encontradas no local em que ocorreu o incidente ou
crime cibernético são: vestígios de arquivos apagados, fragmentos de arquivos, arquivos
ocultos ou criptografados, registros de impressão e conexão à Internet, etc.
A análise forense de um sistema computacional envolve um ciclo de coleta de dados e
processamento das informações coletadas. O ideal para o trabalho do perito em forense
computacional seria obter uma cópia exata do sistema, pois quanto mais precisos e completos
os dados forem, mais abrangente poderá ser a avaliação. A dificuldade está na obtenção de
uma cópia fiel do sistema em questão, pois enquanto a coleta de dados é realizada em um
sistema, novas atividades podem estar coexistindo, como programas ou processos de sistema
9
que estejam rodando e causando alterações no mesmo, destruindo vestígios valiosos. O
simples fato de se executar uma ferramenta para captura dos dados no sistema afetará o seu
estado, tornando-o diferente do momento em que o incidente de segurança ocorreu. Além
disso, os invasores podem deixar armadilhas para destruir os dados (FARMER, VENEMA,
2007).
Para evitar essas alterações, a forense computacional tradicional se concentra em
analisar os dados nos sistemas fora de execução; quando um incidente de segurança é
detectado, o sistema é desligado e os dados que podem fornecer informações úteis são
copiados (logs de aplicativos, MAC Times, assim como o conteúdo de arquivos e o que mais
for considerado importante pelo investigador). Em seguida, a análise é feita com base na
cópia dos dados, garantindo que o cenário original sofra o mínimo de alterações possível. No
entanto, ao se desligar ou interromper a energia de um sistema, muitas informações úteis que
poderiam auxiliar na investigação podem ser perdidas, como o que fica armazenado na
memória RAM ou em periféricos, cuja natureza é efêmera.
Um ramo da área de Forense Computacional, a Live Forensics propõe a coleta de
evidências no sistema “em funcionamento”. Desse modo, é possível ter à disposição mais
fontes para coletar as evidências; quando correlacionadas, estas fontes podem auxiliar na
resolução do problema, principalmente se os dados puderem ser obtidos durante a ocorrência
do incidente. As informações devem ser preferencialmente coletadas de acordo com sua
ordem de volatilidade no sistema; alguns dados possuem maior chance de se perderem,
devido à natureza dos dispositivos que os armazenam e à sua sensibilidade a corrupção
durante uma coleta de dados. Assim, deve ser considerado o ciclo de vida dos dados ao se
realizar uma coleta, para evitar grandes perdas. A tabela 3.1 ilustra o ciclo de vida esperado
dos dados, segundo (FARMER, VENEMA, 2007) e pode ser utilizada como um guia para a
ordem de volatilidade dos diferentes dispositivos de armazenamento.
Tabela 2.1 – O ciclo de vida esperado dos dados.
Tipos de Dados
Registradores, memória periférica, caches, etc.
Memória principal
Estado da rede
Processos em execução
Disco
Disquetes, mídias de backup, etc.
CD-ROMs, impressões, etc.
Tempo de Vida
Nanossegundos
Dez nanossegundos
Milissegundos
Segundos
Minutos
Anos
Dezenas de anos
10
Uma vez que o sistema foi comprometido, pode haver dúvidas quanto à confiabilidade
das informações obtidas. Como ter a certeza de que o investigador está diante de vestígios
autênticos ou invés de resultados manipulados e forçados pelo invasor? Ao ter acesso ao
sistema, o invasor pode, por exemplo, ter modificado a saída de comandos do sistema
operacional, de modo que sejam exibidas apenas as informações que ele deseja. Alvos de
modificação comuns são o Shell, bibliotecas dinâmicas, drivers de dispositivos e até mesmo o
kernel. Assim, cada fragmento de informação deve ser cuidadosamente examinado, a fim de
se encontrar possíveis inconsistências. Quanto maior o número de fontes de informação, e a
independência dessas fontes entre si, maior será a confiabilidade das informações (FARMER,
VENEMA, 2007).
Para garantir a confiabilidade das informações encontradas, deve ser tomada uma série
de cuidados:
• Montar kits de ferramentas confiáveis que estejam disponíveis para uso quando um
incidente ocorrer. Como o ambiente foi invadido, até mesmo os comandos básicos de
sistema operacional não podem mais ser considerados confiáveis, pois podem ter sido
manipulados.
• Montar um ambiente de laboratório, com maior semelhança possível ao ambiente
original, para auxiliar o procedimento de análise.
• Efetuar a análise sobre a cópia das mídias originais, a fim de mantê-las protegidas.
• Utilizar assinaturas criptográficas para autenticar as cópias.
• Manter cadeia de custódia.
• Não armazenar os dados coletados na máquina sob análise, pois o sistema não está
confiável. Enviar os dados coletados via rede para outros hospedeiros, utilizando
ferramentas como netcat ou cryptcat.
2.2. DESAFIOS DA FORENSE COMPUTACIONAL
A Ciência Forense Computacional ainda conta com muitos desafios, de ordem técnica,
social e legal, alguns deles explicitados a seguir, baseado na leitura de (PALMER, 2001) e
(HUBNER, BEM, BEM, 2007):
11
De ordem prática e técnica:
• Carência de profissionais treinados, capacitados e com experiência na área.
• Avanços tecnológicos ocorrendo constante e ininterruptamente. Unidades de disco
rígido simples já alcançaram a capacidade de 1TB (terabytes) em um PC padrão.
Esses dispositivos com grande capacidade de armazenamento criam problemas de
ordem prática, à medida que analisá-los com as ferramentas disponíveis em tempo
hábil, é uma tarefa difícil, pois a cópia de dados é lenta e a realização de pesquisas é
ainda mais demorada.
• Dispositivos de armazenamento com tamanho reduzido podem ser ocultados
facilmente.
• Algoritmos de criptografia de dados se tornaram eficientes de tal modo que quebrar
uma senha utilizando o método de força bruta para ter acesso aos dados cifrados é
impraticável. Para fins de ilustração, caso uma mensagem tenha sido cifrada utilizando
o padrão AES (Advanced Encryption Standard), que possui chave de 128 bits, e o
atacante possua um sistema que tenta um bilhão de chaves por segundo, seriam
necessários
anos para verificar todas as combinações possíveis para a chave.
Ferramentas de criptografia são facilmente obtidas na Internet e distribuídas
gratuitamente.
• Muitas propriedades e mecanismos de sistemas operacionais ou softwares não são bem
documentadas pelos seus desenvolvedores, gerando dificuldades na análise do
ambiente.
• Muitas vezes os dados de interesse do investigador podem não residir no dispositivo
ao qual ele possui acesso físico. O armazenamento online se tornou popular e
acessível, e alguns provedores de serviços na Internet já oferecem serviço de
armazenamento virtual com criptografia.
• A incerteza sobre a acurácia e eficácia das técnicas utilizadas atualmente gera a
necessidade de manter os dados armazenados por longos períodos, desperdiçando
recursos que poderiam ser aplicados na resolução de outros problemas ao invés de
apenas armazenamento.
12
De ordem legal:
• Pouco adianta desenvolver tecnologias extremamente avançadas de análise forense se
os resultados produzidos não estiverem em conformidade com a lei e, portanto, não
tiverem validade jurídica.
• Falta de padronização de procedimentos, protocolos e terminologia, a fim de unificar a
prática e fornecer validade legal ao processo.
• Muitas vezes os dados de interesse do investigador podem estar armazenados em
outros países, sob outra jurisdição, e podem ser acessados como se fossem locais. A
cooperação com o sistema jurídico de outros países pode ser lenta e difícil, mesmo
naqueles que já possuem leis de crimes eletrônicos bem desenvolvidas; geralmente
criam-se regras complexas impedindo a liberação das informações.
• A utilização da computação em nuvem (cloud computing), que vem se mostrando uma
tendência de mercado, introduz vários questionamentos de segurança: Como haverá
garantia de privacidade? Onde estão as evidências? As provas são admissíveis nesse
contexto? Qual é a jurisdição aplicável? Nesse cenário, é possível que o perito não
tenha mais acesso ao ambiente que será investigado, dificultando a realização da
perícia.
• Organizações criminosas agindo inadvertidamente na Internet.
• A coleta e acesso aos dados do sistema para realização da análise muitas vezes vai
contra os direitos de privacidade dos usuários.
• Estabelecimento e reconhecimento da Forense Computacional como disciplina
científica.
2.3. PROCEDIMENTOS
Para assegurar a autenticidade e integridade dos dados obtidos em um processo de
análise forense, devem existir procedimentos bem definidos, claros e documentados,
garantindo que as provas não foram comprometidas ou alteradas durante o processo de coleta
e enquanto estiveram sob custódia dos peritos envolvidos na investigação. Caso contrário, as
informações obtidas no processo forense perdem a validade e podem ser consideradas
ilegítimas. Como todo processo de forense nas outras áreas de conhecimento, deve-se garantir
13
que, de posse dos dados, a análise poderá ser refeita por outros peritos e os mesmos resultados
serão obtidos.
Assim, é importante destacar que durante todo o processo de análise forense é
necessário documentar rigorosamente todos os passos seguidos, assim como manter registro
de todas as pessoas envolvidas no processo investigativo que tiveram acesso às informações
sigilosas, ou seja, deve-se manter cadeia de custódia.
A adoção de métodos e procedimentos também simplifica o processo de coleta,
armazenamento e análise de evidências, contribui para dar valor probatório às evidências
coletadas e minimiza o impacto e reações negativas nos casos em que os envolvidos na perícia
estão sob forte pressão e elevado nível de estresse, evitando ações errôneas que possam
comprometer as evidências. Os procedimentos para a Forense Computacional devem ser
amplos e generalizados de modo a abranger toda a heterogeneidade de softwares, hardwares e
padrões diversos de tecnologia.
A perícia forense computacional possui quatro procedimentos básicos, que
contemplam a identificação, preservação, análise e apresentação das evidências (FREITAS,
2006). As tarefas envolvidas no processo de investigação estarão enquadradas nessas fases,
que são detalhadas a seguir e sintetizam as idéias expostas até aqui.
Figura 2.2 – Procedimentos da perícia forense computacional
A figura 2.2 resume os quatro procedimentos da perícia forense. O processo
transforma os dados coletados do sistema em evidências, compondo provas que podem ser
utilizadas para aplicação da lei ou para uso interno em uma organização. O primeiro contato
14
ocorre quando os dados são coletados. Em seguida, após serem preservados, as cópias geradas
podem ser utilizadas para análise, onde os dados são transformados em informação. Por fim,
ocorre a transformação de informação em evidência, de forma análoga à transformação de
conhecimento em ação, podendo ser utilizada com provas judiciais ou recomendações de
segurança em uma organização. Os resultados também podem servir como conhecimento para
geração de novas pistas para um caso.
2.3.1. Identificando as Evidências
Nessa fase o perito deve buscar todas as evidências possíveis, considerando o cenário
e o tipo de incidente, já que diferentes tipos de crimes geram diferentes tipos de evidências. A
capacidade de identificação vai depender da habilidade e experiência do perito e do uso de
ferramentas adequadas.
Para encontrar evidências, o investigador deve identificar quais sistemas foram
afetados, procurar por dispositivos de armazenamento de evidências, procurar informações
acerca do acontecimento, como nomes de pessoas, números telefônicos, datas e horários, além
de informações sobre o sistema, como: rever a topologia de rede, identificar conexões de rede
estabelecidas, portas abertas, processos em execução e etc.
Após a identificação das fontes de evidências, é preciso realizar a coleta dos dados,
levando-se em conta a prioridade na ordem da coleta, ou seja, deve ser estabelecida uma
ordem na qual os dados devem ser adquiridos, considerando a volatilidade da informação, o
esforço de adquirí-la e o seu valor estimado. A RFC 3227 possui orientações sobre as
melhores práticas de coleta e armazenamento de evidências que são úteis e aplicáveis ao
contexto da forense computacional.
O perito deve prezar pela otimização da coleta de dados, já que não é necessário
coletar tudo que estiver disponível em um sistema, mas apenas as informações essenciais e
aplicáveis à análise do incidente. Também deve minimizar os riscos de corrupção ou
destruição dos dados durante a coleta.
Possíveis fontes de evidências, a serem consideradas pelo perito, são listadas a seguir:
• Dispositivos de Armazenamento na CPU - Registradores e cache
Fornecem pouca informação relevante e segundo (WARREN, 2002) a captura dos
dados pode ser considerada impraticável.
15
• Memória Principal
Pode fornecer informações sobre o sistema operacional e os processos que estão em
execução, além de senhas, dados em manipulação que ainda não foram gravados no
disco, vestígios de códigos maliciosos, textos em claro que estão cifrados no disco,
dados ocultos, etc. Os dados armazenados podem ser capturados através de
procedimentos específicos, que serão abordados no próximo capítulo.
• Memória de Periféricos
Pode fornecer informações úteis que não estão disponíveis na memória principal,
como documentos impressos ou enviados por fax, imagens exibidas no monitor, etc.
• Discos rígidos e mídias secundárias
Podem fornecer dados sobre os arquivos, assim como prover informações sobre sua
manipulação (MAC Times) e permitir a recuperação de arquivos apagados. Além de
informações sobre os arquivos, pode conter informações ocultas nas áreas que não são
acessíveis pelo sistema de arquivos. Normalmente, contém grande parte das
informações utilizadas pelo perito para a extração de evidências.
• Módulos de Kernel
A identificação de módulos de kernel maliciosos pode sugerir que o invasor carregou
módulos com alguma finalidade maliciosa, como fornecer recurso indevidamente a um
dispositivo, incorporar nova linguagem de programação, ou alterar as chamadas de
sistema (system calls). Os módulos maliciosos podem comprometer por completo o
funcionamento normal do sistema operacional, alterando comandos de sistema para
produzir resultados manipulados e esconder as ações do invasor.
• Estado do Sistema Operacional
Dados sobre o estado do sistema operacional fornecem vestígios importantes, como
informação sobre processos em execução e seus privilégios, usuários conectados, data
16
e hora do sistema, aplicativos que estão em funcionamento, em listening, conexões de
rede estabelecidas, status das interfaces de rede, tabelas de rotas, arquivos de
configuração e de logs.
• Tráfego de Rede
Com a utilização de analisadores de tráfego (sniffers), é possível capturar datagramas
que trafegam na rede e obter informações sobre as conexões estabelecidas com a
máquina alvo, de modo a estabelecer uma seqüência de eventos e correlacionar com
outras evidências. Além disso, logs de IDS, firewall, proxy, roteadores e servidores de
autenticação podem fornecer informações importantes.
2.3.2.
Preservando as Evidências
As evidências devem ser preservadas de modo que não haja dúvidas sobre sua
veracidade. Para evitar que sejam comprometidas ou perdidas durante o processo de
investigação, devem ser tomados alguns cuidados:
• Duplicação pericial: criar imagens do sistema a ser investigado para que a análise seja
realizada trabalhando-se apenas com as cópias e mantendo o original como o mínimo
de alterações.
• Todas as evidências devem ser lacradas e etiquetadas, registrando a data e horário em
que a evidência foi coletada, assim como os dados de quem a possui sob custódia.
• Gravar as evidências em mídias que não permitam regravação.
• Identificar e anotar todos os componentes do sistema computacional envolvido, para
que o cenário possa ser recriado em laboratório.
• Manter as evidências guardadas em cofre, para evitar adulteração.
• Manter cadeia de custódia. Deve-se registrar onde, quando e por quem as evidências
foram coletadas; quem teve acesso às informações após a coleta, quanto tempo durou,
quando foi concedido esse acesso e a justificativa para a concessão; quem teve
custódia da evidência, por qual período e como as evidências foram armazenadas
17
durante o intervalo; como e quando ocorreu a transferência de custódia, nos casos em
que esta ocorrer.
2.3.3. Analisando as Evidências
A análise dos dados depende de trabalho especializado para a coleta e interpretação
das informações e normalmente é a fase mais demorada do processo investigativo. Nessa fase,
o perito vai realizar a reconstrução da cena (quando possível), fazer a correlação entre eventos
e análise de todas as evidências coletadas, a fim de responder as questões que norteiam a
perícia forense: identificar quem fez, o que fez, quando fez e como fez. Depois de analisar e
interpretar as evidências, o perito deverá ser capaz de responder a questionamentos que
podem levar ao entendimento do incidente. Todas as atividades executadas nessa fase devem
ser minuciosamente documentadas.
A condução do processo de análise está relacionada ao tipo de incidente que o perito
está investigando, pois dependendo do caso, as pistas que ele busca serão diferentes. Por
exemplo, nos casos de pedofilia, os dados de interesse ao perito normalmente são: as
conexões com outros hosts utilizando protocolos de transferência de arquivos, arquivos de
vídeo e imagem suspeitos, histórico de navegação na Internet exibindo endereços de sites de
pedofilia, serviços de correio eletrônico enviando ou recebendo mensagens com anexos
suspeitos, dentre outros vestígios. Já no caso de sites de hospedagem de conteúdo pirata, os
dados de interesse poderiam ser: servidores web ativos com páginas carregadas, conexões web
com requisição para as páginas hospedadas com conteúdo suspeito. Assim, a experiência do
perito, adquirida em analises anteriores, colabora para agilizar e melhor conduzir o processo
de análise das evidências.
A Figura 2.3 apresenta um fluxograma para condução do processo de análise das
evidências. O modelo apresentado serve como referência e pode ser adaptado de acordo com
as necessidades de cada organização, mantendo-se os princípios e metodologia geral
apresentados.
18
Início
Figura 2.3 – Fluxograma da fase de análise das evidências
Figura adaptada de (DIGITAL, 2007)
19
2.3.4. Apresentação dos Resultados
Por fim, deve ser redigido um laudo pericial apresentando os resultados obtidos pela
investigação de forma clara, organizada, concisa, imparcial e conclusiva. O laudo pericial é o
relato do perito após análise e correlação das evidências, resultado de um processo de
avaliação. Consiste na tradução das informações captadas pelo perito por meio de
conhecimentos especializados e deve estar pautado em aspectos éticos e legais.
No laudo, devem ser anexadas todas as evidências e demais documentos que fizeram
parte do processo investigativo, buscando comprovar a integridade das informações através
do detalhamento de todos os procedimentos e técnicas empregados.
Devem constar também os materiais que foram analisados pelos peritos, o objetivo do
trabalho de investigação, métodos e ferramentas que foram utilizados, dentre outras
considerações específicas. Devem ser fornecidas mídias contendo o conteúdo que foi
analisado e que contém as evidências, juntamente com suas assinaturas criptográficas, a fim
de evitar alterações. Em conjunto com o laudo, os peritos devem devolver as mídias e
dispositivos originais que foram confiscados no momento do incidente, no mesmo estado em
que foram recebidos.
Embora se deva conservar a terminologia tecnológica e científica em seus relatos, o
laudo deve ser elaborado utilizando linguagem acessível a quem ele se destina, utilizando
recursos gráficos e visuais, se for possível, para facilitar a compreensão.
Embora conclusivo, o laudo pericial pode ser questionado ou contestado, por isso é de
extrema importância que seja formulado com argumentações bem embasadas e que a
integridade dos dados seja comprovada. Nele só devem constar afirmações que podem ser
provadas e demonstradas técnica e cientificamente.
Quando realizado para fins corporativos, o laudo também pode fazer recomendações
sobre o que deve ser feito para prevenir ou corrigir o problema: alterações nas políticas de
segurança da empresa, nos procedimentos, processos, ferramentas adotadas, dentre outros.
O Anexo I apresenta um modelo de laudo pericial utilizado pelo Departamento de
Polícia Federal para apresentação dos resultados de seus exames periciais.
20
3.
PERÍCIA FORENSE COMPUTACIONAL: ANALISANDO
A MEMÓRIA VOLÁTIL
Conforme mencionado no capítulo anterior, a memória principal, ou memória volátil,
pode conter informações relevantes para um processo de investigação forense, como senhas,
chaves criptográficas, vestígios de códigos maliciosos, informações de rede e processos,
dentre outros dados. E à medida que surgem novos desafios à forense computacional, como a
utilização de criptografia em discos rígidos e a disseminação de malwares que residem
exclusivamente na memória, tornou-se mais importante ir além da forense tradicional e
desenvolver habilidades para examinar também os vestígios obtidos através da captura e
análise da memória principal. Para realizar esse tipo de análise, o perito deve atualizar
constantemente os seus conhecimentos, uma vez que a área de informática é bastante
dinâmica e os avanços são rápidos.
A memória principal de um computador, a memória RAM, é por natureza considerada
um dispositivo de armazenamento de dados volátil, pois é bastante provável que estes sejam
perdidos quando a máquina for reiniciada ou que sejam sobrescritos enquanto a máquina
estiver em funcionamento com suas atividades padrão. Porém, muitas informações advindas
desses dados voláteis, que só podem ser recuperadas através da memória, são de grande
importância para a condução de um processo investigativo. Segundo (AMARI, 2009), a
análise de qualquer memória volátil é menos precisa do que a do disco rígido, já que estes
possuem uma estrutura pré-definida e conhecida pelos peritos, que baseados nisso sabem onde
devem buscar determinados tipos de informações em um sistema de arquivos. Ao contrário, a
memória, pode ser alocada e desalocada de acordo com a necessidade de sua utilização, sendo
“impossível prever o que irá encontrar na memória volátil ou onde estará armazenado”.
Embora a coleta de informações específicas da memória volátil, sobre conexões de
rede ou processos em execução, por exemplo, seja conhecida há algum tempo e
extensivamente discutida, a questão da coleta, manipulação e análise de todo o conteúdo da
memória física é um esforço relativamente novo, pelo menos do ponto de vista público
(CARVEY, 2007).
Nesse capítulo serão expostas técnicas, procedimentos e ferramentas para a coleta e
análise de dados da memória principal, assim como os dados que podem ser obtidos através
do dump (cópia dos dados) da memória. Não se pretende aqui abordar todas as técnicas e
21
ferramentas existentes e possíveis, mas destacar a importância delas, apresentando as mais
utilizadas atualmente e incentivar a sua aplicação, assim como o aprimoramento e
desenvolvimento de novas ferramentas específicas que facilitem, complementem e estendam
esse tipo de análise.
3.1. A MEMÓRIA VOLÁTIL
Considerando a arquitetura de um computador de uso geral, todo programa e dado
precisa ser armazenado temporariamente na memória principal (RAM) para que seja
executado ou processado pela CPU, devendo permanecer na memória principal apenas
enquanto o processamento dos dados for necessário. Assim, quando um programa gravado em
mídias de armazenamento, como o disco rígido, precisa ser executado, ele é carregado em
uma área da memória RAM e fica disponível para processamento; quando finalizado, a área
alocada para esse programa na memória pode ser liberada, fornecendo espaço para a execução
de outros programas e processos. Diferentemente disso, as arquiteturas de propósito especial,
como de PDAs e celulares, normalmente armazenam os programas e dados em posições de
memória diretamente endereçáveis, então não há necessidade de serem copiados para a
memória principal a fim de serem processados (FARMER,VENEMA, 2007). Porém, as
idéias propostas neste trabalho se baseiam na arquitetura de máquinas de uso geral, na qual os
dados são armazenados na memória principal para que haja acesso rápido pelo processador.
Esse tipo de memória (RAM) possui natureza volátil, devido à rapidez com que os
dados se perdem quando ocorre a realocação das áreas da memória. Segundo a literatura,
quando o computador é desligado, seu conteúdo é perdido; no entanto, essa informação já foi
questionada em estudos de caso. De acordo com o trabalho realizado por (LISITA, MOURA,
PINTO, 2009), em que foi questionada a persistência dos dados na memória volátil, mesmo
após a interrupção de energia, mostrou-se que ainda é possível encontrar resquícios de dados
na memória volátil. Segundo os autores, após a realização de testes no sistema operacional
Linux (Slackware kernel 2.6.24.5-smp), foi possível identificar resquícios de dados antigos na
memória após o reboot da máquina. Nesse mesmo teste, não foi possível identificar vestígios
no sistema operacional Windows XP SP2, pois a memória provavelmente foi limpa no boot
posterior ao desligamento do sistema.
22
O gerenciamento de memória, função desempenhada pelo sistema operacional, é
responsável pela organização da memória e pelas estratégias de gerenciamento, alocação de
espaço e interação da memória com dispositivos. É o gerenciador de memória que determina
como as áreas da memória devem ser alocadas para os processos sob condições de restrição
de espaço, estabelecendo as prioridades de acordo com a necessidade, e também gerencia
como a memória pode ser utilizada pelos processos de sistema.
Segundo (FARMER, VENEMA, 2007) podem residir nas páginas de memória dois
tipos de dados básicos fora os do kernel: dados lidos de arquivos e dados de páginas
anônimas, sendo que as páginas anônimas contêm informações sobre o estado dos processos:
o heap, a pilha, se estão ou não em execução, etc. Cabe ao gerenciador de memória virtual
decidir se determinada página de memória será armazenada em um arquivo (memória virtual
ou secundária), na memória principal ou no espaço de troca (swapping). Depois que um
arquivo é lido na memória principal, seus dados permanecem ali por um tempo, dependendo
do grau de atividade do computador, sendo que as páginas de memória anônimas tendem a ser
mais voláteis que os dados de arquivos. Assim, dependendo do tipo de dado armazenado,
alguns são mais propensos a serem paginados ou sobrescritos, caso o sistema operacional
precise alocar espaço na memória para armazenar outros processos ou dados.
No Windows, os dados e métodos de manipulação utilizados pelo kernel,
denominados de objetos, possuem um OBJECT_HEADER, que consiste em uma estrutura
com informações sobre o objeto armazenado. O kernel trabalha com dois conjuntos de
memória, e escolhe entre duas formas para armazenar um objeto na memória: utilizando o
espaço de paginação (paged pool) ou o espaço não paginável (non-paged pool). A maioria dos
dados será armazenada na área paginável, enquanto os objetos mais importantes, que
precisam ser acessados pelo kernel com maior freqüência, serão armazenados no espaço não
paginável. Os dados paginados são passíveis de serem armazenados em arquivos no disco
rígido, caso a memória principal esteja com pouco espaço disponível. No entanto, processos e
threads, que são acessados com freqüência e possuem considerável importância para o
sistema operacional, são armazenados fora do espaço de paginação, garantindo que estarão
armazenados na memória principal. Por isso, é possível obter informações sobre todos os
processos que estavam em execução no momento em que a imagem da memória é capturada
para a análise forense (AMARI, 2009).
Ainda no Windows, existe uma estrutura que armazena informações sobre os
processos, o Virtual Address Descriptor (VAD), descrevendo qual é a área de memória
23
utilizada pelos processos que estão em execução, além de outras informações relacionadas a
cada um. Dessa forma é possível reconstruir o espaço de endereçamento virtual de um
processo e recuperar arquivos relacionados a ele que estejam mapeados na memória (van
Baar, Alink, van Ballegooij, 2008).
3.2. DADOS ENCONTRADOS NA MEMÓRIA VOLÁTIL
Existe uma grande diversidade de dados disponíveis na memória principal, ou
memória volátil, de um sistema. Informações de rede, informações sobre processos, arquivos
abertos e chaves de registro (registry), dados ocultos, bibliotecas e módulos carregados pelo
sistema operacional, dentre outros. Nessa seção serão apresentados os principais tipos de
dados que podem ser capturados da memória principal e que podem ser úteis para o processo
de perícia forense baseado em conteúdo obtido na memória.
3.2.1. Processos
Podem ser encontradas na memória informações sobre os processos que estavam em
execução no momento da captura, assim como sobre os processos ocultos e processos já
finalizados, caso a área de memória que estes últimos ocupavam não tenha sido realocada
após sua finalização. Por exemplo, podem ser encontradas bibliotecas carregadas por
determinado processo e/ou sua memória endereçável.
3.2.2. Arquivos abertos e Conteúdo do Registro do Windows (Registry)
Verificar quais arquivos foram abertos por determinado processo pode ser muito útil
em uma investigação, pois é possível estabelecer quais as atividades associadas a este
processo. No caso de um malware instalado na máquina, por exemplo, encontrar os arquivos
associados ao processo em execução pode levar à descoberta do código malicioso armazenado
no disco, que tipo de saída está sendo produzida e onde os dados estão sendo gravados, ou
quais arquivos pré-existentes foram removidos e modificados. Também é possível determinar
24
quais as chaves de registro (registry keys) que determinado processo estava acessando através
da análise forense da memória.
Em sistemas UNIX, a estrutura de inodes provê informações sobre os arquivos
mapeados na memória, como permissões de acesso, identificação dos donos do arquivo, data
e horário do último acesso e da última alteração, tamanho e ponteiros para o arquivo.
3.2.3. Informações de rede
As informações sobre as conexões de rede geralmente representam um dos dados mais
críticos e importantes para a condução da investigação. Podem ser encontradas informações
sobre as conexões estabelecidas, principalmente IPs e portas em listening. A obtenção desses
dados a partir do dump da memória é importante porque como o sistema está sob suspeita
após a invasão, ferramentas básicas que forneceriam esses dados, como o netstat, não são
mais confiáveis, podem ter sido manipuladas pelo invasor para exibirem resultados diferentes.
Assim, utilizando as informações coletadas diretamente da memória é menos provável que o
invasor oculte os dados de interesse do investigador.
3.2.4. Senhas e Chaves Criptográficas
Uma das grandes vantagens da forense em memória é a possibilidade de encontrar
senhas e chaves criptográficas para decifrar conteúdos que estão criptografados no disco ou
ter acesso a arquivos protegidos por senha e contas de correio eletrônico ou de mensagens
instantâneas, por exemplo. Dificilmente senhas e chaves criptográficas poderiam ser obtidas
através de análise do disco rígido, pois em geral são armazenadas com algum tipo de
proteção. Através da coleta dos dados em memória, no entanto, é possível obtê-lo, pois ao
utilizar a senha o usuário precisa digitá-la e inevitavelmente ela será armazenada na memória,
permanecendo ali até que essa área de dados seja reutilizada e seus dados sobrescritos.
25
3.2.5. Conteúdo decifrado
Caso não seja possível recuperar as senhas e chaves criptográficas na memória, esta é
outra forma de se obter acesso aos dados cifrados no disco. Quando um arquivo criptografado
é acessado, seu conteúdo é então decifrado e carregado na memória, podendo permanecer nela
armazenado mesmo depois que tiver sido fechado, desde que a área de memória não seja
realocada e os dados sobrescritos. Assim, é possível recuperar todo o conteúdo dos arquivos
ou ainda alguns fragmentos úteis.
3.2.6. Dados Ocultos
É possível que o invasor armazene dados que deseja esconder na memória ao invés do
disco rígido, pois a chance de serem descobertos é menor, já que a análise da memória é
menos freqüente que o exame do disco rígido. Para o invasor, é mais seguro ocultar esses
dados na memória, porque sua eliminação também é mais simples, bastando, por exemplo,
reiniciar a máquina da qual já possui controle.
3.2.7. Códigos Maliciosos
Além de poder ocultar na memória arquivos e informações sensíveis que deseja
proteger, o invasor pode executar códigos maliciosos, como rootkits, que residem
exclusivamente na memória. Assim, o código contendo as instruções e atividades maliciosas
não fica disponível com facilidade para o investigador, dificultando seu trabalho e uma
possível engenharia reversa. Essa técnica, de utilizar a memória ao invés do disco para
armazenar malwares tem crescido significativamente, pois os antivírus e ferramentas de
detecção de malwares não são tão eficazes na detecção de códigos maliciosos na memória
volátil quanto o são no disco; alguns nem possuem essa funcionalidade.
Enquanto um programa está em execução, sabe-se que pelo menos parte dele estará
residindo na memória. Porém, quando sua execução é finalizada e a área de memória que este
ocupava é desalocada, não se sabe por quanto tempo os dados persistem ali, devido a uma
26
série de fatores que tornam o ciclo de vida desses dados não previsível, como o tipo de
sistema operacional, nível de atividade do sistema e quantidade de memória disponível.
Mesmo tendo conhecimento de quais dados é possível extrair da memória, não é
possível medir ao certo a sua persistência na memória, nem mesmo ter a certeza de quanto
tempo os dados que foram encontrados já estavam ali. Como cada kernel e seu gerenciador de
memória possui implementação própria, obter metadados associados a tempo sobre a
memória não é uma tarefa simples, ao contrário de uma análise utilizando MAC Times, por
exemplo, que pode prover informações temporais sobre os dados no sistema de arquivos.
Alguns sistemas computacionais, independentemente do sistema operacional, quando
são reinicializados apagam os dados anteriores da memória principal. Pode ser importante
levar em consideração esta particularidade ao capturar os dados, para se vislumbrar a
potencial longevidade dos dados que estão na memória.
Conforme citado anteriormente, estudos já questionaram a volatilidade da memória
principal e mostraram que é possível recuperar dados nela presentes durante o funcionamento
do sistema, dependendo da intensidade de utilização da memória e realocação de suas
páginas, ou até mesmo após a sua reinicialização.
3.3. TÉCNICAS PARA ANÁLISE FORENSE DA MEMÓRIA
Para viabilizar a análise forense baseada na memória RAM, é necessário que o perito
conheça bem procedimentos distintos para coleta de dados, assim como técnicas para análise
do conteúdo obtido. Nesse capítulo serão discutidos procedimentos e técnicas para a forense
de memória, assim como serão apresentadas ferramentas para a aquisição e análise dos dados
existentes da memória volátil.
3.3.1. Recuperação de Arquivos Mapeados em Memória
No sistema operacional Windows, a estrutura EPROCESS concentra dados sobre
todos os processos, incluindo informações sobre seus atributos e ponteiros para outros objetos
e estruturas de dados que são relacionados a ele. A estrutura EPROCESS contém o bloco
process environment (PEB), que contém dados carregados pelo processo, como módulos e
27
arquivos, o que pode ser muito útil na análise de malwares e rootkits. O PEB também exibe
onde reside a imagem dos executáveis, caminhos das DLLs e as linhas de comando utilizadas
para execução do processo.
O PEB possui ponteiros para a raiz da árvore de descritores VAD (Virtual Address
Descriptor), uma estrutura que armazena informações sobre os processos, descrevendo qual é
a área de memória utilizada pelos processos que estão em execução, além de outras
informações relacionadas a cada um. Com base nessa estrutura é possível reconstruir o espaço
de endereçamento virtual de um processo e recuperar arquivos relacionados a ele que estejam
mapeados na memória.
A Figura 3.1 mostra a representação visual da estrutura VAD tree. Como pode ser
visto, o mapeamento de arquivos utiliza diferentes estruturas de dados. A figura apresenta as
ligações estabelecidas entre essas estruturas de memória e exibe informações sobre os
arquivos mapeados em memória. As linhas pontilhadas indicam ponteiros que são apagados
quando um processo é finalizado.
Uma das estruturas da árvore VAD, denominada Object Table lista os objetos privados
que estão em uso por um processo: arquivos, chaves de registro (registry keys) ou eventos. Os
arquivos mapeados em memória associados com cada processo podem ser recuperados
percorrendo a estrutura da árvore VAD e encontrando os objetos de interesse. Tal como
acontece com os processos que foram finalizados, arquivos que foram fechados permanecem
na memória, apesar não serem elencados nas listas mantidas pelo sistema operacional, e assim
devem ser recuperados através de métodos alternativos. O processo de reconstrução de tais
arquivos é similar ao de reconstruir arquivos que foram removidos de um disco rígido,
embora o processo seja mais complexo com a memória, pelo fato desta ser mais fragmentada.
Geralmente, observando a estrutura Page Table é possível recuperar estes arquivos mesmo
que não estejam ativos na memória. A área da memória denominada Control Area mantém os
vínculos entre nomes de arquivos e seus dados que foram armazenados nas páginas de
memória. Caso esta área ainda esteja presente, é possível recuperar também o nome do
arquivo (AMARI, 2009).
28
Figura 3.1 - Representação visual da árvore de descritores: VAD tree.
(van Baar, Alink, van Ballegooij, 2008).
3.3.2. Recuperação de Arquivos Através de Assinatura
Outra técnica, mais antiga e menos confiável, mas bastante utilizada para se recuperar
arquivos na memória é conhecida como Data Carving ou File Carving. Essa técnica se baseia
no fato de que cada tipo de arquivo tem uma assinatura diferente, que se refere a determinados
padrões de valores que são únicos para aquele tipo de arquivo. Assim, arquivos do tipo zip, ou
com extensões doc e jpeg, por exemplo, terão assinaturas próprias, constituindo padrões
únicos. O processo de “escavação de dados”, buscando pela assinatura, pode ser realizado
linearmente na imagem da memória; se realizado desta forma, arquivos contíguos podem ser
recuperados, mas fragmentos de arquivos não. Porém, existem algoritmos de data carving
complexos que são capazes de recuperar arquivos fragmentados utilizando as estruturas que
os descrevem internamente com maior profundidade.
29
Essa técnica também pode ser utilizada para recuperação em discos rígidos, inclusive
com maior êxito que em dumps de memória, pois normalmente os sistemas operacionais
buscam não fragmentar os arquivos no disco. Assim, como é comum que apenas partes de um
arquivo sejam carregadas na memória, ao invés dele inteiro, mesmo que seja utilizado um
algoritmo eficiente, é possível que as partes que o compõem e que são de interesse do
investigador não sejam encontradas, impedindo sua recuperação.
Embora seja uma técnica que nem sempre garante resultados satisfatórios, é
importante que seja considerada e faça parte do kit de ferramentas de um perito forense.
3.3.3. Detecção e Recuperação de Dados Escondidos
É importante levar em consideração que as técnicas apresentadas anteriormente, apesar
de serem úteis e auxiliar no processo de recuperação, não se aplicam a todos os processos e
threads. Quando um processo é finalizado ou ocultado pelo sistema operacional, a estrutura
de dados que definia aquele processo não fará mais parte da árvore VAD e demais listagens
que o sistema operacional mantém para controlar o que está em execução.
No entanto, processos e threads encerrados, ou arquivos fechados, podem ser de
grande importância ao investigador, já que podem estar relacionados ao incidente, mas terem
sido finalizados antes que o material para análise fosse coletado. Um invasor pode utilizar
manipulação direta de objetos do kernel (DKOM) para remoção de processos suspeitos ou
outros tipos de objetos das listas e tabelas que o kernel utiliza para controlá-los, ocultando
esses objetos da API do Windows e tornando as técnicas apresentadas nas seções anteriores
ineficientes. Dessa forma, é importante desenvolver métodos que não dependam das
estruturas de dados utilizadas pelo sistema operacional.
Conforme (AMARI, 2009), todos os tipos de objetos possuem padrões relacionados a
eles, como exemplo, o cabeçalho de cada processo vai possuir constantes que serão as
mesmas para cada processo encontrado na memória. Assim, para encontrar processos não
referenciados nas estruturas de dados do sistema operacional, é necessário buscar por toda a
imagem da memória pelos valores dessas constantes, utilizando-os como guia no processo de
busca. Existem atualmente ferramentas que efetuam essa busca de forma automatizada para
alguns objetos comuns como processos e arquivos. Algumas características exploradas por
essas ferramentas para encontrar processos escondidos são explicadas por (AMARI, 2009): na
estrutura EPROCESS, o ponteiro DirectoryTableBase aponta para o início de estruturas,
30
então pode ser utilizado para percorrer a informação a fim de encontrar partes importantes e
checar com a “assinatura” previamente mapeada de um processo. Outra checagem é o valor
da PageDirectorytable, que deve ser diferente de zero.
Cada processo requer, no mínimo, uma thread; as threads são armazenadas em uma
estrutura que é basicamente outra lista de vínculos, semelhante ao que ocorre com os
processos, e fica armazenada no espaço de kernel da memória. Dois ponteiros,
ThreadListHead.Flink e ThreadListHead.Blink, são verificados para se confirmar que
apontam para um endereço maior que 0x7fffffff, o que significa que devem apontar para o
espaço do kernel na memória.
Há também outras verificações importantes que podem ser realizadas, para se verificar
a probabilidade de que os objetos em memória sejam processos ocultos.
3.4. EXTRAÇÃO DE DADOS DA MEMÓRIA VOLÁTIL
Existe uma diversidade de métodos que podem ser utilizados para fazer a aquisição
dos dados presentes na memória, alguns deles baseados em hardware e outros em software. A
seguir serão apresentados os principais métodos utilizados para extração dos dados e alguns
aspectos técnicos associados. Tendo conhecimento das opções, o perito pode eleger a que
mais se adequa ao sistema alvo e ao caso que está investigando e assim agir com maior
prudência.
3.4.1. Hardware
Existem dispositivos que possibilitam a captura do conteúdo da memória RAM. Eles
são normalmente utilizados para depurar problemas de hardware, mas também podem ser
utilizados para análise forense. O dispositivo Tribble, um cartão PCI, foi desenvolvido
especialmente para a prática forense no ano 2004.
Outra solução baseada em hardware, que pode ser viável em sistemas que disponham
de portas do tipo firewire, baseia-se no acesso direto à memória (DMA), sem utilização do
processador. Nesse caso, o mapeamento da memória é executado diretamente em hardware,
de forma independente do sistema operacional. Dispositivos firewire podem ler a memória
31
com velocidades superiores aos sistemas que não utilizam DMA (Direct Memory Access) e,
além disso, não enfrentam o problema de algumas versões do Windows que não permitem que
a memória seja acessada em modo usuário. No entanto, não há garantia de que a coleta via
dispositivos firewire será bem sucedida, pois a memória pode não ser completamente copiada
ou o sistema pode travar durante o processo de aquisição.
A vantagem em se realizar a coleta utilizando soluções baseadas em hardware é que
esse procedimento é menos intrusivo para o sistema. Em uma abordagem com software é
preciso rodar um programa que carrega dados na memória, o que pode sobrescrever dados de
interesse que nela estão armazenados. Dependendo da forma em que o software foi
concebido, ele pode precisar utilizar bibliotecas disponíveis no sistema operacional, que
podem ter sido manipuladas pelo invasor e não fornecer resultados confiáveis. Já em uma
coleta efetuada com hardware não são carregados programas no sistema, tornando o conteúdo
obtido mais confiável e fiel ao original.
As soluções baseadas em hardware são opções interessantes principalmente quando o
sistema está bloqueado ou quando a possibilidade de alteração e contaminação do sistema é
inaceitável. A desvantagem é que o hardware precisa ser instalado previamente ao incidente,
devido à necessidade de reinicialização do sistema, e esse tipo de solução possui custos mais
elevados.
3.4.2. Crash Dumps
A análise de crash dumps é outra forma de se obter informações sobre o conteúdo da
memória RAM. Diferentemente de outros métodos de coleta baseados em software, a imagem
obtida a partir de um crash dump é uma cópia inalterada do conteúdo da memória de um
sistema no momento em que ocorreu o crash. Isso ocorre porque quando o crash dump
ocorre, o estado do sistema é congelado e o conteúdo da RAM é gravado em um arquivo de
paginação, para posteriormente ser escrito no disco, em um arquivo com tamanho igual ao da
memória física. Assim, o arquivo de paginação deve ser configurado para ser igual ao
tamanho da memória mais 1MB (megabyte) para o cabeçalho e deve haver espaço em disco
suficiente para gravar um arquivo do tamanho da memória.
Não é necessário instalar nenhum software no sistema para realizar a coleta, e
conseqüentemente não há alteração do conteúdo da memória, mas como há gravação de
arquivo no disco, outros vestígios podem acabar sendo destruídos. A desvantagem desse
32
método é que os crash dumps ocorrem apenas quando há falhas no sistema. É possível induzir
um crash dump; no entanto, no Windows, isso requer alteração em uma chave do registro
(registry key) e reinicialização do sistema, ou seja, o ambiente já deve estar preparado para
essa possibilidade antes do incidente, caso contrário, não será válido para a realização da
coleta do conteúdo da memória. A Microsoft fornece ferramentas para análise de crash
dumps.
Mesmo com as particularidades acima descritas, é interessante que o perito tenha
familiaridade com a análise de crash dumps, pois estes podem fornecer informações
relevantes. Os sistemas operacionais da família Windows permitem gerar três tipos de crash
dumps: pequeno, kernel e completo. O crash dump completo é o que contém todo o conteúdo
da RAM, mas nem todas as versões de Windows permitem gerar um crash dump completo. O
Windows 2003 permite, mas o Windows Vista e Windows 2008 Server não permitem crash
dumps completos em sistemas com mais de 4GB (gigabytes) de memória.
3.4.3. Dumps
Existem diversos programas utilitários que possibilitam a aquisição da imagem da
memória de um sistema, alguns serão descritos no capítulo 3.5 deste trabalho. Essas
ferramentas fazem a leitura da memória bit-a-bit e copiam seu conteúdo para um arquivo, o
dump da memória. Esse arquivo terá o mesmo tamanho da memória física do sistema.
O que deve ser levado em conta, independente da ferramenta que está sendo utilizada,
é que, como atesta o Princípio da Troca de Locard, quando um programa de aquisição de
dump é executado, ele deve ser carregado na memória, significando ele deixará vestígios, e
que algum espaço da memória que poderia conter informações valiosas será utilizado,
podendo acarretar inclusive a movimentação da área ocupada por processos para arquivos de
paginação. Além disso, enquanto a ferramenta está lendo o conteúdo da memória, o estado do
sistema não fica congelado, significando que enquanto algumas páginas estão sendo copiadas,
outras podem estar sendo alteradas, caso o processo que a utilize ainda esteja rodando, por
exemplo. O que vai definir o tempo gasto para coletar a imagem são fatores como a
velocidade do processador, taxas de barramento e operações de entrada e saída do disco.
Apesar de não garantirem uma cópia fiel da memória, pois o sistema permanece em
alteração, a grande vantagem de utilizar ferramentas de dump é que o sistema não precisa ser
desligado ou reiniciado, não há restrição sobre onde a imagem gerada deve ser armazenada
33
(localmente ou em outro host da rede, utilizando netcat) e existem ferramentas disponíveis
gratuitamente para realizar análise dos dumps gerados.
Este é o método mais utilizado atualmente pelos peritos em forense computacional
para aquisição do conteúdo da RAM.
3.4.4. Virtualização
Adicionalmente, nos casos em que é utilizada a virtualização, com softwares como
VMWare, um produto bastante popular, é possível suspender a sessão do sistema operacional
que está em execução, mantendo-a congelada temporariamente. E quando a sessão é
congelada, o conteúdo da memória é gravado em um arquivo cujo formato é semelhante a um
dump de memória, e que pode posteriormente ser analisado.
3.4.5. Hibernação
Quando um sistema Windows entra em modo de “Hibernação”, o conteúdo da
memória é comprimido e salvo em um arquivo chamado “Hiberfil.sys”. A compressão do
conteúdo se dá para minimizar operações de entrada e saída do disco, e a análise deste arquivo
pode fornecer informações sobre o que estava acontecendo no sistema no momento em que
ele entrou em hibernação.
Durante as fases da investigação, é possível que o perito se depare com uma situação
em que não seja necessário coletar todo o conteúdo da RAM, bastando-lhe ter acesso ao
conteúdo da memória utilizado por determinado processo. Existem ferramentas disponíveis
para coletar apenas o conteúdo da memória relacionado a um processo, assim como
informações adicionais a seu respeito (módulos carregados, arquivos abertos, etc). Essas
ferramentas não se restringem a coletar apenas a memória física utilizada pelo processo, mas
também a memória virtual, nos arquivos de paginação. Porém, são aplicáveis apenas aos
processos que são visíveis e considerados como ativos pelo sistema operacional; processos
ocultados por rootkits, por exemplo, não podem ser analisados com essas ferramentas
específicas.
34
3.5. FERRAMENTAS
PARA
AQUISIÇÃO
DE
CONTEÚDO
DA
MEMÓRIA RAM
Neste tópico serão apresentadas ferramentas comerciais e gratuitas que podem ser
utilizadas para se realizar a aquisição de memória em sistemas operacionais Windows. A
intenção não é cobrir todas as possibilidades existentes, mas apresentar as ferramentas mais
utilizadas pelos profissionais da área de forense computacional.
3.5.1. DD
Uma ferramenta bastante popular e considerada por muito tempo padrão na área de
forense computacional, o DD (data dumper), foi desenvolvida inicialmente para sistemas
Unix, não exclusivamente para possibilitar o dump da memória, mas também para realizar
cópias de discos rígidos, dentre outras funções como a geração de hashes criptográficos.
Posteriormente, o DD foi adaptado para rodar sob sistemas operacionais Windows,
permitindo coletar o conteúdo da memória RAM através do acesso ao dispositivo
\Device\PhysicalMemory em modo usuário. No entanto, nas versões mais recentes do
Windows, que vieram após o Windows 2003 SP1, o acesso a determinadas áreas da memória
foi limitado e então somente os kernel drivers conseguem realizar o dump, tornando a
ferramenta inadequada para essa finalidade em sistemas Windows. Nas versões mais recentes
do DD, o device \\.\PhysicalMemory já não vem mais habilitado.
3.5.2. Mandiant Memoryze
Mandiant Memoryze é um software gratuito de forense de memória que pode ser
utilizado tanto para a aquisição quanto para a análise de imagens de memória. É capaz de
realizar o dump de todo o espaço físico de memória, independente de APIs do Windows, ou
apenas do espaço endereçável por um processo no disco. Também permite obter a imagem de
um driver específico ou mesmo todos os drivers carregados na memória. A ferramenta
permite enumerar todos os processos em execução e identificar módulos do kernel presentes
na memória.
35
3.5.3. ManTech Memory DD
ManTech Memory DD é um software open source, disponibilizado sob licença GPL
para uso governamental ou particular. É capaz de adquirir imagens de memória e armazenar
em arquivos binários em formato raw, que então devem ser analisados por outras ferramentas.
Para auxiliar na verificação da integridade dos dados e preservação das evidências, é utilizado
o algoritmo de hash MD5. A ferramenta permite copiar até 4GB de memória em um arquivo
de dump para análise posterior e não precisa ser instalada no sistema, podendo ser executado a
partir de mídias removíveis.
3.5.4. FastDump
FastDump é uma ferramenta gratuita especialmente voltada para o estudo de malwares
que auxilia o investigador a entender o funcionamento de executáveis. A ferramenta gera um
arquivo binário contendo a imagem da memória RAM, que vai depender do tamanho da
memória presente no sistema. Suporta apenas aquisição em sistemas 32 bits de até 4GB de
memória RAM, não suportando o Windows Vista, Windows 2003 e Windows 2008. Possui
uma versão comercial, o FDPro, que suporta todas as versões de Windows, 32 e 64 bits, em
sistemas com até 64BG de RAM.
3.5.5. KntDD
KntDD é uma ferramenta de aquisição de memória que faz parte da suíte KntTools.
Foi desenvolvido visando driblar a restrição de acesso à memória física (\\.\PhysicalMemory)
em modo usuário existente nas versões mais recentes do sistema operacional Windows.
Através dessa ferramenta é possível adquirir imagens em um disco removível local ou através
da rede, nos sistemas com Windows 2000 ou versões posteriores. Ela também permite
converter imagens em formato “raw” para o formato de crash dumps Microsoft, de forma que
os dados possam ser analisados utilizando o “Microsoft Debugging Tools”.
Essa ferramenta é disponibilizada apenas para autoridades da lei ou profissionais de
segurança.
36
3.5.6. MoonSols Windows Memory Toolkit
MoonSols Windows Memory Toolkit é um conjunto de ferramentas voltadas para
forense de memória em Windows. Os utilitários Win32dd e Win64dd, considerados como um
dos melhores utilitários para dump de memória pelos profissionais da área, fazem parte do
grupo de ferramentas disponibilizados por esta suíte, possibilitando a aquisição de memória
em formato raw, crash dumps Microsoft, arquivos de hibernação do Windows, e imagens de
VMWare. Além dos utilitários para realização de dump da memória, também são
disponibilizados outros utilitários para conversão da imagem adquirida para diversos formatos
distintos de dump.
Uma funcionalidade muito importante é que a ferramenta torna possível a conversão
de todos os dumps de memória física no Windows para o mesmo formato dos crash dumps
Microsoft, que podem então ser analisados com a ferramenta Microsoft Windows Debugger
(WinDbg), uma ferramenta importante para a análise de memória RAM.
Possui duas versões: Community Version e Professional Version, sendo a primeira
gratuita e a segunda comercial, contemplando algumas funcionalidades adicionais como o uso
dos utilitários Win32dd e Win64dd em scripts/batchs.
3.5.7. Nigilant32
Nigilant32 é uma ferramenta desenvolvida pela Agile Risk Management que permite
ao investigador visualizar a imagem de um disco rígido ou da memória e obter informações
sobre os processos que estão em execução e das portas que estão abertas no sistema. Essa
ferramenta causa alterações relativamente pequenas no sistema, pois utiliza menos de 1MB
(megabyte) da memória quando é carregado, minimizando assim o impacto causado pelo
processo de aquisição. A versão disponibilizada atualmente é beta, e o software pode ser
baixado e utilizado gratuitamente.
3.5.8. FTK Imager
FTK Imager é uma ferramenta gratuita disponibilizada pela Access Data para
aquisição de imagens forenses. A ferramenta permite criar, principalmente, imagens de discos
37
rígidos em vários formatos, assim como a captura de arquivos bloqueados pelo sistema. Mas
também possibilita a aquisição de dumps da memória RAM e análise de imagens forenses.
3.5.9. Winen.exe
Winen.exe é uma ferramenta de aquisição de memória RAM que faz parte do software
de análise forense comercial Encase Forensic, considerado padrão e amplamente adotado no
mercado. O executável pode ser rodado através de linha de comando ou arquivo de
configuração. É possível executá-lo através de um dispositivo USB conectado ao sistema alvo
e o conteúdo coletado da RAM é salvo em um arquivo com extensão .E01. Existem as versões
32-bits e 64-bits.
3.6. FERRAMENTAS PARA ANÁLISE FORENSE DA MEMÓRIA
Após a obtenção da imagem da memória RAM, o investigador deve providenciar sua
replicação, gerando cópias e, em seguida, proceder com a análise de seu conteúdo, com a
finalidade de obter evidências sobre o incidente de segurança que ocorreu no sistema.
Segundo (CARVEY, 2007), até 2005, o procedimento padrão para a análise envolvia a
execução de ferramentas simples, como “strings” e “grep”, para realizar buscas por endereços
de correio eletrônico, endereços IP, URLs, dentre outras informações. Apesar de ser uma
abordagem que fornece resultados importantes, não provê informações sobre o contexto em
que determinada informação foi encontrada. Assim, não permite estabelecer, por exemplo, a
que processo está relacionado determinado IP ou string que foi encontrada na memória.
Desde então, esforços foram feitos para tentar adicionar contexto às informações
encontradas na RAM, localizando processos específicos e as páginas da memória que estes
utilizam. Foram desenvolvidas ferramentas que podem ser utilizadas para analisar os dumps e,
como resultado, devolver informações detalhadas sobre processos e outras estruturas.
Uma das primeiras coisas que um perito faz durante a atividade de análise é procurar
pelos processos que estavam em execução quando a imagem foi capturada. Em sistemas
operacionais Windows existe uma estrutura básica que contém todas as informações a
respeito de um processo específico; uma lista contendo os vínculos estabelecidos entre essas
38
estruturas é utilizada para manter controle de todos os processos em execução (AMARI,
2009). Conforme já mencionado anteriormente, a estrutura EPROCESS é que representa um
processo no sistema operacional Windows. Essa estrutura varia entre as diferentes versões do
Windows, inclusive entre service packs da mesma versão. Assim, é importante conhecer a
versão do sistema operacional em que foi obtida a imagem da memória, para que se escolha
adequadamente as ferramentas que serão utilizadas na análise. A ferramenta “osid.pl”, um
script em Perl escrito por Harlan Carvey, autor do livro Windows Forensics Analysis, faz o
reconhecimento de qual é a versão e service pack do Windows que estão em execução no
sistema em que o dump foi obtido.
Existem atualmente diversas ferramentas para realizar perícia forense de memória
volátil
em
sistemas
operacionais
Windows.
Nessa
seção,
algumas
ferramentas
disponibilizadas gratuitamente serão descritas e analisadas. Existem também ferramentas
comerciais que são padrão no mercado, como os softwares Encase Enterprise, F-Response e
HBGary Responder; no entanto o foco desta seção estará voltado para ferramentas gratuitas.
Não se pretende aqui manter uma lista de todas as ferramentas, mas apenas descrever algumas
das mais utilizadas pelos profissionais da área.
É importante que o perito conheça bem o comportamento das ferramentas utilizadas,
testando-as em imagens de memória conhecidas antes de adotá-las em um processo de
investigação formal, pois assim, é possível conhecer bem suas saídas, o formato em que as
informações serão apresentadas e evitar a ocorrência de falsos positivos ou falsos negativos
por uso indevido ou desconhecimento acerca do comportamento do software. Ao testar as
ferramentas, também é interessante realizar comparativos entre ferramentas similares, para
que o perito verifique se informações importantes estão faltando ou se existe o retorno de
falsos positivos.
Caso alguma ferramenta apresente inconsistências ou demonstre não
funcionar adequadamente em alguma situação, é possível que não seja aceita como válida
para gerar provas em processos judiciais, tornando todo o processo investigativo inválido.
Não foi possível encontrar muitas informações e documentação disponível sobre as
ferramentas que serão apresentadas. Os dados são baseados, principalmente, no artigo
publicado por (AMARI, 2009), nos sites oficiais destas ferramentas e na instalação das
mesmas para testes em laboratório. Deve-se tomar o cuidado de não utilizá-las diretamente no
sistema sob análise, pois caso ele tenha sido comprometido, pode retornar falsos resultados,
escondendo informações sobre as ações do invasor. O ideal é executar as ferramentas através
de um CD, DVD ou dispositivo USB para mitigar esse risco.
39
3.6.1. Ferramentas básicas
Algumas ferramentas que não foram criadas com a finalidade específica de se realizar
análise forense também podem ser utilizadas para realização da perícia, de forma a contribuir
com informações significativas, sendo geralmente utilizadas para verificar o estado do
sistema. Dentre elas podemos citar o WinDbg, que faz parte do Debugging Tools for
Windows, uma ferramenta para depuração de erros em dispositivos, aplicativos e serviços nos
sistemas operacionais Windows e que pode ser utilizada inclusive para analisar crash dumps.
Possui interface gráfica e não precisa ser instalado na máquina sob análise. Outras
ferramentas úteis são os comandos tasklist - para exibir os processos em execução e suas
informações, strings – para buscar strings em dumps de memória, ipconfig – para fornecer
informações sobre as interfaces de rede e sua configuração e netstat – para fornecer
informações sobre conexões de rede ativas.
3.6.2. Volatility Framework
O framework Volatility é uma coleção de ferramentas implementadas em Python sob
licença GNU GPL para extração de artefatos digitais de amostras de memória volátil (RAM).
As técnicas de extração são executadas de forma independente do sistema que está sendo
investigado, oferecendo visibilidade para o estado de execução do sistema. Atualmente o
framework oferece as seguintes funcionalidades para extração de dados na memória:
• Exibe a data e hora da imagem
• Processos em execução, sockets abertos e conexões de rede ativas
• Apresenta as DLLs carregadas para cada processo
• Exibe os arquivos abertos para cada processo
• Identificadores de registro abertos para cada processo
• Espaço de memória endereçável de um processo
• Módulos do kernel do sistema operacional
• Informações sobre o Virtual Address Descriptor
• Extração de executáveis a partir de uma imagem da memória
40
A ferramenta suporta uma variedade de formatos de dump, efetua a conversão
automática entre alguns formatos e pode ser utilizada em qualquer plataforma que suporte
Python. Sua instalação e utilização são simples, bastando descompactar o pacote fornecido
pela Volatility Systems em um sistema em que o Python já tenha sido instalado.
Seguem abaixo exemplos da utilização de alguns comandos importantes do Volatility
em uma imagem de memória capturada utilizando a ferramenta Win32DD.
Primeiramente, o quadro 3.1 mostra a execução do comando “python volatility”. Essa
opção exibe todos os comandos disponíveis para execução.
C:\Volatility>python volatility
Volatile Systems Volatility Framework v1.3
Copyright (C) 2007,2008 Volatile Systems
Copyright (C) 2007 Komoku, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
usage: volatility cmd [cmd_opts]
Run command cmd with options cmd_opts
For help on a specific command, run 'volatility cmd --help'
Supported Internel Commands:
connections
Print list of open connections
connscan
Scan for connection objects
connscan2
Scan for connection objects (New)
datetime
Get date/time information for image
dlllist
Print list of loaded dlls for each process
dmp2raw
Convert a crash dump to a raw dump
dmpchk
Dump crash dump information
files
Print list of open files for each process
hibinfo
Convert hibernation file to linear raw image
ident
Identify image properties
memdmp
Dump the addressable memory for a process
memmap
Print the memory map
modscan
Scan for modules
modscan2
Scan for module objects (New)
modules
Print list of loaded modules
procdump
Dump a process to an executable sample
pslist
Print list of running processes
psscan
Scan for EPROCESS objects
psscan2
Scan for process objects (New)
raw2dmp
Convert a raw dump to a crash dump
regobjkeys
Print list of open regkeys for each process
sockets
Print list of open sockets
sockscan
Scan for socket objects
sockscan2
Scan for socket objects (New)
strings
Match physical offsets to virtual addresses (may
take a while, VERY verbose)
thrdscan
Scan for ETHREAD objects
thrdscan2
Scan for thread objects (New)
vaddump
Dump the Vad sections to files
vadinfo
Dump the VAD info
vadwalk
Walk the vad tree
Supported Plugin Commands:
memmap_ex_2
Print the memory map
41
pslist_ex_1
pslist_ex_3
usrdmp_ex_2
Print list running processes
Print list running processes
Dump the address space for a process
Example: volatility pslist -f /path/to/my/file
Quadro 3.1 - Uso do comando volatility
O quadro 3.2 mostra o uso do comando ident, que pode ser utilizado para identificar a
data e hora em que a imagem foi coletada, assim como prover informações sobre o sistema
operacional no qual foi gerado o dump:
C:\Volatility>python volatility ident –f C:\dump_tcc_anapaula.dmp
Image Name: C:\dump_tcc_anapaula.dmp
Image Type: Service Pack 1
VM Type: nopae
DTB: 0x39000
Datetime: Fri May 13 14:24:36 2011
Quadro 3.2 – Uso do comando ident da ferramenta Volatility
Pode-se utilizar a opção --help com qualquer comando para obter ajuda, conforme
mostra o quadro 3.3.
C:\Volatility>python volatility ident –-help
Usage: ident [options] (see --help)
Options:
-h, --help
show this help message and exit
-f FILENAME, --file=FILENAME
(required) XP SP2 Image file
-b BASE, --base=BASE (optional, otherwise best guess is made) Physical
offset (in hex) of directory table base
-t TYPE, --type=TYPE (optional, default="auto") Identify the image type
(pae, nopae, auto)
Quadro 3.3 - Utilizando a opção help da ferramenta Volatility
Para listar os processos que estavam em execução no momento em que foi gerado o
dump, pode-se utilizar o comando pslist. Como pode ser visto no quadro 3.4, a saída vai
conter o nome do processo, seu identificador (Pid) e identificador do processo-pai (PPid),
além do horário em que ele foi iniciado e outras informações úteis.
42
C:\Volatility>python volatility pslist –f C:\dump_tcc_anapaula.dmp
Name
System
smss.exe
csrss.exe
winlogon.exe
services.exe
lsass.exe
svchost.exe
svchost.exe
svchost.exe
svchost.exe
spoolsv.exe
explorer.exe
NeroCheck_.exe
jusched.exe
ctfmon.exe
msmsgs.exe
jqs.exe
wmiapsrv.exe
swriter.exe
soffice.exe
soffice.bin
wuauclt.exe
cmd.exe
IEXPLORE.EXE
javaws.exe
javaw.exe
win32dd.exe
Pid
4
356
540
600
648
660
844
944
1200
1232
1348
1600
1740
1788
1796
1808
1932
404
1572
1580
1588
2016
416
1048
512
784
1440
PPid
0
4
356
356
600
600
648
648
648
648
648
1500
1600
1600
1600
1600
648
648
1600
1572
1580
944
944
1600
1788
512
416
Thds
46
3
11
21
23
25
10
69
7
15
12
14
7
1
1
13
5
4
1
1
5
6
1
25
1
14
1
Hnds
256
21
417
445
289
308
229
1013
67
136
113
394
31
95
53
269
195
125
19
19
154
94
20
626
0
0
23
Time
Thu Jan
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
Sun May
01
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
22
00:00:00
16:53:25
16:53:26
16:53:27
16:53:29
16:53:29
16:53:30
16:53:30
16:53:33
16:53:33
16:53:34
16:53:35
16:53:36
16:53:36
16:53:36
16:53:36
16:53:41
16:53:48
16:54:04
16:54:06
16:54:06
16:54:57
16:55:14
16:57:09
16:58:46
16:58:51
16:58:54
1970
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
2011
Quadro 3.4– Uso do comando pslist da ferramenta Volatility
A opção connscan fornece informações sobre as conexões de rede que estavam ativas
no momento em que os dados foram coletados da memória. Já a opção sockets exibe os
sockets abertos no momento em que foi gerado o dump. O comando files exibe os arquivos
abertos para cada processo. É possível especificar o número do processo na linha de comando,
para exibir apenas os arquivos abertos por um processo específico, conforme exemplifica o
quadro 3.5.
C:\Volatility>python volatility files –p 1740 –f C:\dump_tcc_anapaula.dmp
Pid: 1740
File
\Documents and Settings\anapaula
File
\WINDOWS\WinSxS\x86_Microsoft.Windows.CommonControls_6595b64144ccf1df_6.0.10.0_x-ww_f7fb5805
File
\WINDOWS\SYSTEM16
Quadro 3.5 – Uso do comando files da ferramenta Volatility
O comando dlllist exibe uma lista contendo as DLLs carregadas para cada processo, e
o comando regobjkeys exibe uma lista contendo as chaves de registro abertas por cada
processo, o que pode ser visualizado nos quadros 3.6 e 3.7 respectivamente.
43
C:\Volatility>python volatility dlllist –p 1740 –f C:\dump_tcc_anapaula.dmp
NeroCheck_.exe pid: 1740
Command line : "C:\WINDOWS\System32\NeroCheck_.exe"
Service Pack 1
Base
Size
Path
0x400000
0x33000
C:\WINDOWS\System32\NeroCheck_.exe
0x77f50000
0xab000
C:\WINDOWS\System32\ntdll.dll
0x77e50000
0xf0000
C:\WINDOWS\system32\kernel32.dll
0x77db0000
0x9d000
C:\WINDOWS\system32\ADVAPI32.dll
0x78000000
0x86000
C:\WINDOWS\system32\RPCRT4.dll
0x77c50000
0x40000
C:\WINDOWS\system32\GDI32.dll
0x77d20000
0x8c000
C:\WINDOWS\system32\USER32.dll
0x761d0000
0x99000
C:\WINDOWS\system32\WININET.dll
0x77bf0000
0x53000
C:\WINDOWS\system32\msvcrt.dll
0x772b0000
0x64000
C:\WINDOWS\system32\SHLWAPI.dll
0x76290000
0x8c000
C:\WINDOWS\system32\CRYPT32.dll
0x76270000
0xf000
C:\WINDOWS\system32\MSASN1.dll
0x77100000
0x8b000
C:\WINDOWS\system32\OLEAUT32.dll
0x440000
0x121000
C:\WINDOWS\system32\OLE32.DLL
0x78090000
0xe4000
C:\WINDOWS\WinSxS\x86_Microsoft.Windows.CommonControls_6595b64144ccf1df_6.0.10.0_x-ww_f7fb5805\comctl32.dll
Quadro 3.6 – Uso do comando dlllist da ferramenta Volatility
C:\Volatility>python volatility regobjkeys –p 1740 –f C:\dump_tcc_anapaula.dmp
Pid: 1740
\REGISTRY\MACHINE
\REGISTRY\USER\S-1-5-21-1482476501-1606980848-13430240911003\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\INTERNET SETTINGS
\REGISTRY\USER\S-1-5-21-1482476501-1606980848-1343024091-1003
Quadro 3.7 – Uso do comando regobjkeys da ferramenta Volatility
Também é possível, através do comando procdump, extrair executáveis a partir do
dump de memória, possibilitando ter acesso ao código que estava sendo executado na
máquina e, assim conhecer melhor seu comportamento.
C:\Volatility>python volatility procdump –p 1740 –f C:\dump_tcc_anapaula.dmp
************************************************************************
Dumping NeroCheck_.exe, pid: 1740
output: executable.1740.exe
Memory Not Accessible: Virtual Address: 0x405000 File Offset: 0x5000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x409000 File Offset: 0x9000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x40a000 File Offset: 0xa000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x40b000 File Offset: 0xb000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x40c000 File Offset: 0xc000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x40d000 File Offset: 0xd000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x40e000 File Offset: 0xe000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x40f000 File Offset: 0xf000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x410000 File Offset: 0x10000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x411000 File Offset: 0x11000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x412000 File Offset: 0x12000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x413000 File Offset: 0x13000 Size: 0x1000
Memory Not Accessible: Virtual Address: 0x41f000 File Offset: 0x1f000 Size: 0x1000
Quadro 3.8 – Uso do comando procdump da ferramenta Volatility
44
No quadro 3.8, foi possível observar a geração do executável “executable.1740.exe” e
a ocorrência de mensagens informativas do tipo “Memory Not Accesible”, após utilização do
comando procdump. Isso ocorre porque nem todos os endereços virtuais da memória estão
acessíveis na imagem, pois podem ter sidos, por exemplo, paginados para o disco. Assim,
essas mensagens fornecem um log de auditoria para que se possa determinar quais partes do
executável gerado foram recuperadas com êxito.
Para executar o Volatility é necessário obter previamente o dump da memória,
utilizando qualquer ferramenta de dump, como as que foram citadas na seção 3.5 deste
capítulo.
3.6.3. Mandiant Memoryze
Memoryze é um software gratuito, disponibilizado pela empresa Mandiant
especialmente para a realização de forense de memória. Pode ser utilizado para coletar dumps,
assim como para analisar o conteúdo da memória, tanto em sistemas que estão em execução
quanto em imagens de memória. Caso a análise seja realizada em sistemas que estão em
execução, o software é capaz de realizar a análise do arquivo de paginação também. A
ferramenta pode ser executada a partir de uma estação forense, na máquina que está sob
análise ou através de dispositivos USB. Possui as seguintes funcionalidades:
• Captura a imagem de toda a memória do sistema, de forma independente de
chamadas de API.
• Captura o espaço endereçável de um processo no disco, incluindo DLLs,
executáveis e pilhas.
• Captura a imagem de um driver específico (ou de todos) carregado na memória
e o identifica.
• Enumera os processos em execução, incluindo aqueles que possam estar
escondidos por rootkits.
• Identifica os módulos do kernel carregados na memória através do
rastreamento das estruturas e listas de vínculos mantidas pelo sistema
operacional
45
• Identifica manipulações envolvendo as chamadas de sistema e tabelas de
descritores, muitas vezes utilizados por rootkits.
O Memoryze trabalha com dois componentes: o próprio Memoryze e o Audit Viewer. O
primeiro é responsável por fazer a extração e análise do conteúdo da memória, enquanto o
segundo, opcional, é responsável por apresentar o resultado XML gerado pelo Memoryze em
um formato mais amigável. Para utilizar o AuditViewer, é preciso instalar o Python no
sistema.
Após a instalação do Memoryze é possível verificar a existência de vários scripts
XML, cada um com função distinta:
• AcquireDriver.Batch.xml
• AcquireMemory.Batch.xml
• AcquireProcessMemory.Batch.xml
• DriverAuditModuleList.Batch.xml
• DriverAuditSignature.Batch.xml
• HookAudit.Batch.xml
• ProcessAuditMemory.Batch.xml
Além dos scripts XML, também são encontrados os seguintes arquivos batch:
• MemoryDD.bat - obtém a imagem da memória física
• ProcessDD.bat - obtém a imagem do espaço de endereço do processo
• DriverDD.bat - obtém a imagem de um driver específico
• Process.bat - enumera todas as informações sobre um processo específico,
como memória virtual, portas de rede, handle e strings
• HookDetection.bat - procura por hooks (ganchos) dentro do sistema
operacional
• DriverSearch.bat - encontra drivers na imagem de memória analisada
• DriverWalkList.bat – enumera todos os módulos e drivers em uma lista de
vínculos (linked list).
46
Existem três formas de se utilizar o Memoryze: a primeira consiste em utilizar os
arquivos XML nativos à ferramenta, o que requer a edição dos arquivos com extensão
“*.Batch.xml” citados acima, a fim de configurá-los para realizar as atividades desejadas. A
segunda forma é utilizar os scripts batch (extensão “.bat”) fornecidos. Esses scripts geram o
XML adequado para executar a tarefa desejada, de acordo com as opções fornecidas na linha
de comando ao executá-los. A terceira forma é utilizar Audit Viewer, que possui uma interface
amigável tornando a análise mais rápida e intuitiva. Após sua configuração, devem ser
escolhidas as tarefas a serem desempenhadas pelo software.
A seguir, as figuras 3.2 e 3.3 exemplificam o uso do Audit Viewer. Do lado esquerdo,
aparecem os processos encontrados na memória e algumas informações extras sobre cada um,
como Pid, PPid, data em que foi iniciado e o caminho do executável. Do lado direito da tela
existem diversas abas que podem exibir informações específicas para determinado processo
que tenha sido selecionado: arquivos abertos, DLLs carregadas, chaves de registro, dentre
outros.
Figura 3.2 – Tela do visualizador Audit Viewer – Aba Files: análise forense da memória
efetuada com o software Memoryze.
47
Figura 3.3– Tela do visualizador Audit Viewer – Aba Registry Keys: análise forense da
memória efetuada com o software Memoryze.
3.6.4. Windows Memory Forensic Toolkit
O Windows Memory Forensic Toolkit (WMFT) é uma coleção de utilitários destinada
para uso forense. Pode ser utilizado para realizar análise forense em imagens de memória
capturadas a partir de sistemas operacionais Windows 2000, Windows 2003 e Windows XP.
Existem duas versões da ferramenta, uma para Linux e outra para Windows. A versão
desenvolvida para Windows foi escrita em C # para a plataforma .NET e possui
funcionalidades adicionais com relação à versão criada para Linux, como a possibilidade de
detectar objetos escondidos.
Para configurar e utilizar o WMFT é necessário que o investigador realize um trabalho
manual previamente, a fim de localizar os símbolos que apontam para importantes objetos e
estruturas do kernel na memória. As instruções para realização desta atividade prévia foram
publicadas no documento “An introduction to Windows memory forensics”, por Mariusz
Burdach, desenvolvedor da ferramenta. Após localizar o endereço destes objetos na memória,
é possível alimentar o WMFT com esses valores e proceder com a análise através das
48
estruturas de dados, a fim de recuperar processos e demais objetos armazenados na memória
RAM.
Como o WMFT utiliza as próprias estruturas de dados para percorrer a memória e
extrair as informações relevantes, é uma ferramenta vulnerável a ataques mais avançados, nos
quais o atacante esconde os processos e outros objetos deixando-os fora das estruturas de
dados mantidas pelo sistema operacional, que são utilizadas para acompanhamento desses
dados.
Além das ferramentas gratuitas aqui expostas, podemos citar outras, que também são
importantes e comumente utilizadas por profissionais da área: Memparser, FATKit, PTFinder
e VADTools, dentre outras.
49
50
4. ESTUDO DE CASO
Nesse capítulo será realizado um estudo de caso para análise forense de malware em
sistema operacional Windows. Pretende-se mostrar que a análise do conteúdo da memória
volátil (RAM) pode ser muito importante para um processo de investigação forense. Objetivase, também, mostrar como podem ser utilizadas ferramentas de dump e análise de imagens de
memória apresentadas nesse trabalho, com o intuito de obter evidências importantes para um
processo de análise forense.
4.1. CENÁRIO
Para possibilitar a realização deste estudo de caso, foi montado um ambiente de
laboratório, no qual se instalou o sistema operacional Windows XP SP3 em uma máquina
virtual contendo 1GB (gigabytes) de memória, criada com o software de virtualização
VMWare Player.
• Configurações do equipamento
Processador: Intel® Core™ 2 Duo CPU T5670 @ 1.80 GHz
Memória: 3,00 GB
Tipo de sistema: Sistema operacional de 32 bits
• Configurações da máquina virtual
Software de virtualização: VMWare Player 3.1.4
Sistema operacional: Windows XP Service Pack 3
Memória: 1,00 GB
Nesse ambiente foi instalado um banker, código malicioso criado para roubo de
credenciais de acesso a serviços de Internet Banking. Foi utilizado um banker já conhecido
pelas instituições bancárias e pelas principais ferramentas de antivírus, apenas para fins
didáticos. Adicionalmente, com a finalidade de comprovar que se trata de código malicioso, o
arquivo “convite.com”, que é baixado e executado pelo banker, foi submetido para análise no
site Virus Total (http://virustotal.com.br), que provê o serviço de análise automatizada de
51
arquivos e URLs suspeitas, facilitando a detecção de diversos tipos de malwares. O resultado,
corroborando que se trata de código malicioso, pode ser consultado no Anexo II deste
trabalho.
As ferramentas de análise forense utilizadas para este estudo de caso também foram
instaladas e configuradas no ambiente de laboratório, visando simplificar a extração e análise
das informações obtidas da memória.
4.2. REALIZAÇÃO DOS TESTES
Primeiramente, foram instaladas as ferramentas Moonsols Windows Memory Toolkit
1.0 Community Edition e Volatility Framework 1.3 no ambiente de laboratório, para
realização do dump e análise da memória, respectivamente. Também foi necessário instalar o
Python v2.7.1 no sistema para utilização do software Volatility.
Em seguida, foi acessada a URL que faz o download do código malicioso e solicita ao
usuário a sua execução (http://www.djwirya.com/news/css/gif.php?=werhj34r839349rhj).
Normalmente é utilizado ataque de engenharia social, com apelos para convencer o usuário a
executar o arquivo em seu computador, como uma mensagem de email com fotos de artistas
ou até mesmo solicitando a instalação de plugins de segurança para acesso ao Internet
Banking.
Ao acessar o link, o usuário é direcionado a realizar o download do arquivo
“convite.com”, como pode ser visto na figura 4.1.
Figura 4.1 – Download do banker
52
Quando o usuário executa o arquivo, é exibida uma mensagem de erro,
conforme mostra a figura 4.2, no entanto o banker já executou suas atividades no computador.
Figura 4.2 – Mensagem de erro ao executar o banker
Para iniciar a análise, foi realizado um dump de memória utilizando a ferramenta
win32dd.exe, já apresentada neste trabalho. O quadro 4.1 mostra os procedimentos e comando
utilizados para coleta da imagem. Como pode ser observado, foi criada a imagem
“dump_monografia_case.dmp” com tamanho de 1GB (gigabytes), ou seja, com o mesmo
tamanho da memória física do sistema.
C:\Moonsols>win32dd.exe /f dump_forense_malware.dmp
C:\Moonsols>win32dd.exe /f dump_forense_malware.dmp
win32dd - 1.3.1.20100417 - (Community Edition)
Kernel land physical memory acquisition
Copyright (C) 2007 - 2010, Matthieu Suiche <http://www.msuiche.net>
Copyright (C) 2009 - 2010, MoonSols <http://www.moonsols.com>
Name
---File type:
Acquisition method:
Content:
Value
----Raw memory dump file
PFN Mapping
Memory manager physical memory block
Destination path:
dump_forense_malware.dmp
O.S. Version:
(build 2600)
Computer name:
Microsoft Windows XP Professional Service Pack 3
ANAPAULA-XP
Physical memory in use:
Physical memory size:
Physical memory available:
38%
1048048 Kb (
643664 Kb (
1023 Mb)
628 Mb)
Paging file size:
Paging file available:
2519744 Kb (
2034396 Kb (
2460 Mb)
1986 Mb)
Virtual memory size:
Virtual memory available:
2097024 Kb (
2083280 Kb (
2047 Mb)
2034 Mb)
Extented memory available:
0 Kb (
0 Mb)
Physical page size:
Minimum physical address:
Maximum physical address:
4096 bytes
0x0000000000001000
0x000000003FFFF000
53
Address space size:
1073741824 bytes (1048576 Kb)
--> Are you sure you want to continue? [y/n] y
Acquisition started at:
[31/5/2011 (DD/MM/YYYY) 16:0:58 (UTC)]
Processing....Done.
Acquisition finished at:
Time elapsed:
[2011-05-31 (YYYY-MM-DD) 16:02:02 (UTC)]
1:04 minutes:seconds (64 secs)
Created file size:
NtStatus
Total of
Total of
Total of
1073741824 bytes (
(troubleshooting):
written pages:
inacessible pages:
accessible pages:
1024 Mb)
0x00000000
262029
0
262029
Physical memory in use:
Physical memory size:
Physical memory available:
38%
1048048 Kb (
646392 Kb (
1023 Mb)
631 Mb)
Paging file size:
Paging file available:
2519744 Kb (
2034420 Kb (
2460 Mb)
1986 Mb)
Virtual memory size:
Virtual memory available:
2097024 Kb (
2083280 Kb (
2047 Mb)
2034 Mb)
Extented memory available:
0 Kb (
0 Mb)
Physical page size:
Minimum physical address:
Maximum physical address:
4096 bytes
0x0000000000001000
0x000000003FFFF000
Address space size:
1073741824 bytes (1048576 Kb)
Quadro 4.1 – Aquisição do dump de memória utilizando a ferramenta Win32dd
Após a obtenção da imagem da memória, foi utilizada a ferramenta Volatility para
analisar o conteúdo do dump. Utilizando a opção pslist, foi gerada uma relação dos processos
que puderam ser identificados através da memória. O quadro 4.2 exibe apenas os processos
suspeitos e que são de interesse para realização desta análise. Como o comportamento do
banker que está sendo analisado já é conhecido, foi possível reconhecer de imediato os
processos a ele relacionados. Normalmente não se conhece o comportamento do malware
previamente, assim é importante que o perito conheça bem os processos do sistema que está
analisando.
Name
convite.com
avguix.exe
Builder.exe
Pid
3084
3408
3508
PPid
4072
3376
3408
Thds
1
2
1
Hnds
107
85
89
Time
Tue May 31 03:10:53 2011
Tue May 31 03:12:41 2011
Tue May 31 03:12:45 2011
Quadro 4.2 – Processos criados pelo banker
54
As opções connscan e sockets do Volatility também poderiam ser bastante úteis para
identificação de endereços IP, portas e protocolos em uso pelos programas, mas nesse estudo
de caso não foi possível obter essas informações através do dump de memória.
É especialmente importante mapear quais arquivos, chaves de registro e DLLs estão
sendo utilizados ou foram criados e alterados pelo banker. Isso é possível através das opções
files, dlllist e regobjkeys do volatility, como mostram os quadros 4.3, 4.4 e 4.5 para o processo
“avguix.exe”, cujo PID é 3408 e foi executado pelo banker.
Pid: 3408
File
\DOCUME~1\anapaula\CONFIG~1\Temp\IXP000.TMP
File
\WINDOWS\WinSxS\x86_Microsoft.Windows.CommonControls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202
File
\WINDOWS\WinSxS\x86_Microsoft.Windows.CommonControls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202
File
\WINDOWS\WinSxS\x86_Microsoft.Windows.CommonControls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202
Quadro 4.3 – Arquivos criados/acessados pelo processo “avguix.exe”
avguix.exe pid: 3408
Command line : C:\DOCUME~1\anapaula\CONFIG~1\Temp\IXP000.TMP\avguix.exe
Service Pack 3
Base
Size
Path
0x400000
0x819000
C:\DOCUME~1\anapaula\CONFIG~1\Temp\IXP000.TMP\avguix.exe
0x7c900000
0xb6000
C:\WINDOWS\system32\ntdll.dll
0x7c800000
0x100000
C:\WINDOWS\system32\kernel32.dll
0x7e360000
0x91000
C:\WINDOWS\system32\user32.dll
0x77e50000
0x49000
C:\WINDOWS\system32\GDI32.dll
0x77f50000
0xab000
C:\WINDOWS\system32\advapi32.dll
0x77db0000
0x93000
C:\WINDOWS\system32\RPCRT4.dll
0x77f20000
0x11000
C:\WINDOWS\system32\Secur32.dll
0x77100000
0x8b000
C:\WINDOWS\system32\oleaut32.dll
0x77bf0000
0x58000
C:\WINDOWS\system32\msvcrt.dll
0x774c0000
0x13e000
C:\WINDOWS\system32\ole32.dll
0x77be0000
0x8000
C:\WINDOWS\system32\version.dll
0x5d510000
0x9a000
C:\WINDOWS\system32\comctl32.dll
0x3fa50000
0xe6000
C:\WINDOWS\system32\wininet.dll
0x77ea0000
0x76000
C:\WINDOWS\system32\SHLWAPI.dll
0x340000
0x9000
C:\WINDOWS\system32\Normaliz.dll
0x43f90000
0x133000
C:\WINDOWS\system32\urlmon.dll
0x400f0000
0x1e9000
C:\WINDOWS\system32\iertutil.dll
0x76380000
0x48000
C:\WINDOWS\system32\comdlg32.dll
0x7c9c0000
0x81e000
C:\WINDOWS\system32\SHELL32.dll
0x76760000
0x9000
C:\WINDOWS\system32\SHFolder.dll
0x76360000
0x1d000
C:\WINDOWS\system32\IMM32.DLL
0x773b0000
0x103000
C:\WINDOWS\WinSxS\x86_Microsoft.Windows.CommonControls_6595b64144ccf1df_6.0.2600.6028_x-ww_61e65202\comctl32.dll
0x5b1c0000
0x38000
C:\WINDOWS\system32\uxtheme.dll
0x746e0000
0x4c000
C:\WINDOWS\system32\MSCTF.dll
0x75290000
0x2e000
C:\WINDOWS\system32\msctfime.ime
0x5f250000
0x17000
C:\WINDOWS\system32\olepro32.dll
0x71a70000
0x17000
C:\WINDOWS\system32\WS2_32.DLL
0x71a60000
0x8000
C:\WINDOWS\system32\WS2HELP.dll
0x71a10000
0x40000
C:\WINDOWS\system32\mswsock.dll
0x60b30000
0x58000
C:\WINDOWS\system32\hnetcfg.dll
0x71a50000
0x8000
C:\WINDOWS\System32\wshtcpip.dll
55
0x76f00000
0x76d40000
0x76f90000
0x76f40000
0x76fa0000
0x77b20000
0x27000
0x19000
0x8000
0x2d000
0x6000
0x22000
C:\WINDOWS\system32\DNSAPI.dll
C:\WINDOWS\system32\iphlpapi.dll
C:\WINDOWS\System32\winrnr.dll
C:\WINDOWS\system32\WLDAP32.dll
C:\WINDOWS\system32\rasadhlp.dll
C:\WINDOWS\system32\Apphelp.dll
Quadro 4.4 – Bibliotecas utilizadas/carregadas pelo processo “avguix.exe”
Pid: 3408
\REGISTRY\MACHINE
\REGISTRY\USER\S-1-5-21-1644491937-1592454029-839522115-1005
\REGISTRY\USER\S-1-5-21-1644491937-1592454029-839522115-1005_CLASSES
\REGISTRY\MACHINE\SOFTWARE\MICROSOFT\INTERNET
EXPLORER\MAIN\FEATURECONTROL\FEATURE_PROTOCOL_LOCKDOWN
\REGISTRY\USER\S-1-5-21-1644491937-1592454029-8395221151005\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\INTERNET SETTINGS
\REGISTRY\MACHINE\SYSTEM\CONTROLSET001\SERVICES\WINSOCK2\PARAMETERS\PROTOCOL_CATALOG9
\REGISTRY\MACHINE\SYSTEM\CONTROLSET001\SERVICES\WINSOCK2\PARAMETERS\NAMESPACE_CATALOG5
\REGISTRY\MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\EXPLORER\ADVANCED
\REGISTRY\MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\POLICIES\SYSTEM
\REGISTRY\MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN
\REGISTRY\MACHINE\SYSTEM\CONTROLSET001\SERVICES\TCPIP\LINKAGE
\REGISTRY\MACHINE\SYSTEM\CONTROLSET001\SERVICES\TCPIP\PARAMETERS
\REGISTRY\MACHINE\SYSTEM\CONTROLSET001\SERVICES\NETBT\PARAMETERS\INTERFACES
\REGISTRY\MACHINE\SYSTEM\CONTROLSET001\SERVICES\NETBT\PARAMETERS
Quadro 4.5 – Chaves de registro em uso pelo processo “avguix.exe”
No
quadro
4.5,
é
possível
perceber
que
a
chave
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" foi alterada, possivelmente
para incluir os processos criados pelo banker na inicialização do sistema.
Para melhor avaliação dos processos sob suspeita, a fim de identificar se realmente
trata-se de código malicioso, é possível extrair o executável a partir da memória, utilizando a
opção procdump, exibido no quadro 4.6. Assim, o perito pode investigar com mais detalhes o
comportamento do malware em um ambiente controlado.
************************************************************************
Dumping avguix.exe, pid: 3408
output: executable.3408.exe
Quadro 4.6 – Extração do código executável do processo “avguix.exe”
De forma complementar, pode-se utilizar a ferramenta strings, que permite a
identificação de seqüências de dados imprimíveis em arquivos binários como o dump da
memória. Assim, direcionando a saída do comando strings para um arquivo no disco é
56
possível converter em ASCII todos os caracteres identificados no arquivo de dump da
memória, facilitando a identificação dos dados.
Dentre outras informações significantes encontradas na imagem da memória
utilizando o comando strings, podemos citar as URLs que o banker utiliza para fazer
requisições (GET) e submissões (POST), assim como o endereço de email utilizado.
• POST: http://www.ptm-deutschland.de//includes/info.php
• GET: http://www.le-galetas.com/temp/ss.com
• E-mail: [email protected]
É possível estender a análise aqui realizada utilizando o próprio Volatility, outras
ferramentas de análise de memória ou ferramentas complementares de suporte à análise
forense, como sniffers. No entanto, o que foi apresentado nesse estudo de caso pode ser
considerado como relevante, do ponto de vista de obtenção de provas para uma investigação
forense, pois pode gerar evidências consistentes e que, em eventual necessidade de atuação da
Justiça, poderiam ter valor probatório, principalmente se as informações forem
complementadas com outras obtidas em uma análise post mortem.
Foi possível demonstrar e comprovar que a análise forense baseada em conteúdo
obtido a partir de dados voláteis, capturados da memória, pode oferecer evidências essenciais
à elucidação de incidentes de segurança.
O próprio usuário baixou e instalou o código malicioso em sua máquina, o que
acontece na grande maioria das vezes, sem ter conhecimento das conseqüências de sua ação.
Assim, o banker iniciou processos mal intencionados no sistema sem que o usuário sequer
percebesse. No entanto, a aquisição dos dados da memória volátil e posterior análise
mostraram que é possível encontrar vestígios importantes, que confirmam a presença do
banker no sistema investigado, utilizando tanto ferramentas específicas para a forense de
memória, quanto ferramentas complementares, de uso geral.
57
58
5.
CONCLUSÕES
Muitos pesquisadores acreditam que a memória volátil está se tornando o alvo
preferido de exploração pelos usuários maliciosos, a fim de armazenarem dados que desejam
ocultar, ou mesmo para executar códigos maliciosos de forma a impedir engenharia reversa. E
um dos motivos para esse interesse é que poucas organizações adotam a coleta de dados da
memória volátil como procedimento para tratamento de incidentes de segurança. Atualmente
vários códigos maliciosos foram desenvolvidos para residir exclusivamente na memória, sem
necessidade de utilizar o disco rígido; assim, a perícia forense que contemple apenas o disco
rígido pode ser incompleta e ineficaz nesses casos
Diante do estudo apresentado, podem ser obtidas algumas conclusões para aplicação
no processo de perícia forense computacional, em especial à forense de memória. Através do
referencial teórico e do estudo de caso apresentado foi possível ressaltar a importância da
análise forense “in vivo” a fim de obter maior número e diversidade de evidências e foi
destacada a relevância da análise forense da memória, abordando os dados que nela podem ser
encontrados e sua importância para a perícia forense computacional, podendo ser utilizada
isoladamente ou de forma complementar à tradicional forense “post mortem”, que é
conduzida após desligamento do sistema e não contempla a aquisição de dados voláteis.
Pesquisadores e analistas já desenvolveram diversos trabalhos e técnicas para recuperação de
dados da memória, mas muito trabalho ainda pode ser desenvolvido nesta área, pois usuários
maliciosos estão sempre desenvolvendo novas técnicas de ataque e formas de se explorar
vulnerabilidades existentes nos sistemas de tecnologia.
Foram apresentadas técnicas, procedimentos e ferramentas essenciais à prática forense
computacional, assim como as fases que compõem um processo investigativo, ressaltando-se
como é importante documentar bem todos os passos envolvidos no processo e adotar
metodologias que privilegiem a integridade, autenticidade e confidencialidade dos dados. Foi
abordado que tipo de informação pode ser recuperada da memória e o quanto a extração de
dados presentes na memória pode afetar seu conteúdo e vestígios nela presentes.
Conforme apresentado, mesmo sendo uma abordagem relativamente nova, existem
diversas ferramentas disponíveis para a captura, geração de imagens e análise dos dados
contidos na memória RAM. Embora essas ferramentas estejam em constante desenvolvimento
e refinamento, é possível obter resultados valiosos com sua utilização. Porém, mesmo tendo
59
recursos para realização da análise, é necessário que o perito esteja intimamente familiarizado
com o sistema operacional com o qual está trabalhando e como é realizado o seu
gerenciamento de memória, para obter maiores ganhos. Em sistemas operacionais Windows,
em especial, até mesmo as versões de service packs distintas possuem grandes diferenças. À
medida que as ferramentas são desenvolvidas e ganham novas funcionalidades, novas técnicas
são oferecidas aos investigadores, o que juntamente com o amadurecimento dos processos e
procedimentos adotados, contribuem para investigações do tipo “Live Forensics”.
No âmbito corporativo, em especial, é importante destacar a importância da existência
de políticas de segurança da informação como medida preventiva. A política de segurança
deve ser elaborada e divulgada de forma objetiva, clara e concisa e possuir controles
eficientes, permitindo que sua utilização viabilize a padronização dos procedimentos
relacionados aos incidentes de segurança. A norma ISO/IEC 27001 fornece diretrizes para a
elaboração de um sistema de gestão de segurança da informação.
É muito importante que os sistemas de uma organização sejam bem conhecidos e
atualizados através da aplicação de correções, principalmente as que envolvem patches de
segurança, a fim de evitar a presença de vulnerabilidades. Os analistas responsáveis pela
resposta a incidentes e investigação forense da organização devem se manter atualizados e
estar familiarizados com os sistemas em utilização, a fim de fornecer resposta rápida quando
necessário. E, além disso, precisam estar conhecer bem as ferramentas de coleta de dados que
serão utilizadas, evitando ao máximo a contaminação do ambiente sob investigação. Deve ser
montado um kit de ferramentas e um ambiente de laboratório que estejam prontos para
utilização a qualquer momento, pois os incidentes e situações de emergência podem acontecer
a qualquer momento.
Também é preciso investir nas pessoas, na educação dos usuários, que normalmente
são o elo mais fraco e vulnerável do sistema como um todo. A área de segurança da
informação apoia-se em três pilares básicos: processos, pessoas e tecnologia. Assim, para
garantir a segurança de um sistema, não basta apenas manter processos com fluxos e
procedimentos bem elaborados e revisados com freqüência, nem mesmo se basear
exclusivamente na utilização de recursos e ferramentas de proteção; é preciso pensar nos
riscos advindos do envolvimento entre sistemas e pessoas.
Outro ponto importante e que deve ser de conhecimento dos peritos forenses são as
questões legais envolvidas no processo de investigação e inspeção dos sistemas.
Normalmente, lidam com dados sensíveis, então devem ser conscientizados sobre as
60
implicações de suas ações e sobre o respeito à privacidade das informações. É fundamental
que todo o processo seja transparente e pautado pela ética.
Propõe-se, para trabalhos futuros, a realização de estudos de caso utilizando as
ferramentas de análise forense da memória tanto em sistemas operacionais Linux quanto
Windows, a fim de criar comparativos sobre o comportamento das ferramentas em cada
ambiente. Além disso, a criação de frameworks agregando ferramentas voltadas
especificamente à forense de memória volátil, desenvolvimento de ferramentas mais
interativas e documentação acerca de sua utilização.
61
62
6. BIBLIOGRAFIA
[1]
IBGE; Pesquisa Nacional por Amostra de Domicílios – PNAD 2009; Instituto
Brasileiro de Geografia e Estatística.
[2]
KROLL; Global Fraud Report - Anual Edition 2010/11. Acessado em 10/01/2011
em http://www.kroll.com/library/fraud/FraudReport_English-US_Oct10.pdf
[3]
MANDIA, KEVIN; PROSISE, CHRIS; Incident Response & Computer
Forensics; Second Edition; McGraw-Hill, 2003.
[4]
CASTRO, CARLA RODRIGUES ARAÚJO DE; Crimes de Informática e seus
Aspectos Processuais; 2a. Edição, Ed. Lumen Juris, Rio de Janeiro, 2003.
[5]
FREITAS, ANDREY RODRIGUES DE; Perícia Forense Aplicada à Informática:
Ambiente Microsoft; Rio de Janeiro, Brasport, 2006.
[6]
ELEUTÉRIO, PEDRO MONTEIRO DA SILVA; MACHADO, MÁRCIO PEREIRA;
Desvendando a computação forense; São Paulo, Novatec Editora, 2011.
[7]
FARMER, DAN; VENEMA, WIETSE; Perícia Forense Computacional: Teoria e
Prática Aplicada; São Paulo, Pearson Prentice Hall, 2007.
[8]
FARMER, DAN; VENEMA, WIETSE; Murder on the Internet Express ; 1999.
Acessado
em
24/02/2011
em
http://www.neoprag.com/dcm/Murder_on_the_Internet_Express.pdf.
[9]
HUEBNER, EWA; BEM, DEREK; BEM, OSCAR; Computer Forensics – Past,
Present And Future, 2007.
[10]
BRASIL; Constituição da República Federativa do Brasil de 1988. Acessado em
24/02/2011 em http://www.planalto.gov.br/ccivil_03/constituicao/constituiçao.htm.
[11]
RODRIGUES, TONY; Blog Resposta a Incidentes e Forense Computacional; Um
pouco
sobre
leis;
2007.
Acessado
em
17/02/2011
em
http://forcomp.blogspot.com/2007/11/um-pouco-sobre-leis.html.
[12]
ROSA, DANIEL ACCIOLY; Contextualização da Prática Forense; Revista Evidência
Digital – Edição 01, Ano I, Número 01, p. 5, Jan.,Fev.,Mar. 2004. Acessado em
15/02/2011 em http://www.guiatecnico.com.br/evidenciadigital.
[13]
WARREN, G., JAY, G. Computer Forensics:
Addison-Wesley, Massachusetts, 2002.
Incident
Response
Essentials.
63
[14]
PALMER, GARY; A Road Map for Digital Forensic Research; Technical Report DTR
– T001-01, DFRWS. Report From the First Digital Forensic Research Workshop
(DFRWS), New York, 2001.
[15]
AMARI, KRISTINE; Techniques and Tools for Recovering and Analyzing Data from
Volatile Memory, SANS Institute, 2009.
[16]
CARVEY, HARLAN; Windows Forensics Analysis DVD Toolkit; Syngress
Publishing, Inc. ; 2007.
[17]
van Baar, R.B.; Alink, W.; van Ballegooij, A.R. ; Forensic memory analysis: Files
mapped in memory; Journal of Digital Investigation; Volume 5; September, 2008.
[18]
SHIREY, R.; RFC 4949: Internet Security Glossary, Version 2; 2007. Acessado em
30/04/2011 em http://www.rfc-editor.org/rfc/rfc4949.txt.
[19]
DAVIS, NAJA; Live Memory Acquisition for Windows Operating Systems: Tools
and Techniques for Analysis; Eastern Michigan University. Acessado 23/04/2011 em
http://www.emich.edu/ia/pdf/research/Live%20Memory%20Acquisition%20for%20Windows
%20Operating%20Systems,%20Naja%20Davis.pdf
[20]
BOILEAU, ADAM; Hit by a Bus: Physical Access Attacks with Firewire; Ruxcon,
2006.
Acessado
em
14/04/2011
em
http://www.securityassessment.com/files/presentations/ab_firewire_rux2k6-final.pdf
[21]
LISITA, BRUNO LOPES; MOURA, THIAGO SILVA MACHADO DE; PINTO,
TIAGO JORGE; Forense Computacional em Memória Principal; Serviço Nacional de
Aprendizagem Industrial – SENAI; Goiânia, 2009.
[22]
BURDACH, MARIUSZ; An Introduction to Windows memory forensics; 2005.
Acessado
em
22/05/2011
em
http://forensic.seccure.net/pdf/introduction_to_windows_memory_forensic.pdf
[23]
KENT, KAREN; CHEVALIER, SUZANNE; GRANCE, TIM; DANG HUNG; Guide
to Integrating Forensic Techniques into Incident Response – Recommendations of the
National Institute of Standards and Technology; NIST Special Publication 800-86;
August, 2006
[24]
HOWARD, JOHN D.; LONGSTAFF, THOMAS A.; A Common Language for
Computer Security Incidents; Sandia National Laboratories; United States Department
of Energy; SAND98-8667; October, 1998.
[25]
MEMORYZE. Mandiant Memoryze
1.4.4200. Acessado em 04/05/2011 em
http://www.mandiant.com/products/free_software/memoryze
64
[26]
MDD.
Mantech
Memory
DD.
Acessado
http://www.mantech.com/capabilities/mdd.asp
em
04/05/2011
em
[27]
VOLATILITY. Volatile Systems Volatility Framework v1.3. Acessado em 09/05/2011
em https://www.volatilesystems.com/default/volatility
[28]
WMFT. Windows Memory Forensic Toolkit. Acessado em 23/05/2011 em
http://forensic.seccure.net/
[29]
WIN32DD. Moonsols Windows Memory Toolkit Community Edition. Acessado em
29/05/2011 em http://www.moonsols.com/windows-memory-toolkit/
[30]
FASTDUMP. HBGary FastDump Community Edition. Acessado em 29/05/2011 em
http://www.hbgary.com/fastdump
[32]
KNTDD. GMG Systems, Inc. KnTTools with KnTList. Acessado em 29/05/2011 em
http://gmgsystemsinc.com/knttools/
[33]
FTKIMAGER. Access Data Forensic ToolKit 3. Acessado em 29/05/2011 em
http://accessdata.com/products/computer-forensics/ftk
[34]
ENCASE FORENSIC. Guidance Software Encase Forensic. Acessado em 29/05/2011
em http://www.guidancesoftware.com/forensic.htm
[35]
NIGILANT32. Agile Risk Management Nigilant32. Acessado em 29/05/2011 em
http://www.agileriskmanagement.com
[36]
DIGITAL Forensic Analysis Methodology: Process Overview; United States
Department of Justice; Computer Crime and Intellectual Property Section; August,
2007.
Acessado
em
30/05/2011
em
http://www.justice.gov/criminal/cybercrime/forensics_chart.pdf
[37]
SILVA, GILSON MARQUES DA; LORENS, EVANDRO MÁRIO; Extração e
Análise de Dados em Memória na Perícia Forense Computacional; VI Conferência
Internacional de Perícias em Crimes Cibernéticos; Natal, 2009. Acessado em
20/04/2011
em
http://www.gilsonmarques.com.br/artigos/extracao_e_analise_de_dados_em_memoria
_na_pericia_forense_computacional_iccyber_ijofcs.pdf
65
66
7.
ANEXO I
LAUDO Nº xxx/AAAA – SETEC/SR/DPF/DF
LAUDO DE EXAME DE DISPOSITIVO DE
ARMAZENAMENTO COMPUTACIONAL
(Disco Rígido)
Em XX de <mês> de <ano>, no SETOR TÉCNICO-CIENTÍFICO da
Superintendência Regional do Departamento de Polícia Federal no XXX, designados pelo
Chefe do Setor, Perito Criminal Federal XXXXXXX XXXX XXX, os Peritos Criminais
Federais KKKKK KKKK KKKKKK e YYYY YYYYY YYYYY elaboraram o presente
Laudo Pericial, no interesse do IPL nº XXX/AAAA-SR/DPF/EE, a fim de atender a
solicitação do Delegado de Polícia Federal XXXX XXXXXXX XXXX, contida no
Memorando nº XXXX/AAAA-SR/DPF/DF de DD/MM/AAAA, registrado no Sistema de
Criminalística sob o nº XXXX/AAAA-SETEC/SR/DPF/EE, em DD/MM/AAAA,
descrevendo com verdade e com todas as circunstâncias tudo quanto possa interessar à Justiça
e atendendo ao solicitado <OU AOS QUESITOS>, abaixo transcrito<S>:
<SOLICITAÇÃO> OU <QUESITOS>
I – MATERIAL
O presente Laudo refere-se ao exame do seguinte material:
a) Um disco rígido da marca MAXTOR, modelo MMMMM, número de série
XXAXAXAAAXX, com capacidade nominal de XXGB, referencia interna
XXX/AAAA-SETEC/SR/DPF/EE.
II – OBJETIVO
Os exames têm por objetivo extrair e analisar o conteúdo do material descrito
na seção anterior, atendendo à solicitação contida no expediente supracitado.
67
III – EXAMES
Inicialmente, foi realizado o levantamento e a identificação do material
enviado para exame, cujos resultados encontram-se na seção I.
Em seguida, por meio de técnicas forenses apropriadas, o material original foi
duplicado. Esse processo de duplicação consiste na realização de cópia integral do material
original para outra mídia de armazenamento. Como medida de segurança, os exames foram
realizados sobre a cópia, preservando-se o original.
O material original foi submetido a um processo de garantia de integridade,
cujo resultado e parâmetros utilizados foram exportados – na forma de arquivo de texto com
extensão “.log” – para o diretório principal da mídia ótica incluída anexa a este Laudo.
Os exames objetivaram a análise e extração de conteúdo do material
examinado. Este processo atingiu não apenas os arquivos diretamente acessíveis, mas também
aqueles previamente apagados.
Os arquivos de interesse ao apuratório foram extraídos e gravados na mídia
ótica anexa, agrupados por categorias.
IV – CONCLUSÃO
Os arquivos de interesse ao apuratório foram selecionados, agrupados e
gravados na mídia ótica anexa sob as seguintes categorias:
a) Documentos: arquivos contendo documentos no formato MS Word.
b) Planilhas: arquivos contendo planilhas no formato MS Excel.
c) Planilhas com senha: a senha é <LALALALAL>
Os arquivos gravados na mídia ótica anexa passaram por um processo de
garantia de integridade baseado no algoritmo Secure Hash Algorithm (SHA) de 256 bits, cujo
resultado encontra-se em um arquivo denominado “hashes.txt” localizado no diretório
principal da mídia ótica. Por sua vez, o arquivo “hashes.txt” passa pelo mesmo processo, cujo
resultado encontra-se na Tabela 1.
Tabela 1 – Resultado do cálculo de integridade do arquivo “hashes.txt”
CÓDIGO HASH
Dessa forma, qualquer alteração do conteúdo anexo (remoção, acréscimo,
alteração de arquivos ou parte de arquivos), bem como sua substituição por outro com teor
diferente, pode ser detectada – o APÊNDICE A contém informações adicionais sobre a
garantia de integridade.
68
Para visualizar o conteúdo da mídia, basta colocá-la em uma unidade de leitura
apropriada e abrir o arquivo "index.htm" utilizando um navegador de Internet, como o
Microsoft Internet Explorer ou o Mozilla Firefox. A partir desse arquivo pode-se visualizar o
conteúdo gravado na mídia, navegando com o auxílio do menu localizado à esquerda.
Com o Laudo, os Peritos devolvem o material descrito na seção I no mesmo
estado em que foram recebidos. Nada mais havendo a lavrar, os Peritos encerram o presente
laudo que, elaborado em XX páginas, incluindo um apêndice e uma mídia ótica em anexo,
lidos e achados conformes, assinam acordes.
XXXXXXXX XXXXXX XXXXX
PERITO CRIMINAL FEDERAL
Matrícula: XXXXX
YYYYYYY YYYYYYYY YYYYYYY
PERITO CRIMINAL FEDERAL
Matrícula: XXXXX
69
APÊNDICE A – Considerações sobre mídias óticas anexas
A.1 – O Algoritmo SHA-256 (Secure Hash Algorithm - 256 bits)
O SHA-256 é um algoritmo que, a partir de uma mensagem de entrada de
qualquer tamanho, gera uma saída de tamanho fixo de 256 bits (conhecido como resumo, hash ou
código de integridade), calculada a partir do conteúdo dessa mensagem.
A segurança do procedimento consiste no fato de ser computacionalmente inviável
produzir duas mensagens distintas com o mesmo código de integridade ou, a partir do código de
integridade, obter a mensagem de entrada.
Cada arquivo contido na mídia ótica é tratado como se fosse uma mensagem que
passa individualmente pelo processamento do algoritmo. Ao final, obtém-se a relação dos nomes
dos arquivos e seus respectivos códigos de integridade em formato hexadecimal.
Cada mídia ótica anexa contém um arquivo denominado “hashes.txt” que contém
a relação supracitada (listagem dos nomes dos arquivos precedidos do respectivo código de
integridade). Por sua vez, o código de integridade do arquivo “hashes.txt” encontra-se na seção IV
deste Laudo.
Dessa forma, o acréscimo, alteração ou remoção de um único caractere em um
arquivo é condição suficiente para que o código de integridade gerado seja diferente, tornando
detectável a alteração do conteúdo da mídia ótica.
A.2 – Verificação de integridade
Para verificar a integridade das mídias óticas anexas, qualquer programa que
suporte o algoritmo SHA-256 pode ser utilizado. O processo de verificação envolve duas etapas
que devem ser executadas para cada mídia: (1) cálculo da integridade do arquivo “hashes.txt” e
comparação com o resultado presente neste Laudo e (2) cálculo da integridade dos arquivos
contidos na mídia e comparação com os registrados no arquivo “hashes.txt”.
Um dos programas que pode ser utilizado para realizar essa verificação é o FSUM,
disponível gratuitamente na Internet no endereço http://www.slavasoft.com. Utilizando esse
programa, as seguintes etapas devem ser executadas (assumindo que a mídia ótica a ser verificada
esteja na unidade "d:"):
a) etapa 1: na linha de comando, a partir do diretório do programa, digitar: fsum
-dd: –sha256 hashes.txt
b) etapa 2: em seguida, digitar: fsum -jf -dd: -c hashes.txt
O resultado da etapa (1) deve ser idêntico ao presente na seção IV deste Laudo. O
resultado da etapa (2) deve ser a correta verificação de todos os arquivos presentes na mídia, sem
nenhuma falha. Com isso, garante-se a autenticidade da mídia e a integridade do seu conteúdo.
70
71
8.
ANEXO II
Virustotal is a service that analyzes suspicious files and URLs
and facilitates the quick detection of viruses, worms, trojans,
and all kinds of malware detected by antivirus engines. More
information...
0 VT Community user(s) with a total of 0 reputation credit(s) say(s) this
sample is goodware. 0 VT Community user(s) with a total of 0 reputation
credit(s) say(s) this sample is malware.
File name:
convite.com
Submission date:
2011-06-22 01:42:28 (UTC)
Current status:
finished
Result:
29/ 42 (69.0%)
Antivirus
AhnLab-V3
AntiVir
Antiy-AVL
Avast
Avast5
AVG
BitDefender
CAT-QuickHeal
ClamAV
Commtouch
Comodo
DrWeb
eSafe
eTrust-Vet
F-Prot
F-Secure
Fortinet
GData
Ikarus
Jiangmin
K7AntiVirus
Kaspersky
McAfee
McAfee-GW-Edition
Version
2011.06.22.01
7.11.10.61
2.0.3.7
4.8.1351.0
5.0.677.0
10.0.0.1190
7.2
11.00
0.97.0.0
5.3.2.6
9148
5.0.2.03300
7.0.17.0
36.1.8399
4.6.2.117
9.0.16440.0
4.2.257.0
22
T3.1.1.104.0
13.0.900
9.106.4831
9.0.0.837
5.400.0.1158
2010.1D
Last Update
2011.06.22
2011.06.21
2011.06.22
2011.06.21
2011.06.21
2011.06.21
2011.06.22
2011.06.21
2011.06.22
2011.06.22
2011.06.22
2011.06.22
2011.06.21
2011.06.21
2011.06.21
2011.06.22
2011.06.22
2011.06.22
2011.06.22
2011.06.20
2011.06.21
2011.06.21
2011.06.22
2011.06.21
VT Community
not reviewed
Safety score: -
Result
Downloader/Win32.Dloadr
TR/Dldr.Agent.gljj
Win32:Delf-PHN
Win32:Delf-PHN
Downloader.Delf.12.BC
Gen:Trojan.Heur.GG0@YsZg1RpG
Win32.GenHeur.GG@YsZ
Gen:Trojan.Heur.GG0@YsZg1RpG
W32/DLOADR.AY!tr
Gen:Trojan.Heur.GG0@YsZg1RpG
Trojan-Downloader
Trojan/Chifrax.cvp
UDS:DangerousObject.Multi.Generic
Generic Downloader.x!fpl
Generic Downloader.x!fpl
72
Microsoft
NOD32
Norman
nProtect
Panda
PCTools
Prevx
Rising
Sophos
SUPERAntiSpyware
Symantec
TheHacker
TrendMicro
TrendMicro-HouseCall
VBA32
VIPRE
ViRobot
VirusBuster
1.7000
6227
6.07.10
2011-06-21.01
10.0.3.5
7.0.3.5
3.0
23.63.01.03
4.66.0
4.40.0.1006
20111.1.0.186
6.7.0.1.237
9.200.0.1012
9.200.0.1012
3.12.16.2
9653
2011.6.21.4525
14.0.90.0
2011.06.21
2011.06.22
2011.06.21
2011.06.21
2011.06.21
2011.06.21
2011.06.22
2011.06.21
2011.06.22
2011.06.22
2011.06.22
2011.06.22
2011.06.21
2011.06.22
2011.06.21
2011.06.22
2011.06.21
2011.06.21
Trojan:Win32/Dynamer!dtc
a variant of Win32/TrojanDownloader.Delf.QEV
W32/Suspicious_Gen.PKAT
Trojan-PWS/W32.QQPass.529408
Generic Trojan
Downloader.Generic
Mal/Generic-L
Downloader
TROJ_DLOADR.AY
TROJ_DLOADR.AY
TrojanDownloader.Agent.gboy
Trojan.Win32.Generic!BT
Backdoor.Win32.Hupigon.528384.F
Trojan.DL.Agent!vH/IwjyPGlQ
MD5 : 6af757c466f2b4513aded2dae23a2125
SHA1 : 7cb156e9cd8236b0c5b9244d806f8c72548322ef
SHA256: 7e09730269744cd60c8a3c740773cfe05451b6c6d7baa269db833b7f854cfdd2
VT Community
This file has never been reviewed by any VT Community member. Be the first one to comment
on it!
ATTENTION: VirusTotal is a free service offered by Hispasec Sistemas. There are no
guarantees about the availability and continuity of this service. Although the detection rate
afforded by the use of multiple antivirus engines is far superior to that offered by just one
product, these results DO NOT guarantee the harmlessness of a file. Currently, there is not
any solution that offers a 100% effectiveness rate for detecting viruses and malware.
73