Please enable / Bitte aktiviere JavaScript!
Veuillez activer / Por favor activa el Javascript![ ? ]
segunda-feira , novembro 19 2018
Últimas Notícias

Análise do Malware autoinfect do NãoSalvo.com.br

Se você for copiar esse artigo e publicar em outro lugar, DEIXE MEUS CRÉDITOS, EU FIQUEI 3 DIAS ANALISANDO E ESCREVENDO ISSO! Obrigado, Nickguitar.dll.

@Update: Recebi um link de uma análise do mesmo malware, postada no blog do Ludicasec. Leia-a aqui. Apesar de ser o mesmo KL Proxy, a versão que eu analisei aqui veio com um banker junto. Atualizei a parte do javau.n, pois não tinha reparado que as outras strings também eram significativas no código. Portanto, créditos ao Ludicasec por essa parte.

@Update2 (31/07): Analisei melhor o winnit.exe quando cheguei em casa. Texto atualizado em 31/07/2015.

@Update3 (17/11): Acabo de acessar uma página do Não Salvo e surpreendentemente, depois de 4 meses, o arquivo continua lá! E agora pude ver que há uma chamada no final da página como se fosse um script, mas que na verdade é o link direto do executável. Texto atualizado com imagens em 17/11/2015.

 

Na noite desta sexta-feira, 24, 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 “descriptografar” 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á 15 dias atrás e já tem mais de 3000 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).

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.

Ao abrir o site “bb.com.br” enquanto o winnit está rodando, percebo que ele se conecta a diversos IPs, inclusive ao site do bb e do facebook, que estava aberto em outra aba.

 

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 usando a porta 443 (que roda o serviço HTTPS), 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. 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.

Tentei então abrir o IP normal, pela porta 80. A página demorou a carregar, e quando abriu, começou a baixar o arquivo chamado “download”, sem extensão nenhuma. Este era o conteúdo do arquivo:

SSH-2.0-5.34 FlowSsh: Bitvise SSH Server (WinSSHD) 6.31
T ,BssLoginTimeout: user authentication timeout fð«’¿çÛ#Å7o‹LÉßܬƒ©

Certamente é algum arquivo relacionado a conexão SSH com a VPS. Já vi isso antes, este tipo de arquivo é baixado automaticamente ao tentar acessar o servidor pela URL.

Lembrei que tinha deixado o Wireshark rodando, e quando voltei eu apliquei o filtro para exibir apenas pacotes relacionados ao IP da VPS (167.114.122.143), e encontrei algo muito interessante. Diversos pacotes TCP e SSL, enviados e recebidos, contendo o nome do computador de muitas pessoas, e todos eles seguidos de alguma ação como “Join”, “Leave” ou “Connection refused”, e logo após a string “#mestre_c6”. Isso faz bastante sentido, pois a conclusão que chegamos até agora é que se trata de um bot IRC.

O print acima mostra o conteúdo de apenas um pacote, tinham mais de 3 mil pacotes, cada um deles com nomes diferentes, como “Anacarolina-PC”, “USUARIO-PC”, “Gustavo-PC”, “Torre-1”, “Torre-2”, “Torre-3”, etc… Tenho certeza que são todas as vítimas que ele já infectou até agora.

Que tal tentarmos nos conectar no IRC? Provavelmente o “#mestre_c6” é o nome do canal.

PIMBA! NA MOSCA!

Tá aí, todas as vítimas do cara (online agora), inclusive minha máquina virtual… Mandei um “ALOO TESTANDO TESTANDO” pra ver se aparecia no Whireshark, e apareceu!

Fui ver a lista de canais disponíveis, e encontrei novos canais, desta vez com o nome de “bb_c5”, “caixa_c5”, “itau_c5” e “#santa_c5”.

 

Devem ser provenientes de outros infects, mas estão no mesmo servidor.

Dei um whois em um “adm” que estava em um dos canais, e foi retornado mais um canal “#sicredi_c5”.

 

Neste canal estava online apenas um usuário, o mesmo “adm” dos outros. Tentei falar com ele, mas parece que é bot, pois na descrição do usuário está escrito “IceChat9@127.0.0.1”.

Na janela de Plugins, dá pra ver que tem 4 plugins ativos: Python, Perl, EXEC e DNS.

Voltando à máquina virtual, abri o Cheat Engine pra debugar o processo e tentei procurar por algumas coisas no winnit.exe. Como o bb.com.br já estava aberto, digitei qualquer agência e conta para ver o que acontecia, e o winnit pegou os dados!

 

Tentei logar no facebook com credenciais falsas, e o winnit também capturou as informações.

 

Nem mesmo conexões SSL estão seguras!

Uma coisa que eu percebi é que assim que eu loguei no bb.com.br, automaticamente eu fui jogado para o canal “bb_c5” do IRC. Tentei logar no Sicredi (o canal que estava vazio) com dados falsos também, e fui jogado para o canal “sicredi_c5”.

 

Com base nisso, acho que o canal “mestre_c6” tem todas as vítimas infectadas, e os outros canais tem apenas os usuários que logaram nos respectivos bancos. Já no canal, o usuário deve enviar uma MP para o host (o “hacker”) com os dados de login, ou então armazenar de alguma outra forma no servidor.

 

@UPDATE: 17 de novembro de 2015 – Entrei em um link do Não Salvo e o malware continua lá! Dessa vez eu baixei a página e pude ver como ele é chamado no código fonte. Ao ver o código fonte pelo navegador, nas últimas linhas há alguns scripts que fazem menção a um IP. Ao salvar a página e ver o código fonte dela, é possível ver que esse IP é chamado mais vezes no corpo da página.

Ou seja, a página redireciona para o link de um IP, juntamente a um parâmetro. A página é http://185.70.187.209/?true=132b0ac21887e6568b906d155d58

Ao entrar, percebemos que se trata de uma página falsa que diz ser uma atualização do Adobe Flash Player (não havia visto esta página quando fiz a análise).

No código fonte dessa página há um iframe que insere o link de download direto do arquivo, que está hospedado no SugarSync.

Ao tirar o nome do arquivo e os outros parâmetros do link, conseguimos acessar o perfil do cara que hospedou isso aí, que se deu o nome de Alexandre.

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.

O arquivo “winnit.exe” 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. Ao ser aberto, o programa insere o computador numa lista de usuários de um canal no IRC chamado “mestre_c6“, e quando algum site de algum banco é acessado, ele joga a vítima para o canal do respectivo banco. Lá, a o usuário da vítima envia uma mensagem privada ao host (o “hacker”), ou salva os dados de alguma outra forma. Este servidor pode rodar scripts em Perl, Python e executar comandos remotos na máquina da vítima.

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, e ao logar, insere a vítima em um canal de IRC, onde o “hacker” pode ter acesso às informações digitadas e enviar 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. Vou deixar o link do arquivo do install_flashplayer no final para quem quiser analisar por conta própria.

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 3400 acessos em duas semanas, e está aumentando. Veja a página dele aqui).

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!

Sobre Nicholas Ferreira

Sou amante de informática desde criança, tive meu primeiro contato com hacking aos 12 anos, e desde essa data eu venho estudando cada vez mais as diversas áreas da segurança da informação. Tenho certificados de cursos de PHP, Visual Basic, e atualmente estou estudando Análise de Malwares.
Free WordPress Themes - Download High-quality Templates