Lucifer evolui para malware multiplataforma com mineração, DDoS e foco em IoT

Campanha associada a Rudeminer e BlackSquid passou de propagação em Windows para variantes Linux, ARM e MIPS, explorando roteadores Dasan GPON sem correção e ampliando capacidades de controle, mineração de Monero e ataques DDoS.

Componente	Malware Lucifer, com variantes para Windows, Linux, ARM e MIPS, associado tecnicamente a amostras das campanhas Rudeminer, Spreadminer e BlackSquid por reutilização de carteiras XMR e semelhança de código.
Vetor	Exploração de sistemas sem correção, brute force e, em IoT, uso da vulnerabilidade CVE-2018-10561 contra roteadores Dasan GPON não atualizados.
Impacto	Mineração de Monero com Xmrig, execução remota de comandos, download e execução de arquivos, operação por C2, autopropagação em Windows e ataques DDoS em variantes Linux, ARM e MIPS.
Prioridade	Corrigir dispositivos GPON vulneráveis, reduzir exposição de serviços, revisar senhas fracas, procurar persistência em Linux e IoT e investigar conexões para C2, incluindo o domínio defangado tyz2020[.]top.
Versões e arquiteturas	Windows mantém recursos de autopropagação; Linux x86/x64 adiciona execução como daemon, persistência e C2; ARM e MIPS aparecem como versões mais simples com foco em DDoS.
Artefatos	Amostras recentes incluem binários Windows, Linux, ARM e MIPS; algumas variantes Linux, ARM e MIPS não foram removidas de símbolos de depuração, permitindo associar partes de DDoS ao programa chinês Storm Attack Tool VIP 2009.

Resumo técnico

Lucifer começou como um minerador para Windows com capacidade de autopropagação e evoluiu para uma família de malware com suporte a múltiplas plataformas e arquiteturas. A operação observada inclui versões para Windows, Linux, ARM e MIPS, com funções que combinam monetização por mineração de Monero, controle remoto, execução de arquivos e ataques distribuídos de negação de serviço. A mudança amplia a superfície de ataque porque tira a campanha do ambiente tradicional de estáções e servidores Windows e a leva para servidores Linux e dispositivos IoT, onde o ciclo de atualização costuma ser mais lento e a visibilidade operacional é menor.

A campanha apresenta vínculos técnicos com atividades conhecidas como BlackSquid, Rudeminer e Spreadminer. A relação foi estabelecida por semelhanças entre amostras, padrões de mutex e uso de carteiras XMR compartilhadas ou relacionadas. A trilha financeira indica atividade desde o fim de 2018, enquanto amostras da campanha mais recente começaram a aparecer em fevereiro de 2020. Dados de telemetria mostram ocorrências recentes em mais de 25 organizações nos Estados Unidos, Irlanda, Países Baixos, Turquia e Índia, atingindo setores como manufatura, jurídico, seguros e bancos.

O vetor principal citado para dispositivos IoT é a exploração de CVE-2018-10561, uma vulnerabilidade associada a roteadores Dasan GPON sem atualização. Em Windows, a autopropagação depende de exploits públicos antigos e brute force, o que sugere abuso de ambientes com correções atrasadas e política de senha fraca. Nas variantes Linux, ARM e MIPS, o foco técnico se desloca para execução como serviço em segundo plano, persistência e capacidade de manter conexões com infraestrutura de comando e controle, com diferenças relevantes entre arquiteturas.

Fluxo técnico

A cadeia de infecção parte de servidores comprometidos usados pelo operador como origem dos ataques. Após a execução em Windows, a máquina infectada pode tentar continuar a propagação dentro da rede e contra alvos remotos, usando técnicas já públicas e tentativa de autenticação por força bruta. Esse comportamento torna ambientes legados especialmente expostos: a campanha não depende de um zero-day novo no Windows, mas de lacunas persistentes de higiene operacional, como sistemas sem patch, credenciais fracas e serviços acessíveis além do necessário.

No Linux x86/x64, a amostra analisada não inclui autopropagação. Depois de obter execução, o malware se desacopla do terminal e passa a rodar em segundo plano como daemon. Em seguida, tenta criar um socket e associá-lo a uma porta; na versão mais recente descrita, a porta usada é 20580. O objetivo observado desse bind não é receber comunicação de rede, pois não há chamada para escuta posterior, mas impedir múltiplas instâncias simultâneas do próprio malware no mesmo host. Se o bind falha, o processo encerra, usando a porta como mecanismo de exclusão mútua.

A persistência em Linux envolve tentativa de ativar agendamento periódico e alteração de inicialização local. O malware tenta configurar serviços associados ao cron em distribuições baseadas em CentOS ou RHEL, embora uma das tentativas contenha erro de sintaxe. Também pode modificar /etc/rc.local e adicionar execução recorrente no crontab para relançar o binário. Quando executado como root, tenta elevar o limite de descritores de arquivo para abrir mais sockets durante ataques DDoS; quando não tem privilégio de root, usa limites menores. Essa diferença importa para resposta a incidente, porque uma execução sem root ainda pode degradar rede, mas a execução privilegiada aumenta persistência e capacidade de tráfego.

As variantes ARM e MIPS são mais simples que a versão Linux completa. Elas mantêm inicialização semelhante, execução em segundo plano, controle de instância única por bind de socket e configuração de manipulador para SIGPIPE. O domínio C2 observado nessas versões é tyz2020[.]top. Em dispositivos IoT, as amostras interagem com /dev/watchdog ou /dev/misc/watchdog quando disponíveis, ajustando o tempo limite e enviando sinais periódicos de manutenção. Esse recurso impede reinicializações automáticas acionadas pelo watchdog do dispositivo, preservando a permanência do processo durante operação maliciosa.

As capacidades de DDoS nas versões mais recentes foram relacionadas a código de um programa chinês de 2009 chamado Storm Attack Tool VIP 2009. O restante do malware foi modificado para funções adicionais, incluindo operação por C2, mineração de Monero, autopropagação em Windows e adaptação para Linux e IoT. A presença de executáveis associados a variantes de gh0st RAT em um servidor HFS acessível publicamente sugere intenção de ampliar capacidades em máquinas já comprometidas, embora a análise disponível sustente apenas a observação desses artefatos no repositório da campanha, não sua execução confirmada em todos os ambientes atingidos.

Superfície afetada

A superfície exposta inclui sistemas Windows que permanecem vulneráveis a técnicas públicas antigas, servidores ou estáções com credenciais fracas e dispositivos IoT com firmware sem atualização. O caso mais concreto em IoT é o roteador Dasan GPON afetado por CVE-2018-10561. Como a campanha usa servidores comprometidos como ponto de origem, bloqueios baseados apenas em reputação estática podem perder parte da atividade, especialmente quando a infraestrutura muda ou quando o tráfego sai de endereços previamente legítimos.

Em Linux, os sinais mais relevantes estão em hosts que permitem execução de binários externos, persistência por inicialização local e alterações de agendamento. A tentativa de aumentar descritores de arquivo também conecta a infecção ao objetivo de DDoS, pois muitos sockets simultâneos ampliam a capacidade de gerar tráfego. Em ARM e MIPS, o impacto se concentra em dispositivos com pouca telemetria nativa, onde processos em segundo plano, alterações no watchdog e conexões persistentes com C2 podem passar despercebidos por longos períodos.

A atividade observada não se limita a um setor. A telemetria citada inclui mais de 25 organizações em países distintos e domínios como manufatura, jurídico, seguros e bancos. Essa diversidade indica uma campanha oportunista guiada por exposição técnica, e não por um único alvo vertical. O risco operacional é maior em ambientes que misturam estáções Windows, servidores Linux e IoT sem segmentação, porque a campanha combina propagação, execução remota e DDoS em uma mesma operação.

• Roteadores Dasan GPON sem correção para CVE-2018-10561.
• Hosts Windows com patches atrasados e serviços sujeitos a brute force.
• Servidores Linux onde alterações em /etc/rc.local, cron e limites de descritores de arquivo não são monitoradas.
• Dispositivos ARM e MIPS com watchdog acessível e baixa visibilidade de processos.

Hunting e telemetria

A investigação deve priorizar sinais de execução persistente, comunicação C2 e comportamento de mineração ou DDoS. Em Linux, procure processos desconhecidos que se comportem como daemon, tentem manter uma única instância via bind de porta e façam conexões persistentes para fora. O uso da porta 20580 como bind local, quando visto em conjunto com binário suspeito, persistência e aumento de limites de descritores, é um sinal relevante. Isoladamente, uma porta não confirma infecção; a correlação com processo, caminho do executável, histórico de criação e conexões de saída é necessária.

Em IoT, a telemetria costuma ser limitada, então o hunting deve combinar inventário, firmware, exposição externa e tráfego de rede. O domínio defangado tyz2020[.]top aparece como C2 nas variantes ARM e MIPS e deve ser tratado como indicador para pesquisa histórica, bloqueio e investigação de resolução DNS, sem uso como link ativo. Também vale procurar padrões de tráfego compatíveis com DDoS saindo de dispositivos que normalmente geram pouco volume, além de conexões persistentes incomuns após exploração de equipamento GPON.

Em Windows, a atenção deve ir para sinais de autopropagação e mineração. A campanha usa Xmrig para mineração de Monero, então eventos de execução de mineradores, uso elevado de CPU, criação de processos a partir de diretórios incomuns e conexões para pools de mineração devem ser correlacionados com tentativas de autenticação, exploração de serviços antigos e movimentação de arquivos baixados por C2. A reutilização de carteiras XMR foi importante para relacionar campanhas, mas endereços de carteira não devem ser usados como único critério de detecção, porque operadores podem trocá-los sem alterar a cadeia principal.

• Conexões DNS ou HTTP históricas para tyz2020[.]top, sempre tratadas de forma defangada em relatórios internos.
• Processos Linux persistentes iniciados por cron ou /etc/rc.local com bind local em porta incomum, incluindo 20580 quando correlacionado com outros sinais.
• Alterações de limite de descritores de arquivo seguidas de alto volume de sockets de saída.
• Atividade de mineração compatível com Xmrig, uso anômalo de CPU e comunicação com pools XMR.
• Interação anormal com /dev/watchdog ou /dev/misc/watchdog em dispositivos ARM ou MIPS.
• Alguns hashes associados às amostras podem apoiar triagem, como 53c2a0f3c3775111cbf8c09cd685e44a434bdd2d4dc0b9af18266083fb4b41e8, 82934ed1f42986bdad8e78049e27fcb0b8e43a5b0b9332aa913b901c7344cbc6 e a amostra ARM 3ea56bcf897cb8909869e1bfc35f47e1c8a454dd891c5396942c1255aa09b0ce.

Mitigação

A primeira ação defensiva é eliminar as condições exploradas pela campanha. Dispositivos Dasan GPON afetados por CVE-2018-10561 devem ser corrigidos, substituídos ou isolados quando não houver atualização disponível. Serviços expostos desnecessariamente precisam ser removidos da internet, e autenticações sujeitas a brute force devem receber senhas fortes, bloqueio por tentativa, monitoramento e, quando aplicável, autenticação multifator. Em Windows, a correção de vulnerabilidades antigas é tão importante quanto a contenção do binário, porque a campanha depende da permanência de falhas públicas em produção.

Em hosts Linux, a resposta deve validar persistência antes de remover artefatos. Revise entradas de cron, conteúdo de /etc/rc.local, processos que se reiniciam, binários recém-criados, mudanças em limites de descritores e conexões externas persistentes. A remoção deve ser feita com o host isolado ou com controles de saída aplicados, para evitar que o C2 substitua binários ou baixe componentes adicionais. Depois da limpeza, reinicie serviços de forma controlada, confirme que o processo não retorna e revise contas locais, chaves de acesso e logs de autenticação.

Para IoT, a contenção depende de segmentação e controle de tráfego. Dispositivos sem capacidade de agente devem ficar em redes separadas, com saída permitida apenas para destinos necessários. Quando houver suspeita de infecção, a equipe deve coletar o máximo de evidência disponível antes de reinicializar, incluindo tabela de processos, conexões, firmware, configuração e logs exportáveis. Se o equipamento não permitir verificação confiável, a troca de firmware ou substituição física pode ser mais segura que uma limpeza superficial.

A validação pós-incidente precisa cobrir mineração, DDoS e C2. Bloqueios de domínio e hash ajudam, mas não são suficientes diante da evolução observada da campanha. A defesa deve medir redução de tráfego anômalo, ausência de conexões para infraestrutura suspeita, queda de uso indevido de CPU, remoção de persistência e fechamento dos vetores de entrada. Como a família mostrou expansão de Windows para Linux e IoT, a resposta não deve se limitar ao primeiro host encontrado; a busca deve atravessar segmentos, arquiteturas e tipos de ativo.

• Aplicar correções ou isolar roteadores Dasan GPON vulneráveis a CVE-2018-10561.
• Remover exposição externa desnecessária e endurecer autenticação contra brute force.
• Verificar cron, /etc/rc.local, processos daemon suspeitos e limites de descritores em Linux.
• Bloquear e investigar comunicação com C2 defangado, incluindo tyz2020[.]top, sem transformar o indicador em link ativo.
• Segmentar IoT, restringir saída de rede e monitorar tráfego DDoS originado de dispositivos de baixo perfil.
• Investigar presença de mineradores compatíveis com Xmrig e revisar contas, credenciais e artefatos baixados por C2.