O fantasma na máquina: o dossiê completo sobre TA-NATALSTATUS e a guerra territorial do Cryptojacking

Começa como a maioria dos alertas de cryptojacking: uma porta Redis exposta, um processo suspeito, talvez um aumento no uso da CPU. Fácil de ignorar. Fácil de limpar. Até que não seja. Porque alguns mineradores não são apenas operações de esmagar e agarrar — são ocupações silenciosas.

STATUS TA-NATAL é um deles. Nos últimos cinco anos, esse agente de ameaças construiu uma infraestrutura extensa e resiliente explorando as mesmas configurações incorretas esquecidas que todo mundo usa, mas com muito mais disciplina e visão de longo prazo. O malware deles não se limita a minerar — ele esconde, persiste, se espalha e fortalece. E a oportunidade? É enorme. Em apenas alguns países:

• Mais de 17% de servidores Redis na Estados Unidos permaneça exposto
• 33% em Alemanha
• 27% na Reino Unido
• 23% em França
• 41% em Finlândia
• E 39% em Rússia

Dezenas de milhares de servidores em todo o mundo estão vulneráveis — e a TA-NATALSTATUS está ativamente atacando todos eles. Com trocas binárias no estilo rootkit, camuflagem de processos, ofuscação de comandos, bloqueios de arquivos imutáveis e “listas de mortes” anti-rivais, esse grupo transformou um vetor de ataque de mercadorias em uma campanha robusta de aquisição de infraestrutura. Este é o dossiê completo sobre o TA-NATALSTATUS: como eles operam, como evoluíram e como caçá-los, confirmá-los e erradicá-los, antes que seu servidor se torne apenas mais um ativo em seu império em crescimento.

The Hunting Ground: um playground de servidores expostos

O TA-NATALSTATUS não precisa de explorações sofisticadas de dia zero quando seu campo de caça global é rico em alvos. A principal causa de seu sucesso é uma falha sistêmica mundial em proteger adequadamente as instâncias do Redis. Os dados abaixo ilustram a grande escala da oportunidade disponível para eles.

‍

‍

Esses dados revelam uma verdade fundamental: altas porcentagens de servidores expostos não estão confinadas a uma região, mas são um problema global, causado por configurações incorretas do desenvolvedor e configurações padrão inseguras. Esse cenário de dezenas de milhares de servidores vulneráveis é exatamente o que permite que uma campanha automatizada e eficiente como a do TA-NATALSTATUS floresça.

A evolução de um adversário: de 2020 até hoje

Nossa investigação começou quando o CloudSEK Seja Vigil detectou uma instância aberta do Redis dentro de uma das infraestruturas do nosso cliente. Essa instância exposta foi comprometida por um criptominerador, o que desencadeou uma investigação mais profunda. Embora esse incidente tenha servido como ponto de partida, a inteligência de código aberto nos ajudou a descobrir um contexto mais amplo. As táticas, técnicas e procedimentos (TTPs) usados pelo agente da ameaça — agora identificado como TA-NatalStatus — parecem ser uma evolução direta de um worm multiplataforma relatado originalmente pela Trend Micro em 2020.

‍

O que não mudou (The Core Playbook):

• Acesso inicial: Abusando de servidores Redis não autenticados e expostos publicamente.
• Método de execução: Usando os comandos Redis CONFIG SET e SAVE para escrever cron jobs maliciosos.
• Estrutura: Uma cadeia de infecção modular com vários scripts (init/ndt.sh, is.sh, rs.sh).

‍

O que mudou (as atualizações de 2025):

É isso que os torna perigosos hoje em dia. Eles aprenderam com anos de detecção de malware e aprimoraram sistematicamente sua discrição.

• Sequestro de processos: Eles agora empregam uma técnica semelhante a um rootkit para ocultar seus processos. Ao renomear os binários do sistema, como ps e top, para ps.original e substituí-los por invólucros maliciosos, eles filtram seu próprio malware (httpgd) da saída. Um administrador procurando o minerador não o verá usando ferramentas padrão.
• Ofuscação de comando: Eles renomeiam curl e wget para cd1 e wd1. Esse é um método simples, mas brilhante, para contornar produtos de segurança que monitoram downloads maliciosos iniciados especificamente por esses nomes comuns de ferramentas.
• Timestampagem: Conforme observado, o ator usa comandos de toque ou outros métodos para alterar os registros de data e hora de seus arquivos, fazendo com que pareçam arquivos antigos do sistema para enganar a análise forense.

‍

O ciclo de vida completo do ataque: anatomia de uma conquista

A operação do STATUS TA-NATAL não é um esquema simples de “infectar e minar”. Em vez disso, é um ciclo de vida de quatro estágios meticulosamente elaborado para resiliência, discrição e domínio total sobre sistemas comprometidos. Antes de mergulhar na arquitetura de quatro estágios, é essencial explorar o vetor de acesso inicial—um método aparentemente simples, mas altamente eficaz, que aproveita configurações incorretas em vez de explorações.

‍

Acesso inicial: técnica “Root by Inheritance”

O malware não aumenta os privilégios. Nasce com acesso root explorando um servidor Redis que foi iniciado de forma insegura como usuário root. Este ataque é baseado inteiramente em comandos legítimos do Redis, usado maliciosamente.

‍

Sequência de exploração

1. O escaneamento
   O atacante usa ferramentas como o masscan para escanear a Internet em busca de servidores Redis não autenticados e expostos publicamente na porta 6379.
2. A carga
   Quando um servidor Redis vulnerável é encontrado, o atacante envia uma sequência de comandos de configuração. Essas não são explorações, mas operações legítimas do Redis usadas para manipular o servidor.

‍

A decepção (o truque principal)
O atacante executa a seguinte sequência:

‍

• CONFIG SET dir /var/spool/cron/: redireciona o diretório do banco de dados Redis para a pasta cron do sistema.
• CONFIG SET dbfilename root: define o nome do arquivo do banco de dados Redis como root. No Linux, isso se torna /var/spool/cron/root, o crontab do usuário root.
• SET backup1: injeta um cron job malicioso (executado a cada 2 minutos) que baixa e executa o malware.
• SALVAR: Força o Redis a gravar seu conjunto de dados atual na memória (contendo o cron job) no disco como /var/spool/cron/root.
  
  

3. Gatilho de execução
   O daemon cron do sistema lê o novo arquivo /var/spool/cron/root e executa o cron job inserido como usuário root. Isso inicia o download e a execução do script de malware (ndt.sh) com privilégios totais.

‍

Por que isso funciona

• Redis, quando executado como o usuário root, tem permissão para gravar diretamente em diretórios críticos do sistema.
• Isso possibilita que o atacante “herdar” privilégios de root sem nenhuma técnica tradicional de escalonamento de privilégios.
• Se o Redis estivesse sendo executado como um usuário não privilegiado, esse ataque falharia na etapa de gravação do arquivo, pois esse usuário não teria permissões para acessar /var/spool/cron/.

‍

Com o acesso root obtido logo no início, o malware está livre para prosseguir com o restante quatro estágios de seu ciclo de vida — cada um cuidadosamente projetado para manter a persistência, realizar reconhecimento, estabelecer controle remoto e, finalmente, executar suas metas maliciosas (como cryptojacking ou movimento lateral). Compreender esse método inicial de violação é fundamental para avaliar a abordagem disciplinada, pragmática e tecnicamente eficiente.

‍

Etapa 1: Implantação - A aquisição silenciosa (ndt.sh/nnt.sh)

Esse estágio inicial vai muito além do lançamento de uma carga útil. É um desmantelamento sistemático das defesas do hospedeiro para uma ocupação de longo prazo.

• Sabotagem sistêmica: Antes que qualquer carga seja descartada, o script executa uma série de ações de “administrador de sistema hostil”, incluindo a desativação do SELinux (setenforce 0), o aumento massivo do limite do descritor de arquivo (ulimit -n 65535) e a destruição dos firewalls do host (iptables -F).
• Evasão comportamental - The ps Hijack: O script renomeia o binário ps legítimo para ps.original e o substitui por um invólucro malicioso que executa o comando original, mas envia o resultado por meio de grep -v, filtrando explicitamente os nomes de seu próprio minerador (httpgd) e scanner (pnscan). A principal ferramenta do administrador para visibilidade do processo agora está mentindo ativamente para eles.
• A técnica de “trancar a porta atrás de você”: Após o comprometimento, o ator adiciona uma regra iptables para bloquear tudo futuro conexões externas à porta Redis (6379), fechando efetivamente a porta usada para entrar e impedindo que os rivais usem a mesma vulnerabilidade.
• A Guerra do TerritÓRIO: O script executa sua enorme “lista de mortes” (consulte o Apêndice), encerrando dezenas de processos associados a campanhas concorrentes de cryptojacking, como Kinsing e DDG, para garantir que 100% dos recursos de CPU do host sejam dedicados ao minerador.

‍

‍

Etapa 2: Preparação - Forjando as armas (is.sh)

Um hospedeiro conquistado só é útil se puder ser usado para encontrar novas vítimas. O script is.sh é um “preparador de guerra” dedicado, projetado para armar o host. Em uma tática fundamental de resiliência, se ferramentas como 'massacra' ou 'pnscan' não pode ser instalado por meio do gerenciador de pacotes, o script baixa seu código-fonte diretamente do servidor C2 e o compila do zero na máquina vítima.

‍

Estágio 3: Propagação - Liberando a Horda (rs.sh)

Uma vez armado, o hospedeiro é transformado em soldado da botnet, usando uma estratégia de escaneamento sofisticada e multifacetada. O elemento mais crítico é o uso de 'masscan --shard'. Cada bot recebe uma fatia aleatória de todo o espaço de endereço IPv4 para escanear. Esse modelo distribuído permite que a botnet como um todo cubra a Internet de forma incrivelmente rápida, sem que nenhum bot gere tráfego suficiente para acionar bloqueios no nível da rede.

‍

Estágio 4: Persistência - A barata impossível de matar (nnt.sh e chattr)

O estágio final garante que o controle do ator seja permanente. Um cron job de hora em hora chama um script de atualização (nnt.sh) que funciona como um “interruptor de pessoa morta”, reinstalando todo o pacote de malware se alguma parte for removida. Para finalizar o bloqueio, o script usa 'chattr +i' para tornar seus arquivos principais e a chave SSH backdoor imutáveis. Isso evita que os arquivos sejam excluídos ou modificados, mesmo pelo usuário root, causando imensa confusão para os administradores que estão tentando fazer uma limpeza.

Como verificar se você está infectado

Se você suspeitar de uma infecção, não confie apenas no ps ou no top. Execute essas verificações na linha de comando.

Verificação 1: Procure binários sequestrados
Execute esse comando. Se você ver qualquer saída, você provavelmente está comprometido.

Verificação 2: Procure trabalhos maliciosos no Cron
O ator oculta sua atividade redirecionando a saída para /dev/null. Pesquise esse padrão em todas as localizações do cron.

Procure trabalhos suspeitos, especialmente aqueles que executam scripts como nnt.sh ou ndt.sh.

‍

Verificação 3: Verifique se há arquivos imutáveis
O ator bloqueia seus arquivos com chattr +i. Execute lsattr nos caminhos comuns de arquivos de malware. Se você ver um atributo i, é uma grande bandeira vermelha.

Verificação 4: Verifique o backdoor SSH
Essa é a verificação mais crítica. O ator obtém acesso permanente com uma chave SSH. Verifique seu arquivo authorized_keys para ver seu comentário-chave específico, uc1.

Como remover o minerador e remediar

Simplesmente excluir o binário do minerador não é suficiente. Você deve desmontar todo o mecanismo de persistência.

⚠️ AVISO: O único método seguro 100% garantido é isolar o host, recuperar todos os dados necessários e recriá-los a partir de um backup confiável e em boas condições. Se você não conseguir refazer a imagem, siga estas etapas por sua conta e risco.

Etapa 1: Isolar o host
Remova imediatamente a máquina da rede desativando sua interface de rede ou aplicando regras estritas de firewall.

Etapa 2: Desativar o mecanismo de persistência (desbloquear e excluir tarefas Cron)
Desbloqueie os arquivos cron bloqueados antes de excluir as entradas maliciosas.

Etapa 3: Elimine os processos maliciosos
Como o ps foi invadido, use o binário original.

Etapa 4: Remova o malware e o backdoor
Desbloqueie os arquivos imutáveis antes de excluí-los.

Etapa 5: restaurar os binários do sistema
Restaure ps, top, curl e wget ao estado original.

Etapa 6: resolver a causa raiz
Finalmente, proteja sua instância Redis. Defina uma senha forte e configure-a para escutar somente na interface local (bind 127.0.0.1). Se você não fizer isso, você será comprometido novamente.

Indicadores primários de compromisso (TA-NATALSTATUS)

Impressões digitais do ator (identificadores exclusivos)
Comentário sobre a chave SSH: uc1
Monero_Wallet: 84NW3MQDDJZrghgBePwnAtLG8Ma1EK1ITn42YUp4DPK38wnwgy7zxsr28j2n4vylspvPodCFeiJap2ntqjfegcteantrzot
Caminho do diretório de malware: /EP9ts2/

Domínios (malicioso confirmado)

natalstatus.org

a.natalstatus.org

avspbx.com

Pyats.top

pt2an.top

‍

Endereços IP (grupos de mineração e C2/maliciosos confirmados)

103,79,77,16

185,1,19,33,145

94,110,247,97

45,89,52,41

79,137,195,151

80,211,206,105

dev.fugglesoft.me (domínio de pool)

‍

Hashes de arquivo

‍

Fofa Query para identificar mais piscinas matutinas

The Kill List - Uma visão do submundo do cryptojacking

A TA-NATALSTATUS aplica uma política agressiva de “terra arrasada” contra seus rivais. Essa “lista de mortes” fornece um instantâneo em tempo real dos outros atores importantes do ecossistema de cryptojacking e pode ser usada para caçar outras infecções.

Infraestrutura rival de malware (endereços IP destinados à rescisão)

45,76,122,92

176,31,6,16

83.220,169,247

51,38,191,178

46,243,253,15

51,38,203,146

51,15.56,161

200.68,17.196

144,217,45,45

104,248,4,162

188,209,49,54

107,174,47,181

89,35,39,78

181,214,87,241

121,42,151,137

107,174,47,156

Famílias e processos rivais de malware (destinados à rescisão)

‍

‍

Referências

• https://www.trendmicro.com/en_in/research/20/d/exposed-redis-instances-abused-for-remote-code-execution-cryptocurrency-mining.html
• https://help.aliyun.com/zh/acsg/best-practices-for-handling-mining-programs?spm=a2c4g.11186623.0.i4
• https://www.cnblogs.com/skystrive/p/18879419

‍