Análise em Memória Volátil: Malware Cridex, Trojan Banker
Nesta primeira postagem na plataforma PingBack, trarei a vocês a minha análise técnica em memória volátil do Malware Cridex, Sem mais delongas vamos ao que interessa!
Nesta primeira postagem na plataforma PingBack, trarei a vocês a minha análise técnica em memória volátil do Malware Cridex, Sem mais delongas vamos ao que interessa! | ||
Para desenvolver está análise, utilizei um conhecido software forense, voltado para memória volátil chamado : Volatility. | ||
Essa ferramenta nos ajudará no processo de inspecionar um despejo de memória volátil de um computador potencialmente infectado. Este software nos ajudará a recuperar informações úteis para nós (os últimos arquivos modificados, os processos em execução, etc...) armazenadas na memória do computador. | ||
Para começo, utilizando o software Volatility apliquei o plugin imageinfo, onde consegui identificar informações sobre a imagem, entre elas o sistema operacional do computador de onde vem esse despejo de memória (WinXPSP2x86). | ||
| ||
Como agora temos o sistema operacional do arquivo analisado, podemos especificar a volatilidade do perfil (--profile = WinXPSP2x86), e por meio dele tentar encontrar o que aconteceu no computador da vítima. Iremos começar então analisando os processos e processos pais em execução utilizando o plugin pstree. | ||
| ||
À primeira vista, podemos notar um processo estranho chamado “reader_sl.exe” com o “explorer.exe” (PPID = 1484) como processo pai , que foi um dos últimos processos em execução na máquina. deixaremos anotado está informação e continuaremos observando outros indicadores, vamos extrair da imagem em questão outros fatores importantes a serem analisados como verificar os soquetes em execução e abrir as conexões no computador para averiguação. Utilizei então respectivamente os plugins connscan e sockets. | ||
| ||
| ||
O plugin connscan é um scanner para conexões TCP, enquanto sockets irá imprimir uma lista de sockets abertos. Pode se observar com esses resultados duas conexões TCP que são usadas pelo processo PID 1484 (observando as saídas de histórico de comando, podemos facilmente vincular o PID 1484 ao processo explorer.exe). Podemos ver que uma dessas conexões TCP ainda está aberta, a que usa a porta 1038 e se comunica com o endereço IP de destino 41.168.5.140. | ||
Em busca de mais informações, vasculhei os últimos comandos executados, usando o plugin cmdline . Este plugin exibe os argumentos da linha de comando do processo, e com ele descobrimos o caminho completo dos processos iniciados com PID 1484 e 1640. Sera que o processo “Reader_sl.exe” é um meliante (kkkk)?? | ||
O que podemos afirmar até então é que este processo foi lançado pelo processo explorer, e possivelmente é um classico aplicativo Adobe Reader (muito usado no ano em questão, 2012). Porém, já foi observado uma conexão em execução para um IP externo usado por este processo... | ||
Antes de afirmarmos algo, vamos vasculhar o executável em questão utilizando os seguintes plugins: procdump e memdump: | ||
| ||
| ||
O primeiro arquivo “executable.1640.exe” é uma restituição do executável “Reader_sl.exe” e o dump extraído “1640.dmp” representa a memória endereçável do processo. Com os artefatos em mãos, pude analiza-los com o comando "strings" do linux, utilizaremos ele com o auxílio do comando grep pois estamos procurando por uma relação entre a parte da informação já recuperada do dump (especificamente a conexão tcp aberta para o IP 41.168.5.140) e este processo 1640. | ||
| ||
Para esclarecer o comando acima, foi feita a leitura de todas as strings dentro do arquivo em busca do IP 41.168.5.140. O comando grep combinado com o -C VALOR foi utilizado para obter as linhas anteriores e posteriores ao valor procurado, dando-nos assim mais contexto para as informações que queríamos encontrar. Aqui pode-se notar que o executável “Reader_sl.exe” está se comunicando com o IP de destino 41.168.5.140 usando de solicitações POST, podemos supor que está exfiltrando informações do computador da vítima. | ||
Não satisfeito com estes resultados decidi então investigar com mais calma o arquivo, utilizando o "less" no arquivo "1640.dmp", pude encontrar alguns domínios intrigantes. | ||
| ||
Uma lista de domínios bancários. Foi isso que foi encontrado dentro da memória do processo, agora o arquivo “Reader_sl.exe” está praticamente condenado como meliante (kkk). Só nos faltou então ver se o executável é malicioso ou não. | ||
Como ainda não me sinto confortável para fazer uma análise estática, recorri a análise dinâmica para finalizar nosso trabalho. Utilizei o Vírus Total, o mesmo é um serviço online que permite analisar arquivos em busca de padrões, reconhecimento de hash e outras técnicas a ponto de classificar como malicioso/não malicioso. | ||
Obs: A ferramenta é ideal para quem não tem um antivírus instalado no PC ou gostaria de uma segunda opinião, para ter certeza que um arquivo é malicioso ou não. | ||
| ||
Podemos ver então que definitivamente este arquivo é um Malware . Utilizando o Hybrid Analysis pude extrair mais informações, a primeira de todas foi a confirmação que o arquivo é um clássico aplicativo Adobe Reader. | ||
| ||
A segunda coisa que pudemos coletar com a análise do Hybrid Analysis, é que o arquivo em questão possui técnicas contra Engenharia Reversa, contém capacidade de consultar o tempo da máquina e utiliza técnicas de instalação e persistência no ambiente. | ||
| ||
Sem sombra de dúvidas as duas fontes de consultas que utilizamos nos mostrou a real faceta do arquivo " executable.1640.exe". Logo abaixo então, iremos pontuar o que já conseguimos de informações em toda a investigação: | ||
| ||
| ||
Se esta imagem de memória volátil foi extraída do computador de um usuário comum ou funcionário de alguma empresa, poderíamos concluir que o computador está infectado por um Trojan. | ||
Análise feita! se este Malware tivesse aparecido em um ambiente empresarial, agora seria a hora de extrair IOCs (Indicadores de Comprometimento), para ajudar a equipe de SOC (Centro de Operações de Segurança) a deixar a rede e ativos seguros. Iremos continuar seguindo essa situação como exemplo . | ||
OK, encontramos um IP (41.168.5.140) que possivelmente é utilizado como Comando e Controle, mas e se tiverem mais? voltando na Figura 07, podemos ver que o Malware faz uma requisição POST para o caminho " /zb/v_01_a/in /", então utilizei essa string de ponto de procura, para checar se Malware faz outras requisições POST para este mesmo caminho. | ||
| ||
Voilà achamos mais um IOC (IP: 188.40.0.138), com esses dois IOCs em mãos só nos resta ver se podemos associar esses IPs a possíveis nomes de host usando um DNS passivo. | ||
| ||
Daqui pra frente, teríamos que prosseguir e analisar cada nome de host possível para ver se eles podem ser ligados ao Trojan Banker. Compilando essas informações, forneceríamos esses IOCs para a equipe SOC, a mesma seria responsável pelo processo de verificação e detecção de infecção deste Malware na infraestrutura do empresa, implementando regras de detecção em IPS/IDS, EDR E SIEM de forma customizada. | ||
Cheat sheet Volatility | ||
Para saber o tipo do despejo de memória volátil: | ||
Para baixar o processo do arquivo.exe e o arquivo.exe em memória: | ||
Para listar conexões TCP / UDP abertas: | ||
$ volatility -f MyDump.dmp --profile = MyProfile sockets | ||
Para saber qual processo está executando: | ||
Referências | ||
Virus Total: https://www.virustotal.com/gui/ | ||
Hybrid Analysis: https://hybrid-analysis.com/ | ||
Volatility: https://github.com/volatilityfoundation/volatility | ||
Cridex Malware Sample: http://files.sempersecurus.org/dumps/cridex_memdump.zip | ||
