Mudanças no malware Zebrocy detectadas na última campanha do grupo Sednit

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

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

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

Essa última campanha começou com um e-mail de phishing contendo um anexo malicioso, que inicia uma longa cadeia de downloaders que termina com um backdoor. Um exemplo desses e-mails foi carregado no VirusTotal em 22 de agosto, dois dias depois que o e-mail foi enviado. Uma descrição geral do vector de ataque foi recentemente publicada pelo 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 pesquisadores, o grupo Sednit adicionou uma nova linguagem de desenvolvimento ao seu kit de ferramentas, mais especificamente ao seu downloader: a linguagem Nim. No entanto, seus desenvolvedores também estão melhorando seu downloader em Golang, bem como reescrevendo seu backdoor de Delphi para Golang.

Um ataque complicado

A Figura 1 mostra as diferentes etapas que levam a uma vítima a ser atacada, desde o e-mail malicioso inicialmente recebido na caixa de entrada até o backdoor sendo implantado em alvos de ataque considerados "suficientemente interessantes" pelos operadores.

Figura 1: Resumo da cadeia de ataque.

Quando uma vítima é atacada por componentes do Zebrocy, a cadeia de ataque é normalmente bastante barulhenta. Isso porque, neste caso, a vítima tem pelo menos seis componentes maliciosos que foram droppeados no computador antes que o payload final seja executado. Essas atividades podem facilmente desencadear diferentes tipos de alertas através de um produto de segurança.

O documento anexado ao e-mail de phishing está em branco, mas faz referência a uma planilha remota, wordData.dotm, hospedada no Dropbox. Quando você abre este documento no Word, o wordData.dotm é baixado, como se pode ver na Figura 2, e o incorpora ao ambiente de trabalho do documento associado, incluindo qualquer conteúdo ativo que a planilha possa conter.

Figura 2: Documento do Word vazio descarregando uma planilha remota.

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

Como podemos ver na Figura 1, macros em wordData.dotm abrem outro documento (lmss.doc que foi descompactado do arquivo extraído do wordData.dotm). Macros em lmss.doc executam lmss.exe (o novo downloader do Zebrocy em Nim, também extraído do arquivo embebido em wordData.dotm) ao invés de wordData.dotm, executando o downloader diretamente.

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

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), que foi usado em uma campanha anterior que foi realizada em um tempo próximo à criação do lmss.doc. Neste caso, o downloader em AutoIt é ignorado e não tem outra finalidade senão aumentar o tamanho do documento. O operador provavelmente esqueceu de excluir o downloader embebido anteriormente (esta 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 usa a extensão mais recente dessa lista: um downloader escrito na linguagem Nim relativamente nova. É um binário simples para baixar e rodar com dois pequenos detalhes adicionados. O primeiro é provavelmente usado como um truque anti-sandbox e verifica se a primeira letra do arquivo executado (letra 1 aqui ou 0x6C em hexadecimal) não mudou.

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

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

Figura 5: Saída de Hex-Rays das strings de desofuscação.

Por exemplo, a cadeia o-ps-c...ll está "parcheada" em três deslocamentos por s,v e d respectivamente, para fornecer ospsvc.dll. No caso da URL, consiferando que o início da cadeia no downloader é h@p://, as ferramentas procurando por http:// não irão detectá-la.

O downloader em Nim recebe seu payload da biblioteca de links dinâmicos (DLL), chamada ospsvc.dll, em C:\ProgramData\Java\Oracle\, e executa-o 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 downloads anteriores Golang em do Sednit foram descritos com detalhes por outros pesquisadores [1] [2] [3] e parece que os desenvolvedores do Sednit reescreveram seu downloader anterior do Delphi em Golang. Os downloads anteriores recoletam muitas informações sobre o computador da vítima e as envia para o seu servidor C&C. No entanto, este novo é bastante leve em termos de suas capacidades de coleta de dados, conforme descrito abaixo.

Sua função main_init() contém bibliotecas que são inicializadas e não precisam de mais explicações devido a seus nomes (veja este artigo para mais informações).

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

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

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

Além de baixar o próximo estágio do malware, tirar screenshots do desktop da vítima e executar comandos recebidos do servidor C&C são as principais funções desse malware.

Os screenshots são tirados a cada 35 segundos durante os primeiros minutos da execução deste downloader, e depois 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 codificado em base64. A resposta do servidor C&C também é simples: é 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 que descrevemos em uma publicação sobre o Zebrocy. O segundo é o backdoor usual em Delphi: ele também roda como um serviço através do mesmo comando usado pelo downloader em Nim. O terceiro que vimos é um novo backdoor baixado e executado na máquina da vítima, como descrito na próxima seção.

O novo backdoor

Análises

O novo backdoor do Zebrocy não está escrito em Delphi como estamos acostumados, mas em Golang. Tanto quanto sabemos, esta é a primeira vez que este backdoor foi visto, mas ele compartilha muitas semelhanças com o escrito em Delphi.

Ao olharmos 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 capacidades de screenshots são as principais entradas que foram adicionadas.

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

Note que image_png_init substitui image_jpeg_init para tirar screenshots. As imagens no formato JPG são geralmente menores do que no formato PNG.

O backdoor começa com um argumento que é uma string codificada hexadecimal. Tudo menos o último fragmento de seis bytes da string é criptografado com XOR com a chave armazenada nos últimos seis bytes da string. O seguinte fragmento em Python descreve a lógica de decodificação.

key = arg[-6:].decode('hex')
enc = arg[:-6].decode('hex')
''.join(chr(ord(i) ^ ord(j)) for i, j in zip(itertools.cycle(key), enc))

Este é 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 maneira de obter este servidor C&C apenas olhando para o binário. Não há persistência definida nos downloaders, como vimos anteriormente, nem o backdoor tem um mecanismo de persistência.

Este novo backdoor tem várias capacidades que também foram vistas anteriormente no backdoor em Delphi do Zebrocy:

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

Como no 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 coleta de informações. Outra similaridade encontrada é um número de versão de três dígitos (no formato xyz); a versão principal atual é 4.yz

Rede

O protocolo de rede compartilha algumas semelhanças com a versão Delphi do backdoor. A primeira interação com o servidor C&C recupera uma chave AES de 32 bits para criptografar futuras comunicações. A captura de pacotes desse primeiro pedido tem este aspecto:

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 experiência com o Sednit podem pensar que Content-Disposition e a palavra-chave boundary parecem familiares. Eles foram usados anteriormente pelo backdoor em Delphi em seu protocolo de rede - também usa o algoritmo AES para criptografar o pseudo corpo (conteúdo após os dados Content-Type). Note que mesmo que 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 intercâmbio e o campo filename dentro do pseudo-cabeçalho Content Disposition pode ser desencriptado com o seguinte fragmento de Python:

len_filename = len(filename)
len_key = 14
xor_key = filename[-len_key:].decode('hex')
filename = filename[:len_filename-len_key].decode('hex')
val_filename = ''.join(chr(ord(i)^ord(j)) for i,j in zip(itertools.cycle(xor_key),filename))
random_int = val_filename[-4:]

que resulta na seguinte string:

757365722D504318162020190821151055207C.inc

Essa string pode ser melhor compreendida dessa forma:

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

*6 bytes vêm dos identificadores de segurança (SIDs) do usuário atual S-1-5-21‑xxxxxxxxx‑yyyyyyyyyy‑zzzzzzzzzz‑1000

Outras interações com o servidor C&C seguem este padrão, exceto que o pseudo 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 é criptografado, usando o mesmo algoritmo AES usado anteriormente, com a chave fornecida na primeira troca.

Conclusão

Novos downloaders, novo 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á transferindo o código original para outros idiomas ou reimplementando-o na esperança de evitar a detecção. Provavelmente seja mais fácil dessa forma e eles não precisam mudar seus TTPs completamente. O vetor de ataque inicial permanece inalterado, mas usar um serviço como o Dropbox para baixar uma planilha remota é incomum para o grupo.

A ESET recomenda que você esteja atento na hora de abrir anexos suspeitos de e-mail.

Continuaremos monitorando as novas atividades do grupo Sednit e publicaremos informações relevantes no WeLiveSecurity. Caso tenha alguma dúvida, entre em contato conosco pelo e-mail threatintel@eset.com.

Indicadores de Comprometimento (IoCs)

Rede

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