A evolução do Malware Brasileiro

Introdução

O malware Brasileiro continua evoluindo dia a dia, os tornando cada vez mais sofisticados. Se você deseja saber como os variados programas maliciosos funcionam hoje em dia, você pode ir para a seção correspondente aqui. Porém, antes disso, gostaríamos de mostrar comos as técnicas usadas pelos cibercriminisos Brasileiros mudaram, se tornando mais avançadas e cada vez mais complexos.

Dando uma olhada de uma maneira mais ampla nós podemos ver que os autores estão aperfeiçoando suas técnicas para aumentar o tempo de vida do malware assim como o seu lucro.

Algum tempo atrás, analisar e detector malware Brasileiro era algo que poderia ser feito de uma maneira bem rápida devido a nenhuma obfuscação, nenhuma técnica anti-debugging , nenhuma criptografia, comunicação somente em plain-text, etc. O código costumava ser escrito em Delphi e Visual Basic 6, com várias imágens grandes incluídas no binário tonando-o muito grande assim como tratamentos de exceções muito ruins onde era bem comum os processos pararem de funcionar.

Hoje em dia, o cenário não é o mesmo; os atacantes estão investindo tempo e dinheiro para desenvolver soluções onde o payload malicioso fica completamente escondido abaixo de várias obfuscações e proteções de código. Eles continuam utilizando Delphi e VB mas também começaram a adotar outras linguagens como .NET e a qualidade do código está muito melhor, deixando claro que eles passaram para um outro nível.

Vamos passer por algumas amostras mostrando as diferenças entre o que costumávamos encontrar alguns anos atrás e as ameaças sendo entregues nos dias de hoje.

O que costumávamos encontrar

Keylogger

No início, as primeiras amostras utilizadas para roubar informação bancária dos usuários foram simples keyloggers, muitos deles utilizando códigos disponíveis publicamente com pequenas customizações a fim de capturar somente ações específicas. Isto foi suficiente nesta época já que os sites de bancos não utilizavam nenhum tipo de proteção contra esta ameaça.

Código fonte de um keylogger disponível publicamente

Código implementado no binário malicioso

O código era bem simples; apenas utilizava a função GetAsyncKeyState para verificar o estado de cada tecla e então logar como necessário. A maioria dos keyloggers não utilizavam nenhum tipo de obfuscação para esconder os alvos, o que ajudava a identificação destes ataques.

Strings em plaintext utilizadas para identificar a navegação

Phishing Trojan

Após os bancos introduzirem o teclado virtual em seus sistemas, os uso de keyloggers não era mais tão efetivo. Para burlar estas proteções, os criminosos Brasileiros começaram a desenvolver mouselogger e mais tarde os Phishing Trojans.

Este tipo de malware utilizava DDE (Dynamic Data Exchange) para capturar a URL sendo acessada no browser; este método continua funcionando hoje em dia porém muitos dos programas maliciosos atualizaram seus códigos para utilizer OLE Automation ao invés de DDE já que este oferece opções mais avançadas.

Código utilizando DDE para capturar a URL acessada

Após capturar a URL acessada o malware então verifica se a URL está na lista dos alvos especificados. Se encontrado, o malware exibirá uma janela de phishing solicitando os dados bancários.

Phishing Trojan sendo exibido na janela do Internet Explorer

Neste ponto o malware não utilizava nenhum tipo de codificação ou encriptação – todas as strings estavam em plaintext facilitando a análise.

Strings do malware sem nenhuma criptografia/codificação

A informação roubada é então enviada ao atacante por email.

Email com as informações roubadas

Hosts

A fim de roubar as informações de uma maneira não tão simples de identificar como o Phishing Trojan eles começaram a redirecionar os usuários para páginas de maliciosas através da alteração do arquivo de hosts para resolver os domínios dos bancos para servidores especificados pelos atacantes. Desta maneira, o ataque seria muito mais transparente ao usuário aumentando as chances de um ataque com sucesso.

Dados inseridos no arquivo de hosts a fim de redirecionar o acesso

Código utilizado para escrever os dados no arquivo de hosts

Este tipo de ataque foi muito efetivo na época, enquanto nem todas as empresas de anti-malware eram capazes de identificar e bloqueá-los. Nós ainda encontramos algumas amostras utilizando modificação do arquivo de hosts porém não são mais tão efetivos.

Anti-rootkit

Nesta etapa eles entenderam que as soluções anti-malware e proteções de segurança utilizada pelos bancos estavam tornando seu trabalho mais difícil. Eles então começaram a aplicar seus esforços em remover as soluções de segurança antes de executar o payload malicioso a fim de aumentar as chances de uma execução com sucesso e se manter executando na máquina infectada por mais tempo.

Nada poderia ser melhor do que utilizar ferramentas de linha de comando conhecidas que já possuem capacidade de realizar estas ações – e muitas delas já na base de arquivos confiáveis.

• RegRun Partizan

Esta ferramenta é um arquivo Native Executable que executa na inicialização do sistema antes do subsistema Win32 inicializar. Ela é capaz de deletar arquivos e chaves de registros mesmo que protegidos por Kernel mode drivers, pois é executado antes que os drivers sejam carregados pelo sistema. Os comandos que devem ser executados são especificados nos arquivos .RRI como exibido abaixo.

Script RRI do Partizan com a lista de arquivos para remover

• The Avenger

Um driver do Windows projetado para remover arquivos e chaves de registro persistentes. Os comandos que serão executados no sistema são escritos no script que será carregado pelo driver assim que for inicializado.

Interface do The Avenger e o script para remover soluções de segurança

• Gmer

Gmer é um famoso detector e removedor de rootkit que possui diversas funcionalidades para detectar atividades de rootkit no sistema assim como remover arquivos utilizando seu próprio device driver. Como possui uma interface de linha de comando, é bem simples utiliza-lo para remover arquivos protegidos.

Arquivo BAT utilizando a função killfile do GMER para remover soluções de segurança

Mais detalhes sobre Trojans bancários utilizando GMER para desinstalar software de segurança pode ser encontrado em um blogpost separado.

Bootloader Malicioso

Após utilizar anti-rootkits os cibercriminosos Brasileiros foram mais a fundo e começaram a desenvolver seus próprios bootloaders, adaptados exclusivamente para remover as soluções de segurança da maquina do usuário. O downloader tem a função de instalar os arquivos maliciosos e então reiniciar a máquina. Após a reinicialização o bootloader malicioso pode remover do sistema os arquivos desejados.

Basicamente, o malware substitui o NTLDR original, que é o bootloader para os sistemas baseados em Windows NT até o windows XP, para uma versão modificada do GRUB.

GRUB loader modificado atuando como NTLDR

Este loader vai ler o arquivo menu.lst que aponta para os arquivos maliciosos xp-msantivirus e xp-msclean que já foram instalados no sistema.

Arquivo menu.lst com os parâmetros para executar os comandos maliciosos

Assim que executado o malware vai remover os arquivos relacionados a soluções de segurança e então restaurar o arquivo NTLDR original que foi previamente renomeado para NTLDR.old.

Comandos executados para remover os módulos de segurança e restaurar o NTLDR original

O que encontramos hoje em dia

Automação

A maioria dos bancos estavam utilizando identificação de máquina para evitar tentativas não autorizadas de realizar operações utilizando as informações roubadas. Para burlar isto os criminosos começaram a realizar as operações a partir da máquina infectada, utilizando Automação do Internet Explorer (também conhecido como Automação OLE) para interagir com o conteúdo da página.

As primeiras amostras utilizando este tipo de ataque foram os Browser Helper Objects (BHOs) que podiam detectar uma transação de transferência e então alterar a conta de destino, enviando o dinheiro para o criminoso ao invés do destinatário real.

Mais tarde, o mesmo método foi muito utilizado nos ataques a Boletos, onde eles utilizavam automação para capturar o código de barras digitado para então substituir pelo código fraudulento.

Como este método funciona apenas para o Internet Explorer, o malware precisa forçar o usuário a utilizar o internet banking por este browser. Portanto, ele implementa um timer que verifica se o Firefox ou Chrome está sendo utilizado e então mata o processo.

Código para impedir o uso do Chrome e Firefox

Quando uma instância do IE é encontrada, o malware procura por uma aba para que seja possível ler o texto da janela e então saber qual URL está sendo acessada.

Encontrando o handle da aba e obtendo a URL sendo acessada

Busca por títulos de alvos específicos

Como a automação vai processar a estrutura da página, é necessário saber se a vítima está na página para informar os dados do Boleto. Ele instala um tratador para o evento OnDocumentComplete para coletar a URL complete assim que a página é carregada e então verificar se o usuário está na página alvo.

Busca por páginas específicas

Após confirmar que o usuário está na página alvo, o malware vai processar a estrutura da página e instalar um evento para o botão de submit, com isso ele pode ter o controle da execução logo após o usuário submeter a página e então processar o conteúdo informado.

Busca por um textbox específico e captura o texto infomado

Após coletar a informação, ela é processada e então alterada para o conteúdo malicioso antes da página ser enviada.

Para estas amostras nós encontramos obfuscação de string, detecção de debugger e detecção de máquina virtual assim como o método utilizado que não é tão simples de detectar como outros ataques envolvendo Phishing Trojan e Hosts.

Obfuscação de código e RunPE

Buscando novas maneiras de evitar a detecção, os criminosos Brasileiros começaram a utilizar obfuscação a fim de esconder as partes do código que executam suas operações principais.

No código abaixo o desenvolvedor encriptou o código original da função utilizada para realizar o download do payload malicioso; em uma análise estática não é possível entender o propósito desta função.

Função de download encriptada

Em tempo de execução o malware vai chamar a função para decriptar este código antes de executá-lo.

Chamada da função de decriptação

Rotina de decriptação

Como podemos ver no código acima, a decriptação é uma simples operação sub utilizando a chave 0x42 no byte encriptado – uma maneira simples e rápida de esconder partes de código.

Função de download decriptada

Para evitar a detecção pelo firewall de rede, o arquivo baixado é encriptado utilizando uma função de criptografia própria.

Arquivo encriptado

Arquivo decriptado

A função de encriptação também está escondida pelo mesmo método utilizado na função de download – após decriptar o código foi possível encontrar uma encriptação baseada em XOR combinada com uma operação shift-right na chave XOR.

Após decriptar o arquivo, ele não será executado por métodos normalmente encontrados em códigos maliciosos. Para esconder o processo na máquina o malware utiliza um método conhecido como RunPE onde o código executa um processo confiável (como iexplorer.exe ou explorer.exe) em um modo suspenso e então modifica seu conteúdo em memória pelo código malicioso e executa-o.

Código executando o processo confiável com estado suspenso

Após criar o processo no estado suspenso o código vai escrever o novo código para a área de memória, definir o novo EIP para execução e então continuar a thread.

Escrevendo o código malicioso e retomando a execução da thread

Processo do Internet Explorer hospedando o código malicioso

Como o código malicioso está executando no espaço de memória alocado para o Internet Explorer, utilizando ferramentas como o Process Explorer para verificar a assinatura do processo não funciona pois ela verifica a assinatura do arquivo em disco e não na memória.

Está mais que claro que eles mudaram completamente de código amadores para um desenvolvimento muito mais profissional e entendemos que já era hora de atualizar o processo de análise de malware Brasileiro. Estamos certos que a maior parte desta evolução aconteceu devido ao contato e a troca de conhecimento com outros cenários de malware, principalmente do Leste Europeu, que descrevemos neste artigo.

AutoIt Crypto

AutoIt atualmente tem sido bastante utilizado como downloader e crypto para o payload final a fim de evitar a detecção. Após compilado o script AutoIt é encriptado e inserido no binário gerado o que faz necessário extrair o script original antes de analisar seu código.

Buscando por melhores maneiras de esconder o payload final, os cibercriminosos Brasileiros desenvolveram um novo crypto utilizando a linguagem AutoIt onde o payload decryptado é executado utilizando a técnica RunPE.

Fluxo de execução do AutoIt Crypto

O crypto utiliza dois métodos diferentes para armazenar o arquivo encriptado: o primeiro é utilizando a função FileInstall já existente no AutoIt, e a outra é inserindo o arquivo no final do binário.

Quando utilizado o segundo método o crypto escreve a chave que é utilizada para marcar onde o payload encriptado começa para ser possível encontrar o conteúdo para decriptar. Na amostra abaixo, a chave utilizada é uma uma versão reduzida de “Sei que ganharei 20K”.

Chave utilizada para marcar onde o payload encriptado começa

Código principal do AutoIt Crypto

Após a leitura do payload encriptado ele é decriptado utilizando a chave “VENCIVINICI” e então o payload é executado utilizando RunPE.

A função de decriptação não é escrita em AutoIt – é escrita na linguagem C. Após ser compilado os bytes foram incluídos no código como string e então mapeados para a memória e executado utilizando a API CallWindowProc.

Implementação da função de decriptação

Nós encontramos os seguintes algoritmos implementados como métodos de encriptação/compressão para este crypto:

• RC4
• XXTEA
• AES
• LZMA
• ZLIB

O uso do AutoIt em desenvolvimento de malware não é algo novo, porém em meados de 2014 identificamos uma onda de ataques utilizando AutoIt no Brasil, como podemos ver no gráfico abaixo.

Trojan.Win32.Autoit: número de usuários atacados no Brasil

MSIL Database

Outro tipo de malware que emergiu recentemente foi malware desenvolvido em .NET ao invés de Visual Basic 6 e Delphi, seguindo uma tendência que vimos mundialmente. Não é difícil encontrar um downloader escrito em .NET. De toda forma, alguns samples de Trojan-Banker.MSIL.Lanima chamaram nossa atenção ao verificar que alguns deles não utilizavam funções normalmente utilizadas para o download de payload.

Função de download

Como podemos ver na imagem acima esta amostra não utiliza nenhuma função de download porque utiliza SQL Server para hospedar o conteúdo do binário, com isso, utiliza apenas um comando SQL para receber o conteúdo e armazenar no disco.

As strings estão codificadas com base 64 e encriptadas com o algoritmo Triple DES para esconder o texto relacionado com as ações principais do malware.

Função de descriptografia

Esta família de malware é bastante prevalecente no Brasil e na China:

MSIL Crypto

Seguindo o mesmo método utilizado peo AutoIt Crypto os criminosos desenvolveram outro crypto, desta vez utilizando a linguagem .NET. O processo para extrair o executável real é basicamente o mesmo que utilizado pelo AutoIt Crypto porém ele tem um módulo intermediário que é reponsável por extrair o payload final.

Olhando o módulo principal nós temos um código .NET e a função principal deste módulo é extrair e carregar a DLL existente no binário.

Fluxo de execução do .NET Crypto

Função principal do Crypto

Como podemos ver, a função acima vai dividir o conteúdo do binário utilizando o separador “cdpapxalZZZsssAAA” e utiliza a segunda parte que contém o código encriptado do loader.

Início do conteúdo encriptado

Então é hora de decriptar o conteúdo chamando a função com o nome “fantasma”, o nome official utilizado nos fóruns é PolyRevDecrypt que é basicamente uma operação XOR entre o byte encriptado, o ultimo byte do buffer encriptado e um byte da chave passada para a função.

Função de decriptação

Após decriptar, o código será carregado e executado pela função “docinho”.

Função para carregar e executar a DLL

O código deste módulo é basicamente o mesmo que encontramos no executável principal exceto que este utiliza o segundo bloco do conteúdo separado.

Função principal do loader

RAT

Na oferta de reduzir as perdas relacionadas a ataques cibernéticos, os bancos implementaram autenticação de dois fatores (2FA) utilizando token por dispositivos e SMS para transações bancárias por meio de internet banking como complemento as soluções já utilizadas para identificação de máquina. Para resolver este problema os cibercriminosos criaram uma ferramenta de administração remota desenvolvida especificamente para solicitar as informações necessárias para processar as transações online.

Fluxo de execução do RAT

O monitor de browser vai analisar o browser do usuário e verificar se algum dos bancos alvo estão sendo acessados; se estiverem, irá descompactar e executar o cliente RAT e então notificar o C&C sobre a nova infecção.

Monitoramento de acesso ao Internet Banking

As strings utilizadas por este malware são encriptadas por uma rotina de criptografia própria. Após descriptografar as strings podemos identificar os alvos assim como partes importantes no código.

Strings descriptografadas

Para este tipo de infecção é comum os criminosos criarem uma maneira de gerenciar os ataques. Aqui nós podemos ver o número de computadores infectados no mesmo dia, lembrando que este número é equivalente ao número de usuários que acessaram o internet banking enquanto o malware estava em execução no seu computador.

Painel do C&C mostrando a lista de usuários infectados

O cliente RAT irá se conectar ao servidor para avisar o atacante que uma nova vítima está acessando o internet banking. Com isso é possível executar o ataque em tempo real.

Servidor RAT mostrando que uma nova vítima está conectada

Neste momento o atacante necessita apenas esperar o usuário logar para então proceder com o ataque. Quando o usuário já se encontra logado, o atacante pode ver a tela do usuário, bloquear e controlar a execução assim como solicitar informações específicas que são necessárias para consolidar a fraude, como:

• Token
• Tabela de senhas
• Data de nascimento
• Senha da conta
• Senha do internet banking
• Assinatura eletrônica

Para evitar que o usuário possa perceber que o seu computador está sendo controlado remotamente, este RAT tem uma função que simula um update do plugin de segurança exibindo uma barra de progresso e desabilitando todas as interações do usuário. Enquando isso, o atacante pode realizar as operações bancárias utilizando a sessão ativa do browser já que a tela de bloqueio não e exibida para o atacante.

Tela de bloqueio simulando um update

Se alguma informação é solicitada para confirmar as transação, token por SMS por exemplo, o atacante pode solicitar estas informações para a vítima que irá pensar que a informação é necessária para continuar o processo de update.

Tela solicitando o código do token

Assim que o usuário fornecer a informação, o atacante pode utilizá-las na página do banco, burlando o segundo fator de autenticação utilizado na transação.

Informação recebida da vítima

Ransomware

Os criminosos Brasileiros não estão trabalhando somente com malware bancário – eles também estão explorando outros tipos de ataques envolvendo ransomware. Alguns anos atrás, encontramos o TorLocker que contém detalhes no código do malware sugerindo que o desenvolvedor é do Brasil.

Código contendo strings sugerindo que o autor é do Brasil

Como podemos ver na imagem acima, encontramos o texto marcado em azul: “Filho de Umbanda não cai!”. Umbanda é uma religião não ortodoxa no Brasil. O nome marcado em vermelho é o apelido do autor e ele também utiliza a extensão .d74 para os arquivos encriptados. Este usuário é muito ativo em fórums underground buscando serviços maliciosos no Brasil.

Nós também encontramos outras referências, como o uso de um serviço no Brasil para capturar o IP da vítima para então notificar sobre a infecção.

Requisição para um serviço Brasileiro para obter o IP da vítima

Alguns meses atrás, encontramos outro ransomware baseado no código do Hidden Tear que foi modificado para direcionar o ataque a usuários Brasileiros, diferente do primeiro que era direcionado a usuários de idioma Inglês e Japonês.

Computador da vítima mostrando mensagens em Português, solicitando o pagamento para recuperar os arquivos

Por que eles evoluem

Nós temos evidências suficientes que os criminosos Brasileiros estão cooperando com grupos do Leste Europeu envolvidos com ZeuS, SpyEye e outros malware criados na região. Esta colaboração afeta diretamente a qualidade e o nível de ameaça do malware local Brasileiro, pois seus autores estão adicionando novas técnicas em suas criações e se inspirando em copiar algumas funções usadas em malware originado do Leste Europeu. Os criminosos Brasileiros não estão desenvolvendo somente a qualidade do seu código mas também utilizando infraestrutura do cibercrime do exterior.

Nós vimos o primeiro sinal desta ‘parceria’ no desenvolvimento de malware utilizando scripts PAC maliciosos. Esta técnica foi explorada exaustivamente no malware Brasileiro iniciando em 2011 e mais tarde adotado pelo Trojan bancário Russo Capper. Esta cooperação continua com os ciminosos Brasileiros utilizando infraestrutura de Trojans bancários do Leste Europeu – o Trojan-Downloader.Win32.Crishi foi o primeiro a utilizar domínios DGA hospedados em empresas bulletproof da Ucrânia. Também o malware de Boleto adotou o uso massivo de domínios fast flux, visando evitar a retirada dos C2s – nós vimos que os domínios “bagaça”, registrados através de serviços anônimos, que hospedavam crimeware e dados de boleto resolviam IPs diferentes a cada requisição.

The “bagaça” domains: fast flux and bulletproof from Eastern Europe

Outro sinal claro desta cooperação é a presença constante de cibercriminosos Brasileiros em fórums underground Russos ou do Leste Europeu. Não é algo raro encontrar criminosos Brasileiros em fórums Russos procurando amostras, comprando novos crimeware e malware de ATM/PoS, ou negociando e oferecendo seus serviços. O resultado desta cooperação pode ser visto no desenvolvimento de novas técnicas adotadas nos malware Brasileiros.

O Brasileiro autor do TorLocker negociando em um fórum underground Russo

Estes fatos mostram como os criminosos Brasileiros estão adotando novas técnicas como o resultado de uma colaboração com seus parceiros Europeus. Acreditamos que é apenas a ponta do iceberg, já que este tipo de troca tende a aumentar com o passar dos anos pois o crime Brasileiro desenvolve e busca novos meios de atacar empresas e cidadãos.

Conclusão

O cibercrime no Brasil mudou drasticamente nos últimos anos, saindo de simples keyloggers gerados a partir de código fonte deisponível puclicamente para ferramentas de administração remota cusmomizadas que podem executar um ataque completo utilizando o computador da vítima.

Malware que costumavam exibir uma tela de phishing assim que executado agora é completamente reativo e aguarda por uma sessão válida antes de começar o trabalho.

Isto significa que os criminosos Brasileiros estão investindo muito mais dinheiro e tempo para desenvolver seus códigos maliciosos, aperfeiçoando técnicas anti-debugging tornando os malware indetectáveis por mais tempo.

Como sabemos, eles estão em contato com criminosos do Leste Europeu, principalmente Russos, onde eles trocam informações, código fonte de malware e serviços que serão utilizados em ataques no Brasil. Podemos ver que muitos dos ataques usados no Brasil foram vistos primeiramente nos malware Russos assim como técnicas Brasileiras sendo utilizadas em ataques Russos.

Baseado nisso, podemos esperar por malware Brasileiros com obfuscação de código aperfeiçoada, técnicas de anti-debugging, algoritmos de encriptação e comunicação segura tornando nosso trabalho mais difícil do que nos dias atuais.