Por: Igor Rincon U. Gomes
Há alguns meses, recebemos a notícia de que o blog “Não Salvo”, um dos maiores blogs brasileiros de entretenimento, e o site de conteúdo adulto “Malícia” teriam sido comprometidos e seus visitantes estariam sendo induzidos a baixar e instalar um arquivo malicioso.
Após verificação, de fato havia um código malicioso em ambos os sites, que redirecionava os visitantes para outra página, a qual dizia haver a necessidade de uma atualização de plugins (pequenos programas de computador, muito utilizados por navegadores web). Neste artigo analisamos este ataque para entendermos melhor como os atacantes conseguiram infectar os usuários que acessavam esses sites. Utilizamos o caso do portal “Malícia” para o texto.
Quando o a vítima acessa o site a partir do seu computador, uma mensagem requisitando a atualização do Adobe Flash Player, plugin presente na maioria dos computadores de usuários de Internet, é mostrada na tela.
Para entender como isso acontece, buscamos no código fonte da página inicial do site “Malícia” qualquer indício de redirecionamentos e encontramos o trecho abaixo, que nos chamou a atenção:
Figura 1: Instrução malicioso no código fonte da página
A tag <script> do HTML é utilizada para executar scripts no navegador do usuário. O atacante, no caso, utilizou o parâmetro “src”, que força o navegador a baixar e renderizar código em uma URL específica, mesmo que esta aponte para outro host e que nem mesmo seja um script, mas uma página HTML inteira, que é o caso do ataque.
Ao concordar com a suposta atualização, o usuário é induzido a baixar (e executar) um arquivo chamado “flashplayer_install.exe”, nome escolhido criteriosamente para induzir as vítimas.
Figura 2: Requisição de download da ameaça pelo navegador
Este arquivo funciona como um “downloader”, ou seja, baixa da Internet outros arquivos maliciosos. Neste caso, observamos que ao executar o “flashplayer_install.exe” numa máquina de testes, foram baixados um script PAC (Proxy Auto Connect) e um outro script em VBScript, completamenteofuscado, como mostra a imagem abaixo:
Figura 3: Código ofuscado do script baixado pelo malware
Numa tentativa de não levantar suspeitas, o script é baixado com o nome “nmscrp.gif”, sugerindo aos usuários mais atentos ou administradores de rede que porventura filtrem os logs de acesso de seus usuários, que se trata de o download uma imagem GIF, o que não é verdade.
Os arquivos são salvos no diretório %ProgramData%, já com novos nomes: “java.u” é o PAC script, “winWeb.vbs” é o script em VBScript, e “99” é possivelmente o contador de infecções, como a imagem abaixo retrata:
Figura 4: Pasta ProgramData onde estão os arquivos salvos
A técnica de ofuscação do arquivo winWeb.vbs baseia-se na função chr() do VBScript que retorna a representação gráfica de um número na faixa da tabela ASCII(ref). A mesma técnica foi utilizada no comprometimento do site Gizmodo Brasil no início deste ano, para o qual o pesquisador Fernando Mercês criou um script para desofuscação (técnica para retirar a ofuscação).
No caso desta ameaça, iremos utilizar a solução Deep Discovery A N, ou somente DDAN, da Trend Micro, para analisar o funcionamento do malware, incluindo o script em VBScript.
Algumas das funções do malware encontrado são:
1 – Desativar UAC (Controle de Acesso de Usuário) no Sistema Operacional
Figura 5: Relatório de modificações do malware (DDAN – Trend Micro)
Dessa forma, algumas ações que antes não eram possíveis por conta de níveis de privilégio, passam a ser.
2 – Conectividade
O malware deseja saber se possui acesso à Internet, requisito para seu funcionamento. Ele faz isso simplesmente tentando resolver o nome de seu servidor C&C e testando a conectividade com ele através de troca de pacotes ICMP iniciada pelo comando ping.
Figura 6: Relatório de criação de processos pelo malware (DDAN – Trend Micro)
3 – Utilização de técnicas “Anti-security”
É cada vez mais comum a utilização de técnicas que permitem à ameaça detectar se está sendo analisada. Um exemplo é o uso de técnicas de detecção de execução em máquinas virtuais (anti-VM), em ambientes controlados (anti-sandbox), ou mesmo a combinação delas. O malware em questão utiliza uma delas, conforme a imagem abaixo revela:
Figura 7: Relatório de anti-security do malware (DDAN – Trend Micro)
A técnica escolhida foi a de aguardar um grande período de tempo antes de começar de fato a execução maliciosa. Dessa forma, o criador do malware planejou evadir as detecções por sandbox, que precisam estabelecer um limite de tempo para execução de um artefato. O DDAN é capaz de detectar esta técnica e “enganar” a ameaça, forçando a execução antes do término do período de espera.
4 – Configuração maliciosa de proxy
Esta é uma importante etapa na cadeia de infecção, onde de fato será gerada toda arquitetura do ataque para roubo de dados bancários.
4.1 – No registro do Windows achamos o seguinte dado
Figura 8: Registro do Windows na parte de Proxy
4.2 – Ao abrirmos este arquivo (javau.n) notamos o seguinte código:
Figura 9: Código do arquivo PAC
Este código representa um arquivo de configuração conhecido como PAC que, ao ser utilizado, permite a um navegador definir qual será a configuração para o proxy. Podemos observar que são declaradas duas variáveis com strings aleatórias: embaixo existe um “for” (condicional) que realiza um pequeno tratamento da ofuscação das strings. Também podemos verificar algumas características como as strings: “HS” “BC”, “IT” e “AU”, que fazem referência a nomes de bancos.
A função ShExpMatch trará o “return” mencionado no código acima caso as strings dos bancos sejam encontradas nas comunicações de rede da máquina.
Fizemos um tratamento no return para entendermos o que ele nos retorna, para isso utilizamos a ferramenta “pactester”.
Resultado:
Figura 10: Ferramenta pactester utilizada para testar arquivos do tipo PAC
Com isso, conseguimos concluir que todo tráfego relacionado a site de bancos é redirecionado para uma URL maliciosa, como o proxy mencionado acima.
Um tipo de controle que o atacante possui de seus alvos está baseado no registro do nome da máquina vítima, como mostra a imagem abaixo:
Figura 11: Relatório de comunicação de rede (DDAN – Trend Micro)
É importante observar que o proxy não funciona como uma captura dos acessos entre a máquina e o site do banco, ele funciona como um falso site bancário (phishing).
Site do Itaú acessado com conta falsa. Como sempre, importante observar a URL e os detalhes do site:
Figura 12: Site falso do Itaú – Phishing
Captura do tráfego apontando para o IP malicioso:
Figura 13: Comunicação de rede após infecção do malware (Wireshark)
Esta captura nos trouxe o IP “146.0.79.197” em que o método GET (requisição para entrar no site) para o site do ITAU foi feito. Nesta parte, conseguirmos fazer a comparação dos IPs do site do ITAU e do IP onde é feita requisição falsa, confirmando o phishing.
Captura dos dados da comunicação:
Figura 14: Detalhes da comunicação de rede com a falsa página bancária (Wireshark)
Nesta captura foram passados alguns parâmetros em texto claro pela conexão se tratar de HTTP e não HTTPS (Security), o que a maioria das instituições de banco utiliza. “Conta=11111-1” e “agencia=1111”.
Estamos observando um grande aumento na complexidade dos ataques sobre questões financeiras, neste ataque observamos três características planejadas:
1 – Invasão de um site muito acessado: Os atacantes utilizaram uma vulnerabilidade nos sistemas de segurança do site nãosalvo.com.br e malicia.com.br para criarem um sistema de “Disease Vector” propagando o malware para diversas máquinas pela Internet.
2 – Infecção de máquina e configuração de proxy: Os atacantes infectam a máquina do usuário final e forçam a configuração de um proxy no intuito de fazer o redirecionamento quando são encontradas comunicações destinadas a bancos brasileiros.
3 – Phishing de bancos brasileiros: Os atacantes clonaram os sites de bancos comuns no Brasil, possibilitando o roubo de dados sensíveis do usuário.
Um ponto importante é que o comércio de malwares bancários é comumente encontrado no submundo brasileiro, facilitando o trabalho dos atacantes.
Hash dos arquivos:
javau.n (PAC File) = a3167213672e4f4be55b7bb712edb1c7
winWeb.vbs (VBS File ofuscado) = 1022305ac58b657f8c46cfc2c45756da
flashplayer_install.exe = 9bc339d00f5e5ac9b1a880f6bbee3b8d
Continue acompanhando nosso blog, saiba quais são as ultimas ameaças cibernéticas e aprenda a se proteger na rede! Algum comentário sobre essa postagem? Fale com a gente no twitter@TrendMicroBR!
Referências:
1 – http://en.wikipedia.org/wiki/Proxy_auto-config
2 – http://pt.wikipedia.org/wiki/VBScript
3 – http://en.wikipedia.org/wiki/Obfuscation_%28software%29
4 – http://www.youtube.com/watch?v=mHjcemjzWVo
5 – http://www.trendmicro.com.br/cloud-content/br/pdfs/141117_mercadosubmundobr.pdf
Fonte Oficial: http://blog.trendmicro.com.br/entenda-como-funciona-a-arquitetura-de-um-ataque-bancario/#.VVR1bjvd_CI
