ROTEIRO DA AULA 16

-------- 1ª PARTE ---------

-configurar o kernel debugging remoto de acordo com a página 142 da apostila.

-após configurar e conectar na máquina virtual, no WinDbg:

> habilitar verbose no WinDbg

> ctrl break (gera um breakpoint e para o Windows debugado) e g (continua a

execução)

> lm (lista os módulos carregados no kernel)

> x nt!*CreateProcess* (busca funções no kernel com esse nome)

> bp nt!NtCreateProcessEx (coloca breakpoint)

> bl (lista de breakpoints)

> g (libera o windows)

- executar o firefox no windows debugado

> r (ver registradores)

> bc * (breakpoint clean)

> g

- mostrar firefox abrindo na tela de baixo

> x nt!*WriteFile*

> bp nt!NtWriteFile "r esp,ebp; g"

- mostrar a execucao do windows e a tela de resultado

> bc *

> g (tentar deixar máquina conectada em kernel debugging)

- site do windbg com comandos: http://windbg.info/doc/1-common-cmds.html

-------- 2ª PARTE ---------

- abrir malware Lab-09-02.exe no IDA

- ver strings

- ver IDA Imports:

CreateServiceA
OpenSCManager
StartServiceA
CloseServiceHandle

- ver funções relacionadas a criação de arquivos:

CreateFile
WriteFile

- ver funções relacionadas ao Resources:

LoadResource
SizeOfResource
FindResource

- abrir Resource Hacker e ver o PE Header (MZ)

- executar o Process Monitor com filtro relacionado ao processo do malware

- rodar o malware

- parar process monitor e mostrar resultados

arquivo foi criado (com sucesso)

procurar o arquivo em system32 (não existe)
não foi deletado porque não saiu no relatório do ProcMon

- verificar no Process Explorer se tem algum processo rodando

- procurar o arquivo pelo DOS

- executar Autoruns, ir verificando as abas até Driver (vai estar lá)

- executar no cmd:

> sc query "486 WS Driver" (mostra informações do driver que está rodando)

---------

- com o WinDbg ainda ativado para kernel debugging

- verificar se o serviço está rodando

> lm (busca o nome do driver)

- analisar SSDT para ver alguma alteração:

> dd dwo(KeServiceDescriptorTable) L100 (mostra os endereços da SSDT)

(dd: verificar memória, dwo: formatação)

- modulo malicioso tem que começar com 0xf8d4... (foge do padrão)

> dds poi(KeServiceDescriptorTable) L200 (exibe a SSDT com nomes das funções)

- mostrar a função que está hookando na SSDT (pegar o endereço da função)

- restaurar o snapshot para ver qual função estava no lugar dela

- NtQueryDirectoryFile (mostrar MSDN falando do que a função faz)

retorna informações sobre os arquivos que estão no diretório

- porque o rootkit está hookando ela?

> .detach (sai o debug do windows)

- reiniciar o windows e ver se o driver está rodando

- não vai estar e então o arquivo vai ser exibido no system32

* Esse Lab foi retirado do livro Practical Malware Analysis e a solução detalhada
dele pode ser conferida a partir da página 554.