Perigos Ocultos por Trás de URLs Evasivos do Secureserver.net

Os trojans bancários continuam a evoluir rapidamente, afetando grandes organizações bancárias em todo o mundo. Observamos um aumento no uso de malware que utiliza secureserver[.]net para atingir regiões de língua espanhola e portuguesa, abrangendo instituições financeiras da América Latina. Além disso, os hackers também estão mirando países de língua espanhola e portuguesa na Europa e em outras partes do mundo.
 

Essa campanha é espalhada via URL secureserver[.]net, que é um site de hospedagem que também oferece registro de domínios e serviços de hospedagem web em todo o mundo. Durante nossa pesquisa no X-Labs, observamos que esse domínio é frequentemente abusado para hospedar conteúdo malicioso.
 

Acesso Inicial

_{Fig. 1 - Acesso inicial}
 

_{Fig. 2 - Acesso inicial #2}
 

O e-mail contém uma URL hospedada no secureserver[.]net com o seguinte padrão: https://\d{2,3}.\d{2,3}.\d{2,3}.\d{2,3}.host.secureserver.net
 

A URL, quando acessada de locais fora das regiões da América do Norte e do Sul, exibe uma página em branco ou redireciona para outras páginas limpas. Tentamos acessar uma URL semelhante em Portugal e ela baixou um arquivo de arquivo. O arquivo de arquivo contém um arquivo .hta, que contém uma pequena obfuscação.

 

Arquivo HTA:

O arquivo contém uma URL que contém o código:
 

198.148.167.72.secureserver[.]net/OQQst11/gV7Pus771.js
 

_{Fig. 3 - Arquivo HTA}

Código JavaScript:

_{Fig. 4 - Código JavaScript}
 

O código JavaScript novamente resolve para uma URL, “198.148.167.72.host.secureserver[.]net/VFb51.vbs” que contém código VBS.

Código VBS da Primeira Etapa

_{Fig. 5 - Código VBS da primeira etapa}

O script, ao ser executado, se instala em C:\Public como {{randomfilename}}.vbs e executa esse VBS usando o shell. O script VBS contém a URL que é acessada, e outro nível de execução é realizado:

Trecho do Código VBS da 2ª Etapa

_{Fig 6 - Código VBS da segunda etapa}

JavaScript Ofuscado

_{Fig. 7 JavaScript Ofuscado}
 

O script está ofuscado usando JS, que é especificamente ajustado para rodar em navegadores web.
 

Ao desofuscar o código, podemos retratar o comportamento da campanha estaticamente.
 

Código desofuscado e análise estática:

Ao desofuscar o código, descobrimos que ele verifica vários critérios antes de liberar o payload real: 1) Verificação de antivírus 2) Verificação de VM 3) Verificação de OS e BIOS

Verificação de antivírus:

_{Fig. 8 - Verificação de antivírus}

Verificação de VM e BIOS

_{Fig. 9 - Verificação de VM e BIOS}

Verificação do sistema operacional e idioma do OS

 _{Fig. 10 - Verificação do sistema operacional e idioma do OS}
 

 _{Fig. 11 - Verificação do sistema operacional e idioma do OS (continuação)}

Se todos os critérios acima forem atendidos, ele cria uma pasta na rede HOMEDRIVE e baixa o executável AutoIt e o script codificado na pasta, criando um atalho para essa pasta na inicialização:

_{Fig 12 - Executável AutoIT}

A imagem acima mostra três URLs, que ao serem acessadas, soltam arquivos em uma localização de rede do sistema:

• Hxxps://45[.]40.96.231/AutoIt3 – Script AutoIt
• Hxxps://45[.]40.96.231/AutoIt3.exe – Executável AutoIt
• Hxxps://45[.]40.96.231/jama1crt – Algum arquivo de dependência responsável pela atividade maliciosa
   

A partir daqui, cria um atalho que é executado na inicialização:
 

 _{Fig. 13 - Atalho executa na inicialização}
 

Script AutoIt codificado e decodificado e análise:

_{Fig. 14 - AutoIt encoded header (see top left)} 

 Script Decodificado

O script decodificado é grande com muitas verificações, principalmente realizando injeção de processos na memória. Uma parte do script decodificado mostra a injeção em um arquivo PE que começa com o cabeçalho 0x4D5A para arquivo Executável, seguido por uma conversão BinaryToString do código hexadecimal responsável por carregar DLL na memória e invocar sua função exportada:

_{Fig. 15 - Script Decodificado}

Ao executar o arquivo codificado AutoIt e o autoit.exe junto com o arquivo de dependência jama1crt mencionado acima, é gerado um arquivo de despejo de memória. Ao analisar estaticamente o arquivo de despejo de memória, descobrimos que ele novamente continha um arquivo AutoIt incorporado:

 _{Fig. 16 - Arquivo de despejo de memória contém AutoIt}

Este script codificado realiza o restante da injeção na memória utilizando processos como ALLOCATEEXESPACE, UNMAPVIEWSECTION, ALLOCATEEXESPACEATADDRESS e injeta código malicioso em um dos processos legítimos da Microsoft, mobsync.exe:

_{Fig. 17 - Injeção de código malicioso no mobsync}

 _{Fig. 18 - Injeção de código malicioso no mobsync (continuação)}

Alguns comportamentos importantes realizados pelo malware que vale a pena notar: 1) Verifica o idioma e a localização do sistema 2) Adiciona informações do processador ao registro para detectar sandboxing e 3) Verifica informações do sistema
 

Após a execução e a injeção maliciosa no mobsync.exe, ele se conecta a C2s maliciosos fornecendo informações importantes, como Nome do Computador, Informações do Sistema, Detalhes do Usuário e do administrador, e outras informações importantes.
 

Conclusão:

O malware é distribuído através de URLs geo-restritas incorporadas no e-mail, com o principal objetivo de roubar as credenciais do sistema da vítima ao infectar o sistema da vítima com injeção de processos usando o script e ferramentas AutoIt. As URLs funcionam principalmente nas regiões da América do Norte e América do Sul com a intenção de roubar informações bancárias e atuar como trojans bancários ou infostealers.
 

Uma vez acessada a partir do e-mail, a URL baixa um arquivo de arquivo que contém um arquivo .HTA. O arquivo HTA então se conecta a uma URL maliciosa e realiza uma série de atividades, incluindo a navegação de JS codificado através do navegador. Posteriormente, resulta na liberação do script AutoIt, executável e payload de dependência.
 

Quando todos são executados juntos, eles realizam injeção de processos na memória do sistema. Sendo evasivo por natureza, o arquivo executa verificações no idioma do sistema, localização e outras variáveis de ambiente. Após a execução bem-sucedida, ele se conecta a C2s maliciosos fornecendo informações sensíveis aos atacantes.
 

Informações Adicionais:

Durante o trabalho na campanha, foi observado que, além de seguir o padrão mencionado anteriormente, também rouba informações ativamente por técnicas de phishing e diretamente ao liberar executáveis em arquivo de arquivo.

Declaração de Proteção

Os clientes da Forcepoint estão protegidos contra esta ameaça nas seguintes etapas do ataque:

• Etapa 2 (Isca) – Entregue via URL armada incorporada em um e-mail. E-mails e URLs incorporadas são bloqueados por análises de e-mail, análises da web, respectivamente, e Análises de Segurança em Tempo Real.
• Etapa 3 (Redirecionamento) – Redirecionamentos identificados para baixar vários payloads são categorizados e bloqueados sob classificação de segurança.
• Etapa 5 (Arquivo Dropper) – Os arquivos dropper são adicionados ao banco de dados de malware da Forcepoint e são bloqueados.
• Etapa 6 (Call to Action) – O malware entra em contato com servidores de comando e controle (C&C) para fornecer dados sensíveis do usuário, que são categorizados e bloqueados sob classificação de segurança.
   

Indicadores de Compromisso: