Boaxxe adware – Uma nova fraude publicitária – Parte 2

Como prometido, cá estamos para dar continuidade ao artigo que iniciámos a semana passada, acerca da família de malware Win32/Boaxxe.BE que tem como principal objectivo levar tráfego a sites de publicidade, utilizando diversas técnicas fraudulentas, e, assim, ganhar dinheiro. Se no primeiro dos textos, descrevemos o ecossistema em torno desta operação, hoje vamos abordar os aspectos técnicos.

Em primeiro lugar, vamos começar por explicar o processo de instalação, depois vamos relevar como e porquê mantêm a sua própria cache DNS e finalmente o processo de implementação da fraude baseada em cliques.

Processo de instalação

Para dar início a esta análise técnica vamos descrever a forma como o Win32/Boaxxe.BE instala os seus componentes no computador. Resumidamente, este processo segue os três passos indicados na imagem abaixo:

Passo 1 da Instalação

O Win32/Boaxxe.BE chega como um executável Visual Basic, acompanhado do ficheiro “setup.dat“, ambos dentro de um instalador NSIS que simplesmente expande estes ficheiros e executa o binário. Depois de diversas análises ao sistema, em busca de emuladores ou debuggers, este programa extrai uma imagem BMP da sua secção de código. Um exemplo desta imagem é mostrada abaixo:

Os dados da imagem são então descodificados e transformados num novo executável, que assim que for corrido vai decifrar a última camada de código. Esta técnica “recipiente imagem” é provavelmente utilizada para fazer os antivírus acreditarem que o código encriptado não deverá ser considerado para análise, uma vez que se trata de parte de uma imagem. Finalmente, o ficheiro “setup.dat” é desencriptado com uma chave contida em si mesmo, e posteriormente expandido (ou descomprimido se preferirem) com a biblioteca aPLib. Entretanto as instruções JMP e CALL são reconstruídas para se obter o ficheiro binário final.

Passo 2 da Instalação

Com o objectivo de manipular os resultados das pesquisas efectuadas nos motores de busca, o Win32/Boaxxe.BE necessita de controlar o browser do utilizador. A forma como ele é implementado varia de acordo com o browser que está a ser utilizado. Actualmente o Win32/Boaxxe.BE manipula o Chrome e o Firefox através de extensões, enquanto o Internet Explorer é controlado através de instruções carregadas na memória criadas pelo ficheiro binário final que referimos acima. Vamos agora explicar como decorre a instalação das extensões para o Firefox e Chrome.

Chrome

Ficheiros da Extensão

As extensões do Chrome são normalmente distribuídas como um ficheiro CRX assinado, que pode ser instalado abrindo-se simplesmente com o browser. Porém, para fins de desenvolvimento, é também possível instalar extensões “descompactadas”, o que significa copiar os ficheiros das extensões para o lugar certo e por fim modificar as configurações do Chrome para carregar a extensão. Este último método é utilizado pelo Win32/Boaxxe.BE.

Manifesto da extensão, um objeto JSON que contém os metadados da extensão:

O nome da extensão no manifesto será escolhido a partir de uma lista de aplicações instaladas na máquina, com base num valor específico de hardware. Por outras palavras, cada máquina infectada vai usar um nome diferente para a extensão. Este tipo de escolha, dependente de hardware, é normalmente utilizada pelo Win32/Boaxxe.BE, como teremos oportunidade de observar.

Posteriormente, o manifesto declara dois ficheiros JavaScript. O primeiro é um script que corre em segundo plano e que será executado pela extensão enquanto estiver em funcionamento. O segundo é um script de conteúdo que será injetado em cada página corresponde ao parâmetro associado (todas as páginas da web, neste caso). Finalmente, a extensão pede permissão para aceder a todas as páginas (“http:// * / *”, “https:// * / *”) e a várias APIs do Chrome de forma a manipular com sucesso o browser.

O código da extensão, é composto por três ficheiros diferentes. Em primeiro lugar, o script de fundo:

Este script é feito por cerca de 100 linhas de código ofuscado e contém o núcleo de toda a extensão, sendo essencial para o seu funcionamento.

Em segundo lugar, chega o script de conteúdo:

Este script envia simplesmente uma mensagem com o URL actual e executa a resposta.

Em terceiro lugar, está presente um objecto JSON, chamado JSON_PAYLOAD, composto por quatro campos.

Antes de executar os scripts, todos os valores sob a forma de “@@STRING@@” serão substituídos no script que se encontra a correr em segundo plano.

Posteriormente, os três ficheiros, manifesto, script de fundo e scripts de conteúdo são guardados na pasta onde estão as extensões do Chrome.

A instalação de extensões

A instalação real da extensão no Chrome é feita através da modificação do objecto extensions.settings JSON contido no ficheiro “Preferences” na pasta do Chrome. Este ficherio contém – entre outras coisas – todas as extensões instaladas. O Win32/Boaxxe.BE insere as seguintes linhas para declarar a sua extensão:

E … pronto! Nesta altura, o código JavaScript da extensão será carregada no Chrome. A facilidade do processo de instalação pode parecer surpreendente, mas a Google anunciou recentemente que a partir deste mês, a instalação de extensões descompactadas só será possível quando o browser estiver em modo de programador.

Firefox

Ficheiros da Extensão

Os ficheiros necessários para a instalação da extensão para o Firefox são desencriptados.

install.rdf, o manifesto da extensão:

Os campos “id”, “name”, “version”, e “creator” são preenchidos com os valores que dependem do hardware que está presente no computador. Neste exemplo, assumimos que o id” é “{1234}”, e o nome “name” é “Microsoft Office”.

O manifesto será desencriptado e preenchido da seguinte forma:

Este ficheiro declara o código da extensão JavaScript – a linha “component” – e, posteriormente garante que a extensão será carregada, sendo recebida uma notificação na inicialização do Firefox.

O próprio código da extensão, está contido num ficheiro JavaScript. O código actual é descartado de forma semelhante ao que sucede no Chrome, com a substituição das mesmas variáveis @@STRING@@.

Finalmente, os três ficheiros (install.rdf, chrome.manifest e o ficheiro JavaScript) são colocados na pasta que o Firefox utiliza para armazenar as extensões.

A instalação da extensão

Para que a extensão seja instalada no Firefox, as duas operações que referimos em seguida ocorrem na pasta “Profile” do Firefox.

Declaração do caminho da extensão no ficheiro “extensions.ini”.

Verificação da existência de uma extensão com o mesmo ID na base de dados dados SQLite “extensions.sqlite”.

Em caso afirmativo, será feita uma alteração na tabela para apontar para a nova versão instalada. Caso contrário, a extensão é inserida na tabela. E … “voilá”! De modo semelhante ao que sucede com o Chrome, a simplicidade deste processo de instalação pode ser surpreendente. Importa mencionar que o Win32/Boaxxe.BE instala as suas extensões do Chrome e do Firefox de uma forma tão visível que elas aparecem no painel de extensões.

Passo 3 da Instalação

O objetivo da terceira etapa de instalação do Win32/Boaxxe.BE 3 é juntar todo o código binário que será executado no computador. Para este efeito é construída uma mensagem de rede da seguinte forma:

Na caixa a vermelho, vemos um cabeçalho binário composto por quatro campos:

A verificação da mensagem
O tamanho
O tipo de mensagem
O ID de afiliado

Na caixa azul, encontramos o payload da mensagem, que concatena o seguinte parâmetro de texto simples

A mensagem é uma chave encriptada de 244-byte gerada pseudo-aleatoriamente. Posteriormente esta chave é encriptada com uma chave pública RSA contida no binário, e, finalmente, a mensagem encriptada e esta chave recém-encriptada são codificadas em base64. O resultado final é enviado via HTTP para um endereço IP encriptado.

O servidor remoto normalmente devolve uma página HTML, embora também se possa recusar a servir uma máquina que enviou pedidos com muita frequência. Esta página HTML contém apenas um corpo com um valor codificado base64. Uma vez decodificado, aparenta ter uma estrutura de recipiente personalizado com duas bibliotecas do Windows no interior:

O DLL1 é uma biblioteca que será registrada para ser executada a cada inicialização no contexto do regsvr32.exe. A sua finalidade principal será desencriptar o segundo DLL e manter uma ligação com o sistema para garantir a sua execução em todos os processos.

O DLL2 é o payload real Win32/Boaxxe.BE; ele será armazenado no disco rígido do computador de uma forma encriptada – RC4 com uma chave criada a partir do número de série do volume do disco rígido e outros valores específicos de hardware. Por outras palavras, sem saber o hardware exacto usado na máquina, será difícil de decifrar a biblioteca.

Este é o momento em que a coluna Installs presente nas estatísticas do site partnerka.me é incrementada.

Importa salientar que, dependendo dos produtos de segurança instalados na máquina – detectados com os seus nomes de processo e referenciados no servidor de distribuição – podem ser aplicadas protecções aos binários de modo a que escapem à análise dos antivírus. Por exemplo, quando os produtos ESET estão a correr numa determinada máquina, o payload recebido vem protegido pelo software comercial Themida.

O Payload

Nesta altura, o DLL1 será sempre executado no sistema no contexto do regsvr32.exe e irá definir uma ligação nos eventos WH_CALLWNDPROC. Trocando por miúdos, isto significa que esta biblioteca será carregada em todos os processos de recebimento de mensagens por parte do GUI. Sempre que o mesmo for carregado, o DLL1 vai desencriptar o DLL2 e chamar a sua função principal.

Entre as diferentes operações executadas pelo DLL2 vamos descrever o sistema de cache DNS personalizado que mantém o módulo de fraude por cliques com intervenção do utilizador e, finalmente, o módulo automatizado.

Manutenção de cache DNS

Quando o DLL2 é carregado num browser (IE, Firefox ou Chrome) ele da início à manutenção da sua própria cache de DNS, que resulta da associação entre nomes de domínio e endereços IP. O objetivo deste sistema de cache personalizado é evitar a detecção ao nível da rede com base em solicitações de DNS, como veremos mais à frente.

Estruturas de Dados

A cache assenta sobre duas estruturas de dados:

O primeiro deles é a próprio cache – denominada posteriormente de DNS_CACHE e que consiste numa lista de entradas de 0 × 60 bytes. Um exemplo é mostrado abaixo:

Cada entrada contém informações relacionadas com um nome de domínio, que pode ser legítimo (ou seja, não relacionados com o Boaxxe) ou malicioso, por razões que se tornarão aparentes mais tarde. Mais precisamente, ele é composto por:

O próprio nome de domínio, precedido do primeiro byte pelo seu comprimento.
Um campo “domain purpose” (indicado em vermelho para a entrada 1), distinguindo os nomes de domínio legítimos dos maliciosos.
O endereço IP (caixa em azul).
Um campo “already resolved” (caixa em verde)
O timestamp no Windows OLE formato 64 bit (a preto) da última resolução com sucesso.

A segunda estrutura é na verdade uma versão compactada da anterior:

É um mapa que contém um máximo de 256 entradas com 24 bytes de largura cada uma. A chave (a azul) corresponde à soma da verificação de um nome de domínio armazenados na cache, seguida do último endereço IP conhecido associado a ela e, finalmente, duas janelas de tempo que descrevem o intervalo durante o qual o domínio esteve activo.

Esta estrutura é armazenada numa chave do registro do Windows em particular, e é atualizado regularmente a partir da cache DNS na memória.

Deste modo, o processamento da actualização da cache não começa do zero, mas reutiliza sim as informações recolhidas anteriormente e que estão armazenadas na chave do registo.

Gestão da Cache

Inicialização

Quando o DLL2 é executado na máquina pela primeira vez – no contexto do regsvr32.exe – a cache de DNS está vazia. Nesta altura, um conjunto de cerca de 500 nomes de domínio legítimos são desencriptados a partir dos dados do DLL2. Posteriormente, o programa escolhe um subconjunto destes domínios com base num valor específico de hardware. Isto permite que o programa preencha a cache com diferentes nomes de domínio legítimos em cada uma das máquinas infectadas. Finalmente, quando o DLL2 é carregado acrescenta alguns domínios maliciosos – geralmente quatro – para a memória cache, de acordo com o valor ID do afiliado.

Qual o motivo pelo qual o malware necessita de nomes de domínio diferentes e legítimos em cada máquina infectada? Porque ele vai gerar uma série de diferentes solicitações de DNS para nomes de domínio limpos a cada actualização de cache, e, assim, tornar difícil a detecção do Win32/Boaxxe.BE com base em solicitações de DNS confiáveis.

Actualização

O programa irá verificar regularmente cada entrada presente na cache e procederá à actualização a cada 24 horas. Como seria de esperar, ele irá fazer depois um pedido ao DNS pelo nome de domínio, sendo que curiosamente o endereço IP recebido não será o que está armazenado na cache.

Vamos dar um exemplo: se consultar um servidor DNS para o domínio thegreerfive.biz – um domínio malicioso usado pelo Win32/Boaxxe.BE – terá o IP 31.240.6.70 como resposta, que é 1F F0 06 46 em código hexadecimal. Porém, o endereço IP real do servidor associado ao domínio é 31.193.0.178, que é 1F C1 00 B2, porque a encriptação RC4- de F0 06 46 com a chave “ANKS ” dá C1 00 B2.

Os operadores do Win32/Boaxxe.BE controlam apenas o endereço IP “real”, e, portanto, esta técnica permite que os seus nomes de domínio sejam associados a endereços IP “inocentes”.

Fraude iniciada pelo utilizador

Esta fraude refere-se ao desvio de utilizadores quando dão um clique em resultados apresentados pelo motor de busca. Resumidamente, possibilita que o Win32/Boaxxe.BE forneça tráfego de alta qualidade para sites de publicidade, já que redirecciona utilizadores reais – e não robôs – para sites de publicidade relacionadas com o seu interesse (as palavras-chave que são pesquisadas). O funcionamento lógico desta actividade é resumido abaixo. O texto a azul indica as acções do utilizador, e o texto vermelho mostra as acções efectuadas pelo Win32/Boaxxe.BE.

No passo 1, o utilizador procura nos motores de busca por uma determinada palavra-chave K e recebe de volta uma lista de sites relacionados. Ao mesmo tempo, o Win32/Boaxxe.BE envia K para o seu próprio motor de busca, que também revela uma lista de sites relacionados. Importa salientar que no caso de não existirem páginas adequadas para esta palavra-chave em particular, não ocorre qualquer redirecionamento. No passo 2, o utilizador dá um clique num resultado legítimo e volta à página correspondente. Porém, o Boaxxe.BE força o browser a voltar-se a ligar a um dos seus próprios resultados. Na prática, o utilizador não tem tempo para ver a página onde deu um clique, e termina-se directamente na página seleccionada pelo Win32/Boaxxe.BE.

No caso do Chrome e Firefox, a operação iniciada pelo utilizador é implementada nas extensões , como foi anteriormente descrito no processo de instalação, existindo diferenças apenas no caso do Internet Explorer.

Chrome e Firefox

Funcionamento interno

O funcionamento da extensão é semelhante em ambos os browsers, por isso vamos descrever apenas a situação ao nível do Chrome. Lembre-se que a extensão do Chrome é composta por dois ficheiros JavaScript: o script que corre em plano de fundo, a única instância onde será executado permanentemente, e o script de conteúdo, a única instância que terá a duração de cada página.

Aquando da inicialização, o script que corre em plano de fundo desencripta o JSON_PAYLOAD e avalia o campo “c”, que contém a lógica de extensão do núcleo. Este código declara uma variável contendo os motores de busca direccionados. Todos estes motores de busca recebem palavras-chave a partir do utilizador como parâmetros em requisições GET, sendo este o local onde o Win32/Boaxxe.BE os reúne. Para fazê-lo, o código da extensão declara em primeiro lugar o parâmetro da URL que contém a palavra-chave para cada um motor de busca, com as possíveis subpáginas utilizadas nos pedidos de pesquisa. Aqui está a lista dos motores de busca específicos em Dezembro:

Assim, um pedido ao URL “www.google.com/search?q=cat” irá coincidir com a linha 1 da matriz anterior, e a palavra-chave “cat” será extraída do URL e, posteriormente, enviada para o motor de busca do Win32/Boaxxe.BE, que tem sido o searchpagex.com (e searchpagex.org para Firefox) nos últimos meses.

Para além do referido, é declarada uma “lista branca” de sites, nomeadamente Wikipedia , Facebook e Twitter. Deste modo, quando o utilizador dá um clique num destes domínios não será redireccionado. Como é lógico, isto permite que o Win32/Boaxxe.BE seja mais furtivo

Internet Explorer

A fim de implementar esta actividade de fraude no Internet Explorer, o Win32/Boaxxe.BE prende-se à memória utilizando as funções da API do Windows, nomeadamente HttpAddRequestHeadersA , CreateWindowExW e DrawTextExW . Estas ligações comunicam directamente com o código do Boaxxe inserido nos pontos de entrada das funções. A ameaça é implementada numa lógica bastante semelhante à da extensão para o Chrome.

Ele filtra a mesma lista de endereços dos motores de busca para extrair as palavras-chave pesquisadas. A única diferença é que ele não envia essas palavras-chave para o seu próprio motor de busca, mas para um endereço IP malicioso armazenado no cache de DNS personalizado.

Fraude baseada em cliques automáticos

Este tipo de fraude refere-se neste contexto, a navegação silenciosa por sites de publicidade, sem qualquer interação do utilizador. Para fazê-lo, é lançado um processo do Internet Explorer por uma instância do Win32/Boaxxe.BE que se encontra a funcionar em regsvr32.exe .Este novo processo não se encontra visível para o utilizador, graças ao Internet Explorer, tentando ser o mais furtivo possível.

Primeiro, ele modifica várias configurações do Internet Explorer, por exemplo, para desactivar os sons de navegação, ou remover restrições ao download de ficheiros. Para além disso, ele cria também um processo que irá monitorizar continuamente o tempo de execução e a memória usada. Se o tempo for muito longo ou ocupar demasiada memória – ou seja, a máquina estiver sobrecarregada – ele termina a execução . Finalmente, liga-se à função MessageBeep da API para evitar a reprodução de quaisquer sons.

Posteriormente, acrescenta à sua cache DNS um grupo de nomes de domínio encriptado, de acordo com o valor de ID do afiliado. Depois, envia uma solicitação para um deles – com a transformação RC4/base64 habitual – cuja resposta contém as informações necessárias para iniciar a fraude do clique automatizado. Por exemplo :

Os parâmetros importantes são:

A URL geralmente começa uma cadeia de redirecionamentos – normalmente 4 ou 5 – graças ao código de resposta HTTP 302. A última página HTML visitada é então analisada pelo código, para extrair todos os links. Cada uma destas ligações, é então visitada.

Finalmente, depois de cada página visitada o processo faz uma solicitação HTTP GET para um site escolhido a partir de uma pequena lista de sites mais comuns (Google, Facebook, Twitter …).

Neste artigo dividido em duas partes, abordámos uma ameaça complexa denominada Win32/Boaxxe.BE, que tem como principal objectivo levar tráfego a sites de publicidade, utilizando diversas técnicas fraudulentas, e, assim, ganhar dinheiro. No primeiro texto, abordámos o ecossistema em torno desta operação, sendo que neste abordámos os aspectos técnicos.

Em particular descrevemos como o Win32/Boaxxe.BE:

• Efectua a Fraude iniciada por um clique do utilizador, monitorizando as palavras-chave digitadas pelo utilizador em motores de busca redireccionando-o para sites publicitários.
• Efectua a Fraude automatizada sem intervenção do utilizador em que tem a capacidade de navegar silenciosamente pelos sites de publicidade, sem o conhecimento do utilizador.
• Mantém um sistema de cache DNS personalizado, a fim de evitar a detecção, tornando-se mais furtivo.

Perdeu o primeiro artigo? Clique aqui para ler.