Conhecimentos requeridos
Esta postagem possui um conteúdo com grau de complexidade de fácil para moderada. Aqui, assumo que o leitor possui domínio nos conceitos teóricos de Sistemas Operacionais (SO), conhecimentos sobre a estrutura de diretórios e hierarquias do SO Windows XP, e conhecimentos em rotinas básicas de análise forense computacional.
A imagem da memória analisada pode ser obtida no link http://repo.jeiks.net/memory/zeus.vmem.7z com os Hashes:
- MD5SUM: ebec0847119321e7c191956c19c18aa5
- SHA1SUM: 1e3662150e9c300f24fb2641d240b93299b4f4cc
Introdução
Esta publicação é resultado de um dos trabalhos realizados na disciplina de Computação Forense na minha graduação de Ciência da Computação. Antes de qualquer coisa, é importante dizer que o uso indevido das técnicas ou qualquer dano que o conteúdo abordado aqui possa ocasionar a si ou a outros é de responsabilidade do leitor. A intenção aqui é compartilhar minhas experiências, nada mais.
O primeiro passo tomado para a realização da perícia foi conhecer as funcionalidades da ferramenta utilizada, que nesse estudo é o software Volatility. Foram executados os comandos volatility –help e man volatility para analisar o que a ferramenta disponibiliza e como utiliza-la.
O primeiro passo tomado para a realização da perícia foi conhecer as funcionalidades da ferramenta utilizada, que nesse estudo é o software Volatility. Foram executados os comandos volatility –help e man volatility para analisar o que a ferramenta disponibiliza e como utiliza-la.
Depois
de conhecer a sintaxe e a semântica do software, foi testado todos
os comandos disponibilizados pela ferramenta para verificar como é
executado e o que retorna cada funcionalidade. Como o volume de dados
gerado por estes testes é grande, não é viável mostra-los aqui
(no total, os arquivos que gravaram o script somaram 64,2 MB).
Análise
Começando
a análise, vamos levantar as informações básicas sobre a imagem
da memória, como tipo de sistema operacional, usando o comando
volatility -f zeus.vmem imageinfo
e volatility -f
zeus.vmem kdbgscan. Com estes
comandos podemos ver que o SO é Windows XP Service
Pack 2 e que há 25
processos ativos.
Podemos
verificar quais são estes processos ativos com o comando volatility
-f zeus.vmem pslist e
volatility -f zeus.vmem psscan. Como
resultados temos:
Nestas
listas de processos não há nada conclusivo em relação ao que
poderia ser um malware, pois o dump de memória foi fornecido por
terceiros e não há como saber que tipo de software o indivíduo
estava usando quando foi realizado o dump. Assim, podemos realizar um
comando volatility -f
zeus.vmem pslist para
buscar referências cruzadas entre eles:
Neste
ponto analisamos se algum processo tem valor lógico falso entre
pslist e psscan e thrdproc. Quando tal situação ocorre, temos o que
é chamado de Manipulação de Objeto Diretamente no Kernel, ou DKOM
(Direct Kernel Object Manipulation). Através de um DKOM, um malware
pode esconder um processo malicioso de um pslist pois
ele consegue desvincular-se da lista EPROCESS usada pelo pslist para
percorrer os processos. Analisando o resultado do psxview não
consegue-se notar nenhum processo escondido.
Como
a análise dos processos não levantou informações relevantes,
podemos analisar as conexões
de rede e buscar alguma
informação. Verificando as conexões ativas no momento do dump com
o comando volatility -f zeus.vmem connections,
não foi encontrada nenhuma conexão. Tentando encontrar alguma
conexão na memória que tenha sido fechada com o comando volatility
-f zeus.vmem connscan
obtemos o seguinte resultado:
O
resultado do connscan mostra que duas conexões relacionadas ao
processo com PID 856, que no pslist está com o nome de
“svchost.exe”. Levantando as informações relativas ao ip remoto
através da ferramenta whois do site lacnic.net
(http://lacnic.net/cgi-bin/lacnic/whois?lg=EN)
obtemos o seguinte resultado:
---------------------------------------------------------------------------
inetnum: 193.104.41.0 - 193.104.41.255 netname: VVPN-NET descr: PE Voronov Evgen Sergiyovich country: MD org: ORG-PESV2-RIPE admin-c: ESV1-RIPE tech-c: ESV1-RIPE status: ASSIGNED PI mnt-by: VVPN-MNT mnt-by: RIPE-NCC-END-MNT mnt-lower: RIPE-NCC-END-MNT mnt-routes: VVPN-MNT mnt-domains: VVPN-MNT source: RIPE # Filtered organisation: ORG-PESV2-RIPE org-name: PE Voronov Evgen Sergiyovich org-type: OTHER descr: PE Evgen Sergeevich Voronov address: 25 October street, 118-15 address: Tiraspol, Transdnistria phone: +373 533 50404 admin-c: ESV1-RIPE tech-c: ESV1-RIPE mnt-ref: VVPN-MNT mnt-by: VVPN-MNT source: RIPE # Filtered person: Evgen Sergeevich Voronov address: 25 October street, 118-15 address: Tiraspol, Transdnistria phone: +373 533 50404 nic-hdl: ESV1-RIPE mnt-by: VVPN-MNT source: RIPE # Filtered % Information related to '193.104.41.0/24AS49934' route: 193.104.41.0/24 descr: PE Voronov Evgen Sergiyovich origin: AS49934 mnt-by: VVPN-MNT source: RIPE # Filtered
---------------------------------------------------------------------------
Pelas
informações levantadas pelo whois, o ip é do país Mondova.
Podemos verificar também se este IP esta inserido em uma blacklist,
usando a ferramenta disponibilizada no site http://www.ipvoid.com/.
O ipvoid mostra o seguinte resultado para este IP:
Como
este ip está na listado na black list do site Wot
(https://www.mywot.com/),
podemos considerar o endereço remoto como malicioso.
Até
aqui não vimos algum processo em particular que pareça
consideravelmente suspeito, porém alguns malware podem realizar uma
injeção de código nos processos. Para detectar detectar estas
injeções de código, podemos utilizar o plugin malfind.
Para uma analise mais limpa, vamos colocar o resultado do dump
realizado pelo malfind em uma pasta separada (que neste estudo é a
pasta ~/Downloads/zeus), executando então o comando volatility
-f zeus.vmem malfind
–dump- ~/Downloads/zeus. O resultado do comando produz um
conteúdo muito grande de informações do desassembler dos processos
e por isso não será mostrado aqui (O
resultado foi gravado em um arquivo externo, pois o terminal não
mostra todo o resultado),
também temos os seguintes arquivos de dump obtidos com a execução
do programa malfind:
Para
uma análise mais precisa, vamos exibir a árvore de processos com o
comando volatility -f zeus.vmem pstree
para termos uma visão de como um processo pode chamar o outro.
Realizando o comando temos o resultado abaixo:
Neste
ponto podemos ver que o processo “services.exe” pode ter uma
injeção de código, pois o processo Pid 856 têm ele como PPid e o
Pid 856 está fazendo uma conexão com um IP externo através de uma
conexão TPC pela porta 80, como vimos quando realizamos o connscan.
Normalmente o protocolo e a porta usada reportaria a um processo
relacionado a um navegador de internet, o que não acontece neste
caso. Também é prudente
suspeitar do processo winlogon.exe já que services.exe é chamado
sempre que se inicia o sistema operacional. Vamos
analisar o arquivo de dump criado com o malfind através da ferramenta
online virustotal (https://www.virustotal.com/pt/)
para tentar rastrear algum vírus. Primeiro o resultado para o
processo services.exe:
O
resultado da análise confirmou nossa suspeita, agora, vamos analisar
o processo winlogon.exe para verificar se há alguma infecção:
Realmente,
os processos parecem estar infectados com um malware zBot. E
provavelmente o processo é disparado sempre que o computador é
iniciado, pelo fato do processo winlogon.exe estar infectado. Vamos
ver quais as chaves de registro vinculados ao winlogon.exe para
tentar descobrir algum arquivo malicioso. Para realizar tal
verificação vamos usar o comando volatility -f zeus.vmem
-K “Microsoft\Windows NT\CurrentVersion\Winlogon”
que trás o seguinte resultado:
Neste
ponto podemos quer que há alguns programas que são executados,
inclusive um programa chamado sdra64.exe que não parece ser muito
conhecido. Realizando uma pesquisa rápida no mecanismo de busca do
site https://www.google.com.br/
vemos que há uma grande vinculação do processo com este nome e
extensão a uma infecção de vírus do tipo zBot.
Podemos considerar a possibilidade do malware ter desabilitado o firewall da máquina, assim, é mais fácil realizar conexões remotas e furtar informações. Vamos então analisar se o firewall foi desabilitado com o printkey. O resultado da execução do comando volatility -f zeus.vmem -K “ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\ StandardProfile” segue abaixo:
Como
era de se esperar, o firewall foi desabilitado. O que possibilita uma
facilidade maior para o roubo de informações do usuário infectado.
Vamos agora verificar se há algum objeto
mutante na memória. Para isso vamos considerar somente objetos que
possuem semáforos nomeados para realizar uma análise mais limpa
para este caso. O resultado do comando volatility -f
zeus.vmem mutantscan -s
é o seguinte:
O
objeto
_AVIRA_2109 é um processo estranho nesta lista, pois é o nome,
coincidentemente, de um software de antivírus famoso no mercado.
Realizando uma procura por este objeto no site de buscas da Google,
temos várias
referencias de sites que estabelecem uma relação entre o objeto
_AVIRA_2109
e
infecção de malware. Assim podemos afirmar que o objeto é sim uma
infecção de malware.
Conclusão
O
Software de análise de memória volátil Volatility possui ótimas
ferramentas para a análise de memória. Com ele foi possível
levantar uma série de informações sobre o malware Zeus e levou a
conclusão de que este malware é capaz algumas
ações, dispostas a seguir:
-
O malware realizou uma conexão TCP com um ip remoto que remete ao país da República da Móldova.
-
Também sabemos que houve uma injeção de código no processo services.exe e winlogon.exe.
-
Descobrimos que há uma chave de registro que inicia um processo chamado sdra64.exe, alocado no diretório C:\WINDOWS\system32\, que possui um histórico de infecções por malware zBot.
-
O firewall do sistema operacional foi desabilitado, o que nos leva a crer que o malware o desabilitou.
-
Verificamos um mutex no sistema operacional com o nome de _AVIRA_2109 que está relacionado com a infecção de malware.
Referências
Nenhum comentário:
Postar um comentário