DownAndExec: malwares bancários utilizam CDN no Brasil

Recentemente acompanhamos um forte crescimento no uso de NSIS (Nullsoft Scriptable Install System) para a propagação de malwares bancários. Pelos dados de telemetria é possível notar que o último mês de junho foi marcado por algumas campanhas que, como veremos, têm o intuito de executar malwares bancários em computadores no Brasil.

Figura 1: Telemetria da detecção de NSIS/TrojanDropper.Agent.CL em junho de 2017.

A cadeia de ataque é bastante extensa, envolvendo execução de scripts remotos (em alguma medida semelhante ao que vemos da tendência recente de “fileless” em malwares bancários), uso de CDN para comando e controle (C&C), além das habituais técnicas de execução e proteção de malwares.

Este artigo se propõe apenas a analisar o padrão downAndExec que faz uso intensivo de scripts JS para baixar e executar, nesse caso, bankers nas máquinas das vítimas.

Fase 1: Infecção inicial

A cadeia de ataque inicia-se pelo envio de arquivos detectados pela ESET como NSIS/TrojanDropper.Agent.CL. Através de consultas disponíveis no VirusTotal por nomes de arquivos associados a amostras analisadas é possível perceber o intuito de convencer vítimas a executarem o malware valendo-se da Engenharia Social.

Uma característica do NSIS é o fato de, desde a versão 9.43 (junho/2014), ser possível extrair o script embutido no executável, que contém as funcionalidades desse trojan inicial.

Quando carregado, o script faz extenso uso de chamadas recursivas para dificultar o acompanhamento do caminho de execução.

Com poucas modificações em relação ao script original, que faz uso de recursos como ActiveX (disponível apenas para Internet Explorer), é possível debuggar o script utilizando DevTools do Chrome.

Figura 2: chamada recursiva c() e patch do script para debuggar via DevTools.

O script é característico dos malwares classificados como downloader, cuja finalidade é baixar e executar outros malwares na máquina. No presente caso, o script faz o download de um snippet JS hospedado externamente, necessário para complementar sua execução.

A infraestrutura de um provedor de CDN vem sendo intensivamente utilizada para a hospedagem do referido snippet JS. Como é impraticável bloquear todo o domínio da CDN, a resposta à ameaça impõe alguns desafios:

• Bloqueio de novos C&C: talvez por isso observou-se (e ainda é possível observar) o surgimento amiúde de novas urls no mesmo domínio hospedando os C&Cs.
• Busca por IoCs: em ambientes afetados há (potencialmente) um grande número de registros de acesso feitos por softwares não-maliciosos.

Figura 3: Simulação da CDN que hospeda o snippet JS malicioso.

Para simular a CDN que hospeda o snippet JS malicioso e facilitar o debugging, é possível servir esse conteúdo localmente, utilizando um serviço HTTP local (apenas observando para habilitar o compartilhamento de recursos e, dessa forma, executar o script em outras origens).

Figura 4: carregamento do snippet JS hospedado externamente.

Nota-se na figura 4 que o script faz a requisição ao domínio externo (CDN), para obter o conteúdo do snippet, e caso o status da resposta seja “OK” (i.e.: HTTP 200), o conteúdo é retornado.

Fase 2: segundo estágio de download

Após a chamada f(), que retorna o conteúdo do snippet JS (i.e.: a string do script), é invocado o método eval, adicionando a string “downAndExec(\”<parametro_1>\”, \”<parametro_2>\”)” ao final do snippet JS.

Figura 5: chamada de downAndExec com contenação de C&C e x-id ao snippet JS.

O primeiro parâmetro (<parametro_1>) corresponde à URL onde está hospedado o C&C, enquanto o segundo parâmetro (<parametro_2>) contém o dado de “x-id” que, como veremos adiante, é necessário para realizar o download de outros payloads.

Figura 6: relação dos arquivos envolvidos em downAndExec.

O snippet JS possui diversas strings que são atribuídas em tempo de execução. Isso dificulta a compreensão do script quando é realizada uma análise estática (muito embora os nomes das funções não tenham sido modificados ou obfuscados).

Figura 7: obfuscação utilizada no snippet JS.

O trecho principal desse script refere-se justamente à função downAndExec(), que é adicionado pelo primeiro downloader NSIS. Dessa forma, caso o snippet JS seja analisado separadamente, possivelmente por alguma solução de sandboxing, as funções maliciosas não serão executadas e o veredito final da análise será de que o snippet não é malicioso.

Figura 8: definição de downAndExec() no snippet JS.

Além da proteção contra sandboxing, o script também faz algumas checagens antes de executar o trecho malicioso, para filtrar apenas computadores potencialmente interessantes aos cibercriminosos.

A primeira checagem é isOS(), que na verdade retorna simplesmente true, mas pode ser um stub para alguma versão futura desse malware. A segunda checagem é haveAnyPrograms(), que verifica se há algum arquivo de interesse instalado no computador da vítima.

Figura 9: estrutura da função haveAnyProgram() que busca por softwares bancários no sistema.

As funções getPathfromGuid() e getPathFromGuidWow() fazem a busca por arquivos através da existência de chaves CLSID em HKCR. Os arquivos buscados via CLSID são:

Caso nenhum dos arquivos sejam encontrados, o script passa a buscar por pastas associadas a programas de bancos como Bradesco, Itaú, Sicoob e Santander.

A procura por esses arquivos visa evitar a ativação das funcionalidades maliciosas em computadores que provavelmente não são utilizadas para a realização de online banking. Com isso, o nível de detecções diminui (ficando fora da mira de analistas), enquanto a efetividade fica bastante alta.

Sendo encontrado algum desses arquivos em haveAnyPrograms(), há uma terceira checagem para verificar se a conexão parte do Brasil. Como as contas das vítimas de interesse estão no Brasil, a fim de fugir de análises (principalmente as automáticas) realizadas fora do país, o snippet verifica se o IP do cliente é de algum AS (sistema autônomo) brasileiro.

Figura 10: função para verificar que a origem do acesso está no Brasil.

A verificação é feita através da API de ip-api.com, que retorna dados referentes ao IP público fornecido pelo provedor quando o cliente conecta-se à Internet. Caso o countryCode seja “BR”, o snippet verifica com sucesso a terceira condição (i.e. isBR()) e passa para a execução do trecho malicioso.

Comunicação com C&C e execução de payload

Caso o computador da vítima cumpra os requisitos, a execução prossegue para o trecho onde é realizada a comunicação com o C&C e acontece o comprometimento (final) da máquina.

Figura 11: principal trecho de execução do snippet JS.

A função dlToText_s() que está sendo chamada na linha 497 recebe dois parâmetros: a URL do C&C (passada em downAndExec como <parametro_1>), concatenado com “/?t”, e uma string (passada em downAndExec como <parametro_2>.

O primeiro parâmetro de dlToText_s() (i.e.: “<parametro_1>/?t”) indica qual payload do C&C deve ser baixado, enquanto o segundo parâmetro serve apenas para proteger o download do payload por um campo “x-id” (de valor <parametro_2>) adicionado ao header da requisição GET .

Figura 12: funções utilizadas para o download de payloads do C&C.

O arquivo t, no momento da análise, continha apenas o valor “3”. Como vemos em downAndExec(), há diferentes comportamentos possíveis baseados no valor de t.

Figura 13: conteúdo do arquivo t.

Esse valor é atribuído a K e o script prossegue com as seguintes possibilidades:

• K = “1”: snippet sai de execução sem realizar nenhuma ação maliciosa.
• K = “3”: snippet realiza o download de três arquivos, sendo um deles apenas um string (com o nome de uma DLL), e outros dois arquivos PE. Na sequência a função runAsUser() é chamada.
• K = “4”: Caso semelhante a K = “3”, no entanto apenas dois arquivos PE são baixados e, ao invés de runAsUser(), a função runAsRundll() é chamada.

O arquivo ep (para K = “4”) não estava disponível para download, portanto ainda não é possível saber o que acontece nesse caso. Para K = “3”, os arquivos baixados são:

A análise dos payloads está em andamento, no entanto, o fato de se executar o CERTMGR.EXE indica que o PE malicioso é injetado na memória via pré-carregamento de DLL (DLL preloading attack, em inglês).

Como vimos, a técnica downAndExec envolve dois estágios de download e diversas proteções, tanto para filtrar apenas máquinas com perfil desejável, quanto distribuindo os códigos maliciosos em trechos “estéreis”, que sozinhos não executam (a fim de bypassar proteções online), mas que, quando juntos, são capazes de comprometer os computadores das vítimas.

Ainda há questões que exigem mais investigação em relação a downAndExec:

• Por que o uso de CDN para a hospedagem do snippet JS?
• Há funções como runAsAdmin() que não estão sendo utilizadas. Estaria o snippet JS servindo de módulo compartilhado para outros malwares do cibercrime brasileiro?
• Como deveria funcionar a infecção quando K = “4”?

Havendo respostas para essas e outras perguntas vamos voltar nesse tema, portanto, não deixe de acompanhar o blog para ficar por dentro das novidades utilizadas pelo cibercrime brasileiro.

Indicadores de Comprometimento (IoC)