Infecção desde o primeiro contato: NoaBot baseado em Mirai marca presença
Resumo executivo
Os pesquisadores de segurança da Akamai descobriram uma nova campanha de mineração de criptografia, que está ativa desde o início de 2023.
O malware é espalhado pelo protocolo SSH usando um botnet Mirai personalizado que foi modificado pelos agentes de ameaça.
Os recursos do novo botnet, NoaBot, incluem um distribuidor automático que pode ser usado e um backdoor de chave SSH para baixar e executar binários adicionais ou se espalhar para novas vítimas.
Como parte do ataque, uma versão modificada do minerador XMRig é eliminada. O minerador ofusca sua configuração e também usa um pool de mineração personalizado para evitar expor o endereço da carteira usado pelo minerador.
Vimos evidências que vinculam o botnet ao worm P2PInfect, que foi descoberto pela Unidade 42 em julho de 2023.
A ofuscação de malware e o código personalizado mostram um alto nível de segurança operacional, que normalmente indica agentes de ameaças maduros, mas a nomeação dos binários do malware e algumas de suas cadeias incluídas são bastante ingênuas. Isso complica a atribuição.
Vimos mais de 800 IPs de ataque diferentes em 2023, distribuídos uniformemente pelo mundo.
Nós divulgamos indicadores de comprometimento (IOCs), consultas, assinaturas e scripts que podem ser usados para testes de infecções.
Introdução
O NoaBot é mais um botnetbaseado em Mirai. O botnet Mirai é um botnet que pode ser usado para atingir dispositivos de Internet das Coisas (IoT) baseados em Linux. Ele é usado para ataques de negação de serviço distribuída (DDoS). O botnet Mirai original foi identificado em 2016, mas seu código-fonte foi publicadoe muitas variantes podem ser vistas atualmente.
Detectamos pela primeira vez a campanha NoaBot no início de 2023. Desde então, vimos duas evoluções do malware, que consistem em ofuscações adicionais ou uma mudança de comando e controle (C2) e domínios de pool de mineração (Figura 1). Também vimos vários incidentes que derrubam amostras do worm P2PInfect, que indica que as duas campanhas estão relacionadas.
Fig. 1: Atividade de malware NoaBot ao longo do tempo
O botnet
NoaBot tem a maioria dos recursos do botnet Mirai original (como um módulo de leitor e um módulo de invasor, ocultando seu nome de processo etc.), mas também podemos ver muitas diferenças do código-fonte original do Mirai. Em primeiro lugar, o distribuidor do malware é baseado em SSH, não em Telnet como o Mirai.
O scanner SSH parece ser personalizado e bastante peculiar: quando uma conexão é estabelecida, o botnet simplesmente envia a string "hi" e encerra a conexão (Figura 2). A terminação rápida faz sentido no contexto de um scanner, pois não precisa manter a conexão aberta, apenas verificar se ela existe. Mas por que ele se incomoda em enviar "hi"? Isso é um mistério.
Fig. 2: O pacote SSH com a string "hi". Não é um pacote SSH válido, então o Wireshark o marca como malformado.
Outra peculiaridade do malware é a letra de música incorporada. Amostras anteriores do botnet tinham letras da canção "Who's Ready for Tomorrow" de Rat Boy e IBDY (Figura 3). Até onde podemos dizer, essas letras não serviram para nenhuma finalidade. As amostras posteriores não as tinham.
Fig. 3: A letra de música incorporada que parece não servir a nenhum propósito.
Outras alterações do Mirai são que o botnet usa um dicionário de credenciais diferente para seu scanner SSH e inclui muitos recursos pós-violação, como a instalação de uma nova chave SSH autorizada como backdoor para baixar e executar binários adicionais ou se espalhar para novas vítimas (Figura 4).
Fig. 4: Caso de switch de comando do botnet
Além disso, ao contrário do Mirai, que geralmente é compilado com GCC (pelo menos de acordo com seu código-fonte e guia do autor), o NoaBot é compilado com uClibc, que parece mudar a forma como os mecanismos antivírus detectam o malware. Embora outras variantes do Mirai sejam geralmente detectadas com uma assinatura do Mirai, as assinaturas antivírus do NoaBot são de um scanner SSH ou um cavalo de troia genérico (Figura 5).
O malware também é compilado estaticamente e quaisquer símbolos são removidos dele. Isso, além de ser uma compilação fora do padrão, tornou a engenharia reversa do malware muito mais frustrante.
Amostras mais recentes do botnet também tinham sua cadeia ofuscada em vez de serem salvas como texto sem formatação. Isso tornou mais difícil extrair detalhes do binário ou navegar pelas partes da desmontagem, mas a codificação em si era pouco sofisticada e a engenharia simples de reverter.
Também vimos a adição de argumentos de linha de comando ao longo do tempo. O mais interessante é o sinalizador "noa", que fez com que o botnet instalasse um método de persistência na forma de uma entrada crontab para execução após uma reinicialização.
Coincidentemente, parece que esse sinalizador foi fortemente usado, pois algumas das detecções antivírus para amostras de botnet tinham o prefixo "Noa-".
As operações pós-violação, que mostramos na Figura 4, são outra evolução. Não estavam presentes nas amostras anteriores que investigamos.
Fig. 5: Detecções de NoaBot (à esquerda) vs. outra variante de Mirai (à direita)
O minerador e por que não conseguimos encontrar o endereço da carteira dele
O minerador em si é muito menos complicado. É o minerador XMRig padrão, embora também tenha sido autocompilado, e os agentes de ameaça adicionaram algum código antes da execução do minerador para extrair a configuração de mineração em vez de fornecê-la via linha de comando ou salvá-la dentro do binário como texto sem formatação (Figura 6).
Fig. 6: A função principal do minerador
Podemos ver que há outras chamadas de função antes da chamada de função para criar a configuração XMRig. Se falhar, o minerador termina, mas, caso contrário, vai para a lógica do minerador XMRig padrão. (Você pode comparar a descompilação acima com o código-fonte XMRig real.) Por que nós, como pesquisadores, nos preocupamos com a configuração do XMRig? Geralmente, ele contém detalhes sobre o pool de mineração ao qual se conecta, bem como o endereço da carteira para receber pagamentos de mineração. Ao obter o endereço da carteira e rastrear os pagamentos (que geralmente são rastreados por pools públicos), podemos estimar a rentabilidade do gig da criptomineração.
Desta vez, no entanto, os invasores estavam à nossa frente. Então, vamos nos aprofundar na criação da configuração. No código-fonte aberto XMRig, os mineradores podem aceitar configurações de uma das duas maneiras; por meio da linha de comando ou por meio de variáveis ambientais. Em nosso caso, os agentes de ameaça optaram por não modificar o código original XMRig e, em vez disso, adicionaram partes antes da função principal. Para contornar a necessidade de argumentos de linha de comando (que podem ser um indicador de comprometimento de IOC e defensores de alerta), os agentes de ameaça fizeram o minerador substituir sua própria linha de comando (em termos técnicos, substituindo argv) por argumentos mais "significativos" antes de passar o controle para o código XMRig. O botnet executa o minerador com (no máximo) um argumento que o instrui a imprimir seus logs.
No entanto, antes de substituir sua linha de comando, o minerador precisa criar sua configuração. Primeiro, ele copia argumentos básicos que são armazenados em texto sem formatação: o sinalizador RIG-id, que identifica o minerador com três letras aleatórias, os sinalizadores de threads e um espaço reservado para o endereço IP do pool (Figura 7).
Curiosamente, como as configurações são carregadas por meio dos registros xmm, o IDA perde os dois primeiros argumentos carregados, que são o nome binário e o espaço reservado do IP do pool.
Fig. 7: Copiando a configuração básica do minerador
Em seguida, o minerador descriptografa o nome de domínio do pool. O nome do domínio é armazenado e criptografado em alguns blocos de dados que são descriptografados por meio de operações XOR. Embora o XMRig possa trabalhar com um nome de domínio, os invasores decidiram dar o passo extra e implementaram sua própria função de resolução de DNS. Eles se comunicam diretamente com o servidor DNS do Google (8.8.8.8) e analisam sua resposta para resolver o nome do domínio para um endereço IP.
A última parte da configuração também é criptografada de maneira semelhante, e é a chave de acesso para o minerador se conectar ao pool. No geral, a configuração total do minerador tem a seguinte aparência:
<miner_binary_name> -o <pool_ip> --rig-id <random_id> --threads <cpus> –pass espana*tea |
Sentiu falta de algo? Sim, nenhum endereço de carteira.
Acreditamos que os agentes de ameaça optaram por executar seu próprio pool privado em vez de um público, eliminando assim a necessidade de especificar uma carteira (seu pool, suas regras!). No entanto, em nossas amostras, observamos que os domínios do minerador não estavam sendo resolvidos com o DNS do Google, portanto, não podemos realmente provar nossa teoria nem coletar mais dados do pool, já que os domínios que temos não são mais resolvíveis. Não vimos qualquer incidente recente que derrube o minerador, por isso também pode ser que os agentes de ameaça decidiram partir para campos mais férteis.
O Mirai é muito velho está Rust (enferrujado)
Os incidentes mais recentes que vimos também tinham amostras de P2PInfect – um worm de replicação automática ponto a ponto escrito em Rust. Embora o P2PInfect tenha sido visto pela primeira vez em julho de 2023, vimos atividade do NoaBot desde janeiro de 2023, o que significa que ele antecede o P2PInfect por pouco. Por que mudar do Mirai para outra coisa? Algo que pode até ser personalizado? Não temos uma resposta clara, mas algumas suposições.
Primeiro, é mais difícil fazer engenharia reversa do código personalizado do que do código reaproveitado porque ele foi modificado. Em segundo lugar, os agentes de ameaça parecem conhecer bastante de tecnologia, por isso, pode ser que estejam experimentando o desenvolvimento de malware por curiosidade ou tédio (ou ambos). Por fim, dado que o P2PInfect foca em servidores Redis, poderia ser simplesmente um caso de ferramentas diferentes para finalidades diferentes.
Como sabemos que são os mesmos agentes de ameaça, não apenas algum tipo de colaboração? Não temos 100% de certeza, mas estamos próximos. Tudo se resume ao profissionalismo técnico no malware, juntamente com o nível de maturidade de um adolescente em termos de piadas internas, incluindo a inserção de palavrões no nome do minerador, a incorporação de letras de músicas pop de jogos em binários de malware e o envio de "hi" durante a verificação de portas abertas.
O P2PInfect segue essa tradição. Parece uma ferramenta sofisticada, mas usa um soquete Unix e o nomeia como "NunzombiE" (Figura 8). E, embora o NunzombiE seja ofuscado e decodificado durante o tempo de execução, o worm também tem strings incorporadas para "fast_vuln_file" e "slow_vuln_file", strings perfeitamente legítimos para conter em um executável, sem sinais de alerta aqui.
Fig. 8: Strace do worm P2PInfect criando um soquete Unix chamado NunzombiE
Vitimologia
Há 849 IPs de origem diferentes que atacaram nossos potes de mel em 2023. Olhando para a geolocalização deles, podemos ver uma distribuição de atividade relativamente uniforme em todo o mundo. Isso faz sentido, já que o malware é preocupante, de modo que cada nova vítima se torna um invasor. Há, no entanto, um único ponto de acesso de atividade que se destaca e está na China. Esse ponto equivale a quase 10% de todos os ataques que vimos em 2023. É o ponto mais brilhante na Figura 9.
Fig. 9: Área de destaque de geolocalização global de fontes de ataque NoaBot
Mitigação, detecção, emulação
O método de movimento lateral do malware é por meio de ataques simples e antigos de dicionário de credenciais SSH.
Restringir o acesso SSH arbitrário à Internet à sua rede diminui consideravelmente os riscos de infecção. Além disso, o uso de senhas fortes (não padrão ou geradas aleatoriamente) também torna sua rede mais segura, pois o malware usa uma lista básica de senhas que podem ser adivinhadas. Compartilhamos os conjuntos de credenciais usados pelo malware em nosso repositório do GitHub.
Não há muito a dizer sobre a detecção do malware, além de procurar seus nomes binários. Ele é executado a partir de uma pasta gerada aleatoriamente em /lib, portanto, os nomes de processo provavelmente são o caminho. Também deve ser possível detectar seu cron job, se tiver. Um arquivo CSV de IOC também está disponível em nosso repositório, bem como algumas assinaturas da YARA para a mina.
Caso você queira testar seu ambiente contra o distribuidor SSH do botnet, criamos um arquivo de configuração para o Infection Monkey, nossa plataforma de emulação de adversário de código aberto (incluímos uma breve explicação sobre como usar o Infection Monkey no Apêndice). Lembre-se de que, como o malware usa um conjunto de credenciais muito grande, seria impraticável testar todos eles (o malware não se importa com a computação ou com os custos de tempo, mas nós sim). Em vez disso, optamos por incluir apenas as credenciais mais comuns na configuração. Se você quiser incluir mais credenciais (ou diferentes), sinta-se à vontade para criar essa configuração e incluir suas próprias modificações.
Essa configuração do Infection Monkey também adiciona uma string de máscara que fará com que nossas assinaturas YARA sejam acionadas na carga útil do agente Monkey, para que você possa usá-la para testar essa detecção também.
Assim que o Infection Monkey terminar de testar seu ambiente, ele criará um relatório de todas as máquinas que conseguiu violar. Você também pode usar seu plug-in de criptojacking se quiser levar a simulação de ataque para o próximo nível e testar credenciais mais fortes.
Resumo
Na superfície, o NoaBot não é uma campanha muito sofisticada: é "apenas" uma variante Mirai e um criptominerador XMRig, e é fácil de encontrar. No entanto, as ofuscações adicionadas ao malware e as adições ao código-fonte original pintam uma imagem muito diferente dos recursos dos agentes de ameaça. Apesar das habilidades técnicas dos agentes de ameaça, eles parecem ter algumas convenções de nomenclatura imaturas (um soquete Unix chamado "NunzombiE", por exemplo) que persistem mesmo entre diferentes amostras de malware e binários. Usamos essa caraterística para associar o NoaBot ao P2PInfect, e talvez essa pista de detecção seja verdadeira para futuras campanhas de malware.
Apêndice: Usar o Infection Monkey para testar seu ambiente
Instalar o Infection Monkey com base no seu sistema operacional:
Siga as instruções de configuração.
Baixe o plug-in de exploração SSH da página de plug-ins na interface do usuário do Infection Monkey.
Fig. 10: A tela de plug-in Infection Monkey. Use a barra de pesquisa para procurar o plug-in de exploração SSH e baixá-lo.
Importe o arquivo de configuração para emular o NoaBot.
Fig. 11: A tela de configuração do Infection Monkey. Você pode importar a configuração que fornecemos pressionando o botão "Importar config".
Configure os destinos para tentar um ataque na guia "Análise de rede" da página de configuração.
Execute o Monkey.
Vá para a página do mapa para observar o ataque.
Se, a qualquer momento, você quiser interromper a simulação, basta pressionar o botão "Kill All Monkeys" para finalizar o ataque.
