Como os criadores de software malicioso tentam evitar sua detecção: analisamos o Spy.GmFUToMitm como um exemplo

Imagem: Unsplash

Especialistas do Centro de Segurança da Positive Technologies (PT Expert Security Center) descobriram uma amostra interessante de malware se espalhando no segmento de Internet chinês. Este software é usado, entre outras coisas, para realizar ataques MITM, e seu principal recurso é a combinação de várias técnicas para evitar a detecção. Decidimos analisá-los para mostrar como os desenvolvedores de software malicioso ocultam sua atividade.

Como tudo começou

O sistema de análise de tráfego de rede chamou nossa atenção para o fato de que um aplicativo mal-intencionado solicita regularmente uma imagem com conteúdo adicional incluído. O download ocorreu a partir de um recurso legítimo para armazenar imagens - imgsa.baidu.com. Além disso, como se viu, era uma imagem com um nível impressionante de fofura :) E quão blasfema depois disso a tentativa dos invasores de usá-lo para ocultar várias cargas maliciosas parecia blasfema!



Fig. 1. Imagem usada para ocultar o fato de entrega da carga útil

Para começar, para coletar os dados iniciais e comparar as amostras, organizamos uma pesquisa por amostras semelhantes - e encontramos algumas. Isso foi possível graças aos dados característicos da interação da rede e ao nosso extenso banco de dados de tráfego malicioso. Em particular, um padrão claro pode ser visto no tráfego de rede, um padrão que consiste na repetição das mesmas ações por um aplicativo mal-intencionado.



Fig. 2. Tráfego de rede com padrões marcados

Examinamos a primeira solicitação, em resposta a ela, o servidor retornou uma configuração criptografada (Fig. 3) contendo os endereços das imagens que continham a carga útil. Esses dados são armazenados em hxxp://63634[.]top:8081/koded .



Fig. 3. Configuração criptografada

Descriptografia de dados

Os dados recebidos são descriptografados pelo algoritmo DES no modo de livro de códigos eletrônico, com a chave 0x6a 0x5f 0x6b 0x2a 0x61 0x2d 0x76 0x62 contida no corpo do programa malicioso. Após a descriptografia, o texto simples é uma string (Fig. 4), cada uma contendo um link para a imagem. Com base na igualdade dos hashes MD5, esta é a mesma imagem. Aparentemente, para a estabilidade do esquema de entrega, os atacantes localizaram os mesmos dados em endereços diferentes.



Fig. 4. Exemplo de configuração do carregador de inicialização descriptografada

Usando os dados obtidos, o próximo passo é o downloader malicioso iniciar o download da imagem. Ele corta os primeiros 5120 bytes (patinho e filhote) e usa apenas a carga útil (Fig. 5), que segue imediatamente a partir do 5121 ° byte.



Fig. 5. Exemplo de carga útil.

Após descriptografar os dados, obtivemos a próxima configuração de formato, semelhante à obtida na primeira etapa. Essa é mais uma parte dos links de imagem, mas desta vez todos os hashes MD5 são diferentes e existem dois sufixos de caracteres no final de cada linha:



Fig. 6. Segundo conjunto de links e sufixos suspeitos

Algoritmo malicioso

Agora, esses são módulos reais de carga útil. Como se viu, os dois caracteres no final de cada linha são usados ​​para selecionar uma imagem específica, ou seja, uma carga útil específica. Primeiro, é usada uma linha com o sufixo "AD" (Fig. 7). Essa escolha já está predeterminada na fase de criação do programa malicioso. Ou seja, a sequência de carregamento é predefinida na forma de sufixos de dois dígitos.



Fig. 7. Selecionando um link com o sufixo "AD"

A imagem baixada já contém um módulo malicioso, isso pode ser dito pelo menos com base em seu tamanho. Os dados ainda são mascarados como imagens e localizados no mesmo deslocamento de 5120 bytes. Após descartar os bytes extras, o carregador extrai, verifica a quantidade de hash e descriptografa um módulo chamado TkRep.dll no arquivo PE.



Fig. 8. Um exemplo de um módulo criptografado no corpo da imagem e sua soma de hash

Esta biblioteca é carregada em um processo malicioso e, em primeiro lugar, verifica o ambiente em que o módulo está sendo executado:



Fig. 9. Verificando o ambiente de virtualização

Verifica entre os processos em execução a presença de processos com os nomes devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, PCHunter64.exe - além da presença de ferramentas antivírus.



Fig. 10. Verificação de processo

Faz uma verificação de depuração padrão.



Fig. 11. Verificando o início do processo no contexto do depurador

Verifica os tubos abertos listados na tabela.

A próxima etapa é registrar o nó infectado no servidor mal-intencionado, enviando informações criptografadas sobre o nó infectado com uma solicitação POST para o protocolo HTTP (Fig. 12).



Fig. 12. Solicitação de registro no servidor de cibercriminosos

Vale ressaltar que a resposta do servidor sempre contém os mesmos dados e, além disso, apenas o código de resposta do servidor é levado em consideração pelo cliente.

Como o malware oculta sua atividade

De acordo com uma determinada sequência de cargas, prosseguimos para o estudo a seguir. Seu sufixo é "AR". O cliente, de acordo com o esquema existente, baixa a próxima concatenação da imagem com a carga criptografada do serviço de armazenamento de imagens do Baidu Images, descriptografa o módulo e o inicia em um novo processo com um nome aleatório. Em nossa opinião, essa funcionalidade serve para fazer com que um aplicativo mal-intencionado pareça inofensivo. Muitas vezes, este é um cliente de um jogo online (Fig. 13). E essa foi outra técnica de disfarce.



Fig. 13. interface de jogo online

Após essa manobra de distração, o processo malicioso prossegue para o estágio de correção no nó infectado. Para fazer isso, ele usa uma funcionalidade semelhante à funcionalidade dos programas rootkit. Em particular, a introdução de seu próprio driver seguro no sistema.

E é assim que acontece. Na configuração descriptografada, a carga com o sufixo "AE" é selecionada. Esta é a biblioteca TaskReportDLL.dll. Ele tem as mesmas funções que a biblioteca TkRep.dll do estágio anterior - envie informações sobre o sistema e verifique a disponibilidade de equipamentos de proteção.

Em seguida, a biblioteca RealWorkDll.dll é baixada. Entre as funções do RealWorkDll.dll, é importante baixar o driver, que está parcialmente protegido pelo VMPROTECT, e o arquivo PE que esse driver instalará no sistema.



Fig. 14. Caminho para o banco de dados do driver

Em seguida, os arquivos PE usados ​​para instalar o driver são excluídos e esse estágio de correção é concluído.

Uma pesquisa na linha do banco de dados do driver nos levou ao repositório do espelho de recursos rootkit [.] Com, no qual foi encontrada uma instância do rootkit FUTo com o nome correspondente no caminho “objfre_wxp_x86” (Fig. 14). No blog da nossa empresa, este rootkit foi considerado em 2006 .

Vamos considerar com mais detalhes o trabalho no sistema do driver SDriverBlogx86 instalado pelo módulo RealWorkDll.dll. Na primeira etapa, os dados de registro do cliente vão para a rede. O POST é usado como solicitação, mas agora na porta número 8081 (Fig. 15). Aparentemente, essa porta é usada para receber dados se a atividade no sistema infectado tiver atingido o estágio de ativação do rootkit “FUTo”.



Fig. 15. Solicitação de C2 do driver instalado no sistema

O acesso ao servidor de cibercriminosos ocorre de forma criptografada, dados antes de criptografia serem informações sobre o sistema. Separadores de campos de dados, formato de apresentação e número de campos são os mesmos para todos os módulos (Fig. 16).



Fig. 16. Informações do sistema para identificar um nó infectado

Além disso, o mecanismo de operação do driver incorporado no sistema coincide com o carregador de inicialização inicial - a única diferença é que os links para imagens dessa vez foram solicitados a partir da porta rootkit e o caminho de armazenamento de configuração alterado de / koded para / qqwe. Talvez isso esteja relacionado aos serviços qq.com e wechat.com.

A lista de módulos que o processo recebe contém uma lista de arquivos PE. Mas, nesse caso, em vez do sufixo de duas letras para selecionar a carga, no final da linha contém uma chave na forma de um nome de arquivo:



Fig. 17. Configuração recebida pelo driver corrigida no sistema

Depois de carregar as imagens, a carga útil também está localizada no deslocamento de 5120 bytes. A estrutura de carga útil do driver instalado inclui a chave da lista anterior na forma de um nome de arquivo e, em seguida, o próprio arquivo PE. Diferentemente das etapas anteriores, a carga útil não é criptografada aqui.



Fig. 18. Carga recebida pelo rootkit instalado no sistema

Entre todas as cargas recebidas nesse estágio, vale destacar o módulo para a realização de ataques MITM. Seu hash é igual a b9fcf48376083c71db0f13c9e344c0383bafa5b116fbf751672d54940082b99a , a imagem com ele é armazenada neste endereço .

O módulo resultante verifica processos com os nomes devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, PCHunter64.exe, além dos processos ZhuDongFangYu, 360Safe, 360Tray.

No processo de trabalhar com a ajuda de uma solicitação GET, os certificados server.crt, server.key, server.der, startcom.crt são baixados.



Fig. 19. Solicitação de certificados

Os nomes de classe do módulo para conduzir um ataque MITM não deixam dúvidas sobre as intenções dos atacantes (Fig. 20).



Fig. 20. Nomes de classe do módulo para conduzir um ataque MITM

Conclusão

Esse malware consiste em um carregador de inicialização, um arquivo de disfarce, um driver de rootkit e um módulo para conduzir um homem no meio do ataque. Para entrega secreta de carga, o software usa uma técnica para unir dados com imagens JPEG. Para servidores de comando, os atacantes registram nomes nas zonas de domínio superior, lance e também com base em plataformas na nuvem.

Aqui estão alguns métodos para mascarar a atividade usada pelos desenvolvedores de software malicioso:

• disfarçar como uma aplicação legal,
• mascarar tráfego para imagens,
• encaixe como um rootkit.

A ameaça considerada é detectada pelo PT Network Attack Discovery do sistema de análise de tráfego de rede como Spy.GmFUToMitm.


Autores : Dmitry Makarov, Evgeny Ustinov, Positive Technologies