blank

blank

Background

Em dezembro de 2020, a notícia do incidente da SolarWinds tomou o mundo como uma tempestade. Embora os ataques à cadeia de suprimentos já fossem um vetor de ataque documentado, alavancado por vários atores da APT, essa campanha específica se destacou devido ao extremo cuidado dos atacantes e à natureza de destaque de suas vítimas. Acredita-se que quando a FireEye descobriu os primeiros vestígios da campanha, o ator ameaçador (DarkHalo também conhecido como Nobelium) já estava trabalhando nisso há mais de um ano. As evidências coletadas até agora indicam que DarkHalo passou seis meses dentro das redes da OrionIT para aperfeiçoar seu ataque e se certificar de que a violação da cadeia de construção não causaria nenhum efeito adverso.

A primeira atualização maliciosa foi enviada aos usuários do SolarWinds em março de 2020 e continha um malware chamado Sunburst. Só podemos supor que DarkHalo aproveitou esse acesso para coletar inteligência até o dia em que foram descobertos. O cronograma a seguir resume as diferentes etapas da campanha:

blank
securelist

A equipe GReAT da Kaspersky também investigou esse ataque à cadeia de suprimentos e publicou duas postagens de blog sobre ele:

Em março de 2021, a FireEye e a Microsoft divulgaram informações adicionais sobre o malware de segundo estágio usado durante a campanha, o Sunshuttle (também conhecido como GoldMax). Mais tarde, em maio de 2021, a Microsoft também atribuiu ao Nobelium a campanha de spear-phishing se passando por uma organização sediada nos Estados Unidos. Mas a essa altura a trilha já havia esfriado: DarkHalo há muito havia encerrado as operações, e nenhum ataque subsequente foi ligado a eles.

DNS hijacking

No final deste ano, em junho, nossos sistemas internos encontraram vestígios de um sequestro de DNS bem-sucedido que afetou várias zonas governamentais de um estado membro da CEI. Esses incidentes ocorreram durante curtos períodos em dezembro de 2020 e janeiro de 2021 e permitiram que o agente da ameaça mal-intencionada redirecionasse o tráfego dos servidores de correio do governo para as máquinas que controlavam.

Zona Período durante o qual os servidores autorizados eram maliciosos Domínios sequestrados
mfa. *** 22 a 23 de dezembro de 2020 e
13 a 14 de janeiro de 2021
mail.mfa. ***
kk.mfa. ***
investir.*** 28 de dezembro de 2020 a 13 de janeiro de 2021 mail.invest. ***
fiu. *** 29 de dezembro de 2020 a 14 de janeiro de 2021 mx1.fiu. ***
mail.fiu. ***
infocom. *** 13 a 14 de janeiro de 2021 mail.infocom. ***

Durante esses intervalos de tempo, os servidores DNS autorizados para as zonas acima foram trocados para resolvedores controlados pelo invasor. Esses sequestros foram, em sua maioria, relativamente breves e parecem ter como alvo principalmente os servidores de email das organizações afetadas. Não sabemos como o agente da ameaça conseguiu fazer isso, mas presumimos que de alguma forma ele obteve credenciais para o painel de controle do registrador usado pelas vítimas.

Enquanto os redirecionamentos maliciosos estavam ativos, os visitantes eram direcionados para páginas de login do webmail que imitavam as originais. Devido ao fato de que os invasores controlavam os vários nomes de domínio que estavam sequestrando, eles conseguiram obter certificados SSL legítimos do Let’s Encrypt para todas essas páginas falsas, tornando muito difícil para visitantes não instruídos perceberem o ataque – afinal, eles estavam se conectando ao URL normal e pousaram em uma página segura.

blank
Página de login do webmail malicioso configurada pelos invasores

Provavelmente, todas as credenciais digitadas nessas páginas da Web foram coletadas pelos invasores e reutilizadas em estágios subsequentes do ataque. Em alguns casos, eles também adicionaram uma mensagem na página para induzir o usuário a instalar uma “atualização de segurança” mal-intencionada. Na captura de tela acima, o texto diz: “para continuar trabalhando com o serviço de e-mail, você precisa instalar uma atualização de segurança: baixe a atualização”.

O link leva a um arquivo executável que é um downloader para uma família de malware anteriormente desconhecida que agora conhecemos como Tomiris.

Tomiris

O Tomiris é um backdoor escrito em Go, cuja função é consultar continuamente seu servidor C2 em busca de executáveis ​​para baixar e executar no sistema da vítima. Antes de realizar qualquer operação, ele dorme por pelo menos nove minutos em uma possível tentativa de derrotar os sistemas de análise baseados em sandbox. Ele estabelece persistência com tarefas agendadas criando e executando um arquivo em lote contendo o seguinte comando:

O endereço do servidor C2 não está embutido diretamente no Tomiris: em vez disso, ele se conecta a um servidor de sinalização que fornece a URL e a porta à qual o backdoor deve se conectar. Em seguida, Tomiris envia solicitações GET para esse URL até que o servidor C2 responda com um objeto JSON da seguinte estrutura:

Este objeto descreve um executável que é descartado na máquina da vítima e executado com os argumentos fornecidos. Esse recurso e o fato de que o Tomiris não tem capacidade além de baixar mais ferramentas indicam que há peças adicionais para esse conjunto de ferramentas, mas infelizmente não foi possível recuperá-las.

Também identificamos uma variante do Tomiris (internamente denominada “SBZ”, MD5 51AA89452A9E57F646AB64BE6217788E) que atua como um arquivador e carrega qualquer arquivo recente correspondente a um conjunto de extensões codificado (.doc, .docx, .pdf, .rar, etc.) para o C2.

Finalmente, algumas pequenas pistas encontradas durante esta investigação indicam com pouca confiança que os autores de Tomiris podem ser falantes de russo.

A conexão Tomiris

Ao analisar o Tomiris, notamos uma série de semelhanças com o malware Sunshuttle discutido acima:

  • Ambas as famílias de malware foram desenvolvidas em Go, com empacotamento UPX opcional.
  • O mesmo separador (“|”) é usado no arquivo de configuração para separar os elementos.
  • Nas duas famílias, o mesmo esquema de criptografia/ofuscação é usado para codificar arquivos de configuração e se comunicar com o servidor C2.
  • De acordo com o relatório da Microsoft, Sunshuttle dependia de tarefas agendadas para persistência também.
  • Ambas as famílias dependem comparativamente da aleatoriedade:
    • Sunshuttle randomiza seus URLs referenciadores e chamarizes usados ​​para gerar tráfego benigno. Ele também dorme de 5 a 10 segundos (por padrão) entre cada solicitação.
    • O Tomiris adiciona um atraso aleatório (0-2 segundos ou 0-30 segundos, dependendo do contexto) ao tempo base em que ele dorme em vários momentos durante a execução. Ele também contém uma lista de pastas de destino para descartar executáveis ​​baixados, dos quais o programa escolhe aleatoriamente.
    • Tomiris e Sunshuttle propagam novamente gratuitamente o RNG com a saída de Now () antes de cada chamada.
  • Ambas as famílias de malware dormem regularmente durante sua execução para evitar a geração de muita atividade de rede.
  • O fluxo de trabalho geral dos dois programas, em particular a maneira como os recursos são distribuídos nas funções, parecem semelhantes o suficiente para que este analista sinta que podem ser indicativos de práticas de desenvolvimento compartilhadas. Um exemplo disso é como o loop principal do programa é transferido para uma nova goroutine quando as etapas de preparação são concluídas, enquanto o thread principal permanece inativo para sempre.
  • Erros de inglês foram encontrados nas strings Tomiris (“isRunned”) e Sunshuttle (“EXECED” em vez de “executado”).

Nenhum desses itens, considerados individualmente, é suficiente para ligar Tomiris e Sunshuttle com confiança suficiente. Admitimos livremente que vários desses dados podem ser acidentais, mas ainda sentimos que, em conjunto, pelo menos sugerem a possibilidade de autoria comum ou práticas de desenvolvimento compartilhadas.

Uma prova circunstancial final que gostaríamos de apresentar é a descoberta de que outras máquinas em uma rede infectada com Tomiris foram infectadas com a porta dos fundos Kazuar. Infelizmente, os dados disponíveis não nos permitem determinar se um dos programas maliciosos leva à implantação do outro ou se eles se originam de dois incidentes independentes.

O próximo diagrama resume os elos fracos que conseguimos descobrir entre as três famílias de malware mencionadas neste artigo:

blank
securelist

No final, várias pistas sugerem ligações entre Sunburst, Kazuar e Tomiris, mas parece que ainda estamos perdendo uma peça de evidência que nos permitiria atribuí-los todos a um único ator de ameaça. Gostaríamos de concluir este segmento abordando a possibilidade de um ataque de bandeira falsa: pode-se argumentar que, devido à natureza de alto perfil do Sunshuttle, outros atores de ameaças poderiam ter intencionalmente tentado reproduzir seu design para enganar os analistas. A primeira amostra de Tomiris que conhecemos apareceu em fevereiro de 2021, um mês antes de Sunshuttle ser revelado ao mundo. Embora seja possível que outros APTs estivessem cientes da existência dessa ferramenta neste momento, sentimos que é improvável que eles tentassem imitá-la antes mesmo de ser divulgada.

Conclusões

Se nossa suposição de que Tomiris e Sunshuttle estão conectados estiver correta, isso lançaria uma nova luz sobre a maneira como os agentes de ameaça reconstroem suas capacidades depois de serem capturados. Gostaríamos de encorajar a comunidade de inteligência de ameaças a reproduzir esta pesquisa e fornecer uma segunda opinião sobre as semelhanças que descobrimos entre Sunshuttle e Tomiris. Para iniciar os esforços, a Kaspersky tem o prazer de anunciar uma atualização gratuita para nossa classe de Engenharia reversa de malware direcionado , apresentando uma nova linha dedicada à engenharia reversa de malware Go e usando o Sunshuttle como exemplo. As duas primeiras partes também estão disponíveis no YouTube:

https://youtu.be/_cL-OwU9pFQ

https://youtu.be/YRqTrq11ebg

Para obter mais informações sobre a Tomiris: [email protected]

Indicadores de compromisso

Tomiris Downloader
109106feea31a3a6f534c7d923f2d9f7
7f8593f741e29a2a2a61e947694445f438b33380
8900cf88a91fa4fbe871385c8747c7097537f1b5f4a003418d84c01dc383dd75
fd59dd7bb54210a99c1ed677bbfc03a8
292c3602eb0213c9a0123fdaae522830de3fad95
c9db4f661a86286ad47ad92dfb544b702dca8ffe1641e276b42bec4cde7ba9b4

Tomiris
6b567779bbc95b9e151c6a6132606dfe
a0de69ab52dc997ff19a18b7a6827e2beeac63bc
80721e6b2d6168cf17b41d2f1ab0f1e6e3bf99ab52dc997ff19a18b7a6827e2beeac63bc 80721e6b2d6168cf17b41d2f1ab0f1e6e3bf994db585754109f3b7e

Servidor de teste Tomiris
51.195.68[.]217

Tomiris signalization server
update.softhouse[.]Store

Tomiris C2
185.193.127[.]92
185.193.126[.]172

Caminho de construção
C:/Projects/go/src/Tomiris/main.go

Fonte: Kaspersky


Descubra mais sobre DCiber

Assine para receber os posts mais recentes por e-mail.