`Quasar Linux RAT` rouba credenciais de desenvolvedores em Linux e amplia risco na cadeia de software

Implante Linux combina execução em memória, persistência redundante, coleta de segredos de DevOps, captura via PAM, tunelamento de rede e ocultação com LD_PRELOAD e eBPF.

Componente	Quasar Linux RAT (QLNX), implante para Linux voltado a estáções de desenvolvedores, ambientes DevOps e credenciais usadas em publicação de pacotes, nuvem, contêineres e automação.
Vetor	O método inicial de entrega não foi identificado; após obter execução no host, o malware opera em memória, mantém comunicação com C2 por raw TCP, HTTPS e HTTP, e ativa persistência local.
Impacto	Roubo de tokens e credenciais de arquivos como .npmrc, .pypirc, .git-credentials, .aws/credentials, .kube/config, .docker/config.json, .vault-token, credenciais Terraform, tokens do GitHub CLI e arquivos .env, com risco de abuso em registries, nuvem e pipelines de CI/CD.
Prioridade	Investigar estáções Linux de desenvolvedores e runners com acesso a publicação, revogar segredos expostos, validar persistência em systemd, crontab e arquivos de shell, e procurar ocultação por LD_PRELOAD, PAM e eBPF.
Artefatos	Arquivos e mecanismos citados incluem .npmrc, .pypirc, .git-credentials, .aws/credentials, .kube/config, .docker/config.json, .vault-token, .env, systemd, crontab, .bashrc, PAM, LD_PRELOAD, eBPF, kworker e ksoftirqd.
Capacidades	O conjunto operacional inclui coleta de credenciais, keylogging, manipulação de arquivos, monitoramento de área de transferência, captura de tela, execução de comandos, injeção de código, proxies SOCKS, túneis TCP, execução de Beacon Object Files e operação de malha P2P.

Resumo técnico

Quasar Linux RAT (QLNX) é um implante para Linux direcionado a sistemas de desenvolvedores e operadores DevOps, com foco em credenciais que conectam estáções locais à cadeia de desenvolvimento e entrega de software. O risco central não está apenas no controle remoto do host, mas na combinação entre acesso a segredos de publicação, tokens de nuvem, configurações de orquestração, credenciais de repositórios e mecanismos de persistência. Em uma máquina usada para manter pacotes, imagens, infraestrutura como código ou pipelines, esse tipo de coleta pode transformar o comprometimento de um único endpoint em abuso de registries, alteração de artefatos distribuídos e movimentação para ambientes de build.

O malware foi descrito com execução sem arquivo a partir da memória, camuflagem de processo com nomes associados a threads do núcleo, inspeção do host para identificar ambientes conteinerizados, limpeza de logs e múltiplos métodos de persistência. Depois da implantação, ele mantém um ciclo operacional para comunicação com infraestrutura de comando e controle usando raw TCP, HTTPS e HTTP. A superfície de comando é ampla: há suporte a 58 comandos distintos, incluindo execução de shell, gestão de arquivos, captura de teclas, captura de tela, túneis de rede, proxies SOCKS, injeção em processos, execução de Beacon Object Files e administração de uma malha P2P.

Fluxo técnico

O ponto de entrada inicial não foi confirmado. A análise disponível começa após o malware já ter obtido execução no sistema Linux. Nessa fase, QLNX tenta reduzir sua exposição em disco, operar a partir da memória e se apresentar com nomes que imitam componentes legítimos do sistema, como kworker ou ksoftirqd. Essa escolha é relevante para defesa porque esses nomes aparecem com frequência em sistemas Linux reais; a caça não deve depender apenas do nome do processo, mas da relação entre binário, árvore de processos, descritores, mapas de memória, conexões de rede e origem da execução.

A persistência é redundante. O implante usa métodos como unidades ou serviços em systemd, entradas em crontab e injeção em .bashrc, além de outros mecanismos citados como parte de um conjunto de pelo menos sete técnicas. Essa redundância aumenta a chance de reinfecção local depois de uma remoção incompleta. Para um operador de resposta, isso significa que encerrar o processo ou apagar um único arquivo não encerra a intrusão. A validação precisa cobrir pontos de inicialização por usuário e por sistema, arquivos de perfil de shell, serviços habilitados, timers, tarefas agendadas e alterações recentes em diretórios usados por contas de desenvolvimento.

A coleta de credenciais é orientada a ativos de alto valor em engenharia de software. O malware busca tokens de npm em .npmrc, credenciais de publicação do PyPI em .pypirc, credenciais Git em .git-credentials, chaves e perfis AWS em .aws/credentials, configurações Kubernetes em .kube/config, autenticação Docker em .docker/config.json, tokens Vault em .vault-token, credenciais Terraform, tokens do GitHub CLI e variáveis em arquivos .env. Esses artefatos frequentemente carregam permissões persistentes, escopos amplos e acesso não interativo usado por ferramentas de automação.

QLNX também inclui componentes voltados a interceptar autenticação. Um backdoor inline em PAM captura credenciais em texto claro durante eventos de autenticação e registra dados de sessões SSH de saída antes de enviar o material ao C2. Há ainda um segundo logger baseado em PAM, carregado em processos dinamicamente vinculados, que extrai nome do serviço, usuário e token de autenticação. Essa capacidade amplia o problema para além dos arquivos de configuração: mesmo credenciais não gravadas em disco podem ser capturadas no momento do uso.

Superfície afetada

A superfície mais sensível é formada por estáções Linux de mantenedores, engenheiros com permissão de publicação, administradores de infraestrutura, operadores de CI/CD e máquinas usadas para acessar clusters, registries e contas de nuvem. Um host de desenvolvimento costuma concentrar sessões autenticadas, arquivos de configuração, clientes de linha de comando e chaves que não aparecem em servidores de produção. Quando esse host é comprometido, o atacante pode obter credenciais que permitem publicar versões adulteradas, acessar buckets, interagir com clusters Kubernetes, consultar segredos em Vault, enviar imagens para registries ou alterar automações de infraestrutura.

Ambientes que usam runners persistentes, servidores de build compartilhados ou máquinas de salto para tarefas DevOps também exigem atenção. Mesmo quando o malware mira o endpoint do desenvolvedor, os artefatos coletados podem funcionar em outros ambientes se não houver vinculação forte a dispositivo, política de escopo, expiração curta ou autenticação adicional. O risco é maior quando tokens de publicação em npm ou PyPI permitem envio direto de pacotes, quando credenciais AWS têm permissões administrativas, quando arquivos kubeconfig contêm certificados ou tokens reutilizáveis, ou quando variáveis em .env carregam segredos de produção.

A ocultação em duas camadas complica a visibilidade. No espaço de usuário, o uso de LD_PRELOAD pode interceptar chamadas de bibliotecas e esconder processos, arquivos ou conexões de ferramentas comuns. No nível do núcleo, um componente eBPF usa o subsistema BPF para ocultar processos, arquivos e portas de rede de utilitários como ps, ls e netstat quando recebe instruções do C2. A consequência operacional é que verificações feitas apenas com ferramentas locais possivelmente comprometidas podem produzir falsos negativos.

• Estáções Linux de desenvolvedores com arquivos .npmrc, .pypirc, .git-credentials, .aws/credentials, .kube/config, .docker/config.json, .vault-token e .env.
• Máquinas com permissões para publicar pacotes, enviar imagens, alterar infraestrutura como código, acessar clusters Kubernetes ou executar pipelines de CI/CD.
• Sistemas em que PAM, LD_PRELOAD, systemd, crontab, .bashrc e o subsistema eBPF possam ser alterados por uma conta comprometida ou por escalonamento posterior.

Hunting e telemetria

A investigação deve combinar endpoint, identidade, rede e telemetria de plataformas de desenvolvimento. No host, procure discrepâncias entre processos aparentando ser threads do núcleo e a realidade observável em /proc, mapas de memória, caminho de executável, usuário efetivo, tempo de criação e conexões externas. Processos com nomes como kworker ou ksoftirqd executando fora do comportamento esperado devem ser tratados como sinal de alerta quando associados a sockets de saída, descritores incomuns, bibliotecas pré-carregadas ou persistência em áreas de usuário.

Em Linux, a busca por rootkits precisa considerar que comandos locais podem ser enganados. Compare resultados de diferentes fontes: listagem de /proc, telemetria de EDR, inventário remoto, coleta forense offline, eventos de rede no perímetro, logs de autenticação e auditoria do sistema. Verifique variáveis e configurações relacionadas a LD_PRELOAD, bibliotecas adicionadas recentemente, alterações em arquivos de configuração do carregador dinâmico e módulos ou programas BPF inesperados. A presença de hooks em PAM exige revisão de módulos carregados, arquivos de configuração de serviços autenticados e bibliotecas modificadas.

Na rede, o comportamento esperado envolve tentativas persistentes de manter canal com C2 por raw TCP, HTTPS e HTTP. Sem indicadores de infraestrutura específicos, o hunting deve focar padrões: conexões recorrentes de estáções de desenvolvimento para destinos raros, tráfego saindo de processos sem binário claro em disco, fluxos TCP longos, uso de proxies não autorizados, conexões estabelecidas logo após login de usuário e comunicação gerada por processos com nomes semelhantes aos do núcleo. Também vale correlacionar eventos de captura de tela, criação de túneis e acessos a arquivos de credenciais.

Fora do endpoint, monitore abuso dos segredos que o malware procura. Em npm e PyPI, investigue publicações fora de janela, alterações de mantenedor, versões inesperadas e pacotes publicados a partir de locais incomuns. Em AWS, Kubernetes, Docker, Vault, Terraform e GitHub CLI, revise eventos de autenticação, uso de tokens, criação de chaves, alteração de permissões, execução de comandos administrativos e chamadas feitas por identidades de desenvolvedores fora do padrão histórico.

• Processos chamados kworker ou ksoftirqd com conexões de saída, árvore de processos atípica, mapas de memória suspeitos ou executáveis ausentes.
• Entradas novas ou modificadas em systemd, crontab, .bashrc, arquivos de perfil de shell e configurações de inicialização por usuário.
• Alterações em PAM, uso inesperado de LD_PRELOAD, bibliotecas compartilhadas recentes e programas eBPF não autorizados.
• Leitura incomum de .npmrc, .pypirc, .git-credentials, .aws/credentials, .kube/config, .docker/config.json, .vault-token, credenciais Terraform, tokens do GitHub CLI e .env.
• Publicações em registries, acessos de nuvem, ações Kubernetes, operações Docker ou execuções de pipeline originadas de identidades de desenvolvimento em horários, redes ou agentes incomuns.

Mitigação

A resposta deve partir do princípio de que credenciais locais podem ter sido copiadas antes da detecção. Isole o host afetado da rede, preserve evidências voláteis quando possível e evite depender exclusivamente de comandos locais para confirmar a remoção. A coleta deve incluir processos, conexões, persistência, arquivos de configuração de autenticação, bibliotecas carregadas, programas BPF, histórico de shell, artefatos de CI/CD e acessos recentes a arquivos de segredo. Depois disso, reimage ou reconstrua sistemas comprometidos quando a presença de rootkit em espaço de usuário ou eBPF não puder ser descartada com confiança.

A rotação de segredos é obrigatória para qualquer conta, token ou arquivo acessível no host. Isso inclui tokens de npm, credenciais PyPI, credenciais Git, chaves AWS, arquivos kubeconfig, tokens Docker, tokens Vault, credenciais Terraform, tokens do GitHub CLI e variáveis sensíveis mantidas em .env. A revogação deve ocorrer antes da retomada do uso da máquina e precisa ser acompanhada por revisão de logs nas plataformas correspondentes, porque a credencial pode ter sido usada para criar novos acessos, publicar artefatos ou alterar permissões.

Para reduzir exposição futura, remova segredos permanentes de estáções de trabalho sempre que possível. Prefira credenciais de curta duração, autenticação federada, escopos mínimos, aprovação para publicação de pacotes, assinatura de artefatos, proteção de ramos, MFA resistente a phishing e separação entre contas de desenvolvimento e contas de publicação. Em pipelines, use variáveis protegidas, ambientes isolados, runners efêmeros e políticas que impeçam tokens de publicação de ficarem disponíveis fora do job necessário.

A validação final deve confirmar ausência de persistência, normalidade de autenticação e integridade da cadeia de entrega. Revise pacotes publicados após a janela provável de comprometimento, compare artefatos com repositórios de origem, verifique imagens enviadas a registries e audite mudanças em infraestrutura como código. Onde houver suporte, habilite assinaturas e políticas de verificação para pacotes, contêineres e releases. Sem hashes, domínios ou endereços de C2 confirmados, a defesa precisa se apoiar em comportamento, controles de identidade e redução do valor dos segredos disponíveis no endpoint.

• Isolar hosts suspeitos, preservar evidência volátil e reconstruir sistemas quando houver indício de ocultação por LD_PRELOAD, PAM ou eBPF.
• Revogar e recriar tokens de npm, PyPI, Git, AWS, Kubernetes, Docker, Vault, Terraform, GitHub CLI e segredos presentes em .env.
• Auditar publicações de pacotes, alterações em registries, ações de nuvem, comandos Kubernetes, mudanças em pipelines e criação de novas credenciais.
• Substituir segredos estáticos por credenciais de curta duração, escopo mínimo, autenticação federada e controles de aprovação para publicação.
• Monitorar persistência em systemd, crontab, .bashrc, módulos PAM, bibliotecas pré-carregadas e programas eBPF após a contenção.