SlideShare a Scribd company logo
1 of 40
Download to read offline
Computer
Forensics
Histórias das trincheiras
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
Histórias das trincheiras
1. “O pirata”
2. “Ladrões de bancos”
3. “Clicks para o leste”
1. O pirata
“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.
“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.
“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.
“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)
2. Ladrões de
bancos
“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?
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
“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
“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.
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
“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.
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.
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?
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
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!
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!)
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
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.
“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.
3. Clicks para o
leste
“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
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;
“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
“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”
“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?
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
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?
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" */*
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)"
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?
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
[…]
“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.
Resumo e Conclusões
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.
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.
Perguntas e respostas
luis.grangeia@gmail.com
http://grangeia.io

More Related Content

Similar to Histórias de computação forense

Faculdade: Trabalho sobre Seguranca Digital ( Versão em Slides )
Faculdade: Trabalho sobre Seguranca Digital ( Versão em Slides )Faculdade: Trabalho sobre Seguranca Digital ( Versão em Slides )
Faculdade: Trabalho sobre Seguranca Digital ( Versão em Slides )Rafael Biriba
 
XSS Desvendado
XSS DesvendadoXSS Desvendado
XSS Desvendadoricardophp
 
Introdução à Segurança da Informação
Introdução à Segurança da InformaçãoIntrodução à Segurança da Informação
Introdução à Segurança da InformaçãoVinicius Marangoni
 
Issa day ago 2010 defcon
Issa day ago 2010 defconIssa day ago 2010 defcon
Issa day ago 2010 defconAnchises Moraes
 
Certificação Digital (Conceitos e Tendências)
Certificação Digital (Conceitos e Tendências)Certificação Digital (Conceitos e Tendências)
Certificação Digital (Conceitos e Tendências)Jairo Junior
 
Análise de malware com software livre
Análise de malware com software livreAnálise de malware com software livre
Análise de malware com software livreDiego Santos
 
Ethical hacking: Conceitos básicos de Testes de penetração
Ethical hacking: Conceitos básicos de Testes de penetraçãoEthical hacking: Conceitos básicos de Testes de penetração
Ethical hacking: Conceitos básicos de Testes de penetraçãoCleórbete Santos
 
Ransomware - Conceitos e Prevenção
Ransomware - Conceitos e PrevençãoRansomware - Conceitos e Prevenção
Ransomware - Conceitos e PrevençãoMaurício Harley
 
Palestra: Pentest - Intrusão de Redes
Palestra: Pentest - Intrusão de RedesPalestra: Pentest - Intrusão de Redes
Palestra: Pentest - Intrusão de RedesBruno Alexandre
 
Sistema de segurança_web
Sistema de segurança_webSistema de segurança_web
Sistema de segurança_webFavsro Fot
 
Gov vs Hacker, como and os *.gov.br - Usando php avenger
Gov vs Hacker, como and os *.gov.br - Usando php avengerGov vs Hacker, como and os *.gov.br - Usando php avenger
Gov vs Hacker, como and os *.gov.br - Usando php avengerLenon Leite
 
Proteja sua Hovercraft: Mantendo sua nave livre dos Sentinelas ( Versão Segi...
 Proteja sua Hovercraft: Mantendo sua nave livre dos Sentinelas ( Versão Segi... Proteja sua Hovercraft: Mantendo sua nave livre dos Sentinelas ( Versão Segi...
Proteja sua Hovercraft: Mantendo sua nave livre dos Sentinelas ( Versão Segi...Alexandro Silva
 

Similar to Histórias de computação forense (20)

Faculdade: Trabalho sobre Seguranca Digital ( Versão em Slides )
Faculdade: Trabalho sobre Seguranca Digital ( Versão em Slides )Faculdade: Trabalho sobre Seguranca Digital ( Versão em Slides )
Faculdade: Trabalho sobre Seguranca Digital ( Versão em Slides )
 
"Hacking+PHP"
"Hacking+PHP""Hacking+PHP"
"Hacking+PHP"
 
XSS Desvendado
XSS DesvendadoXSS Desvendado
XSS Desvendado
 
Introdução à Segurança da Informação
Introdução à Segurança da InformaçãoIntrodução à Segurança da Informação
Introdução à Segurança da Informação
 
Ransomware
RansomwareRansomware
Ransomware
 
Analysis of vulnerabilities in web applications - LinuxCon Brazil 2010
Analysis of vulnerabilities in web applications - LinuxCon Brazil 2010Analysis of vulnerabilities in web applications - LinuxCon Brazil 2010
Analysis of vulnerabilities in web applications - LinuxCon Brazil 2010
 
Pentest conisli07
Pentest conisli07Pentest conisli07
Pentest conisli07
 
ISSA Day - Agosto
ISSA Day - AgostoISSA Day - Agosto
ISSA Day - Agosto
 
Issa day ago 2010 defcon
Issa day ago 2010 defconIssa day ago 2010 defcon
Issa day ago 2010 defcon
 
Certificação Digital (Conceitos e Tendências)
Certificação Digital (Conceitos e Tendências)Certificação Digital (Conceitos e Tendências)
Certificação Digital (Conceitos e Tendências)
 
Análise de malware com software livre
Análise de malware com software livreAnálise de malware com software livre
Análise de malware com software livre
 
Kali linux
Kali linux Kali linux
Kali linux
 
Segurança em Nuvem - Aspectos Práticos
Segurança em Nuvem - Aspectos PráticosSegurança em Nuvem - Aspectos Práticos
Segurança em Nuvem - Aspectos Práticos
 
Ethical hacking: Conceitos básicos de Testes de penetração
Ethical hacking: Conceitos básicos de Testes de penetraçãoEthical hacking: Conceitos básicos de Testes de penetração
Ethical hacking: Conceitos básicos de Testes de penetração
 
Ransomware - Conceitos e Prevenção
Ransomware - Conceitos e PrevençãoRansomware - Conceitos e Prevenção
Ransomware - Conceitos e Prevenção
 
Palestra: Pentest - Intrusão de Redes
Palestra: Pentest - Intrusão de RedesPalestra: Pentest - Intrusão de Redes
Palestra: Pentest - Intrusão de Redes
 
Sistema de segurança_web
Sistema de segurança_webSistema de segurança_web
Sistema de segurança_web
 
Análise de Malware
Análise de MalwareAnálise de Malware
Análise de Malware
 
Gov vs Hacker, como and os *.gov.br - Usando php avenger
Gov vs Hacker, como and os *.gov.br - Usando php avengerGov vs Hacker, como and os *.gov.br - Usando php avenger
Gov vs Hacker, como and os *.gov.br - Usando php avenger
 
Proteja sua Hovercraft: Mantendo sua nave livre dos Sentinelas ( Versão Segi...
 Proteja sua Hovercraft: Mantendo sua nave livre dos Sentinelas ( Versão Segi... Proteja sua Hovercraft: Mantendo sua nave livre dos Sentinelas ( Versão Segi...
Proteja sua Hovercraft: Mantendo sua nave livre dos Sentinelas ( Versão Segi...
 

More from Luis Grangeia

Inteligência Artificial: Breve Introdução
Inteligência Artificial: Breve IntroduçãoInteligência Artificial: Breve Introdução
Inteligência Artificial: Breve IntroduçãoLuis Grangeia
 
BSides Lisbon 2017 - Fantastic Signals and Where to Find Them
BSides Lisbon 2017 - Fantastic Signals and Where to Find ThemBSides Lisbon 2017 - Fantastic Signals and Where to Find Them
BSides Lisbon 2017 - Fantastic Signals and Where to Find ThemLuis Grangeia
 
Reverse Engineering the TomTom Runner pt. 1
Reverse Engineering the TomTom Runner pt. 1 Reverse Engineering the TomTom Runner pt. 1
Reverse Engineering the TomTom Runner pt. 1 Luis Grangeia
 
Heartbleed && Wireless
Heartbleed && WirelessHeartbleed && Wireless
Heartbleed && WirelessLuis Grangeia
 
Man vs Internet - Current challenges and future tendencies of establishing tr...
Man vs Internet - Current challenges and future tendencies of establishing tr...Man vs Internet - Current challenges and future tendencies of establishing tr...
Man vs Internet - Current challenges and future tendencies of establishing tr...Luis Grangeia
 
SSL: Past, Present and Future
SSL: Past, Present and FutureSSL: Past, Present and Future
SSL: Past, Present and FutureLuis Grangeia
 
IBWAS 2010: Web Security From an Auditor's Standpoint
IBWAS 2010: Web Security From an Auditor's StandpointIBWAS 2010: Web Security From an Auditor's Standpoint
IBWAS 2010: Web Security From an Auditor's StandpointLuis Grangeia
 

More from Luis Grangeia (7)

Inteligência Artificial: Breve Introdução
Inteligência Artificial: Breve IntroduçãoInteligência Artificial: Breve Introdução
Inteligência Artificial: Breve Introdução
 
BSides Lisbon 2017 - Fantastic Signals and Where to Find Them
BSides Lisbon 2017 - Fantastic Signals and Where to Find ThemBSides Lisbon 2017 - Fantastic Signals and Where to Find Them
BSides Lisbon 2017 - Fantastic Signals and Where to Find Them
 
Reverse Engineering the TomTom Runner pt. 1
Reverse Engineering the TomTom Runner pt. 1 Reverse Engineering the TomTom Runner pt. 1
Reverse Engineering the TomTom Runner pt. 1
 
Heartbleed && Wireless
Heartbleed && WirelessHeartbleed && Wireless
Heartbleed && Wireless
 
Man vs Internet - Current challenges and future tendencies of establishing tr...
Man vs Internet - Current challenges and future tendencies of establishing tr...Man vs Internet - Current challenges and future tendencies of establishing tr...
Man vs Internet - Current challenges and future tendencies of establishing tr...
 
SSL: Past, Present and Future
SSL: Past, Present and FutureSSL: Past, Present and Future
SSL: Past, Present and Future
 
IBWAS 2010: Web Security From an Auditor's Standpoint
IBWAS 2010: Web Security From an Auditor's StandpointIBWAS 2010: Web Security From an Auditor's Standpoint
IBWAS 2010: Web Security From an Auditor's Standpoint
 

Histórias de computação forense

  • 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”
  • 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)
  • 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.
  • 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.