No dia 27 de junho de 2017, um novo ataque atingiu muitos sistemas informáticos na Ucrânia, bem como noutros países. Esse ataque foi liderado pelos componentes de malware que a ESET detecta como Diskcoder.C (também conhecido como ExPetr, PetrWrap, Petya ou NotPetya). Embora este malware agisse como uma forma típica de ransomware: encripta os dados no computador e exige bitcoins no valor de 300 dólares para recuperação, a verdadeira intenção dos autores de malware era causar danos e por esse motivo a desencriptação era pouco provável.

No artigo que publicámos na sexta-feira, atribuímos este ataque ao grupo TeleBots e descobrimos alguns detalhes acerca de outros ataques semelhantes que ocorreram na Ucrânia. Este artigo vai revelar alguns detalhes acerca do vetor de distribuição inicial que foi utilizado durante o surto do DiskCoder.C.

A estória de uma atualização maliciosa

O Departamento de Segurança Informática da Polícia Nacional Ucraniana declarou, na sua conta do Facebook, assim como a ESET e outras empresas de segurança, que o software legítimo de contabilidade ucraniano M.E.Doc foi utlizado pelos atacantes para empurrarem o malware DiskCoder.C na fase inicial do ataque. No entanto, até agora, não tinham sido fornecidos quaisquer detalhes acerca de como o processo ocorreu.

Durante a nossa investigação, identificámos uma backdoor muito furtiva e inteligente que foi injetada pelos atacantes num dos módulos legítimos de M.E.Doc. Importa salientar que parece muito improvável que os atacantes consigam fazer isto sem terem acesso ao código fonte do M.E.Doc.

O módulo comprometido tinha o nome de ficheiro ZvitPublishedObjects.dll e foi escrito utilizando o .NET Framework. É um ficheiro de 5MB que continha muitas linhas de código legítimo que podiam ser chamadas por outros componentes, incluindo o executável EZVIT.exe do M.E.Doc.

Examinámos todas as atualizações de M.E.Doc que foram lançadas em 2017 e descobrimos que existem pelo menos três que continham o módulo backdoored:

01.175-10.01.176, lançada em 14 de abril de 2017
01.180-10.01.181, lançada em 15 de maio de 2017
01.188-10.01.189, lançada em 22 de junho de 2017

O incidente com o Win32 / Filecoder.AESNI.C surgiu três dias após a atualização 10.01.180-10.01.181, sendo que o surto DiskCoder.C aconteceu cinco dias após a atualização 10.01.188-10.01.189. Curiosamente, as quatro atualizações de 24 de abril de 2017 até ao dia 10 de maio de 2017 e sete atualizações de software de 17 de maio de 2017 a 21 de junho de 2017, não continham o módulo modificado com a backdoor.

O facto da atualização de 15 de maio conter o módulo comprometido e a atualização de 17 de maio não, pode explicar a baixa taxa de infecção do Win32 / Filecoder.AESNI.C: o lançamento da atualização de 17 de maio foi um evento inesperado para o Atacantes. Eles empurraram o Ransomware a 18 de maio, mas a maioria dos utilizadores do M.E.Doc já não tinham o módulo comprometido por terem feito a atualização.

O timestamp referente à complicação PE dos ficheiros analisados sugere que foram compilados na mesma data da atualização, ou no dia anterior.

A Figura 2 revela a diferença entre a lista de classes da versão comprometida e não comprometida do módulo, usando o ILSpy .NET Decompiler:

A classe da backdoor principal tem o nome MeCom e está localizada no  ZvitPublishedObjects.Server como mostrado na Figura 2.

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

A organização que faz negócios na Ucrânia tem um identificador de entidade legal único, chamado número EDRPOU (Код ЄДРПОУ). Isto é extremamente importante para os atacantes: com o número EDRPOU, eles podem identificar a organização exata que está a utilizar a versão comprometida do M.E.Doc. Uma vez identificada a organização, os atacantes podem então usar várias táticas contra a rede informática da organização, dependendo do (s) objetivo (s) dos atacantes.

Uma vez que o M.E.Doc consiste num software de contabilidade muito utilizado na Ucrânia, os valores do EDRPOU podem ser encontrados nos dados da aplicação que estão presentes nas máquinas que utilizam este software. Deste modo, o código que foi injetado no método IsNewUpdate armazena todos os valores EDRPOU dos dados da aplicação: uma instância do M.E.Doc pode ser utilizada para executar operações em várias empresas, de modo a que o código malicioso colecione todos os números EDRPOU possíveis.

Além dos números EDRPOU, a backdoor coleciona configurações de proxy e e-mail, incluindo nomes de utilizador e palavras-passe, da aplicação M.E.Doc.

Atenção! Recomendamos que todos os dados de utilizadores do M.E.Doc sejam alterados!

O código malicioso grava as informações colecionadas no registo do Windows sob a chave HKEY_CURRENT_USER \ SOFTWARE \ WC utilizando os nomes de valor Cred e Prx. Deste modo, se esses valores estiverem presentes num computador, é altamente provável que o módulo comprometido, de fato, funcione nesse computador.

E aqui está a parte mais inteligente! O módulo comprometido não utiliza servidores externos de comando e controlo: ao invés, utiliza os pedidos de verificação de atualização regular do software M.E.Doc para o servidor oficial M.E.Doc upd.me-doc.com [.] Ua. A única diferença para um pedido legítimo é que o código backdoored envia as informações que colecionou nos cookies.

Não realizámos análises forenses ao servidor M.E.Doc. No entanto, como observámos no nosso artigo anterior, existem sinais de que o servidor estava comprometido. Assim, podemos especular que os invasores implementaram o software do servidor que lhes permite diferenciar entre pedidos de máquinas comprometidas ou não.

E, claro, os atacantes adicionaram a capacidade de controlarem a máquina infectada. O código recebe um blob binário do servidor oficial M.E.Doc, desencripta-o com o algoritmo Triple DES e posteriormente descomprime-o utilizando o GZip. O resultado é um ficheiro XML que pode conter diversos comandos em simultâneo. Esta funcionalidade de controlo remoto torna a backdoor numa plataforma de espionagem muito completa.

A tabela seguinte mostra alguns dos comandos possíveis:

Importa salientar que o comando número 5, classificado por autores de malware como AutoPayload, se enquadra perfeitamente na forma como o DiskCoder.C foi inicialmente executado nas máquinas “paciente zero”.

Conclusões

Como revela a nossa análise, esta é uma operação bem planeada e bem executada. Assumimos que os atacantes tiveram acesso ao código fonte da aplicação M.E.Doc. Na prática, eles tiveram tempo para aprender o código e incorporar uma backdoor muito furtiva e inteligente. A dimensão da instalação completa M.E.Doc é de cerca de 1,5 GB.

É certo que ainda existem perguntas para responder. Há quanto tempo esta backdoor está a ser utilizada? Quais os comandos e ameaças para além do DiskCoder.C ou Win32 / Filecoder.AESNI.C que foram empurradas através deste canal? Que outras atualizações podem estar comprometidas? Poderão ainda ocorrer mais ataques?

Indicadores de Compromisso (IoC)

Nomes de detecção ESET:
MSIL / TeleDoor.A
Servidores legítimos utilizados pelos autores de malware:
Upd.me-doc.com [.] Ua

hashes SHA-1:
7B051E7E7A82F07873FA360958ACC6492E4385DD
7F3B1C56C180369AE7891483675BEC61F3182F27
3567434E2E49358E8210674641A20B147E0BD23C

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

*