Saiba porque 2016 foi considerado o ano do malware bancário Java no Brasil

Além das praias e do Carnaval, o Brasil também é muito conhecido pelos malware bancários. É possível dizer que 2014 foi o ano dos malware bancários CPL, 2015 o ano do crescimento de malware .NET, e, com certeza, 2016 foi o ano dos malware Java no Brasil.

O modo de operação não difere do que já estamos habituados a ver. Através de emails maliciosos, os cibercriminosos tentam convencer as vítimas a baixarem e a executarem um malware em suas máquinas.

Operação de um ataque utilizando malware bancário.

Os temas mais frequentes desses emails envolvem boletos, notas fiscais (NF, NTF-e), currículos, rastreamentos de SEDEX, orçamentos e outros. Abaixo encontram-se os nomes de alguns desses anexos maliciosos enviados às vítimas.

• BOLETO.jar
• Boleto_Atualizado_100008254961337.jar
• Boleto_BV.jar
• Boleto_Cobranca_Set_2016.jar
• Carta_Oficio-17-10-2016.jar
• Curriculo_Atualizado.jar
• Curriculum-Vitae.jar
• Ft.Boleto_Dez21001254871.jar
• ID CODUMENTO SEDEX SR688592688592BR.jar
• NF-eletrônica0065544221.PDF.jar
• NTF-e Paulistana_13-09-2016.jar
• Pedido_Orcamento.jar

Os Arquivos JAR são convenientes para os cibercriminosos, pois são aceitos como anexo em diversos servidores de email, sejam corporativos ou de provedores, e, além disso, são executáveis.

Em geral, esses anexos maliciosos são responsáveis por baixar e executar outros malware na máquina da vítima. Malware que realizam o download de outros malware (chamados genericamente de payloads) são conhecidos como Downloaders (ou Banloads, quando visam a obtenção de credenciais bancárias). O payloads realizam as ações danosos ao usuário, como, por exemplo, o roubo de credenciais bancárias, conhecidos, neste caso, como Bankers.

Funcionamento e relação entre um Banload (trojan downloader) e Banker (payload).

Também é comum detectar payloads como Spy.Keylogger, que monitoram e roubam todas as informações digitadas. Já o DNSChanger/ProxyChanger redireciona o usuário para páginas falsas. Isso ocorre quando a vítima tenta acessar sites de bancos, e-commerce, redes sociais, email e etc.

Banloads, de CPL para Java

Se em 2014, o número de Banloads CPL era comparável ao número de detecções de outras ameaças digitais (como o Confiker), em 2016, o resultado foi bastante discrepante. Além do aumento no número de detecções de Banloads, a parcela provinda de CPL (em 2014) e Java (em 2016) também cresceu, chegando a 68,2% do total de detecções de Banloads durante o ano.

Comparativo entre Banloads no Brasil em 2014 e 2016.

O fato dos trojans downloader serem os primeiros arquivos maliciosos a executarem-se na máquina da vítima durante a cadeia de ataque (vide figura 1), contribui para que possamos compreender o grande número de detecções deste tipo de malware.

Quando os downloaders são detectados, ocorre a interrupção deste malware antes de seguirem com o download e execução do payloads. Soma-se a isso as proteções dos próprios downloaders para prevenirem o download dos payloads em máquinas que não cumprem um perfil desejado (como veremos a seguir) – dificultando a detecção e análise da cadeia de ataque completa.

Por ser o principal Banload detectado no Brasil, e o terceiro no ranking de detecções de 2016 no país, neste post, vamos analisar mais profundamente uma amostra recente de Java/TrojanDownloader.Banload.AK, dando continuidade a uma análise que já publicamos sobre essa mesma variante.

Java/TrojanDownloader.Banload.AK

A amostra que vamos analisar chega às vítimas através de emails com o anexo Curriculo_Atualizado.jar. Ela pode ser descompilada por diversas ferramentas, ou mesmo online, recuperando um código fonte do JAR pronto para ser analisado.

Quando a amostra é descompilada, obtém-se um código bastante extenso com variáveis e métodos obfuscados.

Amostra de Java/TrojanDownloader.Banload.AK após descompilação.

Na análise anterior, já tínhamos observado que código obfuscado encriptava suas strings, utilizando DES/CBC/PKCS5Padding e o nome da classe como chave (o que não se alterou nessa amostra recente do malware).

Strings criptografadas e descriptografadas.

Com isso, era possível desencriptar as strings da amostra e ter uma boa noção do que ocorria. Para esta publicação, fizemos a engenharia reversa completa da amostra para entender todo o fluxo de execução.

Amostra de Java/TrojanDownloader.Banload.AK desobfuscada.

O fluxo completo de execução pode ser dividido em 5 etapas: validações iniciais, validação da arquitetura, download dos payloads, preparação da execução e restart da máquina.

Fluxo de execução da amostra de Java/TrojanDownloader.Banload.AK

• Validações Iniciais

Ao iniciar a execução do método main, são feitas as verificações iniciais, cujo intuito é verificar se o computador está com uma configuração típica brasileira (idioma e local), se possui aplicativos de bancos instalados e não conta com a pasta %APPDATA%/Microsoft/Windows/1.1, onde são armazenados os payloads após o download, o que denota que o Java/TrojanDownloader.Banload.AK ainda não foi executado no sistema.

Método para selecionar e levantar dados sobre o sistema.

Além disso, o malware levanta informações que permitem identificar o computador afetado de maneira unívoca (hostname, sistema operacional e números seriais dos drivers da máquina), que serão enviadas ao centro de comando e controle (C&C) posteriormente.

Método para buscar as aplicações bancárias instaladas no sistema.

Em especial, o malware procura por todos os arquivos com extensão .GPC na pasta GbpPlugin e pela instalação de aplicativos do Bradesco (AppBrad e SCPBrad) para enviar essas informações ao C&C posteriomente.

Se nenhum aplicativo de banco é encontrado na máquina, a execução do malware é terminada, sem contactar o C&C, e sem baixar os payloads, que age como uma proteção contra análise por sandbox.

• Validação da arquitetura

A validação da arquitetura do sistema é bastante simples, apenas verificando a existência da pasta Program Files(x86). Isso é importante para realizar o download dos payloads correspondentes à arquitetura do sistema na etapa seguinte.

Método para verificar a arquitetura do sistema.

• Download dos payloads

O download dos payloads é bastante simples e direto. Os arquivos baixados estão comprimidos, para diminuir o tamanho dos arquivos e, possivelmente, dificultar a análise através de inspeção de pacotes (DPI) .

Fluxo principal de download e preparação da execução dos payloads.

• Preparação da execução

Os payloads baixados na etapa anterior não são executados imediatamente, ao invés disso, o sistema é modificado de maneira a executá-los sempre que o computador é inicializado – um comportamento conhecido como persistência.

A preparação é toda realizada através de scripts VBS que são escritos no sistema e executados pelo Banload – uma característica dos Droppers.

Primeiramente, o Banload prepara um script VBS apenas para executar um dos payloads baixados do C&C. Em especial, a execução é feita através do utilitário RunDll32 e o entry point utilizado é diferente de DllMain (ou mesmo DllEntryPoint), para procurar evadir-se de uma análise via sandbox – isso não quer dizer que seja um método eficaz.

Método para gerar script de execução do payload através do RunDll32.EXE.

Na sequência, através de scripts VBS temporários (que são apagados logo após a execução), o Banlod cria um atalho para a execução do script recém criado (que utiliza o RunDll32) e o coloca na pasta de Startup do sistema. Dessa forma, sempre que o sistema é inicializado, o script apontado pelo atalho é executado.

Fluxo do método de criação do atalho na pasta de Statup do sistema.

Por fim, os dados coletados durante a etapa de validação inicial são enviados ao C&C. Desa forma, os cibercriminosos podem associar os dados do computador comprometido, aos aplicativos instalados e IP (público).

Para esconder as informações, a mensagem possui cada campo codificado em string invertida de hexadecimal, antes de serem todos concatenados e enviados ao C&C.

Método para exfiltração dos dados.

• Restart

A última etapa simplesmente reinicia a máquina. Dessa forma, o script apontadopelo atalho instalado na pasta de Statup do sistema será executado quando o sistema for (re)inicializado.

Payloads

Os payloads baixados constituem em 2 executáveis (PE) escritos em Delphi, que variam dependendo da arquitetura do sistema, e um JAR.

Os arquivos PEs são Bankers utilizados para o roubo de credenciais bancárias, enquanto o JAR é um keylogger, utilizado para registrar as teclas pressionadas pelo usuário.

Eles são detectados como:

Banloads em 2017

No post de hoje, analisamos o principal Banload de 2016. Escrito em Java e que busca dificultar sua análise através da obfuscação dos métodos e strings, além de conter diversas proteções para (tentar) impossibilitar a análise através de sandbox.

Certamente Banload continuarão a ser um grande problema no Brasil em 2017. Provavelmente Java continue sendo bastante utilizado, dado o grande impacto que teve em 2016; e possivelmente vamos ver esses malwares surgindo cada vez mais em linguagens de script, como VB e JS.

Amostra analisada:

 Payloads: