Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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, te...
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...
“O Pirata” - Resposta
▪ Servidor Windows (Web + FTP)
▪ Site institucional
▪ Servidor offline, num datacenter
▪ Primeira an...
“O Pirata” - Resposta
▪ Correr o mesmo anti-vírus, fora da máquina:
▪ Mapeando o disco via SMB: sistemaC$
▪ 1 rootkit
▪ De...
“O Pirata”
Lição #3:
Vir preparado com o equipamento necessário para recolhas!
Lista de compras mínima:
▪ Pen USB de alta ...
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 i...
Estrutura de uma investigação forense
Recolha
Análise /
Investigação
Reporting
Recolha
▪ Fase mais sensível
▪ Estamos na c...
“Ladrões de Bancos” - Recolha
▪ Duas ferramentas de recolha essenciais:
▪ Live memory (RAM):
▪ MoonSols DumpIt: http://www...
“Ladrões de Bancos” - Recolha
▪ Numa das recolhas o disco de sistema era grande: 1TB
▪ Optei por copiar apenas a partição ...
Estrutura de uma investigação forense
Recolha
Análise /
Investigação
Reporting
Análise / Investigação
▪ Não perder o foco
...
“Ladrões de Bancos” - Análise
Tentar responder às questões (começar pelas mais simples):
▪ “Existe malware bancário?”
▪ Re...
Análise de RAM
▪ Volatility framework: http://www.volatilityfoundation.org/
▪ Procurar processos com DLL’s injetados (Inte...
Análise do disco
▪ log2timeline: https://github.com/log2timeline
▪ Cria um ficheiro com todos os eventos possíveis de extr...
Análise do disco (2)
▪ Kibana - https://www.elastic.co/products/kibana
▪ Importar o ficheiro CSV numa base de dados elasti...
Workflow típico
1. Analisar RAM dump (volatility)
a) Existem processos persistentes? DLL’s injetados no Internet Explorer?...
Estrutura de uma investigação forense
Recolha
Análise /
Investigação
Reporting
Reporting
▪ Deve ser feito durante a anális...
Exemplo de documentação – Test Log
Date/Time Test Results Notes
5/4/16 11:13
Search for injected
processes in RAM dump
Inj...
Exemplo de documentação – Conclusões
Conclusões
FACTO
"Há duas backdoors no xyz, em c:123 e c:UsersblaAppsettings123y123.e...
“Ladrões de Bancos” - Conclusões
▪ É relativamente fácil identificar malware num sistema de um sistema Windows
▪ É mais di...
3. Clicks para o
leste
“Clicks para o leste”
▪ 31 de Março 2016
▪ Site “high profile” é catalogado como inseguro pelo Google safe browsing
▪ Apar...
Sobre o Wordpress
▪ WordPress is a free and open-source content management system (CMS) based
on PHP and MySQL. WordPress ...
“Clicks para o leste”
▪ File malicioso: header.php
▪ Continha referências a javascript malicioso alojado noutros domínios ...
“Clicks para o leste”
$ stat header.php-mau
File: `header.php-mau'
Size: 11086 Blocks: 133 IO Block: 32768 regular file
De...
“Clicks para o leste” – Questões a colocar
▪ Desde quando o site está comprometido?
▪ Como foi comprometido? Qual a vulner...
Estrutura de uma investigação forense
Recolha
Análise /
Investigação
Reporting
▪ Recolha:
▪ O auditor não tem acesso ao si...
Testes de intrusão
▪ Ferramenta de análise de segurança Wordpress:
▪ WPScan - http://wpscan.org/
▪ Resultados:
▪ É possíve...
Análise de logs Apache
▪ Logs (à partida) não comprometidos
▪ O sistema que armazena logs é distinto do sistema comprometi...
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 "-" ...
Brute-force
▪ IP’s fora de Portugal
▪ Em algumas situações, o login aparenta ter sido bem sucedido
▪ O tamanho da resposta...
Análise a listagem de ficheiros locais
▪ Que outros ficheiros suspeitos existem?
▪ Ficheiros PHP na diretoria de uploads? ...
“Clicks para o leste” – Respostas a questões
▪ Desde quando o site está comprometido?
▪ Pelo menos desde 30 de Março, muit...
Resumo e Conclusões
Lições aprendidas
1. Os projetos de forense são quase sempre urgentes. É fundamental
estarmos preparados através de exercí...
Lições aprendidas (2)
4. A fase de recolha é que menos perdoa erros e esquecimentos.
Tipicamente só temos uma hipótese em ...
Perguntas e respostas
luis.grangeia@gmail.com
http://grangeia.io
Upcoming SlideShare
Loading in …5
×

Computer Forensics

997 views

Published on

[Portuguese] Slides de uma aula de forense em sistemas de informação que dei como convidado na cadeira de Cibersegurança Forense no Mestrado Mestrado em Segurança de Informação e Direito no Ciberespaço (MSIDC): https://fenix.tecnico.ulisboa.pt/cursos/msidc

Published in: Internet
  • Be the first to comment

Computer Forensics

  1. 1. Computer Forensics Histórias das trincheiras
  2. 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. 3. Histórias das trincheiras 1. “O pirata” 2. “Ladrões de bancos” 3. “Clicks para o leste”
  4. 4. 1. O pirata
  5. 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. 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. 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. 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. 9. 2. Ladrões de bancos
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. 3. Clicks para o leste
  25. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 37. Resumo e Conclusões
  38. 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. 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. 40. Perguntas e respostas luis.grangeia@gmail.com http://grangeia.io

×