Linodas amplia DinodasRAT em servidores Linux com persistência e módulo de evasão

A versão Linux v11 do DinodasRAT usa persistência específica para Ubuntu e Red Hat, comunicação C2 por TCP ou UDP e um módulo auxiliar capaz de mascarar artefatos em binários do sistema.

Componente	Linodas, versão Linux do backdoor multiplataforma DinodasRAT, também conhecido como XDealer, observado em servidores Linux.
Vetor	Execução inicial do implante em servidor Linux, seguida de autoconfiguração, persistência por arquivos de inicialização e conexão a C2 por TCP ou UDP conforme campo mode.
Impacto	Manutenção de acesso, enumeração do sistema, controle remoto, reverse shell, coleta de atividade de usuários, manipulação de arquivos locais e ocultação de artefatos por módulo auxiliar.
Prioridade	Inventariar servidores Linux expostos, procurar persistência em rc.local, systemd e init.d, validar binários substituídos e conter hosts com conexão ao domínio C2 defangado update.microsoft-setting[.]com na porta 443.
Versões	Amostras Linux aparecem desde pelo menos julho de 2021; a análise descreve a evolução até a versão interna V11, mais madura que versões anteriores.
Artefatos	Nomes e caminhos observados incluem ntfsys, /etc/.netsc.conf, ntfsys.so6, campo imei, seção para, parâmetros mode e checkroot.
IoCs	Exemplos essenciais: domínio C2 defangado update.microsoft-setting[.]com:443 e SHA-256 do módulo auxiliar ebdf3d3e0867b29e66d8b7570be4e6619c64fae7e1fbd052be387f736c980c8e.

Resumo técnico

Linodas é a ramificação Linux do DinodasRAT, um backdoor multiplataforma também referido como XDealer. A atividade descrita envolve um ator de ciberespionagem com nexo chinês e foco observado no Sudeste Asiático, África e América do Sul, com sobreposição operacional a campanhas atribuídas a Earth Krahang. O malware tem histórico anterior em ambientes Windows, mas a versão Linux não é apenas uma recompilação direta: a amostra V11 mostra rotinas próprias para servidores Linux, com persistência adaptada a distribuições Ubuntu e Red Hat, lógica de identificação do host, controle de comunicação C2 e um módulo separado para reduzir a visibilidade de artefatos locais.

A evolução interna indica que o projeto Linux já existia pelo menos desde julho de 2021, quando uma amostra marcada como V7 foi vista em ambiente real. A versão V11 mantém semelhanças funcionais com o ramo Windows, inclusive comandos C2 sobrepostos, mas introduz recursos voltados ao modelo operacional de servidores Linux. Entre eles estão verificação de privilégios, ajuste de carimbos de data em arquivos relacionados ao implante, criação de identificador persistente do bot, monitoramento de usuários logados, limpeza de sessões antigas de reverse shell e implantação de um módulo que intercepta a execução de utilitários do sistema para controlar a saída apresentada ao operador local.

Fluxo técnico

Após ser iniciado, o backdoor verifica se recebeu dois argumentos esperados: a letra d e o identificador do processo daemon chamador. Quando esses parâmetros não estão presentes, o binário entra em uma rotina de daemonização, estabelece persistência e reinicia a própria execução com os argumentos esperados. Esse desenho separa a primeira execução, usada para preparar o ambiente, da execução operacional, em que o implante passa a carregar configuração, monitorar o sistema e iniciar a comunicação com o servidor de comando e controle.

A persistência é escolhida conforme a distribuição identificada por arquivos do sistema como /proc/version e /etc/lsb-release. Em Ubuntu, o malware trabalha com rc.local mediado por systemd, criando ou alterando artefatos relacionados a /lib/systemd/system/rc.local.service, /etc/systemd/system/ e /etc/rc.local. Em Red Hat, há dois caminhos: criação de script em /etc/init.d/ com registro no mecanismo de inicialização, ou alteração de /etc/rc.d/rc.local quando esse arquivo está disponível. Em todos os casos, o objetivo é garantir que o implante seja chamado após reinicializações do host.

Na fase de configuração, o malware lê /etc/.netsc.conf, normalmente como arquivo oculto. A seção para contém valores usados no comportamento do implante, incluindo imei, mode e checkroot. O campo imei representa o identificador do bot; quando ele não existe, o malware gera uma identificação no formato Linux_[TIMESTAMP]_[MD5SUM]_[RANDOM NUMBER]_V11, combinando data, material derivado de parâmetros da máquina e número aleatório. O mesmo arquivo de configuração recebe alteração de timestamp para parecer antigo no sistema de arquivos, uma técnica também aplicada a outros artefatos do implante.

A comunicação C2 usa o endereço hardcoded update.microsoft-setting[.]com:443, com resolução do domínio para IPv4 quando necessário. O parâmetro mode define se a conexão será TCP ou UDP, enquanto checkroot influencia o monitoramento de usuários logados. Quando as condições internas permitem, o backdoor abre socket, conecta ao C2 e cria uma thread dedicada ao processamento de comandos. Em seguida, mantém um ciclo contínuo de heartbeat que envia informações separadas por tabulação, permitindo ao operador acompanhar estado do host, versão, arquitetura e outros metadados coletados.

A versão V11 também cria cinco threads auxiliares. Uma monitora usuários logados e pode encerrar a comunicação C2 quando identifica acesso remoto que não corresponde a IP local ou ao C2. Outra observa inatividade da conexão e fecha o canal quando passa cerca de meia hora sem requisições válidas. Uma terceira baixa e prepara o módulo de filtragem. A quarta registra detalhes de usuários conectados cujo IPv4 não seja local nem pertença ao C2. A quinta remove sessões antigas de reverse shell que ficaram sem atividade por quase uma hora.

Superfície afetada

A superfície principal são servidores Linux nos quais o operador conseguiu executar o binário inicial. O contexto não descreve o vetor de acesso inicial, portanto a análise defensiva deve tratar Linodas como implante pós-comprometimento: ele depende de execução no host e, para algumas ações de persistência e alteração de binários, de permissões suficientes para escrever em diretórios sensíveis do sistema. O nome ntfsys aparece em várias amostras e sugere tentativa de camuflagem como componente relacionado a NTFS, embora o comportamento real seja de backdoor.

Ambientes Ubuntu e Red Hat exigem atenção distinta porque o malware implementa caminhos de persistência compatíveis com ambos. Servidores com mecanismos legados de inicialização ainda ativos, arquivos rc.local habilitados ou permissões permissivas em scripts de boot ficam mais expostos à persistência silenciosa. O módulo auxiliar ntfsys.so6, identificado pelo SHA-256 informado nos fatos, amplia o risco porque substitui ou envolve binários usados para inspeção do sistema, como who, netstat e ps, podendo remover da saída nomes de processo, endereços IP, usuários ou outros artefatos vinculados ao implante.

A cadeia também afeta processos de monitoramento que confiam apenas na saída de utilitários locais. Se o operador do host usa comandos do próprio sistema para verificar conexões, processos e sessões, o módulo de filtragem pode alterar a visão apresentada. Essa característica não torna o host invisível em fontes externas de telemetria, mas reduz a confiabilidade de inspeções locais sem verificação de integridade dos binários e sem coleta independente de EDR, logs centralizados, sensores de rede ou imagens forenses.

• Servidores Linux com execução do binário ntfsys ou artefatos ocultos relacionados a /etc/.netsc.conf.
• Hosts Ubuntu com alterações em rc.local, systemd e arquivos de inicialização associados.
• Hosts Red Hat com scripts inesperados em /etc/init.d/ ou mudanças em /etc/rc.d/rc.local.
• Ambientes em que utilitários como who, netstat e ps possam ter sido substituídos, envolvidos por módulo auxiliar ou apresentar saída inconsistente.

Hunting e telemetria

A investigação deve começar pela combinação de persistência, comunicação de rede e integridade de binários. Em disco, procure arquivos ocultos com perfil de configuração em /etc/, especialmente /etc/.netsc.conf, e verifique campos compatíveis com para, imei, mode e checkroot. A presença de identificadores no padrão Linux_..._V11 em arquivos de configuração, memória de processo, strings de binário ou registros de EDR é um sinal forte de relação com essa família. O nome ntfsys também merece análise quando aparece fora de contexto esperado.

Na rede, a prioridade é revisar conexões históricas e tentativas DNS para o domínio C2 defangado update.microsoft-setting[.]com, especialmente na porta 443. A ausência de tráfego atual não encerra a investigação, porque o implante pode fechar o canal quando detecta determinadas condições de usuário logado ou quando a conexão fica sem atividade. Logs de proxy, firewall, DNS recursivo, NetFlow e EDR devem ser correlacionados com janelas de boot, criação de serviços e alterações de arquivos sensíveis.

No endpoint, compare hashes, tamanhos, metadados e timestamps de utilitários comuns. O ajuste artificial de data para arquivos do implante significa que a linha do tempo deve considerar discrepâncias entre mtime, ctime, eventos do journal, registros de pacote e telemetria do agente de segurança. A substituição de binários ou o uso de wrappers pode gerar diferenças entre o que o utilitário local mostra e o que sensores externos registram. Essa divergência é uma pista importante em hosts Linux usados como pivô ou ponto de permanência.

• Consultas DNS, conexões TCP ou UDP e registros de proxy envolvendo update.microsoft-setting[.]com na porta 443, mantendo o indicador defangado em relatórios.
• Arquivos de inicialização alterados em rc.local, systemd, /etc/init.d/ e /etc/rc.d/rc.local com referência a binários fora do padrão.
• Configuração oculta /etc/.netsc.conf com seção para e campos imei, mode ou checkroot.
• Processos ou arquivos chamados ntfsys e módulo ntfsys.so6, inclusive o SHA-256 ebdf3d3e0867b29e66d8b7570be4e6619c64fae7e1fbd052be387f736c980c8e.
• Diferença entre saída local de who, netstat ou ps e dados obtidos por EDR, kernel audit, inventário de pacotes ou telemetria de rede.

Mitigação

A resposta deve tratar o host afetado como comprometido enquanto houver evidência de execução do implante, persistência ou módulo de filtragem. O primeiro passo defensivo é isolar a máquina da rede de produção sem desligá-la de imediato, quando a preservação for necessária, para manter memória, conexões e processos disponíveis à coleta. Em seguida, colete artefatos de disco, memória e logs centralizados antes de remover arquivos, porque o backdoor altera timestamps e pode ter mascarado evidências em utilitários locais.

A contenção exige remover persistências em systemd, rc.local e init.d, restaurar binários do sistema a partir de pacotes confiáveis e validar permissões de arquivos de inicialização. Como o módulo de filtragem pode afetar a visibilidade local, a verificação deve usar fontes externas ou mídia confiável sempre que possível. Bloqueios de rede para o domínio C2 defangado e para a porta usada reduzem comunicação, mas não substituem erradicação, já que a presença local do implante mantém risco de reativação por outro canal se o operador ainda tiver acesso ao ambiente.

Após a limpeza, revise o caminho provável de acesso inicial, mesmo que ele não esteja descrito no contexto técnico. Isso inclui chaves SSH, contas administrativas, serviços expostos, credenciais de automação, tarefas agendadas, permissões de escrita em diretórios sensíveis e cobertura de EDR em Linux. A rotação de credenciais deve priorizar contas usadas no host, segredos acessíveis por processos locais e tokens de automação que possam ter sido lidos por um operador com shell remoto. A validação final precisa confirmar que não há novos heartbeats, persistências reintroduzidas ou diferenças persistentes entre telemetria local e externa.

• Isolar hosts com evidência de Linodas e preservar memória, logs e artefatos antes da remoção.
• Restaurar utilitários do sistema por fonte confiável e validar integridade de who, netstat, ps e binários relacionados.
• Remover entradas indevidas em rc.local, systemd, /etc/init.d/ e /etc/rc.d/rc.local.
• Bloquear e monitorar comunicação com update.microsoft-setting[.]com:443 usando indicador defangado em documentação interna.
• Revisar contas, chaves SSH, tokens de automação e permissões locais acessíveis ao servidor comprometido.
• Aumentar cobertura de auditoria em Linux, incluindo logs centralizados, verificação de integridade, detecção de alterações em boot scripts e comparação com telemetria de rede.