Variante do Mirai explora `CVE-2024-3721` para incluir DVRs TBK em botnet de DDoS

A atividade usa injeção de comandos em DVRs TBK para entregar o Nexcorium, com suporte a múltiplas arquiteturas Linux, persistência local, brute force por Telnet e módulos de ataque DDoS.

Componente	DVRs digitais TBK DVR-4104 e TBK DVR-4216, além de roteadores IoT antigos citados na mesma atividade de botnets baseadas no Mirai.
Vetor	Exploração da injeção de comandos CVE-2024-3721 para obter um script de download, selecionar o binário pela arquitetura Linux do dispositivo e executar o malware Nexcorium.
Impacto	Inclusão do dispositivo em botnet com persistência, força bruta por Telnet, tentativa de expansão para outros equipamentos e capacidade de receber comandos para ataques DDoS por UDP, TCP e SMTP.
Prioridade	Remover DVRs e roteadores IoT expostos sem correção, trocar credenciais padrão, bloquear administração remota desnecessária e procurar execução anômala de scripts, serviços persistentes e conexões externas do dispositivo.
Artefatos	Nexcorium usa tabela de configuração codificada por XOR, módulo de watchdog, módulo DDoS, persistência via crontab e serviço systemd, e remoção do binário baixado após a instalação.
Versões e falhas relacionadas	A campanha também cita exploração ou tentativa de exploração de CVE-2017-17215, CVE-2023-33538, CVE-2025-29635, CVE-2023-1389 e um exploit RCE para roteador ZTE ZXV10 H108L, conforme os casos descritos no contexto.

Resumo técnico

Uma variante de botnet baseada no Mirai, identificada como Nexcorium, está sendo entregue contra DVRs TBK por meio da vulnerabilidade CVE-2024-3721. A falha é uma injeção de comandos de severidade média que afeta os modelos TBK DVR-4104 e TBK DVR-4216. O fluxo observado começa com a execução de comandos no dispositivo vulnerável, passa pela obtenção de um script de download e termina com a escolha de um binário compatível com a arquitetura Linux encontrada no equipamento. Depois da execução, o malware confirma o controle do ambiente comprometido com uma mensagem própria e inicia rotinas típicas de botnets IoT.

O caso reforça um padrão recorrente em dispositivos de gravação, roteadores domésticos e equipamentos IoT sem manutenção ativa: falhas conhecidas, credenciais fracas e interfaces administrativas expostas continuam sendo suficientes para alimentar botnets de negação de serviço distribuída. O Nexcorium não depende apenas da falha inicial nos DVRs TBK. Ele incorpora lógica de expansão, força bruta por Telnet, mecanismos de persistência e um módulo de ataque DDoS. A combinação torna o dispositivo comprometido um ponto de execução de tráfego abusivo, mas também um pivô para procurar outros equipamentos acessíveis a partir da mesma rede.

Fluxo técnico

A exploração de CVE-2024-3721 permite que o operador injete comandos no DVR afetado e use esse acesso para recuperar um script auxiliar. Esse script funciona como etapa intermediária: ele identifica a arquitetura do sistema Linux embarcado e seleciona a carga correspondente, evitando uma única amostra incompatível com parte dos alvos. Esse desenho é comum em botnets IoT porque o ecossistema inclui processadores e builds diferentes, e a taxa de infecção depende da capacidade de entregar um binário executável para cada plataforma encontrada. O conteúdo recebido também indica que o Nexcorium reutiliza características estruturais associadas ao Mirai, incluindo inicialização de tabela de configuração codificada por XOR, componente de watchdog e módulo de DDoS.

Após a execução, o Nexcorium tenta ampliar a presença no ambiente. O malware inclui um exploit para CVE-2017-17215, voltado a dispositivos Huawei HG532, e mantém uma lista fixa de nomes de usuário e senhas para tentativas de autenticação em hosts acessíveis por Telnet. Quando uma tentativa de login funciona, ele busca obter um shell e criar persistência por crontab e por serviço systemd. Em seguida, conecta-se a um servidor externo para aguardar instruções de ataque, com suporte a DDoS por UDP, TCP e SMTP. Depois de instalar a persistência, o binário originalmente baixado é removido, reduzindo a quantidade de artefatos simples no sistema de arquivos e dificultando análise baseada apenas no arquivo inicial.

Superfície afetada

A superfície imediata envolve DVRs TBK DVR-4104 e TBK DVR-4216 vulneráveis à CVE-2024-3721, especialmente quando acessíveis pela internet ou por segmentos internos pouco controlados. A atividade descrita também se conecta a um cenário mais amplo de exploração de hardware IoT antigo ou em fim de vida. Foram citadas sondagens automatizadas contra roteadores sem fio TP-Link afetados por CVE-2023-33538, com a observação de que a exploração bem-sucedida dessa falha exige autenticação na interface web do roteador. O mesmo conjunto de casos inclui exploração de CVE-2025-29635 em roteadores D-Link DIR-823X em fim de vida para distribuir uma variante do Mirai chamada tuxnokill, além de tentativas relacionadas a CVE-2023-1389 em TP-Link Archer AX21 e a um exploit RCE para ZTE ZXV10 H108L.

Nem toda tentativa descrita resulta em comprometimento. No caso de CVE-2023-33538, as sondagens observadas usavam uma abordagem falha, mas a vulnerabilidade subjacente foi confirmada como real e a falha já aparecia no catálogo de vulnerabilidades exploradas conhecidas da agência norte-americana de segurança cibernética desde junho de 2025. Esse detalhe é importante para defesa: tráfego malformado ou tentativas que falham ainda indicam interesse ativo em uma classe de equipamento e podem preceder correções na lógica do atacante. Em ambientes com dispositivos antigos, a ausência de suporte do fabricante limita a resposta a substituição, isolamento, desativação de serviços e revisão rigorosa de credenciais.

• TBK DVR-4104 e TBK DVR-4216 expostos à exploração de CVE-2024-3721.
• Dispositivos Huawei HG532 alcançáveis a partir do equipamento infectado, devido ao exploit embutido para CVE-2017-17215.
• Roteadores TP-Link em fim de vida ou com interface web autenticável, especialmente quando ainda mantêm credenciais padrão ou fracas.
• Roteadores D-Link DIR-823X, TP-Link Archer AX21 e ZTE ZXV10 H108L aparecem em atividades relacionadas de botnets Mirai-like.

Hunting e telemetria

A investigação deve combinar logs de borda, telemetria de rede, inventário de ativos e sinais locais dos dispositivos quando houver acesso administrativo. Em rede, os pontos mais úteis são conexões de saída incomuns a partir de DVRs e roteadores, aumento de tráfego UDP, TCP ou SMTP não compatível com a função normal do equipamento e tentativas repetidas de Telnet contra hosts internos. Como o Nexcorium tenta autenticação com credenciais fixas, falhas de login em massa, conexões curtas e sequência de tentativas contra múltiplos endereços podem indicar varredura lateral. Em ambientes que coletam NetFlow, DNS ou logs de firewall, DVRs iniciando conexões externas persistentes ou tráfego de alto volume devem ser tratados como anomalia forte.

No endpoint embarcado, quando a administração do equipamento permite inspeção, a defesa deve procurar alterações em crontab, criação de serviços systemd não esperados, processos que não pertencem ao firmware conhecido e evidências de scripts temporários usados para baixar binários por arquitetura. A remoção do binário inicial significa que a ausência do arquivo de download não encerra a análise. Persistência, processo em memória, conexões externas e alterações de inicialização têm mais valor do que procurar apenas uma amostra específica. Para roteadores em fim de vida, a telemetria pode ser limitada; por isso, o inventário e o bloqueio de exposição administrativa são parte essencial da detecção.

• DVR ou roteador iniciando tráfego UDP, TCP ou SMTP em volume incompatível com sua função operacional.
• Tentativas de autenticação por Telnet originadas de dispositivos IoT internos contra múltiplos hosts.
• Novas entradas em crontab ou serviços systemd persistentes em equipamentos que normalmente não recebem alterações manuais.
• Execução de script de download seguida por binário ajustado à arquitetura Linux do dispositivo.
• Sondagens contra rotas administrativas de DVRs e roteadores antigos, mesmo quando a tentativa observada não consegue explorar a falha.

Mitigação

A resposta deve começar pelo inventário dos modelos afetados e pela remoção da exposição direta de interfaces administrativas. DVRs TBK DVR-4104 e TBK DVR-4216 vulneráveis à CVE-2024-3721 não devem permanecer acessíveis pela internet ou por redes amplas sem controle. Quando houver atualização de firmware aplicável, ela deve ser priorizada; quando o equipamento estiver fora de suporte ou não houver correção disponível, a medida defensiva mais consistente é substituir o ativo ou isolá-lo em segmento restrito, com regras explícitas de saída. Roteadores TP-Link em fim de vida citados no contexto exigem substituição por modelo suportado, já que a continuidade operacional sem atualização mantém a superfície explorável.

Credenciais padrão precisam ser eliminadas, mas a troca de senha isolada não corrige a cadeia completa. O Nexcorium combina exploração de vulnerabilidade, força bruta, persistência e comunicação com servidor externo, portanto a contenção deve incluir bloqueio de Telnet desnecessário, restrição de tráfego de saída, revisão de serviços persistentes e reinicialização controlada após limpeza ou reinstalação de firmware confiável. Quando houver suspeita de comprometimento, a rede deve ser observada para identificar outros dispositivos que receberam tentativas de login ou exploração a partir do primeiro ativo. Como botnets baseadas no Mirai costumam reutilizar código, módulos e infraestrutura de maneira oportunista, a defesa deve tratar o incidente como problema de classe de ativo, não apenas como uma amostra única.

• Atualizar ou retirar de produção DVRs TBK afetados por CVE-2024-3721; quando não houver correção, isolar ou substituir o equipamento.
• Substituir roteadores em fim de vida citados na atividade, principalmente modelos sem suporte ativo e com administração remota exposta.
• Remover credenciais padrão, revisar senhas fracas e desabilitar Telnet sempre que o serviço não for indispensável.
• Bloquear conexões externas não necessárias a partir de segmentos IoT e monitorar tentativas de DDoS por UDP, TCP e SMTP.
• Verificar persistência em crontab e systemd, processos anômalos e artefatos de download antes de recolocar o dispositivo em operação.