Um novo malware de Linux conhecido como Quasar Linux, ou QLNX, está atacando ativamente desenvolvedores de software e engenheiros DevOps com um nível de sofisticação raramente visto em ameaças focadas em Linux. Diferente da maioria dos malwares que dependem de arquivos armazenados em disco, o QLNX roda quase inteiramente na memória, tornando-o muito difícil para ferramentas de segurança tradicionais detectarem.
O que mudou agora
A análise de analistas da GuardSix, que identificaram o malware, e pesquisadores da TrendMicro, revelou que o QLNX é construído em torno de uma estrutura de acesso remoto de 58 comandos projetada para burlar as defesas convencionais de endpoint Linux. O malware atinge sistemas que rodam Debian, Ubuntu, RHEL, Fedora e Arch, com estações de desenvolvimento e hosts de build CI/CD como foco principal.
O que diferencia o QLNX é sua capacidade de se adaptar a quase qualquer sistema Linux que infecta. Em vez de carregar componentes pré-construídos, ele embute código-fonte C bruto e usa o próprio compilador da máquina alvo para construir um rootkit personalizado em tempo de execução.
Vetor e exploração
A cadeia de infecção do QLNX se desdobra em seis etapas cuidadosamente sequenciadas projetadas para evitar deixar evidências. Ao ser executado, ele cria um arquivo que existe apenas na memória, escreve seu payload real nele, executa esse payload e, em seguida, remove o arquivo original do disco. O processo em execução não tem arquivo associado no sistema de arquivos, então ferramentas antivírus baseadas em disco não encontram nada para escanear.
Para evitar chamar a atenção, o QLNX reescreve seu próprio nome de processo para imitar threads legítimas do kernel, como [kworker/0:0] ou [migration/0]. Threads genuínas do kernel nunca deveriam manter conexões de rede em espaço de usuário ou ter um processo pai regular em espaço de usuário.
Evidências e limites
O malware compila seu rootkit embutido e a fonte do backdoor PAM contra cabeçalhos de kernel locais usando o gcc da vítima, produzindo um arquivo de objeto compartilhado único por host que contorna a detecção baseada em assinatura. O rootkit compilado carrega em todo o sistema modificando um arquivo que força todos os processos recém-criados a carregar a biblioteca maliciosa.
Uma rede peer-to-peer conecta os hosts infectados, de modo que a remoção de um nó de comando não corta o acesso do atacante. Isso torna a limpeza parcial ineficaz, pois o rootkit eBPF pode sobreviver a menos que seja removido completamente no nível do kernel.
Impacto e alcance
O dano vai muito além de um único endpoint. Uma infecção bem-sucedida posiciona um atacante dentro da cadeia de suprimentos de desenvolvimento, com acesso a tudo o que é necessário para adulterar código, publicar pacotes maliciosos ou pivotar para infraestrutura em nuvem. Uma estação de trabalho de desenvolvedor comprometida não é apenas uma máquina infectada; é uma porta dos fundos para repositórios de código, pipelines de build e ambientes em nuvem.
Defensores que perdem o comprometimento inicial podem enfrentar consequências que vão muito além da máquina primeiro infectada, incluindo vazamento de propriedade intelectual e comprometimento de software distribuído.
Medidas de mitigação recomendadas
A GuardSix deixa claro que a limpeza padrão não é suficiente. Uma formatação completa e reinstalação do SO a partir de uma imagem limpa verificada é a única correção totalmente confiável. Para equipes que não podem reimager imediatamente, recomenda-se isolar todos os hosts suspeitos da rede de uma vez, pois removê-los um por um permite que nós de malha sobreviventes reinfectem pares limpos.
Remover arquivos de persistência conhecidos, limpar a configuração da biblioteca de pré-carregamento e coletar logs de credenciais criptografados para revisão forense são essenciais. Na prevenção, restringir o compilador C em sistemas que não o requerem bloqueia o QLNX de construir seu rootkit.
Análise técnica detalhada
O QLNX utiliza técnicas avançadas de ofuscação e persistência. Ao compilar o rootkit no host alvo, ele garante que o binário resultante seja único para aquela máquina específica, tornando as assinaturas estáticas inúteis. O uso de eBPF (Extended Berkeley Packet Filter) permite que o malware opere no nível do kernel com alta eficiência e baixa detecção.
A modificação do arquivo /etc/ld.so.preload é uma técnica clássica de persistência que força a carga de bibliotecas maliciosas em todos os processos. O QLNX combina isso com a injeção de módulos PAM para interceptar autenticações, garantindo que credenciais sejam capturadas mesmo após a reinicialização.
O que os CISOs devem fazer imediatamente
Organizações devem monitorar arquivos de configuração de baixo nível de perto e rotacionar todas as credenciais em toda a empresa após qualquer detecção confirmada. A segmentação de estações de trabalho de desenvolvedores umas das outras quebra a malha peer-to-peer. É crucial auditar processos em execução em busca de nomes de processo suspeitos e conexões de rede incomuns.
Perguntas frequentes
Como o QLNX difere de outros RATs Linux?
O QLNX se destaca pela execução sem arquivo e pela capacidade de compilar seu próprio rootkit no host alvo, tornando a detecção baseada em assinatura ineficaz.
É possível limpar o QLNX sem reimager?
A limpeza parcial deixa risco residual porque o rootkit eBPF pode sobreviver. A reinstalação completa é a única recomendação segura.