Perícia Título

Inserir ForenseAqui
Inserir Título Aqui
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
 Produção e Gerenciamento de
Evidências Computacionais

Fonte: Getty Images

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.

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!
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
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
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 relacionadas ao 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
 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 verificaçã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
9
UNIDADE
Produção e Gerenciamento de Evidências Computacionais

Figuras 4 e 5 – Ilustração da verificaçã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
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 verificação dos uso da rede

11
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 – Identificaçã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
 É importante que você conheça a estrutura de configuração de navegadores diversos
(browsers) para encontrar, mais facilmente, informações pertinentes ao caso, 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 – Identificaçã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
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
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
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
 Figura 14 – Ilustração da resposta do comando malfind

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 processos suspeitos

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
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 identificação da

evidência e processos de análise realizados pelo perito
Fonte: NCJ 199408, 2004

18
 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
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
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
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
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
23