Quasar Linux RAT targets developer credentials and supply chain assets

TL;DR Trend Micro researchers have documented Quasar Linux RAT (QLNX), a previously undocumented Linux implant that harvests developer and DevOps credentials from npm, PyPI, AWS, Kubernetes, Docker, and CI/CD tooling. The malware uses fileless execution, dual-layer rootkit techniques, and 58 distinct operator commands to maintain persistent access while concealing its presence. Successful compromise could allow attackers to push malicious packages or pivot through infrastructure pipelines.

What happened

Trend Micro security researchers Aliakbar Zahravi and Ahmed Mohamed Ibrahim have published analysis of QLNX, a Linux remote access trojan targeting developer systems. The implant focuses on harvesting credentials stored in configuration and credential files commonly used across the software supply chain.

QLNX's credential harvester extracts secrets from .npmrc (npm tokens), .pypirc (PyPI credentials), .git-credentials, .aws/credentials, .kube/config, .docker/config.json, .vault-token, Terraform credentials, GitHub CLI tokens, and .env files. The malware executes filelessly from memory and masquerades as a kernel thread with names such as kworker or ksoftirqd to evade detection by standard process enumeration tools.

The implant establishes persistence through no fewer than seven different methods, including systemd, crontab, and .bashrc shell injection. It employs a two-tiered rootkit architecture: a userland rootkit deployed via Linux's LD_PRELOAD dynamic linker mechanism, and a kernel-level eBPF component that uses the BPF subsystem to conceal processes, files, and network ports from tools such as ps, ls, and netstat.

Once operational, QLNX maintains communication with command-and-control servers over raw TCP, HTTPS, and HTTP protocols through a persistent loop. The malware supports 58 distinct commands enabling operators to execute shell commands, manage files, inject code into processes, take screenshots, log keystrokes, establish SOCKS proxies and TCP tunnels, run Beacon Object Files, and manage peer-to-peer mesh networks.

QLNX includes two Pluggable Authentication Module (PAM) based backdoors. The first intercepts plaintext credentials during authentication events, logs outbound SSH session data, and transmits collected data to the C2 server. The second automatically loads into every dynamically linked process to extract service names, usernames, and authentication tokens.

The malware is capable of profiling its host to detect containerized environments and wiping system logs to remove evidence of its presence. The delivery mechanism for QLNX has not been disclosed.

Why it matters

For developers and DevOps personnel in the MENA region, QLNX represents a direct threat to the credentials that protect access to package repositories and cloud infrastructure. A successful compromise against a package maintainer or DevOps engineer could allow an attacker to:

Push malicious packages to NPM or PyPI registries, affecting downstream consumers
Access cloud infrastructure accounts and resources
Pivot through CI/CD pipelines to compromise build systems and deployment targets
Establish persistent backdoors across multiple systems using the 58 available commands
Harvest SSH credentials to lateral move within networks
Conceal all traces of the attack through log wiping and dual-layer rootkit hiding

The combination of fileless execution, redundant persistence mechanisms, and kernel-level concealment makes QLNX difficult to detect using conventional host-based monitoring. Organizations relying on process enumeration and log analysis for threat detection may miss QLNX's presence entirely.

Affected systems and CVEs

Linux systems (userland and kernel-level compromise possible)
npm package registry
PyPI package registry
AWS cloud infrastructure
Kubernetes clusters
Docker environments
Terraform deployments
GitHub CLI
SSH authentication systems
CI/CD pipelines using the above tools

No CVE assigned at the time of publication.

What to do

The source article does not provide explicit mitigation steps or defensive recommendations. Organizations should consider:

Restricting which systems can publish packages to npm and PyPI through separate, hardened credentials
Implementing kernel integrity monitoring and eBPF policy enforcement where possible
Monitoring for unexpected persistence mechanisms (systemd timers, crontab entries, shell RC file modifications)
Auditing and segmenting SSH access for DevOps and developer accounts
Using file integrity monitoring on credential files (.npmrc, .pypirc, .aws/credentials, .kube/config)
Detecting fileless malware execution through memory scanning and behavioral analysis
Isolating package publishing systems from general developer workstations

Open questions

How QLNX is initially delivered to target systems remains unclear
No specific victims or confirmed incidents are named in the analysis
The threat actor or group operating QLNX has not been attributed
The timeline of QLNX's discovery and initial deployment is not specified
The geographic scope and targeting priorities are not detailed
Whether QLNX has been observed in active use against production systems is not disclosed