1.
Computer
Forensics
Histórias das trincheiras

2.
Sobre o autor
▪ Luis Grangeia
▪ luis.grangeia@gmail.com
▪ LEIC @ IST (1998)
▪ ~15 anos a fazer auditorias de segurança, testes de intrusão, pesquisa e (algum) forense.
▪ http://pt.slideshare.net/lgrangeia
▪ http://grangeia.io
▪ A minha área de especialização não é forense:
▪ A maioria do trabalho forense foi feito com pouca preparação

3.
Histórias das trincheiras
1. “O pirata”
2. “Ladrões de bancos”
3. “Clicks para o leste”

4.
1. O pirata

5.
“O Pirata”
▪ Por volta de 2005
▪ Chamada de um ISP (Hosting provider):
▪ “O servidor que aloja o site www.xyz.pt esgotou a sua quota de rede. O tráfego Web
não justifica o volume de dados de rede (muitos gigas). Podem investigar? É urgente,
fomos obrigados a retirar o site do ar.”
Lição #1:
É quase sempre urgente. O planeamento e preparação para um projeto específico
é muito difícil de fazer.
É importante estar preparado para quase tudo: Equipamento dedicado e pronto a
utilizar.

6.
“O Pirata” - Resposta
▪ Servidor Windows (Web + FTP)
▪ Site institucional
▪ Servidor offline, num datacenter
▪ Primeira análise:
▪ Correr um antivírus no sistema operativo
▪ Procurar ficheiros suspeitos no disco
▪ Zero resultados!
▪ O disco estava quase cheio mas não encontrávamos nada que o justificasse.

7.
“O Pirata” - Resposta
▪ Correr o mesmo anti-vírus, fora da máquina:
▪ Mapeando o disco via SMB: sistemaC$
▪ 1 rootkit
▪ Dezenas de filmes pirata
▪ A “assinatura” do pirata (“hacked by xxx@hotmail.com”, etc. etc.)
Lição #2:
Sempre que possível não confiar num sistema comprometido.
Fazer a recolha de informação e fazer a análise num sistema separado.

8.
“O Pirata”
Lição #3:
Vir preparado com o equipamento necessário para recolhas!
Lista de compras mínima:
▪ Pen USB de alta velocidade (Sandisk Extreme 64GB)
▪ Disco externo de alta capacidade (2TB+) – USB3
▪ Adaptador de disco c/ Writeblocking (ex. WiebeTech Ultradock)

9.
2. Ladrões de
bancos

10.
“Ladrões de Bancos”
▪ Duas ou três ocasiões
▪ Banco “xyz” pretende investigar alegadas vítimas de phishing
▪ Deve ou não indemnizar o cliente
▪ Houve comportamento de risco?
▪ Houve infeção por malware? Se sim, de onde originou?

11.
Estrutura de uma investigação forense
Recolha
Análise /
Investigação
Reporting
Recolha
▪ Fase mais sensível
▪ Estamos na casa de um cliente
▪ Os erros pagam-se caro
▪ uma recolha mal feita compromete toda a investigação

12.
“Ladrões de Bancos” - Recolha
▪ Duas ferramentas de recolha essenciais:
▪ Live memory (RAM):
▪ MoonSols DumpIt: http://www.moonsols.com/products/
▪ Disco:
▪ dc3dd: http://www.forensicswiki.org/wiki/Dc3dd

13.
“Ladrões de Bancos” - Recolha
▪ Numa das recolhas o disco de sistema era grande: 1TB
▪ Optei por copiar apenas a partição de sistema (300GB) – ERRO!
▪ A maioria das ferramentas de forense não trabalha com imagens de partições,
apenas imagens de discos completas.
Lição #4:
Não fazer atalhos na fase de recolha. Normalmente só temos uma hipótese de
recolha.

14.
Estrutura de uma investigação forense
Recolha
Análise /
Investigação
Reporting
Análise / Investigação
▪ Não perder o foco
▪ É muito fácil perdermo-nos no palheiro à procura da agulha…
▪ Partir dos “sintomas” e caminhar do fim para o início

15.
“Ladrões de Bancos” - Análise
Tentar responder às questões (começar pelas mais simples):
▪ “Existe malware bancário?”
▪ Replicar comportamento do cliente (fazer login no banco)
▪ Fazer o dump da RAM na altura em que o comportamento malicioso se manifesta
(pedido de coordenadas da matriz, p. ex.)
Lição #5:
Partir sempre de perguntas simples para respostas simples. Não perder o fio à
meada. Apontar sempre testes efetuados e distinguir factos de conjeturas.

16.
Análise de RAM
▪ Volatility framework: http://www.volatilityfoundation.org/
▪ Procurar processos com DLL’s injetados (Internet Explorer, Chrome, Firefox)
▪ “malfind” plugin
▪ Procurar mecanismos de persistência
▪ “autoruns” plugin
▪ Procurar ligações de rede
▪ “netscan” plugin
▪ Em 90% das situações apenas precisamos da RAM para provar a existência de
malware.

17.
Análise do disco
▪ log2timeline: https://github.com/log2timeline
▪ Cria um ficheiro com todos os eventos possíveis de extrair de uma imagem do
disco:
▪ Sites visitados
▪ Ficheiros criados/acedidos/apagados
▪ Entradas de registry acedidas/escritas/modificadas
▪ Etc.
▪ No caso de uma instalação Windows XP com 7 anos, cria um ficheiro CSV com 6
GB.
▪ Como analisar?

18.
Análise do disco (2)
▪ Kibana - https://www.elastic.co/products/kibana
▪ Importar o ficheiro CSV numa base de dados elasticsearch
▪ Visualizar c/ Kibana
▪ Kibana é difícil de instalar.
▪ Truque: Docker

19.
Workflow típico
1. Analisar RAM dump (volatility)
a) Existem processos persistentes? DLL’s injetados no Internet Explorer?
b) Identificar executáveis maliciosos.
c) Onde estão no disco? Como lá foram colocados?
2. Analisar eventos no disco (log2timeline)
a) Que eventos coincidem com a data de criação dos ficheiros maliciosos?
b) Que sites foram visitados?
c) Que software foi instalado / executado?
3. Documentar tudo!

20.
Estrutura de uma investigação forense
Recolha
Análise /
Investigação
Reporting
Reporting
▪ Deve ser feito durante a análise
▪ Separar factos de conjeturas
▪ Nem todas as perguntas vão ter resposta (não inventar!)

21.
Exemplo de documentação – Test Log
Date/Time Test Results Notes
5/4/16 11:13
Search for injected
processes in RAM dump
Injected.txt Found x injected processes,
5/4/16 11:14
Search for currently
running processes
Pslist.txt Strange process id=9392,
INVESTIGATE
5/4/16 11:29
List TCP connections Connlist.txt FTP connection made to russia
server by process 7237

22.
Exemplo de documentação – Conclusões
Conclusões
FACTO
"Há duas backdoors no xyz, em c:123 e c:UsersblaAppsettings123y123.exe, ver tab
‘backdoors' para mais detalhe"
FACTO
Os logs do web server mostram um conjunto de tentativas de bruteforce ao backoffice do
wordpress. É MUITO PROVÁVEL que duas dessas tentativas de bruteforce, tenham tido
sucesso (tabs 'wp-login' e 'interesting-events‘)
INVESTIGAR
Investigar os possíveis acessos ao backoffice via russia e frança -- ver tab 'wp-login' e
'interesting-events'-- ver logs de backoffice wordpress para ver se houve logins bem
sucedidos nessas datas
TODO Mudar passwords de todos os users de backoffice
INVESTIGAR
Determinar há quanto tempo estão as backdoors na xyz directory. A data dos ficheiros não
deve ser fidedigna pelo que pode usar-se os backups para validar quando foi introduzido o
ficheiro.

23.
“Ladrões de Bancos” - Conclusões
▪ É relativamente fácil identificar malware num sistema de um sistema Windows
▪ É mais difícil perceber a sua origem
▪ Normalmente há mais do que um único malware…
▪ O malware tipicamente é distribuído de forma gradual:
▪ Primeira infeção com malware generalista
▪ O atacante introduz depois malware mais especializado para ataques específicos
▪ Em qualquer dos casos, a análise de RAM (c/ o volatility) responde-os a 99% das
questões, sem precisarmos de “escarafunchar” no disco.

24.
3. Clicks para o
leste

25.
“Clicks para o leste”
▪ 31 de Março 2016
▪ Site “high profile” é catalogado como inseguro pelo Google safe browsing
▪ Aparenta estar a distribuir malware e/ou roubar clicks para “click fraud”
▪ https://en.wikipedia.org/wiki/Click_fraud
▪ Site em Wordpress em sistema Linux
▪ PHP com um “iframe” malicioso, incluído em header.php

26.
Sobre o Wordpress
▪ WordPress is a free and open-source content management system (CMS) based
on PHP and MySQL. WordPress is installed on a web server, which either is part
of an Internet hosting service or is a network host itself;

27.
“Clicks para o leste”
▪ File malicioso: header.php
▪ Continha referências a javascript malicioso alojado noutros domínios (para click fraud)
▪ Quando é que o file foi alterado?
$ stat header.php-mau
File: `header.php-mau'
Size: 11086 Blocks: 133 IO Block: 32768 regular file
Device: 54h/84d Inode: 7544734515 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 4582/sites-xxx) Gid: (4582/sites-xxx)
Access: 2016-03-31 19:15:51.523212200 +0100
Modify: 2015-10-11 16:58:36.000000000 +0100
Change: 2016-03-31 22:04:10.494983773 +0100

28.
“Clicks para o leste”
$ stat header.php-mau
File: `header.php-mau'
Size: 11086 Blocks: 133 IO Block: 32768 regular file
Device: 54h/84d Inode: 7544734515 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 4582/sites-xxx) Gid: (4582/sites-xxx)
Access: 2016-03-31 19:15:51.523212200 +0100
Modify: 2015-10-11 16:58:36.000000000 +0100
Change: 2016-03-31 22:04:10.494983773 +0100
Lição #6:
É muito fácil um atacante confundir-nos. É muito mais difícil esconder todos os
traços da sua existência.
É fácil apagar pegadas na areia de uma praia deserta, mas fica lá a marca da
vassoura…
▪ Truque: “touch -t 11102016 header.php”

29.
“Clicks para o leste” – Questões a colocar
▪ Desde quando o site está comprometido?
▪ Como foi comprometido? Qual a vulnerabilidade?
▪ O atacante pode voltar a entrar?

30.
Estrutura de uma investigação forense
Recolha
Análise /
Investigação
Reporting
▪ Recolha:
▪ O auditor não tem acesso ao sistema (pede os ficheiros e output de comandos on-
demand)
▪ Acesso a logs do servidor Web
▪ Outro tipo de recolha: testes de segurança externos:
▪ Identificar eventuais vulnerabilidades externas

31.
Testes de intrusão
▪ Ferramenta de análise de segurança Wordpress:
▪ WPScan - http://wpscan.org/
▪ Resultados:
▪ É possível enumerar utilizadores de backoffice (do gestor de conteúdos):
▪ Lista de usernames válidos.
▪ Seguidamente tentou-se um teste simples (login == password)
▪ Não foi possível entrar.
▪ Será que alguém tentou o mesmo?

32.
Análise de logs Apache
▪ Logs (à partida) não comprometidos
▪ O sistema que armazena logs é distinto do sistema comprometido
▪ Procurar por acessos a páginas de backoffice:
▪ Ferramentas unix são indispensáveis:
grep " /xmlrpc.php" */* | awk '{print $1}' | cut -f2 -d:
grep "POST /wp-login.php" */*

33.
Tentativas de brute-force encontradas
1.2.3.4 - - [30/Mar/2016:12:43:12 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
1.2.3.4 - - [30/Mar/2016:12:43:13 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
1.2.3.4 - - [30/Mar/2016:12:43:15 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
1.2.3.4 - - [30/Mar/2016:12:43:17 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
1.2.3.4 - - [30/Mar/2016:12:43:18 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
1.2.3.4 - - [30/Mar/2016:12:43:20 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
1.2.3.4 - - [30/Mar/2016:12:43:20 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
1.2.3.4 - - [30/Mar/2016:12:43:21 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
1.2.3.4 - - [30/Mar/2016:12:43:22 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
1.2.3.4 - - [30/Mar/2016:12:43:23 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"
1.2.3.4 - - [30/Mar/2016:12:43:23 +0100] "POST /wp-login.php HTTP/1.0" 200 4060 "-" "Mozilla/5.0
(compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"

34.
Brute-force
▪ IP’s fora de Portugal
▪ Em algumas situações, o login aparenta ter sido bem sucedido
▪ O tamanho da resposta difere da resposta “Login inválido”
▪ Resultado: Lista de IP’s a investigar.
▪ Que outros acessos aqueles IP’s fizeram?

35.
Análise a listagem de ficheiros locais
▪ Que outros ficheiros suspeitos existem?
▪ Ficheiros PHP na diretoria de uploads? Hmm…
▪ Eram de facto backdoors PHP
▪ Foram acedidas na véspera do ataque ter sido detetado (os logs Web demonstram-no)
▪ (e foram utilizadas para modificar o header.php)
grep /uploads/ wp_all.txt | grep .php
[…]
tree/wp-content/uploads/2008/sys-config.php
tree/wp-content/uploads/2008/4e73ddcf58d0fae8ba48d7d5945c6aba.php
[…]

36.
“Clicks para o leste” – Respostas a questões
▪ Desde quando o site está comprometido?
▪ Pelo menos desde 30 de Março, muito possivelmente antes.
▪ TODO: Analisar backups anteriores para detetar quando as backdoors PHP foram
colocadas.
▪ Como foi comprometido? Qual a vulnerabilidade?
▪ Até agora desconhecida.
▪ TODO: poderá estar relacionada com logins bem sucedidos ao backoffce fruto de
tentativas de bruteforce de password. Investigar logs de backoffice wordpress para
saber quem entrou nas datas indicadas.
▪ O atacante pode voltar a entrar?
▪ As backdoors foram desabilitadas. Enquanto não se mudar as passwords de todos os
users de backoffice existe o risco de o site voltar a ser comprometido.

37.
Resumo e Conclusões

38.
Lições aprendidas
1. Os projetos de forense são quase sempre urgentes. É fundamental
estarmos preparados através de exercícios;
2. Não confiar num sistema comprometido. Os logs podem mentir, os ficheiros
podem estar escondidos, etc. Por outro lado é relativamente fácil encontrar
“discrepâncias” entre fontes diferentes.
3. Ter o equipamento e software pronto a usar. Na minha empresa temos uma
“mochila” de forense pronta a arrancar.

39.
Lições aprendidas (2)
4. A fase de recolha é que menos perdoa erros e esquecimentos.
Tipicamente só temos uma hipótese em fazer uma recolha.
5. “Jogar sempre de olho para a baliza”. Partir sempre de perguntas simples
para respostas simples. Não perder o fio à meada. Apontar sempre testes
efetuados e distinguir factos de conjeturas.
6. Documentar sempre durante a análise. Não é preciso escrever muito. Basta
apontar os factos, as conclusões principais, e as evidências em que se
baseiam.

40.
Perguntas e respostas
luis.grangeia@gmail.com
http://grangeia.io