Foi dado início à investigação do incidente ocorrido na empresa, seguindo os passos proposto pelo fluxograma apresentado, no capitulo 5, conforme segue:
1 - Identificar fontes de dados: a verificação inicial das possíveis fontes de dados foi realizada, e identificou-se o servidor que continha os projetos, porém, ainda não havia confirmação da máquina utilizada pelo suspeito, apenas a desconfiança de ser a máquina que ele utiliza na empresa.
Nos levantamentos, foi verificado que se tratava de um servidor Linux que continha regras de firewall e continha autenticação restrita por MAC Address.
O funcionário suspeito, por regras da empresa, não deveria possuir usuário e senha para acesso ao servidor, o que necessitou de uma verificação para descobrir como que os dados foram retirados do servidor.
2 - Coletar dados: como posto acima, foi identificado que o servidor havia sido invadido. Prontamente, buscou-se coletar dados do servidor que estava o projeto que fora repassado à concorrência.
2.1 - Acessar à máquina invadida: realizou-se acesso ao servidor para coleta. 2.2 - Coletar dados voláteis: início da coleta de dados voláteis.
2.2.1 - Coletar sessões de log: foi utilizado o comando abaixo, para verificar todos os acessos ao servidor:
# cat /var/log/auth.log
A seguir, a figura 13 mostra que o usuário ―carol‖ acessou ao servidor. Esse usuário se refere a um dos programadores da empresa, porém o IP faz referência a uma outra máquina, que não pertence ao programador. Pelo IP, foi verificado que pertencia ao suspeito e, pelo horário mostrado, confirmou-se que o funcionário suspeito, ainda, estava na empresa durante o ocorrido.
Figura 13: Tela mostrando os acessos ao servidor. Fonte: Autores (2010).
Todos os logs de sessão foram coletados, assim como os dados abaixo, utilizando o dd do Linux para copiar para o equipamento de perícia.
Foram, então, coletadas todas as conexões de rede, o estado das portas TCP e UDP, os processos em execução, os dados da memória e os arquivos abertos para posterior exame.
2.2.7 – Coletar comandos executados: em seguida, foi realizada a verificação dos comandos executados, por cada usuário que havia se conectado, através do comando:
# cat /home/carol/.bash_history
Foram verificados os comandos executados e identificou-se que o projeto ―projetoX‖ foi copiado do servidor através do SCP (Secure Copy), um meio para fazer downloads de arquivos. Com isso, descobriu-se que o suspeito utilizou o usuário do programador da empresa para fazer a cópia do projeto, como mostrado, a seguir, na figura 14.
Figura 14: Tela do comando, utilizado para fazer o download do projeto. Fonte: Autores (2010).
Todas as informações foram coletadas, e descobriu-se o IP da máquina supostamente utilizada pelo suspeito. Também, foram coletadas, a data e hora da análise realizada no servidor.
2.3 - Coletar dados não-voláteis: após a coleta dos dados voláteis, foram coletados os dados não-voláteis.
2.3.1 - Coletar arquivos de log do sistema: no caso do servidor, foram coletados apenas os arquivos de logs que são gerados pelo sistema para posterior filtragem.
2.4 - Acessar à máquina do suspeito remotamente: como o IP identificado era o do suspeito, iniciou-se a análise em sua máquina.
2.2 - Coletar dados voláteis: foi realizada a mesma coleta utilizada no servidor, para a máquina do suspeito. Nenhuma evidência foi identificada no momento da verificação.
2.5 - Realizar retirada da máquina: os peritos foram até o local em que se encontrava a máquina e procederam, conforme descrito no capítulo 4, para retirar fisicamente a máquina suspeita.
2.3 - Coletar dados não-voláteis: após todo o procedimento de retirada da maquina, seguindo o proposto pela metodologia, foi criada a imagem do disco existente na máquina.
2.3.2 – Criar imagem do(s) disco(s): para essa cópia, também, foi utilizado o comando dd do Linux, que faz uma cópia (bit-a-bit) do disco.
Foi utilizado o seguinte comando:
dd if=/dev/hda bs=1k conv=sync,noerror | gzip -c | ssh -c blowfish user@hostname "dd of=filename.gz bs=1k"
2.3.3 - Restaurar a cópia dos dados: Após a criação da imagem, essa foi restaurada em uma máquina utilizada para exame e análise dos dados.
Comando utilizado:
dd if=filename.gz | ssh -c blowfish root@deadhost "gunzip -c | dd of=/dev/hda bs=1k" Com isso, a parte de coleta foi finalizada. Em seguida, para filtrar os dados, foram aplicados os procedimentos de exame de dados, os quais estão ligados diretamente com a parte de análise.
3 - Exame dos dados (Filtragem): com a imensidão de dados anteriormente coletados, fez-se necessário a filtragem desses para torná-los possíveis de análise, seguindo os passos a seguir:
3.1 - Recuperar dados e fragmentos de dados: ainda, na máquina do suspeito, foi realizada uma pesquisa para verificar a existência do projeto. Posteriormente, foi utilizado o programa ―Recuva‖ que recupera todos os arquivos apagados da máquina. Através dessa análise, foi possível recuperar o projeto que havia sido deletado.
Figura 15: Tela do programa de recuperação de arquivos Fonte: Autores (2010).
A filtragem já tinha por base a busca pelo projeto que havia sido repassado. Isso facilitou, pois reduziu, consideravelmente, a quantidade de dados.
3.2 - Utilizar ferramentas e técnicas disponíveis para a filtragem: foram utilizadas ferramentas para varredura e nada mais foi identificado, apenas o projeto que havia sido copiado. Foi realizada uma verificação nos e-mails e conversas on-lines que estavam salvas no computador, porém nada foi identificado para adicionar ao relatório final e compor a prova do crime. Houve a suspeita de que os dados foram copiados para uma mídia externa e por meio dessa, repassado para a concorrência, entretanto nada foi comprovado.
4 - Analise dos dados: Foi dado início a análise dos dados, pois já havia uma quantidade muito reduzida de dados, se comparado com o inicial.
Foi verificado que para conseguir o usuário e a senha válidos, foi utilizado um script de brute force que faz tentativas, como o próprio nome já diz, por meio de força bruta, para descobrir a senha dos usuários. Isso retirou qualquer suspeitas sobre o programador, que possuía um login e uma senha para acesso ao servidor.
Em seguida, foram verificadas as configurações de rede e foi detectado que o suspeito alterou seu MAC Address para conseguir acesso ao servidor com o comando:
# cat /home/pedro/.bash_history | grep ipconfig
Figura 16: Tela do comando que verifica o MAC Address. Fonte: Autores (2010).
4.1 - Identificar pessoas: foi verificado o horário em que o arquivo foi copiado para a máquina e, verificando os logs do sistema, foi possível constatar que, naquele horário, quem estava logado na máquina era, realmente, o funcionário suspeito. Assim, foi possível identificar o responsável pelo ataque.
4.2 - Identificar locais: com os logs coletados do servidor, foi possível identificar que o suspeito acessou ao servidor do seu computador disponibilizado para trabalho.
4.3 - Identificar eventos: com a alteração do MAC Address e a utilização do script de
brute force, foram possíveis identificar os passos dados pelo suspeito para realização do
crime.
4.4 - Correlacionar as evidências: o correlacionamento ocorreu durante todo o procedimento, tanto de coleta, quanto de exame ou de análise, pois foram surgindo parâmetros que direcionaram a suspeita para uma pessoa. Isso, se deu pela descoberta da invasão, pela a utilização de códigos de brute force encontrados na máquina suspeita e utilizados para a invasão, além de todas as coletas de horários de criação de arquivos e logins realizados. Deu-se também, por todos os parâmetros de configurações que deram suporte à identificação do suspeito.
6.3 CONSIDERAÇÕES FINAIS
Conforme apresentado, o modelo foi validado em cima do estudo de caso realizado, tornando viável a utilização deste, para chegar ao esperado, a constatação e comprovação de fraude interna dentro da empresa XYZ.
Todos os passos foram seguidos conforme descrito no modelo e foram obtidas respostas para as seguintes perguntas:
quem é o suspeito? como procedeu? quando procedeu?
Com esses parâmetros ficou evidente o crime realizado pelo, até então, suspeito, assim como seus passos e os momentos em que foram realizados.
Conclui-se com isto, que o modelo foi de grande valia para a perícia forense computacional realizada, obtendo os resultados esperados.
7 CONCLUSÕES E TRABALHOS FUTUROS
Neste capítulo serão apresentadas as conclusões e trabalhos futuros desta monografia.