.d8888b. 8888888888 .d8888b. 888888888 .d8888b. d88P Y88b d88P d88P Y88b 888 d88P Y88b 888 888 d88P .d88P 888 888 888 888 888 888 888 d88P 8888" 8888888b. Y88b. d888 888 888 `Y8bd8P' 88888888 "Y8b. "Y88b "Y888P888 888 888 X88K d88P 888 888 888 888 Y88b d88P .d8""8b. d88P Y88b d88P Y88b d88P Y88b d88P "Y8888P" 8888 8888 d88P "Y8888P" "Y8888P" "Y8888P"

[ Autor: Nicholas Ferreira ]


[0x3] Análise do malware autoinfect no Blog Não Salvo

28/07/2015



Na noite desta sexta-feira, 24 de julho de 2015, meu amigo Setzen me enviou pelo Skype um link do site NaoSalvo.com.br – um site de humor bem conhecido – contendo um script auto executável (valeu pelo link, Setzen xD), que baixa automaticamente um arquivo para o PC, alegando ser uma atualização do Adobe Flash Player. Tratei de baixar e me preparar para analisar o arquivo. (Link no final do artigo).

Antes de tudo, gostaria de agradecer ao Luiz9 por me emprestar sua máquina virtual, pois a minha não estava conectada à internet corretamente, e algumas partes eu não consegui fazer nela, e tive que usar a dele. Se não fosse por isso, eu não descobriria o segundo arquivo (winnit.exe). Valeu Luiz 😀

(Estou analisando o arquivo ao mesmo tempo em que escrevo este artigo, logo, farei modificações nele depois de publicado)

Só pelo ícone do arquivo baixado já dá pra desconfiar um pouco sobre sua segurança… É um ícone antigo, e não parece ser “profissional”. (Talvez seja maluquice minha, mas consigo reparar quando um ícone não tá de acordo, sei lá…)

O arquivo está hospedado no site Pogoplug.com, em uma conta gratuita.

Depois de baixar o arquivo, dei F5 na página e a mensagem simplesmente sumiu! O cara que programou isso fez um código que verifica se o usuário já baixou o arquivo, se já tiver baixado, ele não exibe mais a mensagem, se não, ele baixa.

Antes disso, eu tinha clicado com o botão direito em cima da mensagem de atualização, e vi que se tratava de um elemento HTML, ou seja, estava incluso na página, coisa que a Adobe nunca iria fazer, pois a pop up de atualização é chamada pelo navegador, e não pela página. (fiquei com preguiça de limpar o cache e printar isso)

Bom, com o arquivo em mãos, vamos dar uma olhada nele.



Tentei ver alguma coisa nas strings, mas tá tudo ofuscado, não há o que aproveitar lá. Pelo visto ele foi compactado com o packer MPress v2.0. Nunca ouvi falar nessa merda, mas resolvi colocar no Olly pra ver se consigo identificar algo útil, e me deparei com algo familiar.




Opa, PUSHAD? Me lembrei na hora do UPX, um packer que usa uma sequência de instruções, começando pelo PUSHAD e terminando pelo POPAD. Não vou explicar pra que servem esses operadores, já expliquei neste vídeo.

Bom, vamos seguir esse call e ver onde ele dá então né…


Adivinha?? Pois é, a estrutura do packer é a mesma do UPX. Começa com PUSHAD, faz todo o código e termina com POPAD, onde é possível ver o OEP (Original Entry Point). Depois disso eu só fiz o lance com o OllyDump e reconstrui os imports com o ImpRec, e pronto, temos nosso arquivo descompactado! Parece que o “hacker” pensou que, por se tratar de um packer não tão conhecido, seria mais difícil de removê-lo. Bom, as coisas não são assim, meu jovem…


Como eu já esperava, o malware foi programado em Delphi (só não esperava uma versão tão antiga, kk), como a maioria dos trojans bankers.
Como é lei, iremos ver as strings do programa, que agora já deve nos revelar bastante coisa.
A primeira coisa que me chamou atençao foi a linkagem de vários diretórios com arquivos .pas (o arquivo fonte da linguagem pascal) externos.


Bom, o Delphi já conta com uma biblioteca de manipulação de HTTP, então isso aí é alguma lib externa. Apenas jogando o nome no Google, vi que se trata de uma biblioteca open-source que trabalha com sockets, e oferece disponibilidade para C++, Visual Basic e Delphi. Veja mais em IndySockets.

Já tá na cara que o cara que programou isso tem a intenção de fazer requisições a algum site, enviando e/ou recebendo dados.
Ao descermos um pouco as strings, é possível ver que o padrão muda um pouco. Começam a aparecer componentes do Delphi, como botões, groupboxes, timers e outras coisas. Mas o que mais chamou atenção é o que vem depois disso. Algumas strings que aparentemente foram cifradas com Base64.


Legal, vamos “decodificar” essas strings e ver o que conseguimos (em ordem)
winmanager.vbs
http://l.new1aahb31.com/nmgifw.gif
http://l.new1aahb31.com/phr/nmscp.gif
Wscript.exe ”
http://l.new1aahb31.com/bossh/c.php?tip=[HD24]-
computername
javau.n
Wscript.exe ”
javau.n
http://l.new1aahb31.com/bosshphr/c.php?tip=[HD24]-
computername
allusersprofile
SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5
SOFTWARE\Microsoft\NET Framework Setup\NDP\v4

Tem alguns links aí, umas chaves no registro, e outras coisas, além do nome “winmanager.vbs”. Não vamos abrir os links agora, vamos para a análise dinâmica, pra ver como esses links interagem com o programa.

Para poupar tempo, não usarei vários programas para analisar, apenas usarei o Whireshark para ver o tráfego na rede e o Process Monitor, que me retorna uma boa quantidade de informação sobre as modificações do arquivo no sistema. Então, vamos simplesmente deixar o ProcMon rodando e vamos executar o arquivo que nós descompactamos.


Esta mensagem de erro é a primeira coisa que é exibida, e o motivo disso é que eu não configurei a internet na máquina virtual, então ela não consegue se conectar a nada (pois não coloquei a senha). Isso mostra que assim que o programa é aberto, ele tenta se conectar a algum servidor HTTP. Depois de dar OK, nada mais acontece.
Na máquina virtual do Luiz9 eu abri o Procmon e deixei pegando os logs.



Como é possível ver no Procmon e no Whireshark, o programa se conectou àquele link que nós descriptografamos anteriormente, acessando o arquivo nmgifw.gif. e baixando-o logo em seguida e renomeando para winmanager.vbs
Ao abrir o vbs que foi baixado (no caso, eu baixei a gif e não renomeei), vejo o seguinte código:

Esse código aí parece bem feio, mas vamos só renomear essa função que está nos dando dor de cabeça.

Continua feio? Bom, pelo menos tá dando pra entender um pouco. Na segunda linha nós vemos que essa função foi feita apenas pra ofuscar o código do programa, que não faz nada mais do que converter alguns números em letras, usando a função chr(). Já vi isso antes, e sei que é super simples de “descriptografar” isso aí. Basta pegar os números que são passados como parâmetro pela função e convertê-los para ascii. E nem preciso ficar apagando coisa por coisa, um simples CTRL + H resolve meu problema.


Agora nós só temos números! Só nos resta copiar os números e convertê-los para ascii, usando a ferramenta ascii-converter.
Depois de um tempo convertendo tudo, é assim que o código ficou, como foi escrito:


Bem melhor, não? Tem mais linha pra baixo, no total são 196 linhas.

Esse arquivo provavelmente é o winmanager.vbs que a gente achou nas strings “criptografadas” com base64.
O código é bem chato de entender, ele faz várias menções da mesma função pra confundir, mas pelo que eu pude entender ele verifica se a pasta “C:\ProgramData” existe. Se existir, ele baixa o arquivo nmdt.txt pra lá, e o renomeia pra javau.n. Se a pasta não existir, ele manda esse arquivo para a pasta “C:\Documents and Settings\AllUsers\”. Ele então sobescreve o arquivo “pref.js”, de preferências do Mozilla Firefox, com este javau.n. Este arquivo parece ter alguns loops que juntos formam algum link, ou coisa do tipo. O nome da função é FindProxyForURL().

Em seguida ele faz um teste de ping no servidor onde os arquivos estão hospedados, para saber se ele está online.
Se o servidor estiver online, ele baixa o arquivo nmversion.txt para a pasta de arquivos temporários, renomeando-o para um número (o número da versão que o malware se encontra). Este arquivo contém a versão atual do malware. Se houver alguma modificação entre esse arquivo temporário e o arquivo hospedado, ele baixa os novos arquivos do malware atualizado. Dessa forma, quando o “hacker” quiser que haja uma atualização automática, é só alterar a versão do arquivo no site, e todos os computadores infectados baixarão automaticamente a nova versão.

Depois disso o programa mexe em uma chave relacionada à conexão com a internet do navegador Internet Explorer, adicionando o arquivo “javau.n” como parâmetro dessa chave. Em seguida, ele se instala na chave Run, fazendo com que o programa wscript.exe mencionado anteriormente (programa do windows que executa os scripts vbs) o execute toda vez que o sistema é iniciado. Após isso ele altera chaves para obter permissão de administrador.

Baixei então o que seria o “javau.n” (o arquivo nmdt.txt que ele baixa do servidor) para analisar. O código parece ser complicado, mas o cara só escreveu um monte de lixo para confundir. Na verdade é bem simples.

Renomeei as variáveis para “a” e “c” para ficar melhor para ler, porque estavam com um nome que confundia. (ignorem a linha 13, tentei forçar um return nela mesma pra ver no que dava, mas não resultou em nada)
Vemos que ele seta dois arrays com várias strings embaralhadas, e depois ele usa um for pra reorganizar os itens dela. Na linha 8 nós vemos que ele retorna “PROXY” + a junção de alguns dos ítens dos arrays. Se nós pegarmos o 6º item + o 7º, etc (começando a contar do 0), nós descobriremos a string “orion.systembrazil.com:80″.

Update
Depois de ler a este artigo, uma análise do mesmo malware, percebi que havia deixado uma coisa passar despercebida. Há também outros itens no array, e eles são importantes! Eu pensei que eles foram colocados ali para confundir a cabeça de quem fosse analisar, mas eles na verdade formam as URLs que serão redirecionadas para a proxy.



Créditos da imagem: Ludicasec.
Ou seja, esse código todo aí diz que todo site que conter as strings “aixa”, “bradesco”, “hsbc” e “itau” serão redirecionados para a proxy “orion.systembrazil.com”, na porta 80. Esse código é então inserido na chave de registro do Internet Explorer relacionada a configuração da URL (configuração de proxy), e no arquivo de preferências de proxy do Firefox.



Créditos da imagem: Ludicasec.
Depois disso tudo eu resolvi entrar em um dos links que o programa acessa e retirar o nome do arquivo pra ver se é possível ver os outros arquivos da pasta, e foi como eu esperava…

Além dos arquivos que eu já havia baixado, há um quarto arquivo chamado “nmscp.gif.old”. Arquivos .old geralmente são usados como backup. Eu li o código dele, e é quase a mesma coisa da GIF atual, não percebi significativas diferenças. Provavelmente é o que restou de uma atualização passada.
Depois de fazer isso tudo, o programa faz uma última requisição ao site, dessa vez a um arquivo diferente, em outra pasta.


O arquivo requisitado foi o c.php, na pasta bosshphr, e envia os dados “[HD24]-AnaMalw” via get, no parâmetro “tip”.
Não sei o que significa o HD24, mas “AnaMalw” é o nome da máquina virtual (Análise de Malware). Com base nisso, tenho quase certeza que é uma espécie de contador ou painel, onde os dados dos PCs infectados ficam armazenados. Tentei olhar a pasta, mas dessa vez o cara colocou uma index, o que não me permitiu ver os arquivos de lá.

Quando eu estava quase fechando tudo e publicando o artigo eu percebi duas coisas diferentes. O apareciomento do arquivo “winnit.exe” e a modificação do tamanho do “winmanager.vbs” (que na verdade foi analisado como “nmscp.vbs”, que aparecam na mesma pasta em que os arquivos foram baixados. O “nmscp.vbs” tinha 5,73kb, enquanto que o “winmanager.vbs” tem 4,74kb.

Voltei ao ProcMon e levei uma década pra descobrir quem tava criando esse arquivo. O filtro de pesquisa de diretório não estavava funcionando, e tinha mais de 26 mil registros, só do processo Wscript.exe. 
Depois de fazer umas gambiarras nos filtros eu consegui ver que é o próprio wscript.exe que cria o arquivo winnit.exe. Ou seja, ele é criado por algum script vbs.

Vendo os registros, vi que havia sido criado outro arquivo antes pelo winmanager.vbs. Foi criado o arquivo winfac.gif, o que me faz pensar que o winmanager.vbs baixou outro arquivo como gif e o renomeou para winnit.exe. Também foi criado o arquivo “7” na pasta, que me lembrou o arquivo de verificação de versão que nós vimos anteriormente.
Percebi então que se tratavam de dois malwares diferentes, provavelmente com funções diferentes também.

Abri o winmanager.vbs no notepad++ para ler seu código, e foi usado o mesmo sistema de ofuscação do outro. Depois de alguns minutos traduzindo tudo, o código pronto me revela outros links.

Finalmente concluí que quem cria o maldito “winnit.exe” é o “winmanager.vbs“.
A imagem acima é de uma função nova que apareceu nele, que verifica a versão do .NET Framework instalado no PC da vítima, e para cada versão ele baixa um arquivo diferente, enviando para dois links de arquivos de texto hospedados no mesmo servidor. Ambos contém o link de dois arquivos hospedados no 4shared. Os dois arquivos são o winnit.exe, que só foi recompilado para versões diferentes do .NET Framework.
Os arquivos estão hospedados nesta conta do 4shared, que entrou há 11 dias atrás e já tem mais de 1000 acessos. (pelo visto esse infect no NãoSalvo causou um prejuízo grande, hein…)
O winmanager.vbs também faz menção a outro arquivo hospedado no mesmo servidor, dessa vez é o “versao.txt“, e o conteúdo desse arquivo é simplesmente o número 7, esclarecendo a criação do arquivo “7” anteriormente.

Esse winmanager.vbs faz quase a mesma coisa que o outro, ele só não baixa o arquivo que altera a proxy no registro e no Firefox. Ele que baixa o winnit.exe para a pasta e o executa.

Winnit.exe



O arquivo winnit.exe pesa 3,65MB e foi feito usando Visual Basic.NET (Isso explica o motivo do winmanager.vbs ter checado a versão do framework). Tentei descompilá-lo usando o Reflector, até consegui ver algumas strings suspeitas, mas o código principal eu não consegui ler, pois ele foi obfuscado.

Strings desse tipo se repetiam, mudando a forma com que era escrita, além de outras strings como “@ Itaú Bankline”. O resto do arquivo estava obfuscado, e não era possível ler o código.
Resolvi então olhar as strings do executável, e me deparei com mais uma gigantesca sequência de strings cifradas com Base64, como o nosso primeiro arquivo do flashplayer.

É possível ler strings como o link do site do Banco do Brasil, Caixa, google, além de strings como “processa”, “senha”, “clonar”, “consulta”, “senhacartao”, “transferências”, “/c “taskkill /f /im plugin-container.exe && taskkill /f /im firefox.exe””, e muitas outras. Encontrei cifras gigantes, e ao passa-las para ascii, vi que se tratavam de códigos HTML. Salvei o texto como html e abri no navegador, e todos eram páginas de bancos como BB, Caixa, Sicred, pedindo para que fosse inserida a senha de acesso a conta.

Depois de olhar as strings eu resolvi fazer o mesmo processo que fiz com o flashplauer: executá-lo e ver o que ele fazia.
A primeira coisa que aconteceu ao executar o winnit.exe foi o bloqueio de conexão dele com a rede pelo firewall do Windows, o que é bem suspeito e anormal, porque a maioria dos malwares que se conecta a rede HTTP não precisa abrir portas, pois a porta 80 já é aberta por padrão. Isso significa que este arquivo tenta se conectar a algum servidor em outra porta que não é a 80.

Não cliquei no Allow access, apenas fui vendo as outras modificações que ele faz no sistema, até que me deparei com o uso do arquivo MakeCert.exe e de chaves no registro relacionadas a criação de certificados também. Leia mais sobre o MakeCert.exe aqui.

O programa depois faz várias requisições a um IP de uma VPS hospedada no Canadá, na porta 443 (SSL), tentando várias portas locais diferentes, enviando o nome do meu PC para o servidor (similar ao arquivo c.php do site, que envia uma string + o nome do meu PC via get para a página de contagem de vítimas). Não sei se esse grande número de requisições se deve ao fato de que minha VM não tem acesso à internet, pois eu não configurei a senha do provedor lá. Talvez, se houvesse a senha, seria feita apenas uma conexão, e outros dados seriam enviados e recebidos. Não consegui ver o que ele faz depois, pois o Luiz havia saído, e eu perdi o acesso à VM dele.

No dia seguinte, pedi novamente a máquina virtual do luiz emprestada para fazer a análise. Deixei o Procmon rodando, abri o winnit.exe e abri o Google e outros sites no Chrome. Nada aconteceu. Depois eu abri a página do bancodobrasil.com.br, e número de eventos feitos pelo winnit aumentou muito rápido, foi de 3.000 eventos pra 12 mil em poucos segundos. Quase todos os novos eventos eram conexões via HTTPS a um IP (167.114.122.143). Ficou claro que o winnit faz alguma comunicação com o Chrome e com o site que ele acessa, já que as modificações foram feitas apenas quando eu abri a página do banco do brasil.


O IP é de uma VPS do OVH Hosting, do Canadá. Ao tentar acessá-la pelo navegador, recebi uma mensagem de erro dizendo que meu IP não foi reconhecido. O sistema até pensou que poderia ser um ataque de negação de serviço.

Pesquisei sobre essa mensagem de erro e descobri que ela é exibida quando ocorre algum problema de identificação do client em algum servidor IRC. Até vi que esse erro aparece as vezes em bots de IRC que não foram bem configurados, o que me fez pensar que o malware envia informações da vítima para o servidor IRC do “hacker”. Isso esclareceu o motivo do pedido de permissão de acesso à rede ao firewall feita pelo malware no início.
Ao ativar o MalwareBytes, ele reconheceu os arquivos na hora como malwares.


Veja que a signature dos dois é “Trojan.Banker” e “Backdoor.IRCBot”, confirmando o que nós concluímos até agora.
Não consegui descobrir mais nada. Tentei acessar outros bancos e o mesmo acontece. Digitei dados aleatórios para ver o que acontecia, mas não deu em nada. Pesquisei sobre este processo, e outras pessoas também afirmaram que é uma espécie de malware que se conecta a um servidor IRC e fica escutando a espera de comandos, como um bot. Não sei pra onde os dados vão, nem como ele pega, mas sei que computadores infectados com esse keylogger terá as contas de banco logadas nele comprometidas.


Conclusão:

 O arquivo “install_flashplayer.exe” é um trojan downloader, compilado no Delphi e compactado com MPress v2.0, que usa a biblioteca IndySocketsbaixa para baixar um script VBS em forma de gif de um site. Ao baixar o script, ele o executa. O script cria um arquivo na pasta “%appdata%/temp”, e verifica se há atualizações do malware em um arquivo de texto no host, comparando o texto deste arquivo com o do arquivo criado na pasta temporária. Se houver atualizações, o novo script é baixado e executado.

O script então baixa o arquivo nmdt.txt e o renomeia para javau.n. Este arquivo contém um script que diz que todos os sites que tirevem as strings “aixa”, “bradesco”, “hsbc” e “itau” na url serão redirecionados para aquela proxy. (Novamente, créditos ao Ludicasec por escrever sobre essa parte). Este script é inserido no arquivo de preferências de usuário do Firefox e numa chave do registro refente à configuração de proxy do Internet Explorer, depois de ter criado uma instância a si próprio na chave de inicialização do registro, para fazer com que o programa “wscript.exe” o carregue toda vez que o sistema for iniciado. Depois disso, ele envia uma requisição a uma outra página no mesmo host, enviando a string “[HD24]-AnaMalw” via GET para ela, que provavelmente é algum contador de vítimas infectadas.

Ele também baixa o arquivo “winmanager.vbs”, que é um script similar ao outro, porém, não instala a modificação de proxy no registro nem altera o arquivo de preferências do Firefox. Esse arquivo baixa uma nova gif chamada “winfac.gif”, que é renomeada para “winnit.exe”, pesa 3,65MB, foi ‘compilado’ com Visual Basic .NET e passou por um processo de obfuscação, para que seu código não possa ser lido. Este arquivo contém várias strings suspeitas como nomes de bancos, coisas relacionadas a cartões, clonagem, além de conter alguns códigos HTML de páginas pedindo dados bancários. O processo requer permissão do Firewall para realizar conexões, e ao ser aberto, ele modifica várias chaves do registro relacionadas a criação de certificados virtuais, usando o programa MakeCert.exe, do próprio Windows.

Ou seja, um dos malwares se trata de uma KL Proxy, que usa a técnica conhecida como Spoof para alterar a proxy dos navegadores e fazer com que, ao acessar algum site, os dados passem primeiro pela proxy antes de chegarem ao destino. Isso faz com que todas as senhas que você digite fiquem salvas no servidor do “hacker”.

O outro se trata de um keylogger banker, que é ativado cada vez que o usuário entra em algum site de banco, captura as teclas digitadas e clicadas e envia para o atacante. Ele também se conecta a um servidor IRC e fica esperando novos comandos remotos.

Meu parabéns se você chegou até aqui sem pular nada (ou quase nada). Passei 3 dias pra analisar tudo e escrever esse artigo, que é o maior que eu fiz até agora. Mesmo assim, não estou satisfeito com a análise, justamente pela falta de recursos de internet, pelo fato de eu estar viajando e a internet aqui não colabora muito. Vou deixar o link do arquivo do install_flashplayer no final para quem quiser analisar por conta própria.

Ainda assim, acho que deu pra ter uma noção do perigo que um click no botão de “executar” pode trazer ao seu PC. Um simples arquivo de 725kb pode trazer uma GRANDE dor de cabeça, e dor no bolso também…

Aí fica o questionamento, o site do NãoSalvo foi invadido, ou será que o administrador tem algo a ver com isso? O site é bem conhecido, qualquer estelionatário magnata poderia pagá-lo para colocar isso lá, e assim conseguiria muitos infects. (O arquivo do 4shared do cara teve mais de 1000 acessos em menos de uma semana).

Mas não vou acusar ninguém, não tenho provas e nem sei se foi realmente isso, é apenas uma versão do que pode ter acontecido.

Link do arquivo install_flashplayer (725kb). (É o link original do arquivo, que estava inserido no site)

Link da página infectada do NãoSalvo. (Depois de baixado, a pop up do flash para de aparecer)

Meus sinceros obrigados a quem leu até aqui, e até a próxima!