O Enigma do Dark Frost: Um perfil de autor de botnet inesperadamente predominante

A fascinante história do Dark Frost Botnet nos apresenta a um agente de ameaças cuja taxa de sucesso e nível de originalidade não se alinham. O botnet combinado foi criado usando código roubado de várias famílias de malware populares (Mirai, Gafgyt e Qbot), dando a esse invasor a capacidade de realizar ataques bem-sucedidos contra o setor de jogos. 

Ao longo de tudo isso, o agente foi visto se gabando de suas façanhas nas mídias sociais, aproveitando o botnet para se envolver em rixas online triviais e até mesmo deixando assinaturas digitais em seus binários (Figura 1). 

Esse perfil de ameaça é mais difundido do que você pode imaginar. Com determinação suficiente e algum conhecimento rudimentar sobre codificação, quase qualquer um pode se tornar uma ameaça real. Isso é especialmente verdadeiro quando se trata de indivíduos mais jovens que podem ou não entender as possíveis consequências dessas ações. A confiança na sua capacidade de viver acima da lei tende a ofuscar os parâmetros legais estabelecidos, tornando-os mais perigosos do que o esperado.

Nossa primeira amostra binária de Dark Frost foi coletada em 28 de fevereiro de 2023, em alguns dos honeypots HTTP da SIRT (Equipe de resposta de inteligência de segurança) da Akamai. O invasor estava direcionando configurações incorretas em servidores Hadoop YARN (sem CVE atribuído) que permitem a execução remota de código (RCE). Embora a amostra tenha sido chamada de "Darkness Botnet," esse título já havia sido atribuído a uma campanha de DDoS por contratação em 2010. Consequentemente, levando em consideração o nome original e outras referências binárias, optamos por chamá-lo de "Dark Frost Botnet".

A exploração desta configuração incorreta do YARN tem crescido em popularidade ultimamente, pois não foi atribuído um CVE e permite que um agente de ameaça induza o servidor a baixar e executar seu binário malicioso. No entanto, deve-se notar que essa vulnerabilidade existe desde 2014, tornando-a longe de uma nova técnica. No entanto, considerando seu nível de sucesso, provavelmente continuará a ser um fator em botnets futuros, apesar do seu tempo. 

O invasor começou enviando uma sondagem para verificar se o aplicativo era vulnerável a esse tipo de ataque (Figura 2).

Ao receber uma resposta de uma instância vulnerável conhecida que fornecemos, o invasor considerou o alvo adequado e continuou a fornecer a carga mal-intencionada (Figura 3).

Também vemos outra solicitação HTTP sendo enviada, mas atualmente não sabemos para que ela pode ser usada (Figura 4).

Ao olhar originalmente para o arquivo, o binário era chamado de "roof" e, embora o hash não tivesse nenhuma reputação por meio de várias ferramentas de terceiros, nossa automação interna acreditava que fosse semelhante a Gafgyt (Figura 5). Isso pode ser devido ao fato de que os IPs invasores foram vistos distribuindo uma variante específica do Gafgyt nos meses que antecederam a distribuição dos binários do Dark Frost, mas é mais provável que corresponda a várias strings comuns em muitos malwares atualmente. 

Depois de passar no endereço IP para procurar binários adicionais, encontramos mais chamado "roof", cada um atribuído ao mesmo autor desde outubro de 2022. Isso nos deu um novo IP para trabalhar, que, por sua vez, nos deu evidência de tentativas adicionais de distribuir cargas úteis (Figura 6; censurada para sensibilidade racial).

Esse agente de ameaça em particular assumiu o crédito por alguns esforços, com níveis variados de evidência. Às vezes eles simplesmente postavam na mídia social, alegando ser os causadores de vários problemas, o que realmente não teria muito peso. No entanto, ocasionalmente, eles acompanham essas reivindicações com capturas de tela documentando os resultados de seus ataques. 

Um exemplo disso é o Tweet deles sobre um ataque aos servidores Plutonium (Figura 7), uma plataforma de hospedagem de jogos de código aberto com servidores dedicados e suporte a mods.

Tweets como esses são apenas o começo. O ator chega a postar vídeos completos dos ataques, como este ataque a um servidor do AmongUs (Figura 8).

Como você pode ver nas capturas de tela, esse invasor está ativo há algum tempo; podemos rastreá-los até maio de 2022, quando atacaram os servidores da Rogue Company (Figura 9).

Nós até encontramos o ator provocando algumas de suas vítimas e revelando informações sobre seus compradores (Figura 12).

Algumas das perguntas mais difíceis de responder ao analisar malware são: quem é o responsável pelo botnet, quem são os alvos e qual é o tamanho do botnet. Esse cibercriminoso respondeu às duas primeiras perguntas para nós, então começamos a ver se eles responderiam à terceira pergunta também – e com certeza, eles responderam.

De acordo com a Figura 13, uma captura de tela feita pelo autor do malware em fevereiro de 2023, existem 414 dispositivos no botnet, sendo a maioria arquiteturas ARMv4 e as próximas duas mais comuns sendo MIPSEL e x86. A presença do ARMv4 é particularmente interessante, pois essa arquitetura está bastante desatualizada. Este método de compilação especificamente para ARMv4 e ARMv7 é comum porque ARMv4 é compatível com ARMv5 e ARMv6. A compilação para ARMv4 e ARMv7 garante que o malware também possa atingir dispositivos mais modernos executados na arquitetura ARMv7. 

Essa abordagem de direcionamento duplo ajuda o malware a lançar uma rede mais ampla, aumentando suas chances de infectar dispositivos com sucesso.

Colocar as mãos no binário teria sido difícil se não fosse por nosso sistema automatizado de coleta de binários (Figura 14), porque no momento da investigação, o IP de distribuição estava inativo. 

Ao recuperar a amostra, descobrimos que estávamos lidando com uma versão x86-64 (Figura 15), que foi removida, acrescentando alguns pequenos inconvenientes ao reverter.

No entanto, havia muitos outros indicadores, como o tratamento de erros e mensagens de uso, para nos orientar dentro do código (Figura 16).

Houve oito ataques no total, sendo alguns muito comuns, como UDP e TCP, mas outros um pouco mais curiosos, como zgoflood (Figura 17).

Por meio de nossos esforços para reverter a amostra, pudemos renomear algumas das funções removidas para as quais deduzimos que foram usadas (Figura 18).

Em seguida, corrigimos o binário (Figura 19) para que nosso IP seja o servidor de comando e controle (C2). Você pode ver que o nome da variável de string agora é diferente de seu valor real. É interessante observar que o C2 também era o IP de distribuição de malware antes dessa alteração.

Usando outro terminal para ouvir na porta C2 que eles especificaram (TCP/420), conseguimos passar nas verificações de conexão C2, mas o programa parecia sair com um erro (Figura 21).

O malware tenta relatar o tipo de SO e a arquitetura da amostra de malware que infectou o dispositivo (Figura 22). Neste caso, estamos usando o Arch Linux para detonar e dissecar uma amostra de x86.

Depois de passar com sucesso as etapas de conexão e registro, o programa continuou a sair apesar de nossos melhores esforços. Algumas mensagens de erro úteis indicaram que a causa é a falta de um driver watchdog instalado em nosso laboratório de malware. Tentamos muitas vezes ignorar ou satisfazer essa verificação até que percebemos que, embora o processo tenha aparentemente interrompido a execução na linha de comando, ele tinha iniciado um processo filho em segundo plano que estava aguardando comandos. 

Para testar isso, enviamos a pulsação para uma variante típica do BASHLITE usando bate-papos de retransmissão na Internet para comunicações C2 (Figura 23).

Os ataques de socketflood e junkflood também pareciam muito semelhantes, ambos enviando uma pequena quantidade de conteúdo codificado em hexadecimal sobre TCP (Figura 25). Outra coisa a observar é que socketflood realmente é impresso como inundação HOLD . 

Ao testar o comando C2 listado como @c2, encontramos um erro de uso. Decidimos que provavelmente significavam !c2, então tentamos (Figura 26) e um único pacote foi enviado.

Os ataques de onepacket, std, randfloode zgoflood também foram lançados com sucesso, mas na verdade não enviaram nenhum dado (Figura 27). Isso pode significar que esses recursos ainda estão em desenvolvimento ou simplesmente estão quebrados.

Começamos a comparar seus ataques e descobrimos que a inundação UDP era a mais confiável e tinha a maior saída. Usamos vários tamanhos de pacotes, começando com 1024 para ver como o tamanho afetou a quantidade total de dados enviados.

Como pode ser visto na Figura 28, executamos isso em uma porta específica por 10 segundos e, em seguida, prosseguimos para coletar esses dados em tcpdump para analisar os resultados (Figura 29).

Os resultados no tamanho do pacote 1.024 por 10 segundos foram de 1,4 milhão de pacotes capturados, resultando em 1,5 GB do total de dados. Isso resulta 1,2 Gbps. Fazendo esse mesmo experimento, vimos os seguintes resultados para vários tamanhos de pacotes (Tabela 1).

Ao executar o teste, o que provavelmente veríamos seria um invasor usando com este pacote algo próximo a 1.024. Quando dobrada, a saída do pacote cai, devido à fragmentação do pacote, o que significa que só observamos os pacotes que chegam pela porta especificada e não seus fragmentos. Para continuar o parâmetro de comparação corretamente, tivemos que iniciar esses ataques no loopback para evitar a fragmentação e ouvir a interface de loopback para medir novamente (Tabela 2). 

Embora o botnet Dark Frost tenha ataques fortes o suficiente para derrubar muitos serviços online, aqueles protegidos pela Akamai são bastante seguros. A SIRT continuará monitorando ameaças como essas e alertando a comunidade sobre o que observarmos. Para mais pesquisas em tempo real da Akamai, siga-nos no Twitter.