O malware Zebrocy não foi de férias

Investigadores da ESET descrevem os últimos componentes adicionados e utilizados numa recente campanha dirigida às embaixadas e ministérios de negócios estrangeiros na Europa e na Ásia.

Aparentemente, o grupo Sednit desenvolveu novos componentes para adicionar à família de malware Zebrocy.

Este grupo, também conhecido como APT28, Fancy Bear, Sofacy ou STRONTIUM, opera pelo menos desde 2004 e tem sido destaque na imprensa internacional nos últimos anos.

No dia 20 de agosto de 2019, o grupo Sednit lançou uma nova campanha dirigida às suas vítimas habituais – embaixadas e ministérios de negócios estrangeiros dos países da Europa Oriental e Ásia Central.

Esta última campanha começou com um e-mail de phishing que continha um anexo malicioso, o qual dá início a uma longa cadeia de downloaders que termina com uma backdoor. Um exemplo desses e-mails foi carregado no VirusTotal a dia 22 de agosto, dois dias depois do envio do e-mail. Uma descrição geral do vetor de ataque foi publicada recentemente no blog Telsy TRT.

No entanto, temos algumas peças adicionais deste quebra-cabeça que podem ser úteis para obter um quadro mais completo desta recente campanha do grupo Sednit.

Como previsto por outros investigadores, o grupo Sednit adicionou uma nova linguagem de desenvolvimento ao seu conjunto de ferramentas, mais especificamente ao seu downloader: a linguagem Nim. No entanto, os seus desenvolvedores também têm estado ocupados a melhorar o seu downloader em Golang, para além de reescrever as suas backdoors de Delphi para Golang.

Um ataque complicado

A Figura 1 mostra as diferentes etapas até que uma vítima seja atacada, desde o e-mail malicioso recebido inicialmente na caixa de entrada até que a backdoor seja implementada nos alvos de ataque considerados “suficientemente interessantes” pelos operadores.

zebrocy
Figura 1. Resumo das etapas do ataque.

Quando uma vítima é alvo de ataque por componentes do Zebrocy, a cadeia de ataque é geralmente bastante ruidosa. Isto porque, neste caso, a vítima tem pelo menos seis componentes maliciosos que foram descartados no computador antes de ser executado o payload final. Tais atividades podem facilmente desencadear diferentes tipos de alerta através de um produto de segurança.

O documento anexo ao e-mail de phishing está em branco, mas faz referência a um documento remoto, wordData.dotm, alojado na Dropbox. Ao abrir este documento no Word, é descarregado o wordData.dotm, como se vê na Figura 2, e incorporado no ambiente de trabalho do documento associado, incluindo qualquer conteúdo ativo que o documento possa conter.

zebrocy
Figura 2. Documento de Word vazio a ser descarregado.

O arquivo wordData.dotm contém macros maliciosas que são executadas. (Dependendo da versão do Microsoft Word, as macros VBA são desativadas por padrão e é necessária uma ação do utilizador para ativá-las). Também contém um arquivo ZIP incorporado que as macros eliminaram e extraíram.

Como se pode ver na Figura 1, as macros no wordData.dotm abrem outro documento (lmss.doc que foi descomprimido do arquivo extraído do wordData.dotm). As macros no lmss.doc executam lmss.exe (o novo downloader do Zebrocy em Nim, também extraído do arquivo embebido no wordData.dotm) em vez de wordData.dotm, executando o downloader diretamente.

No entanto, é importante notar que o lmss.doc, que contém o código VBA que executa o novo downloader em Nim, também incorpora um executável codificado no base64. De acordo com as Propriedades do documento, o lmss.doc foi criado em janeiro de 2019 e modificado a 20 de agosto –  algumas horas antes do início da campanha.

zebrocy
Figura 3. Datas de criação e última modificação do lmss.doc.

O executável embebido no lmss.doc é um downloader em AutoIt (SHA-1: 6b300486d17d07a02365d32b673cd6638bd384f3), o qual foi utilizado numa campanha anterior realizada numa altura próxima à da criação do lmss.doc. Neste caso, o downloader em AutoIt é ignorado e não tem nenhum outro propósito a não ser o de aumentar o tamanho do documento. Provavelmente, o operador esqueceu-se de excluir o downloader previamente embebido (não seria a primeira vez que os operadores Sednit cometem erros).

Os downloaders

Os operadores do Sednit têm usado vários downloaders escritos em diferentes idiomas. Esta campanha utiliza a extensão mais recente desta lista: um downloader escrito na relativamente nova linguagem Nim. Trata-se de um binário simples para descarregar e executar com dois pequenos detalhes adicionados. O primeiro é provavelmente utilizado como um truque anti-sandbox e verifica se a primeira letra do arquivo executado (letra 1 aqui ou 0x6C em hexadecimal) não mudou.

zebrocy
Figura 4. Verificação do nome do arquivo.

O segundo é um tipo de ofuscação onde o operador substitui as letras de marcador de posição numa string com as corretas, nos deslocamentos definidos. Como podemos ver na Figura 5, o downloader reconstrói a string da URL de download correta com este método para evitar ferramentas básicas de análise estática, que poderiam localizar a string da URL.

zebrocy
Figura 5. Saída de Hex-Rays das strings.

Por exemplo, a cadeia o-ps-c..ll está corrigida em três deslocamentos por s,v e d respetivamente, para fornecer ospsvc.dll. No caso da URL, dado que o início da cadeia no downloader é h@@p://, as ferramentas que procuram por http:// não a detetarão.

O downloader em Nim recebe o seu payload da biblioteca de links dinâmicos (DLL), denominada de ospsvc.dll, em C:\ProgramData\Java\Oracle\, e executa-a como um serviço através de regsvr32/s.

ospsvc.dll é um downloader escrito em Golang, e diferente de outros downloaders do grupo Sednit analisados anteriormente.

Os downloaders anteriores Golang do Sednit foram descritos de forma detalhada por outros investigadores [1] [2] [3] e parece que os desenvolvedores do Sednit reescreveram o seu downloader anterior do Delphi em Golang. Os downloaders anteriores coletam muitas informações sobre o computador da vítima e envia-as para o seu servidor de C&C. No entanto, este novo é bastante leve no que respeita a recursos de coleta de dados, como é descrito de seguida.

A sua função main_init()contém bibliotecas que são inicializadas e não necessitam de mais explicações devido aos seus nomes.

zebrocy
Figura 6. Saída Hex-Rays de funções inicializadas em main_init() usando o plugin IDAGolangHelper.

Como a DLL está a ser executada como um serviço, através do downloader em Nim, devemos olhar para main_DllRegisterServer() em vez de main_main(). As strings e a chave são empilhadas e podem ser desencriptadas com um simples loop XOR. Esta simples criptografia é bastante eficiente contra ferramentas que extraem strings empilhadas de binários estáticos.

zebrocy
Figura 7. Saída IDA Pro a partir de strings encriptadas empilhadas.

Para além de descarregar a etapa seguinte do malware, tirar sreenshots do desktop da vítima e executar comandos recebidos do servidor C&C são as principais funções desse malware. Os sreenshots são tirados a cada 35 segundos durante os primeiros minutos da execução deste downloader e enviados para o servidor C&C em formato codificado em base64. O nome do host e os valores de %USERPROFILE% também são enviados para o servidor C&C codificados em base64. A resposta do servidor C&C também é simples: trata-se de uma concatenação de strings codificadas em base64, separadas por “|”.

<spaces>|<cmd to execute>|<name of the binary to drop>|<binary to drop>

De acordo com a nossa telemetria, este downloader foi usado para executar três tipos diferentes de malware. O primeiro é o dumper, enquanto que o segundo é a backdoor usual em Delphi: também executado como um serviço através do mesmo comando usado pelo downloader em Nim. O terceiro que vimos é uma nova backdoor descarregada e executada no computador da vítima, conforme descrito na próxima seção.

A nova backdoor

Análises

A nova backdoor do Zebrocy não está escrita em Delphi como é costume, mas em Golang. Tanto quanto sabemos, esta é a primeira vez que esta backdoor foi vista, mas partilha muitas semelhanças com a escrito em Delphi.

Olhando novamente para o código main_init()da função de inicialização da biblioteca (Figura 8), podemos ver novas entradas. Um algoritmo AES, codificação hexadecimal e recursos de sreenshots são as principais entradas que foram adicionadas.

Figura 8. Diferença entre a backdoor e as funções do downloader inicializadas em main_init().

Observe que image_png_init substitui image_jpeg_init para fazer sreenshots. As imagens no formato JPG são geralmente mais pequenas que as de formato PNG.

A backdoor começa com um argumento que é uma string codificada em hexadecimal. Tudo, à exceção do último fragmento de seis bytes da string, são encriptados com XOR com a chave armazenada nos últimos seis bytes da string. O fragmento seguinte em Python descreve a lógica de descodificação.

É o endereço do servidor C&C, que é então encriptado e armazenado no disco. Esta encriptação é feita utilizando o algoritmo AES-128 ECB com uma chave gerada a partir do nome de host. Portanto, não há nenhuma forma de obter este servidor C&C observando simplesmente para o binário. Não há persistência definida nos downloaders, como vimos anteriormente, nem a backdoor apresenta um mecanismo de persistência.

Esta nova backdoor possui várias capacidades que também foram vistoas anteriormente naa backdoor em Delphi do Zebrocy:

  • manipulação de arquivos como criação, modificação e eliminação
  • recursos de sreenshots
  • enumeração de unidades
  • execução de comandos (através de cmd.exe )
  • programar una tarefa com o seguinte nome Windows\Software\OSDebug (que os operadores poderiam usar para estabelecer a persistência manualmente).

À semelhança da backdoor em Delphi, há um conjunto muito limitado de comandos, mas a capacidade de executar comandos arbitrários através do cmd.exe expande possibilidades como persistência ou recolha de informações. Outra semelhança encontrada é um número de versão de três dígitos (no formato xyz), enquanto que a versão principal atual é 4.yz

Rede

O protocolo de rede partilha algumas semelhanças com a versão Delphi da backdoor. A primeira interação com o servidor C&C recupera uma chave AES de 32 bits para encriptar futuras comunicações. A captura de pacotes dessa primeira solicitação parece-se com:

POST [REDACTED URI] HTTP/1.1
Host: [REDACTED IP]
User-Agent: Go-http-client/1.1
Content-Length: 297
Content‑Type: multipart/form‑data; boundary=b116f1e0a94eff1bb406531e74bb0feba65687cf90ec8a64fc409f230fbd
Accept-Encoding: gzip

–b116f1e0a94eff1bb406531e74bb0feba65687cf90ec8a64fc409f230fbd
Content-Disposition: form-data; name=”filename”; filename=”[REDACTED]”
Content-Type: application/octet-stream

1
–b116f1e0a94eff1bb406531e74bb0feba65687cf90ec8a64fc409f230fbd–

Aqueles com mais experiência no Sednit podem pensar que Content-Disposition e a palavra-chave boundary parecem familiares. Pois foram utilizados pela backdoor em Delphi no seu protocolo de rede. Utiliza ainda o algoritmo AES para encriptar o pseudo corpo (conteúdo depois dos dados Content-Type). Observe que, mesmo que o Content-Disposition e a segunda instância do Content-Type sejam cabeçalhos HTTP reais, eles são usados ​​aqui dentro do corpo da mensagem HTTP. O campo boundary é aleatório para cada troca e o campo filename do suposto cabeçalho Content‑Disposition pode ser descodificado com o seguinte fragmento de Python:

que resulta na seguinte string:

757365722D504318162020190821151055207C.inc

Esta string compreende-se melhor assim:

Username: 757365722D5043
SID*: 181620
Date: 20190821151055
Random: 207C.inc

* 6 bytes vêm dos identificadores de segurança (SIDs) do utilizador atual

S-1-5-21‑xxxxxxxxx‑yyyyyyyyyy‑zzzzzzzzzz‑1000

Outras interações com o servidor C&C seguem este padrão, exceto que o suposto corpo, que é 1 no exemplo anterior, seja substituído pela saída do comando solicitado pelo servidor C&C. O corpo inteiro da mensagem também é encriptado, usando o mesmo algoritmo AES usado anteriormente, com a chave fornecida na primeira troca.

Conclusão

Novos downloaders, nova backdoor: o grupo Sednit tem estado ativo e não permite que os seus componentes se tornem demasiado antigos. Novo? Realmente não. Olhando para ele, parece que o grupo Sednit está a transferir o código original para outros idiomas ou reimplementá-lo na esperança de evitar a deteção. Talvez assim seja mais fácil e assim não precisam mudar os seus TTPs completamente. O vetor de ataque inicial permanece inalterado, mas usar um serviço como o Dropbox para fazer o download de um documento remoto é algo incomum para o grupo.

Indicadores de Compromisso (IoCs)

zebrocyRede

https://www.dropbox[.]com/s/foughx315flj51u/wordData.dotm?dl=1

185.221.202[.]35

Técnicas de MITRE ATT&CK

Referências:

[1] https://unit42.paloaltonetworks.com/sofacy-creates-new-go-variant-of-zebrocy-tool/
[2] https://securelist.com/a-zebrocy-go-downloader/89419/
[3] https://www.vkremez.com/2018/12/lets-learn-dissecting-apt28sofacy.html

DEIXE UMA RESPOSTA

Please enter your comment!
Please enter your name here

*