Quasar Linux RAT o malware que rouba credenciais de desenvolvedores e coloca em risco a cadeia de fornecimento de software

Trend Micro tem detalhado um implante para Linux que aponta especificamente para ambientes de desenvolvimento e operações, batizado como Quasar Linux RAT (QLNX); seu design combina roubo sistemático de credenciais com técnicas de ocultação avançadas, o que o torna uma ameaça especialmente perigosa para a cadeia de fornecimento do software.

Ao contrário de muitas peças de malware geral, QLNX se concentra em extrair segredos que costumam residir em máquinas de desenvolvedores e pipelines: tokens de NPM e PyPI, credenciais de Git e cloud, arquivos .env e configurações de Kubernetes e Docker, entre outros. A obtenção de qualquer um desses elementos permite a um atacante publicar pacotes maliciosos, tomar controle de infraestrutura na nuvem ou mover-se lateralmente através de CI/CD, com potencial para causar um “efeito dominó” em projetos e dependências.

O que torna particularmente inquietante a QLNX é sua combinação de técnicas: execução fileless desde memória, camuflagem como fios de kernel (por exemplo kworker), e uma arquitetura de persistência redundante (systemd, crontab, modificações em .bashrc e outras). Além disso, emprega dois níveis de rootkit — um rootkit em espaço de usuário por LD_PRELOAD e um componente no kernel que usa eBPF para ocultar processos, arquivos e portos — e um backdoor que intercepta credenciais em processos de autenticação PAM. Essa mistura permite permanecer silenciosa durante longos períodos e capturar credenciais em claro justo quando o usuário se autentica.

Do ponto de vista operacional, o QLNX suporta dezenas de comandos remotos para gerenciar arquivos, injetar código, tomar ecrãs, registrar teclas e estabelecer túneis TCP/SOCKS, tornando-o uma ferramenta completa para controle remoto e exfiltração. Também pode carregar módulos em cada processo dinamicamente ligado para capturar tokens, mantendo comunicação persistente com sua infraestrutura de comando e controle por TCP, HTTPS e HTTP.

As implicações para desenvolvedores, mantenedores de pacotes e equipamentos de segurança são claras: uma máquina comprometida não só coloca em risco o código local, mas pode contaminar repositórios públicos e pipelines automatizados. Um atacante com permissões de publicação em NPM ou PyPI pode introduzir versões maliciosas que se propagam a muitos projetos e usuários.

Para mitigar o risco imediato, é imprescindível proteger os segredos e assumir que qualquer estação de trabalho pode ser objetivo. Entre as medidas práticas estão rotar e revogar tokens potencialmente expostos, mover credenciais a vaults gerenciados (secret managers) com acesso temporário e limitado, e substituir tokens de longa duração por mecanismos de identidade federada para CI (por exemplo OIDC) que evitam armazenar segredos em arquivos locais.

Do ponto de vista de detecção e resposta, convém rever artefatos e comportamentos que QLNX abusa: verificar variáveis LD_PRELOAD e módulos PAM suspeitos, auditar entradas incomuns em systemd e cron, verificar a presença de fios/processos que imitam o kernel, e monitorar uso de eBPF ou mapas BPF que não sejam justificados por ferramentas legítimas. Soluções EDR modernas e monitoramento de integridade podem ajudar, mas também é necessário isolar agentes build e usar ambientes efêmeros para minimizar a possibilidade de persistência e roubo de credenciais.

A estratégia a médio prazo deve centrar-se na redução da exposição da cadeia de abastecimento: exigir a assinatura de pacotes, activar processos de revisão de dependências, implementar builds reprodutíveis e aplicar controlos de acesso mínimos nas pipelines. Para organizações críticas, a resposta a um incidente deste tipo pode exigir refazer agentes de build e estações comprometidas desde meios confiáveis, e realizar uma pesquisa forense que inclua captura de memória para detectar execuções fileless.

QLNX mostra duas tendências que devemos abordar com prioridade: por um lado, a exploração de credenciais armazenadas em ambientes de desenvolvimento; por outro, o uso de tecnologias legítimas (LD_PRELOAD, eBPF, PAM) como vetores de ocultação. Para aprofundar a forma como funciona eBPF e porque o seu abuso complica a detecção, você pode consultar a documentação e recursos em ebpf.io. Para entender as técnicas de roubo de credenciais e os padrões de ataque que os equipamentos defensores devem monitorar, a matriz ATT&CK do MITRE é um recurso útil: https://attack.mitre.org/techniques/T1552/.

Em resumo, QLNX não é apenas outro malware para Linux: é um lembrete de que os desenvolvedores e suas máquinas fazem parte do perímetro de segurança. A combinação de controles técnicos, boas práticas em gestão de segredos e processos de hardening em CI/CD é a única forma realista de limitar o alcance de ameaças que buscam precisamente nossos tokens e pipelines para se espalhar.