Análise do backdoor do TeleBots escondido em uma atualização de software

No dia 27 de junho de 2017, um novo ataque afetou muitos sistemas computacionais na Ucrânia e em outros países, incluindo o Brasil. Esse ataque foi liderado pelo malware que os produtos da ESET detectam como Diskcoder.C (também conhecido como ExPetr, PetrWrap, Petya ou NotPetya). Essa ameaça se passa por um típico ransomware: encripta os arquivos e exige 300 dólares como resgate. No entanto, a intenção dos autores era causar prejuízos e corromper a informação mais do que obter o dinheiro, por isso, fizerem tudo o que podiam para tornar a descriptografia dos arquivos muito improvável.

Em nosso post anterior, atribuímos esse ataque ao grupo TeleBots e revelamos detalhes sobre outros ataques semelhantes que afetaram a processos de produção na Ucrânia. Hoje revelamos mais informações sobre o vetor de distribuição inicial que foi usado durante o surto do DiskCoder.C.

A história de uma atualização maliciosa

O departamento de polícia cibernética da Polícia Nacional da Ucrânia afirmou na sua conta do Facebook, assim como a ESET e outras empresas de segurança da informação, que o M.E.Doc, software ucraniano legítimo de contabilidade, foi usado pelos atacantes para propagar o malware DiskCoder.C na fase inicial do ataque. No entanto, até agora, não foram fornecidos detalhes sobre como isso foi realizado.

Durante a nossa pesquisa, identificamos um backdoor muito sigiloso e bem desenvolvido, que foi injetado pelos atacantes em um dos módulos legítimos do M.E.Doc. Parece muito improvável que os cibercriminosos possam ter feito isso sem ter o acesso ao código fonte do software.

O módulo com o backdoor infiltrado tem o nome do arquivo ZvitPublishedObjects.dll. Foi escrito usando o framework .NET e possuiam 5MB com uma grande quantidade de código legítimo, que pode ser chamado por outros componentes, incluindo o executável principal M.E.Doc ezvit.exe.

Examinamos todas as atualizações do M.E.Doc que foram publicadas em 2017 e descobrimos que existem pelo menos três que continham o módulo alterado para incluir o backdoor:

175-10.01.176, liberada em 14 de abril de 2017
180-10.01.181, liberada em 15 de mayo de 2017
188-10.01.189, liberada em 22 de junio de 2017

O incidente com o ransomware XData (Win32/Filecoder.AESNI.C) ocorreu três dias após a atualização 10.01.180-10.01.181 e o surto do DiskCoder.C aconteceu cinco dias após a atualização 10.01.188-10.01.189. Curiosamente, quatro atualizações entre 24 de abril de 2017 e 10 de maio de 2017, assim como sete atualizações entre 17 de maio de 2017 e 21 de junho de 2017, que não continham o módulo com o backdoor.

Uma vez que a atualização ocorrida em 15 de maio continha o módulo e a do dia 17 de maio não, temos uma hipótese que pode explicar a baixa relação da infecção do Win32/Filecoder.AESNI.C: o lançamento da atualização do dia 17 de maio foi um evento inesperado para os atacantes. Eles propagaram o ransomware em 18 de maio, mas a maioria dos usuários do M.E.Doc já não tinham o módulo com o backdoor porque o haviam atualizado.

Os dados de compilação dos arquivos PE analisados sugerem que esses arquivos foram compilados na mesma data que a atualização do dia anterior:

Imagem 1 – Marca de tempo da compilação do módulo com o backdoor na atualização de 15 de maio.

A imagem 2 mostra a diferença entre a lista de classes da versão com e sem o backdoor do módulo, usando um Decompiler .NET ILSpy:

Imagem 2 - Lista de classes no módulo backdoor (à esquerda) e sem backdoor (à direita).

A classe de backdoor principal é chamada de MeCom e está localizada no espaço de nome ZvitPublishedObjects.Server, assim como é possível ver na imagem 2.

Imagem 3 - Classe MeCom com código malicioso, conforme mostrado no Decompiler .NET ILSpy.

Os métodos da classe MeCom são invocados pelo método IsNewUpdate do UpdaterUtils no ZvitPublishedObjects.Server. O método IsNewUpdate é invocado periodicamente para verificar se uma nova atualização está disponível. O módulo com o backdoor de 15 de maio é implementado de forma ligeiramente diferente e tem menos recursos do que o do dia 22 de junho.

O Registro Estatal Unificado de Empresas e Organizações da Ucrânia identifica entidades que funcionam no país através do número EDRPOU. Isso é extremamente importante para os atacantes: com o número EDRPOU, os cibercriminosos podem identificar exatamente a organização que agora está usando o M.E.Doc, que contém o backdoor. Uma vez identificada, podem então usar várias táticas contra a rede informática da organização, dependendo do alvo que persigam.

Condiderando que o M.E.Doc é um software de contabilidade comumente usado na Ucrânia, os valores do EDRPOU podem ser encontrados nos dados do aplicativo das máquinas que o utilizam. Assim, o código que foi injetado no método IsNewUpdate coleta todos os valores EDRPOU dos dados do aplicativo: uma instância M.E.Doc pode ser usada para executar operações contábeis para várias organizações, de modo que o código que contém o backdoor coleta todos os números EDRPOU possíveis.

Imagem 4 - Código que coleta números EDRPOU.

Além dos números EDRPOU, o backdoor coleta configurações de proxy e email, incluindo nomes de usuário e senhas, do aplicativo M.E.Doc.

Atenção: recomendamos que sejam alteradas as senhas de proxies e contas de email de todos os usuários do software M.E.Doc.

O código malicioso escreve as informações reunidas no registro do Windows sob a chave HKEY_CURRENT_USER\SOFTWARE\WC usando valores de nomes Cred e Prx. Então, se esses valores existem em um computador, é altamente provável que o módulo que contém o backdoor tenha sido executado nele.

E aqui está a parte mais astuta: o módulo com o backdoor não usa servidores externos como C&Cs, mas usa pedidos regulares de verificação de atualização do software M.E.Doc, feitos para o seu servidor oficial, upd.me-doc.com[.]ua. A única diferença com um pedido legítimo é que o código com o backdoor envia as informações coletadas nas cookies.

Imagem 5 - Pedido HTTP do módulo com o backdoor que contém o número EDRPOU nas cookies.

Não realizamos análises forenses no servidor M.E.Doc. No entanto, como observamos em nosso post anterior, há sinais de que foi comprometido. Por isso, podemos especular que os atacantes implantaram um software para o servidor que permite diferenciar entre pedidos de máquinas comprometidas ou não.

Imagem 6 - Código do backdoor que adiciona cookies ao pedido.

E, claro, os atacantes adicionaram a capacidade de controlar a máquina infectada. O código recebe um objeto binário grande (blob), o descriptografa usando o algoritmo Triple DES e, em seguida, o descompacta usando o GZip. O resultado é um arquivo XML que pode conter vários comandos ao mesmo tempo. Essa funcionalidade de controle remoto torna o backdoor uma plataforma de ciberespionagem e de cibersabotagem com amplas habilidades.

Imagem 7 - Código do backdoor que desencripta os comandos recebidos do operador do malware.

A tabela a seguir mostra possíveis comandos:

Comando	Propósito
0 – RunCmd	Executa o comando do shell fornecido
1 – DumpData	Decodifica os dados fornecidos pela Base64, e os guarda em um arquivo
2 – MinInfo	Coleta informações sobre a versão do SO, bits (32 ou 64), privilégios, configurações UAC, configurações de proxy, configurações de email, incluindo usuário e senha
3 – GetFile	Recolhe o arquivo do computador infectado
4 – Payload	Decodifica os dados fornecidos pela Base64, os guarda em um arquivo o executa
5 – AutoPayload	Da mesma forma que o anterior, no entanto, o arquivo fornecido deve ser um DLL e se executará na pasta do Windows utilizando rundll32.exe. Além disso, tenta sobrescrever o DLL e o apaga.

Note-se que o comando número 5, nomeado pelos autores do malware como AutoPayload, encaixa perfeitamente com a forma na qual o DiskCoder.C foi inicialmente executado nas máquinas do "paciente zero".

Imagem 8 - Método AutoPayload que foi usado para executar o malware DiskCoder.C.

Conclusões

Como mostra nossa análise, essa é uma operação altamente planejada e executada com precisão. Assumimos que os atacantes tiveram acesso ao código fonte do aplicativo M.E.Doc. Eles tiveram tempo de conhecer o código e incorporar um backdoor muito sigiloso e astuto. O tamanho da instalação completa do M.E.Doc é de aproximadamente 1,5 GB, e neste momento não temos uma forma de verificar se não há outras backdoors injetados.

Ainda existem perguntas para responder. Há quanto tempo esse backdoor está sendo usado? Quais comandos e malwares diferentes do DiskCoder.C ou Win32/Filecoder.AESNI.C foram propagados através desse canal? Quais outras atualizações de software podem ter sido comprometidas por esse grupo para usá-las como armas?