Malware dirigidos contra bancos poloneses e instituições na América Latina

Recentemente surgiram notícias sobre ataques aos bancos poloneses no site de segurança da Polônia ZaufanaTrzeciaStrona.pl (traduzido aqui em inglês). O impacto dos ataques foi descrito dramaticamente com adjetivos como “o mais sério”, e os relatórios iniciais foram apoiados por dois textos da Symantec e da BAE Systems. As instituições afetadas são de diversas nacionalidades, em todo o mundo, e se estendem até a América Latina, incluindo o México e o Uruguai, com alvos de alto perfil no visor dos atacantes.

Existem muitos aspectos interessantes nesses ataques, começando por seus alvos, passando por seus vetores de comprometimento, até as funcionalidades específicas dos executáveis maliciosos que foram usados. Apesar dos dois primeiros aspectos terem sido minuciosamente examinados, os binários maliciosos envolvidos não receberam muita atenção até o momento. O propósito deste texto é fornecer detalhes técnicos desse malware até então minimamente documentado.

Canal de distribuição

Como mencionado no portal de notícias da Polônia, a ameaça é enviada de forma sigilosa através de um ataque conhecido como watering hole, no qual, por meio de um site confiável que foi comprometido, que redireciona os visitantes para uma outra página maliciosa e que contém um exploit. No caso dos ataques poloneses, o ponto de partida foi o site oficial da Komisja Nadzoru Finansowego (Autoridade de Supervisão Financeira da Polônia):

No entanto, nossos dados indicam que o site da autoridade equivalente no México, a Comissão Nacional Bancária e de Valores, também serviu redirecionamentos maliciosos idênticos; infelizmente, a informação divulgada pelos serviços de rastreamento web ou pela própria instituição ainda não foram confirmados, nem mencionados. Segundo os nossos dados, os redirecionamentos foram a partir dessa página do site:

Etapa 1: Dropper

Se o exploit kit consegue realizar a entrega do malware com êxito, o payload malicioso (uma aplicação console de 64 bits) é executado no computador da vítima. Ao contrário do dropper relatado pela BAE Systems, esse programa espera um dos três argumentos: -l, -e, o -a (seção 2 na seguinte figura). Enquanto que o parâmetro -l tem o mesmo significado, os dois restantes são necessários para extrair binários da próxima etapa (seção 4 na figura) e para iniciar automaticamente (autoiniciar) um deles como serviço (seção 5):

Na seção 5 da figura acima, o dropper tenta alterar a configuração de um serviço do sistema para tornar o carregamento do dropper como um serviço. O serviço é configurado para iniciar automaticamente pelo gerenciador de controle de serviços durante a inicialização do sistema e para isso, é necessário privilégio de administrador.

Ao contrário das etapas subsequentes, a ameaça não se esconde muito cuidadosamente durante a primeira etapa. Inclusive contém declarações detalhadas que fornecem informação sobre o status da execução (nesse caso, relacionadas com a extração de recursos criptografados; no entanto, a informação de debug como os nomes originais de funções não estão presente).

O dropper utiliza o carregamento de API dinâmica ao invés de ter funções do Windows em sua tabela de importação, o qual está muito bem explicado no relatório Novetta “Operation Blockbuster” no Lazarus Group, página 34. A seção 3 da figura acima mostra um wrapper dessa funcionalidade, que vai de uma biblioteca de sistema a outra, de forma consecutiva.

Parece que os atacantes definem a segunda etapa como “loader” e a terceira, que contém a principal funcionalidade do malware, como “módulo”. O loader é descriptografado, enquanto o módulo apenas é extraído e executado da forma como está. Para reduzir sua visibilidade durante a análise forense, os arquivos tomam emprestados seu tempo de criação do shlwapi.dll, uma biblioteca do sistema. Uma característica importante do algoritmo de encriptação utilizado é que se trata de uma cifra de fluxo semelhante ao RC4 bastante recente chamada Spritz. Já estão disponíveis implementações do Spritz em C e Python, e correspondem ao seguinte código desmontado do dropper:

Etapa 2: Loader

Há mais indicadores com a intenção de preservar o baixo perfil da ameaça. O loader é protegido por um packer comercial chamado Enigma Protetor e pudemos notar que o módulo é armazenado de forma criptografada, aguardando que o loader o descriptografe e o libere. Após examinar mais atentamente essa proteção, descobrimos foi usada uma cópia não registrada do Enigma v. 1.31 para 64 bits. Como já esperávamos, criadores de malware com esse nível de sofisticação não cometeriam um erro tão básico como revelar sua identidade usando uma cópia devidamente registrada. No entanto, não é incomum que criminosos se aproveitem de uma cópia vazada do aplicativo ou pirateada se ela encontra-se disponível.

Os atacantes que pretendem construir uma grande botnet, em geral, não usam packers comerciais, pois uma boa proteção de fabricantes anti-malware os detectam de forma genérica. Portanto, eles restringem o tamanho potencial da botnet. No entanto, no caso de um ataque dirigido, usar tal proteção tem suas vantagens. Uma delas é que a reconstrução do binário original, ou seja, determinar como era antes de entrar no processo de camuflagem, quase nunca é fácil.

A impressão, por vezes, de que apenas máquinas com Windows de 64 bits podem ser alvo dessa ameaça está errada, pois também foi extraída de uma variante para 32 bits em computadores de algumas instituições afetadas. Embora tenha a mesma estrutura geral, essa última não é uma mera recopilação da primeira, mas que possui ligeiras diferenças: as etapas do dropper e loader são combinadas em uma só, usam a clássica cifra RC4 e não Spritz, e a etapa do módulo é armazenada no registro ao invés de utilizar o sistema de arquivos. Além disso, a versão do protetor Enigma aplicado é a 3.7, com uma licença para um desenvolvedor, e aparentemente foi usado para proteger o binário no dia 11 de janeiro de 2017.

Etapa 3: Módulo

A terceira e última etapa é o módulo relativamente grande (~730 KB) que contém as principais características do malware: para se comunicar com o C&C e receber ordens de operadores. Além disso, o módulo injeta-se em todas as seções iniciadas no sistema Windows comprometido.

A seguinte captura de tela mostra a situação depois após o carregamento do módulo na ferramenta de desmontagem IDA Pro. A barra superior mostra várias partes do binário: seções de código em azul, e seções de dados em cinza e amarelo. A diferença entre as partes azuis e celestes é que estas últimas representam o código estaticamente vinculado as bibliotecas existentes. Além do runtime habitual do C, identificamos a linkagem de uma biblioteca de multiprotocolo para transferência de arquivos (de código aberto) chamada libcurl (versão 7.47.1, lançada em 8 de fevereiro de 2016), juntamente com fragmentos de código de projetos como OpenSSL e XUnzip. O efeito de cor na barra não é gerado automaticamente: nesse caso, tivemos que marcar explicitamente as partes que consideramos como código de biblioteca vinculado e importamos todos os nomes das funções. As seções em azul mais escuro representam o código escrito pelos atacantes.

Existe apenas uma URL criptografada no módulo. A comunicação é criptografada, mas não registramos nenhuma, pois o servidor remoto não estava respondendo no momento da análise. O módulo suporta diversos comandos, mais do que suficientes do tipo para caracterizá-lo nitidamente como um Remote Acces Trojan (RAT). O dicionário de comandos é o seguinte: “SLEP”, “HIBN”, “DRIV”, “DIR”, “DIRP”, “CHDR”, “RUN”, “RUNX”, “DEL”, “WIPE”, “MOVE”, “FTIM”, “NEWF”, “DOWN”, “ZDWN”, “UPLD”, “PVEW”, “PKIL”, “CMDL”, “DIE”, “GCFG”, “SCFG”, “TCON”, “PEEX”, “PEIN”. Muitos se explicam por si só (“SLEP” é semelhante ao inglês “sleep” de “dormir”, “PKIL” é matar um processo, “UPLD” é exfiltrar informação, “DOWN” é descarregar, “DEL” é apagar um arquivo, etc.).

Ferramentas do tipo Lazarus

Os investigadores da BAE Systems se referem ao dropper de 32 bits protegido por Enigma como: “Uma vez descompactado, executa uma variante de malware conhecida, que foi vista como parte do kit de ferramentas do grupo Lazarus…”. Além disso, a Symantec afirma: “Algumas cadeias de código vistas no malware utilizado compartilham aspectos comuns com o código do malware usado pelo grupo de ameaças conhecido como Lazarus”. Também é possível encontrar uma conexão no relatório Novetta, como a mencionada carga dinâmica do API. Todas esses sinais nos motivam a descrever as propriedades cruciais e reais de um kit de ferramentas semelhante a Lazarus:

Malware de múltiplas etapas que se executa em cascata.
A etapa inicial é um aplicativo de console que espera pelo menos um parâmetro.
WINAPIs são carregadas de forma dinâmica.
Usa RC4 ou semelhante com uma chave longa para desencriptação da próxima etapa.
As etapas seguintes são bibliotecas linkadas dinamicamente que se carregam como serviço e tipo de inicialização SERVICE_AUTO_START (solicita privilégios de administrador para essa ação).

Nossos dados mostram a atividade de vários malware tipo Lazarus in-the-wild recentemente. No entanto, para proporcionar um panorama mais claro sobre todo o caso, precisamos de tempo para colher mais informações relevantes.

Estranha descoberta

Durante nossa investigação, encontramos outra amostra interessante que pertence à mesma família de malware. Um aplicativo de console esperando quatro parâmetros chamados fdsvc.exe (2), que executa em cascata (1). Além disso, desencripta a próxima etapa usando RC4 com uma chave de 32 bytes (4), mas não tem as duas últimas propriedades. Por outro lado, injeta o payload em todas as seções em curso do Windows, sendo que o payload tem libcurl v. 7.49.1 linkado de forma estática. O que torna essa amostra especialmente interessante é a forma com a qual a etapa final analisa comandos de operadores, usando o idioma russo apresentados em um translit, que é um método de codificação do alfabeto cirílico com letras do latim.

No entanto, devemos ser cuidadosos com a atribuição. O idioma usado pode ser uma pista falsa, principalmente porque os criadores do malware usualmente implementam comandos através de números ou atalhos em inglês. Ter um comando de doze letras é algo pouco prático.

Conclusão

Considerando os artefatos no código, nós nos arriscamos a dizer que isso não é uma reutilização de código existente muito antes desses recentes ataques a bancos poloneses, nem um projeto esquecido e descontinuado. Além disso, observamos ocorrências de malware que se assemelham a esse exemplo nas últimas semanas.

Os atacantes por trás da ameaça sabem muito bem o que estão fazendo, por isso, as equipes de resposta a incidentes em instituições financeiras e outras organizações de alto padrão provavelmente não terão sonos tranquilos em um futuro próximo. Na verdade, esse é o trabalho dessas equipes nos dias de hoje: padecer de noites não dormidas!