IV_Teorico

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Perícia Forense 
Computacional
Produção e Gerenciamento de Evidências Computacionais
Responsável pelo Conteúdo:
Prof. Me. Marcelo Carvalho 
Revisão Textual:
Prof. Me. Natalia Conti
Nesta unidade, trabalharemos os seguintes tópicos:
• Introdução;
• Evidências de Acesso Indevido;
• Evidências de Uso da Rede;
• Estado de Segurança (Detecção de Malware);
• Gerenciamento da Evidência;
• Produção de Relatórios.
Fonte: Getty Im
ages
Objetivos
• Detalhar processos de análise e observação de evidências digitais assim como a guarda e 
gerenciamento das mesmas;
• Demonstrar ferramentas e atuação prática do profissional perito forense em atuação 
com casos exemplo.
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o úl-
timo momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Produção e Gerenciamento de 
Evidências Computacionais
UNIDADE 
Produção e Gerenciamento de Evidências Computacionais
Contextualização
Após a análise inicial do perito em evidências digitais coletadas, é comum que ape-
nas partes da tese e linha de investigação fiquem comprovadas, demandando novas 
análises para que seja possível o entendimento do ocorrido em um escopo mais am-
plo, permitindo a visualização sequencial de eventos e contexto. 
A atividade do perito, que pode ser segmentada em várias fases, com objetivos 
distintos, pode ser realizada com base em prioridades estabelecidas para investigação, 
mas comumente ocorrem guiadas pelas descobertas de evidências. Isto é, em última 
instância, mesmo tendo um plano delineado para a coleta e análise das evidências, é 
o aparecimento de artefatos que leva à procura por outros e ordena a sequência de 
investigação conduzida pelo perito.
6
7
Introdução
Como na unidade anterior tivemos a oportunidade de evidenciar o acesso a um 
arquivo proibido, caracterizando a hipótese e linha investigativa conduzida no caso, 
nesta unidade realizaremos análises adicionais para completar as informações da in-
vestigação. Lembre-se que é papel do perito também atentar para a característica de 
completude da evidência para que seja aceita para apresentação em juízo (FARMER, 
2006). Completar a sequência de eventos relacionados ao caso é o principal objetivo 
desta coleta de evidências complementar. Neste sentido, servem os dois primeiros 
capítulos desta unidade para que pensemos que outras características podem ser ob-
servadas, obtidas do dump de memória realizado anteriormente, para que seja possível 
perceber, de forma mais precisa, as atividades realizadas no computador investigado. 
Observe que os achados complementares podem ou não ser imputados ao suspeito 
no caso. Focaremos nossos exemplos de análise e procura de evidência no dump de 
memória realizado na unidade anterior, já que a procura por arquivos e conteúdos em 
disco é mais trivial.
Outra característica para apresentação em juízo, a evidência acreditável, também 
será tratada nessa unidade. Para isso, discutiremos brevemente sobre a produção do 
relatório e exposição dos fatos baseados em evidências colhidas, para que este docu-
mento possa ser entendido por leitores não técnicos.
Evidências de Acesso Indevido
O processo de investigação, como vimos na unidade anterior, é conduzido majori-
tariamente guiado pelo processo de descoberta de evidências, partindo-se de uma ob-
servação geral guiada. O aprofundamento em um ou outro local/repositório de dados, 
ou mesmo solicitações de evidências extras, em outros ativos, ocorre a partir dessa 
análise inicial. Isto é, ainda que haja um plano inicial e fluxo de ações, o desencadear 
do processo ocorre em razão dos achados. Assim, não necessariamente um primeiro 
achado responderá ou sustentará a hipótese e linha investigativa do caso. O perito, 
então, a partir desta primeira “pista” irá aprofundando a investigação e adquirindo 
mais informação. Estas informações e achados não centrais irão compor o relató-
rio, obviamente, mas num primeiro momento, serão vistas como secundárias, apenas 
caracterizando e especificando detalhes vistos na evidência. Portanto, há uma série 
de informações e análises que serão conduzidas, mas que servirão apenas para um 
melhor entendimento das características do ambiente/infraestrutura de TI envolvida e 
não diretamente para compor provas de sustentação do caso declaradas.
Um exemplo deste tipo de informação secundária, considerando o exemplo de 
caso, hipótese e linha investigativa que usamos como enredo para demonstrar pas-
sos de investigação na unidade anterior (estória do incidente e caso fictício), é a 
descrição de características e configurações do sistema operacional (SO) no compu-
tador em análise. Vários itens podem ser descritos nesse sentido, como a presença 
7
UNIDADE 
Produção e Gerenciamento de Evidências Computacionais
de indícios de uso de “bit lock”, swap, encriptação de disco, registro de vinculação 
de conta com Active Directory ou Samba, atualizações de software, canal usado em 
placa Wi-fi ativa, etc. Para fins de ilustração, neste capítulo, procederemos com a 
demonstração de uma informação secundária relacionada ao controle de acesso do 
SO no computador investigado.
É importante conhecer os locais onde residem arquivos de configuração do SO, para extrair 
informações específicas quando necessário. Também é importante conhecer a lista de APIs, 
binários e/ou executáveis presentes em uma determinada versão/distribuição de um SO. 
Veja exemplo desta lista em SO Windows, disponível em: https://symc.ly/31JRRoq
Imaginemos que continuamos a investigar o computador ilustrado na unidade an-
terior. Utilizando o mesmo dump de memória realizado, novamente carregando-o no 
framework Volatility, disponível na máquina virtual Kali Linux, o perito dá prosse-
guimento aos testes e análises. Com o comando “shelbags” (Figura 1), o perito agora 
verifica se há indícios de que o suspeito acessou um diretório protegido, incompatível 
com suas permissões.
Figura 1 – Ilustração do uso do comando shellbags
De forma minimalista, gostaria que você pensasse em shellbags como um receptáculo 
de informações no SO, em que são guardadas informações de acesso e customizações 
realizadas pelo usuário. Por exemplo, se você acessar o Windows Explorer e escolher a 
forma de visualização de lista ou detalhes para os arquivos e pastas exibidos, esta “custo-
mização” fica armazenada neste receptáculo. Da mesma forma, se você acessar uma pas-
ta em uma lista de diretórios, esse registro também fica armazenado, entre outras coisas, 
para prover histórico. Neste cenário, se existe um shellbag para aquele diretório/arquivo, 
significa que o usuário sabia de sua localização, pois “navegou” até lá para abrir o arquivo. 
Note que, mesmo se o suspeito, após realizar o acesso indevido ao arquivo, resolvesse 
apagar evidências e deletá-lo, ou mesmo o diretório inteiro, o shellbag persistiria e estaria 
disponível para análise posterior com um dump de memória (GLADYSHEV, 2006).
Como o registro oferece suporte para User Access Control (UAC) e informação de 
controle de integridade, informações relacionadasao controle de acesso também ficam 
disponíveis ao perito. Para fins de auditoria e, aqui descrito, análise forense, o acesso a 
este receptáculo (Há dois principais receptáculos de interesse ao perito: NETUSER.DAT 
\Software\Microsoft\Windows\Shell\Bags e UsrClass.dat \Local Settings\Software\
Microsoft\Windows\Shell\Bags) irá nos informar sobre detalhes de alcance a uma de-
terminada pasta/arquivo. 
8
9
Ao acessar o receptáculo, o perito poderá visualizar uma árvore de estrutura conten-
do o caminho da “navegação” entre diretórios e acesso a arquivos executada e arma-
zenada na subkey BagMRU, conforme ilustrado abaixo (Figura 2). Neste exemplo, esta 
subkey poderia mostrar o caminho do arquivo PDF que analisávamos em UsrClass.dat\
Local Settings\Software\Microsoft\Windows\Shell\BagMRU\0\0\2\0\1. Os núme-
ros após a tag BagMRU indicam a estrutura de navegação interna (Drives/Diretórios/
Subdiretórios, etc). Continuando a análise, avaliar a subkey MRUListEX do shellbag, 
poderia informar ao perito qual a ordem de acesso (“navegação de diretórios”) o suspeito 
executou para chegar até a pasta de destino onde o PDF foi encontrado. Ele já sabia do 
local? Pesquisou antes?
Figura 2 – Ilustração da navegação de um usuário em lista de diretório,
mapeada pela subkey BagMRU em shellbags
Fonte: Adaptado de 4n6k.com
Como já sabemos que o arquivo que estávamos procurando (ilustrado pelo texto “top 
secret” em um PDF) encontrava-se carregado na memória do computador em análise 
e fomos felizes em recuperá-lo integralmente para anexar como prova, agora podemos 
sondar informações adicionais sobre ele. Podemos iniciar identificando um espaço de 
memória de interesse, identificado pelo uso de um processo, em específico. Se você se 
recorda da unidade anterior, havíamos identificado um processo associado ao uso de um 
leitor de PDF. Se quiséssemos extrair a porção de memória específica desse processo, 
poderíamos executar, em sequência, os comandos “pslist” e “memdump” (no exemplo, 
especifica-se o -p para identificar o processo do leitor de PDF que interessa ao perito), 
conforme vemos ilustrado na imagem abaixo (Figura 3).
Figura 3 – Ilustração da verifi cação dos locais de memória pertinentes
ao processo de interesse do perito
Em seguida, seria útil também saber a localização da paginação em memória virtual 
(DTB) com o uso do comando “memmap” (Figura 4 e 5).
9
UNIDADE 
Produção e Gerenciamento de Evidências Computacionais
Figuras 4 e 5 – Ilustração da verifi cação dos locais de memória
virtual ao processo de interesse do perito
Assim, vários outros comandos podem auxiliar o perito na obtenção de informa-
ção complementar.
Existem vários outros comandos do framework volatility, os quais não exploramos aqui. É 
recomendável que você conheça todos, tanto para entender o uso (que informações aporta 
para a investigação), quanto ntaxe do comando propriamente. Veja a lista atualmente dis-
ponível em: http://bit.ly/321GZTc
Por exemplo, o comando “filescan”, que vai oferecer a oportunidade de visualizar o 
local residente em memória deste arquivo, ponteiro e, de forma mais importante para 
esta fase de aprofundamento, quais eram as permissões de acesso no momento. Caso 
ele indicasse W, conforme imagem de exemplo abaixo, estaríamos com evidência de que 
o suspeito possuía acesso de escrita no documento. A julgar pela resposta do comando 
shellbags, executado anteriormente, estes são resultados incompatíveis, possivelmente 
indicando que o suspeito subverteu o sistema de controle de acesso, ganhando/escalan-
do privilégios (estaria relacionado àquela tela preta que vimos nas imagens gravadas no 
arquivo de monitoração do data-center extraído do CFTV?).
Shellbags servem para auxiliar o perito na investigação de várias outras formas, além da-
quelas brevemente ilustradas aqui. Saiba mais em: http://bit.ly/31TZYif
10
11
Evidências de uso da Rede
Seguindo com a exploração do caso exemplo, agora que já estudamos um pouco 
a evidência de dump de memória do ponto de vista da localização do arquivo foco da 
investigação, com comprovação do acesso e visualização e comprovações secundárias 
para melhor contextualizar a sequência de atos, vamos concentrar nossa atenção no 
uso de recursos de comunicação via rede. Se você se recorda da estória que caracteri-
zava o evento, as imagens de vídeo CFTV do data-center sugeriam que o suspeito tinha 
acessado um browser ou alguma tela clara da qual vimos o reflexo da luz projetada pelo 
monitor, possivelmente tentando enviar o arquivo confidencial para o beneficiário da es-
pionagem industrial. Para comprovar ou refutar essa nova hipótese, vamos lançar mão 
de novos comandos do framework Volatility, específicos para rede.
Com o comando “netscan”, o perito poderia verificar se há indícios de que o suspeito 
acessou recursos de rede para compartilhar ou enviar arquivos externamente. Como a 
resposta deste comando aponta para o uso de portas e IPs específicos (sockets), presu-
me-se que você compreenda este conceito (veja link “SAIBA MAIS” abaixo). Também 
que algumas portas possuem fim específico (default), como a porta 80/443 para http/
https, a porta 143 para imap, etc. 
Existem portas de serviços padrão, que são reguladas pela IANA. 
Saiba mais em: http://bit.ly/2xcAkam
A intenção do perito, portanto, é determinar se houve uso de porta de serviço padrão 
para comunicação de rede, que possa estabelecer o possível envio do arquivo secreto 
para terceiros. Para isso, vamos inicialmente executar o comando e, em seguida, verifi-
car se existe algum socket suspeito (Figura 5).
Figura 6 – Ilustração da verifi cação dos uso da rede
11
UNIDADE 
Produção e Gerenciamento de Evidências Computacionais
Como é possível perceber, o perito agora possui indícios de uso de rede na data-hora 
do incidente, provenientes do endereço do computador investigado na rede local do data-
-center 10.0.2.15/24. Note também, que esta evidência também aponta para o uso de 
navegador (possivelmente webmail?), o que, até o momento, sustentaria aquela tese ini-
cial indicada inicialmente pela filmagem das ações do suspeito em frente ao computador. 
Como é possível perceber, no entanto, só um dos endereços possui registro de respon-
sável junto à IANA (será que o segundo servidor foi “montado” temporariamente apenas 
para executar a ação e depois removido para deixar menor quantidade de rastros?).
Figura 7 – Identifi cação DNS dos servidores de destino da conexão (rede remota)
Certamente, um passo seguinte seria identificar os servidores Web apontados na 
evidência pela conexão na porta 443 e solicitar logs de transação nos intervalos de data 
coincidentes. Um firewall ou roteador de borda, naquela rede remota, também possivel-
mente seriam envolvidos entre os ativos cuja solicitação de evidências seria encaminha-
da ao juiz responsável pelo perito, já que precisaríamos estabelecer, daquele lado (rede 
remota), que houve a conexão proveniente do endereço IP do computador investigado 
(rede local).
Um desdobramento possível seria identificação de login ou atributo de autenticação 
que pudesse ligar, ainda mais fortemente, o suspeito como autor do ilícito investigado.
Agora que sabemos que houve acesso Web, vamos focar mais atenção nesse aspecto, 
verificando uso de navegadores (browsers) no computador analisado. Também buscare-
mos por resquícios de informações de navegação. Novamente vamos demonstrar aqui 
a parte da pesquisa envolvendo memória apenas. Isso porque a visualização do uso do 
navegador por meio de dados provenientes do disco é mais simples. Também porque 
em vários casos de investigação, nota-se que um dos primeiros procedimentos realiza-
dos pelo autor da ação investigada (suspeito) trata de apagar as informações e histórico, 
cache e downloads, assim como muitas vezes até logs e registros internos no SO.
12
13
É importante que você conheça a estrutura de configuração de navegadores diversos 
(browsers) para encontrar, mais facilmente, informações pertinentes aocaso, residentes 
também em disco. Após identificar o navegador, visite o site do fornecedor e pesquise 
a estrutura de pastas e locais específicos de guarda de configurações. Veja exemplo do 
navegador Firefox em: https://mzl.la/31SzQ7q
Como primeira ação investigativa, verificaremos os navegadores instalados no com-
putador (Ex.: Internet Explorer, Chrome, Edge, Opera, Firefox, etc) para facilitar a 
pesquisa por seus executáveis, quando formos procurar por processos associados. Para 
este exemplo, procuraremos pelo navegador padrão do Windows 7 em questão. Para 
evitar incorrer em exibição, de forma acidental, de dados de navegação ou qualquer 
dado pessoal existente nos computadores do laboratório usados para produção deste 
material, exibiremos, a partir daqui, dados fictícios apenas. Para isso, utilizaremos ima-
gens e memória de computadores disponibilizados para teste. 
Caso você deseje reproduzir os comandos aqui exemplificados e obter os mesmos resul-
tados, efetue o download das imagens de teste (dumps de memória), representadas nas 
figuras, em: http://bit.ly/2YbL8Bq. 
Iniciaremos identificando se há histórico de uso do navegador Internet Explorer (IE) 
e processos associados, conforme demonstrado abaixo (Figura 8).
Figura 8 – Identifi cação de processos relacionados ao uso do navegador (browser)
Perceba que o comando grep utilizado, na sequência do “pslist” que havíamos usado 
em outros exemplos anteriormente, tem a função de filtrar apenas o processo de interesse.
Com o comando “yarascan”, o perito poderia verificar se o conteúdo do cache em 
memória reflete algum achado de interesse, considerando os processos do navegador 
acessados na data/hora do evento sob investigação. Conteúdos visualizados no cache, 
que poderiam contar mais sobre o ocorrido são aqueles voltados ao histórico de visita a 
sites (vistos na imagem ilustrativa, na coluna do lado direito). Note que essa informação 
é equivalente àquela que poderia ser vista no histórico do navegador, mantido em disco. 
Porém, mesmo usuários comuns têm ciência e capacidade de apagá-los. Não é de se es-
perar, em uma investigação forense, que atos ilícitos cometidos deliberadamente tenham 
sido executados por este perfil de usuário. Usuários avançados ou mesmo conhecedores 
de técnicas antiforense usarão de meios para alterar ou deletar registros que mantenham 
rastros disponíveis nestes locais. Em memória, no entanto, a ação de mascarar este 
rastro não é tão simples.
13
UNIDADE 
Produção e Gerenciamento de Evidências Computacionais
Para melhor identificar a presença de URLs no cache que analisávamos, procure 
pelos indicadores “REDR”, “URL” e/ou “LEAK”. No exemplo abaixo, uma variação 
do comando que facilitaria a visualização desses indicadores seria: yarascan -Y “/(URL 
|REDR|LEAK)/” -p 2392
Figura 9 – Ilustração da pesquisa por registros relevantes em cache,
usado pelo navegador (browser)
No contexto da investigação, o descobrimento da URL acessada no brower do com-
putador investigado serviria para comprovar, de forma mais sólida, o envio do arquivo 
PDF por meio da conexão https estabelecida. A identificação de Webmail ou outra URL 
que identifique claramente um serviço de comunicação acessado é o objetivo desta fase 
da análise.
Para visualização das conexões de rede, completando o cenário de visualização de 
comunicação que iniciamos nesta sessão, o perito poderia utilizar-se dos comandos 
“connections” e “sockets”.
Figura 10 – Ilustração da resposta dos comandos connections e sockets
Saiba que a lista de comandos do framework de investigação Volatility não é apli-
cável a todos os SOs. Estes ilustrados acima (Figura 9) não são compatíveis com o 
profile que estávamos usando para examinar o dump Windows 7, que realizamos na 
unidade anterior.
14
15
Estado de Segurança (Detecção de Malware)
Para finalizar nossa demonstração de exemplos de atividade do perito forense com-
putacional, em sua ação analisando dumps de memória, vamos agora explorar no-
vamente a classificação dos atores, mencionada anteriormente. Lembre-se que, nesse 
sentido, o perito precisa determinar (agora no caso do computador investigado) se ele 
assumiu papel de vítima, gateway ou atacante no cenário investigado.
Para isso, ainda que já tenhamos coletado evidências suficientes para suportar a 
tese de culpabilidade do suspeito, que assumimos inicialmente como hipótese, precisa-
mos afastar a possibilidade de que o computador tenha sido “invadido” e “controlado” 
remotamente (ROBERTSON et al., 2016). Perceba que este é um passo importante, 
pois a tese se apoia no fato de que o suspeito que estava à frente da máquina nas 
filmagens é o responsável pelos atos. No entanto, o que se pôde coletar de evidên-
cias até o momento (desconsiderando aquelas que ponderamos serem potencialmente 
alcançáveis por meio da requisição dos dados de acesso aos provedores/servidores 
identificados) não liga, de forma indubitável, o suspeito e as evidências de acesso e 
tentativa de envio do arquivo contendo conteúdo confidencial.
Para afastar a possibilidade de dúvida, o perito então procede com uma análise 
de segurança do sistema operacional em busca de infecções que possam fragilizar as 
provas já coletadas. Isso, porque em se comprovando a existência de vírus, malware, 
root-kits, backdoors, ou outras formas de controle da máquina, as evidências perdem 
a força esperada como prova material. Ainda que o perito pudesse se aprofundar na 
busca de responsabilização de terceiro (que não o suspeito do caso), caso o controle 
remoto fosse comprovado, caracterizando o papel do computador como gateway ou 
vítima, aqui focaremos apenas na atividade decorrente do relato principal no caso.
O trabalho do perito nessa fase identifica se há indícios de DLLs e bibliotecas di-
ferentes do normal. Para a definição de “normal”, o perito deve comparar a lista de 
DLLs carregadas em memória, em razão dos processos ativos, com um baseline de 
referência. Este baseline pode ser obtido com o próprio fabricante/desenvolvedor do 
SO ou mesmo com uma instalação do SO realizada de forma segura.
O comando no framework Volatility, utilizado para esta finalidade, é o “dlllist”, 
conforme demonstrado na ilustração abaixo (Figura 11).
Figura 11 – Ilustração da resposta do comando dlllist
15
UNIDADE 
Produção e Gerenciamento de Evidências Computacionais
Com o comando “printkey”, o perito verifica os programas em registros no SO. 
Em passo seguinte, localiza aqueles “persistentes”, ou seja, que são acionados pelo SO 
em sua inicialização. Isto é especialmente importante, já que são locais preferenciais 
para injeções realizadas por atacantes, oferecendo oportunidade de ataque desde o 
boot do sistema.
No caso do SO Windows, a Microsoft disponibiliza baselines de segurança que podem ser 
usados para fins de comparação pelo perito. No caso do Windows 10, a ferramenta Microsoft 
Security Compliance Toolkit possui o baseline para esta versão. 
Disponível em: http://bit.ly/31JTimO
Figuras 12 e 13 – Ilustração de respostas do comando printkey
Como você deve ter percebido, estes dois comandos requerem muita atenção do pe-
rito e, principalmente, demandam por uma comparação manual, que além de suscetível 
a erro, é extremamente trabalhosa.
Paralelamente a essa verificação, o que se faz comumente é um teste automatizado 
utilizando uma base de dados de “normalidade” do próprio Volatility. O comando para 
essa comparação é o “malfind” (Figura 14).
16
17
Figura 14 – Ilustração da resposta do comando mal� nd
Na sequência do seu uso, o perito gera um HASH dos processos suspeitos, identifi-
cados pelo “malfind” e verifica em bases de conhecimento de antivírus e afins. Neste 
exemplo, submetido ao site virustotal.com que resultou ser um falso-positivo (Figura 15). 
Conclui-se, portanto, que o computador investigado não possui indícios de infecção e 
que, portanto, o perito pode classificá-lo como vítima, no contexto do caso.
Figura 15 – Ilustração do hash resultante dos processossuspeitos
sendo submetidos para análise em virustotal.com
Gerenciamento da Evidência
A tarefa de gerenciamento de evidências digitais, como vimos em outras unidades, 
envolve uma série de atividades. Da mesma forma como vemos em filmes de investiga-
ção, quando os primeiros a chegar ao local do crime “isolam o local” para investigação 
17
UNIDADE 
Produção e Gerenciamento de Evidências Computacionais
(MOZAYANI e PARISH-FISHER, 2017), preservando o perímetro para a chegada dos 
detetives, o ideal é que em caso de incidente e casos de investigação envolvendo a atua-
ção do perito forense computacional, ele seja o primeiro a ter contato com as evidências, 
sem “contaminação prévia”. O “isolamento” do local (cena de crime, por exemplo) está 
diretamente ligado à quantidade de evidências “aproveitáveis” e aceitas em corte. 
De acordo com boas práticas, o fluxo geral que vimos ilustrado nas duas últimas 
unidades é: 1) Avaliação do local; 2) Extração das evidências; 3) Examinação das evi-
dências; e 4) Documentação e reporte (laudo) dos achados (NCJ 199408, 2004). Uma 
identificação completa da evidência, assim como dos procedimentos executados pelo 
perito é essencial para o controle do processo e validação/aceite das evidências pela 
corte judicial. Lembre-se que ao apresentarmos a evidência, compondo prova material, 
como parte da argumentação da defesa ou acusação no caso, a contraparte (defesa 
no caso de estarmos contribuindo com a acusação do suspeito) irá tentar invalidar a 
prova, procurando viés de falhas processuais ou incompetência e imperícia do perito. 
Documentar, portanto, é essencial. Conforme ilustrado na imagem abaixo (Figura 16), 
as ações do perito e a identificação e caracterização da evidência podem ser percebidas 
em um exemplo prático. Dados de “onde” sairam as evidências e tipo de arquivamento, 
assim como suas características do objeto e ferramenta(s) de análise usadas (Ex. Evidên-
cia colhida <data-hora completa>, em <local completo>, SO: Windows 7, ferramenta 
usada: FTK Imager, Volatility, etc), são informações básicas a declarar. Note que uma 
das tarefas listadas para o perito, no exemplo abaixo, é a obtenção de informações de 
contas e senhas de usuários no SO. Ainda que não tenhamos demonstrado os comandos 
específicos para esse propósito nesta unidade, saiba que a própria ferramenta Volatility 
que exploramos possui comandos para a extração dessa informação.
Figura 16 – Ilustração do preenchimento de identifi cação da
evidência e processos de análise realizados pelo perito
Fonte: NCJ 199408, 2004
18
19
Outro ponto importante é a própria solicitação de serviço. Esta serve para determi-
nar escopo e contribuições esperadas do perito forense computacional e também serve 
de apoio para solicitação de mandados de busca, a serem autorizados pelo juiz do caso.
Conforme ilustrado na imagem abaixo (Figura 17), é possível observar que na própria 
solicitação de serviço, requisitando o trabalho do investigador forense, há uma instrução 
explícita de anexar os logs da cadeia de custódia da(s) evidência(s).
Figura 17 – Ilustração do formulário de solicitação de serviço
forense para um caso em investigação
Fonte: NCJ 199408, 2004
Produção de Relatórios
O processo de produção de relatórios é um passo importante para transmitir, ade-
quadamente, o trabalho de investigação realizado pelo perito forense computacional. 
Este passo deve ser conduzido cuidadosamente, não apenas pensando em formatos 
padrão, mas na importância da semântica e linguagem usada no texto. O uso de 
jargões e expressões populares deve ser evitado, dando lugar a colocações que expri-
mam, com precisão, a descrição do ocorrido e permitam uma visão clara do parecer 
do perito. De maneira geral, esta fase de produção textual, no que diz respeito ao 
conteúdo, deve ser escrita pensando em informar: a) dados do investigador (perito); b) 
dados de identificação do caso/incidente; c) descrição do caso, hipótese(s) e linha(s) de 
investigação; d) delimitação do escopo de local e infraestrutura analisado; e) metodolo-
gia, achados e artefatos extraídos; f) classificação dos atores; g) resultado das análises 
e provas materiais a serem anexadas ao caso (sustentando ou refutando hipóteses); e 
h) conclusões do perito. Note que, nessa organização, há uma ênfase inicial em des-
crever os processos e métodos utilizados. Isso é feito, propositalmente, a fim de dar 
ao leitor o claro entendimento de rigor da análise. De maneira comum, esta parcela 
19
UNIDADE 
Produção e Gerenciamento de Evidências Computacionais
do documento serve como uma espécie de resumo executivo, que vai permitir ao juiz 
ou solicitante do relatório que possa decidir sobre a necessidade fragilidade/robustez 
da análise, decidindo, por exemplo, solicitar exames complementares ou mesmo uma 
segunda opinião. Neste sentido, é importante que haja uma espécie de “disclaimer” 
informando limitações processuais ou técnicas encontradas pelo perito, no curso de sua 
investigação, que o tenham impedido de realizar um fluxo ótimo de trabalho ou que 
tenha imposto limitação ao seu poder de observação e julgamento. Deve ficar claro ao 
leitor, viés(es) percebidos durante o processo que por ventura possa(m) influenciar na 
precisão da análise.
Já em relação ao texto em si, recomendações genéricas que podem ser obtidas no 
Instituto comercial de forenses (ICFP - http://bit.ly/2Y7i8e1 ) incluem: 
• Linguagem clara e concisa;
• Estruturada;
• Relevante e lógica;
• Precisa e completa;
• Imparcial e objetiva;
• Profissional;
Do ponto de vista da aceitação da documentação em juízo, como vimos na unidade 2 
da disciplina, é importante atentar para admissibilidade das provas (considere que auten-
ticidade e confiabilidade estão implícitas no processo, conforme descrito na Unidade 3. 
Para isso, atenção especial do perito à descrição de autorizações e mandados de busca 
relacionados ao seu processo de extração de evidência, que devem ser explicitamente 
declarados no relatório. Já em relação à completude, o perito deve deixar claro ao leitor 
se conseguiu obter a totalidade das evidências digitais necessárias e/ou a extensão dessa 
obtenção em relação ao todo. Por fim, o caráter acreditável do relatório deve ser alcan-
çado por meio da escolha da linguagem, que deve conter os termos técnicos necessários 
para a precisa descrição dos eventos e achados, mas, ao mesmo tempo, promover o en-
tendimento de audiência não técnica, por meio de explicações e “traduções” em termos 
que contribuem para o amplo entendimento (independente da formação tecnológica 
computacional e de segurança da informação do leitor).
20
21
Os processos de investigação de evidência, com o objetivo de extrair informação secundá-
ria, são igualmente importantes àqueles que vimos na unidade anterior, focados primaria-
mente na comprovação da hipótese e linha investigativa. Isso, porque é requisito da prova, 
para que seja aceita em juízo, que esta conte a história e sequência de eventos, de forma 
completa e relacionada ao incidente investigado.
Aqui vimos diversos exemplos de comandos, com objetivos específicos de demonstrar 
“como” ocorreram os eventos e “de que forma” o suspeito se comportou, em relação às 
ações realizadas no computador investigado.
Também revisitamos o assunto de gerenciamento de evidência, com vistas na produção de 
relatório e preocupação especial com a validade das provas, de modo a diminuir a chance 
do trabalho do perito forense computacional ser invalidado, devido à falha procedural mal 
documentada ou executada.
Esperamos que tenha gostado e adquirido esses novos conhecimentos.
21
UNIDADE 
Produção e Gerenciamento de Evidências Computacionais
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Livros
Interpreting Evidence: Evaluating Forensic Science in the Courtroom
ROBERTSON, B; VIGNAUX GA, BERGER, CEH. Interpreting Evidence: Evaluating 
Forensic Science in the Courtroom. 2 ed, Wiley, Oxford, 2016.Vídeos
Threat Hunting: Memory Analysis with Volatility
Examinando coletas de evidências por meio da ferramenta Volatility (em inglês).
https://youtu.be/dp-XIC1CPzI
Computação Forense e a Carreira de Perito - Gilberto Sudré
https://youtu.be/Q2mfTZs0LKk
Evidence Collection & Preservation | Crime Scene Sketching - UCO Forensic Science Institute
Preservação de evidências e cenas de investigação (em Inglês).
https://youtu.be/Od0yP81kqrg
 Leitura
Forense Digital – Perícia Forense Computacional
Artigo descrevendo etapas básicas da investigação forense.
http://bit.ly/2Y9wdbd
22
23
Referências
FARMER, D. Perícia Forense Computacional. Teoria e Prática Aplicada. 1ed, 
Pearson, São Paulo, 2006.
GLADYSHEV, JZ. J-. Using shellbag information to reconstruct user activities, 
Digital Investigation, v.6, pp 69-77, 2006.
MOZAYANI, A; PARISH-FISHER, C. Forensic Evidence Management: From the 
Crime Scene to the Courtroom. 1 ed. Flórida: CRC Press, 2017. 211 p. ISBN-10: 
149877718X.
NCJ 199408. Forensic Examination of Digital Evidence: A Guide for Law Enfor-
cement. 1 ed. Office of Justice Programs National Institute of Justice, 2004. 91 p.
ROBERTSON, B; VIGNAUX GA, BERGER, CEH. Interpreting Evidence: Evalua-
ting Forensic Science in the Courtroom. 2 ed, Wiley, Oxford, 2016.
23