Forense Computacional com Software Livre

Forense Computacional com Software Livre

Apresentação Luiz Vieira Especialista de Testes e Segurança Consultor de Segurança 16 anos de experiência em TI Pen-Tester, Perito Forense (CHFI) Articulista sobre Segurança de vários sites: VivaOLinux, SegurançaLinux, Imasters, HackProofing e etc Entusiasta do Software Livre Filósofo e Psicoterapeuta Blog: http://hackproofing.blogspot.com

Tópicos de hoje O que é Forense Computacional? Principais desafios da Forense Computacional Passos de uma Investigação Análise Viva e Post Mortem Distribuições Linux para Forense Ferramentas Livres e Toolkits para Forense Análise de memória física Demo: Análise de tráfego de rede com Xplico Demo: Recuperação de senhas Windows com Ophcrack Demo: Criação e análise de casos com o Autopsy Demo: Análise de memória física em busca de Malware do tipo Banking

Introdução & Ferramentas

O que é Forense Computacional? Uma série metódica de técnicas e procedimentos para coletar evidências de um sistema computadorizado, de dispositivos de armazenamento ou de mídia digital, que podem ser apresentadas em um fôro de uma forma coerente e de formato inteligível. - Dr. H. B. Wolf

Passos de uma Investigação

Principais desafios da Forense Computacional Ainda é mais uma arte do que ciência; Ainda está em seus estados iniciais de desenvolvimento; Há pouco conhecimento teórico sobre o qual as hipóteses empíricas são baseadas; Há falta de treinamento apropriado; Não há padronização de ferramentas.

Distribuições Linux para Forense FDTK Forensic Digital Toolkit Helix REMnux CAINE - Computer Aided INvestigative Environment DEFT Linux PeriBR Backtrack

Ferramentas Livres e Toolkits para Forense Toolkits Autopsy Framework Volatility Sleuth Kit The Coroner's Toolkit Ferramentas Centenas delas: Foremost Scalpel memdump shred Pasco etc, etc, etc...

Análise de Memória

Análise Viva e Post Mortem Dados Voláteis São informações que ficam armazenados na memória principal do computador. Isso quer dizer que elas possuem um ciclo de vida curto. Esse tipo de análise é chamada de Análise Viva. Dados não-voláteis Dados não voláteis, são dados que podem permanecer na máquina durante longos períodos de tempo e podem ser recuperados mesmo após a mesma ser desligada. As análises baseadas em dados armazenados em mídia de backup, pendrives, CDs, ou memória auxiliar como um HD, são chamadas de Análise Post-Mortem.

Análise de memória física A análise de memória física baseia-se em fazer um dump da memória física e virtual de um sistema. O que podemos conseguir através da memória física? Arquivos com senhas em texto puro Arquivos com variáveis de ambiente ($HISTFILE) O mapas de todos os serviços que se encontram em execução. Aplicações de terminal: memdump (posix) - http://www.porcupine.org/forensics/memdump1.0.tar.gz (solaris/bsd/linux) Configuração de memory dump do windows (windows)

Dump da memória Dump da memória é nome do processo de capturar as informações da memória, e pode ser feito através do comando dd: #dd < /dev/mem > mem.dump #dd < /dev/kmem > kmem.dump O investigador pode realizar buscas por palavras-chave através dos comandos grep e strings: #strings -a mem.dump grep palavra-chave

Diretório /proc O diretório /proc é um pseudo-sistema de arquivos usado como uma interface para as estruturas de dados do kernel do sistema operacional. A memória pode ser acessada pelo pseudo-arquivo /proc/kcore, que representa a memória física do sistema no formato de um core file. Buscando processos vinculados ao firefox: # strings -a /proc/kcore grep firefox > kcore_firefox.dump

Investigando Tráfego de Rede

Ferramentas de coleta de informações de rede Ferramentas de coleta de informações em redes são softwares que podem ser usados para obter dados da rede para análise forense. Estas ferramentas geralmente oferecem a funcionalidade de um sniffer e um sistema de detecção de intrusão combinadas. Sniffers Os sniffers operam na camada de enlace do modelo OSI. Isso significa que eles não têm que jogar pelas mesmas regras que as aplicações e serviços que residem nas camadas mais acima. Os sniffers podem capturar tudo e gravar para posterior análise. Eles permitem que o usuário analise todos os dados que estão contidos no pacote.

Análise de tráfego de redes A partir do tráfego de rede é possível analisar toda a comunicação entre atacante e máquina invadida, estabelecendo uma seqüência de eventos e comparando com as outras evidências encontradas. Um dos programas desse gênero mais popular é o tcpdump. # tcpdump -i eth0 host 10.10.0.1 O parâmetro -w do tcpdump permite armazenar os datagramas capturados em um arquivo binário para posterior análise: # tcpdump -w trafego.dump

Análise de tráfego de redes Com a análise dos datagramas pode-se encontrar evidências como: endereço IP inválido ou suspeito; tráfego em portas desconhecidas; tráfego em serviços ou portas que não deveria estar ocorrendo; datagramas com opções, flags ou tamanhos que não respeitam os padrões do protocolo (Request for Comment - RFC); flood de datagramas na rede; tráfego TCP em portas incomuns.

Captura de tráfego de rede com Xplico

Inicialização do DEFT & Xplico Para inicializar o Xplico, vamos utilizar a distribuição forense DEFT, pois já possui o Xplico instalado por padrão. Para tanto, vamos dar o boot em uma máquina virtual utilizando o DEFT.

Inicialização do DEFT & Xplico Após o boot com o DEFT, precisamos verificar se o dispositivo de rede está funcionando e configurado, com acesso à rede. Estando tudo ok, vamos iniciar a interface gráfica com o comando startx:

Inicialização do DEFT & Xplico Essa é a tela gráfica do DEFT, onde podemos ver o menu inicial, que reúne as ferramentas forenses, no canto inferior esquerdo:

Inicialização do DEFT & Xplico Para acessarmos o Xplico, precisamos clicar no menu DEFT > menu Computer Forensic > Xplico:

Acesso ao Xplico O Xplica será aberto automaticamente no browser, exibindo a tela de login. Os dados para acesso são exibidos na parte inferior da tela:

Configuração do Xplico Após logar, veremos a tela a seguir. Como não temos nenhum caso configurado, a tela estará em branco, como se segue. E para criarmos um caso, clicamos no menu NewCase:

Configuração do Xplico Para criarmos um caso, precisamo definir seu nome, uma referência externa, e se os dados serão originados de um arquivo pcap gerado anteriormente, ou se realizaremos uma Live Acquisition:

Configuração do Xplico OK! Caso criado e configurado, precisamos clicar sobre o nome do caso para configurarmos a captura do tráfego de rede:

Configuração do Xplico Como não temos ainda nenhuma sessão de captura e análise do tráfego de rede, precisamos, nessa tela, clicarmos em NewSession:

Configuração do Xplico Nesse ponto, daremos um nome à sessão que será criada, e clicamos em Add:

Configuração do Xplico A sessão foi criada, mas não inicializada. Para isso, clicamos no nome da sessão para irmos para a tela de configuração da sessão:

Utilização do Xplico Precisamos, antes de iniciar a captura dos dados, selecionar qual o dispositivo de rede que ficará em modo promíscuo, capturando os dados. Após isso, clicamos em Start e aguardamos a captura do tráfego gerado pelas máquinas existentes na rede:

Utilização do Xplico Depois de um tempo, clicamos em Stop e aguardamos a decodificação do tráfego. Quando o Xplico terminar essa fase, permitirá que selecionemos o tráfego gerado por um host específico para analisarmos o mesmo:

Resultados Aqui, podemos selecionar que tipo de dados queremos visualizar a partir do que foi capturado na rede. Na figura abaixo, vemos os dados de páginas WEB, e quano clicamos nos links, as páginas são remontadas e exibidas:

Recuperação de senhas de Windows com Ophcrack

Utilização do Ophcrack Precisamos dar o boot com o Ophcrack na máquina executando o Windows, para podermos recuperar sua senha. A seguinte tela é exibida ao iniciar o Ophcrack. Selecionamos a primeira opção:

Utilização do Ophcrack Logo que o Ophcrack se inicia, uma tela é carregada automaticamente, onde os usuários existentes na máquina Windows sejam exibidos e a Rainbow Tables são carregadas na memória:

Utilização do Ophcrack Depois de um tempo aguardando, o Ophcrack consegue recuperar as senhas de todos os usuários do sistema Windows:

Autopsy / SleuthKit

Objetivos Aprender a como montar e configurar um caso no Autopsy Entender os passos necessários para realizar uma investigação utilizando o Autopsy Utilizar ferramentas de criação de linha do tempo a partir dos MACtimes dos arquivos recuperados

Criando um novo Caso Para criar um novo caso, o investigador deverá entrar com alguns dados tais como: Nome: um nome para o novo caso Descrição: uma breve descrição do caso (opcional) Investigadores envolvidos: nome dos investigadores envolvidos no caso (opcional)

Criando um novo Caso Após a criação de um novo caso, o mesmo é aberto e o investigador é guiado através de uma série passos, onde serão cadastradas as máquinas sob investigação e suas respectivas mídias (imagens extraídas destas). A figura a seguir mostra a tela de configuração do novo host a ser adicionado.

Criando um novo Caso Para cada host cadastrado, o perito poderá adicionar ainda um conjunto de arquivos contendo imagens extraídas das máquinas apreendidas. Estas imagens podem ter sido extraídas de discos rígidos do sistema. As figuras a seguir mostram o processo de inclusão de imagens para análise posterior.

Criando um novo Caso

Criando um novo Caso Concluída a inclusão das imagens, o host está pronto para ser analisado e o perito pode então iniciar o processo de análise dos dados contidos nas imagens.

Estudo de caso: sistema Linux comprometido

Estudo de caso: Sistema Linux comprometido O sistema em questão era um honeypot de alta interatividade, que foi comprometido por um atacante, visando ganhar o controle total do sistema através da esclada de privilégios. Inicialmente, vamos entender um pouco mais sobre o sistema comprometido: O sistema executava uma instalação padrão do Linux Red Hat Server 6.2. A time zone do sistema estava configurada para GMT-0600 (CST). Algumas informações foram detectadas e logadas pelo IDS instalado.

Estudo de caso: Sistema Linux comprometido Uma cópia bit-a-bit das partições ativas foi obtida, como detalhado abaixo: /dev/hda8 / /dev/hda1 /boot /dev/hda6 /home /dev/hda5 /usr /dev/hda7 /var /dev/hda9 swap Os arquivos de imagem pode ser montados em sistemas Linux usando a interface de loopback, como a seguir: # mkdir /t # mount -o ro,loop,nodev,noexec honeypot.hda8.dd /t # mount -o ro,loop,nodev,noexec honeypot.hda1.dd /t/boot [ etc... ]

Estudo de caso: Sistema Linux comprometido As questões a seguir, servem mais como diretrizes, para sabermos o qual tipo de prova encontrar e no que precisamos nos concentrar: Identificar o método de invasão, a data e a hora. Identificar, tanto quanto possível, as informações sobre o(s) intruso(s). Lista de todos os arquivos que foram adicionados/modificados pelo intruso. Fornecer uma análise desses programas. Havia um sniffer instalado? Se sim, onde e quais arquivos estão associados com ele? Haveria um "rootkit" ou ocultação de outros programas de cavalo de tróia instalado no sistema? Se sim, quais programas do sistema operacional foram substituídos? Construir uma linha do tempo dos acontecimentos e fornecer uma análise detalhada da atividade no sistema, observando as fontes de apoio ou confirmação de provas.

Estudo de caso: Sistema Linux comprometido Para descompactar o arquivo com as imagens: # tar xvf challenge-images.tar E para descompactar as imagens coletada: # for i in 1 5 6 7 8 9 > do > gunzip honeypot.hda$i.dd.gz > done Para montar as imagens precisamos criar os pontos de montagem: # mkdir /t # mkdir /t/boot # mkdir /t/home # mkdir /t/usr # mkdir /t/var

Estudo de caso: Sistema Linux comprometido E a montagem das imagens: # mount -o ro,loop,nodev,noexec honeypot.hda8.dd /t # mount -o ro,loop,nodev,noexec honeypot.hda1.dd /t/boot # mount -o ro,loop,nodev,noexec honeypot.hda6.dd /t/home # mount -o ro,loop,nodev,noexec honeypot.hda5.dd /t/usr # mount -o ro,loop,nodev,noexec honeypot.hda7.dd /t/var

Estudo de caso: Sistema Linux comprometido "ils" e "ils2mac" foram usados para obter os horário de MAC de exclusão dos inodes nas partições 1, 5, 6, 7 e 8. Os arquivos resultantes foram então combinados com os valores obtidos através da execução do "grave-robber" contra o sistema de arquivos raiz em "/t", para incluir os inodes excluídos juntamente com os inodes ativos. # grave-robber -c /t -m -d. -o LINUX2 # for i in 1 5 6 7 8 > do > ils honeypot.hda$i.dd ils2mac > hda$i.ilsbody > done # ls -l *body

Estudo de caso: Sistema Linux comprometido Depois que visualizamos os arquivos gerados, vamos organizá-los melhor: #for i in 1 5 6 7 8 > do > cat hda$i.ilsbody >> body-deleted > done # cat body body-deleted > body-full # mactime -p /t/etc/passwd -g /t/etc/group -b body-full \ 11/06/2000 > mactime.txt # vim mactime.txt Recuperação, verificação e visualização de arquivo apagado: # icat honeypot.hda8.dd 8133 > foo # file foo # tar -tvf foo # tar -xvf foo <Analisar os arquivos recuperados>

Estudo de caso: Sistema Linux comprometido O script de instalação para o bot eggdrop foi encontrado, enquanto buscando por arquivos deletados: # grep -i " tpack " * # less `grep -i " tpack " * awk '{print $3;}'` Após o carregamento do arquivo.tar, o invasor parece desempacotar outro arquivo tar no diretório /t/usr/man/.ci. Isso é possível verificar no mactimes.txt. Há, inclusive uma cópia do inetd encontrada no diretório.ci, que difere do utilizado pelo sistema real da máquina comprometida: # md5sum /t/usr/sbin/inetd /t/usr/man/.ci/inetd

Estudo de caso: Sistema Linux comprometido Logo em seguida, o invasor cria um link do.bash_history tanto do / quanto do /root para o /dev/null, numa tentativa de desabilitar o log history. Seguindo adiante, podemos encontrar uma lista os arquivos em /t/usr/man/.ci que foram criados ou executados pelo invasor. Isso mostra a substituição dos seguintes arquivos do sistema operacional, pelas versões de um rootkit com cavalo de tróia: ls, ps, netstat, tcpd e top. Executando o comando strings no arquivo /t/bin/ls, é exibido o nome do arquivo e configuração do rootkit /usr/man/r. <Analisar arquivo>

Estudo de caso: Sistema Linux comprometido Já o programa snif que podemos ver pelo mactimes.txt dentro do./ci é o sniffer linsniff. O mesmo foi executado, mas o sniffer não conseguiu logar nenhuma conexão. De acordo com o mactimes, as 06:53:06, o invasor instalou um servidor SSH, gerou um novo par de chaves pública/privada, e modificou o arquivo /t/etc/rc.d/rc.local finalizando-o com a linha /usr/local/sbin/sshd1 (iniciando o daemon em cada reboot). E finalmente podemos ver o daemon do ssh1 iniciado. O inode deletado com a propriedade 1010/users suspeito. Após recuperado, encontramos o script de instalação do sshd: # icat honeypot.hda5.dd-dead-109802 > 1010_users # file 1010_users # cat 1010_users

Estudo de caso: análise de memória, em busca de malware do tipo banking

Estudo de caso: análise forense de malware, do tipo banking A empresa X entrou em contato com você para realizar um trabalho de perícia forense em um incidente que ocorreu recentemente. Um dos empregados recebeu um e-mail de um companheiro de trabalho que possuía um link para um arquivo.pdf. Ao abrir o arquivo, o funcionário não percebeu nada de estranho. Entretanto, recentemente ele percebeu atividades não-usuais em sua conta bancária. A empresa X conseguiu obter uma imagem da memória da máquina virtual do funcionário que está com suspeita de comprometimento. E a empresa deseja que você analize a memória e reporte qualquer atividade suspeita encontrada.

Estudo de caso: análise forense de malware, do tipo banking As questões abaixo devem seguir como base para nortear o processo de investigação: 1. Liste os processos que estavam em execução na máquina da vítima. Qual o processo mais provável de ser responsável pela exploração inicial? 2. Liste os sockets que estavam abertos na máquina da vítima durante a infecção. Existem processos suspeitos com sockets abertos? 3. Liste todas as URLs suspeitas que possam estar na memória do processo. 4. Há quaisquer outros processos que contêm URLs que podem apontar para problemas bancários? Em caso afirmativo, quais são esses processos e quais são as URLs? 5. Estavam lá todos os arquivos que puderam ser extraídas do processo inicial? Como esses arquivos foram extraídos? 6. Se houver algum arquivo extraído do processo inicial, quais as técnicas que usou para realizar a exploração? 7. Liste os arquivos suspeitos que foram carregados por todos os processos na máquina da vítima.

Estudo de caso: análise forense de malware, do tipo banking Baixar Volatility, pdfid, pdf-parser # wget https://www.volatilesystems.com/volatility/1.3/volatility-1.3_beta.tar.gz # wget http://www.didierstevens.com/files/software/pdfid_v0_0_11.zip # wget http://www.didierstevens.com/files/software/pdf-parser_v0_3_7.zip http://www.forensicswiki.org/wiki/list_of_volatility_plugins

Estudo de caso: análise forense de malware, do tipo banking 1. Liste os processos que estavam em execução na máquina da vítima. Qual o processo mais provável de ser responsável pela exploração inicial? # python volatility pslist -f Bob.vmem AcroRd32.exe Este é um processo do Acrobat Reader, abeto a partir do processo com o PID 888, Firefox. 1752 888 8 184 Sat Feb 27 20:12:23 2010

Estudo de caso: análise forense de malware, do tipo banking 2. Liste os sockets que estavam abertos na máquina da vítima durante a infecção. Existem processos suspeitos com sockets abertos? Usando o Volatility para listar os sockets: # python volatility sockets -f Bob.vmem Informações cruzadas a partir da lista de conexões: # python volatility connections -f Bob.vmem

Estudo de caso: análise forense de malware, do tipo banking Temos dois endereços IP suspeito: 193.104.22.71 (Malta hosting) e 212.150.164.203 (Israeli hosting registrado com o nome search-network-plus.com ). Informações conseguidas a partir do whois podem nos dar algumas pistas: # whois search-network-plus.com # whois 193.104.22.71 Apenas um processo está conectado com o Malta hosting: PID 880 svchost.exe. Dois processos estão conectados com Israeli hosting: PID 888 firefox.exe e PID 1752 AcroRd32.exe Outros sockets suspeitos abertos são: listening socket, TCP port 1030, PID 4 (pode ser uma porta de um serviço Windows) connected socket, TCP port 2869, endereço remoto 192.168.0.1:30380 (não é exibido na lista de sockets abertos, pode estar com o status CLOSE_WAIT ) listening socket, TCP port 30301, PID 880 dois sockets conectados, TCP port 1184 e 1185, endereço remoto 193.104.22.71 HTTP port PID 880 socket conectado, TCP port 2869, endereço remoto 192.168.0.1:30379 PID 1244 socket conectado, TCP port 1189, endereço remoto 192.168.0.1:9393 PID 1244

Estudo de caso: análise forense de malware, do tipo banking 3. Liste todas as URLs suspeitas que possam estar na memória do processo. Podemos obter o dump do endereço da memória do processo suspeito usando o Volatility: # python volatility memdmp -p 880 -f Bob.vmem O arquivo resultante possui cerca de 93mb. Utilizando busca por string em busca de IPs e os nomes dos hosts anteriores (193.104.22.71, 212.150.164.203, search-network-plus.com) podemos chegar a resultados interessantes: http://193.104.22.71/~produkt/9j856f_4m9y8urb.php http://193.104.22.71/~produkt/69825439870/73846525#n http://193.104.22.71/~produkt/983745213424/34650798253 http://search-network-plus.com/cache/pdf.php?st=internet%20explorer%206.0 Fazendo o mesmo com o processo do Acrobat Reader, PID 1752, há algumas referências ao search-network-plus.com: http://search-network-plus.com/load.php?a=a&st=internet Explorer 6.0&e=2 http://search-network-plus.com/load.php?a=a&st=internet%20explorer%206.0&e=2 http://search-network-plus.com/load.php?a=a&st=internet Explorer 6.0&e=3 and a couple of references to Israeli hosting IP address: 212.150.164.203

Estudo de caso: análise forense de malware, do tipo banking 4. Há quaisquer outros processos que contêm URLs que podem apontar para problemas bancários? Em caso afirmativo, quais são esses processos e quais são as URLs? No dump da memória do processo com PID 888 (firefox.exe): http://search-network-plus.com/cache/pdf.php?st=internet%20explorer%206.0 http://search-network-plus.com/favicon.ico Ambos os links estão também na memória do processo com PID 1244 (svchost.exe) A parte mais interessante vem da string no dump da memória do PID 644. No offset 0x148b68 da imagem da memória ha uma string: Ahttps://onlineeast#.bankofamerica.com/cgi-bin/ias/*/GotoWelcome É uma codificação para a redirect/fake URL usada no arquivo de configuração C:\WINDOWS\system32\lowsec\user.ds para o site do banco alvo para phishing ou injetar HTML em formulários online.

Estudo de caso: análise forense de malware, do tipo banking 5. Estavam lá todos os arquivos que puderam ser extraídas do processo inicial? Como esses arquivos foram extraídos? Após o dumping da memória do processo com o Volatility: Podemos usar o foremost na imagem resultante da memória, chamada 1752.dmp: # python volatility memdmp -p 1752 -f Bob.vmem # foremost -i 1752.dmp -o pid1752 Podemos assumir que o exploit inicial foi arquivo PDF malicioso, então verificamos o arquivo pdf da saída do comando foremost (pid1752/pdf/). Há sete arquivos, todo totalmente ou parcialmente corrompidos. Cinco arquivos são realmente pequenos (menos de 500 bytes), os últimos dois são mais interessantes, 60kb e 600kb de tamanho, respectivamente nomeados de 00599696.pdf e 00600328.pdf. Ambos os arquivos não serão extraídos caso o foremost seja executado em cima da imagem completa da memória, apenas se for sobre a imagem da memória do processo AcroRd32.exe.

Estudo de caso: análise forense de malware, do tipo banking O arquivo de 60kb está encriptado, mas não contém seções "ativas", de acordo com a saída do comando pdfid.py: # python pdfid.py 00599696.pdf Sem /OpenAction, sem /JS, nem /Javascript. Uma surpresa, porém, surge do outro documento: # python pdfid.py 00600328.pdf

Estudo de caso: análise forense de malware, do tipo banking 6. Se houver algum arquivo extraído do processo inicial, quais as técnicas que usou para realizar a exploração? Ele utiliza uma falha bem conhecida no PDF. Usando o pdf-parser podemos rastrear a estrutura do PDF malicioso. Primeiro buscamos qual seção refere-se ao bloco javascript (id 1054 no arquivo PDF): # python pdf-parser.py --search javascript --raw 00600328.pdf obj 11 0 Type: Referencing: 1054 0 R

Estudo de caso: análise forense de malware, do tipo banking Então, objeto 11 refere-se ao javascript. Usando o mesmo comando: # python pdf-parser.py -f -r 11./00600328.pdf Referencing: 787 0 R, 1847 0 R, 11 0 R << /Parent 787 0 R /Resources 1847 0 R /Type /Page /AA /O 11 0 R >> # python pdf-parser.py -f -r 1054./00600328.pdf # python pdf-parser.py --object 1054 --raw --filter 00600328.pdf > malicious.js

Estudo de caso: análise forense de malware, do tipo banking Isso quer dizer: quando a página é exibida (é a única página) uma ação é executada (/AA significa "Add Action"): ativar o objeto 11, que se refere ao objeto 1054, o javascript malicioso. Agora, precisamos da versão desobsfuscada do javascript, então vamos analizar o código. No byte 83506 há uma chamada de função: HNQYxrFW(eval,VIfwHVPz(xtdxJYVm,JkYBYnxN),BGmiwYYc) A função é definida no byte 83161: function HNQYxrFW(KChuBWpl,aTkRRqKD,HVqLGmiA){KChuBWpl(HVqLGmiA(aTkRRqKD));}

Estudo de caso: análise forense de malware, do tipo banking O único propósito da função é ocultar uma chamada para a função eval(). Utilizando métodos normais de desobsfuscação não conseguimos chegar muito longe, então editamos um pouco o javascript para torná-lo mais legível e colocamos entre tags <script>: <script language="javascript"> var xtdxjyvm='011110000010101100000...' var JkYBYnxN='011100100100110101...' return VzBJVOyp;}

Estudo de caso: análise forense de malware, do tipo banking 7. Liste os arquivos suspeitos que foram carregados por todos os processos na máquina da vítima. A partir desta informação, o que um possível payload da exploração inicial poderia fazer que estaria afetando a conta bancaria da vítima? Usando o Volatilily para listar os arquivos abertos por todos os processos: # python volatility files -f Bob.vmem Podemos buscar arquivos abertos no momento em que foi feito o dump da memória. Processo AcroRd32.exe (PID 1752) carregou: File \DOCUME~1\ADMINI~1\LOCALS~1\Temp\plugtmp\PDF.php

Estudo de caso: análise forense de malware, do tipo banking Podemos ver um arquivo.php relacionado a URL: http://search-network-plus.com/cache/pdf.php?st=internet%20explorer%206.0 encontrada no processo do Firefox, e pode estar relacionada ao download inicial do PDF malicioso (como um link no e-mail do funcionário). Mais interessante é o processo 644 (winlogon.exe): # python volatility files -p 644 -f Bob.vmem File \WINDOWS\system32\sdra64.exe File \WINDOWS\system32\lowsec\user.ds File \_AVIRA_2109 File \WINDOWS\system32\lowsec\local.ds Podemos ver os arquivos relacionados ao malware em questão. A partir daqui, o processo torna-se mais complexo e adentrando ainda mais nos domínios das técnicas de análise de malware.

Obrigado!!!! Luiz Vieira luizwt@gmail.com https://groups.google.com/group/exploits-brasil hackproofing.blogspot.com Tel: 55-11-6429-0505